On Tue, 11 Aug 2026 21:27, Christian Kastner <ckk@debian.org> 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.