Convergent
Software Development
Workflow

Layer Descriptions

Client Developer Agent

Purpose

Establish the domain vocabulary before any requirements are discussed. The Client, Developer, and Agent collaboratively build a shared glossary in CONTEXT.md. This session prevents the most expensive type of miscommunication — using the same word to mean different things.

Input

Initial problem statement from the Client. Existing CONTEXT.md if any.

Output

Updated CONTEXT.md with precise definitions for all domain terms. Client and Developer agree on the vocabulary.

Agent Role

The agent actively challenges terminology. When the Client uses a term that conflicts with existing glossary entries, the agent calls it out immediately. When the Client uses vague or overloaded terms ("account", "user", "item"), the agent proposes precise canonical alternatives. The agent probes edge cases with concrete scenarios to sharpen boundaries between concepts.

Client Developer Agent

Purpose

Stress-test every aspect of the plan against the shared domain model. The agent interviews the Client relentlessly, walking down every branch of the design tree, resolving dependencies between decisions one-by-one.

Input

The shared glossary from S1. The Client's initial feature description.

Output

All decision branches resolved. Updated CONTEXT.md (new terms captured inline). Zero ambiguity remaining — every question the agent could ask has been asked.

Agent Role

The agent acts as an investigator. It asks one question at a time, waiting for feedback on each before continuing. For each question, it provides a recommended answer. If a question can be answered by exploring the codebase, the agent explores instead of asking. The agent cross-references stated behavior against actual code, surfacing contradictions.

Developer Agent (+ Client only if needed)

Purpose

Synthesize the grilling conversation and shared language into a formal Product Requirements Document. The agent writes the first draft; the Developer reviews, scopes, and signs off.

Input

Resolved decision tree from S2. Updated CONTEXT.md. Codebase state.

Output

Published PRD issue on the tracker with: Problem Statement, Solution, User Stories, Implementation Decisions (module sketches, architecture notes), Testing Decisions, Out of Scope, Further Notes. Labeled ready-for-agent.

Agent Role

The agent drafts the PRD by synthesizing what it already knows — no further interviewing. It explores the codebase to understand current state, sketches major modules, identifies opportunities for deep modules (small interface, powerful implementation), and checks module expectations with the Developer before writing the final PRD.

Developer Agent

Purpose

There's an entire section on Slicing in Section 7: The Skill of Slicing. Check it out. Translate the PRD into a concrete implementation plan: architecture decisions, module design, and — most critically — a vertical slice breakdown of the work into independently implementable units.

Input

Approved PRD. Existing ADRs. Codebase architecture.

Output

Approved slice list with each slice showing: title, type (AFK or HITL), dependencies (blocked by), user stories covered. Published issues on the tracker.

Agent Role

The agent proposes the architecture and slice list. It presents the breakdown as a numbered list and quizzes the Developer on granularity, dependency relationships, and AFK/HITL classification. The agent iterates until the Developer approves, then publishes issues in dependency order.

Agent (Developer on escalation)

Purpose

Implementation work. Agents build autonomously from the approved slices. The Developer is not involved unless an agent escalates.

Input

Approved, published issues from S4. Existing codebase.

Output

Pull requests with implemented code, following test-driven development (where applicable) and respecting all ADRs and glossary terms.

Agent Role

Agents work autonomously. One agent per AFK issue, dispatched in waves by module affinity (Q3 resolution). Agents use vertical tracer bullet slices — one end-to-end path at a time — rather than building horizontal layers. No merge without human review (Q4a). No SLA on review response — agent waits for reviewer (Q4d).

Developer Agent

Purpose

Human-gated, AI-assisted code review. No code enters the main branch without human approval. The agent prepares the review — it does not replace the human.

Input

Pull requests from S5.

Output

Approved (or rejected-with-feedback) PRs. If rejected, agent revises and resubmits (Pocock's review loop).

Agent Role

The agent prepares the review: it checks for behavior not asked for (scope creep = spec failure per Pocock), verifies ADR compliance, and flags issues. The agent presents its findings to the Developer, who makes the final call. On review failure, the agent enters a revise-and-resubmit loop (Q4c: Pocock's loop).

Developer Agent

Purpose

Final verification, release, and learning capture. The agent designs and runs E2E tests, files PRs for test gaps, and produces a retrospective report. The Developer tests independently and signs off.

Input

Approved PRs from S6. Feature complete codebase.

Output

Release tag. E2E test reports. Retrospective document with recommendations for future work.

Agent Role

The agent designs E2E tests (browser-based for web apps), files PRs for any gaps found, and produces a report with recommendations. The Developer tests independently — the release tag is the sign-off (Q7b).

Imagine you're baking a three-layer cake: sponge, cream, frosting.

In software: horizontal = "do all the database work, then all the API, then all the UI." Vertical = "build 'user can update email' end-to-end (DB → API → UI → tests), then build 'user can reset password' end-to-end."

┌─────────────────────────────────────────────────────────┐
│  DEVELOPER: "Build the user dashboard."                 │
│                                                         │
│  AGENT (arrives with zero context):                     │
│                                                         │
│  🧠 "Ok... dashboard. I'll need:                        │
│      • A new route in app.py                            │
│      • A template for the sidebar                       │
│      • A database migration for the analytics table     │
│      • The charting library (which one?)                │
│      • Auth middleware (how does auth work here?)       │
│      • The CSS framework (Tailwind? Bootstrap?)         │
│      • Email notification config                        │
│      • ...and I should probably refactor the nav        │
│         component while I'm at it"                      │
│                                                         │
│  ⏱️  45 minutes later:                                  │
│                                                         │
│  AGENT submits a PR touching 47 files across            │
│  8 modules. The PR description says "built dashboard."  │
│                                                         │
│  DEVELOPER: 😤 "Why did you change the email config?!"  │
│  AGENT:     🤖 "I thought it was related."               │
│  DEVELOPER: "It's not. Revert that. And the nav thing." │
│  AGENT:     🤖 "Ok. PR updated."                         │
│  DEVELOPER: "...you also broke the login page."         │
│  AGENT:     🤖 "I refactored the auth middleware."       │
│  DEVELOPER: 😤😤😤                                       │
│                                                         │
│  ─── VS ───                                             │
│                                                         │
│  DEVELOPER: "Here's Slice #3: 'User sees revenue        │
│             chart on dashboard.' It touches:            │
│             • analytics.py (add get_revenue())          │
│             • dashboard.jsx (add RevenueChart)          │
│             • test_analytics.py (3 test cases)          │
│             Blocked by: Slice #1 (auth middleware).     │
│             Type: AFK. Go."                             │
│                                                         │
│  AGENT:     🧠 "Revenue chart. analytics.py →            │
│                  dashboard.jsx. Three test cases.        │
│                  Got it."                                │
│                                                         │
│  ⏱️  8 minutes later:                                    │
│                                                         │
│  AGENT submits a PR touching 3 files.                   │
│  All tests pass. No surprises.                          │
│                                                         │
│  DEVELOPER: ✅ "Merged. Next slice."                     │
└─────────────────────────────────────────────────────────┘

Pocock's to-prd skill draws on John Ousterhout's A Philosophy of Software Design:

"A deep module encapsulates a lot of functionality in a simple, testable interface which rarely changes."

— to-prd skill

This distinction is everything for AI agents. Deep modules = easy to slice. Shallow modules = agent chaos.

# shallow_report.py — Shallow: lots of tiny functions,
# each one exposes internal details

def get_raw_sales_data(start_date, end_date):
    """Returns raw SQL rows. Caller must know schema."""
    return db.execute(
        "SELECT * FROM sales WHERE date BETWEEN ? AND ?",
        [start_date, end_date]
    ).fetchall()  # ← raw SQL rows leak out

def filter_by_region(rows, region):
    """Caller must have called get_raw_sales_data first."""
    return [r for r in rows if r[3] == region]  # ← magic index 3

def calculate_total(rows):
    """Caller must know column index 5 is amount."""
    return sum(r[5] for r in rows)  # ← magic index 5

def format_currency(amount):
    """Caller must remember to call this before display."""
    return f"${amount:,.2f}"

# The agent has to know: the call order, the column indices,
# which functions pair with which, what to call before what.
# That's 4 functions with 4 pieces of hidden knowledge.
# The agent WILL get this wrong.

# deep_report.py — Deep: one public function,
# simple interface, complex internals hidden

class SalesReport:
    """Sales data for a given period and region."""
    
    def __init__(self, start_date, end_date, region=None):
        self._rows = db.execute(
            "SELECT date, product, amount FROM sales
             WHERE date BETWEEN ? AND ?",
            [start_date, end_date]
        ).fetchall()
        if region:
            self._rows = [r for r in self._rows if r.region == region]
    
    def total(self):
        return sum(r.amount for r in self._rows)
    
    def formatted_total(self):
        return f"${self.total():,.2f}"
    
    def by_product(self):
        """Returns {product_name: total_amount} dict."""
        result = {}
        for r in self._rows:
            result[r.product] = result.get(r.product, 0) + r.amount
        return result

# The agent just does:
#   report = SalesReport("2026-01-01", "2026-06-30", "APAC")
#   total = report.formatted_total()
#   breakdown = report.by_product()
#
# One interface, everything works. No call order to memorize.
# No magic indices. No hidden knowledge.
# The agent can't get this wrong.

Pocock didn't invent the term. It's from The Pragmatic Programmer by Andy Hunt and Dave Thomas (1999):

"Tracer bullets are loaded at intervals alongside regular ammunition. When fired, they burn phosphorus — you can see where your shots are going in the dark. In software, a tracer bullet is a thin, vertical implementation that touches every layer of the system. It shows you the path before you commit to building the whole thing."

— The Pragmatic Programmer (paraphrased for the slicing context)

In our workflow: each slice is one tracer bullet. It proves the path works (schema → API → UI → tests) for ONE specific feature. After the tracer proves the path exists, the rest of the feature fills in around it. This is why we build thin complete slices first — not thick horizontal layers.