AI Coding Assistants

[mcuee]

@dl8dtl @stefanrueger and @MCUdude

I am just starting to use the free AI tools to see if they can be useful in terms of helping out on the issues. I am not going to ask them to really come out with a PR or things like that. I do not have access to a paid coding assistants and I have no plan to pay for one any time soon.

Linux kernel AI Coding Assistants guidance for reference, maybe we can adopt it as a guideline as well.
https://docs.kernel.org/process/coding-assistants.html

Please share your thoughts.

[mcuee]

Some example uses from libusb, hidapi and libusb-compat project for reference.

1. long standing issues of libusb-compat-0.1

• Fix memory leaks in USB bus and device cleanup libusb/libusb-compat-0.1#31

2. github action related issues and proposed fixes

• github action issues libusb/libusb#1837
• Fix GitHub Actions workflow issues: CIFuzz location, outdated actions, redirected owner libusb/libusb#1838

3. libusb proposed enhancements in terms of documentation

• hotplug: fix LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT safe-function documentation libusb/libusb#1811
• doc: add man page generation from Doxygen libusb/libusb#1805

4. libusb Windows hotplug and macOS concurrency issue analysis confirmation test code generation

• Race in libusb_get_device_list and libusb_free_device_list with WinUSB backend and maybe others as well libusb/libusb#1793
• Darwin backend: concurrency audit (8 issues, partial PR coverage, proposed roadmap) libusb/libusb#1798

5. hidapi improvements

• libusb: Fix high CPU usage in callback thread libusb/hidapi#783
• cmake: declare version and policy requirements once at the top level libusb/hidapi#808
• windows: fix LNK4006 duplicate symbol warning in static CMake builds libusb/hidapi#809
• windows: guard static_assert with __STDC_VERSION__ for C99 compatibility libusb/hidapi#810
• libusb: make hid.c compile cleanly as C++ libusb/hidapi#811
• cmake: add HIDAPI_BUILD_AS_CXX to compile sources as C++ libusb/hidapi#814

[mcuee]

I am trying to use the free AI tools to help out on the analysis and documentation side of avrdude.

1. Documentation

• To improve the documentation of libavrdude functions #1057
• avrdude documentation improvement  #1674

2. Python GUI Windows packaging
   Upload avrdude-gui artifacts for Windows #1946

3. Analysis of long standing issues

• PICKit 4, SNAP, Atmel ICE and Power Debugger only work with hidapi but not libusb #1221
• Errors and warnings while running avrdude -c '*/u' on s390x #1917

As mentioned, I am not going to ask them to really come out with a PR to fix issues. I do not have access to a paid coding assistants and I have no plan to pay for one any time soon.

But the documentation improvement can probably landed in Wiki and avrdude docuemntation if we can agree on the usage of AI tools.

[mcuee]

Some other potential issues we can ask AI tools to help out, if we agree on the policy to use AI tools.

• Reference to avrdude issues not planned -- but PRs will be welcome #1710
• https://github.com/avrdudes/avrdude/wiki/Known-limitations-of-avrdude-and-OS-support-information#known-issues-for-test-avrdude-tool

[stefanrueger]

I agree with the linux kernel policies. For AVRDUDE contributions the (human) submitter should be responsible for

• Reviewing all AI-generated code
• Ensuring compliance with licensing requirements
• Taking full responsibility for the contribution

I also suggest that the code that's been contributed by AI should be marked as such with an assisted by <AI generator name/version>.

Having seen a lot of wrong, misleading and hallucinated AI-generated diligent reviewing (and testing as per usual) is paramount.