Software factories can turn intent into tested code with very little human intervention. Agents pick up queued work, write and test the implementation, respond to findings, and prepare it for release. With enough sandboxes, tools, evaluators, and retries, much of the software production process can run on its own.
Passing checks builds confidence in the behavior they cover, but the harder decision comes next. The code may work as specified, yet still introduce a poor boundary, an unexpected dependency, or more risk than the change is worth.
The review gate is where teams decide not only if the code works, but also whether it should become part of the system.
StrongDM has described a version of the software factory in which people define intent, scenarios, and constraints, then agents generate and validate the implementation without traditional human code review. That approach puts more responsibility on the validation harness.
For teams building long-lived systems, a practical design rule applies. Review depth should follow the cost of error.
Or, as Vercel’s CEO Guillermo Rauch puts it:
That is not to say that every change requires a person to read every line of code. Routine, tightly bounded changes can move through automated checks. But changes affecting security, architecture, customer data, or public interfaces still deserve a visible review gate.
A software-factory workflow in which automation moves changes forward while the depth of human review increases with risk and blast radius.
Coding gains shrink on the way to release
The productivity gains from coding agents are real, but they shrink as work moves toward production.
The 2026 working paper “Writing Code vs. Shipping Code” studied more than 100,000 GitHub developers. It found large gains in coding activity across successive generations of AI tools and smaller gains in projects and completed releases. The authors describe the pattern as a weak-link problem, with human work across review, integration, testing, and release constraining the production chain.
More code enters the process while review, integration, and release continue to demand time and technical judgment.
One proposed answer is deeper automation of the review gate. In “Why Software Factories Fail,” Dex Horthy argues that tests and agent loops reward immediate correctness more readily than long-term maintainability.
A test can confirm within minutes that a defined behavior works. The cost of a poor boundary, unnecessary coupling, or “shotgun surgery” may surface months later, when the next change becomes harder than it should be.
That delayed cost is difficult to express as a fast reward signal. A model can earn a passing result today while making tomorrow’s work more expensive. Long-horizon benchmarks such as SlopCodeBench are beginning to measure how agents perform as requirements arrive across a series of checkpoints.
A green build is useful evidence. Maintainability also depends on how the change shapes future work.
A harness can measure what a team knows how to check
Harness engineering is essential. Agents need constrained tools, reproducible environments, clear stopping conditions, and dependable feedback.
Addy Osmani’s writing on agentic code quality makes a strong case that software quality increasingly depends on the constraints surrounding the agent.
Those constraints belong throughout the delivery process.
- Types and compilers reject invalid states.
- Unit, integration, property, and mutation tests challenge behavior.
- Linters and security scanners catch known classes of failure.
- Sandboxes keep failures contained.
- CI and policy gates enforce hard requirements.
These checks catch measurable failures quickly and reduce the work that reaches a reviewer.
Other questions span a wider part of the system. A test can report whether an assertion passed. Reviewing an authentication change may require understanding how it affects inventory search, chat, a data store, and an API client outside the diff. A linter can enforce an established architectural rule. Deciding whether that rule fits a new product requirement calls for product and engineering context.
Automated checks provide evidence and the review process connects that evidence to the consequences of the change.
Review depth should follow the cost of error
Risk-based review gives teams a specific rule for directing human attention.
As agents produce more changes, reviewers get more leverage by supervising the broader process and taking direct ownership of the decisions where mistakes cost the most.
A narrow dependency update with deterministic coverage may require little human attention. A change to authentication, billing, data retention, or a public API deserves deeper review. The author can be a developer or an agent. The scope and consequences of the change determine the review path.
In his essay on agentic code review, Osmani describes this as moving the human from in the loop to on the loop. People supervise the system, sample its output, and focus their attention on decisions where mistakes would be expensive.
Horthy reaches a similar conclusion from a different direction. Human judgment moves earlier into product review, architecture, and program design. Implementation proceeds in smaller vertical slices that are easier to verify and redirect.
Independent review gives teams a second reading grounded in codebase context and organizational rules. It can surface evidence and identify the work that deserves closer attention, while leaving the decision to ship with the team.
Reviewers need a path from the system view to the code
A conventional summary compresses a change, but compression alone is not enough for review. Reviewers need a way to verify what the summary says.
A reviewer needs two connected views:
- A system view showing the change’s intent, behavior, dependencies, risk, and potential impact.
- A code view showing the relevant findings, files, and exact lines supporting the explanation.
The system view saves reviewers from reconstructing the change from a file tree. Traceability between the two views lets them test every claim against the implementation.
Reviewers can move from an exact code finding to its broader system context—and back—to understand both the evidence and the blast radius.
A large pull request shows what this review model requires in practice. The following Change Stack and Blast Radius walkthrough demonstrates how a reviewer can begin with the scope of a change and move directly to the supporting code.
Watch the Change Stack and Blast Radius walkthrough:
Change Stack and Blast Radius in practice
The demonstration starts with a pull request touching roughly 35 files and 2,000 lines. The raw diff includes a FastAPI backend, authentication, SQLite and Qdrant storage, AI image processing, chat, tests, and review configuration.
Change Stack reorganizes the file-level diff into semantic layers covering API contracts and startup, authentication and persistence, AI processing and search, chat and API validation, and review controls. The layers give the reviewer a reading order based on behavior and dependency instead of alphabetical file paths.
A reviewer can select the database-initialization summary, jump to the code that inserts a default administrator with plaintext credentials and profile data, and inspect the critical finding attached to that range.
Blast Radius extends the view across the affected system. In the demonstration, it shows five directly changed areas and identifies a frontend API client that may be affected even though the pull request leaves that client untouched.
A security finding involving an untrusted username can be followed from the FastAPI entry point through authentication and persistence into SQLite, Qdrant, search, and chat.
The graph gives the reviewer a model of how the change moves through the system. The reviewer can test that model against the code and decide whether the implementation belongs.
Review time can go toward testing the proposed account, challenging assumptions, and deciding whether the design is sound.
A review gate the team can trust
A review gate earns trust when its depth matches the consequences of the change. Routine work can move quickly on automated evidence, while consequential changes need enough context and traceability for reviewers to understand what is at stake and inspect the code behind each claim.
As agents take on more of the implementation, teams need an independent view of the change before it ships. Reviewers should be able to see how far its effects may reach and follow each finding back to code they can inspect.
The team can then make the final call with that evidence rather than spending review time reconstructing the change from scratch.
