I have been reading
AWS Marketplace’s report on “The Role of AI in Software Development”.

There are useful ideas in it. I am not against AI in the SDLC. Quite the opposite. I use it every day.

But I disagree with the underlying direction.

The report takes the current SDLC as more or less given and then shows how AI can be applied to each phase: planning, design, coding, verification, integration, release, deployment, operations, monitoring.

That sounds reasonable at first.

But what if the current SDLC is the problem?

What if the issue is not that backlog grooming is too slow, sprint planning is too manual, acceptance criteria are too tedious to write, test generation takes too long, release notes are annoying, deployments are complex, and monitoring produces too many alerts?

What if those are symptoms of a deeper design problem?

When I looked at the SDLC diagram in the report, the first thing that struck me was the size of “Plan”. It is a small step in the loop. Almost a passing station before the “real work” starts.

That is where I think many organizations go wrong.

For me, the planning phase is not a small administrative step. It is where the business solution is designed.

I increasingly call this Business Solution Design.

Not requirements gathering. Not ticket writing. Not a handover from business to IT. Not “please document what you want so engineering can estimate it”.

Business Solution Design is the place where business, engineering, architecture, QA, security, compliance, audit, operations, and observability look at the same problem together.

This is where the system is shaped.

If we do that badly, AI will not save us. It will just help us produce more artifacts from a flawed understanding.

More user stories. More acceptance criteria. More test cases. More generated code. More dashboards. More tickets. More ceremonies to coordinate the mess.

Faster mud is still mud.

The report suggests that AI can help generate acceptance tests from user stories and acceptance criteria. I understand the appeal. But I would rather not start with user stories and then ask AI to infer the tests.

I want the business behavior to be explicit before the ticket exists.

This is where EventModeling becomes so powerful.

With EventModeling, we model the business process over time. We make business events visible. We identify commands, decisions, policies, state views, automations, translations, and the people or systems involved.

Then we slice the model vertically into small foundational units:

State change. State view. Automation. Translation.

These are not arbitrary tickets. They are business units of behavior.

Each slice contains the business rule, the command, the resulting event, the read model or automation, and the examples that prove it works.

At that point, coding often becomes surprisingly boring.

And boring is good.

A new slice is frequently a variation of an existing slice. Copy a proven pattern. Rename the command. Rename the event. Adjust the data attributes. Add the business rule. Add the tests that were already implied by the model.

The hard work moved earlier, where it belongs.

The report also talks about AI suggesting security controls, generating threat models, scanning code, finding vulnerabilities, and improving security during coding, verification, release, and deployment.

Again, useful.

But I do not want security to be mainly a downstream correction mechanism.

Security controls should be part of the business model.

In an EventModel, every business activity is explicit. That means every activity can have a permission. RBAC no longer needs to be invented around abstract technical entities after the fact.

The business defines the roles. The business defines which activities each role may perform. The permissions follow the modeled activities.

There is much less room for misunderstanding because access control is aligned with the way the business actually works.

The same is true for compliance.

The same is true for auditability.

If the business process is modeled as a chain of events, the audit trail is not a separate reporting afterthought. It is the system’s memory.

Who did what? When? Based on which command? Which business rule allowed it? Which event was recorded? Which state view changed afterwards?

This is not something I want to reconstruct from logs three months later.

The report also spends a lot of space on monitoring and observability. Most of it is technical observability: logs, alerts, traces, anomaly detection, incident response, runbooks.

All important.

But business observability is different.

Business observability asks questions like:

How many applications are stuck in underwriting? How many policies are waiting for payment confirmation? Which cancellations are pending manual approval? Where are claims not progressing? Which partner journey is creating business exceptions?

In an EventModel, business observability is not a separate platform bolted on later.

It is another state view slice here and there.

If the business needs visibility, we model the view. We derive it from events. We make it part of the blueprint.

This also changes planning.

If work is sliced into small, similar foundational units, planning stops being a guessing game. The effort calculation becomes much closer to counting than estimating.

How many state changes? How many state views? How many automations? How many translations? How many integrations have unusual complexity?

There will always be exceptions. Some slices are harder. Some integrations are ugly. Some domains are unclear.

But the overall shape becomes much more predictable.

That removes a lot of the ceremonies we have normalized.

Less backlog grooming. Less sprint planning theatre. Less chasing ticket status. Less long alignment meetings. Less “who is blocked by whom?” Less pretending that story points are science.

I am not saying AI has no role here.

AI can be extremely valuable.

It can challenge the EventModel. It can find missing edge cases. It can draft examples. It can suggest business rules that may have been forgotten. It can generate slice templates. It can help compare similar flows. It can produce code from a well-structured blueprint. It can help create state views for business observability. It can support compliance and security reviews.

But then AI is assisting Business Solution Design.

It is not compensating for the absence of it.

That is the distinction I care about.

My concern with many “AI in the SDLC” narratives is that they accept the current fragmented SDLC and then automate the fragmentation.

AI-generated tickets are still tickets. AI-generated tests are still late if the behavior was never properly designed. AI-generated dashboards are still weak if the business questions were not modeled. AI-assisted security is still reactive if controls were not part of the business activity. AI-optimized deployment is still painful if the system is not sliced for safe change.

The real opportunity is not to sprinkle AI over the existing SDLC.

The opportunity is to rethink how we design business solutions in the first place.

Start with the business flow. Make time visible. Make decisions visible. Make controls visible. Make permissions visible. Make auditability visible. Make business observability visible.

Then let AI help us move from blueprint to implementation.

That is where I believe the leverage is.

Not in making the mud move faster.

Originally published on LinkedIn (2026-06-24): https://www.linkedin.com/pulse/ai-fix-broken-sdlc-gabriel-n-schenker-s3wbe