Session 12: SDD — Spec-Driven Development and AI Engineering Harnesses
Date: June 18, 2026
Duration: 27 minutes
Presenter: Merlin Chen
Participants: 60+ attendees visible during the live session
Session Recording
📋 Overview
Session 12 presented Spec-Driven Development (SDD) as an AI engineering harness: a control layer that turns ad hoc code generation into a governed delivery system. Merlin Chen explained why faster code generation is only one part of software delivery. Reliable outcomes also require validated intent, explicit scope, ordered phases, durable artifacts, verification evidence, recovery, and review.
The session combined the underlying engineering principles with a repository-based WiseTech case study. The demonstrated SDD workflow routes work through specification, design, test-driven implementation, verification, and submission gates; persists state outside the chat; integrates with repositories and work items; and supports resuming or correcting an interrupted agent workflow.
🎯 Key Topics Covered
1. AI Coding Is Not Reliable Delivery
AI coding tools are effective at quickly generating first drafts, explaining existing patterns, scaffolding code and tests, and reducing blank-page time. Those capabilities do not automatically provide validated requirements, build and test discipline, reviewable evidence, or recovery when a session loses context.
The delivery gap is therefore a systems problem. Without a harness, an AI can be fast and fluent while still producing the wrong result. Engineering controls are what turn model capability into dependable delivery.
2. The Harness Is the Control Layer
An AI engineering harness wraps the model with the operating system needed for delivery:
| Layer | Responsibility |
|---|---|
| Model | Generation and reasoning |
| Workflow | Ordered phases and orchestration |
| State | Memory, artifacts, and recovery |
| Tools | Repositories, PRs, task systems, and documentation |
| Verification | Builds, tests, review, and evidence |
Merlin connected this design to wider ecosystem patterns such as durable state and human-in-the-loop execution, flow orchestration and tracing, evaluation-driven iteration, regression testing, and red-team guardrails. As models become more capable, the quality of this surrounding control layer becomes more important.
3. Specifications Reduce Ambiguity
SDD inserts an explicit statement of what and why between the initial request and the implementation. That specification anchors later design, coding, and verification in reviewable intent instead of letting the model silently fill gaps.
Skipping this step creates a subtle risk: an agent may confidently implement a coherent but incorrect interpretation. SDD makes the intent explicit and verifiable before coding momentum builds.
4. An Explicit, Phased, and Gated Pipeline
The core SDD pipeline demonstrated seven phases:
| Phase | Purpose | Required outcome |
|---|---|---|
| Init | Establish the branch and runtime state | Canonical working context |
| Validate | Investigate the current system | Evidence and confirmed assumptions |
| Propose | Define the change | Scope and acceptance criteria |
| Design | Plan the implementation | Design and executable tasks |
| Code | Implement the change | TDD-guided code and tests |
| Verify | Check the result | Builds, tests, traceability, and verdict |
| Submit | Hand off the work | Pull requests and delivery context |
Each phase checks that the previous phase left behind the required artifact. If a prerequisite is missing, the workflow stops and routes back to the appropriate earlier command. These hard gates distinguish a governed delivery pipeline from a one-shot assistant.
5. Beyond Prompting: Governance, State, and Evidence
SDD provides controls that persist beyond a single interaction.
Capabilities shown in the repository:
- phase routing, hard gates, and anti-shortcut rules;
- ordered tasks, TDD expectations, and focused build/test scope;
- runtime state in
.sdd.yamland an append-onlyrun-log.jsonlledger; - recovery after interruption using external state rather than chat memory alone;
- durable artifacts such as
context.md,proposal.md,design.md,tasks.md, andverify-report.md; - integration with GitHub PRs, ediProd notes, eDocs, and knowledge sources.
A prompt influences one interaction; the harness governs the complete operating context.
6. Operational Depth and Delivery Realism
The repository extends the basic pipeline with features needed for day-to-day use:
- interactive and full-autonomy modes;
- end-to-end orchestration through an autopilot workflow;
- feedback loops for PR comments and shelf-test failures;
- worktree-aware execution and recovery;
- multi-repository coordination across CargoWise repositories;
- targeted verification instead of brute-force full-solution builds;
- a bundled local dashboard through
/sdd-hub.
This is closer to workflow engineering than prompt engineering. The goal is not simply to produce more code, but to make the delivery process observable, recoverable, and usable across a team.
7. Repository Case Study
Merlin demonstrated the WiseTech sdd repository, including its phase documentation, workflow diagram, worktree dashboard, work-item artifacts, and a carbon-emissions example spanning multiple repositories.
The example showed evidence captured during validation, traceable acceptance criteria, explicit design and task artifacts, and commands for investigating repository and PR state. The workflow could use different AI clients while keeping the engineering process and durable evidence in the repository.
8. Why the Harness Matters
The expected payoff is broader than coding speed:
- Safer autonomy: agents receive more freedom inside clear boundaries and gates.
- Better traceability: reasoning and outcomes remain inspectable through durable artifacts.
- Earlier gap detection: requirement problems surface before implementation accelerates.
- Team scale: delivery depends less on one perfect prompt or one expert engineer.
The core takeaway was that a harness is how teams scale AI safely—not how they slow it down.
📊 Presentations & Materials
Session Recording
🎥 Watch the June 18, 2026 recording
Recording highlights:
- The gap between AI-assisted coding and reliable delivery
- Harness engineering as a control layer around the model
- Spec-first development and ambiguity reduction
- The seven-phase gated SDD pipeline
- Durable state, recovery, artifacts, and integrations
- Operational features for autonomy, worktrees, and multi-repo delivery
- Walkthrough of the WiseTech SDD repository and example work-item artifacts
No standalone presentation files were supplied with the recording. The screenshots above were captured from the session for reference.
🔗 Featured Resources
- WiseTech SDD Repository - Internal repository demonstrated during the session
- Git Worktree Documentation - Multiple working trees used by the SDD workflow
- Agent Skills in VS Code - Reusable instructions and resources for coding-agent workflows
🎮 Quiz Activity
No structured quiz activity or scored quiz was included in the supplied recording.
🏆 Quiz Results & Winners
| Status | Details |
|---|---|
| No ranking published | The recording did not include a scored quiz or winner announcement. |
🔑 Key Insights
- Generation speed is not delivery reliability: requirements, gates, evidence, and recovery remain engineering responsibilities.
- Specifications are a control surface: explicit intent reduces the risk of polished but incorrect implementation.
- Hard gates prevent shortcuts: every phase must leave reviewable evidence for the next phase.
- State must survive the chat: runtime state, logs, and artifacts make work resumable and auditable.
- Verification should be targeted and traceable: build and test evidence should map back to acceptance criteria.
- The harness enables safer autonomy: stronger controls allow teams to grant agents more freedom with less risk.
📚 Further Learning
For Developers
- Write acceptance criteria before asking an agent to implement a change.
- Preserve investigation evidence, design decisions, tasks, and verification results as repository artifacts.
- Use focused tests and changed-project builds rather than treating a generated patch as sufficient evidence.
For Teams
- Define the required artifact and review gate for each delivery phase.
- Treat state and recovery as first-class capabilities for long-running agent work.
- Adopt autonomy gradually: begin interactively, measure evidence quality, then expand orchestration.
🙏 Acknowledgments
Special thanks to:
- Merlin Chen for presenting the SDD framework and repository case study
- Aimee Li for hosting and facilitating the session
- All participants for joining the knowledge-sharing session
Build the system around the model
Use specifications, gates, durable state, and verification evidence to turn model output into a controlled delivery workflow.
Do not skip the evidence-producing phases
An agent can generate plausible code before the requirement is understood. Validate intent and preserve evidence before implementation begins.
Session 12 | June 18, 2026 | SDD — Spec-Driven Development and AI Engineering Harnesses | Merlin Chen