How I Build with Three Claude Code Agents at Once

People sometimes picture a solo founder as one person typing very fast. For G8KEPR, it's closer to one person running a small room. There are three Claude Code agents in that room, and my job is mostly deciding what they work on and checking what comes out.

Here's the loop, start to finish.

The flow

1. Plan in Todoist. Everything starts in the G8KEPR project, with its subprojects and their P0 to P4 sections. That's where I decide what matters next. (I wrote about the priority levels and the scorecard in the previous post.)
2. Build a tracker page. The chosen work gets pulled out of Todoist into a single tracker page. Todoist is good at holding a lot of work. The tracker is about this batch, in one place.
3. Have Claude write three DEV briefs. From the tracker, Claude writes three markdown files: DEV1, DEV2 and DEV3. Each is a brief for one developer, describing the work that agent owns.
4. Open three Claude Code CLI windows. One brief per window. DEV1 goes to the first, DEV2 to the second, DEV3 to the third.
5. Let the agents plan and work. Each agent reads its brief, creates its own tasks, and works through them.
6. Coordinate through GitHub. The three agents work in the same codebase, and they coordinate with each other on their GitHub commits so their changes fit together.
7. Supervise until done and tested. I watch, review, and steer. A batch isn't finished when the agents say so. It's finished when it's done and the tests pass.

Or, as a table of who does what:

Step	Who	What comes out
Plan	Me, in Todoist	The next batch of work
Track	Me	A tracker page for that batch
Brief	Claude	DEV1, DEV2, DEV3 markdown briefs
Build	Three Claude Code agents	Tasks, code, tests, commits
Coordinate	The agents, via GitHub	Commits that fit together
Check	Me	Work that's done and tested

Why briefs instead of just talking to it

The briefs are what make the parallel part work.

It's tempting to open a Claude Code window and start typing requests. That's fine for one small change. For three agents at once, it falls apart, because none of them know what the other two were told. A written brief gives each agent a clear, fixed statement of its job, and it gives me something to check the finished work against.

Having Claude write the briefs from the tracker also means the plan gets restated in full before any code is written. If the brief doesn't match what I meant, that's the cheapest possible moment to find out.

Why three

Three is the setup I run. I don't have a benchmark behind it, and I'm not going to invent one. What I'd point out is that the agents parallelize and the supervising doesn't. Every extra window is one more thing for the same one person to watch and check.

What I still do

This is the part I want to be clear about, because "three AI agents built it" can sound like nobody's driving.

• I decide what gets built. The agents never pick the work. It comes from my Todoist plan and my priorities.
• The briefs come from my plan. They're the contract for the batch, and the thing finished work gets checked against.
• I supervise while they work. I'm watching the windows, not wandering off.
• I review and test everything. "Done" means done and tested, and I'm the one who signs off on both.

That last point ties back to the shape of the codebase itself. G8KEPR has roughly 1.39 million lines of tests against about 1.0 million lines of source. When code can be produced faster than one person can read it line by line, the tests are how I hold it to a standard. I wrote more about that in Building a Security Startup by Myself.

Note

This is a workflow for building a product with AI agents, not a product built by AI agents. It's a distinction worth making for anyone deciding whether to trust a security tool.

Where this leaves the series

That's the machinery behind G8KEPR as it stands: one person, a product narrowed to a correlation engine, a license question answered twice, a scorecard to keep it honest, and three agents doing the building while I do the deciding and the checking.