# Development-Driven Specifications for AI Coding Agents

Building executable knowledge through iterative pair programming with AI systems.

- **Source:** [Hacker News: Front Page](https://brifing.si/source/b07aa772-b1a0-4a76-aa18-719c6f9e2dde)
- **Published:** 2026-11-08
- **Topic:** [technology](https://brifing.si/c/technology)
- **Original article:** <https://github.com/waywardgeek/ensemble>
- **On Brifing:** https://brifing.si/s/d27cf1e4-4eec-45f8-9e64-9f1b55d60146

## Redefining Software Specifications

The Ensemble project introduces Development-Driven Specifications, shifting away from static, upfront documentation. Instead of writing detailed plans before coding, developers pair-program with AI to build systems. This approach treats the resulting code as an output, while the primary asset becomes the reusable knowledge required to reconstruct the system from scratch.

## Evolution Through Iteration

Ensemble V3 is built using C# 14 and .NET 10, developed entirely within the previous V2 environment. This recursive development process allows Bill Cox and the Cadence agent to improve both the teaching material and the agent itself. Each edition preserves specific verification limits to ensure consistent learning outcomes across versions.

## Executable Knowledge Transfer

The goal is to create an executable specification, which functions as a codebook transferring engineering judgment rather than just a feature list. By building the code and the specification simultaneously, the human developer gains expertise during the process. This prevents the common pitfall of relying on final inspections of unfamiliar AI-generated code.

## Technical Build Requirements

Building the Ensemble application requires a .NET 10 SDK, as the runtime alone is insufficient. The repository provides specific Make targets for building the GUI or terminal client. Users must ensure the SDK is correctly located in their shell's PATH or provide an explicit override path to the compiler during the build.

## Testing and Regression Framework

The project utilizes a dual-language testing strategy, with C# used for regression executables and Go tooling for graders and local providers. The make test command executes both suites, while make test-go targets only the Go components. This separation ensures that the active runtime remains distinct from the supporting publication and grading infrastructure.

## Grading and Historical Snapshots

Each chapter includes documented executable commands and specific grading scopes, such as the 65 points defined for Chapter 5. Historical snapshots from Edition 1 and Edition 2 are preserved in their respective directories. These archives are not rewritten, ensuring that original grading metrics remain valid for those specific historical manuscript versions.

## Manuscript and Publication Workflow

The system supports automated manuscript assembly, allowing users to generate EPUB or PDF versions using make book commands. These publishing tools operate locally without requiring external installations. Importantly, source code edits do not automatically trigger book updates; publication remains a distinct, manual step separate from the core development and promotion process.

## The Puffin Book Context

The Puffin book serves as the working environment for Gateway, Connections, and security-focused Watchtower tasks. It strictly follows the Development-Driven Specs methodology, where outlines remain provisional rather than fixed feature sets. This structure reinforces the project's philosophy that coding agents should be built through continuous learning rather than rigid, pre-defined requirements.

## Sources covering this story

- https://github.com/waywardgeek/ensemble — 

---

_Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._
