Posts with tag code-review

A candidate repeated my question back to me, waited a beat, and recited a definition word for word. The questions did not change. What they measure did.

The rules are written down. The agent reads them on every prompt. They still do not make it into the code, and nothing is broken enough for the bot to report. A rules file is not configuration. It is a suggestion with an unknown success rate.

I audit dependencies. Lockfiles, advisories, the whole ritual. Then the keyv worm shipped its payload as committed agent config, and I realised I have no equivalent reflex for the files that configure the thing writing my code.

AI adoption doubled our code output. Nobody budgeted for the reading. Telemetry from 22,000 developers shows the bill: 5x longer review, tripled incidents, and 31% more PRs merged with no review at all. This is what treating review as infrastructure actually means.

I committed code I hadn't read, felt the guilt, and almost filed it as a discipline problem. It wasn't. The gap between not trusting AI's code and not reading it is the clearest signal we have that the valuable part of the job moved downstream — from writing to reading.

Speed without reading creates technical debt. Here is exactly what I check when reviewing frontend code at data scale — and what AI keeps getting wrong.

AI can make developers faster. But speed without reading is just a faster way to create technical debt.

A comment under my last post made me rethink where AI ends and static analysis begins. Here is how I draw the line — based on a system I run in production.

Adding a new agent to my system takes 2 days. Not because of the architecture — but because teaching it to think like me is the hard part.

No Python, no Node.js, no custom plugins. Just ~2,900 lines of prompt engineering and a fan-out/fan-in architecture that actually catches real bugs.