In 2024 I wrote about fixing code review after it became our team's bottleneck. Everything in that post assumed a person had written the code. Most of my code is now written by an agent, and those PRs can wait a week for review.
This post goes back through my old review hierarchy and asks who checks each layer now. It also covers what I check instead, and where that approach breaks.
AI built most of a recent feature, and built it well. Then UAT surfaced a requirement from a client meeting that never made it into the planning docs.
This is about the last 10%: the context that never reached the AI, and the judgement calls about risk and timeline that it can't make on your behalf.
Six issues describing five phases, and I don't use them that way any more. Plan, specify and constrain have collapsed into a single conversation.
The collapse is the success condition rather than a failure. The five phases remain the fastest way to diagnose work that has gone sideways, even when they're no longer sequential steps.
Ad-hoc prompts produce inconsistent documentation because the AI doesn't know your standards. You can hand a junior engineer a style guide; with prompts there is no equivalent.
So I built one. Encoding standards as reusable skills works like a type signature — constrain the input and the output, and the shape of the work stops drifting.
When AI writes code at volume you can't read every line, and you shouldn't have to. Tests become how you verify output without parsing the implementation.
This is about why most coverage targets are theatre, and the question worth asking instead: if I read only the tests, would I know whether this code is correct?
If you skip planning and go straight to "build this", the AI will invent a plan for you. It won't reflect your domain, your constraints, or what you actually need.
This covers which planning artefacts earn their keep — PRDs, mapping docs, statements of intent — and a short readiness checklist for deciding whether work is ready to hand over.
We estimated 232 hours for the content and meta migrations on a major editorial platform. It took 80, at the same scope and the same review rigour.
The difference came from how the work was divided: AI as a product manager before any code, then as a junior engineer afterwards, with me as tech lead throughout.
The pitch is speed. The reality, for a lot of engineers, is bloated PRs full of defensive code that nobody wants to review.
AI isn't unreliable; unconstrained usage is. This is about what changes when you define shapes, types and tests up front rather than hoping a better prompt will do the work for you.
I used to enforce heavy pre-commit hooks to optimise for fast feedback. These days, I push most of those checks to CI.
This post isn’t about tooling so much as it is about flow state, cognitive load, and learning the cost of enforcing the right checks at the wrong time.
There’s a point in a long, complex project where you stop noticing the shift happening. You’re answering a few more questions, stepping into a few more decisions, translating a few more ambiguities.
And then one day you realise the project isn’t just something you work on anymore. It’s something you carry.