In February, the author made a rule: no more writing code by hand. Six months later he’d shipped more than any stretch of his career, failed more too, and watched the tool that ran it all collapse under its own weight. This is the field report — and it’s one of the more honest first-person accounts of agent-driven development out there.

The rule

Before AI, his superpower was the system living in his head: exact lines, strange decisions, unwritten assumptions. The cost was reading every change to keep that mental model current — and the typing. Copilot autocomplete helped, Cursor’s tab-complete helped more, Claude Code changed a ton, but agents were wrong a lot, so he read every change to match it against the desired state in his head. Then, early this year, the models got good almost at once — GPT-5.3 and Opus 4.6 handled larger changes with much less steering.

So the February rule: if an agent got stuck, he wasn’t allowed to finish the code himself. He had to figure out what the agent was missing and fix that instead. He got good at coding by reps — write, run, fail, fix — and the rule forced him to get those reps at the agent level. He broke it once, for three minutes, and it felt great right up until he realized how much typing was involved.

One agent became a dozen

Waiting for an agent to finish, he spun up another. Then another. ADHD, he says — just filling the time. The first parallel setup was chaos: agents sharing git state, installing dependencies, fighting over ports, leaving processes running, and everyone waiting on the longest-running agent. He’d started more agents to avoid waiting and created a new way to wait.

The escalation: worktrees solved the Git collisions but agents still shared databases, ports, and processes; AGENTS.md patches (“use a random port, create an ephemeral database”) just burned context; containers got closer but the boundary was leaky and the laptop had to stay awake. Then he joined exe.dev — Linux VMs that come up in seconds — and each task got its own machine. He closed his laptop and the work kept going. A startup script, written by Claude and iterated in a loop until a fresh VM reliably became a working dev environment, did the provisioning.

That created a new problem: a dozen tmux windows. He built botd — one place to manage every agent box from phone or laptop: provision and deprovision, inspect conversations, send follow-ups, review diffs. Three rules: it had to run somewhere other than his laptop, mobile had to be first-class, and every conversation had to be preserved. Trust model: YOLO mode inside disposable VMs (a trashed box costs nothing but the VM), read-only access to anything external, and credentials injected via a proxy so secrets never entered the VM at all.

Validation and review

At peak, about twenty VMs. Agents could run tests, trigger the full CI suite, start the app, drive it through a browser, and send screenshots — but the agent was still grading its own work. It could build the wrong thing, write tests for the wrong thing, and confidently report everything passed. Being able to open the running environment and drive the UI yourself was the check that mattered.

Reviewing was the other bottleneck. Hand-written code was understood by the time it reached review — the decisions were made along the way. With agents, the whole diff appeared at once, unfamiliar, and when several finished at once you had a queue of complete changes to load into your head before merging any. Other agents reviewing the code worked surprisingly well and caught real bugs — but he still couldn’t merge on their say-so. He had to understand the change. He’s responsible for what merges.

Sometimes he understood it — green tests, good screenshots, correct schema, all review agents approving — and threw it away anyway. Maybe nobody needed it; maybe it introduced a second way to do something; maybe a small convenience added complexity the system would carry for years. The tools could tell him the change worked. They couldn’t tell him whether it was worth adding. Shipping got easy; deciding what to ship got important. Unshipping is so much harder — Hyrum’s Law means someone depends on every observable behavior.

Not all agents write code

An agent is a model in a loop with tools; the tools decide what an agent can be. A development agent needs a full computer. Three of the most useful ones ship nothing:

  • Investigation — “Customer reports: <their report, verbatim>. Please figure out what happened using the ClickHouse logs.” Verbatim matters: if you summarize, the agent inherits your interpretation and your blind spots. Then the decision is his, made from evidence.
  • Attack — a red-team agent with one instruction, try to break into our systems. It found open network paths they thought were restricted and showed exactly how they were reachable; patched before anyone outside noticed.
  • Watch — Athena babysits every deployment: reads the diff, metrics, and logs, and during one rollout correctly identified an infrastructure problem (not the new code) and kept deploying to the other machines instead of blindly halting.

Engineer the system before the agent writes the code

An agent can now design and build an entire system almost instantly — and if you just accept it, you’ve inherited a legacy codebase that happens to be brand new. That’s vibe coding. Agentic engineering is working with the agent on the system first — architecture, interfaces, constraints, tradeoffs — so when the code arrives you understand what you’re about to own. Everything known about running software teams is amplified: behavior, contract, and property tests matter more than unit tests that mirror the implementation; migrations and state are the part that’s still hard; agents copy what they find, so bad patterns amplify faster than good ones; the marginal cost of bespoke tools has collapsed, so write your own linter; and peer code review is dead — the review that matters happens in the design discussion and contracts, before the diff exists.

The Shelley example: he wanted its tools to be asynchronous. The first design put the burden on the agent to decide which commands ran in the background — a pile of edge cases. Vibe coding would have accepted it. Instead, discussion found a design that removed most of the edge cases entirely: every command follows the same path and auto-backgrounds after sixty seconds. He only found this example by asking an agent to search across all his conversations — which is why preserving every conversation mattered. The history wasn’t an archive; it was a queryable record of how he worked.

botd died; the data didn’t

botd crumbled this month. It was entirely vibe coded — he never read a line of its code — and at its core was a genuinely hard problem: driving every model family through its own native harness (Claude Code, Codex, the rest) while papering over their differences. That is exactly the kind of problem where architecture matters, and he wasn’t paying attention. It became the thing he described earlier: a brand-new legacy codebase inherited without understanding the decisions inside it. But the twist — the conversation search was never sent to botd. The history lived in SQLite, so he pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.

The honest accounting: six months in, he’s lost some of that line-by-line depth. But he can ask agents detailed questions and dig into whatever he needs. Work no longer waits for him to finish one thing before starting another. He shipped more, and failed more — abandoned VMs, dead-end designs, a collapsed tool — and the failures were cheap, which is most of how he learned what works. The loop that taught him to code, moved up a level: he used to iterate on code; now he iterates on prompts, designs, whole features. “I stopped writing code by hand. I didn’t stop engineering.”