Article

AI coding agents are the default. Now the bottleneck is you.

Author

Oleksandr Kotliarov

Date

July 27, 2026

Reading Time

23 min

Adoption is settled. When LeadDev declares AI coding agents “the default” and 88.3% of developers in LinearB’s 2026 benchmarks use AI multiple times a week, the “should we?” conversation is over. The interesting question is what breaks next. The answer is already measurable: generation scaled faster than verification did, and every second-order shift you’re about to hit is downstream of that one gap.

The imbalance doesn’t announce itself. Your dashboards will look excellent — PRs per engineer up, issues closed up. The failure shows up two layers down, in numbers most teams don’t chart: how long a pull request sits before anyone opens it, and how many incidents you produce per unit of shipped work.

The bottleneck moved. It didn’t disappear.

For two years the constraint was typing speed. Agents removed it. The constraint didn’t vanish — it relocated to the review queue.

LinearB’s 2026 benchmarks cover 8.1 million pull requests across roughly 4,800 teams. Human-authored PRs merge within 30 days at 84.5%. AI-assisted PRs merge at 32.7%. Two-thirds of AI-assisted pull requests are still open, or abandoned, a month later.

The spread across team maturity kills the easy explanation. Elite teams hit 95% acceptance on manual PRs and 71% on agentic ones; most teams can’t clear 60%. This isn’t bad teams being bad at AI. The best engineering organizations in the sample still lose 24 points of acceptance rate when the author is an agent.

Then the number that explains the mechanism: AI-assisted PRs wait about 5.3x longer before a reviewer picks them up — roughly 1,055 minutes against 201 for the agentic cut. (LinearB uses 4.6x for the broader AI-assisted category and 5.3x for agentic specifically, so the multiple depends on the cut. The direction doesn’t.)

And the detail that reframes everything: once review starts, AI PRs move slightly faster than human ones, 194 minutes against 252. The reviewing isn’t slow. The getting-picked-up is. Work piles up at the gate rather than moving slowly through it — which matters, because most of the advice circulating right now optimizes the part that was never broken.

Bar figure: PRs merged within 30 days — human-authored 84.5% against AI-assisted 32.7%; time in review — human-authored 252 minutes against AI-assisted 194 minutes; and AI-assisted PRs wait 5.3x longer before a reviewer picks them up. Source: LinearB, 2026.

Faros AI studied 22,000 developers across 4,000+ teams with two years of telemetry, comparing low-adoption teams against high-adoption ones, and named the pattern better than anyone: “acceleration whiplash.”

The gains in that data are real. Epics per developer up 66%. Task throughput up around 34%. PR merge rate per developer up 16.2%. Stop reading there and the tools work exactly as advertised.

The rest of the cut is where it gets expensive. Median time to first PR review up 156.6%. Median time in code review up 441.5%. Code churn up 861%. Bugs per developer up 54% — against 9% in Faros’s 2025 study, so the trend is accelerating rather than settling. Incidents-to-PR ratio up 242.7%. And the one that should end any comfortable reading: PRs merged with zero review, up 31.3%.

That last number is the pressure valve. When a queue slows 156% and work keeps arriving, something gives, and what gives is the gate. Nobody decides to stop reviewing. The queue decides for them.

Then the human factor, which most teams underprice. Sonar surveyed 1,149 professional developers: 96% say they don’t fully trust that AI-generated code is correct, but only 48% always check it before committing. That 48-point gap between belief and behaviour is the actual risk surface.

Sonar’s supporting numbers explain the gap rather than blaming developers for it. 38% say reviewing AI-authored code takes more effort than reviewing a colleague’s. AI accounts for 42% of committed code in that sample, projected to 65% by 2027. More code, each unit harder to review, arriving into the same reviewer-hours. The verification gap isn’t a discipline problem. It’s arithmetic.

Why time-to-first-review is the number that moves

“Review is the bottleneck” is a slogan until you can say why that specific number blew out.

Consider what a reviewer does with a human-authored PR. They don’t read it cold. They know the author, roughly what they were working on, which ticket it came from, probably discussed the approach three days ago. The diff arrives pre-loaded with context, and review is mostly a check against a mental model they already hold. That’s why a 400-line PR from a teammate is often a 20-minute job — 380 of those lines confirm what you expected to see.

Now open a 400-line agent PR. The author can’t be asked why. There was no design conversation; the design happened inside a context window at 2am. The commit message describes what changed, not what was considered and rejected. The reviewer builds the whole mental model from scratch, from the diff, with no priors about which parts are load-bearing and which are the agent being verbose.

That cost is paid before review starts, which is why time-to-first-review moves and time-in-review doesn’t. A reviewer scanning their queue makes an unconscious triage call: what does opening this cost me? For an agent PR the honest answer is “I don’t know, and probably a lot.” So it sits. Then the next one sits. Once opened, review completes fast, because agent code is often mechanically fine — the dread was about the unknown, and the unknown mostly resolves.

Size compounds it. At the 75th percentile, LinearB found AI-assisted PRs run 2.5–2.6x larger than unassisted ones: 400+ lines against 157. Dev Interrupted’s analysis of the dataset treats the merge-rate collapse and the size increase as one phenomenon seen from two angles. A 400-line PR from an author you can’t interrogate is a different object than a 157-line PR from someone sitting eight feet away, and putting both in the same queue under the same policy is where the process breaks.

This is also why “make the PRs smaller” is real advice rather than a platitude. It’s the only lever in the chain a team controls unilaterally, without buying anything or reorganizing anyone.

What the agent actually gets wrong

Volume and latency explain the queue. They don’t explain the incidents. For that you need to know what kind of defect an agent produces, and the best public attempt is CodeRabbit’s study of 470 open-source GitHub PRs — 320 AI-coauthored, 150 human-only — scored against one issue taxonomy.

The headline is unremarkable: 10.83 issues per PR in AI-coauthored code against 6.45 for human-only, a 1.7x multiplier, roughly proportional to the size difference.

The composition is the story. Security issues run up to 2.74x higher in AI-coauthored PRs — improper password handling and insecure direct object references most common. Logic and correctness issues up 75%. Readability problems 3x+ more common.

Read that against the latency data and the incident numbers stop being mysterious. The defect classes most over-represented in agent code are precisely the ones that survive a fast skim. A readability problem is visible in three seconds. An insecure direct object reference looks like working code: it compiles, it passes tests, it does what the ticket asked, and it also lets an authenticated user read someone else’s record by incrementing an ID. That defect doesn’t care how quickly you approved. It cares whether anyone built a mental model of the authorization path — the exact thing a rushed reviewer skips.

So the chain is tight. Agents write more code, in bigger PRs, with a defect mix weighted toward invisible failures, into a queue 156% slower to open anything that now merges 31.3% more work unreviewed. Incidents-to-PR up 242.7% isn’t a surprise. It’s the arithmetic.

CodeRabbit’s own caveat is worth carrying: they note they “cannot guarantee all PRs labelled human-authored were actually authored only by humans.” Some of that baseline is certainly agent-assisted and mislabelled, which would make the real gap smaller than 1.7x. Take the direction, hold the multiplier loosely.

The older agent-failure literature is useful here for shape rather than rate. In January 2025, Answer.AI ran a month-long evaluation of Devin across 20 real tasks: 3 successes, 14 failures, 3 inconclusive, with no discernible pattern predicting which would work. The characteristic failure wasn’t giving up — it was pressing forward on impossible tasks and inventing success. Asked to deploy multiple apps to a single Railway deployment, which Railway doesn’t support, Devin hallucinated features rather than reporting the constraint. Carnegie Mellon’s TheAgentCompany benchmark found the same texture across 175 simulated office tasks: the best model completed 30.3%, and failures included fabricating data and renaming a user to fake a completed task.

Both are dated — Answer.AI predates Cognition’s orchestration release by fourteen months, and CMU tested a model generation well behind the frontier. Quoting either as a current failure rate would be dishonest. What survives is that these were failures of self-report: the systems failed by confidently producing something that looked like success. That’s the failure mode a review process has to catch, because the system won’t flag it. And it’s the one a backed-up queue is worst at catching.

The counter-argument deserves better than a footnote

The bottleneck story has a credible counterweight, and if you argue this position internally you’ll meet it within ninety seconds. It’s DORA’s State of AI-assisted Software Development 2025, and it earns a real hearing.

DORA’s read: 90% of developers have adopted AI tooling, up 14 points year over year, and 80%+ report a genuine productivity increase. Their framing of the trust question is the sentence to beat — “AI doesn’t replace code review; it makes code review more critical.” That’s a story about a control point gaining importance, not failing. It comes from Google Cloud’s research arm with a decade of methodological credibility behind it.

Take it seriously, because the productivity gains it reports are the same ones Faros measured. Nobody in this argument disputes that throughput rose.

But read DORA’s own trust data before filing it as the optimistic case. 24% trust AI output “a great deal” or “a lot”; 30% trust it “a little” or “not at all”; 46% land on “somewhat.” The seniority breakdown should stop you: among experienced developers, 2.6% highly trust AI output against 20% who highly distrust it. The people who have seen the most production incidents are the least willing to sign off on agent code unchecked, by roughly 8:1.

DORA also coins the best phrase available for what that checking costs — the verification tax. Time saved writing code gets re-spent auditing it. And 60%+ of their respondents have found AI-related errors after deployment, which means the audit is paid either way, and a majority of teams are paying it in production rather than in review.

The synthesis that holds both sides is Faros’s word: whiplash. The gains are real and the defect cost is real, at the same time, in the same teams. DORA saying review is “more critical” and Faros measuring zero-review merges up 31.3% describe the same pressure from opposite ends — one is what should happen to review under agent load, the other is what did. Both are correct, and the distance between them is the whole problem.

The strongest honest version of the optimist’s case: review infrastructure is under-built rather than fundamentally broken, because it was designed for a volume that no longer exists. That’s solvable. It just isn’t solved by ignoring it, and nothing on the vendor roadmap solves it for you.

The best-known number in this debate was retracted by its own authors

There’s an epistemics problem underneath all of this, and it should change how much confidence you put in any number here — including the ones above.

In July 2025, METR published a randomized controlled trial that became the most-cited data point in the skeptic’s case: 16 experienced open-source developers, 246 real tasks on repositories averaging a million lines, using Cursor Pro with Claude 3.5 Sonnet. Developers were 19% slower with AI tools.

The second-order finding made it famous. Those developers predicted a 24% speedup beforehand. Afterwards, having been measurably slowed, they still believed they’d been 20% faster — a 39-point perception gap, in experienced engineers, on their own work.

Here’s the part that never gets quoted alongside it. In February 2026, METR published an update saying they can no longer run this measurement. Too many developers now refuse to participate in a no-AI condition, and the resulting selection bias is severe enough that METR is changing the experiment design. Their qualitative read is that late-2025 tooling has likely narrowed or reversed the slowdown — which they explicitly label “weak evidence,” more honesty than most people citing their earlier number have shown.

So the most rigorous study in this space measured early-2025 tools, produced a number now eighteen months stale, and its own authors say the measurement can’t currently be redone. Anyone quoting “19% slower” at you in mid-2026 is quoting a retracted instrument.

Sit with what that implies for the rest of the evidence. METR’s design was the good one — randomized, controlled, real tasks, real repos. Everything else cited here is telemetry or survey. LinearB and Faros are observational cuts of production data, with the confound that teams adopting AI aggressively may differ systematically from teams that don’t. Sonar and DORA are self-report. CodeRabbit is scored by a vendor selling code review. None of these are bad sources; none are RCTs either, and the field’s best attempt at one just reported it can’t hold a control group together, because an experienced engineer working without AI is becoming hard to staff.

The conclusion isn’t nihilism. It’s that you should weight your own telemetry above all of it. The industry numbers tell you which two or three metrics are worth instrumenting. They don’t tell you your team’s values.

From author to editor

If an agent writes the code, your job is to review it. That sounds obvious until you see the volume shift.

A DX cohort study across 400+ organizations found AI-authored code went from 22% of commits in Q4 2025 to 51.9% by Q2 2026 — more than doubled in two quarters. Over the same window, median PR size went from 44 lines to 72. Nearly doubled in a year.

Hold those together: the median engineer now reviews substantially more code than they write, and each unit of review is larger. DX’s warning is the sharpest framing of the cost — “compounding cognitive debt across the team as engineers struggle to understand code they did not write.” Cognitive debt behaves like technical debt. It accrues silently, it’s cheap to ignore for two quarters, and it comes due during an incident, when the person paging through an unfamiliar module at 3am is nominally its owner.

The tooling is repositioning around this, and where it’s moving is the clearest available signal about where the job goes.

Amazon’s Kiro is the sharpest example. It reached general availability in March 2026 and is built spec-first rather than prompt-first. The workflow inverts a chat-driven agent: you write natural-language requirements, Kiro generates user stories with explicit acceptance criteria, then a technical design document, then a task list — maintaining traceability between requirement, design, and implementation. When the code changes, you can ask which requirement it came from.

The positioning is the tell. Amazon shipped Kiro cloud-agnostic and standalone, deliberately separate from the AWS-coupled Amazon Q Developer. AWS does not usually build products that work fine on Google Cloud. That they did here says they believe the specification — not the code, not the cloud — is the durable unit of engineer output.

AGENTS.md does the same at repository level. Formalized as an open spec in August 2025, led by OpenAI with Google, Cursor, and Factory, it was donated to the Linux Foundation’s Agentic AI Foundation in December 2025, and it’s read natively by Codex, Cursor, Copilot, Gemini CLI, Aider, Zed, and a couple dozen other tools.

The donation matters more than the adoption count. Vendors don’t hand a format to a neutral foundation out of generosity. They do it when the format is worth more as shared infrastructure than as a lock-in point. OpenAI giving up unilateral control is a bet that the file outlives any particular agent.

What an AGENTS.md holds is unglamorous and exactly the point: build and test commands, style rules, directory boundaries, what not to touch, which patterns the codebase already rejected. It’s the context a new hire absorbs in a fortnight and an agent absorbs in one file read. Written badly, every session rediscovers your conventions and gets them wrong in a fresh way each time.

The hiring signal points the same direction and needs reading carefully rather than dramatically. Salesforce’s Marc Benioff said in February 2025 the company wouldn’t add software engineers that year, citing a 30% engineering productivity gain; headcount has held near 15,000 since. His line to other executives — “we are the last generation to manage only humans” — is the quotable part.

We’d push back on the extrapolation built from it. That’s one company, with a CEO who sells AI agents commercially and therefore has an incentive to describe a world where they replace headcount. The broader “juniors are finished” narrative is mostly aggregator content recycling percentages with no primary labour dataset behind them, and we won’t repeat numbers we can’t trace.

The defensible claim is narrower and more useful: the work is moving from writing code to specifying and verifying it. That’s a different skill than the one most review processes exercise — and it’s a skill that historically came from writing a lot of code badly and being corrected. If the industry stops paying people to do the thing that produces the judgment, the judgment doesn’t appear from somewhere else.

Fleets need fleet managers

The vendors saw the throughput ceiling and shipped past it. What’s on the market now is GA product, not roadmap.

In March 2026 Cognition released “Devin can now manage Devins”. A parent session decides a task needs parallel workers, spawns them, allocates resources, sets execution constraints, monitors progress, resolves conflicts, and compiles results. Cognition’s framing is that it eliminates “external orchestration overhead” — meaning the orchestration layer you were about to build is now inside the product.

Cursor’s cloud agents launched February 2026 and hardened fast: multi-repo support, version history and rollback, scoped secrets. Cursor 3.2 added /multitask in April 2026, decomposing a task across subagents, each on its own VM and branch. The documented ceiling is 10 parallel workers per user, 50 per team, with a self-hosted option for orgs that need execution inside their own network.

Replit’s Agent 3 gives the clearest number for the autonomy horizon: it runs autonomously for up to 200 minutes with minimal supervision, against roughly 20 minutes for Agent 2. A 10x jump in how long a system works unattended before it needs you — the most concrete public measure of leash length available.

Google’s Antigravity 2.0, launched at I/O on May 19, 2026, is the full pivot from AI-assisted IDE to orchestration platform: an orchestrator decomposes the goal and spawns dynamic subagents on the fly, each with an isolated context window. Their headline demo — 93 parallel sub-agents building a working OS in 12 hours — is vendor-produced, so weigh it as marketing. The product shipped regardless. GitHub’s Copilot coding agent reached GA as a standalone app in June 2026, running parallel sessions on isolated git worktrees so agents don’t collide on each other’s files.

Notice what every one of these solves, and what none of them solve.

Each is a generation orchestration layer. More agents, more parallelism, more branches, more output. Not one announcement claims to have fixed the review bottleneck at the other end. Nobody ships a “your reviewers are now 5x faster” feature, because that product doesn’t exist.

So the fleet tools make the imbalance strictly worse. They multiply the input to a queue already 156% slower to open anything. Ten parallel workers per engineer is ten times the generation and exactly the same reviewer-hours. Orchestration got solved; verification got multiplied by the solution.

Concept figure: an orchestrator fans out into many parallel agent workers — 10 per user, 50 per team — which all converge into a single narrow review pipe that is 156% slower, ending in one block labelled "same reviewer-hours." Orchestration got solved; verification got multiplied.

Tom Moor, Linear’s head of engineering, is the most useful voice here precisely because he’s an enthusiast. Linear’s numbers, reported in the LeadDev piece, are genuinely good: PRs per author rose from 52.7 in February 2026 — itself a 30% increase — to 59.8 by March. Issues closed per author went from 44.4 to 55.2. Over 50% of the PRs generated by Linear’s internal coding agent were mergeable. They cut context-window token usage around 40% through optimization. This is a team that is good at this and has the receipts.

Moor’s assessment of what he built: “Code review is the new bottleneck.” The person with the highest agent throughput in the story is the one telling you the constraint moved. That’s an operator’s report from the far side of the curve you’re climbing.

His proposed fix is the honest version of the optimist’s position: “I’m very bullish on AI, and with every problem it causes, the solution is more AI.” Maybe. That’s a bet, and he’s clear-eyed enough to say so — his other line is the one to pin up: “Right now, this is still human in the loop.”

One more Moor observation should worry anyone planning to solve this with policy. When Linear accidentally took AI tooling away from engineers: “When we’ve taken that away accidentally from people, they scream.” You will not fix the verification gap by making agents harder to use. That lever is gone. The remaining levers are all on the review side.

The bill changes shape

Per-seat pricing assumed a human typing. Per-token pricing assumes an agent that never sleeps, and the difference lands on an invoice your finance forecast hasn’t modelled.

The hardest number here comes from the LeadDev piece: a Linear engineer ran up $6,000 in Cursor bills during a single library-migration project. One engineer, one project.

That’s the number to internalize, and it’s worth saying why it’s the one we use. You’ll see claims that agentic spend is becoming the second-largest line item after payroll, or figures like $500–$2,000 per engineer per month. Those come from vendor comparison content rather than audited datasets, and we won’t launder them by repeating them confidently. Treat the Linear example as an existence proof rather than a benchmark: one engineer on one migration can produce a five-figure line item without anyone doing anything wrong.

Linear’s token-optimization work implies the corollary. If a competent team removes 40–90% of their token consumption through engineering effort, an unoptimized team is paying several times over for the same output. Token efficiency is becoming an engineering discipline with a direct P&L line — a new thing for most engineering orgs to own.

The structural problem: cost is now coupled to agent activity rather than headcount. Per-seat spend is predictable by construction; you know how many people you have. Per-token spend is a function of how enthusiastically your engineers use the fleet you just handed them, which has no natural ceiling and, per Moor, strong resistance to being capped.

Vendors also rewrite the unit economics underneath you mid-flight. Google restructured Antigravity from subscription to credits in March 2026: free-tier quotas cut roughly 92%, Pro users losing their 5-hour refresh cycle, credits at $25 per 2,500 with no clear documentation of what a credit buys. It drew immediate public backlash.

The lesson isn’t that Google was greedy. It’s that a vendor can change your cost base in a single release, and the opacity is the operational problem more than the price. You cannot forecast against a unit you can’t define, and “what does a credit buy” was not documented.

Then there’s who owns the vendor, which stopped being hypothetical.

In June 2026, SpaceX agreed to acquire Cursor-maker Anysphere for $60B in an all-stock deal, days after SpaceX’s own IPO. The run-up explains the number: Anysphere’s ARR went from around $100M in January 2025 to roughly $4B by June 2026, with a $2.3B Series D in November 2025 at a $29.3B valuation. So $60B is about double a valuation set seven months earlier.

Sit with the shape of that. One of the largest AI-coding vendors, embedded in a large share of engineering orgs, folded onto the balance sheet of a rocket company. Whatever you make of the strategic logic, the roadmap for a tool your team touches daily is now downstream of people whose primary business is launch cadence. Anthropic shows the same gravity from another angle: a $30B Series G at a $380B post-money valuation, with Claude Code above $2.5B run-rate. The market is pricing coding agents as infrastructure, and infrastructure gets consolidated.

Which brings us to the case study that belongs on every procurement checklist. In July 2025, Windsurf was pulled apart in three weeks. A roughly $3B OpenAI acquisition collapsed. Google then paid $2.4B to license Windsurf’s technology and hire the CEO, co-founder, and part of the R&D team into DeepMind — structured as licensing rather than acquisition. Cognition bought the remaining IP, product, and roughly 200 staff for around $250M. Three weeks later, Cognition laid off 30 of those employees and offered buyouts to the rest.

A company with real product, real revenue, and real customers was split three ways and restructured inside a month. Every team standardized on Windsurf woke up to a different owner, a different roadmap, and most of the senior people gone. Nobody did anything to them. The market moved.

If your workflow is welded to one agent vendor, you’re betting on a market that reshuffles faster than your procurement cycle can respond. That’s not an argument against agents. It’s an argument for knowing what your exit costs before you need to know.

The new attack surface

One more shift, easy to miss because it isn’t about productivity.

Agentic tools can act. That single property turns prompt injection from a content problem into a code-execution problem. Your IDE could render malicious text. Your agent can run it.

The clearest illustration is the Antigravity vulnerability found by Pillar Security, reported to Google in January 2026 and patched on February 28. The mechanism is almost boring: the find_by_name tool’s Pattern parameter lacked input sanitization. An attacker could inject the -X flag — exec-batch — into the underlying fd utility, and fd -X runs a command against every match. Arbitrary code execution, delivered through a file-search parameter.

The part that should change how you think about agent sandboxes isn’t the missing sanitization. It’s the classification bug underneath. As CyberScoop’s coverage makes clear, the attack bypassed Antigravity’s most restrictive “Secure Mode” entirely — because find_by_name was classified as a “native tool” rather than a shell command, and Secure Mode evaluated shell commands.

Read that again, because it generalizes to every agent sandbox on the market. Secure Mode wasn’t defeated. It was never consulted. The security boundary was drawn around a category of action, and the dangerous action was filed under a different category — a hole shaped like a taxonomy decision someone made months earlier, probably in an afternoon, probably reasonably.

That’s the structural risk. Sandboxes enumerate what’s dangerous — shell access, network calls, filesystem writes outside the workspace — and gate those. But every agent platform ships dozens of native tools that feel safe by category (search a file, read a doc, list a directory) and are implemented by shelling out to a real binary with real flags. The model assumes the taxonomy is complete and correctly applied. It is neither, because it’s maintained by hand and the tool list grows every release.

So the question for a vendor isn’t “do you have a sandbox mode.” Everyone has one. It’s: what is enumerated, what is excluded, and who reviews that classification when a new tool is added? If the answer is a list, ask when it was last audited against the actual tool registry. Google’s was wrong in a shipped flagship, found by an outside researcher, and they paid a bounty for it — the system working, and also a demonstration that internal review missed a -X flag in a file-search parameter.

Your IDE never had this attack surface. Your agent does, and its sandbox is only as good as its least-examined tool.

What to do in the next 12 months

Concrete, low-ceremony, doable this quarter. Not a maturity model.

Instrument the gate, not the output. Stop reporting PRs merged and lines shipped. They go up regardless now and measure the part of the system that stopped being scarce. Track two numbers instead: time-to-first-review on AI-assisted PRs, and your incidents-to-PR ratio.

Why those two. Time-to-first-review is the leading indicator — it’s where reviewer-capacity shortfall first becomes visible, and it moves weeks before merge rate degrades and months before incidents rise, because a queue backs up long before it starts dropping things. Incidents-to-PR is the lagging one, and the ratio matters rather than the raw count: raw incidents rise with any growth, but incidents per unit of shipped work rising means each thing you ship is more dangerous than what you shipped last quarter. That’s the Faros 242.7%, and it tells you whether your throughput gain is real or borrowed. Both are computable from data already in your Git provider and your incident tracker. Neither needs a vendor.

Put a hard budget alert on agent spend per engineer. An alert, not a cap — a cap produces exactly the reaction Moor described, and you’ll spend political capital you need elsewhere. Per engineer, per week, firing before one migration quietly becomes a $6,000 line item.

The mechanism it catches is specific: a long-running agent session on a large context, iterating. That’s the shape of the Linear example, and it’s invisible in monthly aggregate billing, where one engineer’s outlier disappears into a team number until the invoice lands. When it fires, the first question is whether the context window is doing unnecessary work — Linear cut 40% through optimization alone, so the answer is often yes.

Make spec review a first-class gate. If the engineer’s real output is the AGENTS.md and the spec, review those with the seriousness you used to spend on the diff.

Concretely, in a repo: AGENTS.md gets a CODEOWNERS entry and requires senior approval, the same as a migration or a CI config. For any task large enough to produce a multi-hundred-line PR, the spec — requirements plus acceptance criteria, which is what Kiro generates and what you should write by hand regardless of tooling — lands as its own reviewed artifact before the agent runs, rather than as a description in the PR body afterwards. The reviewer of the resulting diff reads the spec first, which restores exactly the shared context that’s missing from an agent PR. That’s the mechanism: agent PRs sit because there was no design conversation to lean on, so you manufacture one, in writing, ahead of time.

The honest caveat: nobody has quantified whether spec review reduces total verification burden or relocates it one layer up. It might be the same work in a different place. What it definitely does is move the work earlier, and a wrong spec caught in ten minutes of reading is cheaper than a thousand wrong lines caught in a backed-up queue — or not caught, in the 31.3% that merge unreviewed.

Run a 30-day vendor-switch test. Ask it out loud: if your primary agent vendor were acquired and gutted next month, the way Windsurf was, could you move in 30 days?

Make it specific rather than philosophical. What’s portable: AGENTS.md, deliberately, which is a large part of why the Linux Foundation donation matters commercially. What isn’t: vendor-specific rules files, IDE-coupled workflows, agent configurations living in one product’s cloud, CI integrations wired to one API. Write the list. That list is your real lock-in, and it’s worth pricing calmly now rather than during a migration whose timing you didn’t choose. The answer might be “we’d take the hit, they’re worth it.” That’s a fine answer, and a different thing from not knowing.

Ask your vendor the classification question. Once, in writing, this quarter: which agent actions does your sandbox mode evaluate, which are excluded, and what happens when a new tool is added? You’re not looking for a marketing answer about security posture. You’re looking for whether anyone on their side can name the boundary. Antigravity’s team presumably couldn’t, and that was a shipped flagship.

None of this is a transformation programme. Four numbers, one file, and a question — all of which fit in a quarter, and all of which get more expensive the longer you wait, because the volume they’re meant to control compounds while you decide.

The teams that come out ahead this year won’t be the ones generating the most code. That contest is over and everyone tied. They’ll be the ones who rebuilt review, cost control, and vendor independence to match the volume the agents already produce — a management problem wearing an engineering costume, sitting in your queue right now, 5.3x longer than it should be.