Writing and reviewing code used to be the twin constraints on shipping software. Agents are erasing the first and overloading the second. Code is now plentiful, but judgment about what deserves to merge is not. Better models sharpen what agents write, but they don't make that call.
The people who build and operate software need more than code that works. Each change has to fit the architecture, hold up in production, and stay understandable enough to maintain. Once code enters a shared system, the model that produced it matters less than the quality of the decision to ship it.
AI has scaled code generation far faster than the human attention, context, and accountability needed to absorb it, and that gap is where the pressure now sits.
Better models create more downstream work
Each generation of coding tools has brought real gains at the point of creation. Whether that output survives to shipped software is the question the NBER working paper "Writing Code vs. Shipping Code" set out to answer by tracking more than 100,000 GitHub developers across three generations of AI coding tools. Autocomplete increased coding activity by 40%, interactive agents raised the cumulative gain to 140%, and autonomous agents pushed it to 180%.
The gains narrowed as the work moved toward delivery. The 180% increase in coding activity became a 50% increase in projects and a 30% increase in releases. The researchers describe the pattern as consistent with the weak-link hypothesis. AI and human effort stay complementary across the production chain, so the stages that still run on human effort set the pace.
The farther work moves from the coding model, the more it depends on coordination, context, and human judgment. A commit sits close to the model, while a release depends on the entire delivery system. Someone has to understand the change, integrate it with other work, test it, and approve it for production.
Acceleration in one part of the system creates pressure in the next. Better models generate more plausible code, but they also create more decisions for every process responsible for turning that code into reliable software.
Code can arrive before the decision
For most of software history, implementation paced the flow of change. Teams discussed an idea, established its priority, assigned the work, and then invested engineering time in turning it into code. The cost of implementation encouraged teams to make important decisions before a pull request appeared.
Coding agents compress that sequence. A prompt, a support request, or a production alert can become a proposed change quickly, and code can be created before the organization has established its value, priority, or readiness. As the backlog shifts from ideas and tickets to shippable code, the pull request takes on a larger role.
A PR can represent a change to an authorization boundary, a pricing rule, or a customer promise. Each one creates decisions about correctness, risk, and ownership.
The diff supplies the evidence, but reviewers need more than that: they need a coherent path through the change. Understanding a PR means knowing what it intends, which behavior and systems it touches, and what the team takes on by merging it.
Route each change by consequence
A growing stream of pull requests turns review into an attention-allocation problem.
A formatting update, an authentication-flow change, and a database migration deserve different review paths. Each carries its own urgency, risk, and reviewer effort.
Value, risk, dependencies, readiness, and reviewer fit should shape the queue. Routine changes move through automated validation and a focused human check, while consequential work gets deeper analysis and lands with the right senior engineers, security specialists, or domain owners. Incomplete or low-value changes stay outside the active queue until they earn attention.
This approach protects scarce human attention. It also makes the review queue easier to understand. Teams gain a visible basis for deciding what should move first, what deserves deeper scrutiny, and where a particular person's expertise will create the most value.
The authoring model holds the local context behind its implementation; the organization supplies the broader context that determines value, consequence, and ownership. Once each change has an appropriate path, the next opportunity is to make judgment reusable within that path.
Judgment scales when it becomes reusable
Codified standards give every change a consistent quality bar. An architectural rule, written once, guides every relevant pull request. Test expectations hold across repositories, risk classifications define the evidence a change needs before merge, and feedback from one review sharpens how the next is evaluated.
This is how expert knowledge becomes shared infrastructure. Instead of personally inspecting every generated diff, senior engineers, security specialists, and domain owners shape every incoming change through reusable guidance. Independent verification adds another safeguard.
The authoring agent carries the assumptions that shaped its solution. A separate reviewer can challenge those assumptions, inspect the surrounding codebase, apply organizational standards, and test suspected failure modes. The coding agent can then address the findings and submit the change for another review.
Human attention then starts with the higher-order work of weighing intent, architectural impact, acceptable risk, and the decision to ship.
The durable advantage sits around the model
Organizations will use many coding agents. Developers will pick different models for different tasks, and model leadership will keep changing. The models may change every week, but the organization can preserve the context, standards, and evidence behind its decisions.
Each change inherits the history of the system around it. Teams need codebase knowledge, architectural standards, and the reasoning behind earlier decisions. When that knowledge persists across agents and repositories, each review can build on the last instead of starting from scratch.
Judgment determines the return on AI
The model race will keep producing more capable agents and a larger volume of plausible code. Each gain in code generation shifts more leverage downstream. When several agents write the code, independent verification keeps quality honest. Pull requests arriving faster than teams can review them need to be triaged by consequence, and a codebase absorbing thousands of changes needs oversight that continues after they merge. The systems downstream of the model determine how much of that output becomes reliable software.
At CodeRabbit, we’re working toward a future where each change receives the depth of review it calls for, decisions are backed by evidence, and protection continues after merge. However good the next model is, deciding what ships will still be the hard part.
