Originally published on tamiz.pro.
Five years ago, a code review meant reading someone else's diff, spotting a bug or a bad abstraction, and leaving a comment. Today, a code review often means reading a diff that no human wrote — or at least, no human wrote alone.
AI pair programmers, autonomous agents, and codex-tier models have quietly collapsed the gap between design and implementation. The result isn't just faster shipping; it's a fundamentally different artifact arriving at your pull_request stage. And the industry hasn't caught up to what that actually means.
The Inversion That Nobody Named
What changed isn't velocity — we've been getting faster for decades. What changed is ownership.
Before agents, the person who wrote the code was the person who understood the code. That relationship was the foundation of every review process, every on-call rotation, every postmortem. When you wrote it, you knew why. Even when you wrote it badly, you knew how badly.
Now the author and the auditor are different kinds of minds. One is a language model optimizing for coherence and completeness against a prompt. The other is a human engineer checking whether that output is actually correct — not just plausible.
We didn't just add a tool to the workflow. We inverted the center of gravity. The human moved from writer to auditor, and most teams treated it like a lightweight role change. It isn't.
What We Actually Ship Now
Let me be specific about what's different.
The surface-level diff is smaller, but the reasoning surface is larger. A human-written feature typically documents its decisions in the code, the PR description, and maybe a design doc. An AI-generated feature documents its decisions nowhere — unless you count the implicit reasoning traces from a model that may have considered (and rejected) three alternative implementations before producing the one you see.
Bugs don't look different, but their origin story does. An off-by-one error from a junior engineer reflects a gap in understanding. An off-by-one error from an agent reflects a gap in your verification process. The symptom is identical. The remediation is not.
Architectural drift happens faster and leaves fewer traces. Agents excel at local correctness — making the function work, making the test pass. They are dramatically worse at global consistency unless explicitly prompted, and even then, they optimize for the prompt, not the system. I've seen PRs where every change was locally sound and the aggregate was incoherent.
The feedback loop compressed, but the learning loop atrophied. When writing code is cheap, you stop doing the mental work that makes writing code valuable. You stop feeling the shape of the problem space. You stop developing the intuition that catches edge cases before they reach the diff.
What We Got Right
For fairness, the gains are real and substantial.
- Boilerplate evaporated. Auth middleware, CRUD endpoints, serialization layers, test fixtures — the stuff that used to consume 40% of a sprint is now ambient. Engineers who used to write it are free to focus on actual domain complexity.
- Onboarding velocity improved for competent engineers. A new hire can now read AI-generated code and understand it faster because the models tend toward conventional patterns. The code is often more idiomatic than what a struggling mid-level would produce.
- Test coverage expanded. Agents write tests at rates humans don't match, and the tests are usually better than what most engineers write under deadline pressure. This is one of the highest-ROI shifts I've observed.
- Documentation caught up to code. AI fills the gap between what the code does and what the code says it does. That gap was always the biggest source of maintenance debt.
These aren't small things. They are structural improvements. But they're also the easy part.
What We Still Get Wrong
Here's the part most teams haven't reckoned with yet.
1. We Treat AI Output as Draft, Not Evidence
The dominant mental model is: AI writes code, human reviews it. This is backwards.
A draft implies the author expects it to be incomplete. An auditor doesn't complete drafts — they verify claims. The output of an AI agent is a claim about correctness, performance, and security. Your job isn't to fix it; it's to stress the claim.
Most reviewers don't do this. They read for syntax errors, obvious bugs, and style issues — the same checks they always performed. What they're missing is the verification work: tracing the agent's assumptions, checking that the prompt constraints were fully honored, validating that the solution generalizes beyond the examples provided.
This is a harder cognitive task than reading code. Most engineers haven't been trained for it.
2. We Don't Audit the Prompt, Only the Output
The prompt is the spec. The code is the implementation. We review the implementation obsessively and ignore the spec.
When an agent produces wrong output, the root cause is almost never in the code the agent generated. It's in the ambiguity of the request, the missing constraints, the unstated assumptions about the runtime environment or data characteristics. Fixing the code without fixing the prompt is cosmetic — the next feature will fail for the same reason.
Yet I see almost no team tracking prompt quality the way they track code quality. No prompt review rituals. No prompt versioning. No metrics on prompt-to-output fidelity.
3. We Lost the Apprenticeship Path
This is the slowest-moving cost and arguably the deepest.
Junior engineers learned architecture by writing it badly and having seniors correct them. They learned trade-offs by feeling the weight of their own decisions. They learned to read systems by building pieces of them.
Agents short-circuit all of that. A junior who ships 3× the features via AI in their first year has more output but less pattern density — fewer repeated encounters with the same classes of problems that build genuine expertise.
We're going to feel this in five years when the mid-level cohort that grew up with agents hits the roles that require deep systems judgment. They'll have impressive portfolios and thin intuition.
4. We Confuse Verification with Validation
This is the single most important distinction most teams miss.
Verification: Does the code do what the prompt said? (Checkable by reading.)
Validation: Does the code do what the business actually needs? (Requires understanding the domain.)
Agents are excellent at verification — they follow instructions literally, often too literally. They are terrible at validation — they have no model of your stakeholders, your constraints, your unwritten conventions.
Most code reviews today conflate the two. A reviewer sees correct-looking code and signs off. The code is verified. It is not validated. The feature ships. It solves the wrong problem.
5. We Don't Track Agent Attribution
When a bug lands in production, we need to know: did the human design this, did the agent design this, or did they co-design it?
The answer determines the postmortem. A human-made mistake points to training gaps or process gaps. An agent-made mistake points to specification gaps or tooling gaps. A co-designed mistake points to both — and that's the most dangerous category because both parties share blame and neither takes ownership.
Yet almost no team tracks this. PRs don't say who wrote what. Postmortems don't ask. The signal is lost.
What an Agent Audit Actually Looks Like
If you're going to take this seriously, here's a practical framework that's working in a few organizations I consult with:
The three-pass review. Every AI-assisted PR gets three distinct passes, each with a different goal:
- Correctness pass: Does the code work? Run it. Break it. Check the tests.
- Intent pass: Does the code match the prompt? Read the prompt. Read the code. Trace every constraint.
- System pass: Does the code fit the system? Check for architectural consistency, security implications, performance characteristics, and operational concerns that no single PR description would capture.
Most engineers do one pass that tries to do all three. It doesn't work well for any of them.
Prompt documentation as a first-class artifact. Every PR that includes AI-generated code should link to or include the prompt. Not the raw prompt — a sanitized version that captures the intent, constraints, and context the agent was given. This makes the spec reviewable, versionable, and traceable.
Attribution tags. A lightweight convention: [AI: generated], [AI: assisted], [Human: authored]. Not for blame — for signal. When you see a pattern of AI: generated code in a module, you know where to invest review attention and where to invest training.
The 30-minute rule. If a PR was primarily AI-generated and exceeds 30 minutes of focused review, the team flags it for a follow-up session. The assumption: if you can't verify it quickly, either the change is too large, the AI misunderstood something fundamental, or you don't understand the system well enough to audit it. Any of those is a problem worth escalating.
The Hard Truth
AI didn't make code review easier. It made code review different. The old skills — pattern recognition, abstraction sense, bug intuition — still matter. But they're necessary conditions, not sufficient ones.
The new skill is specification literacy: the ability to read a prompt and understand what it asserts, what it leaves open, and what it implicitly assumes. This is a skill most engineers haven't practiced because prompts were never formal enough to practice on.
Until we treat prompts as specs, code as claims, and reviewers as auditors — rather than co-writers — we'll keep shipping plausible-looking software that doesn't actually solve the right problems.
The tool changed. The responsibility didn't. But we're still reviewing like nothing happened.
Frequently Asked Questions
Q: Should I stop using AI code generators if they make code review harder?
No. The productivity gains are real and structural, not ephemeral. The right move is to upgrade your review process, not abandon the tool. Teams that stop using AI will lose ground to teams that learn to audit it effectively.
Q: How do I know if my team is ready for agent-level code review?
If your current review process relies heavily on senior engineers reading every line, you're already past the point of sustainability — AI just accelerated the pressure. Start by implementing attribution tags and the three-pass review on a single team. Measure review time, bug escape rate, and post-merge rework before and after. If review time drops and escape rate stays flat or improves, you're on the right path.
Q: What's the single highest-impact practice to adopt this week?
Start requiring that every AI-assisted PR includes the prompt (or a summary of it) in the PR description. This single practice surfaces 80% of the bugs I've seen in AI-generated code — they're specification bugs, not implementation bugs, and they're invisible without the spec to compare against.
Top comments (0)