Blog
Running coding agents safely
Generating a diff is the easy part now. These are notes on the harder part: containing what the model runs, keeping secrets out of its reach, and structuring the work so a result can be checked.
Your tests are a guard, not the goal
We shipped an agent that reported success in four seconds without calling the model once. What went wrong was the definition of done: a green suite is a constraint on the answer, not a description of it.
Read it →We killed our own agents with docker rm -f
A two-minute task kept taking twelve. The container was named after the org and removed as though it belonged to the task, and the lease TTL that recovered it was also the only thing detecting the failure.
Read it →When failing safe fails you
A reviewer returned a list where we expected a string. Every fallback did the safe thing, the rails counted them as real rejections, and the user got a Go type error instead of a code review.
Read it →Best-effort telemetry that was never any effort at all
A stale foreign key meant every telemetry write failed, for as long as the feature had existed. The writes were best-effort by design, so nothing complained, and we signed records attesting to nothing.
Read it →The planner has never seen your repo
Our planner assigned a Rust filename in a Go repository, and the worker spent its whole budget on a position it could not win. Treating a plan as hints rather than instructions, and detecting unwinnable runs before paying for them.
Read it →How to sandbox AI-generated code
A practical threat model for running code a model just wrote: what the sandbox is actually defending against, why egress is the control that matters, and where the common setups leak.
Read it →Running coding agents without giving them your API keys
If an agent can read your credentials, so can the code it writes. How to build an execution boundary where the model never holds a secret, using sealed credentials and a narrow trust surface.
Read it →