> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Build in parallel

> Learn how to build several features at once with parallel tasks: delegate safely, slice work small, and apply changes without surprises.

Handling multiple pieces of work at once is one of those skills that separates good builders from exceptional ones. This page teaches you how to build several features at the same time, safely, even if you've never worked this way before.

## A new way to work with Agent

So far, you've probably worked with Agent like a partner sitting next to you: you ask, you watch, you respond. Building in parallel is a different relationship. You hand a feature to Agent as a **task**, and it goes off and builds it in the background while you do something else.

You already work this way in everyday life. You don't stand in front of the washing machine until it finishes. You start the laundry, then go cook. Tasks work the same way: start one, and while it runs, start another, review something else, or just keep chatting with Agent in the main conversation.

This changes your role. You stop being a passenger watching one build and become the director of several.

## Your app is safe while tasks run

The first question everyone asks: *will a background task break my app while I'm not looking?*

No. Each task works on its own **copy** of your project. Your app doesn't change until you review a task's work and choose to apply it.

Each task also gets its own Agent and inherits your full project context, so you don't repeat yourself. Tasks are independent: you can start the next one the moment the first is running.

## A worked example: three features at once

Imagine a car rental app that already handles reservations and sign-in. You want to add three features:

* An events page
* Event registration
* A contact form

Built one after the other at about five minutes each, that's fifteen minutes. Built in parallel, it's about five.

Create a task for each feature. Tasks start in Plan mode, so each one shows you a plan before building. Approve the plans, and watch what happens: the events page and the contact form start building immediately, but event registration waits. Visitors can't register for events if the events page doesn't exist yet. Agent notices that dependency on its own, acts like a project manager, and runs that task after the one it depends on.

<Frame>
  <img src="https://mintcdn.com/replit/L22mbBMLs80H8_c8/images/replitai/task-plan-sidebar.png?fit=max&auto=format&n=L22mbBMLs80H8_c8&q=85&s=46aa76922ec245592fba29347bebc5c7" alt="Thread view showing multiple tasks running in parallel with status indicators" width="3430" height="1986" data-path="images/replitai/task-plan-sidebar.png" />
</Frame>

To see everything at once, open the task board, where every task moves through columns from draft to done in real time.

<Frame>
  <img src="https://mintcdn.com/replit/L22mbBMLs80H8_c8/images/replitai/task-board-progress.png?fit=max&auto=format&n=L22mbBMLs80H8_c8&q=85&s=3b4ef2fbede2d057e40c138956ccd74d" alt="Task board showing tasks organized in columns from draft to done" width="3456" height="1984" data-path="images/replitai/task-board-progress.png" />
</Frame>

## Slice your work small

The skill that makes parallel building work is cutting features into small, self-contained tasks. Small tasks finish faster, are easier to review, and are less likely to interfere with each other.

A useful rule: **if your task description contains "and", consider splitting it.**

* Good: "Add an events page", "Add a contact form"
* Too big: "Add events and registration and email notifications and an admin view"

The big version isn't wrong, but it forces one Agent to do everything in sequence. Four small tasks give Agent the chance to run them together.

Test yourself. Which of these could run in parallel?

1. Add a dark mode toggle
2. Add a customer reviews section
3. Let customers reply to reviews
4. Translate the app into French

<Accordion title="Answer">
  Tasks 1, 2, and 4 are independent and can all run at once. Task 3 depends on task 2: there's nothing to reply to until reviews exist. You don't need to catch this yourself. Agent detects the dependency and sequences those two tasks for you.
</Accordion>

## Why you update before you apply

Here's the one concept that trips everyone up, so let's take it slowly.

Two friends each take home a copy of the same party invitation to improve it. One adds a map. The other rewrites the schedule. You accept the first friend's version, and it becomes the real invitation. Now the second friend's copy has a problem: their rewrite is based on an invitation that no longer exists. Before you can accept their work, they need to redo it on the newest version.

Tasks work exactly like this. Each one copied your project when it started. The moment you apply one task's changes, every other task's copy is one version behind. For unrelated features that's often fine, but since you're not reading the code, you can't be sure two tasks didn't touch the same thing.

<Tip>
  Before applying a task's changes, **update** the task first. Updating syncs the task with the latest version of your app and resolves any conflicts, so your tasks build on top of each other instead of overwriting each other.
</Tip>

## Review like a manager

Parallel building makes you a manager, and the classic manager mistake is approving work you didn't check. The discipline is a simple loop, one task at a time:

<Steps>
  <Step title="Test the task's work">
    Open the finished task and try the feature. Click through it like a user would.
  </Step>

  <Step title="Apply it">
    Happy with it? Apply the changes to your main app.
  </Step>

  <Step title="Update the next task">
    Before touching the next finished task, update it so it syncs with the version you just changed.
  </Step>

  <Step title="Repeat">
    Test, apply, update, until every task has landed.
  </Step>
</Steps>

<Frame>
  <img src="https://mintcdn.com/replit/L22mbBMLs80H8_c8/images/replitai/task-review-apply.png?fit=max&auto=format&n=L22mbBMLs80H8_c8&q=85&s=4801afb66f05f46e919c8900c2963735" alt="Task review screen showing Agent's work log, test results, and Apply changes button" width="3456" height="1984" data-path="images/replitai/task-review-apply.png" />
</Frame>

Never batch-approve. Three unreviewed features applied at once means three suspects when something looks wrong.

## When to stay sequential

Parallel building is a tool, not a rule. Stay in the main conversation, one thing at a time, when:

* **Two ideas touch the same screen.** "Redesign the home page" and "change the navigation" will collide. Do them in order.
* **You're exploring.** In design work, the result of one attempt changes what you want next. Exploration is a conversation, not a work order.
* **You can't describe the task in one sentence.** If you can't state it simply, you're not ready to delegate it.

## Find your ceiling

The limit on parallel building isn't Replit. It's your attention. Every time you switch between tasks, you pay a small cost in focus, and everyone's budget is different.

Start with two tasks. If reviewing them feels comfortable, try three. Agents are good enough at building that you don't need to supervise every step, so most builders find the speed is worth the switching. But this is a skill you practice, not a setting you enable.

## Next steps

* [Task system](/core-concepts/agent/task-system): The full reference for how tasks work.
* [Plan and Build modes](/learn/plan-vs-build-mode): Why tasks start with a plan.
* [Vibe coding 101](/learn/foundations/vibe-coding-101): The build-in-small-slices mindset that makes slicing tasks natural.
