In the last post I described how I run a small team of coding agents — roles, reusable skills, gates, short verified loops — and argued the durable value is the process around the model, not the model. Then a new wave of coding agents landed that seems built to test exactly that claim. They don’t just generate faster. They plan and validate as they go, run for long unattended stretches on multi-step, tool-heavy work, and — the part that matters most — independently confirm their own results before declaring a task done. If the agent now does the planning and the checking itself, do you still need the harness you built around it?
I already run some work on a long leash — auto-approve, permissions bypassed, the agent left to grind through a chunk on its own. So this isn’t hypothetical for me. Here’s what I think actually changes, and the one thing that quietly matters more.
The autonomy dial moved — the principles didn’t
What’s genuinely new is that more of the harness has moved inside the model. Planning, step-by-step verification, self-correction over a long run — capabilities I used to build around an agent are increasingly things the agent does on its own. That’s real progress, and it’s tempting to read it as “the scaffolding is obsolete now.”
It isn’t. The scaffolding didn’t disappear; its job changed. When an agent can run for an afternoon unattended, you stop supervising steps and start supervising outcomes. Division of labour, codified standards, real gates, verified loops — every principle from the previous post survives. What moves is the altitude at which you apply them. You manage a longer-leashed agent the way you manage a capable senior who works independently: not by watching every keystroke, but by setting a crisp brief and inspecting the result hard.
The gate moves outward — it doesn’t vanish
Here’s the honest way to think about auto-approve and bypassed permissions: you haven’t removed the gate, you’ve relocated it. A per-action approval gate becomes a structural gate at the boundary — the pull request, the test suite, the required check, the review before merge. That’s a completely reasonable trade. But it’s only reasonable if the structural gate is genuinely strong, because it’s now the only thing between the agent and your main branch.
Where people get burned isn’t autonomy itself — it’s turning on bypass and leaning on weak gates. Auto-approve on a change that’s fully reversible, well-tested, and confined to an isolated branch is fine. Auto-approve on something that can push to production, spend real money, delete data, or touch a system of record is not — no matter how good the agent looks. The mode you run the agent in should be set by the blast radius of what it can do, not by how confident it sounds.
The dial: reversibility × gate strength × containment
If I had to compress “how long a leash should I give?” into one rule, it’s this: autonomy is safe in proportion to reversibility × gate strength × blast-radius containment.
- Reversibility — can a bad result be cleanly undone? Code on a branch, yes. A production migration, a payment, a sent message — no. Irreversible actions stay on a short leash with a human in the loop, always.
- Gate strength — the more you remove the interactive check, the stronger the terminal check has to be: tests that actually assert the new behaviour, a reviewer that blocks, checks that can’t be skipped.
- Containment — an unattended agent should work in isolation (its own branch, worktree, or sandbox) so a runaway can’t corrupt the main line while you’re not looking.
Turn all three up and you can safely hand over a lot. Let any one of them fall to zero and no amount of model capability makes the autonomy safe.
Self-verification is not the same as verification
This is the part I’d underline hardest, because it’s the most seductive of the new capabilities. An agent that checks its own work and only declares “done” when its own checks pass is a real improvement — it kills a lot of sloppy, obviously-broken output. But it is still the agent grading its own homework. Self-verification and independent verification are not the same thing, and the gap between them is exactly where the expensive failures live.
The failure mode you cannot catch from inside the agent is the confident wrong answer — the run that reasoned its way to a plausible, well-tested, entirely mistaken result and then sincerely certified itself complete. The more articulate the agent is about why it’s correct, the more that self-certification can lull you. So the external gate matters more now, not less, and it has to be independent of the thing it’s checking: a behavioural test that fails if you revert the change (proof the check tests reality, not the agent’s story about reality), and a reviewer — increasingly a separate agent with an adversarial brief — that doesn’t share the builder’s blind spots. The rule I keep coming back to: the agent that checks its own work still needs a second set of eyes that don’t share its assumptions.
Your job moves up the stack
When you’re not watching the steps, your leverage shifts to the two ends of the run: the brief going in and the acceptance coming out. You become less of a builder-babysitter and more of a spec-writer and acceptance-tester. That’s not a demotion — it’s where the judgment was always most valuable. Two things get more important as a direct result:
- Skills and playbooks become your steering wheel. When you can’t correct an agent mid-step, the encoded standards it loaded at the start are how you shaped the work. Under autonomy, writing your judgment down once stops being a convenience and becomes the main control surface.
- The reviewer role gets promoted. More unwatched output means more that needs independent checking — a strong argument for making the adversarial reviewer a first-class, separate agent whose only job is to try to prove the work wrong.
Checkpointed autonomy beats a blind sprint
A long autonomous run produces a lot of diff you never saw happen. The way to keep the “short verified loop” honest without babysitting is checkpointed autonomy: let the agent run long, but have it surface at verifiable milestones — tests green, a reviewable sub-change, a stated plan before a risky step — rather than dumping one enormous unwatched leap at the end. You keep the leverage of a long run and the safety of a short loop, because each checkpoint is a real gate, not a status update. Pair that with isolation by default, and an unattended agent becomes something you can trust without hovering.
Bigger engine, better brakes
None of this argues against autonomy. I use it, it’s genuinely faster, and the agents that plan and self-verify are a real step up. The point is narrower and, I think, durable: a more autonomous agent is a bigger engine, and a bigger engine is a reason to invest in better brakes and a better test track — not to take your hands off the wheel. The capabilities moving inside the model don’t retire your harness; they let you move it up a level, from gating steps to gating outcomes, from watching to specifying-and-verifying.
So the answer to “does this change my setup?” is yes — the mechanism of control moves outward and upward. And the answer to “does it change my thinking?” is no. Give agents a process, keep the verification independent of the agent, match the leash to the blast radius. The models will keep getting more autonomous; the discipline that makes that autonomy safe is the part that stays yours.
Follow-up to how I run a small team of coding agents, and a companion to Agentic AI Is Not Just LLMs and Tokens.
Part of the Agentic AI series
- Agents Eat the Stack Top-Down
- The Substrate War
- Buy, Build, or Orchestrate
- Service-as-Software
- The Frontier Labs Are in the Squeezed Middle of Their Own Stack
Companions: Who Advises the Disrupted? · Agentic AI Is Not Just LLMs and Tokens · A Product Playbook for Agentic AI · Why Agentic AI Transformation Is Hard · Give Your Coding Agents a Process · A Longer Leash — you are here.
Part of a personal DIY hobby, tinkered together on weekends. The coding setup here is my own personal practice, built around open-source tooling.
Leave a Reply