In a single year, spec-driven development went from buzzword to having its death certificate signed. Three articles trace that arc, and read back to back they leave a more useful question than whether SDD works: which process each kind of change deserves, and who checks that what was built is what was asked for.
I read them with ALDC in mind, and with how work actually gets done at a Business Central partner. They proved me right on some things and forced me to change others.
Three moments in the same debate
In October 2025, Birgitta Böckeler (Thoughtworks) tried Kiro, spec-kit and Tessl and brought some order to the term. She described three levels: writing the spec before the code, keeping it alive as the feature evolves, or making it the only file a human ever edits. Her verdict was sceptical: a small bug turned into four user stories with sixteen acceptance criteria, and she would rather review code than piles of markdown.
In June 2026, Matthew Wilson (Instil) went further and declared SDD dead. His case is economic: with usage-based billing, generating a hierarchy of artefacts and dragging it through the context on every step costs several times more than working in plan mode. And on his projects the output did not improve: same quality, more files, and documents that ended up contradicting the code.
In September 2026, Adrian Hall replied that SDD is alive and changing role. Agents now plan on their own, so much of the ceremony is redundant, but business judgement still does not live in the repository. For him the spec becomes shared memory between people and agents, and human checkpoints belong at decisions, not at every mechanical phase.
In Business Central the spec has more work to do
Wilson leaves a door open that I think is the key to the whole debate: a spec pays off when it outlives any single implementation. He mentions regulated domains, public APIs and decisions you will have to defend three years from now. A Business Central project at a partner fits there almost every time.
The requirement arrives as a customer document, gets estimated, becomes scope and someone signs it. Months later, when the customer asks why a credit memo is calculated that way, the answer has to live somewhere other than a chat with an agent nobody remembers. In that context, the approved architecture document is part of the deliverable.
It also matters that everything in Business Central is brownfield. Every extension builds on the base application and on other extensions, so the agent has to reason about what already exists before writing a line. Böckeler saw spec-kit duplicate classes that were already in the code; in AL that mistake is expensive, which is why ALDC’s architecture phase spends so much effort deciding what gets extended and what subscribes to events.
There is also an advantage to being vertical. Böckeler pointed out how hard it is to separate the functional spec from the technical one when the spec is meant to fit any technology. ALDC does not try: the customer document and the requirements are functional, the technical specification talks about AL objects, fields and events, and each has its own owner.
Separate agents so nobody grades their own exam
The Wilson critique that made me think hardest is about agent teams with roles: architect, developer, reviewer. In his view those roles mimic a coordination protocol designed for people who cannot read each other’s minds, and a model with the whole context does not need to pay that toll. For coordination, I agree.
In ALDC the roles are separated for a different reason. Whoever reviews should not be whoever wrote the code, for the same reason as in a human team: the author takes for granted what they meant to do. With agents the risk is more concrete, because a model that can touch the tests tends to adjust them until they pass.
That is why the tests that come from the specification are not modified by whoever implements, and an independent auditor checks the result against the business criteria captured in the architecture, not just against whether it compiles. Wilson is right that those extra rounds are paid at full price. The honest question is whether they buy evidence we would not otherwise have, and that question needs data.
What the debate forces me to change
Proportional ceremony is already in ALDC: a small, clear change goes straight to the developer agent, an error gets diagnosed before anything is touched, and only larger work goes through architecture and phased orchestration. What is missing is making it explicit, with a three-line spec for small work, as Hall suggests, instead of skipping the spec altogether.
Human gates belong at decisions. Today a person approves the architecture and then every implementation phase. Hall puts it plainly: approving mechanical phases gives the appearance of control without delivering it. Moving between phases should be decided by automated evidence, and the person should be kept for what an agent cannot guess: the data model, business semantics, anything irreversible.
The spec has to survive change. When a change request lands on an existing feature, the natural move is to evolve its specification rather than open a new one from scratch. If I don’t, ALDC stays where Böckeler places spec-kit: specs that last as long as one change and, over time, stop telling the truth.
And it has to be measured. With usage-based billing, the first question any team will ask is what a requirement costs with ALDC versus plan mode, and what each one caught that the other missed. Today I have intuition and cases, not that number.
References
- Birgitta Böckeler, Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl, martinfowler.com, 15 October 2025
- Matthew Wilson, Spec-driven development is dead. Long live plan mode, Instil, 19 June 2026
- Adrian Hall, Is Spec-Driven Design Dead?, 11 September 2026
- ALDC (AL Development Collection): GitHub repository and Visual Studio Marketplace extension
- Kiro: kiro.dev
- spec-kit (GitHub): github.com/github/spec-kit
- Tessl Framework: Tessl documentation
Closing
If the debate makes one thing clear, it is that more markdown does not mean more control. In Business Central the spec earns its place because the business needs it later; what I have to prove is that every piece of ceremony around it buys evidence and not just tokens. That is the work ahead for ALDC.