How Event Modeling Became the Perfect AI Enabler (And Why Vibe Coding Will Always Fail)

Four years ago, I had a realization that changed everything: our current way of building software simply doesn’t work and will never scale.

I was watching the same pattern repeat on every project. Build something. Review it. Change it. Rebuild it. Everyone calls it “scope creep,” but that’s not what it really is.

It’s a fundamental alignment problem.

People never agreed on what was important in the first place. The endless ping-pong between developers and stakeholders wasn’t about changing requirements - it was about never having clear requirements to begin with.

Then AI arrived, and I watched everyone get excited about a “revolution” in software development.

But here’s what I saw: we just replaced the developer with AI and kept doing the exact same broken thing.

The Vibe Coding Trap

When the first vibe coding examples came out, I thought: “Wait a second… how is this different from what we’ve been doing the last few years? We just switched out the dev.”

People were throwing prompts at AI like they used to throw requirements at developers. Same endless back-and-forth. Same frustration, maybe even worse.. Same lack of clarity.

You can’t vibe your way to working software - whether you’re working with humans or AI.

The problem was never the developer. The problem was always the lack of alignment on what we’re actually building and why.

The Breakthrough: Event Modeling as the Foundation

Everything changed for me when I started working seriously and professionally with Event Modeling.

Event Modeling solved the human alignment problem. You sit down with stakeholders, you map out exactly what the system needs to do - event by event, step by step, slice by slice - and suddenly everyone is looking at the same picture. No guesswork. No ambiguity.

Then I had another realization: if Event Modeling creates crystal-clear alignment for humans, why not use it as the source of truth for AI?

So I tried it. I gave AI the full Event Model and simply said: “Build it.”

And it worked. Beautifully so..

Not kind of worked. Not “worked with a ton of fixes.” It actually worked with minimal intervention.

The Two-Layer System That Makes It Possible

After a lot of experimentation, I discovered the structure that makes this reliable:

Layer 1: Rules Files - These define how to structure things - the architectural foundation. They tell AI how you want your code organized, what patterns to follow, what frameworks to use.

Layer 2: The Event Model - This explains what to build - the complete blueprint of your system’s behavior, flows, and logic.

Add in some additional building blocks:

• Slicing to create minimal context boundaries
• Given-When-Then statements for business rules that become inline comments

The result? 80-90% of your backend code generated automatically.

The Process: From Idea to Production in Days (Not Months)

Here’s exactly how this works in practice:

Step 1: Event Modeling (Hours to Days)

Start with stakeholders. Don’t skip this. This is where you align on:

• What problem are we solving?
• What does the vision look like?
• What are the actual flows and decisions?

You build the Event Model gradually. Sometimes it takes a few hours. Sometimes a few days for complex systems. But you’re creating the foundation for everything that follows.

Step 2: Validation (30 Minutes - 2 hours)

Take that Event Model and:

• Build the narrative from it - read the story
• Walk through the narrative with stakeholders
• Generate an in-browser prototype directly from the model

This is your sanity check. Stakeholders can click through the flows, see what’s happening, and confirm: “Yes, this makes sense.”

Sometimes we catch crucial missing steps here. Most often, if the Event Modeling was done well, we’re good to go. When we do find issues, we go back to the model - not the code.

Step 3: Backend Generation (Slice by Slice)

Now the magic happens:

• Static code generator creates the skeletons for your entire backend architecture - services, contracts, data structures - all based on your Event Model
• Generate an OpenAPI spec so frontend and backend have a clear contract
• Given-When-Thens become AI-TODO comments embedded in the code
• Use Claude Code (or similar) to implement the business logic by working through those AI-TODOs slice by slice

Why does this work so well? Slices create minimal context boundaries.

AI doesn’t need to understand your entire system. It just needs to understand one slice at a time. The Event Model provides perfect context for each slice, and AI fills in the logic based on the Given-When-Then rules.

You can use one of the provided Code Generators or simply hook up your own ( using AI can be done in a matter of hours.. )

Step 4: Frontend Generation

The frontend is just as automated:

• Use tools like Lovable, if you want to go fast for a first draft
• Feed them the Event Model and OpenAPI spec ( generated from the Event Model )
• The frontend generates reliably because it knows exactly what the backend expects
• Contract-driven development means both sides speak the same language

To keep the cost curve flat, we also use the Slicing Concept in the Frontend - clear separation for components and modules. This typically requires some adjustments in the generated Code if you use Lovable - but still much faster than anything I have ever seen.

Step 5: Infrastructure & Deploy

Define your infrastructure concerns, hook everything together, and you’re ready to deploy.

Total time from idea to deployable software? Days. Sometimes hours.

Compare that to traditional development: weeks of requirements gathering, months of development, constant back-and-forth, endless scope changes.

The Real Game-Changer: The Flat Cost Curve

But speed isn’t even the biggest win here.

The real breakthrough is what happens after you ship.

In traditional software development, there’s a brutal truth everyone knows but nobody talks about: the more features you add, the slower everything gets.

It’s the coupling trap. More features mean more coupling. More coupling means every change touches more of the system. Small changes start taking ages. Simple bug fixes become expensive.

The cost curve goes exponential.

With slices, this doesn’t happen.

Because slices contain coupling within clear boundaries, changes only impact a few slices - never the whole system. You know exactly which slices need to be adjusted. The cost curve stays flat.

How Maintenance Actually Works

Three months after you ship, the client needs a change. New feature. Modified business rule. Whatever.

Here’s what you do:

1. Go back to the Event Model (always start with the model)
2. Update the affected slices
3. Regenerate just those slices (backend + frontend)
4. Deploy

You’re not excavating through layers of coupled code trying to figure out what will break. You’re working with the same clear model you started with, making surgical changes to specific slices.

The process repeats. The speed stays consistent.

This Isn’t Theory - It’s Proven at Scale

Here’s what most people don’t know: this approach isn’t experimental.

My partner company Adaptech have been doing this for over a decade. Adam Dymitruk - the founder of Event Modeling itself - is the CEO of Adaptech. It works at scale and we can prove it.

The track record?

• Hundreds of systems built this way
• Bug fixes for free
• Fixed-cost development
• Sustained velocity over years

The methodology works. It’s been proven at scale, across industries, over time.

And with AI, we go even faster..

Why This Changes Everything

Let me be direct about what this means:

Traditional approach:

• Weeks/months from idea to production
• Constant misalignment and rework
• Exponentially increasing cost of change
• Every project is a gamble

AI-enabled Event Modeling approach:

• Days/hours from idea to production
• Clear alignment from day one
• Flat cost curve over product lifetime
• Repeatable, predictable process

AI is the accelerant. Event Modeling is the structure that makes it work.

Without the structure, you’re just vibe coding - and that fails with AI the same way it failed with human developers.

With the structure, you have something transformative.

The Industry Is Changing - You Can Participate

Here’s the reality: you can watch this shift happen, or you can be part of it.

I’m actively seeking teams to support. If you want a flat cost curve and real speed in your development process, this is the best approach I’ve found in 20 years.

Here’s how to get started today:

Event Modeling Toolkit - Provides the complete foundation. Everything you need to model systems from scratch and use the code generators is built right in.

Workshop - The fastest way to learn this approach. My next training is at the end of the october, and I personally work with a small group of technical leaders to get them confidently modeling and building.

Book + Online Course - Self-paced learning for teams who want to start on their own timeline. Tons of material available.

Have a chat directly next week - let´s find out, how this could work for you.

The Choice

The choice is simple: keep doing what you always did to get what you always got.. I know companies that spend hundreds of dollars, some thousands per developer on AI. Just using this approach allows to massively safe on tokens, as you don´t have the expensive ping-pong. The problem isn´t solved with AI - you only pay AI instead of a human - time to break this chain.

I’m building with teams who want to move this fast. Teams who are tired of the coupling trap and the exponential cost curve. Teams who see that AI is a tool, but only if you give it the right foundation.

If you’re ready to see what’s possible when you combine Event Modeling with AI-enabled development, DM me. Let´s have a chat and see, what is possible.

Sometimes you need some new ideas to solve some very old problems. Let’s build something that actually works.

Martin Dilger Founder & CEO, Nebulit Event Modeling Expert | Architecture Consulting