The bottleneck moved from typing to trusting
For years, the basic productivity story in software was easy to follow: if people could write code faster, they could ship faster too. That made sense when the slow part of the job was getting ideas out of your head and into the editor. A developer typed. A reviewer skimmed. A merge happened. The pace was limited by fingers and patience as well as maybe the occasional typo that turned a semicolon into a small personal crisis (believe it or not).
That story feels outdated now. Code can be produced far faster than teams can absorb it. AI-generated code, copy-pasted patterns, and auto-written boilerplate have changed the shape of the work. On the whole, a person can create a full pull request before another teammate has finished reading the title of the last one. The backlog grows, not because people forgot how to write code, but because the team can now create more change than it can realistically inspect with care.
Faster code creation only helps when the team can decide, with confidence, what deserves to ship.
That sentence sounds simple because the problem is simple in theory and messy in practice. The limiting factor’s moved downstream. Writing a change is no longer the hard part. Accepting it is. A developer might generate a patch in minutes, but the team still has to answer basic questions before merge: Does this do what it claims? What happens when input looks a little weird? Does it fit the rest of the codebase, or does it work only in the neat little world the generator imagined? Those are review questions, and they take time.
The trouble gets sharper when code arrives faster than the person who wrote or generated it can explain it. If a teammate can’t describe why a change exists, how it works, and what trade-offs it makes, the review burden spreads. Someone else has to trace the logic, inspect the edge cases, and guess at intent. That’s not a typing problem anymore. It’s a trust problem.
That distinction matters because fast production can create a misleading sense of progress. A stack of pull requests looks active. Commits are landing. Everyone seems busy. Yet the ship button stays frustratingly out of reach while reviewers work through the consequences of each change. A small feature that took ten minutes to generate might need twenty minutes of reading and another ten minutes of testing as well as a careful back-and-forth before anyone feels comfortable merging it (for better or worse). Multiply that by a few engineers, and the productivity bottleneck becomes obvious pretty quickly.
Moving on, the same pattern shows up with AI-generated code in particular. It can be useful, and it often is, but it also tends to produce output that looks tidy before it’s fully understood. That’s a sneaky little trap. Clean syntax can hide fuzzy reasoning, and m. On a Friday.
So the practical question is no longer how to make typing easier. It’s how to make acceptance safer and faster without pretending every generated change deserves automatic trust. That usually means tighter code review habits, better test coverage, and clearer ownership for each change that heads toward production. If the next section sounds a little more procedural, that’s because the fix lives in process, not in wishful thinking.
Why review is slower than generation
the clock starts somewhere else, once a team can produce a pull request in minutes. Typing is no longer the slow step. Understanding is. In software development, that shift matters because a generated change can arrive looking neat, complete, and a little smug, while still leaving a long trail of questions behind it.
On top of that, a hand-written change usually comes with more intent baked in. Even if the code’s messy, the author often knows why the branch exists, which edge case they were guarding against, and what tradeoff they accepted on purpose. A generated change can be the opposite. The syntax may be clean. The variable names may even be decent. But the reasoning behind the diff is often thin, and that missing context gets paid for during pull request review.
Reviewers have to do more than skim for obvious mistakes. They need to check logic, edge cases, and whether the new code fits the rest of the codebase without starting a small fire three modules away. Does the function behave the same way under retries? What happens with null data, duplicate events, odd ordering, stale cache entries, or that ancient corner of the app nobody has touched since the last migration? Simple as that. A fast first draft rarely answers those questions on its own. It usually creates them.
A fast draft is cheap; a clear explanation is the expensive part.
That’s why review feels slower than generation. The code may have been produced in seconds, but the team still has to build confidence in it. Reviewers aren’t just approving text on a screen. They’re checking whether the change will survive real traffic, real users, and real maintenance. In practice, that means reading more carefully than they’d for a small, plainly written edit.
Then again, the burden gets heavier when the author can’t explain the change cleanly. At that point, the reviewer stops evaluating the work and starts reconstructing it. They trace call sites. They compare the diff with old bugs. They read tests to infer intent. They ask whether the author meant to handle a case or simply missed it. None of that is glamorous, and none of it makes developer productivity feel especially speedy. It does, yet keep the team from approving code they don’t actually understand.
Because of this, that extra work doesn’t stay inside the pull request either. Maintainers inherit it when they merge and support the code later. M. If the original change was never well understood, the incident becomes a scavenger hunt through assumptions, warnings, and half-finished comments. The team pays for the shortcut twice: once in review, once in recovery.
Google’s reviewer speed guidance puts a practical point on it: reviews should happen promptly, because waiting around for feedback slows the whole chain of work. That advice sounds simple until you multiply it across a busy team. The queue grows, if generation gets faster but review does not. People spend more time waiting for judgment than creating the next change. The bottleneck has moved, and it is sitting in the review column.
The same pressure shows up in the DORA 2025 report and the 2025 year in review, where delivery performance matters more than the raw speed of drafting code. A large batch of fast, unclear changes doesn’t help much if the team can’t approve them with confidence. More output at the keyboard can still mean less usable progress in the system.
After that, that is the part teams sometimes miss when they talk about AI and speed. The first draft got cheaper, sure. The expensive part moved downstream. At first glance, reviewers now spend their time checking whether the code makes sense in context, whether the edge cases were handled, and whether the person who opened the PR can actually explain what changed without reading the diff out loud. Everyone else has to do that work for them, if they can’t.
And that’s how review becomes the pace-setting step. Not because humans forgot how to type. Because a change is only as fast as the team can trust it.
How teams restore confidence before merge
Once a change comes from a model, a prompt, or a quick copy-paste session, the temptation is to treat it like free progress. It isn’t. The code still lands in a repo with a person’s name on it, and that person needs to be able to say why the change exists, what it’s supposed to do, and where it might break. The reviewer gets stuck doing archaeology before the actual review even begins, if they can’t give that answer in plain English.
That’s why the safest teams don’t give generated code special treatment in the flattering sense. On the whole, they give it the same treatment they’d give any other change: one owner, one reason for being there, and a clear purpose that somebody is willing to defend. A vague “the model wrote it” explanation does a lot of damage here. M. It leaves the rest of the team guessing which parts were intentional, which parts were copied from a pattern that barely fit, and which parts were patched at 11:47 p.m. Because the first version failed in staging (and that’s no small thing). Review slows down fast when the author can’t explain the shape of the change.
If the person who sent the patch can’t explain it, the merge request has already become a team problem.
That’s where review habits need a small reset. Engineering teams often act as if more generated code should mean more output, as though volume itself is the prize. In practice, bigger diffs usually mean more surface area, more context switching, and more chances for a reviewer to miss the one line that matters. Google’s guidance on small CLs is useful here because it cuts through the buzz: smaller changes are easier to understand, easier to test, and easier to push back on when the behavior looks odd. A tight change forces a tighter explanation. That’s a good thing, even if it bruises a few egos.
The same logic applies to Google Cloud’s discussion of who reviews AI-written code. “ The person merging the code still needs enough context to judge whether the change belongs in the product, not just whether it compiles. If the author can’t walk through the intended behavior, the fallback becomes guesswork. Guesswork is a rotten way to run a codebase.
Stronger test coverage helps here because it lowers the amount of mental simulation every reviewer has to do. A reviewer shouldn’t need to hold the entire function in their head and mentally step through every branch like they’re trying to solve a puzzle in a dim room. Billing, formatting, caching, or anything else that can fail in a noisy way, the test suite should do some of that heavy lifting, if the code touches auth. Good tests make review less of a trust exercise and more of a verification exercise. For the most part. They also make bad explanations easier to spot. The gap shows up pretty quickly, when the change “looks fine” but the tests are paper-thin.
That’s where code quality and explainability meet. A change that can be described cleanly usually has a cleaner shape in the repo. On the whole, a change that can’t be described cleanly often hides a mess of special cases, copied code, or broad edits that were never really understood. The DORA team’s AI capabilities model report points in the same direction: teams tend to do better when AI use sits inside solid delivery practices instead of replacing them. That doesn’t mean every generated line needs ceremonial treatment. It means the guardrails matter more when the code came from somewhere fast.
Another thing: in day-to-day review, that can look plain and almost dull, which is exactly the point. The author should be able to answer a few simple questions without waffling. What changed? Why now? What test would fail if this regressed? What part of the codebase does this touch that might surprise another engineer next week? If the answers are fuzzy, the team should pause. Not forever. Just long enough to get the rationale on the table and tighten the patch before anyone starts nodding along out of habit.
That pause saves time later. It keeps review from becoming a cleanup pass for unclear intent, and it prevents one person’s speed from turning into three other people’s after-hours headache. The result is a merge queue that moves on judgment instead of optimism, which is a much healthier way to ship.
Conclusion: speed up the right step
At the same time, the teams moving carefully aren’t anti-automation. They’re simply refusing to confuse faster drafting with faster delivery. That distinction matters more than it first appears.
That’s the real shift here. When code gets easier to produce, the team has to get better at deciding what deserves to ship. Otherwise, you end up with a pile of quick changes that all need slow reading, slow testing, and slow cleanup. The work has not disappeared, and no surprise there. It has simply moved. Reviewers, maintainers, and incident responders inherit the bill if the original author can’t explain the logic or defend the edge cases.
Speed in drafting is useful. Speed in shipping only shows up when the team can trust what it approves.
Review standards are part of that trust. So is test coverage, and is ownership. If a change has a clear owner, a clear purpose, and tests that cover the parts most likely to break, review gets much easier. Not easy. Just easier in the way that matters. Reviewers can spend their time checking judgment instead of reverse-engineering intent. That is a better use of everyone’s attention, and it tends to keep software delivery from turning into a long series of polite, expensive guessing games.
There’s also a useful cultural wrinkle here: teams need permission to slow down the merge, even when the draft came together quickly. That may feel backward at first. A developer who produced something in five minutes might expect five-minute approval. In practice, the opposite is often healthier. Fast generation calls for sharper scrutiny, because the cost of a missed assumption doesn’t stay local. It lands on the rest of the team, and later on customers.
That’s why None of that means code generation is a bad idea. It means the surrounding sequence has to grow up a bit. AI can help with boilerplate and routine refactors as well as first-pass implementation. Fine. Use it, and not ideal. Let it save time where time is being wasted. Then spend some of that saved time on the parts that actually protect the release: explaining the change, testing the weird cases, and making sure someone is accountable when it reaches production.
That balance is the practical takeaway. Teams have to be more selective about what they accept, if code is easier to write. Speed becomes a tax instead of a gain, if review gets weaker. If review gets stronger, the same automation that created extra output can support real progress.
So the goal is pretty simple: improve for trusted delivery, not just faster output. In a world where code appears quickly, the best teams will be the ones that ship with clear ownership, solid tests, and enough skepticism to ask, “Should this go out?” before they ask, “How fast can we make it?”
