Table of contents

SDD Is a Symptom, not a Methodology

Getting software delivered has always required a specification.

Having a clear specification of what is required is essential.

Writing such a spec is a collaborative effort:

• Product owns the business intent
• Engineering owns the technical constraints
• Design owns the interaction and behaviour

The spec is a shared artefact formed through deliberate thinking and judgement. It must embody strategy and confirm that what is to be built is relevant.

The software industry now suggests that having a specification will make AI tooling more reliable. No. And this is not new.

A clear spec has always meant that the outcome is more likely to be successful.

SDD for AI-augmented teams is just a 30-year-old idea in a sparkly jacket.

What is new

SDD is not new. But the context is.

SDD is being reframed as:

• a way to generate code from structured specs
• a way to constrain AI agents
• a way to reduce non‑determinism
• a way to enforce governance in AI‑augmented pipelines

This reframing gives the impression that SDD is a new discipline rather than a new label for long‑standing engineering practice.

The spec is not the goal. Working software is.

Regardless of who writes the spec, you will need to iterate: build, release, gather user and market feedback, and steer with additional thinking and judgement.

SDD Surfaces When Teams Confront Ambiguity

SDD appears when teams realise:

• their requirements are too vague
• their systems are too implicit
• their data contracts are too loose
• their AI tooling is too unpredictable

SDD is the label people reach for when they need clarity, structure and determinism.

You do not need SDD. You need clarity, structure and determinism.

Write a spec, get the code for free?

The assumption in tech currently seems to be, write a spec, feed it into an AI and get out all the code you need for free.

Writing the spec requires deliberate thinking and judgement by Product, Engineering, and Design. You cannot automate this.

The Limits of the "Spec → Code" Argument

Taking the "spec → code" argument to its logical conclusion: why not use AI to automate the generation of the spec? Why stop at generating code? We could use AI to generate the company's vision and strategy so vision → strategy → spec → code can be AI generated?

Because large language models are probabilistic pattern-matching processes, domains that are less pattern rich than the unambiguous grammar of a computer programming language or a mathematical formula will be less well modeled by an LLM.

In 2026, LLMs are experiencing major leaps forward since the initial revolution started, but over time, the incremental improvements and the size of the leap forward will lessen as all the low-hanging innovation fruit is quickly consumed, and we realise the fundamental limits of pattern matching.

Well engineered code cannot be seen

"Marley was dead: to begin with."

These six words start A Christmas Carol by Charles Dickens. And what they achieve is beyond just the words.

Dickens uses the line to establish an absolute fact the reader must accept, because the entire supernatural and moral structure of the story depends on Marley being unquestionably dead. Without that certainty, the ghost would not be a ghost, Scrooge’s transformation would lose force, and the story’s logic would collapse. The sentence subtly fixes the rules of the world before the plot begins.

Well engineered code is the same; it embodies a team's judgement beyond the text that can be seen.

To capture every eventuality in a specification would require anticipating everything. Humans are not good at this, which is why incremental delivery is essential.

We forget that any sufficiently detailed spec is the code.

In addition, code executes within a much larger environment. Aligning code to work within a changing environment requires judgement from across the organisation, not only from engineering.

Juniors are Not Doomed

Before LLMs, a junior software engineer would traditionally have been given a task that was self-contained: fixing bugs or delivering straightforward features. This reduced the risk to the business and ensured that the engineer could get up to speed with house rules: how code was delivered; what to expect from a PR; who to seek help from.

This familiarisation is part of the 70% of the job. The junior will use their judgement, with feedback, to contribute to the understanding that product, engineering and design collaborate to achieve. This is how the junior engineer learns and gains experience by doing the whole software engineering cycle, end-to-end.

With large language models, the 30% of the job is likely to change. But the 70% will remain the same. The 70% cannot be fully automated by LLMs as it requires judgement.

Good engineering is more than what you can see in the code. Marley may be dead but the role of the junior is not.

When Code Becomes Cheap

AI is now part of software engineering. The question is not whether we use it, but whether we use it well.

Writing the code is the last step once the team has gained a good understanding of what is required. Without clarity, our current use of AI is to produce more code that is not needed or will not be used.

If AI makes the cost of writing code essentially zero, we need to ensure that the code that is written is exactly what is required for the business, given the singular context of the business within its market.

The quick win for AI companies has been to demonstrate how suited their LLMs are to code generation. But like any tool, its value depends entirely on how we choose to use it.

A business should not define itself by how much code can be generated but by the quality of its products; leadership must recognise that rushing out large quantities of code will dilute that quality.

Leadership should focus on clarity, structure and determinism so that the product being designed and built is what the organisation genuinely needs.

If AI reduces the cost of producing code, leadership must raise the standard of what is worth producing. The responsibility for clarity increases as the cost of execution falls.

AI changes the economics of code, not the fundamentals of engineering.

Related Work

• The biggest ROI from AI comes from improving team‑level work, not speeding up individual coding.
• Individual AI delivers diminishing returns; meaningful improvement comes from strengthening the collective workflow.
• AI adoption is an organisational transformation requiring mandates, measurement, and redesigned processes.