The ultimate 'context engineering' I guess.
I need to get back into Cucumber. It's been a while. Like a decade or so. ðŸ«
The ultimate 'context engineering' I guess.
I need to get back into Cucumber. It's been a while. Like a decade or so. ðŸ«
Here's the thing I've discovered, that makes using Gherkin+AI so awesome:
You don't need to automate the Gherkin.
Just write the .feature files in high detail, and then skip the steps. And then just ask the AI to make sure to check against the Gherkin. And, if you want something changed, just adjust the Gherkin by hand and ask the AI to implement the changes to match the new description.
The models _are_ the test automation.
It's like you architect a software bluebrint and the AI is the builder.
And, after it builds things, you can go in and rearrange everything, to your liking, and then say, "I changed the code. Please double-check that I didn't break the features," and it'll go through and mark everything that conflicts.
And, if you get tired of your code, delete the entire /src/ and say, "Please generate all of the code to implement the .feature tests." and it'll write it all out, neatly, in 5 minutes.
This is the way.
Code is disposable.
Creativity and some discipline in getting thoughts down coherently is where the value is now.
Wild.
The code is disposable is actually turning into a software architect's dream, which I didn't see coming. As he can use a prototype to hone the behavior, and then generate lots of different implementations to fulfill the behavior, and then pick the one he likes best and architect it even harder.
Prbly worth getting AI to write the gherkin from general handwaving and refine from there.
Gonna give this a try.
I wrote a design document, including PlantUML diagrams, and mockups, and hyperlinks to designs I liked and specs I wanted to cover and architectural/quality concepts I wanted to include, and coding guideline stuff from our PO. It was like 5 pages long.
And then I had it generate the .feature files, and went through multiple iterations on each file, editing and then having it review-and-suggest-more, and basta. The team has been feeding me their wishes, on the side, in Gherkin, and I just say "Please incorporate this into the .feature files and then implement." and ta-da!
Super powerful and also should stop most of the ai hallucination.
Yes. I actually always say, "You might have made some stuff up. Please go back and check against the features." and it actually corrects any hallucinations, itself.
What you get out is not a product, but it's a highly-functionality prototype. You can then hone it and refine it. Once it gets relatively good and everything basically works, you can hand it off to your architect (or architect it, yourself) and he can rewrite the code.
He can even open a new repo, copy-paste in the .feature files, and then build a completely new, clean software program that passes the same tests.
The key is that you hone it and refine it OVER THE FEATURES, never directly in the implementation. Otherwise, the business logic gets wiped out, when it changes code. You have to hard-break between the behavior and the implementation.