Today’s speed from idea to a running website is less than a day, an iteration or additional functionality is minutes. And because most of my workflows are automations or scripts, I run out of GitHub tokens (the ones used up when you run scripts on their deployment server) faster than I run out of AI tokens.
We are now in a world where coding is not as tedious as it used to be, and yet we still have the same problems as before, and more.
The goal shouldn’t be to become a 10x developer, doing more of the same thing because you’re faster. It’s to hack yourself into becoming better: shifting to an engineering mindset, making systems instead of writing programs.
Where it started
By happenstance, a new job led me to read about event modeling because I had landed in a small team that had a very big system scope and I needed a way to make sense of things for myself.
Previously I had been involved in projects that were very focused, or in the early stages of an iteration of a very specific scope.
As a consultant, you’re expected to know a little bit more about something, and you’re expected to be able to give an opinion about how to go about things. That’s why personally, I invest some (haha) of my free time keeping myself up to date and informed with what’s happening in the industry.
Event sourcing enters the room naturally when you’re in the event modeling world. It’s not a new thing, but there was a point when I thought I didn’t have the mental capacity to understand it.
After sitting in a bunch of workshops on event modeling, the event sourcing part still didn’t sink in. But already I had seen the benefit of visually being able to see what a system does or should do without seeing the code.
As I learned and understood more and more about event modeling, along came AI and that allowed me to speed up the learning process and opened up the door to a whole lot of experimentation.
In order to fully understand something, you have to put it into practice. And with AI, anyone can all of a sudden build whatever their heart desires.
The only way to really understand event sourcing was to build something, so I decided to build something.
Building away the details
Yes, AI gave me the ability to all of a sudden be able to formulate a LINQ statement, but it also gave me the ability to fill in the blanks for other things that I didn’t particularly want to deal with: UI design and implementation, setting up infrastructure, etcetera.
At the time, I had my website that had nothing on it, and an app service on Azure that I had used to make a bank for my kids, for me to be able to track how much I have bribed them with so I know how much I need to set aside should the time come they actually want to collect, but for them to also see how much they would be chopping off their savings should they choose to buy this thing.
I had the infrastructure, why not build more things. ChoreMonkey, an app to track which chores needed to be done by whom, was the app that I first tried to event model just to try to apply what I’d learned.
There’s a few things that make me happy as a developer: getting something to work, being able to show someone what I’ve made, getting people to actually use it.
Naturally I wanted to bring the event model to life. I used AI to automate all the things that I didn’t want to deal with, building a deploy pipeline so it compiles and ships things as soon as I merge to the main branch.
They’re scripts that run automatically when the merge happens. I didn’t have to worry about anything else but writing the code.
Because there’s a lot of infrastructure that you need to set up when it comes to an event sourced system, I didn’t want to have to do it again and again.
I solved that problem by organizing my API into modules that would register into the infrastructure and I can just focus on the features of whatever app it is that I’m building.
Instead of me googling, watching tutorials, getting my dev environment set up, I can just ask AI to explain things to me and I can make a decision whether this technology is right for the thing that I want to make.
All this time, I’ve used AI not to build out all my ideas, but build away details that would otherwise slow me down from coming up with the next idea or feature of my apps.
Losing track
The biggest project that I have attempted is my barrio, it’s a glorified family website. I didn’t want my kids having to sign up to Facebook just to keep my family halfway around the world updated with whatever is going on with our lives, but have one place where anyone who is interested could come and find out without having to post it on all of social media or a public blog, ready for scraping.
Building that was so much fun. But I was shipping so fast that I lost track of what I’d actually built.
I needed a way to find out what has been built and that’s when I got the idea of generating an event model from code.
I set my AI on the job, and when the event model came out, that’s when I realized the value of the tests written alongside the code. It took a million tokens, which wasn’t sustainable, but the tests already said it: given x and y have happened, when you do a, then z happens. So we built a helper to structure the tests that way and a script to read them. Zero tokens, and an obvious addition to the build pipeline I already had. (I wrote more about that here.)
I got AI to refactor all my past projects’ tests so they too could have their event models viewed.
Now my latest event modeling app is a library of books which are event models of everything I’ve built during my learning journey, with links to the GitHub code should I be interested.
Using it
And since my app usage is stored as events, we could easily create another script that pulls the count of events from the store and adds that as information on the event model.
Now I have something that gives me a signal on whether a feature was actually used or not. I can decide to retire it, or think about discoverability and usability and recalibrate, all thanks to the events backing my app.
The shortcut
I understood event sourcing the moment the next new feature idea came. I didn’t have to migrate any database. I just had to know whether something had happened or not for the new functionality to succeed or fail. And if it was about showing something on screen, it felt like anything was possible as long as I had the events to back it up. No more need for AI to help me formulate complex LINQ queries!
My learning journey so far has been highly fueled by AI. What I’ve learned is that using AI to take shortcuts is not a bad thing, as long as that shortcut is not your end destination but rather a step in the direction of where you want to be.
That’s the ^x: not writing more programs, but making systems.
