Parallel Agentic Engineering: Stop Running Just One Agent
Run multiple coding agents in parallel. Once you can give an agent a task and trust yourself to evaluate the result, making that workflow concurrent is one of the most useful things you can spend your engineering time on. I call this parallel agentic engineering. This past Sunday, after building a workflow around it, my daily commit count more than doubled relative to the preceding workweek.
I already argued that you should stop writing code, then described how I set a goal and let an agent work. Parallel agentic engineering takes that further. An agent can be implementing one issue while I specify another, review a third, or get a fourth ready to merge. There is no reason every task has to wait for the previous conversation to finish.
Stop waiting
Running one agent leaves a surprising amount of time unused. You explain a problem. It reads files, thinks, edits, runs tests, and thinks again. You watch. Sometimes you interrupt because it is going wrong. Often you are simply waiting for work you already know how to evaluate. During that interval, another agent could be solving another problem. The first improvement is learning to notice that waiting time and give it somewhere useful to go.
Parallel work requires independent tasks. Two agents changing the same interface under different assumptions can create more work than they finish. Give one a bounded onboarding change and another a release packaging problem, with clear verification criteria for each. My issues and experiments records give each task somewhere to keep its goal, evidence, and unresolved questions. That written context makes switching between agents manageable.
Give every task a workspace
Separate Git worktrees make parallel agents much easier to manage. Each task gets a branch and a working directory: a little branch tree. Agents can edit and commit in their own checkouts while I move between them. On Saturday I built private automation around creating, navigating, and integrating these branch trees. The useful idea is repeatable workspace setup. Creating another place for an agent to work should be cheap enough that you actually do it.
Keeping parallel tasks moving also means preserving their context. Which issue is this checkout working on? What did the agent just verify? What needs my decision? I added explicit current-issue tracking because I kept losing that thread when switching tasks. Integration needed the same attention: bring main into a branch, review the result, then merge completed work back. Unrelated uncommitted changes elsewhere should not stop the entire operation. Conflicting changes still need resolution.
Make parallel work cheap
Parallel agents also need usable account and session management. Named profiles give my agent launchers separate application homes, so I can keep logins and session state organized while using multiple subscriptions. More subscriptions can expand the capacity available to the workflow; a profile itself does not create an account or make its allowance infinite. The practical objective is having enough capacity that I can keep useful work running while I direct it.
Small delays become conspicuous when you run agents in parallel. A branch status command that crawls through build caches interrupts every switch. A merge that unexpectedly changes your current directory makes you recover your bearings. I spent part of the weekend removing those interruptions. Improving the path from finished task to reviewed merge helps every agent I run afterward. This is engineering effort with a repeated payoff.
175 commits
On Sunday, September 13, I made 175 commits in the Astrohacker repository. The preceding Monday through Friday averaged 67.2 commits per day. That is about 2.6 times the average, after putting this parallel workflow into use. Removing merge commits barely changes the comparison: 170 versus 67 per day. Those are Chicago calendar days, counting history reachable from main.
The parallel workload included EarthBucks onboarding, NuTorch release work, and website motion controls across the Astrohacker projects. The count includes plans, verification records, fixes, and bookkeeping; it does not mean 175 features or prove a controlled productivity gain. But it gives me a concrete baseline for improving this workflow. I am convinced I can go substantially beyond doubling.
Find your limit
Try parallel agentic engineering against your own baseline. Start another independent task while the first agent works. Review the diffs, run the relevant checks, and integrate completed changes. Count commits consistently, but also look at what they accomplished. Splitting one change into ten commits teaches you nothing about your capacity. Finishing more useful work while maintaining your review standards does.
As you add parallel work, pay attention to what starts holding it up. Perhaps you cannot specify tasks fast enough. Perhaps review piles up, builds compete for memory, or integration becomes painful. That is your next engineering problem. Improve it, then try again. How many commits can you make in a day with parallel agentic engineering?
Go parallel.