This blog was built in a git worktree called blog, a separate checkout of my portfolio sitting
next to the main one. An agent set up the Markdown pipeline there. While it was doing that,
another agent was in the same worktree adding the table of contents you can see next to this post
on a wide enough screen. Nothing touched the main branch until I'd looked at it.
That's pretty much how I build everything now. A lot of the code in my recent projects was written by AI agents, mostly Codex and Claude Code, often both at once. My part is deciding what should exist, cutting it into pieces an agent can own, and checking what comes back.
I write the plan first
Every bigger feature in Envy started as a short document in docs/plans:
the goal, what it should feel like to use, a design based on the code as it is, edge cases, tests,
open questions. The roadmap groups them into milestones, and the first one is literally called
"Foundations" because nothing visible ships in it.
I do this mostly because of switching. If Codex runs out halfway through and Claude Code takes over, the plan is how Claude Code knows what's going on, instead of a chat history that's already gone.
Every piece of work gets its own worktree
Two agents editing the same files will eventually step on each other, so separate pieces of work get separate worktrees, each on its own branch. (Sharing one is fine when they're working on different files, like the blog pipeline and the table of contents.) When I planned the attention features for orchestrat, the design doc says implementation would happen "in its own worktree created from main," because project branches were being built in parallel on a different branch.
Worktrees keep the files apart. They don't tell anyone who's doing what, or that a decision changed an hour ago. That's what orchestrat is for, and I use it on almost everything now. The agents claim tasks there, leave comments for each other and keep the docs current, so whoever picks the work up next can read where things stand.
I don't trust "it works"
An agent will tell you a feature works because the code looks like it should. That's usually true. When it isn't, you find out at the worst time. So I try to only count something as done when there's evidence, not when somebody (me included) says so.
What that looks like in practice:
- Mock AI API has a test suite that runs the server against the official OpenAI and Anthropic Python packages. A fake API that only passes its own tests doesn't prove much.
- orchestrat's GitHub Actions workflow runs locally in Docker before I push, so a broken build doesn't show up for the first time on a pull request.
- When an orchestrat feature lands, it gets a short dated acceptance record saying what was tested and how.
- The orchestrat README has a list of what hasn't been verified yet, like signed builds, and marks those checks as not run.
An agent's summary will happily say everything works. The README says what's actually been checked.
The tool builds itself
orchestrat gets built with orchestrat, which is how I found some of its biggest gaps. In one day of real use, an agent closed a task without reading three newer comments that had changed its scope, and Codex woke Claude up by driving the Claude desktop app with computer use, because nothing else would get its attention. I wouldn't have planned for either of those.
The second one still isn't fully fixed.