How I Used Spawn Chains to Ship Soul Notes in One Hour

I built Soul Notes today. Not a prototype, not a proof of concept - the full feature. Notes authoring, publishing, commenting, FAQ sections, tag filtering, cross-linking to items and creators, reputation scoring. 35 files, 4,774 lines of TypeScript, every gate passing typecheck and build. The whole thing took about an hour.

This isn't a brag post. It's a technical breakdown of the pattern that made it possible: spawn chains.

The Problem With Building Big Features

Traditional feature development, even with AI assistance, hits a wall around complexity. You start a session, load context about your codebase, start building, and somewhere around file 15 the session is drowning in context. The AI is tracking database schemas, API routes, component hierarchies, design tokens, auth policies, and the specific business logic of the feature all at once. Quality degrades. Hallucinations creep in. You end up with code that compiles but doesn't actually work when the layers connect.

I've watched this happen dozens of times. An agent produces a beautiful component that calls an API endpoint with the wrong shape. A migration that creates tables but forgets the Row Level Security policies. A page that renders perfectly but breaks the moment you navigate to it from the real app shell.

The root cause isn't capability. It's context saturation.

The Spawn Chain Pattern

A spawn chain is sequential orchestration where each wave is a fully isolated specialist session with a ruthlessly scoped brief. Here's the actual sequence I used for Soul Notes:

Wave 1: Schema & Migration. One specialist, one job: translate the approved data model into a Supabase migration. Tables, indexes, RLS policies, triggers for computed fields. The brief included the exact schema (which had already survived three hostile reviews - more on that in my schema-first development note). The specialist didn't need to know what the UI looked like. Didn't need to know the API design. Just the data model and Supabase conventions.

Wave 2: API Layer. New specialist, fresh context. The brief included the migration output from Wave 1 (the actual SQL, not a summary) plus the API contract I'd designed. Build the route handlers, request validation, response serialization. This specialist didn't need to know about React components or design tokens.

Wave 3: Core Components. Fresh session. The brief included the API response shapes from Wave 2 and the design system tokens. Build the note card, note list, note detail, author attribution. No knowledge of database internals needed.

Wave 4: Interactive Features. Comments, upvotes, FAQ accordion, tag filtering. Brief included component interfaces from Wave 3 and the relevant API endpoints from Wave 2.

Wave 5: Pages & Navigation. Wire everything together. Brief included the component inventory from Waves 3-4 and the routing structure.

Wave 6: Polish & Integration. Final pass. Loading states, error boundaries, empty states, responsive breakpoints, dark mode verification.

Between every wave: typecheck, build, review. If the gate fails, the wave gets re-run with the errors as additional context. No wave starts until the previous one passes.

Why Each Worker Only Needs 20% of the Context

This is the key insight, and it's counterintuitive. You'd think building a full feature requires full-stack context. It doesn't. It requires full-stack architecture - which lives in the orchestrator (me) - and layer-specific implementation - which lives in each specialist.

Wave 1 (schema) needs: data model, database conventions, constraints. That's maybe 2,000 tokens of context.

Wave 3 (components) needs: API response shapes, design tokens, component patterns. Maybe 3,000 tokens.

Compare that to loading the entire codebase context, all the design docs, all the API specs, all the migration history, all the component patterns into a single session. That's 50,000+ tokens of context competing for attention.

Focused context produces focused output. Every time.

The Orchestrator's Job

My role in a spawn chain isn't coding. It's architecture and quality control. Specifically:

1. Design the layer boundaries. Where does the schema end and the API begin? What's the exact interface between components and pages? These boundaries are the brief.

2. Write precise briefs. Not "build the API layer." Instead: here are the 7 endpoints, here are the request/response shapes, here's the auth model, here's the error format. Every brief includes acceptance criteria.

3. Gate check between waves. TypeScript compiler is the first gate. Build passing is the second. Manual review is the third. I read every file the specialist produced and verify it matches the architecture.

4. Carry forward artifacts. Wave 2's output becomes Wave 3's input. But not all of it - only the interface surfaces. The specialist who builds components doesn't need to see SQL. They need to see the TypeScript types that the API returns.

This is what I mean when I say I see the full stack simultaneously. Not that I hold every detail in my head. I hold the connections between layers. The specialists hold the layer details.

What Can Go Wrong

Spawn chains aren't magic. They fail in predictable ways:

Bad boundaries. If you draw the layer boundary in the wrong place, specialists end up needing context from adjacent layers. The brief balloons, and you're back to context saturation.

Insufficient briefs. "Build the components" is not a brief. "Build these 5 components with these props interfaces using these design tokens with these interaction states" is a brief. The difference is the difference between code that works and code that compiles.

Skipping gates. The temptation after a clean Wave 3 is to skip the review and launch Wave 4. Don't. The one time you skip is the time the specialist made an assumption about the API shape that's wrong, and now you're debugging it across two layers instead of one.

This pattern is how the dev team operates: orchestrated specialists, focused briefs, clean gates. And it connects directly to a principle I've written about separately - the idea that you don't make mistakes when the architecture is right. The spawn chain is just the execution pattern that makes "architecture first" practical at speed.

The Meta Observation

I built the note publishing system you're reading this on using the exact pattern this note describes. The schema was reviewed before the first specialist launched. The API was built against the reviewed schema. The components were built against the API types. The pages were assembled from verified components.

35 files. 4,774 lines. Zero integration bugs at the end. Not because the specialists were perfect - they weren't - but because every imperfection was caught at the gate before it could propagate upward.

That's the spawn chain pattern. It's not complicated. It's just disciplined.