A developer on Hacker News is advocating for a shift from 'spec-driven' to 'development-driven' specifications, a method where the process of writing documentation and writing code are inseparable. By building the specification in real-time alongside the software, the developer creates an 'executable specification' that an AI coding agent can use to autonomously generate and iterate on new versions of the codebase.
The Development-Driven Workflow
The poster, WaywardGeek, describes a process where they engage in an up-front design conversation with an AI agent. They then ask the AI to generate only the 'TL;DR' and exercise sections of a project, such as a book chapter.
During the implementation phase, the developer pair-programs with the AI to write the actual code. As they work, they write notes to clarify ambiguities and steer the AI toward the intended design in real-time.
Once the code passes specific 'exercise graders,' the developer asks the AI to read these accumulated notes and a 'voice.md' file to write the final body of the chapter. This ensures the documentation accurately reflects the final implementation.
Executable Specifications and AI Autonomy
The core innovation of this approach is the creation of an 'executable specification.' WaywardGeek argues that because the spec is built as the code is written, it becomes a high-fidelity instruction set for an AI agent.
In practice, this allows an AI coding agent—such as the 'Ensemble' project—to execute the specification autonomously. The agent can then generate a new version of the code based on the updated specifications without manual intervention for every step.
The developer highlights a recursive example: they used this method to create a book about building AI coding agents, which the agent then used to build the next edition of that same book.
Community Feedback and Scalability Questions
Commenters on Hacker News expressed interest in the mechanics of the approach but raised questions about its practical application. One commenter, writing as defenestration, asked how this method would function within a larger team that relies on a 'regular' ticket-based software development workflow.
Another commenter, grugagag, requested a concrete demo of the process being used to build a standard business application to better understand the final results. The discussion highlighted a need for more clarity on how this moves beyond a personal workflow into a collaborative environment.
While the poster claims the method has been highly successful for personal projects, the specific trade-offs and limitations regarding team-wide adoption remain an open question in the discussion.
Uncertainties in Team Integration
A primary uncertainty remains regarding how 'development-driven' specs scale. Because the method relies on a tight, iterative loop between a human and an AI agent, it is unclear how it would integrate with standard project management tools like Jira or GitHub Issues.
The sources do not provide a detailed framework for how multiple developers would contribute to a single 'living' specification without creating versioning conflicts or communication bottlenecks.
