Am 01.06.26 um 13:14 schrieb Luca Fascione:
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)
Absolutely! In my personal work this is the biggest part of AI anyway.
In case of lilypond's #34 i felt need to overlook all history since
creation of the issue, and while i could not include the mailing lists
(yet!) i would not have felt able to do anything without a special tool
to enable local LLM to gain and create overview about 3k lilypond MRs
and 7k lilypond issues. How should one read this, even with classical
keyword search etc.?
- 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
+1
- 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.
+1
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.
Absolutely.
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.
Well this produces significant overhead for creating code. This reminds
me of earlier times when in academia you were asked to prove you found
source in a real book from paper and not in "the internet", or such.
And from your above one could actually conclude that hand-written code
should be checked more thoroughly ;-)
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.
Yes. But completely independent from the coding tools.
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.
Exactly.
Arno
HTH
L
