The doc-intel demo on this site went from a written spec on May 29, 2026 to a production deploy on Fly.io on June 27: 74 commits in 29 days, one person. Most of that code was written by coding agents, Claude Code specifically. I made the architecture decisions and reviewed every change, and when the system breaks in production it is my pager that goes off. The result held up well enough to publish: the demo's first week in production is a public incident log, five human interventions and all.
ByteByteGo published a conceptual survey of agentic coding tools recently, and as a map of the space it is fine. A map is a different artifact from a working setup. This post is the setup behind a system that actually shipped: the loop I run, and the guardrails that made agent-written code safe to deploy.
The loop, compressed: a written spec, an implementation plan cut into small tasks, a fresh agent per task, test-driven development on behavior changes, two review passes, and an eval gate in CI. The ordering carries most of the value, so I will walk it in order.
The spec exists before any agent runs
Nothing reaches an agent until the spec is written and reviewed. The demo's spec landed on May 29 and went through four to five review rounds before any code existed, which is my standard for anything non-trivial. A spec problem caught at review costs a paragraph edit. The same problem caught after five agents have built on top of it costs a rewrite, and the agents will have built on top of it quickly and without complaint, which is exactly the danger.
The spec then becomes an implementation plan decomposed into small tasks. Small is load-bearing. A task has to fit comfortably inside one agent session, and it needs a checkable done condition, such as a failing test that now passes or an endpoint that returns the documented shape. Where tasks can run in parallel, they get disjoint file ownership, so two agents landing code at the same time cannot generate a merge conflict. I think of these as landing lanes: the boundaries are what keep the planes apart.
A fresh agent per task, with skills loaded
Each task gets a brand-new agent carrying the task description, the relevant slice of the spec, the files it owns, and nothing else. The tempting alternative, one long-running session that "knows the project," degrades in a predictable way, because context windows are caches: evicted on restart and polluted long before that. Task decomposition is where the real prompt engineering lives. The plan gets the cleverness; the prompts stay boring.
Before it starts, the agent loads process expertise from a library of roughly 85 SKILL.md files: how to run TDD, how to prepare a pull request, and so on. Every skill carries a semver version and an ADOPT / FORK / BUILD classification, and CI fails when a pinned version goes stale. The consequence is that the workflow itself is versioned like code. When agent behavior drifts, I can diff the process the agent loaded the same way I would diff the source.
TDD, then two review passes
Any task that changes behavior runs test-first, enforced: write the failing test, confirm it fails for the expected reason, implement the smallest change that passes, confirm it passes. With agents, TDD does a second job beyond design pressure. The test pins the behavior the spec asked for, and it is the one artifact the agent cannot talk its way around. Agents report success in fluent, confident prose; a red test does not negotiate.
Every change then takes two review passes. The first checks spec compliance: is this what the plan said to build, nothing more, nothing less. The second checks code quality: is this something I am willing to maintain. The implementer agent fixes findings between rounds. Splitting the passes matters, because a reviewer checking everything at once anchors on style and misses scope creep, and scope creep is the signature agent failure: an abstraction nobody asked for, built beautifully.
The eval gate blocks the merge
Tests cover the deterministic parts of the system. The demo has a model in the middle of it, and for that class of regression the merge gate is an eval suite that runs on every pull request and posts the quality delta as a PR comment. When the number drops, the merge is blocked. Retrieval is scored separately from generation quality: recall@k sits at 0.93 on the current backend, with faithfulness at 0.97 and citation correctness at 0.95 on the generation side. The full machinery is in evals as CI.
The property that matters for this workflow is who the gate refuses to trust. It does not trust me or the agent, and it does not care how confident the pull request description sounds. Model-behavior regressions block merges the same way failing tests do, and that is what makes "most code written by agents" compatible with a production deploy one person answers for.
Where it still hurts
Agents overclaim, confidently. "All tests pass" from an agent means, at best, "the tests I remembered to run pass." Every claim of done needs verification against fresh command output, and that verification is human time. My throughput ceiling is how much agent output I can honestly review in a day; the small-task discipline upstream exists mostly to keep each individual review cheap.
Context quality decays before context length runs out. An agent deep in a long session starts contradicting its own earlier decisions, which is another argument for fresh agents over heroic prompts stretched across a mega-session. If a workflow depends on one agent holding three days of state, the workflow is the bug.
And the gates are load-bearing. Agent-written code without TDD and eval gates is liability generation: plausible-looking diffs arriving faster than any reviewer can honestly absorb. The volume only becomes an asset when every diff has to survive the full gauntlet before merge.
The same policy runs on this blog, for what it is worth: drafts are agent-written, and every factual claim gets a human fact-check pass before publish. It would be odd to hold the code to a higher standard than the claims about it.
What the human is for
Strip away the tooling and the human job is short to state. I decide what gets built, and I decide what is acceptable to merge. The consequences stay with me too: the pager, and the credibility attached to every number this site publishes. The agents took the typing. The accountability stayed here, and most of the machinery above exists to keep that accountability real at agent speed.
If you would rather learn this loop hands-on than reconstruct it from blog posts, the DIY course teaches exactly this workflow on a system you build yourself.
The output is public either way: the systems this workflow produced are summarized in the operator brief, and the one it shipped in June is answering questions right now at the live demo.