A year ago, the prevailing wisdom was that AI coding agents would replace specifications. Why write a spec when you can just describe what you want and let the agent figure it out? That experiment ran. The results are in. And now there's a growing counter-movement: spec-driven development has its own subreddit, new tools like OpenSpec, SpecKit, and BMAD are appearing weekly, and the conversation across Reddit communities from r/ClaudeCode to r/microsaas has shifted from "how do I prompt better" to "how do I structure context better." The instinct is right. The execution, in most cases, is still wrong. The pattern is consistent across every community where people build real products with AI. The first project goes great — it's small enough to hold in your head, and the agent can infer enough from a simple prompt. The second project hits a wall. Complexity compounds, agents start contradicting each other across sessions, and the builder realizes they've been the specification layer all along — carrying context between conversations manually, catching misalignment by reading diffs, hoping nothing drifted. A former engineering director on Reddit, now deep in Cursor daily, noted that traditional agile practices — "iterative and incremental design, user stories, TDD, continuous review" — are "extremely helpful and really essential when developing with AI." Not despite AI making development faster, but because of it. Specs are back because speed without structure produces chaos. The faster you can build, the more damage a misaligned foundation causes. The current wave of spec-driven tools mostly treats specifications as documents — long markdown files that describe what to build, then get passed to an agent as context. This is better than nothing, but it recreates the PRD problem at a different scale: too much irrelevant context, no hierarchy, and no connection between the spec and the actual structure of the product being built. The agents that perform best don't work from a single monolithic spec. They work from scoped context — the specific facts, assumptions, and constraints relevant to the exact feature being built, nothing more. Research and real-world experience both point the same direction: agents need focused context packages, not comprehensive documents. The other gap: most spec tools are static. You write the spec, then build. But building reveals new information — assumptions turn out wrong, dependencies surface, requirements shift. A spec that doesn't update as you build becomes stale the moment the first agent runs. Dossier takes a different approach to the specification problem. Instead of a document, it uses a hierarchical product map — Product → Workflows → Functionalities — where each node carries its own structured context: known facts, active assumptions, and open questions. When you build a feature, the agent receives only the context relevant to that specific functionality. When you learn something new during a build, it feeds back into the map as context for future iterations. The specification isn't a static artifact — it's a living structure that evolves alongside the product. The key insight: forcing agents to surface assumptions and questions before coding starts is where the quality improvement actually happens. Not in the spec itself, but in the structured conversation between builder and agent that the spec enables. Spec-driven development is having a moment because the community is learning what works at scale. The tools that survive will be the ones that treat specifications as living, hierarchical, agent-ready context — not just longer prompts. Dossier is free and open source.