I have been freelancing for more than a decade, and almost all of that time I have built software alone. That has not changed. What changed is that solo development stopped feeling solo.
The shift was not “I found a better model.” It was giving the AI a role instead of a task list. Producer, Director, Assistant Director, Engineer, Tester, Designer, Document Owner. Same tools, split responsibilities.
Originally published in Japanese on May 23, 2026. This English version was written in September 2026.
That one change did more for my output than any model upgrade. When everything goes into one conversation, the conversation drifts: you start discussing scope and end up three levels deep in an implementation detail, with a spec decision quietly made along the way. Roles stop that.
This is about the setup, not the product
I am not going to describe the service I am currently building — no industry, no client, no screen URLs, no data model, no API surface, no feature names. That is not the interesting part.
The interesting part is how you keep a one-person project from being driven by conversational momentum. How you keep specification, implementation, verification, documentation, and the release decision as separate steps when there is nobody else in the room to enforce the separation.
What I do now is closer to “run development as an AI team” than “have an AI do the development.” The gap between those two is larger than it sounds.
A general-purpose assistant crosses its own wires
An AI can discuss direction, write code, review a diff, propose test cases, and tidy documentation. All of that is real. The failure mode is putting all of it into a single thread.
What that looks like in practice:
- You open with strategy and end up editing a function signature, without having closed the strategy question
- You are mid-implementation and a spec change gets decided implicitly, by the model, in passing
- You ask for test coverage and get new features invented alongside it
- You ask for a doc update and the model drags back an assumption you abandoned two days ago
None of those are model failures exactly. They are what happens when the request has no boundary. So I stopped saying “handle this” and started saying “in this role, within this scope, done when this is true.”
Claude sits upstream, as Producer
I use Claude mostly in a Producer role. Not because it ranks above Codex — because of where in the work it fits.
Claude gets the vague stage. What are we building. Why now. What is in scope this round. What is explicitly not. Who it matters to, and for what. This is a long, unstructured conversation, and deliberately so: the large context window and the willingness to stay abstract are exactly what that stage needs.
The rule at this stage is that no code gets touched. Adding a feature is easy; deciding whether it should exist in this iteration, whether it breaks an existing flow, whether it holds up as a complete user action, and whether I will be able to explain it later — that is the work. Once those are settled, the output is something a Director or Engineer can pick up.
Claude as Producer owns the “why” and the “how far.”
Codex runs the execution roles
Codex carries the delivery side, switching roles per task rather than per tool.
- Director — fixes purpose, scope, in/out, and completion criteria; writes the handoff; reviews what comes back; decides whether it can close
- Assistant Director — takes short requests, gathers what is missing, summarizes, drafts handoffs, routes work
- Engineer — implements, builds, verifies, organizes the diff
- Tester — sets expected values, runs Playwright or manual checks, compares expected against actual
- Designer — screen structure, information hierarchy, visual priority, UI direction
- Document Owner — decides whether a change needs to reach human-facing documentation
The constraint that makes this work is negative, not positive. The Engineer does not make final spec decisions. The Tester does not add features. The Designer does not implement. The Document Owner does not change code. Same model, different permissions.
Roles are a division of attention, not a headcount
“AI team” sounds like running many agents in parallel. That is not the point. You can get most of the benefit from one model, as long as each invocation has one job.
| Role | What it is looking at |
|---|---|
| Producer | Purpose, background, business meaning |
| Director | Scope, decisions, handoffs, review, close |
| Assistant Director | Organizing, summarizing, routing, keeping things moving |
| Engineer | Implementation, build, verification, the diff |
| Tester | Expected vs actual, operation flow, regressions |
| Designer | Information design, visual priority, UI direction |
| Document Owner | Human-facing docs, whether an update is needed, what to publish |
Someone thinks. Someone builds. Someone verifies. Someone records. Someone closes. I have not added people; I have separated concerns.
The handoff is the interface
Once roles exist, the handoff document becomes the thing that actually matters. Throwing “do this” at a role produces the same mess as having no roles at all.
A handoff to the Engineer states the branch, the worktree, the HEAD it assumes, the goal, what is in scope, what is out of scope, the completion criteria, which documents to read first, and what to report on finish.
A handoff to the Tester states expected values, the URL and port to check, startup preconditions, the operations to walk through, and the report format. To the Designer: this round’s target area, and the shared elements that must not change. To the Document Owner: which change affects human-facing docs, and which document it belongs in.
The rule I hold to is that a new thread must be able to start from the handoff alone. No “as we discussed.” I encode the recurring shapes as reusable skills so the vocabulary stays consistent between threads.
The side effect I did not expect: it drastically reduced how much I have to keep in my own head.
Docs are the workspace, not the minutes
Conversations scroll away. In the moment everything is clear; the next day, in a different thread, under a different role, it is not. Context budgets have limits, and re-explaining is its own kind of friction.
So specification, open questions, decisions, the current active task, and task history live in documents. Not tidy minutes written afterwards — the working record of truth. What is the current task. What assumptions are fixed this round. Which old assumptions are explicitly retired. What is in and out. What has to be verified before it can close.
Then the next AI reads the document instead of recalling the conversation. That single move is what made the setup stable.
Writing documents is work, so the AI writes them too. The Director maintains the document; Designer, Engineer, and Tester work against it; the Director folds their reports back in. The document is what keeps the team pointed the same direction.
Write “not doing” next to “doing”
This is the habit I would keep if I had to drop everything else: every scope statement carries an explicit out-of-scope list.
AI helpfully expands scope. It is usually well-intentioned. In development it is dangerous. So I name the shared components not to touch, the flows not to change, the spec changes not to make, the retired assumptions not to revive, the things not being verified this round.
“This far” is not enough on its own. You also need “and no further.” Human teams need this too — with AI you need it more, because AI is fast, including in directions you did not want.
Implementation finishing is not the finish
I used to relax when the build passed. It works, it compiles, good enough.
Now the Engineer finishing hands off to the Tester, and the Tester is not asking “does the screen render.” It asks: what was the expected value, what was the actual value, do they match, does this hold up as a complete user action, does anything stall midway, does an unrelated screen flash for a frame, can the user get back to the normal path.
A screen that works in isolation but traps the user in a flow is not OK. A save that succeeds but leaves no route back to the main path is not OK. The Director takes the Tester’s result and decides whether it closes. Splitting those three roles is what stopped things slipping through after implementation.
Designer and Document Owner settle the project down
The Designer role is not decoration. It is deciding what information gets emphasis, what gets suppressed, whether the existing tone survives, and whether shared elements that should be untouched have been touched. Establishing UI direction before implementation removes a lot of thrash.
The Document Owner asks a narrower question: does this change need to reach human-facing documentation? Not everything does. Changes affecting how something is explained, the release decision, or a user’s understanding do. Pure internal refactors usually do not. Having someone make that call is what keeps the project permanently in an explainable state, rather than in a “shipped, will document later” state.
Claude and Codex split by role, not by rank
My split is Claude for the upstream — planning, background, direction, open questions, structuring a decision — and Codex for delivery: Director, Engineer, Tester, Document Owner.
It is not a hierarchy. Some tasks I plan with Codex directly. Claude also serves as the third-party reviewer after work lands, precisely because it was not the one that wrote it.
The useful question turned out not to be “which AI is better at this,” but “which role does this moment need.” Ask it in that order and tool choice mostly answers itself.
The human role shrinks in volume and grows in weight
“AI team” sounds like the human matters less. My experience is the opposite in the part that counts.
Hands-on volume is down — research, implementation, testing, summarizing, documentation all have somewhere to go. Judgment is up. What are we building. Why now. What is in scope. What are we not doing. Which report do I accept. Where do I close.
Those stay with me, and they get harder, because vague input produces vague progress at high speed. So: write the goal, write the scope, write the exclusions, write the completion criteria, read the verification result, send it back when it does not hold.
An AI team is not a structure for making the human unnecessary. It is a structure for making the human’s time go into judgment.
Still unfinished, and still better
The honest problems: handoffs get too long. Over-splitting roles adds weight instead of removing it. Writing full preconditions for a two-line fix is overkill. And an AI’s own verification result is not always something to take at face value.
Even so, the direction holds. There is someone to think direction with, someone to implement, someone to verify, someone watching the documentation, someone assembling the evidence for closing. All of them are AI. But with roles split, handoffs written, docs as the source of truth, verification real, and a close decision at the end, it operates a lot like a team.
What I am building is not full automation. It is a way to run solo development as a team of one plus roles — and the loneliness of building alone is mostly gone.
References
- Claude Code overview | Claude Docs
- Command line options | Codex CLI reference
- Subagents | Codex documentation — the official mechanism for running specialized agents in parallel, which is a different thing from the persistent role threads described here
- Playwright — what the Tester role drives for browser checks