I suspect if the idea became practice they would come up with a better name for it.
As the article raises BDD for many was about discussions, collaboration, communication and stakeholder alignment whilst also leveraging from development by example in this case product behaviors. The automated coverage was also a reasonable secondary byproduct.
In SDD where do your specifications come from?
BDD could be used to create your specifications so its still BDD rather than SDD in that case.
So you have specifications, AI then creates unit tests, from the unit tests it creates product code, from the product code it creates acceptance tests and round we go. Maybe we could create acceptance tests, then create the code, then create the unit tests or any mix and match or resequencing of above.
It sounds a bit like a solo hobbiest approach and for that it may suffice.
I’d be wary having the AI agent designer, developer and tester with just a conducting role simulating BDD at least at this point.
I had a discussion that I will explore further that the AI agents can be really good at rapid prototyping and already people seem to be finding value in this. I like that prototype level, give me a prototype level code, tests, acceptance tests etc so the Agents as accelerators to get started, similarly with testing generating small prototype tools to run risk experiments.
To go from the prototype level to full product though I still feel Humans at the Helm remains key and not just a solo human, a team of them.
So for me we are not there yet, I like the idea that at some point I’ll wake up in the morning and have an idea of an app that will help me do something that day, I specify this to my group of agents and its up and running by the time I’ve got a coffee and the A-team’s theme tune has finished. Real time apps as you need them for real time challenges. Not there yet in my view and I’m not sure what we lose would be worth it.
)