Many teams are now experimenting seriously with AI in the software delivery lifecycle. That is good. But I see a familiar pattern emerging.
At first, people use AI for what is often called vibe coding. You describe roughly what you want. The AI generates something. You tweak it. It generates more. For prototypes, experiments, and learning, this can be powerful.
The problem starts when we confuse that with a production-grade approach.
For a non-trivial line-of-business application, especially in a regulated domain, vibe coding is dangerous. Not because the AI is useless. Quite the opposite. It is dangerous because the AI is very capable, very fast, and very willing to produce something that looks plausible.
But plausible is not enough.
Imagine hiring a team of very smart junior developers. They have never worked in your domain. They do not know your company. They do not understand the history of your platform, your regulatory constraints, your business priorities, or the trade-offs that shaped your architecture.
Then you give them a few pages of loosely written requirements and ask them to build the system.
Would you be surprised if the result was not what you needed?
AI is not so different. It wants to help. It wants to produce an answer. But without a precise model of the business, it will fill the gaps itself.
And that is where accidental complexity begins.
Many people have recognised this, which is why spec-driven development has become popular in the AI-assisted development space.
That is definitely better than vibe coding. But I think it still has a problem.
The problem is not that specs are useless. The problem is that specs quickly become walls of text.
AI can generate huge specifications full of detailed prose. At first this feels rigorous. It feels like progress. But then a human has to review it.
And this is where things break down.
When we read a large specification, we create a mental model in our head. We try to imagine the process, the decisions, the data, the edge cases, the dependencies, the outcomes.
But if the specification contains too many details, the mental model becomes fragile. Each stakeholder builds a slightly different one. Business people see one thing. Engineers see another. Compliance sees a third. Product sees yet another.
The document looks shared. The understanding is not. This is why I believe we need to go beyond spec-driven development.
We need a blueprint.
Not a document that describes the model. A blueprint that is the model.
For me, this is where EventModeling becomes extremely powerful.
At the highest level, we can start with a map of the major business processes the application needs to support. In a Life & Health insurance platform, this might include customer onboarding, premium collection and arrears, policy cancellations, claims processing, and so on.
Each of these areas can then be broken down further.
Policy cancellations may include cancellation from inception, cancellation by administration, cancellation after non-payment, and other more specific processes.
Eventually, we reach the level I would call a business activity.
A business activity is a meaningful unit of work triggered by an actor that leads to a business outcome.
Examples could be:
Change policy owner bank details.
Change policy owner address.
Register first notice of loss.
Cancel policy from inception.
- Change policy owner bank details.
- Change policy owner address.
- Register first notice of loss.
- Cancel policy from inception.
At this level, EventModeling shines.
The goal is not to create one gigantic EventModel for the whole platform. That would just be another monolith, only this time on the wall.
Instead, each EventModel is more like a chapter in a book. The whole application is the book. A business activity is one chapter.
Each chapter can be modelled, reviewed, implemented, and evolved with relatively loose coupling to the other chapters.
This matters a lot when we bring AI into the picture.
An information-complete EventModel gives us something that prose specifications rarely give us: a visual, structured, human-reviewable model of the business activity.
It shows the flow of information.
It shows the actors.
It shows the views.
It shows the commands.
It shows the business events.
It shows the side effects.
It shows the outcomes.
- It shows the flow of information.
- It shows the actors.
- It shows the views.
- It shows the commands.
- It shows the business events.
- It shows the side effects.
- It shows the outcomes.
And, if designed well, it does this without overwhelming the people who need to understand it.
The happy path can remain visible at the surface.
The details can be available through drill-down.
That is important because the subtle parts of a business activity usually live in the business rules.
Take something simple like changing an address.
On the surface, it sounds trivial.
A call center agent opens the customer view, enters a new address, clicks a button, and the address is changed.
But the business rules matter.
Does the person requesting the change really exist?
Is the person allowed to request this change?
Does the policy exist?
Is the policy active?
Is the new address valid?
Is the new address still within the allowed jurisdiction?
Should this change trigger downstream communication?
Should it affect an open claim?
Should it affect premium collection?
etc.
- Does the person requesting the change really exist?
- Is the person allowed to request this change?
- Does the policy exist?
- Is the policy active?
- Is the new address valid?
- Is the new address still within the allowed jurisdiction?
- Should this change trigger downstream communication?
- Should it affect an open claim?
- Should it affect premium collection?
- etc.
These are not implementation details. They are business decisions.
And they need to be modeled where they belong: inside the slice of the EventModel that represents the activity.
This is also where Given-When-Then becomes more interesting.
We can describe the rules in text, and that is already useful.
But I think the better version is to express the scenarios directly in terms of events and commands.
GIVEN these past business events
WHEN this command is issued
THEN this business event is produced
- GIVEN these past business events
- WHEN this command is issued
- THEN this business event is produced
With meaningful example data.
That makes the rule concrete. It makes it reviewable. It makes it testable. And it keeps the language close to the actual business flow.
Now comes the AI part.
Once we have an information-complete EventModel, we can use AI in a very different way. We no longer ask the AI to invent a system from a large ambiguous specification. We ask it to implement a slice:
one slice
of a known type
using a known reference implementation
with known input
with known output
with known business rules
with tests derived from the scenarios.
- one slice
- of a known type
- using a known reference implementation
- with known input
- with known output
- with known business rules
- with tests derived from the scenarios.
That is a completely different task.
For example a prompt could be:
Implement slice A1 of the “change policy owner address” EventModel. This slice is a state change. Use the state change reference implementation. The actor is the call center agent. The command is ChangePolicyOwnerAddress. The successful outcome is PolicyOwnerAddressChanged. Cover all Given-When-Then scenarios as tests.
Now the AI is not wandering through a fog of prose. It is working from a blueprint.
And because each slice maps to one of a small number of foundational building blocks, the implementation approach can be highly constrained.
State change
State view
Automation
Translation
- State change
- State view
- Automation
- Translation
That is the part I find most exciting.
The complexity of a business application does not have to come from inventing new technical shapes all the time.
It can emerge from combining a small number of understandable building blocks in business-meaningful ways.
This also changes the role of the human.
The human is not there to review thousands of lines of AI-generated prose and hope no important ambiguity slipped through.
The human is there to shape, challenge, and validate the business model.
Does this business event mean the right thing? Is this command expressing the real intent? Are we missing a rule? Is this actor allowed to do this? Is this outcome auditable? Does this slice belong in this chapter?
That is where business solution design belongs. And that is where AI can become genuinely useful. Not as a replacement for thinking. Not as a shortcut around modeling. Not as a machine that magically turns vague wishes into enterprise-grade systems.
AI becomes useful when we give it a precise, visual, information-complete blueprint and ask it to execute within clear boundaries.
So perhaps the question is not whether EventModeling is better than spec-driven development. The better question is: How do we go beyond specs that humans struggle to review, towards blueprints that humans and AI can both work from?
My answer is simple.
Use EventModeling to design the business solution
Use scenarios to make the business rules explicit
Use slices to keep the work small
Use reference implementations to constrain the AI
Then let AI help with implementation.
- Use EventModeling to design the business solution
- Use scenarios to make the business rules explicit
- Use slices to keep the work small
- Use reference implementations to constrain the AI
- Then let AI help with implementation.
But keep the EventModel as the source of truth. Because in serious line-of-business systems, the biggest risk is not that AI writes code too slowly.
The biggest risk is that it writes the wrong system very quickly.
Originally published on LinkedIn (2026-05-29): https://www.linkedin.com/pulse/ai-does-need-more-specs-needs-better-blueprints-gabriel-n-schenker-mr0de
