AI coding environments have evolved rapidly, from simple chat-based prompting, to retrieval-augmented generation (RAG), and more recently to autonomous agents. Each step has improved output quality, but also introduced new workflow patterns. Agent-based coding, for instance, often means longer execution cycles: the agent works autonomously for a while before returning for human feedback. to autonomous agents This shift resembles the transition from a synchronous for-loop to an asynchronous, event-driven architecture. Instead of one AI working step-by-step, we now have multiple parallel coding agents operating independently and reporting back—bringing both speed and complexity. Pro tip: this post is the result of lots of research and therefore link heavy, do explore them as they contain many extra gems.. Why Parallelize? (Speed & Exploration) Speed The first reason is that we want to speed up the coding process. The idea is that we can complete multiple tasks in parallel and then combine the results. This is pretty much how human product management planning works: we have different developers work next to each other on different features and merge them back in. complete multiple tasks Exploration But speed isn’t the only reason. Another benefit, perhaps even more important, is the ability to explore divergent ideas in parallel. As humans we give multiple people or teams the same task and have them use different strategies. This helps in the innovation process and also in a better understanding of the solution space. One of the first appearances of “choice of options” was in gpt-engineer (now Lovable) generating multiple generations of UIs. We captured this pattern in the 3rd AI native dev pattern: “From delivery to discovery”, where we explain that delivery is automated anyhow, so we can focus on discovering new ideas.. How do we structure this new workflow? From Specification to Subtasks (Planning) To parallelize, we need to break large specs into atomic tasks that agents can work on independently. This is where reasoning agents act as architects and planners. We are seeing task management appear as a core function inside of code generation tools: Aider introduced Architect modeTask-master helps breaking down your PRDClaude Code has a Planning modeRoocode’s orchestrator mode Aider introduced Architect mode Aider introduced Architect mode Task-master helps breaking down your PRD Task-master helps breaking down your PRD Claude Code has a Planning mode Claude Code has a Planning mode Roocode’s orchestrator mode Roocode’s orchestrator mode Source: AI Code King Youtube video - Claude Code / OpenCode + T-Mux + Worktrees: This SELF-SPAWNING AI Coder TEAM is INSANITY! Source: Source: AI Code King Youtube video - Claude Code / OpenCode + T-Mux + Worktrees: This SELF-SPAWNING AI Coder TEAM is INSANITY! Review & Merge Strategy Once the build and code tasks are done, our human job begins again. We now have multiple task results that need to be reviewed! People are trying to figure out how this changes the code review process: How do we navigate all the parallel implementations?Provide access to all running app instances?Help with the comparison of the outputs for the same task? How do we navigate all the parallel implementations? Provide access to all running app instances? Help with the comparison of the outputs for the same task? UI example of Async Code Agent UI example of Async Code Agent So we end somewhere with a mix of tabs and code diffs, with some using color coding to label different environments. color coding A few emerging tools are attempting to manage this workflow complexity: Async Code Agent, Crystal, CCManager, SplitMind, Claude squad, Claude Code crew with their own new UI workflow. Async Code Agent Crystal CCManager SplitMind Claude squad Claude Code crew Another approach is opening the IDE from the terminal loop when it needs more feedback like the VSCode plugin for Claude code. VSCode plugin for Claude code Additionally, this begs the question: can we automate the review too? I haven’t seen any specific implementations on this that were integrated, but I can imagine all the CI/CD review tools could help us here too. From AI engineering we can definitely borrow the LLM as a judge concept. Now next to the specification for building the app, we need to specify examples and guidelines to review the application and changes. LLM as a judge Risk and Trust Boundaries Let’s be honest—parallel agents aren’t without danger: we all know that LLMs and agents can get things wrong and, given the wrong access, can do bad things such as removing everything on your computer. Yet, if we want to delegate the tasks we are “forced” to trust and just accept that agents have a lot more access. Otherwise we always have to be in the loop to approve the steps of the agents. That’s why you see people enable dangerous-settings and YOLO mode. This also makes it clear that we have to reduce the possible blast radius of this. can do bad things such as removing everything on your computer Agent Workspaces: isolation spectrum A human developer typically picks up tasks and code in their own environment. For agents, that means we have to give them their own development environment too. Let’s walk through the spectrum of workspace isolation strategies: from chaotic to cloud-native. Workspace StrategyIsolationMergeability	UX Impact
Multi-IDE Windows	LowManualHighGit Worktrees	MediumEasyMediumDevContainers/Cloud	HighExternalLow Workspace StrategyIsolationMergeability	UX Impact
Multi-IDE Windows	LowManualHighGit Worktrees	MediumEasyMediumDevContainers/Cloud	HighExternalLow Workspace StrategyIsolationMergeability	UX Impact
Multi-IDE Windows	LowManualHighGit Worktrees	MediumEasyMediumDevContainers/Cloud	HighExternalLow Workspace StrategyIsolationMergeability	UX Impact Workspace Strategy Isolation Mergeability UX Impact Multi-IDE Windows	LowManualHigh Multi-IDE Windows Low Manual High Git Worktrees	MediumEasyMedium Git Worktrees Medium Easy Medium DevContainers/Cloud	HighExternalLow DevContainers/Cloud High External Low Multiple IDE Windows (and screen chaos!) The first way I saw people trying to parallelize their environment was spinning up multiple IDEs and pointing them to the same codebase. This was shown in echohive’s video: “multiple Cursor Composer and Windsurf Cascade agents”: This creates a lot of windows and becomes chaos on the screen. You also need a clear strategy for directory partitioning to avoid having them all writing to the same place. multiple Cursor Composer and Windsurf Cascade agents becomes chaos on the screen strategy for directory partitioning This is why people started moving towards headless execution or terminal-based execution of the coding. Git Worktrees for isolated branches Now you could copy the files, but what you want is to actually copy the repo with its version control, because that will allow you to merge the results back in later. Git actually has an integrated mechanism for this called git worktrees. It allows you to clone and branch a git repository into another directory. The first video I saw it in action was in Indydevdan’s video: “Claude 4 ADVANCED AI Coding: How I PARALLELIZE Claude Code with Git Worktrees” Claude 4 ADVANCED AI Coding: How I PARALLELIZE Claude Code with Git Worktrees Source: Indy Devdan Youtube: Claude 4 ADVANCED AI Coding: How I PARALLELIZE Claude Code with Git Worktrees Indy Devdan Youtube: Claude 4 ADVANCED AI Coding: How I PARALLELIZE Claude Code with Git Worktrees This mechanism was also described on the Claude code best practices page (scroll down). In addition, Claude Code has the ability to spawn sub agents and just by describing the parallel process in markdown files people had this parallel loop working. Claude code best practices page spawn sub agents People documented their experiences with this novel workflow that are well worth a read: Claude Code for Parallel DevelopmentHow I Use Claude Code, Start New ThreadHow To Wield Coding Agent ClustersWay Enough - Git worktreeParallel AI Coding with Git WorktreesLLM Codegen go Brrr – ParallelizationClaude Code Was Surprisingly Well-Crafted and User-Friendly Claude Code for Parallel Development Claude Code for Parallel Development How I Use Claude Code, Start New Thread How I Use Claude Code, Start New Thread How To Wield Coding Agent Clusters How To Wield Coding Agent Cluster Way Enough - Git worktree Way Enough - Git worktree Parallel AI Coding with Git Worktrees Parallel AI Coding with Git Worktrees LLM Codegen go Brrr – Parallelization LLM Codegen go Brrr – Parallelization Claude Code Was Surprisingly Well-Crafted and User-Friendly Claude Code Was Surprisingly Well-Crafted and User-Friendly We also saw many tools emerging around this new workflow (note: many are experimental) such as Uzi, AI - fleet, Claude flow and Claude simone. Uzi AI - fleet Claude flow Claude simone Container / DevContainer isolation in cloud or CI Within CI/CD systems, we are typically using containers to contain builds. Or we can use devcontainers for local machine isolation. We can apply this for agents too: we all give them their own machine, keeping our local machine clean. Additionally, this allows us to scale the machine power via the cloud and support more complex tech stacks. We see this happening in the First look at Cursor background agents (multiple agents in the cloud: spawns a container and pulls from the github repository and then reports back. It is also recommended by Claude to run your agents using a container or in devcontainer (see this Claude config for it). First look at Cursor background agents (multiple agents in the cloud see this Claude config for it Therefore it should not come as a surprise that one of the former founders of Docker is working on an optimized workflow of spanning up containers and merging remote agent work back. You provide the container-use as an MCP server to the agent and it spawns off multiple containers. This is also now used by frameworks such as Claude parallel work. container-use Claude parallel work Create 2 variations of a simple hello world app using Flask and FastAPI. each in their own environment. Give me the URL of each app This would spin up two containers, have them pull the existing repo, start coding and then start the preview version of the app. Further Considerations in Parallelizing Agents Knowledge Consolidation Parallel execution isn’t enough. We also need shared memory so agents don’t reinvent the wheel every time: when the system learns things, we want it to share the common knowledge. This can improve future runs of the agents. A first crude form of this was agents updating a shared markdown file as “shared” memory. We are starting to see the first signs of this being externalized to a shared memory service. This knowledge is another artifact that the agents produce and that we need to approve and review. shared memory service We need to make sure that the knowledge is up to date and not conflicting, much like the specifications and requirements. Diversification of knowledge can also be fostered by using different models for different tasks, here each model is going through a parallel thought process in addition to parallel threads for coding. From CI/CD to Continuous Imagination What if we think we can put the different varieties in front of customers for feedback? in front of customers for feedback? In CI/CD, the testing and review happens on the build systems. Now we can have these build systems as part of our agentic coding. We still have to work out how multiple developers and their own set of developer agents will collaborate and merge, but we can already shift part of the process left. It feels quite similar to parallel feature branches, or for end users feature flags. It’s still early days, and we are taking our first steps from “auto-committing” to “auto-deploying” and the parallel exec actually will help the reproducibility and sharing of results. These parallel execution frameworks may lay the groundwork for Continuous-AI — where iteration, learning, and deployment form one seamless loop. So this isn’t just Continuous Integration anymore, it’s Continuous Imagination.✨ Continuous-AI Continuous Imagination.

The Rise of the Self-Spawning AI Dev Team

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

7 Major Learnings from The AI Engineering SF World Fair 2025

97% of Tech Leaders Fear Unethical AI Use but Only a Third Have Oversight

Fixing Web3 Marketing: Understanding the Real Web3 Audience

The Next Era of AI: Inside the Breakthrough GPT-4 Model

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

7 Major Learnings from The AI Engineering SF World Fair 2025

97% of Tech Leaders Fear Unethical AI Use but Only a Third Have Oversight

Fixing Web3 Marketing: Understanding the Real Web3 Audience

The Next Era of AI: Inside the Breakthrough GPT-4 Model

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps