Yadda 3.0.0: BDD in the Age of AI Agents
scresswell
59 points
27 comments
August 15, 2026
Related Discussions
Found 5 related stories in 46.1ms across 4,128 title embeddings via pgvector HNSW
- AI Coding and Its Discontents polymorph1sm · 13 pts · August 10, 2026 · 50% similar
- Show HN: Open-source playground to red-team AI agents against public prompts zachdotai · 13 pts · August 09, 2026 · 49% similar
- AI 2040 and the cult of intelligence rvz · 196 pts · July 11, 2026 · 48% similar
- A grumpy screed about AI in software engineering ssutch3 · 51 pts · July 18, 2026 · 48% similar
- Hating AI in 2026 HotGarbage · 24 pts · July 14, 2026 · 48% similar
Discussion Highlights (9 comments)
scresswell
Yadda 3.0.0 is out. The release modernises the JavaScript BDD library, but more interestingly, it was largely built by Claude Code and points to why executable specifications may become even more valuable in an agentic development world.
krautsauer
"Behaviour Driven Development" I was expecting something on Binary Decision Diagrams. SAOD is worst with TLAs.
Amekedl
Being hard here, though: Purely dismissing it as not being worth of my time due to the example alone.
lifeisstillgood
The example of “transcibe the initial project discussion, turn that into BDD and that makes the rails to guide the AI is … either brilliant and insightful or a snake eating it’s own tail. I think it has to be worth a try though…
blfr
Very impressive that it was done with Opus 4.8. My experiences with Opus have been such that I always max out my Fable allotment but rarely exceed 40% of the remaining limit on Claude.
jesol
I also think BDD is a really powerful tool for UI acceptance tests! I've now worked on adding it to two AI codebases (one engineered, another vibecoded), and so far it has been mostly positive. Having non-engineers be able to see what effects their code changes have in the UI is nice; and I find having high level API and UI tests is forcing the first layer of cleanup (standardize access to DB through models/services, and a single API SDK). I am also really interested in standardizing the REST interface with typespec, and the database schema with DBML. I think creating these closed-loops with high-level specs is one of the best ways to make an AI project ownable by a team.
wesselbindt
So, I get the idea of having a layer of abstraction between your tests and the system under test. You decouple _what_ is being done from _how_ it is done, which leads to robust, easily maintained, and even more re-usable test suites. I've seen it in action, it's a great idea, I've reaped the benefits myself. Great stuff. What I've never really understood is why some people choose natural language for the abstraction. It just seems like such an odd and expensive choice. Most of the layers of abstraction we add in our codebase are written in the programming language of choice itself, they're functions, classes, what have you. But for this one specific flavor of abstraction, folks reach for natural language. The one potential benefit I could think of for this over a more standard DSL is that non-technical colleagues would be able to read or even write these specs. But in practice I've only seen this pan out once in my life, and that was with a more traditional DSL rather than natural language. Is there a hidden benefit I'm overlooking?
Arubis
My go-to for forcing AI to at least attempt to follow BDD has been to demand that it use Phoenix Contexts.
sroerick
I hadn't heard of BDD before, but the idea of "executable spec" is certainly very interesting