Spec-Driven Development: write the spec before you write the code
AI coding tools are everywhere. Salesforce reports that over 90% of its 20,000 developers now use them daily. TELUS shipped 30% faster and saved over 500,000 engineering hours. Zapier runs 800 internal agents with 89% organisational adoption.
Most teams have the tools. Few have a disciplined way to work with them. At INFO, we use Spec-Driven Development, a practice that treats the specification as the primary artifact, written before any code. Across projects, it has consistently cut delivery timelines from months to weeks.
Start at the finish
Before we write a single line of product code, we write a spec. A specification is a piece of text written in Markdown. It’s stored in a place that every stakeholder can access in order to debate and edit. The spec describes what we’re building, why, and what ‘done’ looks like: goals, constraints, assumptions, success criteria, and what we’re explicitly not building.
When we can’t write a spec precisely, we don’t yet fully understand the work. Better to find that out in 25 minutes at the spec stage than after implementation, when the same misalignment can cost you days in corrections.
Three levels, one shared picture
We decompose every project into three levels: an initiative spec covers the goal, constraints and success criteria, reviewed with stakeholders before anything else moves.
Feature specs describe discrete requirements, reviewed by the team, before implementation starts.
Task specs are the smallest of the three: one endpoint, one component, one migration, scoped so it can be completed in one focused run.
Writing specs together with your team quickly leads to a shared understanding. This kind of alignment is hard to achieve in only a kick-off meeting. It happens when both sides work through the same document and commit to a specification before anything gets built.
Let the spec run the agents
Time to conduct the orchestra. Now, prompting an AI without structure works fine for small, isolated tasks. It falls apart when complexity grows. Spec-Driven Development allows you to prompt AI even when the context is elaborate.
Every team has been there. The requirement that seemed obvious until it wasn’t: the edge case. The unusual situation nobody thought to plan for. The feature that made perfect sense in the brief, and none once it was built.
Writing specs up front captures a part of these situations, the other parts will show up when you’re building.
What works is treating the spec as a working hypothesis. You refine it at each checkpoint. The AI executes against it. Automated tests validate against it. When something misaligns, you update the spec, not just the code.
That loop means bugs trigger spec updates instead of patches. Misalignments become short conversations instead of expensive incidents.
We still make the calls. The spec defines where our judgment gets applied and makes it visible to everyone involved, including the agents doing the work. At INFO, that’s a deliberate choice: engineers, designers and product managers stay in control.
What the team actually produces
Designers move from creating static mock-ups to working component libraries where developers can build on directly. A handoff cycle that normally takes days, largely disappears.
This is where Spec-Driven Development is heading: product managers writing feature specs that close the gap between what’s wanted and what gets built. QA engineers contributing with precise edge cases and error state assertions, which agents translate directly into test suites. Engineers orchestrating, reviewing, and owning the output.
On FLEX+, we applied Spec-Driven Development to turn Resourcefully’s internal energy consultancy tool into a scalable SaaS. From the moment we started implementing, the pace held.
Within six weeks we delivered a shippable platform, against an expected timeline of six to twelve months. FLEX+ is ready to venture out, with five organisations keen to onboard.
Slow down to ship faster
Spec-Driven Development asks you to slow down before you speed up. Before a single line of code gets written, we make sure we fully understand what we’re building and why. That takes discipline. The first days on a new project are mostly writing and aligning, not shipping. That is intentional.
One risk is worth naming upfront: specs encode what you believe to be true, including the things you don’t yet know you’re missing. A well-written spec can amplify a misunderstanding just as easily as it can prevent one.
The answer is to treat the spec as a living document. Every misalignment is a reason to sharpen it, not abandon it.
The teams that ship fastest in the next few years won’t be the ones with the most AI tools. It’ll be the ones who know how to orchestrate them. Spec-Driven Development is at the core of that orchestration. And it’s how we work.
INFO helps your organization ship faster with Spec-Driven Development. Get in touch and scale up now.