Reviewing every change an agent generates is becoming impossible.
Long-running agents produce larger and more frequent pull requests, and any tool, workflow, or person can now open a PR with almost no effort. This has greatly increased what engineering teams can do, but it also brings new challenges to managing code changes.
Human attention is now a scarce resource in the agentic SDLC. Existing workflows often squander it on low-value tasks.
Before developers can write or review meaningful code, three hidden "attention taxes" stand between them and high-value work:
- The Triage Tax: Deciding what deserves attention first.
- The Comprehension Tax: Rebuilding context from fragmented files.
- The Vigilance Tax: Ensuring code stays safe after the merge.
The Triage Tax: Someone has to decide what deserves human attention
A pull request used to be a careful investment. Teams scoped and planned the work, and then someone spent hours or days encoding the change. That made PRs comparatively rare. Today, roughly 2-in-3 AI-written PRs are never merged. They just sit in your queue taking up space and attention until they are closed.
Most pull request queues are sorted by when PRs arrived, which repository they are in, who wrote them, and their review status. These details help teams keep track, but they do not show which changes need to be prioritized.
As more changes are proposed, reviewers have started acting like human routers. They scan titles, piece together context, find the right people, decide what is urgent, and figure out if a change is even ready for review. This often creates chaos. Important work can get stuck behind less valuable changes, reviewers work on things they do not need to, and teams waste time sorting the queue before they can even start reviewing code.
A small fix that unblocks a customer may deserve attention before a large refactor that has been waiting longer for review. A security fix has to ship immediately, but it also demands careful validation. Effort and importance are independent dimensions, and arrival order in your PR queue tracks neither.
No hospital makes its surgeons triage the waiting room. Yet that is exactly what we ask senior engineers to do: burn through their cognitive bandwidth deciding what deserves attention before they can spend it on what does.
Review routing by consequence is becoming part of the engineering system itself. Teams need queues that can distinguish value, urgency, risk, dependencies, readiness, and reviewer fit before a human starts reading the diff.
The Comprehension Tax: Developers have to rebuild context from fragmented files
Once a PR earns a closer look, the reviewer still has to understand it, and most review surfaces make that harder than it should be. They open with files, lines, and comments, leaving the reviewer to build a cognitive map of the change from a file tree.
Repositories are organized around implementation, but reviewers think in user flows. A single user flow can touch a route, a provider, a configuration file, a template, and a test, and the file tree groups none of them together. Every reviewer has to build that understanding of the PR from scratch. Depending on the complexity of the PR, reviewers can lose half an hour or more before they understand the code well enough to review it.
Traditional code review assumes a reviewer can easily build that cognitive map, and the assumption breaks down when agents make large changes across services, data models, and infrastructure. The code may be correct line by line, but the change as a whole can still be hard to understand.
For example, a diff shows that a function changed, but it does not explain whether the change crosses an authorization boundary, starts a migration, or breaks an external integration.
Without that explanation, review turns into guesswork, and the organization ships faster while slowly losing its shared understanding of the system.
What a reviewer needs instead is a tl;dr of what the change means. They need a UI that understands reviewers have finite attention and clearly lays out the contracts, domain behavior, integrations, tests, and migrations the change touches. It should give an honest account of how far the change reaches and where it needs deeper scrutiny.
Ideally, the reviewer should need just a minute or two to understand what the change is trying to do and why the files belong together.
Production observability helps teams see how a system is running. As AI-generated changes get bigger and more common, teams will also need code explainability, a way to understand decisions and behavior before they become part of the system.
The Vigilance Tax: Attention has to outlast the merge
A change continues to matter even after it ships. Each PR might look correct in isolation but still increase the entropy of the codebase and make it less secure over time.
Dependencies change, new vulnerabilities show up, data flows shift, and services connect in new ways. An architectural choice that was safe when a change merged might not be safe months later.
Teams increasingly know this and worry about it. They also know that the same AI making developers more productive is making it easier for attackers to find and exploit vulnerabilities. Traditional rule-based security tools are no longer enough to protect codebases from novel attack vectors on their own.
Teams are starting to apply the same scrutiny to changes after they merge as they do before. The review system cannot stop at approval. It has to help teams understand what changed, what assumptions the change introduced, and when those assumptions need to be revisited.
Focusing on what matters
The next era of software development will not just be about how much code organizations can produce. It will be defined by how much change they can handle responsibly.
With code shipping faster than anyone can read or explain, teams are losing the ability to shape their work intentionally. Deciding what deserves attention, what has been validated, and whether the codebase is getting less secure one reasonable change at a time is a tax on every developer, paid daily in output.
What if developers stopped paying it? All that would remain is the part only a human can do: use judgment to build a better and safer codebase.
Soon, they will. A better way to manage change is coming.
