I’ve been in this industry long enough to watch technologies come and go. I’ve seen the excitement around new frameworks, the promises of revolutionary tools, and the breathless predictions about what would “change everything.” Most of the time, these technologies turned out to be incremental improvements wrapped in marketing hyperbole.

But parallel agents? This is different. This is the first time I can say, without any exaggeration, that I’m witnessing technology that will fundamentally transform how we develop software.

How We Got Here

To understand where we are today, we need to look at the full history of AI-assisted coding. It started with GitHub Copilot, which introduced the concept of AI pair programming. Copilot could autocomplete code as you typed, suggesting functions, completing implementations, and helping with repetitive tasks.

Then came the AI-powered editors like Windsurf and Cursor. These took the concept further by integrating AI deeply into the development environment. Instead of just autocomplete, you could have conversations with AI about your code, ask for refactoring suggestions, and get help with debugging. The AI understood your entire codebase and could provide contextual assistance.

This year, we’ve been working with what’s called “vibe coding” — AI tools where you describe what you want in natural language, and the AI generates complete functions, classes, or implementations from scratch. You tell it “create a sign up form with google, github, and microsoft login options” and it produces working code that captures the vibe of what you asked for.

The term “vibe coding” was coined by Andrej Karpathy in this tweet, which perfectly captured what this new way of programming felt like.

There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…

— Andrej Karpathy (@karpathy) February 2, 2025

This was genuinely revolutionary. Suddenly, you could generate boilerplate code, build simple functions, create UI components, and even tackle complex implementations just by describing them. Many engineers adopted these tools and found them incredibly useful for certain types of work.

The technology worked well enough that it changed how many of us approached coding. Instead of starting from a blank file, you could start with a working implementation and refine from there. It made prototyping faster, reduced the tedium of writing repetitive code, and opened up possibilities for rapid development.

Running Agents in Parallel

Here’s what’s different now: you can run multiple AI agents at the same time, each working on different problems. Instead of waiting for one agent to finish a task before starting the next one, you can have several agents running simultaneously - one building a user interface, another writing API endpoints, and a third creating database schemas.

The core advantage is simple: you can do multiple things at once. This isn’t about smarter AI or better algorithms - it’s about parallelization. The same vibe coding tools we had before, just running multiple instances simultaneously.

The first company that offered a good solution for this was GitHub, with their GitHub Co-Pilots that were running in the cloud. You basically go to an issue and describe it on GitHub. When you are ready with all the descriptions that you think should be able to describe the function, you assign it to Co-Pilot and then wait for the result.

In practice, this means that you can go to your existing issues, check if they have enough context to be handed over to AI. And then you wait for the system to send you a notification that you can review the results.

This transforms the way you write code, and instead of focusing on the microsteps, you are playing the role of a senior engineer who is guiding and providing context to multiple agents who are implementing the features in your codebase. Your job as an engineer now becomes reviewing the code for correctness, ensuring that proper architectural decisions were taken, that a feature makes sense from the user’s perspective, and that the code meets all the security and compliance standards that you need.

The agent itself has the same limitations as you would when you’re vibe coding, which means that they will have the same tendency to make bugs, to lack enough context, to not understand the code. But you are as an engineer, and I would say partly a product owner and designer, would guide the system to implement it for you.

How to work with multiple parallel agents

Parallel agents are changing the way engineers work. Instead of focusing on one task at a time, you can now coordinate several agents working on different features or bug fixes in parallel. You’re actively managing multiple streams of development, reviewing code, and providing feedback as each agent completes its work.

With this approach, I can manage to have 10–20 pull requests open at once, each handled by a dedicated agent.

Here are some practical steps to take:

1. Prepare issues with sufficient context

Start by ensuring each GitHub issue contains enough context for agents to understand what needs to be built and how it integrates with the system. This might include details about feature behavior, file locations, database structure, or specific requirements such as displaying certain fields or handling edge cases.

2. Assign agents in batches

Once issues are ready, assign them to AI agents (such as @copilot). Each assignment typically starts a new pull request, where the agent creates a plan, builds a checklist, and begins implementation. Multiple issues can be assigned at once, allowing agents to work in parallel. Each individual agent takes around 5-20 minutes to complete its work.

3. Review and iterate locally

After an agent completes its tasks, review the resulting pull requests locally. Testing features and verifying correctness is essential. If changes are needed, leave comments or feedback on the pull request, and the agent will continue refining the solution.

4. Maintain flow between reviews

Unlike traditional workflows, parallel agent orchestration keeps me engaged and focused. Instead of waiting for one agent to finish, it’s possible to move between active pull requests—reviewing, testing, and providing feedback as needed. This enables simultaneous progress on multiple tasks without significant mental overhead.

Here is a recording of how this works in practice:

What to Expect from Parallel Agents

Working with parallel agents requires a different mindset than traditional or vibe coding. The shift is as significant as moving from traditional coding to AI-assisted development in the first place.

Mental Model Changes

Control shifts from precision to orchestration. Instead of controlling every line of code, you’re managing multiple problems simultaneously. Think like a system engineer managing Kubernetes pods rather than babysitting individual servers - each task is expendable and replaceable.

Everything becomes asynchronous. Unlike vibe coding where you wait and watch, parallel agents work asynchronously by default. The context you provide upfront determines the result 30 minutes later. You can’t do half-hearted prompts and fix as you go, because those fixes come an hour later.

Batch thinking replaces linear thinking. Instead of picking one perfect task from the backlog, identify several problems you could tackle in a day. A good approach is focusing on 2 critical deliverables while running 5-10 small background tasks - copy changes, UI fixes, minor bugs that can process while you focus on important work.

Realistic Success Rates

Don’t expect 100% success rates. Here’s what typically happens based on my personal observation while writing code.

• 10%: Perfect one-shot solution, ready to ship.
• 20%: Almost there, needs 10 minutes of local refinement.
• 40%: Needs manual intervention.
• 20%: Completely wrong. Close the issue and write down learnings.
• 10%: Bad product idea.

Even if only 10% of the issues are solved perfectly by the agent, the process is still valuable. Agents reliably handle the initial setup—finding the right files, writing boilerplate, and adding tests. By the time you review, much of the groundwork is done, so you can focus on investigating and fixing specific problems.

The frustration of engineers comes when they don’t have a properly aligned expectation of what they should expect from a coding agent. Some engineers simply give up if they don’t get the perfect 100% solution. I think you should move past this limitation and just learn to extract the goodness while jumping in with proper engineering knowledge where it needs to be.

What Works Well vs. What Doesn’t

Parallel agents excel at:

• Bug fixes and race conditions
• Backend logic, controllers, validations
• Database changes and migrations
• Package version bumps and code transformations
• Small, well-defined implementation tasks

They struggle with:

• New UI development (you need to see changes as you build)
• Tasks requiring real-time visual feedback
• Implementing undocumented additions to existing PRs
• Complex architectural decisions requiring context beyond the issue

Skills That Become More Important

Several traditional skills become even more valuable with parallel agents:

Full-stack understanding is valuable when working with parallel agents. If your expertise is limited to either frontend or backend, you’ll quickly encounter roadblocks. Agents often need guidance across the entire stack, from database migrations to UI updates, so being able to navigate both worlds ensures smoother collaboration and better results.

Problem decomposition becomes a critical skill. Large, complex issues are difficult for agents to tackle effectively. Breaking down big problems into smaller, well-defined tasks allows agents to work independently and in parallel, increasing the overall throughput and making it easier to review and integrate their work.

Good writting skills are important. Agents rely on the clarity and detail of your issue descriptions to produce accurate results. Avoid vague language, unnecessary jargon, or ambiguous requirements. The more specific and structured your instructions, the higher the quality of the agent’s output.

QA and Code Review skills take center stage in this workflow. Since the review cycle is the main bottleneck, being able to quickly assess code quality, spot bugs, and verify that requirements are met is crucial. Efficient testing and validation ensure that parallel development doesn’t lead to a backlog of unreviewed or faulty code.

When you are working with parallel agents, you should optimize for review speed. You can start 50 issues, but you still need to review, understand, and verify each one. Making that review cycle fast—ideally under 10 seconds to check out, rebuild, and test—becomes critical to the entire workflow.

Engineering Practices That Enable Parallel Agents

Working with parallel agents requires a well-structured engineering environment that supports rapid iteration and review.

Fast CI/CD Pipeline

A robust CI/CD flow makes it easy to test and verify results. When agents complete their work, you need to quickly validate that the changes work correctly without manual deployment overhead. Automated testing, fast builds, and seamless deployment processes remove friction from the review cycle. Without this foundation, the bottleneck shifts from agent completion time to deployment and testing time.

System Documentation

System architecture documentation helps when multiple agents work on different parts of your codebase. Agents need to understand how components interact, where files are located, what conventions are followed, and how different systems integrate. Well-documented APIs, architectural decisions, coding standards, and system boundaries help agents make better decisions and reduce the need for manual corrections.

Preview and Staging Environments

A reliable staging environment where you can manually test features is required. Since agents work asynchronously, you need a consistent place to validate their output without affecting production systems. This environment should mirror production, deploy quickly, and allow easy testing of multiple concurrent changes. The ability to spin up isolated environments for different branches or pull requests streamlines the parallel review process.

Monorepo Architecture Benefits

Keeping related services and components in a single monorepo works better when working with parallel agents. A monorepo gives agents context about the entire system within a single codebase.

When agents work across multiple repositories, they lose context about service interactions, shared libraries, and dependencies. This leads to solutions that work in isolation but break integration points. With a monorepo, agents understand the full scope of changes needed - updating API contracts, adjusting client code, and modifying shared utilities all in one pull request.

The unified view enables better architectural decisions. Agents can see existing patterns, reuse common components, and maintain consistency across the system. Code reviews are more effective because all related changes are visible in one place, making it easier to verify that agents haven’t introduced integration issues.

Monorepos simplify deployment and testing for parallel development. Instead of coordinating releases across multiple repositories, you can test complete system changes together and deploy atomically. This reduces complexity when managing multiple concurrent agent-generated changes across service boundaries.

Tools That Support Parallel Agents

Several development tools now support running parallel agents, each with different strengths and maturity levels.

GitHub Agents offer the most polished experience. They’re integrated directly into GitHub Issues and work seamlessly with VSCode. You assign issues to @copilot, and agents create pull requests that you can review locally. There are still some rough edges, but GitHub is addressing these issues one by one with regular improvements.

Cursor is currently experimenting with parallel agent support through a beta program. They’ve invited select users to test this functionality, and early reports suggest it’s a promising implementation. If you’re already using Cursor for vibe coding, their parallel agents might be worth exploring once they open up broader access.

OpenAI’s Codex CLI also supports running agents in the cloud, which enables this type of parallel development workflow. The CLI lets you start agents that continue running remotely, allowing you to manage multiple concurrent coding tasks without keeping your local environment tied up.

Each tool takes a slightly different approach to parallel execution, so the best choice depends on your existing development workflow and tool preferences.

Wrapping Up

I’ve been working with parallel agents for a few weeks now, and it’s changed how I approach development. The ability to work on multiple problems simultaneously, rather than sequentially, makes a real difference in productivity.

The technology isn’t perfect - you’ll spend time reviewing and fixing agent-generated code. But when you can kick off 10 tasks and have most of them move forward without your direct involvement, it frees up mental bandwidth for the problems that actually need human judgment.

If you’re curious about trying this approach, start with small, well-defined issues in your backlog. Write clear descriptions and see what happens. The worst case is you spend a few minutes reviewing code that doesn’t work. The best case is you discover a new way of working that fits your development style.