I keep my AI Agents running 24/7. Most people hear “AI writes your code overnight” and picture a black box doing the thinking.
That’s not at all what this is.
What I’ve built is closer to a very disciplined, very tireless junior developer who never gets bored. The thinking - the architecture, the design decisions, the business rules - that all happens before the agent touches a single line. What the agent handles is the part that used to drain me: the repetitive, tedious, mechanical translation from a clear specification into working code.
Let me show you exactly how this works.
It Started With One Client Project
Last year I was working with a client and we used that project as a blueprint. So it wasn’t greenfield, but something already there. Not a perfect process from day one - more like a foundation I kept improving, iteration by iteration.
The key insight from that project was simple: if your specification is precise enough, the code almost writes itself. And event modeling gives you exactly that kind of precision. Every slice - every small, distinct business capability - is defined so clearly that there is almost no room for ambiguity.
The first slices we generated, I reviewed every single line. Carefully. Skeptically.
But here’s what I kept seeing: the code looked like code I would have written myself. Same structure. Same decisions. Because the blueprint architecture - the patterns we defined by hand at the start - became the rules the agent followed every single time.
At some point, I just stopped reviewing every slice. It didn’t happen dramatically. It quietly became unnecessary.
Step One - The Blueprint Architecture
Before the agent writes a single line on its own, you do something important by hand.
You take two or three slices - small, representative ones - and you implement them yourself. This takes maybe two to three hours. Not days. Not a week. A focused morning.
This is not throwaway work. This is the most important work in the entire process.
What you are doing is defining what “good” looks like for this specific project. How is a state change slice structured here? Where does the API layer live? Right now for example I’m defining this for Axon5 and DCB. How are test cases written? What does the command handler look like?
You answer those questions once, by hand, with full attention. Then you take those implemented slices and use them - together with AI - to generate skill files. One skill file per slice pattern. A skill file is just a precise description: “this is how we build things here.”
This is the structure. These are the rules.
From this point forward, the agent never has to guess. It has a template. It has examples. It has your decisions encoded as instructions.
Step Two - The Event Model as the Source of Truth
The specification lives in the event model - not in markdown files, not in tickets, not in a requirements document someone wrote six months ago and nobody reads anymore.
Every slice in the event model gets exported as a structured JSON file directly into the project repository. This means the specification is versioned alongside the code. You can see how it changed. You can revert it. The agent reads it directly - no translation, no interpretation, no ambiguity introduced in between.
Each slice also carries its behavior - the given/when/then rules that describe exactly what this slice should do, what it should allow, what it should reject. Three rules, five rules, sometimes thirty for a complex slice. All of it encoded before the agent starts.
When a slice is ready to be built, its status changes to planned. That’s the only signal the agent needs.
Step Three - The Night Shift
This is where the overnight magic happens - and it’s simpler than it sounds. And actually, it’s not necessarily overnight. It happens anytime during the day.
The agent runs in a loop. It looks for any slice in status planned. It picks one up, sets it to in progress, implements it according to the skill files and the given/when/then rules, runs the tests, records what it learned, and clears its context.
Then it starts again.
The context clearing is the key insight. Most people who work with AI agents long enough notice the same thing: the longer a session runs, the worse the output gets. Wrong decisions accumulate in the context. The agent gets confused by its own history.
The Ralph Loop solves this by treating every iteration as a fresh start - but carrying the learnings forward in a separate file that persists across iterations. Early on, that learnings file grows quickly. Corrections, adjustments, edge cases discovered. Over time it stabilizes. The agent stops making the same mistakes because they are already encoded as rules.
What you end up with is an agent that gets smarter the longer you run it - not dumber.
Step Four - The Check
When I get to the office, I check how many slices were implemented overnight.
If the tests are green, I move on.
That’s it.
Not because I stopped caring about quality - but because the quality is already enforced by the blueprint architecture, the skill files, and the given/when/then specifications. The agent didn’t make design decisions. It followed yours. The code looks like code you would have written yourself, because in a very real sense, you wrote the rules it followed.
Whether you incorporate a dedicated review, or you add more guardrails - fully dependent on the project itself.
What This Means for Your Team
Requirements still change - they always will. But with this approach, a changed requirement usually means one thing: update the slice in the event model, set it back to planned, and the agent picks it up in the next iteration.
You stop fearing change. You stop dreading the moment a client calls with new requirements. Because the system is built to absorb change without rework.
The thinking is still yours. The architecture is still yours. The business rules are still yours.
What you’ve automated is the boring part. And that turns out to be worth more than most people expect.
This is the Event Modeling Specification I use - also what is versioned and stored in code. I help Software Teams define those clear specifications for AI - and build maintainable systems that require no rework.
Learn Event Modeling from the experts
Join the Event Modeling Hands-On Workshop on March 16/17 — learn how to design systems that are honest from the start.
Want to learn how to apply Event Modeling and Event Sourcing in practice?
Follow the Online Course “Implementing Eventsourcing” - comes with a Lifetime Event Modeling Toolkit License.