Skip to content

LLM (Generative AI) Policy

Background

Recently, Mbed CE has been receiving an increasing number of contributions that are assisted via, or generated entirely by, large language models (LLMs), also known as generative AI. We, the Mbed CE maintainers, are aware that these tools have value, but also come with significant downsides:

  • They ultimately work via very sophisticated pattern matching, not humanlike intelligence. So, when they encounter code and situations far away from their training dataset, their output becomes less predictable and they can make unintended or incorrect changes.
  • Even when asked to summarize or check their work, their output cannot be entirely trusted as it may be a confabulation.
  • They struggle to create documentation for their work: often, generated docs are either too verbose and flowery to be useful, or completely incorrect.
  • As they have no awareness of a programmer's long-term plan for a codebase, repeated operations done over time with an LLM can result in code that works but is extremely confusing and contradictory to read.
  • They are often trained on data that is copyrighted and non-public (opening the door to all sorts of fun copyright issues), or data where the authors did not desire for their work to be used to benefit LLM companies (not great from an ethical standpoint).
  • Training LLMs and running inferences with them has a heavy environmental cost.

Despite these downsides, LLMs can be a very useful tool for efficiently scanning the substantial Mbed CE codebase and finding the correct location and method to make a desired change. They can also be a valuable method of auditing and fuzzing codebases for potential security holes, as they're capable of reading large amounts of code and testing the things they have identified. We have seen many developers use these tools effectively as part of their work on Mbed CE, and do not want to disallow such responsible usage.

Ultimately, the choice of whether to use LLMs or not is up to the developer's choice based on the project and the task being done. To aid people in this choice, this document establishes a policy that defines the acceptable and unacceptable use of LLMs within Mbed CE.

Mbed CE LLM Policy

  • LLM tools may be used (responsibly!) when contributing to Mbed CE.
  • You are responsible for all code contributed under your name, regardless of whether any of it was generated by an LLM.
  • You should understand the code being contributed and be able to discuss and debug it independently. You should also have done sufficient testing to be confident that your change works as intended (whether that involves running existing Mbed OS tests or setting up your own test).
  • All contributions, whether an LLM was used or not, will be subjected to a rigorous code review by the Mbed CE maintainers.
  • Low effort contributions, e.g. where the code obviously does not work or where the stated purpose of the contribution has no relation to the actual code changes, are not allowed. They waste substantial maintainer time and effort, and repeated offenses may lead to a ban from contributing to Mbed CE.
  • This problem is not exclusive to LLM-assisted contributions, but unfortunately they make this kind of thing easier to do and more common.
  • While code should be commented and documented appropriately, documentation that has a very low information density or documentation that does not match the actual code is not acceptable. LLM users should review their code carefully for this before submitting a contribution.
  • We take the view that no documentation is better than incorrect documentation, because at least then there is no conflicting information!
  • We request that interaction with Mbed CE developers on the GitHub repo be done by humans. Automated agents must not independently open pull requests, file issues, post review responses, or communicate with contributors. LLMs may help draft text (just keep it concise!), but a human must review and personally submit every message. Project-approved automation and CI are excluded.

Our LLM policy is inspired by that of the Debian project. See that link for a more in-depth rationale on many of the points discussed here.