Verdent Docs
This is archived Verdent 1.0 documentation. For current product documentation, see Verdent.

Parallel Development

Work on multiple features simultaneously using isolated workspaces

Parallel development enables you to work on multiple features, bug fixes, and experiments simultaneously. Each runs in its own isolated workspace, where tasks and their agents work independently.


What You'll Learn

  • Set up parallel development workflows
  • Work on features, bugs, and experiments simultaneously
  • Common patterns for parallel execution

Overview

Parallel development combines:

  • Workspace Isolation - Each workspace has its own branch and file state
  • Parallel Tasks - Multiple tasks with their own agents working simultaneously
  • Selective Rebasing - Choose which results to integrate
BenefitDescription
FasterMultiple agents complete work in parallel
No ConflictsIsolated workspaces prevent interference
Safe ExperimentationTry different approaches without risk

Setting Up Parallel Work

Create First Workspace

Click New Workspace in the Top Bar, name it feature-auth

Start First Task

In the input box, describe the feature and send to start a task with its agent

Create Second Workspace

Without waiting, click New Workspace again, name it bugfix-123

Start Second Task

Describe the bug fix to start another task with its agent

Create More as Needed

Repeat for additional parallel tasks

Workspace Structure

flowchart TD
    B[master branch - stable] --> W1[Workspace: feature-auth]
    B --> W2[Workspace: bugfix-123]
    B --> W3[Workspace: experiment-caching]

Monitoring Progress

Switch between workspaces to check progress:

ActionShortcut
Next workspaceCtrl+Tab
Previous workspaceCtrl+Shift+Tab

All tasks and their agents continue working regardless of which workspace you're viewing.


Workflow Patterns

Work on a feature while addressing an urgent bug:

WorkspaceTask
feature-dashboardContinue feature work
hotfix-securityFix critical bug

Bug fix completes first → rebase immediately. Feature continues unaffected.

Try different solutions to the same problem:

WorkspaceApproach
approach-reduxImplement using Redux
approach-contextImplement using Context API
approach-zustandImplement using Zustand

Compare results, rebase preferred approach, delete others.

Build multiple unrelated features simultaneously:

WorkspaceFeature
feature-authUser authentication
feature-dashboardDashboard UI
feature-notificationsNotification system

Each feature develops independently, rebase when complete.


Completing Parallel Work

Review Each Workspace

Click Task Changes to review changes for each workspace

Address Issues

Fix any problems found in reviews

Commit Changes

Use Source Control (Ctrl+Shift+G) to commit with descriptive messages

Rebase to main branch

Click Workspace Actions → Rebase to main branch for each completed workspace

Clean Up

To delete a workspace, click the trash icon near the workspace name in the Workspace Bar, or right-click the workspace in the top bar and select Delete.


Best Practices

Good Candidates for Parallel Work

  • Independent features
  • Bug fixes unrelated to current work
  • Experiments and proof-of-concepts
  • Different approaches to same problem

Poor Candidates

  • Tasks with dependencies (A must complete before B)
  • Very small, quick tasks
  • Tasks requiring tight coordination

FAQs

How many parallel tasks should I run?

Start with 2-3 and increase based on performance. Complex tasks may need more resources per agent.

What if parallel tasks need to share code?

If tasks need shared code, they may not be good candidates for parallelization. Complete shared work first, then parallelize independent follow-up tasks.

Do tasks stop when I switch workspaces?

No. Tasks and their agents continue working in the background when you switch to another workspace.

What is Task Changes?

Task Changes shows the total set of code changes made across the entire task so far. It reflects everything that has been modified since the task started.

What is Step Changes?

Step Changes shows only the code changes introduced by the current prompt. It reflects what was added or modified in this specific execution step.


See Also