AI is changing software delivery, but maybe not in the way we first expected.

The obvious story is that AI can generate code faster. It can write tests, summarize documentation, create boilerplate, explain unfamiliar code, propose designs, and automate many of the small tasks that used to consume a lot of time in the classical software development lifecycle.

That part is visible. Everyone can see it. A prompt goes in, code comes out. But I think the deeper change is happening somewhere else.

As implementation becomes faster, unclear thinking becomes more expensive. A vague requirement that once caused weeks of slow misunderstanding can now become working code in minutes. It may compile. It may pass some tests. It may even look impressive in a demo. But if the underlying business intent is wrong, AI has not solved the problem. It has accelerated the creation of the wrong solution.

This is why I believe business solution design becomes more important in the age of AI, not less.

Not as a new isolated role that replaces everyone else. Quite the opposite. Business solution design must become a joint endeavour across the whole delivery organization.

Software engineers, quality engineers, architects, product managers, product owners, business analysts, operations, security, compliance, support, and domain experts are all affected by this shift. Their work will change. Some tasks will become automated. Some boundaries between roles will blur. Some old rituals may disappear. But the roles themselves will not simply vanish.

What becomes more important is the combined perspective these roles bring.

A product owner may understand the commercial intent. A business analyst may see the process and the exceptions. A software engineer may see where the model becomes too vague to implement cleanly. A QA may immediately ask what “correct” means in edge cases. An architect may see coupling, boundaries, and long-term consequences. Operations may see failure modes, observability, recoverability, and supportability. Security and compliance may see constraints that must not be treated as afterthoughts.

Each role looks at the same problem from a different angle.

One person alone may only see a 2D projection of the problem. It may look complete from that viewpoint, but something important is hidden. When multiple roles explore the same business activity together, the model gains depth. It becomes more like a 3D object. Add time, sequence, state changes, side effects, and lifecycle behaviour, and we are suddenly much closer to a 4D understanding of the system.

That is the kind of understanding AI needs.

Because AI does not remove ambiguity. It acts on ambiguity. If the business model is incomplete, AI will fill the gaps. It will make assumptions. It will choose names, boundaries, workflows, validations, error handling, data structures, and interactions. Some of those choices may be reasonable. Some may be wrong. The dangerous part is that they may remain hidden inside code that looks perfectly professional.

In the past, vague requirements often failed slowly. Teams discussed, implemented, tested, misunderstood, reworked, clarified, and corrected. It was inefficient, but the friction sometimes exposed the gaps.

With AI, the friction is reduced. That sounds good, and often it is. But it also means we lose some of the natural resistance that used to force clarification. If we are not careful, we move faster through the very parts where we should slow down.

This is where business solution design becomes a discipline, not just an activity.

It is the work of making business intent precise enough that humans can validate it and AI can implement it safely. It is not only about collecting requirements. It is not only about drawing architecture diagrams. It is not only about writing user stories or acceptance criteria. It is about shaping the business behaviour of the system before we ask machines to generate parts of it.

What is the actor trying to achieve?
What business decision is being made?
What command expresses the intent?
What event represents the outcome?
What information must be visible at that moment?
What rules decide whether the action is allowed?
What side effects should happen?
What must never happen?
What should be observable later?
Who needs to understand, approve, operate, or audit this behaviour?

• What is the actor trying to achieve?
• What business decision is being made?
• What command expresses the intent?
• What event represents the outcome?
• What information must be visible at that moment?
• What rules decide whether the action is allowed?
• What side effects should happen?
• What must never happen?
• What should be observable later?
• Who needs to understand, approve, operate, or audit this behaviour?

These are not purely technical questions. They are not purely business questions either. They sit in the space between business, product, architecture, quality, operations, and implementation. That is exactly why no single role should own them alone.

AI makes this joint modelling work more valuable because it creates a sharper distinction between two kinds of activity: deciding what the system should mean, and producing the artifacts that implement that meaning.

The second part is increasingly AI-assisted.

The first part still requires human judgment.

Someone still has to decide what “correct” means.

Someone still has to notice that two stakeholders are using the same word differently. Someone has to realize that a “cancellation” in one context is not the same as a “cancellation” in another. Someone has to ask whether an address change is merely a data update or whether it affects jurisdiction, communication, tax, premium collection, claims, or compliance. Someone has to see that a happy path is hiding five business rules and three operational concerns.

That someone should not be one heroic individual. It should be the delivery system itself, working through a shared model. This is why I keep coming back to EventModeling.

A prose specification can describe a system, but every reader still has to reconstruct the model in their own head. A Jira backlog can divide work into tickets, but it often fragments the bigger picture. Architecture diagrams can show technical structure, but they frequently miss the business behaviour. Test cases can describe expected outcomes, but they may appear too late if the model itself was never explicit.

An EventModel gives the team a different medium.

It makes the flow of business activity visible. It shows actors, views, commands, events, automations, translations, and business rules in one coherent picture. It allows different roles to reason about the same thing without forcing everything into prose or code too early.

The product person can ask whether the flow represents the intended customer or user experience.

The business analyst can challenge missing rules and exceptions.

The engineer can ask whether the commands and events are precise enough to implement.

The QA can turn scenarios into concrete examples.

The architect can examine boundaries and coupling.

Operations can ask what must be monitored, retried, reconciled, or supported.

Security and compliance can point out where permissions, auditability, or regulatory constraints must be part of the model.

The value is not only in the diagram. The value is in the conversation the diagram enables.

This is also why I think business solution design in the age of AI should not become another handover phase. We should not replace “business writes requirements and throws them over the wall to engineering” with “business solution designer creates a model and throws it over the wall to AI.”

That would repeat the same old mistake with better tooling.

The model must be co-created. It must be challenged. It must be reviewed from several angles. It must be concrete enough to guide implementation but understandable enough that non-technical stakeholders can still validate it. It must contain the happy path, but also allow drill-down into the rules and scenarios where the real business meaning often lives.

Only then does AI become genuinely useful.

Once the model is clear, AI can help in very powerful ways. It can generate implementation tasks slice by slice. It can create test cases from Given-When-Then scenarios. It can identify inconsistencies between commands, events, and views. It can propose missing edge cases. It can compare the implementation with the model. It can generate documentation that stays close to the business language. It can help teams move faster without asking the AI to invent the business.

That last point matters.

AI should not be asked to discover the business model from vague prose and scattered tickets. It should work from a model that humans have made explicit. It should implement within boundaries, not create the boundaries silently. It should help execute design decisions, not hide them.

This changes the meaning of productivity.

The goal is not simply to produce more code. Producing more code is easy. Producing more correct, coherent, maintainable, auditable business behaviour is harder. And in serious line-of-business systems, that is what matters.

If AI lowers the cost of implementation, then the cost of building the wrong thing becomes even less acceptable. The bottleneck shifts from typing speed to clarity. From local task completion to shared understanding. From individual output to collective design quality.

That is why the future of software delivery is not a world where all classical SDLC roles disappear. It is a world where their perspectives need to come together earlier and more deliberately.

The software engineer does not become irrelevant. The engineer becomes one of the people who can tell whether the model is implementable without accidental complexity.

The QA does not become irrelevant. QA becomes one of the people who can turn business intent into examples that expose ambiguity before it reaches production.

The architect does not become irrelevant. Architecture becomes less about abstract diagrams and more about ensuring that business capabilities, boundaries, and technical structures evolve together.

The product owner and product manager do not become irrelevant. Their responsibility for prioritization and outcomes becomes even more dependent on clear models of behaviour and value.

Operations does not become irrelevant. Operability must be designed into the business flow, not bolted on after AI has generated the system.

Business analysts do not become irrelevant. Their ability to uncover rules, exceptions, language, and process variations becomes more important when those details can immediately influence generated artifacts.

The roles change, but the need for their judgment remains.

Maybe the most important shift is that we can no longer afford to treat business solution design as something implicit. In many organizations, it happens informally in meetings, Slack threads, ticket comments, architecture reviews, QA discussions, and production incidents. The understanding exists, but it is scattered. AI needs something more explicit than scattered understanding.

It needs a model.

Humans need that model too.

Because the real promise of AI in software delivery is not that we can bypass design. It is that, with better design, we can make implementation much more direct.

That is the opportunity.

Not AI instead of business solution design.

AI because of better business solution design.

The better AI becomes at generating software artifacts, the more valuable the shared human activity of deciding what should be generated becomes. And that activity cannot belong to one role alone. It needs the full 3D, maybe even 4D, view of the business problem.

Different roles.

Different angles.

One shared model.

That may be one of the most important capabilities for software organizations in the age of AI.

Originally published on LinkedIn (2026-06-01): https://www.linkedin.com/pulse/ai-makes-business-solution-design-more-important-less-schenker-7md6e