AI can produce more software, more documentation, more tests, more pull requests and more analysis than humans can reasonably consume. At first sight that looks like an obvious productivity breakthrough, and in many ways it is. But there is a problem hidden inside that productivity gain. If our way of trusting the output of an AI agent is still to have a human read everything the agent produces, then we have not actually solved the scaling problem. We have simply moved the bottleneck somewhere else.
An agent can create a twenty-page specification almost instantly. Another can turn it into code. Another can generate hundreds of tests. Yet another can review the pull request. Somewhere at the end of that chain, however, we still seem to expect a human being to decide whether all of it is actually correct. That approach does not scale. The answer, in my view, is not to create even more detailed specifications. It is to make the blueprint itself verifiable.
Trust has to come from constraints, not from reading everything
When I talk about trusting AI-generated output, I do not mean blindly accepting whatever an agent produces. Quite the opposite. Trust should come from our ability to subject that output to simple, explicit and repeatable checks.
Today we often create trust through review. Someone writes something, someone else reads it, perhaps a third person approves it. That model already struggles in normal software development. AI makes the asymmetry much worse because machines can produce information many orders of magnitude faster than humans can consume it. We will never win that race by reading faster, adding more reviewers or creating bigger approval chains. We need to reduce the amount of interpretation required in the first place.
That is one reason I find Event Modeling increasingly interesting in the context of AI-assisted software development. Not because an Event Model is a prettier requirements document, and not because diagrams are somehow inherently better than text. The important difference is that the model gives us structure that can be checked.
Information complete does not mean exhaustive
This distinction matters because a specification can contain an enormous amount of detail and still leave important questions unanswered. The opposite is also true. A relatively compact model can contain all the information required to implement and verify a piece of behaviour.
For me, an information-complete blueprint is not one that describes everything in prose. It is one where the important questions have explicit answers. Where did this information come from? What can cause this state change? What fact is recorded when it happens? What information can a user see when making the decision? What happens automatically afterwards? Which business rules must always hold? Which other part of the system is allowed to depend on this behaviour?
Those questions become much easier to reason about when the solution is built from a small number of well-defined building blocks rather than described in an ever-growing body of text.
Four building blocks give us a grammar
In the way I use Event Modeling, a business solution is divided into chapters, and chapters are divided into slices. Each slice represents one of four foundational patterns: a state change, a state view, an automation, or a translation between systems.
That restriction is useful because it creates a grammar. Instead of allowing every team, engineer or agent to invent its own structure, we constrain what a slice can be. Once you have that kind of grammar, you can validate against it.
A state-changing slice, for example, has certain things we should expect to find. There is an intention expressed as a command. There is information available to make the decision. There are business rules that determine whether the command is allowed. If the command succeeds, a business fact is recorded as an event.
A view has a different purpose. It consumes facts and produces information for a particular need. An automation reacts to facts and triggers further behaviour. A translation converts information at a system boundary.
The model does not have to explain all of this again in paragraphs every time. Part of the meaning is carried by the structure itself. That is fundamentally different from a large functional specification, where the reader often has to rediscover the structure by interpreting the text.
Data should never appear from nowhere
Another powerful check is data provenance. Every piece of information used by the system should have an origin. If a field appears on a screen, where did it come from? If a command contains an attribute, who supplied it? If an event contains a fact, what decision produced it? If a projection contains a value, from which events was it derived?
A data attribute should be traceable through the model. Nothing should simply appear because an engineer, analyst or agent assumed that it must exist somewhere.
This sounds almost trivial, but in large systems it is surprisingly common for concepts and attributes to gradually acquire a life of their own. One team introduces a field. Another creates its own interpretation of the same field. A third builds logic around it. Eventually nobody can clearly explain which version represents the actual business fact or where the data originated.
An information-complete blueprint makes those relationships visible. Once they are visible, they can be checked.
Scenarios turn behaviour into something testable
Structure alone is not enough, of course. We also need to describe expected behaviour, and this is where scenarios become important.
For every slice we can express concrete examples using Given, When, Then. The important part for me is that the Given, When and Then should not become another layer of abstract prose. They should use the actual elements of the model. Given these events have happened. When this command is issued. Then this event should happen, or this command should be rejected.
That connects the business intent directly to the model. The same scenarios can be understood by business experts, used by engineers during implementation, turned into acceptance tests and evaluated by machines. They are not another interpretation of the requirements. They are part of the blueprint itself.
This gives us another set of rules against which generated output can be checked.
Invariants define what must never become untrue
Examples are valuable, but examples only cover individual situations. Some business rules are stronger than that because they must hold regardless of the specific scenario. Those are invariants.
A policy must not be cancelled twice. A payment must not be allocated beyond the outstanding amount. A claim payment must not exceed an approved limit. The actual invariants will differ from one domain to another, but the principle is the same. There are conditions that define valid business state and that should never be violated.
If those invariants are part of the blueprint, they become another verification mechanism. Now an implementation is not merely judged by whether a few expected examples work. It must also preserve the properties that the business considers non-negotiable.
That becomes increasingly important when agents start producing implementation code. The faster we can generate code, the more valuable these kinds of explicit boundaries become.
Events are the contracts between slices
There is another constraint I consider essential. Slices should not become coupled through shared internal concepts. Not through shared aggregates, common domain objects or some giant canonical business entity that everybody is allowed to reach into.
They should communicate through business facts: events.
If PolicyCancelled has happened, that is a fact another part of the system may react to. The consumer does not need access to the internal model that decided whether the policy could be cancelled. It only needs the fact that the cancellation happened and the information required to act on that fact.
This is why I believe important business events should be treated as contracts and curated accordingly, for example in an event registry. Their meaning matters, their ownership matters, their evolution matters, and their use can be checked.
If a slice consumes information it should not know about, we can detect it. If it depends on another slice’s internals, we can detect it. If an agent invents a new coupling path because it happens to be convenient, we can reject it.
This matters because accidental coupling is one of the biggest contributors to complexity in software systems. Once everything knows about everything else, every change becomes harder to reason about. AI can generate code very quickly, but it can also generate a tightly coupled system very quickly. Speed does not make coupling less dangerous. It merely allows the consequences to arrive sooner.
Why a detailed functional specification is not the same thing
At this point someone will reasonably say that all of this can also be described in a sufficiently detailed functional specification. I don’t think that solves the same problem.
The first issue is the form itself. A text document is primarily designed to be read and interpreted by humans. You can make it longer, more precise, add tables, acceptance criteria and diagrams, but at some point somebody still has to interpret whether all those pieces are consistent with one another. More text often increases that burden rather than reducing it.
The second issue is how those specifications are commonly created. In many organisations, business intent moves sequentially from a business expert to a business analyst, from analyst to product owner, from product owner to engineer, and from engineer to QA. Each step translates the previous one.
I sometimes call this the telephone game of software development.
Every translation creates another representation of the problem, and every representation creates another opportunity for information to be lost, reinterpreted or invented. Eventually we have a business description, requirements, epics, user stories, acceptance criteria, technical designs, test cases and implementation code. Then we spend an extraordinary amount of effort trying to make sure they all still describe the same thing.
One model, created together
The more important difference with Event Modeling is therefore not the notation. It is the collaboration around the model.
The Event Model should not be created by a business analyst and then handed over to engineering. It should be built together. Business experts, product, engineering, QA and other relevant stakeholders work on the same model. They disagree in front of the same blueprint. They resolve ambiguity there. They use the same concepts.
The model becomes jointly owned.
That gives us one source of truth, one language and, perhaps most importantly, one shared mental model of how the business process should behave.
AI can participate in this process. It can suggest slices, identify missing scenarios, ask where data came from, spot an event that nobody consumes, identify an attribute that appears without an origin, or propose Given/When/Then scenarios. I see a lot of value in using AI exactly this way.
But I would not want the agent to become the owner of the model. The business intent still has to be agreed by humans. That is the part we should not automate away.
Human judgment at the boundary, automation inside it
This leads to a distinction I think will become increasingly important. We cannot automate the question of whether this is the business behaviour we actually want.
That requires people who understand the business, the customer, the risks, the regulation and the consequences. It requires discussion, disagreement and sometimes judgment where there is no simple rule to apply.
But once that intent has been made explicit and agreed, we can automate a great deal of what follows. We can check whether every attribute has an origin, whether every state-changing slice produces a defined business fact, whether scenarios refer to elements that actually exist in the model, whether invariants are covered, whether a slice depends only on allowed contracts, whether the implementation conforms to the blueprint, whether the tests demonstrate the scenarios, and eventually whether production behaviour still matches what was designed.
Those are very different questions from asking somebody to read three thousand lines and decide whether they look right.
For me, that is where the real opportunity lies.
AI makes good structure more important, not less
There is an understandable temptation to think that better AI means we need less structure. If the agent is clever enough, perhaps we can describe roughly what we want and let it work out the rest.
I expect the opposite.
The more capable our agents become, the more important it will be to define the boundaries within which they can operate independently. Otherwise their productivity simply becomes our review problem.
I do not want an army of agents producing endless artefacts that an army of humans then has to inspect. I want agents operating against an explicit business blueprint, with rules that make most incorrect output rejectable automatically.
That requires the blueprint to be information complete, but it does not require it to be enormous. It requires structure, traceability, explicit behaviour and contracts. Most importantly, it requires humans to agree on the business intent before machines start multiplying the implementation.
The future of AI-assisted software development may therefore depend much less on writing ever more detailed specifications for agents, and much more on creating models that leave less room for interpretation and far more room for verification.
Originally published on LinkedIn (2026-09-25): https://www.linkedin.com/pulse/information-complete-same-detailed-gabriel-n-schenker-uybee
