Generative AI for PRs

Posted Nov 12, 2025 14:41 UTC (Wed) by emk (subscriber, #1128)
Parent article: About KeePassXC's code quality control (KeePassXC blog)

High-end generative AI (eg Claude Code with Sonnet 4.5) can be quite genuinely useful in the hands of a senior engineer. It occupies roughly the same space as a diligent intern. If you give it clear instructions, achievable goals and sufficient feedback, it can write a lot of OKish code quickly. But to actually use that code in production, you'll need to review it and understand it, and you'll need to impose architectural discipline. The entire process feels extremely familiar to me, because it's the same stuff I need to do to scale up a development team.

I also get much better results if I design the code for heavy, automatic testing. This includes things like property tests, which can easily generate a few million test cases. I also install linters, formatters, pre-commit hooks, CI, and all the other tools I'd set up for a team. Typically, I need more of these tools than I'd need with an all-human team.

I absolutely have used Claude Code on one or two open source projects I maintain. I do read all the code carefully, and don't hesitate to scrap or rework it as necessary. This is fine, as processes go. As long as an actual human can be trusted to take responsibility for the code, these tools can be useful in specific circumstances.

(And honestly, if I were getting spammed with AI CVEs referring to non-existent functions, I would be sorely tempted to set up Claude Code as a first pass filter to draft rejection notices for me. Reporting bugs in non-existent functions would lead to a permanent ban on that submitter.)

to post comments

Generative AI for PRs

Posted Nov 13, 2025 15:26 UTC (Thu) by khim (subscriber, #9252) [Link]

> It occupies roughly the same space as a diligent intern.

Can you clarify? Diligent intern is someone you spend time on today, to, hopefully, get a good colleague in the future.

I fail to see how spending your time on LLM can be a good time investment.

> If you give it clear instructions, achievable goals and sufficient feedback, it can write a lot of OKish code quickly.

There's a problem with that idea: it's actually faster to write code than to give a clear instructions, achievable goals and sufficient feedback if your code doesn't include bazillion copy-paste lines that are more-or-less identical.

And if your code does include bazillion copy-paste lines then the proper way is to find a way to not have that code duplication and not bring intern or LLM into your project.

I guess both intern and LLM can be useful for tests writing, where some copy-paste may be better to ensure that each individual test is simpler, in isolation… but that's it.

> This includes things like property tests, which can easily generate a few million test cases.

And how is that in improvement? Every time I need to pass VK-GL-CTS I want to cry because there are million tests that only are good to report ten thousands of errors if one mistake is made. So I need to spend thousand times more resources to get the exact same effect.

And it's like that everywhere: most of the “improvements” from the use of LLMs are net negative. They are doing and improving things that are not needed in the first place.

If, once a while, in the pile of garbage generated there are something nice it's a good thing, sure, but most of the time it's just garbage!