The Build Loop and Parallelism - Playbook

The loop

Here is the rhythm, and it almost never changes:

A real user names a real problem. "I keep forgetting which customers I quoted last week." "I cannot take photos and notes at the same time on a job site."
I write a short plan in plain English and point the AI at the relevant files.
It reads the codebase, writes the code, runs the type-check, and opens a pull request.
I review the diff, open the preview, and use the change as a real user.
I ask for revisions, or I merge.

A small feature is under two hours, start to finish. A meaningful one is under a day. A normal day is three to ten of these merged to production. There is no standup, no sprint, no staging environment drifting away from production. The whole thing is a tight loop between a person with taste and a machine with patience.

Why every turn stays small

The single most important property of this loop is that each change is small enough to hold in my head. That is not a style preference. It is what makes every other safeguard work.

A small diff can actually be reviewed. A thousand-line diff gets rubber-stamped, and rubber-stamping is how the bugs get in.
A small change can actually be smoke-tested in a couple of minutes.
The cost of being wrong is reverting one commit, which takes thirty seconds, instead of untangling a week of intertwined work.

Ship small and reversible, and you can move fast precisely because no single mistake is expensive. Ship big, and every merge is a gamble.

Briefing is the work

Notice where my time goes in that loop. Almost none of it is typing code. It is step 2 (writing a clear enough plan that the output solves the real problem) and step 4 (reviewing and using the result). The clearer the brief and the more context I load up front (which files, which conventions, which trade-offs are off the table), the less churn there is on the back end. Most of the time the AI appears to save gets reinvested in writing better briefs. That is the trade, and it is a good one.

There is a compounding effect worth knowing about. Early in this project, the AI generated big features that needed heavy debugging. After a few weeks, once the codebase had enough patterns (a standard shape for a server action, for plan gating, for the auth flow), the AI could pattern-match against the existing code instead of inventing, and the loop got noticeably faster and cleaner. Consistency compounds. The more uniform your codebase, the better your AI performs in it.

Parallelism: running more than one loop at once

The loop above is one agent at a time. The accelerator is running several at once, each in its own git worktree on its own branch, so they do not collide. A worktree is just a second checkout of the same repository in a separate folder, sharing one underlying git history. Modern AI coding tools can spin up an isolated worktree for a sub-task automatically, or run an agent in its own cloud environment entirely.

Done well, this is how one person ships like a team: three agents build three independent features while you review the first. Done carelessly, it is a swamp. On this project the careless version showed up as: roughly seventy worktrees piling into a "tarpit," edits landing in the wrong folder, an agent missing its own per-folder environment file, two sessions doing the same work because neither checked, and once, a session closing another session's pull request by mistake.

The discipline that keeps parallelism an asset:

One worktree per task, clearly named. When work is genuinely independent, parallelize. For sequential work, a plain branch is simpler and has fewer footguns.
Use real isolation for parallel agents, so two of them cannot write to the same working folder.
Check what already shipped before you start. A quick look at the latest history on the main branch prevents redoing work a parallel session already merged. Pull request numbers are not even stable across parallel sessions, so do not trust them as identifiers.
Know each branch's deploy target. Feature branches here deploy to a separate preview project, not production. If you do not know where a branch deploys, you will "verify" on the wrong URL.

Sub-agents: delegate the fan-out, keep the judgment

A related move: when a task is "read forty files and extract the important parts," hand it to a sub-agent and let it return a digest, instead of pulling all forty files into your own working memory. We did exactly that to build this course: a sub-agent read forty session logs and returned the decisions and scars, and then I curated. The split is the lesson. Delegate the breadth; keep the taste. And launch agents one at a time, because batching their launch means an interruption cancels the whole batch.

The multimodal shortcut in the loop

When the problem is visual, do not describe it, show it. Drop a screenshot into the loop. On this project a column was clipping a dollar value on the quote builder; a single screenshot of the broken layout was enough to diagnose it and ship the fix, where a paragraph of description would have taken three rounds. The tool has eyes. Use them. (More on this in the verification module.)

The honest limit

The bottleneck in this whole system is not the AI's writing speed. It is your reviewing speed. Every parallel agent you add increases throughput and increases the amount you have to review and integrate. Past the point where you can actually review what comes back, parallelism stops being speed and becomes a backlog of unvetted risk. The right number of simultaneous agents is the number whose output you can genuinely review and smoke-test, and not one more. The accelerator and the brake are both you.

Exercise

Run the loop once, end to end, on something tiny. Brief it in plain English, review the diff, open the preview and use it as a real user, then merge. Notice how much of your time was briefing and reviewing versus coding.
Then try one parallel worktree. Start a second independent task in its own checkout. Feel the coordination cost (the second environment file, the "which folder am I in," the merge at the end). Decide for yourself where your personal limit is.
The next time something looks wrong, screenshot it instead of describing it, and notice how much faster the diagnosis goes.