A common phrase we hear in the context of AI-assisted development is "spec-driven development" or SDD. There are many definitions of SDD floating around. Here is a good one from Birgitta Böckeler:
Spec-driven development means writing a “spec” before writing code with AI (“documentation first”). The spec becomes the source of truth for the human and the AI.
So what's a "spec"? Birgitta offers this definition:
A spec is a structured, behavior-oriented artifact - or a set of related artifacts - written in natural language that expresses software functionality and serves as guidance to AI coding agents.
There are many AI-based tools available for teams who want to practice SDD. They can build code exactly to the spec given to them. What we miss in all the talk about SDD is - where does the spec come from? How do we know it really specifies the capabilities that the customers want and need?
For those that missed the world of waterfall, spec stands for specification. The specs that were written then are not what we mean now. Let’s dive into that a bit more.
We still need the good practices and principles
The way teams build production and test code is clearly changing. The principles and practices we have followed to create examples, executable tests, prototypes and other artifacts that show how each new feature behaves have not changed. It's even more important that we build the shared understanding of each new software change.
When you go to learn about SDD, it sounds like a new waterfall process - create a big batch of specs, feed it to the agents, and generate a huge amount of code. We're hearing more every day about "cognitive debt", also called "comprehension debt", on the part of teams trying to review and understand these huge batches of generated code. It's not humanly possible.
Applying the Holistic Testing Model to SDD
Looking at the Holistic Testing Model, would we change anything when using AI to create code and tests from specs using AI agentic development? Whether or not we adopt AI-assisted development, working incrementally and iteratively, one small change at a time, is the road to success.
We still need to test the business ideas and make sure they will solve customers' problems. We still need to analyze and manage risks. It's still important to prioritize the top few quality attributes for each new change. Sure, AI can help us process analytics about customer needs, so maybe it can speed up some of these activities.
Build quality in throughout the SDLC
Using examples and tests to guide development is even more critical if we're going to trust AI tools to build the code for a new capability. Behavior-driven / acceptance test-driven development and Specification by Example (remember that?) help make sure we deliver what our customers want and need. And yes, AI can speed up building prototypes that help to ensure we know how a new change should behave.
Automating the tests based on examples that emerge from conversations among delivery and business team members goes more quickly with AI assistance. However, we still need those human conversations to ensure shared understanding of what to build.
Some of the testing activities we plan based on the right-hand side of the model will also be quicker and easier if we employ AI tools wisely. They still need to happen because we don't want to take our human brains out of the equation.
If you take nothing else away from this post, just remember, "work in small batches". This principle for successful software development, happy teams and happy customers dates from the 1970s. It's time more teams learned and followed it.
More learning
If you'd like more details about how using a specification-by-example approach, making one tiny change at a time, we recommend Antony Marcano's work on this topic. His article, "What (Almost) Everyone Gets Wrong About Spec-Driven Development with AI", is a great place to start. We also enjoyed the video Antony generated from it using Google NotebookLM.