Hello, idk but doesn’t 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 the 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. quality gates and no escape. From my own experience I know that llms are capable. I let it implement a new compression algorithm for the timescaledb extension. But do I know what it was doing? Absolutely not. And this scares me. If you don’t have access anymore to llms (worst case), we are then completely 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 that review the patches. Have a nice weekend :-) Kind regards, Manuel > Am 25.07.2026 um 01:08 schrieb Soren Stoutner <[email protected]>: > > On Friday, July 24, 2026 1:33:01 PM Mountain Standard Time 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 > > This page lists the resolution as withdrawn. > > https://www.debian.org/vote/2026/ > > Is that some sort of classification error? > > -- > Soren Stoutner > [email protected] > <signature.asc>
