Yesterday I blogged about how I’d picked up my old event modeling project again, and decided to test drive it with a new project.
One of my kids had recently started taking drawing commissions online. I’d been helping with the payment side, so they would take an order, check with me if they got paid, then start working on it.
It was fine for the first one, but then in a span of days they’d gathered 5 more.
Then the payment service wanted proof that the goods had been delivered, so we had to match each payment with its order, take screenshots, etc. In short, the process became quite tedious fast.
So I asked my agent to come up with a plan for this. Because eventPAD was event sourced, building an MCP for the agent to plot was easy. That’s now part of my planning step, which used to show the event model in my emoji text notation.
Even on mobile, it works since the agent can just send me a JSON blob and I can load it up to the tool.
Because it’s so much easier to read, we can iterate better before queuing up the build.
With all the projects that I’d been building these past few months, I’d have a very clear understanding of what I wanted to build in the beginning, but then once my agents finish the first MVP, adding new features becomes a message and it gets shipped to production.
The products grow at crazy speeds. Now my workflow is so automated that I can send a message to the agent and a few minutes later, I can check my site and test.
Once it started building, I asked my kid to send me some screenshots of their pricing strategy and sent it to the agent because I thought maybe it could improve on the UX of how we could set pricing, before going to bed.
This morning when I started testing, I was confused when I tested out adding products. It had become creative and added some complex shenanigans in the offer added flow. My kid’s pricing had an extra fee per character and different levels of drawing, line art or a full render, and the agent had built all of it in. Adding a product had become a very complex affair.
I quickly added a feature to eventPAD that would allow me to compare two models, and display the differences of the generated model and the planned model. You could see differences in the slices, scenarios, properties, etc.
Sure enough, the offer flow didn’t match the plan, and there were these 32 other features not planned (some of those were me just scope creeping by the way).
I decided to look into the implementation model to understand where the diffs were. And obviously, there it was, the shenanigan slices and I remembered my just before bed message of sending the screenshot.
Another thing I had added to eventPAD was a replay button. I got curious and clicked it and watched as the board rebuilt itself.
I had refactored all my tests and my build process to include a step that exports the event model from the code.
At this point, in my mind I had completely misunderstood how it was doing that. I made an assumption that the script was going through the whole codebase, picking up my API feature files and test files and assembling the board state from it.
If you look at an event model, one would think that the easiest way to display a board like that is to pass a JSON blob that sets all the properties of the chapters, slices and other components. I remember thinking I would never have had the time to write a parser for code to build something like that. You’d have to look at the main code for the slices and then you’d have to look at the test code for the Given/When/Thens.
I was about to go ask the agent why are we including the history, why can’t we just send the state of the board? I got curious and looked at the implementation file exported from the tests and imported from the platform as well as the export import feature.
This is when I had the eureka moment of understanding that the export runs all the tests and saves the events produced by the When step, which is running actual code, and those scenarios are mapped to slices and chapters and the board is built from that.
If you want the nuts and bolts, my agent Harry wrote up the whole pipeline on the itsybot devlog, following one test all the way to the board.
If a test exists, it’s been run to get the output event or the resulting view, proof that the code is according to specified scenarios.
From there, comparing the plan and the implementation model shows very clearly the state of the application.
As for the commissions, the MVP is out. Now we’re going through the specs chapter by chapter, so we get it right.
I didn’t used to pay much attention to Given/When/Thens. I was still wrapping my head around event modeling and event sourcing. Now I realise they’re what closes the loop, especially in agentic development.
