Ã… skape fremragende programvare
La oss bygge noe ekstraordinært sammen.
Stol på Lasting Dynamics for enestående programvarekvalitet.
Mohamed Boukrim
okt 29, 2026 • 10 min read
In September 2025 Birgitta Böckeler, a Distinguished Engineer at Thoughtworks, tried three tools built for spec-driven development: the idea that an AI coding agent should work from a written specification rather than a chat prompt, and one test in her write-up says more than the rest. The agent did thorough research on the existing code and wrote notes describing the classes that were already there. Then it ignored the fact that those classes existed, treated the notes as a new specification and generated them all over again, creating duplicates.
Nothing was missing from those notes: they said the classes already existed, and the agent read past it. Böckeler files the episode under the question of whether specs give a "false sense of control", and that is the honest place to start. A written spec does not guarantee that an agent builds the right thing. What it gives you is something to check the result against, which a prompt lost in a chat window never will. GitHub made a related point when it launched its Spec Kit toolkit, describing coding agents as tools that excel at pattern recognition but still need unambiguous instructions.
For whoever pays for the software, this changes what is worth owning. Code produced by an agent is hard for a non-developer to read, and there is a lot of it, whereas the spec is the one part of AI-built software a buyer can actually read, check and sign. This article looks at spec-driven development from that chair, covering what it changes in a contract, where it doubles as evidence and where it becomes plain overhead, along with the three questions we would ask any software partner before buying.
Spec-driven development is a way of building software with AI agents in which a written specification comes before any code. The spec describes what the software must do, how anyone can tell that it is done, and what is deliberately left out; the agent generates code from it, and people check the result against it.
Microsoft's developer blog calls structured specs “the shared source of truth for both humans and AI” and sums up what its teams learned in one line, “Spec for both humans and AI". It sums up what its teams learned in one line: "Spec quality = output quality.” Simple as that sounds, the label covers several quite different practices, which Böckeler sorts into three levels of ambition.
At the most modest level, spec-first, a spec is written for a task and set aside once the task is done. Spec-anchored work keeps the spec and updates it as the feature evolves, while spec-as-source goes all the way, so that people edit only the spec and never touch the code. Every approach she examined was spec-first, and not all of them aimed any higher.
That distinction is the one a buyer should care about, because unless a supplier commits otherwise, the spec is likely to go stale after delivery: nobody was asked, or paid, to keep it current. If you want a spec you can still rely on in two years, write that into the agreement.
The spec-driven development tools on the market vary widely. GitHub Spec Kit, Amazon's Kiro and the open-source OpenSpec all organize work around written specs, and Tessl, whose framework Böckeler tested in private beta, went furthest toward spec-as-source. They are named here for orientation and not as a ranking, since for a buyer the choice of tool matters far less than what happens to the spec once the work is delivered.
Calling all this waterfall with a new name misses how it is practiced today. A spec is written per change, often for a single feature or fix, and reviewed just before the agent runs, instead of being signed off as one large document months ahead of delivery.
When code costs almost nothing to generate, the scarce thing is a clear description of what should be generated. Our piece on the AI productivity paradox traced where the time goes once AI writes a large share of the code: the effort did not vanish but moved into specification, review, integration and rework.
La oss bygge noe ekstraordinært sammen.
Stol på Lasting Dynamics for enestående programvarekvalitet.
Spec-driven development is simply the name the industry gave to that shift. The part of the work that was already growing, deciding and describing what to build, becomes an explicit, versioned step instead of something scattered across chat windows, tickets and people's memory. GitHub argues that requirements such as security policies and compliance rules, which often live in someone's head or in a wiki nobody reads, belong in that spec, where an agent can actually use them.
Good teams have always written requirements, so the spec itself is nothing new. What has changed is the reader, a machine that acts on the text literally and turns every gap into software instead of a question.
GitHub describes a spec as “a contract for how your code should behave”, a line that reads very differently to a buyer than to a developer. For anyone who commissions software, spec-driven development changes what you can hold a supplier to, because the spec is versioned and stored next to the code it produced.
Acceptance criteria written before the agent runs can be read and signed off by someone who has never opened the code. “A customer who enters an invalid VAT number sees an error, and no order is created” is something a product owner can verify in a minute. When criteria like that exist before delivery, acceptance stops being a matter of opinion at the end of a project and becomes a comparison against what both sides agreed at the start.
The commercial model is where this pays off most, whichever side of the fixed price vs time and materials debate you are on. A fixed price is only defensible when the scope is explicit, including what is deliberately left out, and a change request is only visible against a written baseline. Under time and materials, the spec shows what the hours bought and whether the result matches the request, and in both cases it brings scope disagreements to the surface early, while they are still cheap to settle.
That leads to the three questions we would put to any partner building software with AI agents. Ask whether you will receive the specs as well as the code, in a form you can read and keep, and ask who writes them and who on your side approves them at each change. Then ask how a change to the spec is agreed and priced, because the answer is what turns changing your mind into a visible decision instead of an argument about what was meant.
New frontier models keep arriving: three were released on 22 September 2026 alone, as our look at how to read AI benchmarks showed. Partners change too, and a written spec outlives both, so switching means handing over documents and tests, with no need to reverse-engineer what the previous team had in mind.
Spec-driven development has a side effect that auditors will appreciate: a spec kept in version control doubles as documentation. Each change carries a record of what was intended, who approved it and when, produced as a by-product of the work and not reconstructed later, when someone asks for it.
Regulation now asks for that kind of record explicitly. Under the Cyber Resilience Act, Regulation (EU) 2024/2847, manufacturers of products with digital elements must draw up technical documentation containing at least the elements listed in Annex VII (Article 31). Point 2(a) of that annex covers the design and development of the product, including a description of the system architecture. Most of the regulation applies from 11 December 2027, and our guide to the Cyber Resilience Act covers the rest.
Fra idé til lansering lager vi skalerbar programvare som er skreddersydd til dine forretningsbehov.
Samarbeid med oss for å akselerere veksten din.
To be precise about the claim, a kept, versioned spec makes this documentation cheaper to produce and easier to trust because it was written at the time, not after the fact. It does not make anyone compliant, nor does it replace the risk assessment or the vulnerability handling the regulation also asks for.
Inside the company, the same record settles a different question: when AI-built software causes a problem, people want to know who decided what it should do, and a signed spec answers that. Our piece on who decides how AI is used in a company covers the organizational side of that accountability.
The strongest critics of spec-driven development are people who tried it seriously, and their objections deserve a fair hearing before anyone signs up for it.
When Böckeler asked Kiro to fix a small bug, the workflow turned it into four user stories with sixteen acceptance criteria, which she described as “like using a sledgehammer to crack a nut”. With Spec Kit, the volume of markdown files to review led her to conclude: “I'd rather review code than all these markdown files.” Her tests date from September 2025, and she notes that the tools change quickly, but her underlying point, that the process has to fit the size of the change, still holds. Even Microsoft's broadly positive write-up warns that not every change needs the full lifecycle.
False confidence is the subtler risk, as the duplicated classes in the opening showed: even with detailed specs, templates and checklists Böckeler frequently saw agents ignore some instructions and follow others too eagerly. A spec reduces the guessing an agent does, but it does not remove the need to review what it produced.
Model-driven development offers a precedent worth remembering: it promised that people would edit models and generate code from them, and it never took off for business applications. Böckeler warns that the most ambitious form of the new approach, where only the spec is edited, could inherit the downsides of both: the inflexibility of model-driven development and the unpredictability of language models.
Thoughtworks placed spec-driven development in the Assess ring of its Technology Radar in November 2025, a ring it defines as "worth exploring with the goal of understanding how it will affect your enterprise", and noted that the workflows remain elaborate and opinionated. Meanwhile the term itself is drifting, and Böckeler has heard people use “spec” as a synonym for “detailed prompt”, which it is not: a spec is a document that people review, agree on and keep, with acceptance criteria someone can test.
The practical lesson for a buyer is that a heavy spec process proposed for a two-line fix is cost, not quality.
Whether spec-driven development is worth it for a given change depends on how expensive a wrong guess would be, how long the software will live and how many people have to agree that it is done. Rework is rarely cheap, as we have written about the real cost of poor software quality, so the closer the answers get to “very”, “years” and “several people”, the faster a spec pays for itself.
Vi designer og bygger digitale produkter av høy kvalitet som skiller seg ut.
PÃ¥litelighet, ytelse og innovasjon i alle ledd.
| Type of change | Is a spec worth it? | Why |
|---|---|---|
| Small bug fix or text change | Rarely | A short ticket and a review are enough; a full spec costs more than the change. |
| Visual tweak on an existing screen | Usually not | A screenshot and a sentence of intent do the job, unless the change touches business rules. |
| New feature with business rules | Ja | The rules are exactly what an agent would otherwise guess, and what you will check at acceptance. |
| Anything touching payments, personal data or access control | Always | A wrong guess is expensive, regulated or both, and the spec is your record of what was intended. |
In buyer language, a good spec defines done in terms someone can test and is explicit about what is out of scope. It also records the constraints that apply, from data that must stay in the EU to regulatory requirements and response times, and it describes what should happen when something fails, whether that is a rejected payment or a supplier system that does not answer.
Writing it is a joint job: the buyer contributes the business rules and the acceptance criteria, not the technical design, and engineering turns those into a plan an agent can execute. A spec written only by engineers tends to describe the solution they already had in mind, while one written only by the business tends to leave out what the agent needs to know. If you are still testing whether an idea is worth building at all, a minste levedyktige produkt comes first, and its spec can be much lighter.
The usual framing, vibe coding vs spec-driven development, suggests two opposites, but the two are better seen as the ends of one dial. Vibe coding means describing what you want in conversation and accepting what the agent produces, and even GitHub's launch post says it can be great for quick prototypes while being less reliable for serious, mission-critical applications or existing codebases.
That makes vibe coding a sound choice for throwaway prototypes, internal experiments and demos meant to answer a question. The trouble starts when a prototype becomes a product without anyone writing down what it was supposed to do, because from then on the only description of the software is the software itself, and every later change is a guess about intent.
The skill lies in knowing where each change sits on that dial, since spec-driven development is cheap insurance exactly where a wrong guess is expensive and an unnecessary cost everywhere else.
About to commission software built with AI agents and not sure what to ask for besides the code? Tell us what you are planning.
This article was written by Mohamed Boukrim at Lasting Dynamics, an EU-based custom software development company that also builds AI software. It is written for the person who approves software rather than the person who writes it, because that is where a written spec changes the most. The sources above are dated and linked, so you can check whether they still hold when you read this. The three questions are yours to ask, and the answers are yours to judge.
It is a way of building software with AI agents in which a written specification comes first. The spec states what the software must do, how to test that it is done and what is out of scope; the agent generates code from it, and people check the result against it.
No. In waterfall, one large specification is written at the start of a project. Spec-driven development instead writes a spec for each change, often a single feature or fix, and reviews it before an AI agent implements it.
Vibe coding means describing what you want in conversation and accepting what the agent produces, which suits prototypes. Spec-driven development writes down the requirements and acceptance criteria first, which suits software that will live for years or where a wrong guess is expensive.
Yes. GitHub's Spec Kit works with Claude Code, GitHub Copilot and Gemini CLI, and open-source alternatives such as OpenSpec support many other coding assistants. The tool matters less than whether the specs are kept, reviewed and handed over to you.
Forvandle dristige ideer til kraftfulle applikasjoner.
La oss skape programvare som gjør en forskjell sammen.
Mohamed Boukrim
I am a Software Engineer and Backend Developer with a relentless focus on software quality and robust architecture. I don't believe in shortcuts; outstanding results are the direct product of daily commitment and hard work. Alongside my team, I leverage Agile methodologies and continuous process evaluation to push boundaries and optimize performance. I approach every challenge with a highly competitive mindset: I work tirelessly to reach the top, and once there, I keep pushing to maintain the lead.
