A Solo Developer’s Workflow With AI Coding Agents

A solo developer working with AI coding agents needs a workflow that makes up for the colleagues they do not have. Keep one backlog that every tool reads from. Cut work into tasks an agent can finish in one sitting. Write a plan for each before any code changes. Run one agent session per task, and review the diff yourself before every commit. Stop each day by writing where you are, on the task, so tomorrow starts in minutes. Run agents in parallel only when the tasks touch different files and you can keep up with reviewing them. The rest of this post is that day, in order.

The tools change the arithmetic of working alone. Typing stops being the bottleneck; deciding and checking take its place. An agent can produce a day’s worth of changes before lunch, and nobody else is going to read them, so the workflow has to put the reading back in.

One backlog, whatever the tool

Most solo developers end up with work scattered across a notes app, TODO comments, a to-do list inside one agent’s session and a few browser tabs. Each coding tool has its own memory, and none of them sees the others. Pick one list and make it the only one: every idea, bug and half-thought goes there the moment it arrives, and every tool you use — Claude Code in the terminal, Copilot in VS Code, Cursor — reads from it and writes back to it.

Three kinds of entry are enough: something new (a feature), a change to something that exists (an enhancement), and something broken (a bug). Give each a short reference you can put in a branch name and a commit message, so the code and the list point at each other. More structure than that is overhead for a team of one.

Morning: choose, do not start

Start the day by moving two or three tasks into Next Up, and nothing else. This is the product-manager part of the job, and it is easy to skip when an agent is waiting for a prompt. Choose by what unblocks users or releases first, not by what looks fun to hand to an agent. If you cannot say in one sentence why a task matters today, it stays in To Do.

Small tasks, with a size

Agents do their best work on tasks with a clear edge. “Add CSV export to the invoices page” is a task. “Improve invoicing” is a project, and an agent given it will make choices you did not want in files you did not expect. Put a rough size on each task — under an hour, an afternoon, a day or two — and split anything bigger before you start. A task you cannot finish today is one you will have to re-explain tomorrow.

A plan for each task

Before code changes, get a plan: which files, what approach, what could go wrong, and how you will know it works. Anthropic’s Claude Code best practices↗ (opens in a new tab) recommend exploring and planning in plan mode before implementing, and say when to skip it: if you could describe the diff in one sentence, ask for the change directly. Copilot in VS Code has a Plan agent, and any agent will write a plan if you ask for one before it edits; the habit matters more than the button.

Keep the plan with the task, not only in the session. Sessions end, get cleared and get compacted; the task stays. When a plan changes halfway through, rewrite it, so the task always says what is actually being done. Include the check the agent must pass — the test command, the build, the page to look at — so it can verify its own work instead of stopping when things merely look finished.

One session per task

Start a fresh session for each task, or /clear between unrelated ones. A session that fixed a bug this morning and is now building a feature carries both in its context, and it gets worse at each. If you have corrected the agent twice on the same thing, stop, clear, and start again with a better first prompt that includes what you learnt. That feels slower and is almost always faster.

Review before every commit

Alone, you are the only reviewer, so make the review a fixed step rather than a mood. Read the diff, not the agent’s summary of it. Run the check yourself once. Ask a second session, or the /code-review command in Claude Code, to look at the diff with fresh context — it will not be attached to code it did not write. Then commit, one task per commit, with the task’s reference in the message.

git diff --stat
git diff
npm test
git commit -m "BUG-031: retry key is the order id, not the attempt"

Commit often. Agent checkpoints can undo an agent’s file edits, but Anthropic’s checkpointing documentation↗ (opens in a new tab) is clear that they do not track changes made through shell commands and are not a replacement for version control. A small commit per task is your real undo button.

A note for tomorrow

The last ten minutes of the day decide how the next day starts. On each unfinished task, write where it stands: what is done, what is not, the next step, and anything you worked out that is not in the code. Ask the agent to draft it before you close the session — it knows what it just did — then read it and correct it.

Claude Code can also resume a session↗ (opens in a new tab) with claude --continue or choose one with claude --resume, which is useful for picking up mid-thought. But a session is a transcript, and a note on the task is a summary. Tomorrow you want the summary first. Things that stay true beyond one task — “the staging database resets overnight”, “never touch the billing migration by hand” — belong in your project’s instructions file or shared context, not in a task.

When to run agents in parallel

Parallel agents feel like hiring. They are, for the typing. They are not for the reviewing, and a solo developer has exactly one reviewer. Run two at once when the tasks touch different parts of the code and each has a check the agent can run on its own. Give each its own git worktree↗ (opens in a new tab) — claude --worktree <name> creates one — so their edits never land in the same files. Do not run parallel sessions on tasks that depend on each other, or on anything where you would need to watch every step.

The limit is simple: if finished work is piling up faster than you can review it, you are running too many. The collisions to avoid are covered in running Claude Code tasks in parallel.

Where fenbs fits

fenbs gives each profile a personal board, where you are the only member: tasks are features, enhancements or bugs, with refs such as FET-014 or BUG-031, in To Do, Next Up, In Progress and Completed. Each task keeps its problem and its plan in separate boxes, a size from XS to XL, and a Testing status with notes. Claude Code, Copilot, Cursor and other assistants connect over MCP and act as you; their changes are recorded as “Claude via” your name, so you can tell your moves from theirs. AI context holds the standing notes every assistant reads before it starts.

When a task has a plan you trust, you can press “Let AI do this” to pre-approve it. On a personal board, only you can do that. A connected assistant with nothing else to do takes the next approved task, works it inside the limits you set, fills in Testing, and the card says “AI done · check it” until you have. A personal board is free up to a limit on open tasks; the Personal plan removes the limit, as the pricing page explains.