The temptation with agentic coding tools is to skip the spec and go straight to the prompt. The model is right there. It writes code faster than you can describe it. Why would you spend a day writing down what you want when you can just ask for it?
Two years of running delivery this way have given us a clear answer. The spec wins every time. Not because prompts are weak, but because of what a prompt cannot hold.
A prompt is a conversation, and conversations evaporate. The intent behind a feature lives in the chat history of whoever prompted it. When that person moves on, or the thread scrolls away, the reasoning goes with it. Six weeks later, nobody can say why the system behaves the way it does, only that it does.
A prompt also has no definition of done. The model produces something that looks right, and looking right becomes the acceptance criterion. There is no testable statement of what the feature must do, so there is nothing to verify against, nothing to regression-test, and nothing to hold the next change accountable to.
And a prompt does not propagate. Real products change. A pricing rule shifts, a persona gets refined, a compliance requirement lands. In a prompt-driven build, each change is a new conversation that may or may not account for every place the old decision touched. Drift is not a risk. It is the default.
A specification written as business rules and executable acceptance criteria is not documentation about the product. It is the contract the product is built and verified against. When the code passes, done means something. Every requirement traces back to the intent that created it and forward to the code and tests that implement it, so when a stakeholder asks why the system works the way it does, there is an answer, and when a rule changes, the blast radius is visible before anyone writes code.
Here is the part that surprises people: the agents themselves are the biggest beneficiaries. Agentic tools are dramatically better when they work from a spec. A model prompted with a complete specification, business rules, data model, API contracts, produces code that fits the system around it. A model prompted with vibes produces code that fits the conversation. The spec is not overhead on the AI. It is the input that makes the AI reliable.
This is the position we run our own delivery on: intent captured as a connected, testable specification at discovery, held as the single source of truth from estimate through release, with changes propagating across every connected deliverable. The specification is not what you write after the fact. It is the artifact the product is built from. AI accelerates how the work gets built. People decide what gets built. The spec is where those two meet.
If your team is shipping fast with agentic tools and starting to feel the ground shift underneath, the fix is not to slow the tools down. It is to give them, and your people, a ground truth worth building on. The teams that treat specification as a first-class engineering discipline will look back on this era the way we now look back on version control: not as process overhead, but as the thing that made everything else possible.