AI Can Write Code Faster Than We Can Review It — And That’s Becoming the Real Bottleneck
For most of software development history, writi...
For further actions, you may consider blocking this person and/or reporting abuse
same blind spot shows up one step later. a team can review 1800 lines of ai code carefully and still break prod because nobody checked the new env var or the migration order. review catches logic bugs, not the deploy step. that gap is just as expensive and way quieter.
That’s a great point. We can spend a lot of time reviewing the code and still miss the things around it, like env changes, migrations, or deployment configuration.
AI can help with those checks too, but someone still needs to understand the full deployment path and make sure all the pieces line up.
A useful Level 1 step for those 27-file PRs is to review the contract before the code.
For API changes, generate
openapi.jsonfrom the base branch and the PR head, then diff that first. If the change aroundDELETE /workspace/:iddoes not match the requirement that only account owners can permanently delete a workspace, there is no point reviewing the 1,800 lines yet. It turns "does this look right?" into a concrete requirement check.That’s a really practical approach. Checking the contract first can save a lot of time, especially when AI-generated PRs touch so many files. It also makes the review more about whether we built the right thing, not just whether the code looks correct.
writing a code never was an issue before. implementing feature - was.
It in general includes many things - tools, integrations, proper architecture, code, tests and of course code review, remember how many times it took us sometimes to approve the PR finally???
now every part of this system improved (including PR reviews) with a help of AI.
the problem now - we have to deal with much bigger cognitive load. mean we now should be X times more actively thinking about the same things.
shiping 1 feature a week before and shipping 10 features now! compare the diff!
Exactly. The interesting part is that AI didn’t just make coding faster — it accelerated almost every step around implementation too.
But shipping 10 features instead of 1 also means we have 10x more changes to understand. The real challenge now may be keeping up with the cognitive load, not the coding speed.
The most important distinction here is that verification can be perfectly correct and still validate the wrong thing. If the requirement is misunderstood, the implementation, tests, and AI review can all agree while the feature remains wrong from a business perspective.
That suggests a useful shift in review: don’t make the AI reviewer the final authority on whether the change is correct. Let it handle mechanical and code-level verification, while the human focuses on intent, invariants, and whether the changed behavior actually matches the product contract.
I’d also track review surface area, not just lines changed. Twenty small isolated changes may be easier to reason about than a 200-line change that crosses authentication, data access, and billing boundaries. As agents get faster, understanding the dependency and blast-radius structure of a change may become more valuable than simply reducing review time.
Yes, exactly. I really like the idea of measuring review surface area instead of just lines changed. A small change that touches auth, billing, and data access can be much harder to reason about than a larger isolated change.
As AI gets better at generating and verifying code, understanding intent and blast radius may become an even bigger part of the developer’s job.
The load-bearing move here is separating review from verification, and I would push it further. They are different jobs and only one of them scales.
Review is a human reading a diff and forming a belief. That is bounded by attention, and agents have already outrun it. Verification is asking whether what the diff does is permitted, and that does not have to be done by reading. It can be done by making whole classes of change unrepresentable.
In payments the pattern that works is narrowing the surface rather than speeding up the reading. Anything that moves money goes through one interface, and that interface gets reviewed as though it were the only code in the repo. A two-thousand-line agent diff that does not touch it gets a much cheaper look than a twenty-line one that does.
One worry about "verified, maintainable value shipped" as the metric: it is not measurable, and unmeasurable metrics lose to measurable ones every time. PRs merged will win. Something like "how much surface must a human read to believe this is safe" is at least countable, and it goes down when you do the right thing.
Exactly. I especially like the distinction between review and verification. If agents are already outrunning human attention, the answer probably isn't making humans read faster—it’s designing systems where dangerous changes have fewer places to hide.
And “how much surface must a human read to believe this is safe” is a much more practical metric than a vague productivity score. That shifts the goal from reviewing more code to making less code require deep human review.
This is a really important point. AI has made code generation much faster, but review hasn’t accelerated at the same rate.
The bottleneck is shifting from “How fast can we write code?” to “How fast can we understand and validate code?” And reviewing AI-generated code properly still requires strong knowledge of architecture, edge cases, security, and the actual business requirements.
AI can increase our output, but without improving the review process, it can just increase the amount of code we need to maintain.
Exactly. The scary part is that AI can make the codebase grow faster than the team’s understanding of it. At some point, more output stops being productivity and starts becoming maintenance debt. I think the next big gains will come from making verification smarter, not just generation faster.