Use of AI code assistants in the development

[Eugenio La Cava]

Hi all,

I recently forked both the kicad and the kicad-python repos to work on feature that are missing.

I have a question regarding the use of AI code assistant in the development of new features and in the fixing of existing bugs: is the use of such tools permitted, tolerated or frowned upon?

[Jon Evans]

Hi Eugenio,

I can speak as the maintainer of kicad-python, but for kicad as a whole, I'm only one of the lead developers and we have not discussed or released a formal policy on this.

AI code assistants may be used in many ways, ranging from fairly benign (prompting one to explain a piece of code to you to help you understand it, or using one as a refactoring tool to modify an existing piece of code in straightforward ways) to potentially questionable (generating large chunks of code or even entire projects, which may have questionable authorship/licensing implications) and definitely unacceptable (wasting people's time by posting the incorrect output of an LLM without disclosing that it is from an LLM, and not having the knowledge yourself to double-check the output).

I would recommend using the following guiding principles when considering using LLMs as part of a contribution to KiCad or any open-source project:

1) Do not make any technical contribution that you do not fully understand yourself.  Bug reports, code submissions, or discussion in the form of comments are all contributions to an open-source project.  One of the best ways to burn goodwill by using AI tools that I have seen is to attempt to make contributions that one does not understand, resulting in either being dismissed as nonsense or (worse) wasting the time of actual human maintainers to try to understand something that ends up being the fabrication of an LLM.

2) Always disclose the use of an LLM in any work you submit, whether saying "I translated this comment to English using ChatGPT" or "I used Claude to try to fix this bug, and this is the solution it suggested".  LLM outputs can be very useful as a shortcut to getting work done, but they have serious limitations: they are not true intelligence, and they will easily invent solutions that do not work or have subtle problems.  The output of an LLM needs to be scrutinized at least as much as that from an unaided human, because it is more likely that the human who prompted the LLM either doesn't fully understand the output, or did not check it carefully.

As to whether or not the KiCad project will accept code contributions that were primarily or substantially generated by LLMs, I cannot answer that on behalf of the team, it's a complicated question.

Separate from the AI question, I will also note that it is best practice for KiCad (and most open-source projects) to discuss with the development team before taking on the development of new features.  This can be in the form of asking on the mailing list, commenting on an open issue saying you'd like to work on it, or opening a new feature request issue and stating that you're willing to work on the implementation if it is accepted.  Starting by forking and writing code might work, but if you do so without discussion, you risk having your code submission rejected because it is not compatible with other future plans that you didn't know about.

Best,

-Jon

--
You received this message because you are subscribed to the Google Groups "KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devlist+u...@kicad.org.
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/0b635111-4421-4c6a-aeea-7d7d515810fbn%40kicad.org.

[Eugenio La Cava]

Hi Jon,

Thank you for the prompt reply and the precious feedback.

I realised that I might have sounded arrogant in my previous message, and I apologise for that.

It wasn't my intention.

I genuinely want to help and learn in the process.

I will search the tickets in the kicad-python's and find a way to be of help, and I will also try to contribute to and learn from this mailing list.

Best,

Eugenio.

You received this message because you are subscribed to a topic in the Google Groups "KiCad Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/a/kicad.org/d/topic/devlist/2-mAIjt971c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to devlist+u...@kicad.org.
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCAgXpM6xVigUoWQDwsjOOxzOXOb_s%3Dx1hLSKczsZ0ebKg%40mail.gmail.com.

--

Dr. Eugenio La Cava

Dottore di Ricerca in

Scienze Agrarie ed Ambientali

-

Dr. Eugenio La Cava 

Philosopher Doctor in

Agricultural and Environmental Sciences

[Salvador E. Tropea]

Hi Jon:

My 2 cents on this:

On 13/7/25 18:03, Jon Evans wrote:
> ... they will easily invent solutions that do not work or have subtle
> problems.


I strongly advice to ask to the AI to generate code to test the
generated code. AI can write code really fast, so generating the tests
is fast, and you can be more confident about what was generated looking
at the test.


Regards, SET

[Eugenio La Cava]

Hi Salvador,

This is precisely what I am doing.

Whenever I generate code with Claude code, I ask him/her/it to write and execute tests on the code that was generated, and then I run the tests myself again to verify that everything checks out.

Often, the code needs to be corrected because it has bugs, but everyone makes mistakes, even the most brilliant programmer.

I'm not letting Claude blindly generate code and then push it to any repo.

I am not so experienced, but neither so naive as not to test the code.

--
You received this message because you are subscribed to a topic in the Google Groups "KiCad Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/a/kicad.org/d/topic/devlist/2-mAIjt971c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to devlist+u...@kicad.org.
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/1ddb19ac-ce7a-45b9-9de9-075396048d4b%40inti.gob.ar.

[Jon Evans]

This is a fine approach when writing new software or new pieces of software in an existing codebase.

It is not universal though: for a piece of software like KiCad, it is often a significant challenge to come up with a suitable test that actually tests for desired behavior.

It is also not currently feasible to write automated tests for parts of KiCad (for example, anything involving the UI).

A test that tests against the behavior you *think* the code should have is only useful if that actually matches the behavior the code *actually* should have.  For large codebases like KiCad that have been around for a while, understanding the latter takes time working with the code.

-Jon

--
You received this message because you are subscribed to the Google Groups "KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devlist+u...@kicad.org.

To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/1ddb19ac-ce7a-45b9-9de9-075396048d4b%40inti.gob.ar.