Reviewing a colleague's pull request starts from trust. They understood the problem, wrote the fix, and probably tested it before pushing. My job is to catch what they missed, not to re-derive whether they understood the assignment in the first place.
That's the whole shift. Not worse code. A different kind of author, one that never learned to say it isn't sure. Reviewing a model's diff starts from nothing. It didn't understand the problem so much as pattern-match toward something plausible. It didn't test it unless told to. And it will say it's done in the same confident sentence whether it's actually done or just looks done.
what actually goes wrong
It's rarely syntax. Models are good at syntax. What slips through is scope, confidence, and claims of correctness nobody earned.
Ask for a bug fix and the diff can look complete without being complete. You get the fix plus three refactors nobody asked for, each reasonable in isolation, none reviewed the way the original fix was. Ask for a CSS change and get told it's fixed, when fixed meant a rule was added, not that anyone looked at the rendered page. I had exactly this happen building my own site. Two buttons, active and hovered, were both meant to look selected, and a fix landed that only worked until you hovered the button you'd just clicked, which is the one thing anyone actually does right after clicking it. It wasn't complete until someone opened a browser and inspected the actual computed style and saw the text color match the background.
The same thing happens with facts, not just code. A thesis draft I was writing carried a claim about two ride-hailing apps and an OTP flow, stated with total confidence, and it turned out backwards on the first real check. Confidence was never the signal, not even with people, but a person's confidence at least correlates loosely with whether they checked. A model's doesn't correlate with anything.
the discipline that replaces trust
With a model, your usual instinct for what to skim has nothing to calibrate against. With a colleague, you skim the parts you trust and slow down for the parts you don't, and that instinct is usually right because it's built on actually knowing them. Every line needs the scrutiny of the first line, because there's no history to lean on for which lines are safe.
Nothing is done until it's verified the way a stranger would verify it, run it, look at it, read the actual output, not the description of the output. A screenshot of the change beats a sentence describing the change. A computed style beats a claim that a rule was added. A checked fact beats a fact stated with confidence. It's slower than trusting the summary. It's also the only way to know the summary was true.
the bottleneck moved
Writing code got dramatically faster. Reviewing it didn't. Reviewing was never a typing-speed problem. It was a judgment problem, and judgment doesn't scale just because the model does.
The teams that ship faster with AI-generated code aren't the ones generating more of it. They're the ones who rebuilt review around the assumption that nothing is true until it's checked, and got fast at checking.
That's the actual skill now. Not writing code. Reading it like it hasn't earned your trust yet, because it hasn't, until you've looked.
conclusion
Verifying harder isn't the whole answer, the cheaper fix is needing less of it. A short standing set of rules, don't invent this pattern, don't touch that file, always verify this way, turns a hundred small judgment calls into one decision made in advance instead of caught after the fact. An open-ended request produces an open-ended diff too, so asking for one bounded piece of work at a time keeps what needs reviewing small enough to actually hold in your head. I've stopped a task mid-way before, three steps into a direction I hadn't actually asked for, and the fix wasn't reviewing the output more carefully once it landed. It was cutting the task back to what I meant before more of it got written.
More on actually fixing this soon, it deserves its own piece.
Get new essays and theses by email
More essays
- Pricing AI Products When the Cost per Task Keeps Falling Oct 27, 2026
- The Liability Wall Stopped Being Hypothetical Oct 4, 2026
- The Personal Assistant Landscape, Right Now Sep 30, 2026
- The Home Doesn't Have One User, So Its Assistant Shouldn't Either Sep 26, 2026
- Qualities of Great AI Coding Agents Sep 22, 2026
- The AI Bubble Deflates, The Technology Doesn't Sep 22, 2026
- The Boring Levers That Actually Run A Boutique Agency Sep 15, 2026
- India's Seed Stage Is Missing Its Powerhouse Sep 13, 2026
- What Not To Do In A YC Interview Sep 8, 2026
- An AI Assistant That I Actually Want Sep 1, 2026
- The Small Things I Keep for Myself Aug 31, 2026
- What Changes When You Go From Operator to Investor Aug 10, 2026
- The Wow Moment Shouldn't Take Two Weeks Apr 21, 2026
- The Three Moments That Will Make or Break Littlebird Apr 14, 2026
- Voice at Work, Why It's Harder Than It Looks Mar 31, 2026
- Top of Funnel for Voice-First Tools Is Not Signups. It's Someone Else's Product Mar 27, 2026
- When Thinking Outruns Writing Mar 26, 2026
- Why Voice-First Tools Struggle in India Mar 23, 2026
- When AI Disappears, Value Appears Mar 20, 2026
- The Tiny Feature That Saves Your Users and Your Metrics Feb 5, 2026
- Anatomy of a CLI-Based Code Assistant Jan 20, 2026