Re: General resolution: LLM usage in Debian

Hello,

idk but doesn=E2=80=99t anyone knows how it works at work?

Flood of vibecoded slop everywhere.
Do a sane review of n klocs per change is impossible.
~200 lines per change is the max. After this the attention goes away. And th=
e flood of changes leads to automation bias. Lgtm ship it ;)

Maybe use llms strictly only to review patches and debugging?
Should only point to the bug but not how to fix the bug?

In the end llms are only
next token prediction based on probability.
There is no magic behind it. Just pure compute power.

I know by myself that it is to tempting to use llms.

It might work when you have a really good harness, lots of tooling, tests. q=
uality gates and no escape.

=46rom my own experience I know that llms are capable. I let it implement a n=
ew compression algorithm for the timescaledb extension. But do I know what i=
t was doing? Absolutely not.
And this scares me.
If you don=E2=80=99t have access anymore to llms (worst case), we are then c=
ompletely helpless.
Also llm written code has a different style.

If you really want to use llms you have to also scale the number of persons t=
hat review the patches.

Have a nice weekend :-)

Kind regards,
Manuel


> Am 25.07.2026 um 01:08 schrieb Soren Stoutner <[email protected]>:
>=20
> =EF=BB=BFOn Friday, July 24, 2026 1:33:01=E2=80=AFPM Mountain Standard Tim=
e Debian Project Secretary - Kurt Roeckx wrote:
>> Hi,
>> A new general resolution has been started about the use of LLMs in
>> Debian. The current proposals are available at:
>> https://www.debian.org/vote/2026/vote_002
>=20
> This page lists the resolution as withdrawn.
>=20
> https://www.debian.org/vote/2026/
>=20
> Is that some sort of classification error?
>=20
> --
> Soren Stoutner
> [email protected]
> <signature.asc>