Agentic development: what changed, what broke, and where it goes next

13 August 2026

Coding agents moved the bottleneck from writing software to verifying it. What the 2026 data actually says, the practices that hold up under it, and the bet I'd make on the next two years.

For most of my career the unit of work was a line of code. Today it is a verified change: something an agent produced, that I understood, tested, and can defend in review. That sounds like a small reframing. It isn't. It moves the binding constraint in software engineering from typing to trusting, and almost everything interesting about agentic development in 2026 follows from that one move.

What follows is my read of where we are, with the numbers attached. I have tried to be honest about the parts that got worse, because a post that only lists the wins is a sales page, not an engineering assessment.

How we got here, in three moves

Autocomplete predicted the next token in the file I had open. Chat moved the model out of the file and into a conversation, but I was still the one holding the codebase in my head. Agents inverted that: the model gets a terminal, a filesystem, the test suite, and a loop — and I hold the goal. The interface stopped being a text box and became a harness.

Adoption stopped being the story somewhere in 2025. DORA's 2025 report put AI use at roughly nine in ten developers, and its central finding was not that AI makes teams fast — it was that AI is an amplifier and a mirror. It does not fix a team. It multiplies whatever that team already is. Google's CEO said in April 2026 that 75% of the company's new code was AI-generated and approved by an engineer, though numbers like that are worth reading carefully: "AI-written" means very different things depending on whether you count accepted suggestions, agent-authored diffs, or anything a human later signed off on.

The part I find more telling as an engineer is how fast the boring infrastructure standardized. MCP went from one vendor's experiment to the way tools are exposed to models, with its TypeScript and Python SDKs each past a billion total downloads and a July 2026 specification that reads like grown-up plumbing: a stateless protocol core, cacheable results, hardened authorization, a formal extensions framework. AGENTS.md went from a convention to an open specification used by more than 60,000 open-source projects and stewarded by the Agentic AI Foundation under the Linux Foundation. Two years ago the interesting question was which model. Today it is which harness, and what that harness is allowed to touch.

The capability curve, read carefully

The most useful single measurement I know of is METR's time horizon: the length of task, measured in how long it takes a human professional, that an agent completes with 50% reliability. Their January 2026 update rebuilt the suite to 228 tasks, 31 of which take a human eight hours or more. On that suite the frontier sits around five hours — Claude Opus 4.5 at 320 minutes, GPT-5 at 214. The doubling time is about 197 days across the full history, but roughly 89 days if you only count progress since 2024.

That curve deserves a caveat that its fans usually skip. Benchmark tasks are well-specified, self-contained, and come with a clean success signal. Production work is none of those things: the requirements are wrong, the context lives in three people's heads, and "done" is a negotiation. Read the horizon as how long a leash the agent can be trusted with, not as how good it is. A 2026 position paper makes the sharper version of this point — coding benchmarks conflate the model with the harness around it, which is exactly the part teams are actually differentiating on.

What broke

The clearest picture of the cost comes from Faros AI's 2026 report, built on two years of telemetry from 22,000 developers across more than 4,000 teams. Under high AI adoption, throughput went up: tasks per developer +33.7%, epics per developer +66%, PR merge rate +16.2%. So did everything downstream of it: bugs per developer +54%, the incidents-to-PR ratio +242.7%, code churn +861%, median time to review a pull request +441.5%, and pull requests merged with no review at all up 31.3%. They call the pattern acceleration whiplash, which is as good a name as any.

LinearB's 2026 benchmarks, across 8.1 million pull requests from 4,800 organizations, show the same thing from the other end. Agentic pull requests wait 5.3x longer before a reviewer picks them up — 1,055 minutes against 201 — and at the 75th percentile they are 2.6x larger, 408 lines against 157. Then they merge at 32.7%, where human-authored PRs merge at 84.4%. Generation got cheap. Attention did not.

The bottleneck did not disappear. It moved from the keyboard to the review queue, where it is much harder to see and much more expensive to ignore.

There is also a result I think every developer using these tools should sit with. In METR's randomized trial, 16 experienced open-source developers worked 246 real tasks in repositories they knew well. With AI they were 19% slower — and afterwards estimated that AI had made them 20% faster. Being fair to the study means quoting its own caveats too: METR now labels the result historical, and redesigned the 2026 follow-up because selection effects made the newer estimate unreliable, with developers reluctant to participate if they might have to work without AI. The durable finding is not "AI is slower." It is that our sense of our own speed is not evidence. This has to be measured.

Developers seem to know it. In Stack Overflow's 2025 survey, 84% used or planned to use AI tools while trust fell to 29%, down eleven points in a year; 46% actively distrust the accuracy of the output against 33% who trust it, and only 3% trust it highly. The most experienced respondents were the most skeptical. That is not luddism — it is calibration, and it is the correct response from anyone whose name is on the deployment.

Open source has been the least protected surface. Maintainers spent the past year drowning in plausible-looking pull requests that their authors could not explain when questioned, to the point that entire collectives have shut down rather than keep triaging them. Review is the scarce resource in this whole system, and it is the one thing agents made cheaper to consume and no cheaper to supply.

What actually works

None of that is an argument against agents. It is an argument for engineering around them, which is what I have spent the last stretch of my consulting work doing. The practices that survive contact with a real codebase, in rough order of leverage:

• Make the repository legible to an agent. An AGENTS.md at the root with the build and test commands, the code-style rules, and an explicit list of what not to touch. One-command setup. Fast, deterministic tests. Everything an agent has to rediscover is paid for twice — once in tokens, once in the mistakes it makes while guessing. This is the cheapest change with the largest effect, and it is ordinary engineering hygiene wearing a new hat.
• Context engineering, not prompt engineering. Reliability comes from what is in the window, not from clever phrasing. Anthropic's guidance matches what I see in practice: give subagents isolated context and let them return short summaries, compact aggressively, and use git commits and a progress file as checkpoints so a compaction is a save point rather than an amnesia event.
• The spec is the leveraged artifact. When the agent writes the code, the highest-value thing a human produces is the specification: outcomes, scope boundaries, constraints, prior decisions, and — above all — verification criteria. It belongs in the repository next to the code, not in a ticket that rots.
• Optimize for review, not for output. If review is the constraint, then a 400-line agent diff is a failure of task decomposition, not a productivity win. Small diffs, one concern per pull request, agent-written tests reviewed as skeptically as agent-written code. Work nobody can review is not finished work.
• Sandbox, and assume prompt injection. The lethal trifecta is access to private data, exposure to untrusted content, and a way to send data out; an agent with all three is one poisoned issue away from exfiltration. Prompt injection is still OWASP's number one LLM risk and it is architectural, not a bug awaiting a patch — instructions and data arrive in the same token stream. So: scoped short-lived credentials, restricted network egress, and a human in front of anything irreversible.
• Give agents identity, not shared secrets. The Cloud Security Alliance found 68% of organizations cannot reliably tell agent activity apart from human activity. An agent should be a first-class non-human identity — its own principal, short-lived at runtime, with the human preserved as the delegating subject and revocation that actually works. The compliance side is converging on the same shape: the EU AI Act's transparency obligations took effect on 2 August 2026, and satisfying them in practice means logs that bind prompts, tool calls, model versions, and human approvals together.

Where this goes

Longer leashes, run in parallel. Background agents that work in isolated worktrees or microVMs and come back with a pull request are already normal, and the frontier tools run several at once. That turns an engineering question into an organizational one: one human, N agents, each producing work that must be reviewed. The ratio is bounded by verification throughput, not by model quality — which is why I think review tooling, not model choice, is where teams will actually separate over the next two years.

Verification becomes a discipline with a name. Evals are moving into CI the way unit tests moved into CI in the 2000s: multiple trials per scenario, because a single pass hides instability, and drift detection wired back into the pipeline. If the last decade's answer to "how do you know it works" was a test suite, the next decade's answer is a test suite plus an eval suite plus a trace you can replay.

The protocols keep hardening. MCP's 2026 roadmap is transport scalability, agent-to-agent communication, governance, and enterprise readiness — audit trails, SSO, gateway behavior. That is what a technology looks like on its way into banks, healthcare, and public-sector procurement, which in this part of Europe is where a lot of the work is.

The entry path has to be rebuilt. Entry-level hiring sits well below its 2023 peak, and the tasks juniors used to learn on — write the obvious code, cover it with tests — are precisely the ones agents do at cost. I do not read that as a smaller profession. I read it as a broken ladder that someone has to repair, because the skills the market now wants at the bottom are the ones we used to call senior: framing problems, writing specifications, reviewing critically, owning what happens in production.

The bet

If I had to commit to three things: a codebase's value increasingly is its verifiability, so tests, types, observability, and reproducible environments stop being hygiene and start being throughput. Review — not authorship — is where engineering organizations differentiate, and the ones that industrialize it will run agent fleets safely while the others just ship incidents faster. And the job title does not change, but the deliverable does: not code, but a system that keeps producing correct, defensible change at a speed no one can read line by line.

That last part is the actual work, and it is the same work it always was. We just moved up a level of abstraction, and the price of the move is that being wrong now scales as well as being right.

A note on method, since it would be strange to write this any other way: the research for this post was agent-assisted and the site it sits on ships an AGENTS.md telling the next agent how to build it, how to test it, and where not to go. Every number above is linked to its primary source, and I read them before I used them — which is, more or less, the whole argument.

Back to all posts