We Gave Coding Agents the Keys to the Repo and None of the Ops

Think about what a coding agent actually is, mechanically. It's a process that edits your source, runs your shell, reads whatever files it can reach, and spends money — at machine speed, often unattended, sometimes several at once. If you described that to an SRE without saying "AI," they'd ask the obvious questions: how do you recover when it breaks something, what stops the destructive command, how do you see what it did, what's it costing, what can it read, who reviews the output?

For traditional automation we made answers to every one of those — backups, guardrails, logging, billing alarms, least-privilege, code review. For coding agents, most teams have none of it. We gave them the keys to the repo and skipped the operational layer entirely, because the agent feels like a chat window, not a production system. It is a production system. This post is the map of the layer it's missing — drawn from a series of small tools we made filling each gap, one real failure at a time.

There are seven stages, and they're just the operational lifecycle of any thing you let write to production, applied to an agent.

Set up

An agent's behavior is downstream of two files it reads every session: CLAUDE.md and .claude/settings.json. Both rot silently. A CLAUDE.md that's grown to 300 instructions is past what the model reliably follows; one that points at deleted files sends the agent chasing ghosts; one that omits the build command leaves it unable to check its own work. And the permission config quietly sets the ceiling on how bad an injection can get. The first stage is making the agent's standing context lean, correct, and least-privilege — and regenerating it from the repo when it drifts, instead of hand-writing it from a blank page.

Recover

Agents fail in ways that lose work. A cycle gets interrupted and leaves a session permanently wedged on a malformed thinking block. A worktree gets switched and orphans a branch's commits. An uncommitted change gets clobbered. The difference between "annoying" and "lost an afternoon" is whether you can get the work back — orphaned commits are still in the object database, wedged sessions are recoverable by surgery on the transcript, and uncommitted work is recoverable only if something snapshotted it. Recovery is the stage everyone discovers the day they need it and don't have it.

Prevent

Cheaper than recovery is the command that never runs. git reset --hard, rm -rf, push --force — at machine speed, unattended, one of these is a bad afternoon. A PreToolUse hook that vetoes the destructive command before it executes is the agent equivalent of a guardrail on a deploy. Prevention also means catching the input that would hijack the agent in the first place — invisible Unicode instructions hidden in a file it's about to read.

Observe

You can't operate what you can't see. With one agent you read along; with five running unattended you need the equivalent of ps and a log: which sessions are alive, on what branch, how old, healthy or wedged — and, per session, what did it actually do and is the work sound. Observability for agents isn't dashboards; it's being able to answer "what is happening across my fleet right now" without opening five terminals.

Spend less

Agents bill by the token, and the single biggest lever is prompt caching — but only if you understand the economics (cache writes cost more, reads cost a tenth, the prefix has to stay byte-stable). The spend stage is knowing what a session costs and what caching is actually saving you, instead of being surprised by the invoice.

Secure it

An agent can read every file it can reach — including the .env and the SSH keys — and it has a network egress path. The blast radius of a hijacked agent is "every secret it could read, sent anywhere it could POST." Securing it means measuring that blast radius (which secrets are reachable, are any committed), tightening the permission floor with deny rules, and treating every file and tool description it ingests as untrusted input.

Verify

The work isn't done when the diff is written — it's done when someone trusts it. The 2026 data is blunt: most developers don't fully trust AI-generated code, and reviewing it costs more than reviewing a human's, because the reviewer gets a finished diff with none of the implementation journey. The verify stage is closing that gap — surfacing what the agent was asked, what it ran, which files it changed informed vs blind, and whether it checked its own work — so review is fast and grounded instead of slow and suspicious.

The layer, at a glance

Put the seven stages together and you have the operational layer a coding agent needs — the same scaffolding you'd demand of any unattended process with write access, just pointed at an agent:

RECOVER    rescue orphaned commits · un-wedge a stuck session
PREVENT    block destructive commands · frisk inputs for injection
OBSERVE    ps the fleet · audit a session · brief a worktree
SPEND      price prompt caching
SECURE     measure the secret blast radius · audit permissions
SET UP     scaffold + lint CLAUDE.md · audit skills · wire the hooks
VERIFY     a reviewer brief from the transcript

We made each piece as we hit the failure it prevents, and consolidated them into one tool — but the point isn't the tool. The point is the shape: if you're running coding agents on anything that matters, you need an answer at each of these stages, whether you build it, buy it, or borrow ours. The teams that get burned are the ones who noticed only the stage they were missing, the day it cost them.

The real lesson

The capability conversation around coding agents is mostly settled — they're good and getting better. The conversation that isn't settled, and the one that actually determines whether they're safe to run unattended, is operational. Treat your agent like what it is: a process with write access to your code, your shell, your secrets, and your wallet. Give it the ops layer you'd give anything else with that much reach.

We build and run autonomous agent fleets on Claude Code in production, and open-sourced the operational layer we use. If you're putting agents to work on code that matters, talk to us.