I have as well, like Kieren, used LLMs for a variety of tasks, both in my day job and for personal coding projects.
On Mon, Jun 1, 2026 at 12:04 PM Kieren MacMillan < [email protected]> wrote: > I have worked a fair bit with LLMs in the context of <my day job> Here's a few thoughts that are probably germane to this discussion, and that I hope will be of some use for you: - I think that using these systems to aid your own understanding of the code is hardly worth documenting or legiferating about (and they are often very helpful in that) - I have found that for many programs their reviewing capabilities are extremely useful. I have a habit of typing down code and quickly showing it to whatever AI I have at hand. It saved me a lot of time, it'll handily catch missing edge conditions, inverted loop conditions, various random little runaways. Also don't think this is worth documenting whether this is permitted use or not, to me it's a code analysis equivalent to syntax checking - I have also found it extremely useful to use them to look into debug/regression/profiling runs and produce cursory analyses. They are often very time-efficient for that, and again, they are just better log parsers with soem analysis apability. The way I see it this is also an area that is comfortably a free-for-all. People should do what fits their needs best. I will tell you that at the moment I feel that for me and my work, my impression is that I produce approximately the same number of (better) features per unit of time: my code feels more robust, it's enormously more complete (I leave behind far fewer fixme's for example, or todo's), and it's much more thoroughly and continuously tested. I am convinced it's better code overall. I agree with what seems to be prevailing sentiment and intent of this conversation: what do we do when these tools produce material that is meant to go into the repo as the main content. I think it makes little difference if that is C++/Scheme/... language (the code) or English/German/Italian/Chinese/... language (the docs). I also think that it seems right that the tool does not matter: the _person_ submitting is the author of the code for all intents and purposes. Whether it was typed on a keyboard, voice-recognized, or generated by an agent (presumably under user guidance) makes no difference. The submitting human should carry all responsibility for it. Thinking about it, it seems to me that in this case it's probably wise to document in the submission which agents' help (name and versions are probably ideal) was used to produce the submitted text, and to what degree the machine-generated code was retained as-is or modified. Aside from the curiosity, this has to do with potential legal issues: if you imagine a future date when a claim is made against "AI-Bot-23" chances are this will include a version range for it as well. Reconstructing such version range on our commits after the fact is probably much more trouble than just saying "Assisted-by: AI-Bot-23 v3.1, Coding-Bot-34 v1.7", and stating the retained-vs-handmodified rate in the text of the commit message. (Btw, the linux kernel folks have proposed a specific git tag for this, probably wise to use that one). With this information in the repo the project will be able to assert what content may need reworking and what is instead in a 'good' state already, should a problem of this kind arise. And absolutely very agreed on the point about reviewer's load: it seems wise to raise awareness that submitted code is work for the reviewers and thereby more code induces more work. Like in all projects, there will be trust built on a per-individual fashion, and this will in turn cause more scrutiny in some cases versus others. Seems like a normal part of life in a project where several people work together, coding assistants don't seem to change that all that materially. HTH L -- Luca Fascione
