The job description didn't change. It’s the job that did.
A senior engineer who spent a decade learning how to design systems can now spend half a morning deciding which AI-assisted pull requests are safe to merge. The assistant can produce another implementation in seconds. The senior still has to work out if it belongs in the system.
That's the part of AI coding economics we don't talk about enough.
Generation scaled.
Judgment did not follow.
Faros AI's 2025 telemetry across more than 10,000 developers and 1,255 teams found that high-AI-adoption teams merged 98% more pull requests and completed 21% more tasks. At the same time, PR review time increased 91% and average PR size increased 154%. At organization level, Faros found no corresponding improvement across overall throughput, DORA metrics or quality KPIs.
That's not evidence that AI coding doesn't work.
It's evidence that when one stage of a system accelerates, the constraint can simply move somewhere else.
And increasingly, it moves to the humans who know enough to say no.
Generation got cheap
Writing code was never the only expensive part of software engineering.
The harder part is deciding what belongs in a system that already exists.
That requires context:
- what already solves the problem
- which dependency isn't obvious from the current file
- why an earlier team made a particular trade-off
- what looks local but has consequences three services away
- which implementation is technically valid but wrong for this architecture
AI dramatically reduces the friction of producing a plausible change.
It doesn't automatically reduce the effort required to establish that the change is the right one.
Faros's data makes the shift visible. High-AI-adoption teams in its 2025 dataset were producing substantially more pull requests, but review time increased at the same time. Faros describes human approval as a new bottleneck in the software-development lifecycle. The research report includes the underlying metrics and methodology.
That's an important distinction.
A company can improve generation throughput without improving delivery throughput.
If everything downstream remains fixed, more code simply arrives at the queue faster.
The queue is where the cost becomes visible
Think of an engineering workflow as a pipeline.
Before widespread AI coding:
design → implementation → review → test → deploy
Implementation consumed a meaningful share of the time.
Now an agent may dramatically compress that stage:
design → IMPLEMENTATION → review → test → deploy
The rest of the pipeline hasn't magically compressed with it.
Faros calls this pattern an AI productivity paradox. Its 2025 analysis found 98% more merged PRs on high-adoption teams alongside 91% longer review times, while aggregate organizational delivery metrics showed no significant improvement.
The company hasn't necessarily become slower.
It may have created more work-in-progress upstream than its existing verification capacity can absorb.
And unlike token usage, review capacity isn't elastic.
You can't API-call another five years of architectural experience.
When verification runs out, it doesn't announce itself
Nobody schedules a meeting and says:
“From Monday, we're going to understand less of the code we merge.”
The standard shifts quietly.
The queue grows.
A change looks reasonable.
Tests pass.
The diff is larger than anyone would like, but another eight PRs are waiting.
So review moves from:
“I traced what this touches and I understand why it belongs here.”
toward:
“Nothing obvious looks wrong.”
Faros's 2026 report, based on two years of telemetry from 22,000 developers across 4,000 teams, suggests the pressure did not ease as teams got used to the tools. Comparing the periods of lowest and highest AI adoption within each organization, median time in pull-request review was up 441.5%, bugs per developer were up 54%, and pull requests merged without any review, human or agentic, were up 31.3%.
Those are observational measurements, not proof that AI directly caused every change.
But they describe a failure mode engineering leaders should recognize:
when verification capacity saturates, the work doesn't necessarily stop entering production.
The debt leaves the review queue.
It moves into the codebase.
When verification runs out, it doesn't announce itself.
The person reviewing the code is often also the missing context
Why can't we solve this by simply adding more reviewers?
Sometimes we can.
Generic bugs, formatting, obvious security patterns and mechanical checks are excellent candidates for automation or wider review distribution.
But some reviews repeatedly route toward senior engineers for a different reason.
The reviewer isn't only checking code quality.
They're supplying organizational memory.
They know:
“We tried that abstraction two years ago.”
“This service looks independent, but settlement assumes that ordering.”
“You can't move this call without breaking the fallback path.”
“There's already an implementation in the other repository.”
“The reason this ugly piece exists is incident 481.”
That's not generic programming knowledge.
It's knowledge of this system.
Which means the senior engineer is simultaneously:
- reviewer
- architecture historian
- dependency map
- duplicate detector
- incident memory
- escalation endpoint
You can hire another competent engineer.
You can't instantly give them the same organizational context.
Confident wrong answers scale faster than corrections
There's another reason the senior becomes important as AI usage grows.
AI can produce explanations as easily as implementations.
That's useful when the explanation is grounded.
It's dangerous when nobody knows enough to challenge it.
Anthropic tested this from a learning perspective in a randomized controlled study published in January 2026. Developers learning an unfamiliar asynchronous programming library with AI assistance scored 50% on a later comprehension quiz, compared with 67% for developers who worked without AI assistance. The result wasn't uniform across all AI use: participants who asked conceptual questions and engaged with explanations retained more than those who primarily delegated the work. Anthropic publishes the study and methodology here.
The interesting failure mode isn't:
AI wrote bad code.
It's:
AI did enough of the reasoning that the person shipping the result built a weaker mental model of what happened.
That matters during review.
An AI assistant working on a system with an available expert has a correction mechanism.
The assistant says:
“This queue exists to reduce latency.”
And the senior says:
“No. It exists because the synchronous version caused ordering failures.”
The hallucinated rationale dies.
Now remove the senior.
The same explanation can become the best answer anyone has.
A fluent answer starts filling the gap where organizational knowledge used to be.
That's how concentrated knowledge changes from a productivity problem into a verification problem.
The most dangerous modules aren't necessarily the oldest ones
We tend to associate tribal knowledge with legacy systems.
A billing platform from 2014.
A Java service nobody wants to touch.
A home-grown integration that survived four reorganizations.
AI changes that assumption.
A new module can accumulate weakly distributed understanding quickly if:
- an agent generates much of it
- one engineer directs the work
- another engineer gives a shallow review
- nobody else builds a full mental model
The code may be three weeks old.
Its effective bus factor can still be one.
That is one reason raw contribution counts aren't enough to measure knowledge distribution. Research into software bus factor has found that engineering knowledge also flows through code review and team communication, not just authorship history. A 2022 study based on 269 engineer responses proposed a multimodal model combining version-control, code-review and communication signals.
More people touching code doesn't automatically mean more people understand it.
More contributors ≠ more shared understanding
A repository can have:
20 contributors
and still have:
1 person who can explain why the important parts work the way they do.
The reason teams don't notice is that AI feels fast
This is where the METR result becomes useful.
In its 2025 randomized study, 16 experienced maintainers worked on 246 real issues in mature open-source repositories they already knew well. When allowed to use AI tools, they took 19% longer on average. Before the study they expected AI to make them 24% faster, and afterward they still believed it had made them roughly 20% faster. METR publishes the complete study, sample and limitations here.
The narrow sample matters.
It doesn't establish that AI makes developers slower in general, and METR explicitly warns against that interpretation.
What it gives us is much more relevant here: developers can be wrong about their own AI-driven productivity. AI changes the subjective experience of work. Waiting for yourself to type 80 lines feels slow. Watching an agent produce them in ten seconds feels fast.
The review, correction, rediscovery and coordination costs happen later and are spread across different people.
That makes them psychologically easier to miss.
“Just automate more of the review” only solves part of the problem
We absolutely should automate more review.
Static analysis.
Tests.
Security checks.
Linting.
Common defect detection.
Policy enforcement.
These tools raise the floor and keep humans from spending scarce review time on mechanical problems.
But no generic reviewer knows automatically that:
the company already solved this problem in another repository
or:
the current implementation looks inefficient because of a customer-specific constraint
or:
the proposed change reintroduces an architecture the team deliberately abandoned
Those questions require organization-specific context.
You can give that context to an AI reviewer.
But then you've moved the same problem one layer back:
where does the reviewer get reliable knowledge of the system?
The answer can't simply be “whatever fits in the prompt.”
Two kinds of context, two different fixes
Look again at what the senior supplied in those reviews. Some of it is structure: where the existing implementation lives, what calls this function, which service owns the event, which files a change touches. That knowledge is in the code. Anyone with the right tooling can retrieve it, and nobody should need ten years of experience to do so.
The rest is rationale: why the abstraction was rejected two years ago, why the ugly piece exists (incident 481), why settlement depends on that ordering. None of that is in the code, and no index will find it. It is retrievable only if someone wrote it down.
That second category has a process fix, not a tooling fix. Every time a senior reviewer supplies a "why" in a review comment, the team needs a place where it lands for the next reader, human or AI: an architecture decision record, a decision log in the repository, a comment next to the code that links to the incident. Writing those used to lose out to delivery pressure because it was slow. It is not slow any more. The same assistant that produced the change can draft the decision record from the review thread, with the senior correcting instead of writing. Teams that do this turn every review into a deposit into shared context. Teams that do not keep paying the same senior to answer the same question.
The scalable part is retrieval, not judgment
A lot of senior-engineer interruption isn't senior-level work.
Questions such as:
- Where is this implemented?
- What calls this?
- Is there an equivalent in another repository?
- Which service owns this event?
- Where is this configuration used?
- Which files are relevant to this change?
don't inherently require ten years of experience.
They require access to the right codebase context.
Today, those questions often land on seniors because the senior can answer them faster than another engineer can reconstruct the system.
That's the layer Tentaro targets.
Tentaro indexes private repositories and makes grounded code context available to engineers and compatible AI assistants through MCP. Its product boundary deliberately stops short of code generation: the value is supplying the organizational context around code, with answers grounded back in source.
That changes the routing pattern.
Not:
AI generates → senior reconstructs everything → senior approves
but:
AI generates → system-specific context is retrievable → senior spends attention on judgment
The senior doesn't disappear.
Their scarce time gets used for questions that genuinely need them.
Questions to ask before adding another coding agent
Before increasing seats, agent concurrency or autonomous workloads, look at what happened to the existing verification layer.
1. Did PR volume grow faster than review capacity?
If yes, more generation may simply deepen the queue.
2. Which reviewers receive the most AI-assisted changes?
Don't average across the team.
Find the humans at the constraint.
3. What percentage of their review time is actually retrieval?
Sample ten reviews.
How much time was spent deciding versus finding context that could have been retrieved?
4. How often can authors explain the generated change without reopening the AI session?
That's a surprisingly useful comprehension test.
If the author needs the agent to reconstruct its own work before they can discuss it, the team may be merging output faster than ownership is being created.
IS YOUR SENIOR REVIEW QUEUE A CONTEXT PROBLEM?
Check what your senior reviewers did last week:
- explained where logic lives
- pointed developers to another repository
- identified existing implementations
- reconstructed dependencies
- explained historical architecture
- corrected an AI explanation of the system
- reviewed large AI-assisted diffs
- answered questions that could be resolved from code
- delayed higher-level design work because review was waiting
If most boxes are checked, you don't have only a review-capacity problem.
You also have a context-distribution problem.
Senior review should be a scarce resource
The most expensive reviewer shouldn't spend their day telling people which file to open.
Their value is in judgment that the repository alone can't give you.
Questions such as:
- Is this trade-off worth making?
- Does this fit where the product is going?
- Are we accepting the right operational risk?
- Is the obvious solution wrong because of something the team learned before?
- Should this abstraction exist at all?
Those are senior questions.
“Where is the implementation?” isn't.
The more AI scales code generation, the more important that distinction becomes.
You don't need to eliminate human review.
You need to stop consuming senior review capacity on work that isn't actually judgment.
AI didn't remove the bottleneck. It revealed it.
For years, implementation limited how much engineering work a team could put into motion.
AI is weakening that constraint.
That's valuable.
But software delivery is a system.
When implementation becomes cheaper, another scarce resource becomes visible.
In many teams, that resource is verified organizational understanding:
- Faros's telemetry gives us one view of the shift: high AI adoption correlates with much higher output and much longer review cycles.
- Anthropic's learning experiment shows that task completion and retained understanding don't always move together.
- METR shows that the people doing AI-assisted work can misjudge its effect on their own speed.
Put those together and a more useful question emerges.
Not:
How much more code can our agents generate?
But:
How much more change can our organization understand, verify and safely absorb?
That's the capacity worth scaling next.
What are your seniors actually reviewing?
Take ten AI-assisted pull requests from the last two weeks.
For every senior-review comment, classify it:
MECHANICAL → Could a tool catch it?
RETRIEVAL → Did the reviewer supply information already present somewhere in the codebase?
JUDGMENT → Did the reviewer make a decision that required experience, historical intent or trade-offs?
If retrieval is consuming a meaningful share, that's a fixable bottleneck.
Tentaro is built for that middle layer: making private code context queryable to engineers and compatible AI tools so senior attention stays available for the work that actually requires judgment.
Test one review-heavy repository
See how Tentaro supplies code context through MCP, keep the coding tools, and review process you already have.
