Two-Track Parallel Development

In our previous lessons, we explored how to use specialized AI agents to handle complex tasks with high precision. We learned that by delegating work to subagents, we avoid context decay and keep code quality high. Now that you understand how to manage a single stream of work, it's time to look at how we can scale this process.

In a production environment, we often have multiple features waiting to be built. If Feature A and Feature B do not rely on each other, we do not have to wait for Feature A to finish before starting Feature B. This is called Parallel Development. By running these workflows at the same time, we significantly reduce calendar time — the actual days or hours it takes to deliver the project — even if the total amount of work remains the same.

In this lesson, you will learn how to identify when features can be built in parallel and how to coordinate them so they do not clash when they are merged back together.

Not every task can be done in parallel. If two features require changing the same line of code in the same file, they will cause a "conflict." To work in parallel, features must be independent.

We use a simple checklist to verify independence:

1. No shared files: Aside from basic configuration or test setup, the features should live in different files.
2. No integration dependencies: Feature A should not need code from Feature B to function.
3. Different database tables: They should not modify the same data structures.
4. Different API endpoints: They should provide different routes for the user.

Let's look at our target features: Task Tags and Task Reminders.

Since these use different tables and files, they are perfect candidates for parallel development. We can document this in a file called parallel-features-analysis.md to ensure our AI agents understand the boundaries.

Even though the features are independent, they usually share a common starting point, such as the database. If two agents try to create a database migration at the same time, they might generate conflicting version numbers. To prevent this, we use Phase 1: Foundation.

In this phase, we perform a single session to set up the infrastructure that both features will use.

First, we create a database migration that defines the tables for both features. This ensures the "ground" is ready for both tracks.

# Generate the migration
alembic revision --autogenerate -m "add tags and reminders tables"

This creates a file in alembic/versions/ with a name like abc123def456_add_tags_and_reminders.py. The migration will define the new tables:

"""add tags and reminders tables

Revision ID: abc123def456
Revises: previous_revision
Create Date: 2024-01-15 10:00:00.000000

"""
from alembic import op
import sqlalchemy as sa
from sqlalchemy.dialects.postgresql import UUID

revision = 'abc123def456'
down_revision = 'previous_revision'
branch_labels = None
depends_on = None


def upgrade():
    # Tables for Feature A: Tags
    op.create_table('tags',
        sa.Column('id', UUID(as_uuid=True), primary_key=True),
        sa.Column('name', sa.String(30), nullable=False),
        sa.Column('user_id', UUID(as_uuid=True), sa.ForeignKey('users.id'), nullable=False),
        sa.Column('created_at', sa.DateTime(timezone=True), nullable=False)
    )
    
    op.create_table('task_tags',
        sa.Column('task_id', UUID(as_uuid=True), sa.ForeignKey('tasks.id'), nullable=False),
        sa.Column('tag_id', UUID(as_uuid=True), sa.ForeignKey('tags.id'), nullable=False),
        sa.PrimaryKeyConstraint('task_id', 'tag_id')
    )

    # Tables for Feature B: Reminders
    op.create_table('reminders',
        sa.Column('id', UUID(as_uuid=True), primary_key=True),
        sa.Column('task_id', UUID(as_uuid=True), sa.ForeignKey('tasks.id'), nullable=False),
        sa.Column('user_id', UUID(as_uuid=True), sa.ForeignKey('users.id'), nullable=False),
        sa.Column('due_date', sa.DateTime(timezone=True), nullable=False),
        sa.Column('description', sa.String(500)),
        sa.Column('is_sent', sa.Boolean, default=False, nullable=False),
        sa.Column('created_at', sa.DateTime(timezone=True), nullable=False),
        sa.Column('updated_at', sa.DateTime(timezone=True), nullable=False)
    )


def downgrade():
    op.drop_table('reminders')
    op.drop_table('task_tags')
    op.drop_table('tags')

Next, we verify that the foundation is solid by running the migration and checking if the models can be loaded. In your CodeSignal environment, these tools are already set up for you.

# Apply the migration
alembic upgrade head

# Verify that our Python models can see the new tables
python -c "from src.models.tag import Tag; from src.models.reminder import Reminder; print('Foundation OK')"

Output:

Foundation OK

By completing this small shared step first, we create a "safe zone" where the two parallel tracks can now run without stepping on each other's toes.