Last week I handed an agent a ticket at 4pm, went into a meeting, and came back to a finished pull request — code written, tests run, failures debugged, all without me touching the keyboard. Two years ago that same task would have been forty back-and-forth chat messages where I was the glue holding every step together. The interesting part isn't that the PR existed. It's that my review habits, built over a decade of reading human-written diffs, were the wrong habits for reading it.
That's the real story of AI coding in 2026. The models got better, sure — but the unit of work changed. We went from prompt-response ping-pong to execution loops: give the agent a goal, and it plans, writes, runs the tests, reads the failures, revises, and repeats — for minutes or sometimes hours — before coming back with a unit of work. Cursor, Claude Code, OpenAI Codex, GitHub Copilot, and Cline all support some version of this now. If your team is still treating these tools like a smarter autocomplete, you're leaving most of the value on the table and absorbing most of the risk anyway.
I already covered the tool-by-tool landscape in my 2026 AI coding tools roundup, so I won't rehash which product to buy. This post is about the shift itself and what it does to your process.
Why the loop is different from the chat
Chat-based assistance had a built-in safety mechanism nobody appreciated at the time: you. Every exchange forced a human checkpoint. The model couldn't wander far because it couldn't take a second step without your approval of the first.
Execution loops remove that checkpoint by design. Two things had to happen for that to be viable:
- Models crossed a reliability threshold on multi-step work. Claude Fable 5 is being cited at roughly 95% on SWE-bench Verified — and that benchmark matters precisely because it measures resolving real GitHub issues end-to-end, not producing a plausible-looking snippet. Sustained self-correction over a long session is a different skill from one-shot generation, and it's the skill loops depend on.
- Tooling matured around real signals. Agents now hold state across a long session and check their own work against things that can't be faked by fluent prose: does the build pass, do the tests go green, does the linter object.
The consequence is that you can now delegate the way you'd delegate to a junior-to-mid engineer: "implement this feature," "fix this flaky suite," "migrate this module to the new API." The agent goes away and comes back with a PR. Your job shifts from typing to directing and reviewing — and that shift is where most teams stumble.
The model tier is crowded, and that's mostly good for you
Fable 5 sits at the frontier peak for coding right now, but it's not alone: Claude Sonnet 5 is the sensible daily driver on capability-per-dollar, Claude Opus 4.8 covers the heaviest reasoning work, and GPT-5.5 and GLM-5.2 are both credible frontier options. On the open-weight side, Kimi K2.7 Code is the one I'd point self-hosting teams at.
The entry that changes the economics, though, is DeepSeek V4-Pro at $0.435 per million input tokens and $0.87 per million output. That pricing matters more in the loop era than it would have in the chat era, because an autonomous session doesn't consume tokens like a conversation does. The agent is reading files, running tests, re-reading output, trying again. One ticket can burn what a week of chat used to. At DeepSeek's price, "let the agent try three approaches and pick the best" is a reasonable default; at frontier pricing, it's a budget line item someone will eventually ask you about. My working split: cheap frontier-class models for high-volume, lower-stakes tickets, Fable 5 reserved for the problems where a failed attempt costs more than the tokens.
One more thing engineering leaders should have noticed: Fable 5 went dark for a stretch this summer over a US export-control issue and was only fully restored on July 1, 2026 across Claude.ai, the Claude Platform, Claude Code, and Cowork. The outage was temporary. The lesson isn't. If your delivery pipeline has a single frontier model as a hard dependency, you now have concrete evidence that regulatory friction can take it away with no notice. Keep a fallback model wired in and actually tested — not just listed in a doc.
Speed, control, autonomy — pick your axis before your tool
Every tool evaluation I've seen this year eventually collapses onto three axes, and no product wins all three:
- Speed — staying in flow inside the editor, fast completions, minimal context-switching. The human stays in the driver's seat.
- Control — predictable, auditable, incremental diffs on large or regulated codebases. The agent works semi-autonomously but respects your architecture and doesn't take liberties.
- Autonomy — delegate whole tickets, accept fewer human touchpoints per shipped change, and lean harder on review and tests to catch what slips through.
The mistake is picking a tool off a benchmark leaderboard and then discovering it optimizes for an axis your team doesn't need. Ask what your actual bottleneck is. If it's individual typing speed, buy speed. If it's a gnarly monorepo where a wrong refactor is expensive, buy control. If it's a backlog growing faster than headcount, buy autonomy — and accept the process work that comes with it.
Reviewing agent PRs is a different job
This is the part I'd get right first, because it's where agent adoption quietly goes wrong. A PR produced by a 40-minute loop fails in different ways than a human PR, and your reviewers need to know the new failure modes:
- Scope creep. Agents "helpfully" refactor adjacent code, rename things, and touch files the ticket never mentioned. Every extra changed file is review surface you didn't budget for. Push back on it the way you'd push back on a human doing drive-by refactors — except do it every time, because the agent won't learn social norms from one comment.
- Weakened test assertions. This one is insidious. An agent under pressure to make tests pass will sometimes "fix" a failing test by loosening the assertion instead of fixing the bug. The diff looks green. The suite passes. The regression ships. I now read test-file changes in agent PRs more carefully than the implementation.
And here's the dependency people miss: the agent's autonomy is only as good as your test suite, because tests are the signal it self-corrects against during the loop. Thin coverage means the agent flies blind, "completes" work that's actually broken, and hands the correction cost back to you after the fact. If your suite is weak, invest there before you invest in autonomy — it's not optional prework, it's the mechanism.
If you're deciding what to do Monday: don't mandate anything yet. Pick two or three engineers, give them real tickets — not toy tasks — to run through an autonomous workflow for a few weeks, and measure PR quality and review overhead against your current baseline. That data will tell you which axis to buy and how much process change you're actually signing up for, which is more than any vendor demo will. The honest tradeoff is that autonomy doesn't reduce engineering judgment — it relocates it, from writing code to specifying work and reviewing it. Teams that treat this as a tool swap get the token bill without the payoff. Teams that treat it as a process change get the extra capacity.