Bringing Behavior-Driven Development into 2025 with LLMs: ZapCircle for React Developers
My new project: ZapCircle
I’ve been working on my Wrangell Data application - data cleaning and wrangling, almost all in the front-end, running in the user’s web browser. As you can imagine, there are a lot of React components that go into this, and I used ChatGPT to help me code them initially, and then update them as things change.
This worked - to a certain extent. The chat interface for ChatGPT wasn’t ideal for these edits, and there were issues with either too little or too much context for what I was doing.
I’m sure these things can all be ironed out, but what really struck me was my workflow:
- Ask ChatGPT to come up with a functional specification for a new feature, such as a dropdown list picker.
- Edit that spec by hand, and then paste it back into ChatGPT to generate a React component
- Edit the React component to get it to work, and then ask ChatGPT to add a new feature to it
- Ask ChatGPT to write tests for the React Component
- Repeat the cycle - there was a lot of cutting and pasting, and it was hard to keep track of where in the ChatGPT chat interface I had put some of this stuff. Projects help, but it’s still not really organized the way my code base is.
I realized that I had come back to something old - Behavior Driven Development (BDD) - probably best expressed in the Cucumber project for Ruby. The focus of Cucumber was to write tests using plain English, and then developers would write intermediate steps that the plain English would call for the tests. This was all done long before LLMs, and probably isn’t quite as popular as it used to be.
What would happen if we took this approach, and used it for everything? I’m used to seeing acceptance criteria in JIRA tickets when working with product managers or product owners, and that’s probably not really the best place for that to live either, disconnected from the code base.
I have to admit - my next step went too far.
I went down the path of creating my own web application framework, with single file components that contained the behavior specification, the HTML, and vanilla JavaScript that rendered and updated the HTML. This was a really fun exercise - I built a Vite plugin that served up my single file components, I had a hot loader that let you run the web application framework in dev mode, and everything was organized around storing state in Valtio. No JSX needed, which I thought might be simpler for the LLM to work with.
As you can imagine, this quickly became a handful, and I reigned things back in - after all, Wrangell Data uses React, and that’s what I was trying to build anyway. I took the good ideas from that web application framework (the behaviors, using TOML) and threw away the bad ideas (single file components, trying to kickstart a new front-end web framework) to build ZapCircle. I will say that Valtio was great, and I would definitely use it in the future.
Now, you can use my tool to write your behavior next to your source code, generate code from that behavior, and then version it all together in Git. The current version uses OpenAI’s API to generate code with the model of your choice, using your own key. It uses LangChain, so supporting other LLMs is on the roadmap.
Want to generate behavior specifications for your existing components? ZapCircle does that as well, giving you round trip capabilities.
There’s a lot more that can be done with this project, but I’m pretty excited about it. If nothing else, this is a fast-moving area of tech to be working in right now.
Note: Originally published on LinkedIn on my own account.