The Skill That Mattered for Decades
Ask an experienced engineer what they're good at, and the answer almost always circles back to writing: building a tricky function cleanly, translating a problem into elegant code, picking the right pattern at the right moment. Producing code was the scarce, well-paid, admired skill. Reading code – going through someone else's pull requests, checking whether it holds up – was the chore you squeezed in between the real work. Hardly anyone ever bragged about being a good reviewer.
That ratio is now flipping. When a model writes most of the new code – and in many teams it already does – production is no longer the bottleneck. Code arrives faster, cheaper, and in larger volumes than a human would ever have written by hand. The constraint moves to the one place no model takes off your hands: understanding whether the code is right, and owning the consequences when it ships.
The decisive engineering skill of the coming years, then, isn't writing code. It's reading someone else's – quickly, sceptically, ruthlessly.
The Inversion
For decades a quiet assumption held: writing is hard, reading is easy. Designing a function that solves a problem was the demanding, creative part. Reading it and signing off was routine – a safety net, not the main act. Which is exactly why review was the unloved stepchild in most teams: under-budgeted, rushed, rarely taken seriously.
AI inverts that ratio precisely. Writing – translating a clear intent into working code – is exactly the kind of work models excel at. It's well-bounded craft that appears a million times over in the training data. What a model doesn't supply is judgement: the ability to tell whether this code does the right thing in this system, with this data, under this load – and whether anyone can stand behind the consequences once it goes live.
The scarcity has moved. Generation has become cheap; comprehension has stayed expensive. And comprehension can't be delegated: it's precisely the activity a human has to take on, because it's the point where "the code runs" becomes "we understand what it does and we vouch for it." Review used to be the end of the pipeline. Now it's the eye of the needle everything has to pass through.
Why AI Code Is Uniquely Treacherous to Review
Humans have always reviewed code with a single, highly efficient heuristic: looks reasonable → probably fine. That shortcut works because bad human code usually also looks bad. Tangled logic, crude variable names, a comment reading "TODO: this is a hack" – the surface betrays the weakness. You read the first few lines, catch the smell, and look harder.
AI code demolishes that heuristic. It is plausible. It compiles. It reads cleanly. The variable names are sensible, the structure is conventional, the comments are polite. It looks like the work of a competent, well-rested colleague – and is still confidently wrong in subtle ways:
- an edge case that's never handled – the empty list, the negative amount, the timezone right on the day boundary
- an API call that's invented: a method that sounds so plausible you take it for real, until it doesn't exist at runtime
- a silent security hole – user input dropped unsanitised into a query, a secret in the logs, an authorisation check that forgets exactly one path
- an assumption that doesn't hold: that the response is sorted, that the field is never null, that the operation is idempotent
With human code, appearance and correctness roughly track each other. With AI code they're decoupled. The model optimises for plausibility – for code that looks like correct code – and that is not the same thing as correctness. Which is precisely why AI code is more dangerous to review than the work of a shaky junior: with the junior, the rough surface warns you. With the model, the smooth surface lulls you.
The New Failure Mode Is Rubber-Stamping
There's a failure mode almost no one sees coming, because it doesn't feel like a failure. It feels like productivity.
The mechanics are simple and brutal. Volume goes up: where two pull requests a day used to run through review, now it's ten. The time per review stays flat or shrinks, because the pressure to ship has risen. So attention per line drops. "I understand what this code does" quietly becomes "looks plausible, passes the tests, approved." That's rubber-stamping – the wave-through where the green tick has lost the meaning it once carried.
The insidious part: from the outside it looks identical to functioning review. The same pull requests, the same approvals, the same green CI. Except no one is really looking any more. The team ships more and understands less. Every rubber-stamped PR adds a little code to the system that no human ever fully held in their head – and that is the most expensive form of technical debt there is: not code that looks bad, but code nobody understood and therefore nobody can safely change.
That debt compounds. The first waved-through bug is cheap. The tenth sits on a foundation of nine other unexamined assumptions, and nobody knows which still hold. When a team wakes up at this stage, the honest question is rarely "where's the bug?" but "do we even understand our own system any more?"
What Good Review Looks Like Now
When writing gets cheap, reading has to get more demanding. Good review in the AI era no longer checks syntax and style first – linters and the model itself handle that. It checks the things a model is structurally most likely to get wrong and a rushed human is most likely to miss:
- Intent before implementation. The first question isn't "is this code correct?" but "does it solve the right problem?" Code can be flawless and still do the wrong thing, because the model plausibly misread the task.
- Architecture, not the line. Does this change fit the structure of the system, or does it smuggle in a second, competing pattern? Models build locally sensible and globally inconsistent.
- The edges. The empty input, the boundary value, the concurrent access, the timeout. Exactly the cases that never show up on the happy path – and the ones the model is most likely to have skipped.
- The error paths. What happens when the call fails, the database drops, the response half-arrives? Generated code describes success eloquently and failure patchily.
- The security surface. Every place user input, permissions, secrets, or external data come into play. The model has no notion of a threat; that has to come from the human.
And above all of it sits a cultural rule that must not be negotiable: whoever submits AI code owns every line of it. Not "the AI wrote it that way" – but: you submitted it, so you can explain why it is this way and not another, what it does on the empty input, and why you trust that API call. If the submitter can't, the pull request isn't finished, however green the tests glow. The model typed the code; accountability can't be typed alongside it.
"Can't We Just Have AI Review AI?"
The obvious objection: if reading is the new bottleneck, why not have one model review another model's code and be done with it?
As a first pass, that's actually sensible. An AI reviewer catches the obvious: unhandled error cases, missing tests, known security patterns, style breaks. As automated linting on steroids it's valuable, and it takes the blunt work off the human so they can save their attention for the hard part.
But it doesn't solve the real problem, for two reasons. First, it shares the blind spots. The same training biases, the same pull toward plausible rather than correct answers, the same missing sense of what is allowed to break in this business and what is not. A model that can't spot a subtly wrong assumption won't spot it in another model's code either – it nods it through with the same composure. Second, and this weighs more: an AI review manufactures false confidence. A second green tick feels like more certainty, but it's just the same bet placed twice. And crucially, it transfers no accountability. When the system falls over at three in the morning, no one can hide behind "but the review AI agreed." At the end of it stands a human who owns the merge – and that is exactly the part no automation can take away.
Calibrate Rigour to Blast Radius
Now the honest other side, before the lesson gets stretched too far. Not all code deserves the same rigour – and reviewing everything with maximum paranoia is its own form of waste. A throwaway script that reformats a CSV once needs no triple security review. An internal dashboard five people see is not the payment flow.
The right variable isn't "how much code" but blast radius: what happens in the worst case if this code is wrong? That's what determines how closely you look.
- How big is the damage if it breaks? Payment logic, authentication, data migrations, anything touching customer data or money – maximum rigour, line by line. An internal helper tool – lighter review.
- How reversible is it? A feature behind a flag you can flip back in seconds tolerates more speed than a migration that rewrites data irreversibly.
- How far does it reach? An isolated function with no dependencies is harmless. A change to a central component used in twenty places is not.
- Does it live long? Code that stays and grows earns the care you spare throwaway code.
High blast radius means: read slowly, doubt every assumption, make the submitter explain every line. Low blast radius means: waving it through is fine. The skill isn't to review everything to the hilt – it's to steer attention to where a mistake actually hurts. And for that to stay possible at all, one plain hygiene rule applies: keep pull requests small. A human can read 200 lines with genuine scepticism. At 2,000 they slip into wave-through mode – which, as we've seen, isn't review at all.
Conclusion
For decades, writing code was the skill an engineer earned and got paid for. That skill hasn't become worthless, but it's no longer scarce. What's scarce now is the thing long treated as a box-ticking exercise: reading someone else's code quickly, sceptically, rigorously – and standing behind it.
For teams, that means rebuilding a discipline many have neglected for years. Review has to become a first-class, visibly valued activity, not unpaid overhead squeezed between the real tasks. From here on you hire and develop not only people who write brilliantly, but people who read sharply. The experienced engineer's leverage is no longer how fast they type, but how well their judgement and taste filter a firehose of generated code.
This is exactly where we set the bar at NH Labs. We use AI in engineering because it's fast and good – but we don't treat review as an optional last step. We treat it as the core discipline every line has to pass through. A human understands every line submitted, can explain it, and owns the merge. That's why our clients can trust the output: not because an AI wrote it, but because a human read it.