# The Outer Loop Needs a Context Engine


URL: https://getunblocked.com/blog/the-outer-loop-needs-a-context-engine/
Published: 2026-07-14T09:00:00Z
Author: Brandon Waselnuk
Categories: Engineering Insights, AI Agents, Context Engine

AI teams merge 98% more PRs but review time is up 91%. The outer loop is the new bottleneck — here's why more review and bigger context windows don't fix it.

---
At 2am an autonomous agent opens a pull request. By the time the team logs on for standup, three more are waiting behind it. Nobody has written a line by hand. The code got authored while everyone slept, and the review queue is where the team is quietly drowning.

That queue has a name. It is the outer loop: the human work of review, judgment, and direction that wraps around everything an agent produces. The inner loop, writing and iterating on code, got automated fast. The work that surrounds it did not.

## What is the outer loop, and why is it suddenly the bottleneck?

Teams with high AI adoption merged 98% more pull requests, yet PR review time climbed 91% and PR size grew 154%, while organization-level DORA metrics stayed flat, according to Faros AI's read of the 2025 DORA report ([Faros AI](https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025), 2025). The work didn't vanish when the writing got automated. It shifted downstream onto whoever reviews the output.

Addy Osmani frames the split cleanly. Engineers own review and direction while agents run the inner loop, and quality becomes back pressure, because the agent can ship more than you can meaningfully review ([Addy Osmani](https://x.com/addyosmani/status/2074927530482835916)). We agree, and we'd push it one step further. The reason merges rise while stability holds flat is that agents generate output at machine speed, while the judgment step still runs at human speed. Generation got cheap. Verification did not. The bottleneck didn't appear because humans got slower. It appeared because the cheap half of the loop lapped the expensive half.

## Why can't you just review faster?

AI improves quality at the individual and micro level, but is associated with degraded system-level software stability, according to Google Cloud's 2025 State of AI-assisted Software Development report ([Google Cloud](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report), 2025). Speed at one desk does not translate into stability across the system.

Back pressure is Osmani's term for what happens next. When an upstream stage produces faster than a downstream stage can absorb, pressure builds at the slow point. Here the slow point is human judgment, not typing speed. You can read a diff quicker, skim more files, or add another reviewer. None of that changes the ceiling, because the agent ships more than any human can weigh with real care. Faros AI's 2026 analysis, a larger sample a year later, puts a sharper number on the squeeze: median time spent in PR review has climbed roughly 441% as AI output grows ([Faros AI](https://www.faros.ai/blog/ai-code-quality-senior-engineer-review-burden), 2026). Reviewing faster only treats the symptom while the pressure behind it keeps building.

## Why do the instructions you write to steer agents rot?

Frontier models follow instructions well at low density, but accuracy falls as the list grows, dropping to roughly 68% at 500 instructions, according to the IFScale benchmark ([IFScale, arXiv:2507.11538](https://arxiv.org/abs/2507.11538), 2025). The rules you write to steer an agent are not free. They compete with each other.

Matt Pocock named the deeper problem: instruction rot. As he puts it, "code is the environment the agent operates in," so the rules you hand-write capture only what you already knew to write down ([Matt Pocock](https://x.com/mattpocockuk/status/2066612676520779867)). We've observed the same pattern independently and call it [rules-file rot](/blog/rules-file-rot): a `CLAUDE.md` or rules file is a snapshot, and the codebase plus the discussion around it moves faster than the snapshot does. No public benchmark measures that staleness head-on yet, but IFScale shows the mechanism that makes it bite. Pile up instructions to compensate for missing context, and adherence degrades exactly when you need it most.

## Why does more context make it worse, not better?

Across 18 frontier models, performance degrades non-uniformly as input tokens grow, even on simple tasks, according to Chroma Research's "Context Rot" study ([Chroma Research](https://www.trychroma.com/research/context-rot), 2025). A bigger window doesn't buy better reasoning; past a point it just adds noise the model has to wade through.

François Chollet describes the mechanism underneath: compounding complexity fills the context window and degrades the model's reasoning ([François Chollet](https://x.com/fchollet/status/2069483683955028265)). The more you stuff in, the harder it becomes to reason over what matters. Position makes it worse. A 2025 study, "Lost in the Middle: An Emergent Property from Information Retrieval Demands," found accuracy is U-shaped by placement: models handle a fact well at the start or end of a long context and measurably worse when it sits in the middle ([arXiv:2510.10276](https://arxiv.org/abs/2510.10276), 2025). So the instinct to dump the whole repo, every doc, and all of Slack into the prompt backfires. You feed the model noise, and the signal it needs sinks into the middle where it reads it worst.

## Why don't more review or bigger context windows fix the outer loop?

Refactored code fell from roughly 25% of changes to under 10%, while copy-pasted code rose from 8.3% to 12.3%, a churn-and-rot signal, per GitClear's 2025 research ([GitClear](https://www.gitclear.com/ai_assistant_code_quality_2025_research), 2025). Meanwhile 66% of developers report AI answers that are "almost right, but not quite," and only 3.1% highly trust AI accuracy, per Stack Overflow's 2025 survey ([Stack Overflow](https://survey.stackoverflow.co/2025/ai), 2025).

Here is the synthesis. More review fails because the human reviewer is as context-starved as the agent was. The reviewer sees the diff, but not the Slack thread that killed this approach in March, not the reverted PR, not the design doc nobody has opened in a year. Adding reviewers moves the same missing-context problem onto more tired people. A bigger context window fails for the reason we just covered: it feeds more of the noise that degrades reasoning. The "almost right, but not quite" answers are the expensive ones. They pass a fast read and fail in production, which is precisely the failure mode a rushed review cannot catch. (GitClear's window ends December 2024; we treat it as directional, not definitive.)

| Approach | What actually happens |
| Add more reviewers | The same missing-context problem lands on more people, who still can't see the Slack thread, the reverted PR, or the year-old design doc. |
| Enlarge the context window | The model gets more noise, relevant facts sink into the middle, and reasoning degrades. |
| Supply a context engine | Sources get synthesized and reconciled, conflicts get resolved, and the same decision-grade context reaches the agent and the reviewer. |


## What the outer loop actually needs: decision-grade context

Back pressure fails as a purely human practice for one reason: the reviewer lacks the same context the agent lacked. Only 3.1% of developers highly trust AI output today ([Stack Overflow](https://survey.stackoverflow.co/2025/ai), 2025), and trust is a context problem before it is a model problem. You cannot judge what you cannot see.

The fix is architectural rather than a matter of adding headcount. A [context engine](/blog/what-is-a-context-engine) synthesizes and reconciles across code, PRs, discussions, tickets, and docs, resolves the conflicts between them, and enforces permissions, then delivers that same picture to every agent and every reviewer on demand. This is not a search index or a static [knowledge graph](/blog/context-engine-vs-knowledge-graph); it is reconciliation and synthesis at query time. That turns back pressure from a staffing problem into an engineering one. On the [context-maturity ladder](https://getunblocked.com/context-maturity/), this is L6, harness engineering: the harness around the model, not the model itself, becomes the product.

This is where Unblocked fits, as the context engine for engineering. It supplies [decision-grade context](/blog/decision-grade-context) to the agent writing the code and the human reviewing it, from the same reconciled source. As one engineer put it after wiring it into his agent workflow, "It surfaces things I wouldn't have thought to look for" (Justin McCraw, Software Engineer, The Information). That is the loop working as designed: humans judging with full context, not guessing with partial diffs.

## Frequently asked questions

### Is the outer loop the same as code review?

No. Code review is one activity inside it. That human band spans the full sweep of work around agent output: review, judgment, direction-setting, and shipping decisions. Faros AI found PR review time up 91% under high AI adoption ([Faros AI](https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025), 2025), but the pressure spans well beyond the review tab.

### Can better rules files fix instruction rot?

Only partially. IFScale shows instruction-following drops to about 68% at 500 instructions ([IFScale, arXiv:2507.11538](https://arxiv.org/abs/2507.11538), 2025), so piling on rules eventually hurts adherence. Rules files also capture only what you already knew to write down. The codebase and its surrounding discussion move faster than any static file, which is why the rot returns.

### Does a bigger context window solve context rot?

No, and it can make things worse. Chroma Research found performance degrades non-uniformly as input grows across 18 models ([Chroma Research](https://www.trychroma.com/research/context-rot), 2025), and the 2025 "Lost in the Middle" study found accuracy sags when key facts sit mid-context rather than at the edges ([arXiv:2510.10276](https://arxiv.org/abs/2510.10276), 2025). Reconciled, relevant context beats raw volume.

## Give the outer loop something to push against

Back pressure only works when the system carries the context, not just the human. Osmani is right that agents run the inner loop while engineers own the outer one. Pocock's point about instruction rot holds against any moving codebase. And the degradation Chollet describes, where extra context crowds out reasoning, is exactly what the benchmarks keep measuring. The missing half is what to do about it: stop asking a tired reviewer to reconstruct context from memory, and give the whole loop a shared, reconciled source of truth.

That is the shift from staffing the problem to engineering it. A context engine that synthesizes across your code, PRs, discussions, tickets, and docs, and delivers decision-grade context to every agent and every reviewer, is what gives the outer loop something solid to push against. Start with the [context-maturity framework](https://getunblocked.com/context-maturity/) and find where your team sits today.