📅 Register (free): Spec-Driven Development with ATDD & AI (Oct 14)
👋 Hello, this is Valentina with the free edition of the Optivem Journal.
Markdown spec = enforced spec? WRONG.
Markdown = Spec. Acceptance Test = Executable Spec.
❌ Spec -> AI writes code -> Human manually tests
✅ Executable Spec -> AI writes code -> Automatic spec verification
99% of developers follow Spec-Driven Development (SDD) the WRONG way.
1. They write the spec in Markdown.
2. They tell AI to implement code based on spec.
But what's the problem here? Sure, AI reads the markdown file, but doesn't follow it fully! It may decide to skip instructions, or misinterpret instructions, etc.
So we can NOT trust AI!
We have to manually read the spec, manually run the system, and manually decide whether the functionality that the system implemented matches what was in the spec.
Interestingly, this is not a new problem. We've had this problem for ages, with human developers. Remember, we'd write a User Story, the developer thinks they followed it, but then QA says it doesn't work correctly - that there was something that the developer missed, or they had misinterpretations.
Well, that's exactly the same problem in Spec-Driven Development, how most people practice it.
The solution is: EXECUTABLE specs. With executable specs, we can be sure to enforce that AI actually implements the behavior that we specified. We have an automated way to check - a pass or fail. This means if AI skips instructions, or misinterprets something, we'll have a test telling us it failed. AI tries again, until the test passes. There's no way for AI to "cheat" the test.
That's the right way to do Spec-Driven Development. Convert textual specs to executable specs.
⚡Full walkthrough, with the code examples
📅 Register (free): Spec-Driven Development with ATDD & AI (Oct 14)
Only acceptance tests can tell us if it's working properly.
Agree that a spec has to be able to fail. The step we would add sits before the acceptance test: the questions the spec never asked. An executable test pins what someone thought to write down, but the expensive misses are the cases nobody listed, like what happens on a retry or a partial refund. Who writes the acceptance tests in your setup, the developer or the agent? If the agent turns the Markdown into tests, its misreading goes into the test as well, and then the test passes.