A solo developer's workflow with AI agents

A solo developer's workflow with AI agents works best when you deliberately switch between three roles: planner, reviewer and release owner. The agents do much of the implementation, but nobody else will decide what to build, check what was built, or decide what ships. If you blur those roles, you end up approving your own plans without scrutiny and shipping work you only skimmed. The fix is rhythm, not tooling: a weekly planning session, a short daily routine that starts with review rather than new work, and a release decision you make on purpose. This article lays out that rhythm in concrete steps and notes the guardrails that matter most when there is no second pair of eyes. It complements project management around Claude Code and the Codex CLI equivalent, which focus on the agent side.

Three roles, one person

As planner, you decide what the project is for, which tasks matter this week, and what each task must achieve. You write task descriptions an agent can finish and a reviewer can check. See writing tasks agents can finish.

As reviewer, you treat agent output as a proposal. You read the diff, run the checks yourself, and accept, return or decline. The reviewer's loyalty is to the outcome, not to the plan or the agent's effort.

As release owner, you decide when accepted work goes to users. That decision considers things no single task covers: whether the pieces work together, whether documentation is ready, and whether now is a sensible time.

The trap for solo developers is doing all three at once, in the flow of a session. You plan a task, the agent builds it, you glance at it and merge, and you deploy. Each role then gets a fraction of its proper attention. Separating them in time, even by an hour, is the cheapest quality control you have.

The weekly rhythm

Set a fixed slot each week, about an hour, for the planner and release owner roles.

Step 1: Reread the project goal and any decisions recorded since last week.

Step 2: Clear or triage the review queue. Anything older than a few days gets a decision now.

Step 3: Read progress as built versus accepted, not cards closed. See tracking progress honestly.

Step 4: Choose this week's work. Pick a small set of tasks in dependency order, sized to your review capacity rather than to what agents could start. Write or tighten their descriptions and checks.

Step 5: Make release decisions. Is anything accepted ready to ship? If yes, schedule it. If not, write down what is missing.

Step 6: Note what you are deliberately not doing. A short list of declined or deferred items stops them creeping back into daily work.

The output of the session is a short written plan you can glance at each morning.

The daily rhythm

Start each day as the reviewer, not the planner. Look at what is waiting for review first, oldest item first. Review is easier with fresh attention and gets harder as items age against changing code.

Next, check blocked and decision-owed work. A solo project stalls most often on decisions only you can make, such as which library to use or whether a feature is worth finishing. Make one or two of those decisions each morning rather than letting them accumulate.

Only then start new agent work, and only up to your WIP limit. For each task, open the agent with the task description and relevant context, agree the plan before edits on anything non-trivial, and let it run. See planning before agent edits.

End the day with two minutes of notes: what was accepted, what is waiting for review, and anything you decided. Tomorrow's review starts from that note, and next week's planning session uses the accumulated notes as its record.

Guardrails when nobody else reviews

Working alone removes the colleague who would have asked why a test was deleted or why the change touches billing. Replace that colleague with rules you commit to in advance.

Run checks yourself. Do not accept an agent's statement that tests pass; run them on the code you are about to merge. An independent check is the closest thing you have to a second reviewer.

Wait before merging risky changes. For anything touching shared helpers, data, authentication or money, leave the diff overnight and review it again the next morning. The second look catches what the first missed.

Keep scope tight. Ask agents for one change per task. Large mixed diffs are where solo review fails.

Record decisions. Six weeks later, you are a different reviewer with a different memory. A one-line reason for each significant decision is a message to that person.

Keep a decline list. Saying no to work is part of the planner's job, and writing it down stops you relitigating it every week.

QUESTIONS

How should a solo developer review AI agent code without a second reviewer?

Separate building from reviewing in time, run the checks yourself on the exact code you will merge, and leave risky diffs overnight for a second look. Keep each agent task to one change so diffs stay readable. Write down why you accepted anything significant.

How much time should a solo developer spend planning versus coding with agents?

A useful starting point is about an hour of planning each week plus a few minutes each morning to review and decide. With agents doing most implementation, your time shifts toward writing clear tasks and checking results. If review keeps backing up, plan less work rather than reviewing faster.

Should I start my day with new agent tasks or with review?

Start with review. Waiting items go stale as code changes, and fresh attention catches more problems. Clear or triage the oldest items, make any pending decisions, and only then start new agent work up to your WIP limit. Starting with new work lets the review queue grow every day.

RELATED GUIDES

• How to find and organize work across projects
• How to create a project card in BRAIN FLUID Desk
• How to read project progress in BRAIN FLUID Build

RELATED HARNESS PAGES

• Claude Code project management Claude Code project management as a workflow: run Claude from project cards, schedule tasks and review results before you accept them.
• Codex CLI project management Codex CLI project management as a workflow: launch Codex from project cards, schedule explicit tasks and inspect outcomes before accepting.
• WIP limits for AI agent work WIP limits for AI agent work: why agents make starting too easy, and why the limit belongs on review capacity rather than on running sessions.
• human review of agent output Human review of agent output: what to inspect before accepting AI changes, and how recorded outcomes make the review honest.
• How to write a task an AI coding agent can finish How to write a task an AI coding agent can finish: one outcome, a scope, dependencies, completion criteria and the check that proves them.
• Keeping long-running AI coding projects on track Keeping long-running AI coding projects on track: written goals, scheduled re-planning, drift checks between plan and code, and tested backups.