A year ago we were "vibe coding": you vaguely described a need to an agent, got back code that looked right, and prayed. GitHub puts it bluntly: "sometimes the code doesn't compile, sometimes it solves part of the problem but misses the real intent" (GitHub, Spec Kit). The answer taking hold everywhere in 2026 has a name: spec-driven development (SDD).
The principle, as Thoughtworks phrases it: "write a spec before writing code with AI - the spec becomes the source of truth for the human and for the AI" (Birgitta Böckeler, martinfowler.com). At Ippon, the same intuition is framed as a reversal: "the specification becomes the project's source of truth", an operational artefact "consulted and used every day", and no longer "a forgotten document" (Ippon).
If that idea sounds familiar, it should: it is Survol's founding conviction. "The approved spec IS the prompt", we wrote on day one. Watching a whole industry converge on that thesis is, let us say, a pleasant confirmation. But the best analyses go further - and point, without always resolving it, to the real problem.
Why now: the "ambiguity tax"
SDD answers a precise ailment. specdriven.ai gives it a name: the "ambiguity tax" - "the expensive cycles of hallucination and rework caused by vague requirements" (specdriven.ai). Microsoft describes the same phenomenon differently: "teams ship software that works but misses the original intent… the loss of meaning as ideas travel from need to requirements, to architecture, to implementation" (Microsoft Developer Blog).
The practical conclusion is unanimous: align first, accelerate second. "Instead of prompting then correcting, teams align first and let AI accelerate execution from a clear spec" (Microsoft). That is the heart of the matter, and it is a team question as much as a code question: deciding together what "good" means, before launching the agent.
The question almost nobody settles: maintaining the spec
The sharpest analysis of the lot comes from Thoughtworks. Böckeler distinguishes three levels of SDD, rarely made explicit:
- Spec-first: you write a good spec, use it for the task at hand… then forget it.
- Spec-anchored: the spec is kept after the task, to evolve and maintain the feature over time.
- Spec-as-source: the spec is the primary source file; humans only edit the spec, never the code.
And here is her observation, which we consider the blind spot of SDD as it is tooled today:
"All the SDD approaches I found are spec-first, but not all of them aim to be spec-anchored or spec-as-source. And often, what the spec's maintenance strategy over time should be is left vague, or entirely open." - Birgitta Böckeler, Thoughtworks
Translation: most SDD tools can help you write a fine spec to start a task. Almost none answers the question that matters over the life of a real product - who updates the spec when the feature evolves, who links it to shipped versions, who guarantees it stays the truth and does not become that "forgotten document" Ippon warned about? Writing a spec is a gesture. Keeping it alive is a system.
That is precisely Survol's promise. With us, the spec is not a markdown file sitting next to the code, surviving only on a developer's discipline. It is a first-class product object: every feature carries its spec, versioned, linked to its shipped versions (v1.0, v1.1, v2.0…) and to the decisions that shaped it. Spec-anchored by construction - the spec lives as long as the product does.
The guardrails: the project's "constitution"
The second building block common to every SDD tool: a base of persistent rules. specdriven.ai calls it the "constitution" - a constitution.md that "establishes the project's permanent principles (tech stack, code standards, security rules) serving as immutable context for all AI operations". At AWS the logic is the same, taken a step further: teach the agent your conventions once and for all via a CLAUDE.md, hooks, and skills - reusable instruction files - packaged into shareable plugins (Gunnar Grosch, AWS Builder). The guiding idea, he says: "so you never explain the same workflows again in every session".
Excellent principle - but inside a team, who owns those files and keeps them current? If they live in the repository, by hand, they drift: every developer has their own version, and yesterday's security rule is no longer injected today. Survol treats that base for what it is: governance infrastructure. Our organisation technical constraints - security, libraries, conventions - are injected automatically at the start of every agent session, at three levels (mandatory, strong, preference), with every application logged. And the agent's guidance files (CLAUDE.md-style, skills) can be managed from Survol as well as from the source code - one truth, never drifting. The "constitution" stops being a pious wish; it applies itself.
The real bottleneck: human review
That leaves the costliest blind spot, and this one has numbers. SDD shifts the developer's role: from "coder" to "architect and reviewer" (specdriven.ai). Wonderful - except that review then becomes the limiting factor. The data is blunt: across 10,000+ developers, teams with high AI adoption "complete 21% more tasks and merge 98% more pull requests - but PR review time rises by 91%, creating a critical bottleneck at human approval" (C.J. Roth, citing Faros AI's Productivity Paradox Report). It is Amdahl's law applied to software: the system goes no faster than its slowest link. And that link, now, is the human who approves.
A clear spec already reduces that cost - you review against explicit intent, not against a gut feeling. But Survol goes further by tooling the review itself, instead of leaving it to a lead's heroism:
- A preview to approve on every version, before any merge - you test the intent, not lines of diff.
- Acceptance test books, run by a human on an identified environment: verification is structured, traceable, reusable.
- Expert reviews on demand - a report readable by a non-developer, where each finding becomes a task for the agent in one click.
The same report notes that AI gains go overwhelmingly to senior engineers - "nearly five times" those of juniors - because they "know what good code looks like" and can therefore review and correct efficiently (Addy Osmani, quoted by C.J. Roth). A platform that structures review is a way of spreading that judgement beyond the seniors alone - and it is also why our expert reviews exist.
Where Survol changes things: SDD as a team sport
Here is the thread running through all these sources. Today's SDD tools - Spec Kit, Kiro, Tessl and friends - are first and foremost developer tools, in a terminal, one task at a time. They are excellent at that. But the spec stays a technical file, whose maintenance is "left vague", whose guardrails depend on individual discipline, and whose review clogs up a single human.
Survol takes the same principle - the spec as source of truth - and scales it to a product and a team:
- The spec is a product object, not a file: written in plain language, discussed, versioned, linked to shipped versions. Spec-anchored by default.
- Alignment precedes execution: product decisions are settled as a team - dated, voted on, attached to the feature - before the agent is launched. Microsoft's "align first", with tooling.
- Guardrails are infrastructure: constraints injected into every session, guidance files managed centrally.
- Review is structured: previews, test books, expert reports - to loosen the bottleneck everyone observes.
- Non-technical people genuinely steer: because the spec is the interface, a PM, an executive or a founder with no technical team can orchestrate the agent without writing a line of code.
The takeaway
- Spec-driven development is winning: the spec, not the prompt nor the code, becomes AI's source of truth. GitHub, Microsoft, Thoughtworks and AWS all confirm it.
- The blind spot, flagged by Thoughtworks: maintaining the spec over time is almost always "left vague". Writing a spec is a gesture; keeping it alive is a system.
- Two underrated pieces of work: guardrails that genuinely apply (the "constitution"), and human review that does not clog up (91% more review time, per Faros AI).
- Survol answers all three: the spec anchored as a product object, constraints injected and administered, review tooled - SDD out of the terminal and turned into a team sport.
"As AI commoditises code generation, the engineering bottleneck has moved from writing syntax to defining intent" (specdriven.ai). We could not agree more - and we would add: defining intent, keeping it alive, surrounding it with guardrails and having it reviewed is continuous team work that deserves better than a file in a corner of the repository. That work is what Survol equips.
Sources: B. Böckeler, "Understanding Spec-Driven Development", martinfowler.com · GitHub, "Spec-driven development with AI" (Spec Kit) · Microsoft Developer Blog · specdriven.ai · Ippon · H. Park, "Using spec-driven development with Claude Code" · G. Grosch, AWS Builder · C.J. Roth, "Building an Elite AI Engineering Culture".
