Your AI Agents Aren't the Bottleneck. Your Repository Is.

The Delegation Gap Is a Repository Problem

Anthropic's 2026 Agentic Coding Trends Report surfaced a number that should be more uncomfortable than it has been treated as. Developers now use AI in roughly 60% of their work — but report being able to fully delegate only 0–20% of tasks. Anthropic calls this the delegation gap, and it is the single most important metric in agentic engineering right now, because it is the gap between AI as a typing accelerator and AI as actual capacity.

The instinctive explanation is model capability: agents cannot yet be trusted with a whole task, so we supervise them line by line, and we wait for the next release to close the gap. That explanation is comforting because it makes the problem someone else's roadmap item. It is also mostly wrong.

The strongest available evidence points somewhere much less flattering. DORA's 2026 research found that AI tools deliver 35–40% gains on clean greenfield tasks — and 10% or less on brownfield work inside existing legacy code. Same models. Same tools. Same engineers. A three- to fourfold difference in return, determined entirely by the properties of the repository the agent was pointed at.

That is not a model problem. That is an infrastructure problem, and it has a name that has been quietly consolidating across engineering blogs and vendor tooling since spring: agent readiness. The question is no longer how capable your agent is. It is whether your codebase is a legible environment for one — and for most companies with a codebase older than three years, the honest answer is no.

This reframing matters commercially, because it changes where the budget should go. A team that spends €200k on seats, orchestration platforms, and premium model tiers while running a nine-minute CI pipeline against 30% test coverage has bought a Formula 1 engine and bolted it to a chassis that cannot transmit the power to the road.

The AGENTS.md Correction: What the Research Actually Found

The industry's first collective answer to agent readiness was documentation. AGENTS.md — a single Markdown file at the repository root telling any agent the build commands, test commands, style rules, and do-not-touch boundaries — was formalised as an open specification in August 2025 with participation from OpenAI, Google, Cursor and Factory, and donated to the Linux Foundation's Agentic AI Foundation that December. By the end of 2025 more than 60,000 open-source projects had adopted it, and it is now read natively by 30-plus tools including Claude Code, Copilot, Cursor, Codex, Gemini CLI, Devin and Amazon Q.

It was a reasonable hypothesis, cheaply tested, and broadly adopted before anyone measured it. Then someone measured it.

A team at ETH Zurich — Gloaguen, Mündler, Müller, Raychev and Vechev — published "Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?" in February 2026, running the experiment across multiple models and agent harnesses on SWE-bench and related benchmarks. The headline finding: providing context files does not generally improve task success rates, while increasing inference cost by more than 20% on average — and this held for both LLM-generated and human-committed files. LLM-generated context files actively reduced success rates in five of eight tested settings, with drops averaging around 0.5% on SWE-bench Lite and 2% on AGENTbench, against a 20–23% cost increase.

The mechanism the researchers identified is more instructive than the numbers. Coding agents are too obedient. They faithfully follow the instructions in a context file, so when those instructions encode requirements that are unnecessary, stale, or subtly wrong, the agent dutifully makes its own task harder. And the single most common ingredient of a typical AGENTS.md — the codebase overview and directory listing — turns out to be near-worthless, because agents are already good at discovering structure themselves. Reading a hand-maintained map just burns reasoning tokens and adds cognitive overhead.

The correct reading of this paper is not "delete your AGENTS.md." It is narrower and more useful: context files earn their keep only for genuinely non-inferable facts — the internal deployment convention nobody would guess, the one module that must not be touched for licensing reasons, the test command that differs from the framework default. Everything an agent could discover by looking is a liability that costs you money on every single run. And crucially: instructions are not a substitute for infrastructure. You cannot document your way out of a repository that cannot verify itself.

Verifiability Is the Real Context

If instructions are not the lever, what is? The most defensible answer emerging from 2026 practice is verification. The frontier of what an agent can accomplish is set not by how well you describe the task, but by how reliably the environment can tell it whether it has succeeded.

This follows directly from how agents work. An agentic loop is a search process: propose a change, observe the result, correct, repeat. Every element of that loop is bounded by the quality of the observation step. A repository with a fast, comprehensive test suite gives an agent a dense, immediate error signal, and it will iterate its way to a correct answer without human intervention. A repository where the only way to know if something broke is to deploy it and wait for a customer to complain gives the agent nothing — so it produces code that compiles, passes the three tests that exist, looks plausible in review, and fails in a nightly batch job two weeks later.

The magnitude of this effect is larger than most leaders assume. LangChain's work on structured skills found agents completing tasks 82% of the time with proper scaffolding loaded versus 9% without — not a marginal improvement, a categorical one. And on the test side, Diffblue reported its testing agent producing 81% average line coverage against 32% for a senior developer iterating with a general-purpose coding agent, which tells you something about how much of the verification substrate is itself now automatable if someone is assigned to do it.

This is why the teams getting real leverage from agents in 2026 look, from the outside, like they are doing boring work. They are cutting CI feedback from eleven minutes to ninety seconds. They are adding type annotations to untyped Python. They are making the build hermetic so that an agent's failure is a real failure and not an environment flake. They are writing characterisation tests around legacy modules with no coverage. None of this is exciting, none of it demos well, and all of it multiplies the return on every AI seat the company is already paying for.

The Eight Pillars: What Agent Readiness Actually Measures

The most concrete framework to emerge so far comes from Factory.ai's Agent Readiness work, which scores repositories across eight technical pillars: style and validation, build system, testing, documentation, dev environment, code quality, observability, and security and governance. Each criterion is binary, and a repository must pass 80% of the criteria at a maturity level — plus everything below it — to unlock that level. Level 3, "standardised," is the point at which agents can reliably handle routine maintenance: bug fixes, tests, docs, dependency upgrades.

Each pillar maps to an observed production failure mode, which is what makes the framework useful rather than merely tidy. Without style validation, for example, the agent submits code with formatting issues, waits for CI, fixes blindly, and repeats — burning tokens and wall-clock on a problem a pre-commit hook would have eliminated. Without a hermetic dev environment, an agent cannot distinguish its own error from a broken container. Without observability, it can produce a change that is correct in the test suite and catastrophic under production load.

What is striking about the eight pillars is how little of it is AI-specific. This is the same list a competent staff engineer would have produced in 2019 as a description of a healthy repository. Agents did not create these requirements; they removed the option of ignoring them. A human engineer can compensate for a bad build system with tribal knowledge, a Slack message, and twenty minutes of annoyance. An agent cannot — it just fails, silently and expensively, at scale.

That is the genuinely new thing here. Engineering hygiene used to be a quality argument that competed poorly against feature work in every roadmap meeting. It is now a throughput argument with a measurable multiplier attached, and it wins on the merits. If a €200k-per-year AI tooling spend returns 10% on your main codebase and 40% on a clean one, the readiness work has an ROI you can put in a slide.

Where Unready Repositories Actually Fail: The Review Queue

The cost of an unready repository does not show up where people look for it. It shows up downstream, in the review queue, as a queueing problem that most dashboards are structurally incapable of displaying.

LinearB's 2026 benchmarks, drawn from 8.1 million pull requests across more than 4,800 organisations, found agentic AI PRs sitting in the queue with a pickup time 5.3x longer than unassisted PRs, and AI-assisted PRs waiting 2.47x longer. The same dataset produced the year's most quoted finding: developers feel about 20% faster while measuring as roughly 19% slower — a 39-point gap between perception and reality. CircleCI's 2026 data shows the same shape from a different angle: feature branch throughput up 59% year over year while main branch throughput for the median team actually fell. Work is being produced faster and arriving at the merge point slower.

Repository readiness is what determines how much human attention each of those PRs consumes. When style, types, tests, and security scanning are enforced mechanically, a reviewer's remaining job is to evaluate whether the change is the right change — a judgement task. When none of that is enforced, the reviewer becomes a human linter, and reviewing a 900-line agent-authored diff by hand is both slower and less reliable than reviewing a human one. CodeRabbit's analysis found AI-authored code surfacing roughly 1.7x more issues per PR on mature codebases, with logic errors 75% more common, security vulnerabilities at 2.74x the rate, and I/O performance problems 8x more frequent.

There is a second-order effect worth naming, because it compounds. GitClear's analysis of 623 million code changes found legacy refactoring down 74% since 2023 — agents generate new code far more readily than they consolidate existing code. So an unready repository does not merely resist agents; under agentic development it degrades faster than it did before, accumulating duplication that makes it progressively less legible to the next agent that touches it. The gap between ready and unready codebases is widening on its own.

Why This Work Doesn't Get Done In-House

If the case for readiness is this clear, the obvious question is why so few companies have done it. The answer is not ignorance. It is capacity allocation, and it is almost perfectly predictable.

Readiness work is senior work. Writing characterisation tests around a legacy payments module, making a decade-old build hermetic, introducing types into an untyped codebase without a big-bang rewrite, cutting CI from eleven minutes to ninety seconds — these tasks require exactly the engineers who are least available, because those same engineers are the ones holding up current delivery. It is also work that produces no visible feature, which means it loses every roadmap negotiation it enters against a customer commitment. And it is work with a defined endpoint: a six-month project, not a permanent headcount, which makes it a poor fit for hiring.

That combination — senior, time-boxed, invisible to customers, blocked by the very people best qualified to do it — describes a category of work that is nearly impossible to staff internally and unusually well suited to an external dedicated development team. A parallel team can rebuild the verification substrate while your in-house engineers keep shipping, and the two streams barely contend for the same attention.

The staffing profile matters more here than on ordinary feature work, though, and it is where most outsourcing arrangements would fail. You cannot hand this to a volume vendor supplying mid-level engineers against a specification, because the specification is the hard part. Deciding which 40 legacy modules deserve characterisation tests first, or how to make a build reproducible without a rewrite nobody has budget for, is judgement work — it requires people who can read an unfamiliar system and form an opinion about it. This is the argument for senior-led nearshore development rather than offshore volume: a small number of experienced engineers in a compatible timezone who can ask your architect a question at 2pm and have the answer the same afternoon.

At StepTo we have run senior engineering teams out of Belgrade since 2014, and readiness engagements have become a recognisable and growing share of the work — build and CI modernisation, test-suite reconstruction, and application modernisation undertaken specifically so that a client's existing AI tooling investment stops returning brownfield numbers. Engineers are assigned by name and stay with the codebase, which matters disproportionately on this kind of work: the value is in accumulated understanding of a specific legacy system, and that evaporates the moment people rotate off a shared bench.

A 90-Day Agent-Readiness Program

Readiness is not a rewrite, and treating it as one is the most common way it gets killed before it starts. It is a sequence of bounded interventions, ordered so that each one makes the next cheaper. Here is a shape that works on most brownfield codebases.

Weeks 1–2: measure. Score the repository against the eight pillars honestly, and instrument the three numbers that matter — CI wall-clock to first failure, test coverage on the modules that change most often, and the percentage of agent PRs merged without a human commit on top. That last number is your real delegation rate, and almost nobody tracks it. You need a baseline, because the entire business case for this work depends on being able to show the number moving.

Weeks 3–6: close the feedback loop. Enforce formatting and linting mechanically at commit time so that no reviewer or agent ever spends a cycle on it. Make the build hermetic and reproducible. Attack CI latency directly — a pipeline under two minutes changes agent behaviour categorically, because the agent can afford to iterate rather than guess. This phase alone typically moves the delegation rate more than any tooling upgrade.

Weeks 7–10: rebuild the verification substrate. Identify the modules with the highest change frequency and the lowest coverage — that intersection is where agents will do the most damage — and write characterisation tests around them. Introduce type coverage where the language allows it. The goal is not a coverage percentage for a dashboard; it is that a wrong change fails loudly and immediately in the parts of the system that actually change.

Weeks 11–13: prune the instructions and set the boundaries. Now, with the infrastructure carrying the weight, cut your AGENTS.md down to non-inferable facts only, per the ETH Zurich finding — delete the directory listing, delete anything the agent can discover, keep the deployment convention nobody would guess. Then define the governance boundary: which paths agents may touch unattended, which require human review, and which are off-limits entirely. Re-measure against your week-two baseline and put the delta in front of whoever approved the AI budget.

What This Means for How You Buy Engineering

Agent readiness quietly changes the due diligence question you should be asking any development partner, and most procurement processes have not caught up.

The standard question — which AI tools does your team use? — has become close to meaningless, because the honest answer from every credible vendor in 2026 is the same three or four products. The differentiating question is what a partner does to the repository. Do they leave behind a codebase with a hermetic build, meaningful coverage on the modules that change, and a CI pipeline fast enough for an agent to iterate against? Or do they leave a large volume of AI-generated code that works today and is progressively less tractable to every agent and engineer who touches it afterwards?

This distinction has direct economic consequences for you, and it is worth writing into contracts. If a vendor's agentic velocity is achieved by generating code faster than the repository can verify it, they are borrowing against your future throughput and booking it as this quarter's delivery. The GitClear refactoring collapse is the aggregate signature of exactly that trade being made across the industry. Readiness metrics — coverage on high-churn modules, CI duration, agent-PR merge rate without human correction — are objective, cheap to measure, and belong in a statement of work next to the feature list.

For teams evaluating staff augmentation or a full outsourced team, the practical test is simple enough to run in a first technical conversation: ask a prospective partner what they would change about your repository in the first 30 days, before writing a single feature. A vendor optimising for billable hours will tell you they can start on the backlog Monday. A partner who understands where 2026's leverage actually sits will have opinions about your build, your test suite, and your pipeline — and will be able to explain what each one is currently costing you per agent-hour.