The Gap Inverted

Delphi. People travelled for weeks to find out what to do. Deciding was always the slow part.

Why specifications matter more now, not less

Part of the series Domain-Driven Design Meets AI.

The first post in this series introduced the Synergetic Blueprint as the thread that connects DDD’s methods into one end-to-end process, and argued that AI does not replace that process but makes its ambitions reachable in practice. Five Principles for AI-Assisted DDD then set the rules of engagement, among them the one this post depends on: artifacts are prompts.

This post takes a step back from the individual techniques and asks a blunter question. Why does any of this matter more now than it did five years ago?

We settled this in the 1950s

If someone told you they were about to build a software system with no specification at all, you would assume they were joking. We have known since the 1950s that you have to say what a system should do before you can build something suitable for the job. Benington described it in 1956 (Benington, 1956). Royce wrote it down again in 1970 (Royce, 1970). It is one of the few things our field settled early.

Then vibe coding arrived (Karpathy, 2025), and for a moment it looked like we had forgotten all of it.

I don’t think we forgot. Something underneath moved, and the old habits stopped fitting the new shape.

The gap used to be wide

Between discovery, meaning the work of establishing what to build, and delivery, meaning the work of putting it in front of users, there has always been a gap.

For decades that gap was measured in months. We specified a system, then built it for a year. Even in 2019, the slowest organizations in the DORA data still needed one to six months to get a single change into production (DORA and Google Cloud, 2019). Whatever we learned during discovery was stale before anyone could act on it.

Agile narrowed it (Beck et al., 2001). Working software every few weeks. Then continuous delivery, in days (Humble & Farley, 2010). Then the best teams deploying on demand, with a lead time under a day (DORA and Google Cloud, 2019; Forsgren et al., 2018). For a short and pleasant period, discovery and delivery ran at about the same speed. You could learn something on Tuesday and ship it on Thursday.

With AI-assisted coding, the gap did not keep narrowing (CircleCI, 2026). It flipped.

Two curves with different floors

This is where the argument turns, so it is worth being precise about the mechanism rather than waving at a benchmark.

Delivery time is bounded by machine throughput. Compile, test, deploy, and now generate. Every one of those costs has been falling for thirty years, and the last one is falling fastest (CircleCI, 2026). Going from quarterly releases to on-demand deployment is not a modest improvement. It is four or five orders of magnitude, and the floor underneath it is close to zero.

Discovery time is bounded by something else entirely: how many people have to agree, how long it takes them to build shared understanding, and when all of them are available. Those costs are set by human cognition and by calendars.

Discovery did get faster. Collaborative modeling made it faster, and that was the point of inventing it. A three-week specification phase turned into a two-day workshop. Call it five or ten times better. That is a real gain and I do not want to diminish it.

But it is a linear improvement running against an exponential one, and the two curves have different floors.

Delivery’s floor approaches zero. Discovery’s floor is however long it takes a group of humans to genuinely agree about something complicated, and that number has not moved much and is not going to. Two curves like that will cross. Which year they crossed is a detail worth arguing about. That they crossed is not.

Brooks told us in 1987 that deciding what to build was the hard part (Brooks, 1987). That has not changed. What changed is that it is now also the slow part.

“But AI speeds up discovery too”

This is the strongest objection to the argument, and it is partly right. A model can synthesize interview notes, propose a candidate structure, lay out an option space, draft the diagram, and produce a first-cut glossary in seconds. The first post in this series made exactly that case: AI collapses the cold start, and reacting to a draft beats staring at an empty board.

Look at what is being accelerated, though. The writing-down was never the bottleneck. No project in history was late because transcribing the model took too long.

The bottleneck is agreement. It is getting six people to mean the same thing by ‘delivered.’ A model can hand you a draft in seconds, but it cannot make the operations lead and the finance lead discover, in front of each other, that they have been using that word differently for two years. That happens in a room, at human speed, and it is the part that decides whether the software is right.

AI makes the cheap half of discovery cheaper. The expensive half is untouched.

If delivery isn’t the constraint, discovery decides

That is an uncomfortable conclusion for a profession that has spent forty years optimizing the other end of the pipeline. If code is cheap, the quality of our software is set almost entirely by the quality of our understanding. Build the wrong thing quickly and you have simply arrived at the wrong place sooner.

Which is why collaborative modeling matters more now than when it was invented, and I mean the whole family of it. Domain Storytelling (Hofer & Schwentner, 2021), EventStorming (Brandolini, 2013), Event Modeling (Dilger, 2024; Dymitruk, 2019), Example Mapping (Adzic, 2011; Wynne, 2015), the Visual Glossary (Zörner, 2021), and the rest of the artifacts the Blueprint strings together. They differ in notation, in granularity, and in what they put at the center, and you should pick according to the problem in front of you. What they share is the thing that matters here: they get a group of people to produce, together, an explicit and precise account of how a business actually works.

That output is not a picture you draw once and abandon on a Miro board. It is a specification. It says what happens, in which order, who triggers it, and what the system shows afterward. Precise enough that people can agree on it, and precise enough that a machine can build from it.

That second property used to be a nice side effect. It is now the point. It is also what the third principle means when it says artifacts are prompts: the output quality you get from AI is bounded by the input quality you give it, and the artifacts of collaborative modeling are that input.

What LLMs are actually missing

LLMs do not fail at domain work because they are not ‘intelligent.’ They fail because they have no access to the domain.

The rules that decide whether a piece of software is correct are rarely in the codebase and almost never on the internet. They are in the head of the people who have processed the business for years and know how to handle it (most of the time even around the software they use). They are in the standing argument between operations and finance. They are in the exception that only comes up in December. A model that has not been told these things will produce plausible code that is wrong in ways nobody notices until it reaches production. From Stories to Code worked through what that looks like in practice, and what changes once the domain artifacts are in the prompt.

The fix is not a longer prompt. It is a shared, explicit model of the domain that the team and the machine can both read. Collaborative modeling was always worth doing because it got people to agree. It now has a second job: it is the channel through which the domain reaches the tools that write your code. Whichever technique you use, the output has to be explicit enough to be understood by someone who was not in the room, and a machine is always someone who was not in the room.

We were never crazy to insist on specification. We were only slow at it, and delivery was slow enough that the cost stayed hidden. That excuse is gone.

Next in this series: The Hidden Border Between Strategic and Tactical Design — the point in the Blueprint where eliciting stops and building begins, where the primary Drafter changes from a human to a machine, and where a handover done badly is most expensive to undo.

This series grew out of my work on the book DDD Meets AI, published by Springer Nature in February 2027.

---

References

References

Adzic, G. (2011). Specification by example: How successful teams deliver the right software. Manning Publications.

Beck, K., Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for agile software development. https://agilemanifesto.org/.

Benington, H. D. (1956). Production of large computer programs. Proceedings of the Symposium on Advanced Programming Methods for Digital Computers, 15–27.

Brandolini, A. (2013). EventStorming. https://www.eventstorming.org. https://www.eventstorming.org

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532

CircleCI. (2026). The 2026 state of software delivery. CircleCI. https://circleci.com/landing-pages/assets/2026-state-of-software-delivery-report.pdf

Dilger, M. (2024). Understanding Eventsourcing: Planning and implementing scalable systems with Eventmodeling and Eventsourcing (p. 500). Independently Published. https://leanpub.com/eventmodeling-and-eventsourcing

DORA and Google Cloud. (2019). Accelerate: State of DevOps 2019. DORA / Google Cloud. https://dora.dev/research/2019/dora-report/2019-dora-accelerate-state-of-devops-report.pdf

Dymitruk, A. (2019). Event modeling: What is it? eventmodeling.org. https://eventmodeling.org/posts/what-is-event-modeling/

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps. Building and scaling high performing technology organizations. IT Revolution Press.

Hofer, S., & Schwentner, H. (2021). Domain storytelling: A collaborative, visual, and agile way to build domain-driven software (1st ed., p. 288). Addison-Wesley.

Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases through build, test, and deployment automation. Addison-Wesley.

Karpathy, A. (2025). There’s a new kind of coding I call “vibe coding”. Post on X (formerly Twitter), @karpathy. https://x.com/karpathy/status/1886192184808149383

Royce, W. W. (1970). Managing the development of large software systems. Proceedings of IEEE WESCON, 26, 1–9.

Wynne, M. (2015). Introducing example mapping. Cucumber blog.

Zörner, S. (2021). Software-architekturen dokumentieren und kommunizieren: Entwürfe, Entscheidungen und Lösungen nachvollziehbar und wirkungsvoll festhalten (3rd ed., p. 309). Carl Hanser Verlag.