Phase 3: Build

What: Generate the Technical Spec and build the whole feature in a single coherent pass, with the reveal controls from the Exposure Plan in place.

Thinking mode: Engineering thinking. Making it real. Build assumes construction with AI agents. Without agents, build pace matches consumption pace and the asymmetry that motivates LDD disappears. The agent receives the Spec and the Exposure Plan, gets full codebase context, and builds. For complex features, the agent can plan and delegate to sub-agents, use skills, or orchestrate plugins. On a team, whoever has the best context on the codebase drives the agent. Sometimes that's an engineer, sometimes it's a PM who's been living in the code. Solo builders pair with the agent directly.

Inputs: The Spec (from Frame), the Exposure Plan (from Slice), the codebase, the test suite.

Output: Working code for the whole feature (not production-ready, but working), with reveal controls wired up so the first reveal level can go live without exposing the rest.

The first step of Build is translating the Spec and the Exposure Plan into a Technical Spec: data models, APIs, architecture decisions, dependencies, existing patterns to follow, and how the reveal controls will be implemented. The technical context belongs to whoever is closest to the code: an engineer, an agent with the right context window, or both. The Spec says what and why; the Technical Spec says how.

The scope is the feature, not the product

"Build the whole thing" means the whole feature, not the whole product. The product evolves iteratively and incrementally, one feature at a time, loop after loop. What stays coherent and unsliced is the feature inside a single bet.

Take an Enterprise Dashboard on our LMS for tracking employees' progress on our trainings. That's one feature, one bet. Building it "whole" means the agent designs and implements the data model, the queries, the permissions, the views, the filters, the empty states, the pagination, and the export flow in one coherent pass, with full context on the existing codebase. The reveal controls ship with it: a feature flag wraps the whole dashboard, a role check gates it to pilot admins, and the export flow sits behind its own toggle so reveal level 1 can go live with the read-only views while writes and exports stay dark. It does not mean building the rest of the LMS or any other feature at the same time. It also does not mean building only the first reveal tile and coming back later for the rest; that is the gradient-artifact trap.

Build is not "implement a thin slice." The thin slicing happens at reveal time, not at build time. Agents drift when context is rebuilt, so handing them the whole feature's bet at once and letting them build coherently is what keeps the feature from turning into a patchwork. The code is cheap to throw away, so there is no penalty for building more of the feature than the first reveal level needs.

The goal is to preserve context and catch drift early, without blocking execution. Building is not the "easy part" that anyone can do. It requires real judgment about architecture, trade-offs, and quality. What's changed is that AI amplifies that judgment, making it possible to go from a Spec to a coherent feature in hours rather than days.

Spec-Driven Development lives here

If you're familiar with Spec-Driven Development (SDD), this is where it fits. SDD is the practice of writing a tight, detailed spec and handing it to an agent to build. The spec is the interface between human intent and agent execution.

LDD and SDD are complementary, not competing. LDD wraps around SDD:

• Frame answers what are we betting on? and produces the Spec.
• Slice answers what do we expose, to whom, and in what order? and produces the Exposure Plan.
• Build (SDD) answers how do we get the agent to build the whole artifact well, in one pass? It generates the Technical Spec and builds.
• Validate answers did each belief hold? by revealing progressively and testing.
• Decide answers did the bet pay off, and what do we do next?

SDD on its own builds exactly what the spec says. LDD makes sure the spec is worth building in the first place, and that what gets built actually gets validated. Without LDD, SDD can produce perfectly executed code that solves the wrong problem. Without SDD, LDD's Build phase lacks the discipline to get clean, reliable output from agents.

Think of it this way: LDD is the learning system. SDD is the execution engine inside it.