Re: Ballot option: Debian is created by humans

On Wed, 12 Aug 2026, 19:12 Matthias Geiger, <[email protected]> wrote:

> On Tue, 11 Aug 2026 21:27, Christian Kastner <[email protected]> wrote:
> >Hi Matthias,
> >
> >while I respect that you have principles that lead you to reject LLM
> >contribution, for the purposes of this vote, things like this don't
> >help:
> >
> >On 2026-08-11 19:57, Matthias Geiger wrote:
> >> Lintian complaining that a package has no watch file. An LLM might try
> >> to "help" by writing a d/watch file. However, without context, this can
> >> be totally wrong.
> >
> >Yes, and this was realized from the very beginning, resp. a design
> decision.
> >
> >LLM solutions have evolved substantially. The have been doing retrieval
> >augmented generation, tool calling, and do lots of other things for many
> >years now.
> >
> >To offer some anecdata, the results I'm getting from LLMs are generally
> >high quality.
> >
> Hi,
>
> I'll grant that there has been some development,sure.
> >> If the package has no VCS upstream or isn't developed
> >> anymore, a watch file makes no sense. A seasoned contributor will know
> >> that and ignore/override said warning; an LLM can't.
> >
> >Of course it can...
> >
> >Here's a simple dialog [1] with Kagi Assistant [2] for ISC cron. You can
> >see the search queries it performed, the reasoning steps, and the
> >conclusions.
> >
> >For cron, it generated a correct version 5 file pointing to isc.org, the
> >original (and inactive) upstream. Our cron still has version 4 pointing
> >to Salsa (because we maintain a fork), so it didn't just copy our code.
> >
> >One could argue "but it didn't find the fork", but I asked specifically
> >for ISC cron (not Debian cron), and one of the searches included the
> >Debian package specifically so it's not like it missed something.
> >
> >Again, I do wish to respect other people's principles and decisions. But
> >we need to have an informed vote, and for that we need to get the facts
> >straight.
> >
>
> Some models might be able to do this, yeah. This doesn't change the fact
> that unless the model is constantly retrained (which takes a significant
> amout of time and resources), it will have information that is out of
> date.
>

Model doesn't have to contain that information. It only needs to know that
such information exists and figure out where to find it, then it can go
out, read the latest version of the Debian Policy and check latest commits
in debian branches of similar projects on Salsa to come up with a specific
solution for this package.

It doesn't need restraining for that. Tool use is the game changer.


Furthermore, it is simply not possible to build an LLM that does not
> hallucinate [0]. This means that even if you get to 99% accuracy, at the
> end of the day, I still can't trust the output. Which defeats the
> purpose, if such validation is still needed. Then I can just go ahead
> and write my own code; if I make any errors, that is on me, but at least
> it is deterministic.


And again that is already obsolete as the tool usage grounds the LLM in
verifiable facts. It can use compilers, linters and all kinds of tests to
automatically validate its changes, add new tests that verify that
requested changes are actually effective and iterate based on test errors.
It is everyday agent-assisted coding nowadays.

Plus it can spawn a separate critical agent that will review and critique
the output of the first one.

The quality of the result is evolving monthly.