Treating the Spec as an Interface: What GSD Gets Right About AI Workflow Design

The core tension in AI-assisted development is that the tools are good at writing code but indifferent to the workflow around it. You get autocomplete at industrial scale, but the question of what to build, in what order, with what constraints, remains entirely on you. Get Shit Done (GSD), a meta-prompting and spec-driven development system that surfaced on Hacker News this week with 237 points and 128 comments, is an attempt to address that gap directly.

The system sits above your AI coding tool, not inside it. Its job is to maintain structured specifications, manage context deliberately, and use meta-prompting to generate the precise instructions that your AI assistant actually receives. That framing is more interesting than it first appears.

The Three Layers

GSD operates on three distinct layers that map onto three different problems in AI-assisted development.

The first is the spec layer. Before any code is written, GSD asks you to define what you’re building in a structured format. This is not README-style documentation; it is closer to a formal interface definition. The spec captures requirements, constraints, acceptance criteria, and architectural decisions. It becomes the source of truth that the rest of the system derives from.

The second is the context layer. Large language models have bounded context windows, and what you put in that window determines the quality of what comes out. Context engineering, a term that has gained traction as a distinct discipline from prompt engineering, is about curating that window deliberately rather than letting it fill up with whatever the conversation happens to produce. GSD treats context as a managed resource, deciding which files, which documentation, and which prior decisions belong in each AI invocation.

The third is the meta-prompting layer. Rather than writing prompts by hand for each task, GSD generates them from the spec. The spec is parameterized; the meta-prompt is a template that takes spec fields as inputs and produces a structured instruction set for the AI. This makes the instructions reproducible and reviewable, not just one-off strings typed into a chat interface.

What Meta-Prompting Actually Solves

The term “meta-prompting” can mean several things depending on context. In academic usage, it often refers to prompting a model to generate its own prompts, a technique explored in work by Google DeepMind and others on self-referential prompt generation. In GSD’s usage, it is closer to prompt compilation: you write a high-level spec, and the system compiles it into a structured prompt suited for the specific task at hand.

This distinction matters because it changes where the human’s cognitive work happens. Writing a good ad-hoc prompt requires holding the entire context of the task in your head while also thinking about how to phrase it for an LLM. Meta-prompting lets you separate those concerns. You think about what you want at the spec level, and the system handles the translation.

The closest prior art is probably Anthropic’s CLAUDE.md convention, where you put project-level instructions in a file that gets included in every AI invocation. GSD generalizes this idea: instead of a single static file, you have a dynamic system that generates context from a living spec. Cursor’s .cursorrules files serve a similar purpose at the project level, but again statically. GSD is arguing that static rules are not sufficient for complex, multi-session development work.

The Spec-as-Interface Concept

The most useful frame for understanding GSD is to treat the spec not as documentation but as an interface. In software engineering, an interface defines a contract: what inputs a component accepts, what outputs it produces, what invariants it maintains. GSD’s specs play the same role between the developer and the AI.

When you write a function signature before implementing it, you are constraining what the implementation can be. The spec does the same thing at a higher level. It constrains what code the AI generates, what files it touches, what patterns it uses, and what it considers out of scope. That constraint is valuable precisely because AI coding tools, left unconstrained, will happily solve adjacent problems, introduce unnecessary abstractions, or drift toward patterns that are not appropriate for the project.

This connects to a well-documented failure mode in agentic AI workflows: context drift. Over a long session, as conversation history accumulates and the context window fills, the model’s behavior shifts. Early instructions get diluted by later exchanges. The AI starts optimizing for the immediate conversation rather than the original requirements. Maintaining a structured spec that gets reinjected into context at each step is a direct mitigation for this.

A concrete example: suppose you are building a Discord bot with a specific permission model and command structure. Without a spec in context, asking an AI to “add a moderation command” produces something that works in isolation but may not fit the existing architecture, the error handling conventions, or the state management approach you have already established. With the spec in context, the AI is working against a defined interface rather than inferring one from whatever files happen to be in the window.

Comparison to Adjacent Approaches

Behavior-driven development tools like Cucumber take a similar approach: write human-readable specifications first, then generate or implement the code that satisfies them. The difference is that BDD specs are ultimately test specifications, executable assertions about system behavior. GSD specs are generative, feeding into code production rather than code verification. The two approaches are complementary rather than competing.

Test-driven development has a comparable adoption curve problem. The workflow requires discipline that produces value primarily over time, and the upfront cost feels higher than the immediate benefit. GSD will face the same friction. Writing a thorough spec before coding feels slower than just starting, and the benefits, fewer AI hallucinations, more coherent output, easier iteration across sessions, compound rather than appear immediately. Every productivity methodology that requires upfront investment has faced this exact skepticism.

Aider, a popular open-source AI coding tool, handles context through a different mechanism: you explicitly add files to the context, and Aider maintains a repository map using ctags to navigate the codebase intelligently. That is context engineering from the bottom up, starting with the code. GSD’s approach is top-down, starting with the spec and deriving the necessary context from it. Both approaches acknowledge that context management is a first-class concern; they just start from different points in the development lifecycle.

Simon Willison’s writing on context windows and the broader discussion around “context engineering” as a field have been making the same argument GSD embodies in code: the quality of LLM output is largely a function of context quality, and treating context as an afterthought is where most AI coding workflows currently fail.

What the Hacker News Discussion Reveals

With 128 comments and 237 points, the GSD thread generated substantial engagement. The skeptical view, predictable for HN, is that this is elaborate scaffolding around a problem that better tool integration should eventually solve natively. If AI coding tools handled context management and spec adherence natively, you would not need a separate system for it. That criticism is fair as far as it goes, but it is also an argument for waiting rather than shipping.

The more substantive concern is about maintenance overhead. GSD asks you to maintain a spec as a living document, update it as requirements change, and keep it synchronized with the codebase. That is real work. In a solo project or a small team with strong discipline, it is tractable. In a larger or faster-moving codebase, keeping the spec authoritative becomes its own coordination problem, and a stale spec may be worse than no spec.

The Adoption Problem

GSD is, at its core, a workflow proposal. Like TDD, like code review, like architecture decision records, it asks you to do more work upfront in exchange for compounding benefits over time. The systems that succeed in this category tend to be the ones that integrate into existing tools smoothly and deliver visible payoff quickly enough to justify the initial investment.

The question for GSD is whether the spec format and meta-prompting layer are legible enough to be maintained across a team, not just by an individual. If the spec is only as good as the person writing it, and if writing it well requires specialized knowledge, then the tool is solving one problem while creating a dependency. The most durable version of this approach would have a spec format simple enough that any contributor can update it correctly, and a meta-prompting layer opaque enough that they never need to think about it.

That is a narrow target. It is also the right one to aim for, and the fact that this system exists, has been open-sourced, and has attracted genuine discussion suggests there is real demand for something in this space. Whether GSD specifically is the answer matters less than the question it is asking: if the AI can write the code, who writes the contract the AI is writing against?