BDD
Since I came across it a long time ago I have been intrigued by the idea of Behaviour-Driven Development (BDD). Something about the Given-When-Then notation and capturing short scenarios of behaviour clicked with me.
Given I have entered a record for the book “Thus Spoke Zarathustra”
And I have not captured any other books
When I am visiting the book search page
And enter the search term “Zarathustra”
Then it shows one search hit: “Thus Spoke Zarathustra”
It clearly states inputs, the “state of the world” before that (the data; Latin for the givens) and the event triggering an observable state transition, which carries additional data, and outputs, the now changed “state of the world.”
Every spoken phrase has this basic structure. “I throw the ball” means a change of the physical position of the ball inside the world. In the physical world, in a continuum, but conceptually as a step change, from “ball here” to “ball there”. The BDD format makes things cognitively easy. It speaks in examples, not in ambiguous rules.
Of course this is almost programming. In a recent talk[1] Kent Beck, known for his supposed invention of TDD (test-driven development), tells us that the idea of test-driven development really can be traced back to a much earlier point. In a later chapter in the 1957 book Digital Computer Programming the author makes the point that to gather requirements, one sits down with the clients and talks about inputs and outputs. That is, one captures input-output pairs in example form.
Now, as beautiful as I personally think this is, the “almost programming” part is what will make it a bit tedious and time consuming. In practice you won’t be able to sit down with your clients or PMs and gather all your requirements that way, but, in my opinion, you should try to get some of them, or capture those in this form when disambiguation is important.
LLM
What made this idea really only one for hardliners of methodology, was that in addition to capturing requirements in this already tedious manner, painstaking efforts would be necessary to glue these sentences to actual underlying code. How this worked, was that these sentences were pattern matched. For example: ‘Given I have entered a record for the book “Thus Spoke Zarathustra”’ meant that that triggered some general code which would get a book into the database, and the title would be specified by the exact string given. Lots of work to maintain this.
Not so much with the advent of LLMs. In fact, now you get any amount of babble basically for free. Maintaining big test suites has become easy and maintaining glue code a non-issue. I have found myself using a couple of variants of this lately.
The first one is “traditional” Gherkin Syntax with glue code. I see some theoretical value here, maybe bordering on superstition, in generating this alongside your e2e tests. The syntax still then has to be very rigorous, which makes them, even if written in natural language, a bit too clunky. But maybe the LLM looks at it and can get some amount of intentionality from it.
What I found more interesting was a variant, in which I specify scenarios with a higher degree of freedom, deviating from the rigorosity of a fixed syntax. This I think is what comes closest to the original spirit of what BDD is about. You can collaboratively create slightly formal documents together with your customers and are almost good to go. Instead of glue code, a small LLM based pipeline translates the scenarios into (version-controlled) executable tests. It’s the same as glue code, but different, basically.
What I am really using, though, albeit only for personal projects at this stage, are just files of this kind
## Open a link in a tab in an orb - accross machines
- Given I am on my Mac Mini
- And when I am on the SN context with Zoo
- And in that SN context in the orbs subcontext
- And in that Orb is a session
- When I ask that session "Open a link in a new tab for example.com"
- Then a popup opens in Zoo displaying a message containing "http://example.com" which takes me to that page with a normal click without modifiers in a new tab.
## Zoo Tasks - Task Notes
Given there exist at least two Tasks
And there is a session inside Task ABC
When I ask it to write "hi" to the Task notes
Then I will find that "hi" in the notes of Task ABC
(This is from an agent orchestrator IDE type of thing I’m working on. Note the deviation from more correct BDD syntax: I should have said ‘When I ask it: Write “Hi” to the Task notes’, the complete string that I imagine passing to an agent session. This is a real example I just picked from my files in order to demonstrate that doing this is very forgiving.)
There is no glue code in this case at all. These things are prompts. And I found this works fantastically. Opus 5.5 style LLMs transform this into exactly the behaviour I want[2] (of course when enough context is accumulated in the session for this to make sense). This style is not only unambiguous, but it also stays readable. If I go back to it, I (and this time I mean myself and not only the bots) still can very much understand my original intention regarding how I wanted the application to behave.
Footnotes
Kent Beck: Software Engineering in the Age of AI | Prodacity 2026 YouTube This was boring. Don’t watch it. But at 4:23 he talks about this book. Daniel D. McCracken - Digital Computer Programming.
And into code and tests; whether they look like you want, you have to ensure by other measures.