@bboeckel@toot.thoughtworks.comAt work, since quality and long term maintainability are our competitive advantage, we ended up with a couple of rules for developers who want to use these statistical tools (as opposite to fully debuggable code generation tools we also use and sometime even develop for internal use):
1. All code and documentation suggested by a
#LLM must be clearly marked with something like
// begin LLM: Copilot and
// ens LLM: Copilot.
2. All commits message that contains changes suggested by a LLM must start with
[LLM].
We have a few codebase that evolved over decades (and got carefully migrated over time through IDEs, framework versions, build systems and so on), with several new developers joining the teams but also few of them leaving.
Yet, over all these years, it has always been possible to reconstruct how and why a certain change had been introduced.
Now, including the output of these mindless statistical agents might easily demage the whole codebase in subtle ways, hurting the trust of our customers and ultimately our edge over alternatives.
We discussed if it was possible to forbid the use of these tools, mostly because of
#copyright and
#dataprotection concerns, but end up realizing that given how the hype is affecting the IDEs, with eg.
#Microsoft pushing his
#Copilot down the devs throat, we cannot really forbid them to new devs already addicted.
So we are opting for demage reduction, with the hope to be able to assess the total value (or demage) effectively provided by these tools.
Unfortunately these tools are designed to avoid any responsibility, so you cannot create a git account for Copilot's commits, so we know that some junior devs might forget to mark the LLM output, but fortunately they are going to pair program with a senior for a while, at the beginning.
This however shows how pair programming and code reviews serve pretty different purpose and cannot catch all the issues that might be evident to the other.
@mtorchiano@mastodon.uno 
Arno roule 
