In some of my recent articles I have argued that AI will not fix a broken SDLC, and that we need a blueprint before we hand work to an agent. There is a practical question hiding behind those arguments: what would I actually do if I had the opportunity to rebuild a substantial enterprise application today?
I am not thinking about a greenfield demo or a small application whose entire behavior fits comfortably into the head of a handful of developers. I mean a real system that has been running for years, contains thousands of business decisions, integrates with external parties, supports operations every day, and has accumulated the usual mixture of deliberate architecture, historical compromises, forgotten assumptions, workarounds and things nobody quite remembers the reason for.
Now add another assumption. The team has access to a very capable AI model, ideally the latest and greatest frontier model. It can inspect the entire codebase, tests, documentation, architecture diagrams, issue history and operational information. Context is no longer the limiting factor it once was. Given that capability, would I simply ask the agent to rewrite the application?
No. At least not yet.
I would first use it to help us rediscover what the system actually does.
Imagine a logistics platform
Consider a logistics company operating a platform that coordinates the collection and distribution of parcels and cargo from end to end. A customer requests a collection, a shipment is accepted, packages move through depots and sorting facilities, routes are planned, cargo may cross borders, delivery windows change, drivers report failed delivery attempts, shipments are redirected, items get damaged or lost, proof of delivery is recorded, and carriers and customers eventually need to be billed. None of these activities exists in isolation. What happens at one stage of the journey influences decisions made much later.
Over the years, the system supporting all of this has grown into a collection of services. One service deals with collection requests, another knows about shipments, others deal with routing, depots, tracking, delivery, customer communication and billing. Some communicate through events, others synchronously. Some contain carefully designed domain logic, others mostly manipulate data. Each owns some part of the overall state.
The architecture diagram may look quite respectable until someone asks a deceptively simple business question: what exactly happens when a customer changes the destination of a shipment that has already left the collection depot?
Suddenly the service diagram is far less useful. The answer might involve a customer portal, a shipment service, route planning, a depot application, notifications, billing rules and perhaps an external carrier. One part of the rule may even live in the user interface because, five years ago, that happened to be the easiest place to put it. Understanding the actual business behavior means following a path across organizational and technical boundaries that were never designed to explain the business process as a whole.
The system is organized one way. The business behaves another way. That difference matters.
The dangerous rewrite
If we decided to replace this platform, the obvious approach would be to study the existing architecture and reproduce it using newer technology. Shipment Service becomes the new Shipment Service. Routing Service becomes the new Routing Service. Interfaces are recreated, databases are migrated and existing APIs are preserved. Perhaps the implementation language changes. Perhaps the deployment architecture becomes cleaner. Perhaps the Kubernetes manifests are beautiful this time.
AI could make this considerably faster, but it could also make the mistake considerably faster because we would be treating the existing technical structure as if it were the definition of the business.
It is not.
The current architecture is partly business design, partly technology choice, partly organizational history and partly sediment left behind by earlier decisions. Some boundaries may still be excellent. Others may exist only because of a team structure that disappeared years ago, because of a technology limitation that no longer exists, or because two developers happened to be working on different parts of the system at the time.
A rewrite gives us an unusual opportunity. We can preserve the valuable thing, which is the business behavior, without automatically preserving every historical boundary around it. But to do that, we first need another representation of the system.
I would start with the business story
Before generating significant amounts of code, I would build a shallow Event Model of the entire logistics operation. I would not try to capture every decision and edge case immediately because that would quickly turn into another form of big design up front. At this stage I want the landscape, not every road sign.
Collection requested. Shipment accepted. Cargo collected. Shipment received at depot. Shipment assigned to route. Shipment loaded. Border clearance completed. Delivery attempted. Shipment delivered. Delivery failed. Shipment redirected. Shipment returned.
When we place these events in their business sequence and start connecting them, the real chapters of the system begin to appear. Arranging collection is one chapter. Moving goods through the distribution network is another. Last-mile delivery has its own story. Exceptions and returns form another. Billing may depend on facts produced across several of them.
Already this gives us something a service diagram cannot give us. It gives business people, engineers, testers and architects one place where they can point at the same process, follow the same timeline and ask the same questions. We can see where one business process influences another before deciding which application, service, database or team should own the implementation.
Only then would I start going deeper.
The slice becomes the unit of work
Within each chapter, I would model the individual slices of behaviour. I keep coming back to four patterns because an astonishing amount of enterprise software can be described with them: state change, automation, state view and translation.
A state change makes a business decision and records what happened. A customer requests that a shipment be redirected, for example, and the system decides whether that is still allowed. An automation reacts to something that has already happened and initiates the next action. A shipment arriving at a regional depot may trigger route planning. A state view presents information in the form required for a particular decision or interaction. A dispatcher needs a different view of a shipment than the customer tracking it from a phone. A translation connects our business model with somebody else’s model. A carrier, customs authority or warehouse system should not dictate the internal language of our application simply because we integrate with it.
These slices are deliberately small, but that is exactly the point. I do not want an agent to receive a Jira epic called “Improve shipment redirection” and discover the business while it generates the code. I want us to understand the slice first.
Who can request the redirection? Until what point in the journey is it allowed? What happens when the new destination requires a different carrier? What happens to the price? What if the parcel is already on a delivery vehicle? Which facts must be true before the decision can be made? Which previous events matter, and which are irrelevant to this particular decision?
At this point Given-When-Then scenarios become much more interesting. They are no longer acceptance criteria added at the end of an analysis process. They become executable examples of the business blueprint. They describe the behavior humans have discussed and agreed upon in a form that can also guide implementation and testing.
And now the agent finally has something useful to work with.
This is where I want AI
I would absolutely use an AI model during this design process. I would give it the existing code, tests, old specifications, tickets, API definitions, logs and whatever Event Models or diagrams already exist, then ask it to investigate how shipment redirection currently works.
The model can trace code paths that would take a human hours to follow. It can discover that one validation exists only in a frontend component. It can find an event consumer in another service that quietly changes billing behaviour. It can compare documentation with tests and implementation. It can identify rules that are implemented differently in two channels. It can draft the first version of the Event Model slice and propose scenarios for humans to review.
That is an excellent use of AI because it accelerates investigation without pretending that investigation and decision-making are the same thing.
I would not, however, let the model quietly decide what the correct business behaviour is. Suppose the documentation says a shipment can be redirected until it reaches the destination depot, while the existing application stops allowing it as soon as the shipment is loaded onto the line-haul vehicle. Which is correct?
That is not a coding question.
Perhaps the code contains a bug. Perhaps the documentation is outdated. Perhaps operations discovered years ago that later redirection creates unacceptable costs. Perhaps the rule differs depending on the carrier or the type of cargo. The model can find the discrepancy and assemble the evidence around it, but humans have to resolve it.
The result should not disappear inside a chat conversation either. The decision belongs in the blueprint, in the scenarios and ultimately in an automated test. An agent with access to everything does not magically turn conflicting information into truth. It simply becomes much better at finding the conflict.
That is already extremely valuable.
Then let the agents code
Once a slice has been understood, the relationship with AI changes. Now I want speed.
The Event Model defines the flow. The scenarios describe the behaviour. The architecture provides a small number of implementation patterns. The agent no longer has to invent the system from first principles every time it receives a task. It can implement one vertical slice whose purpose and boundaries are already understood.
The command or API entry point, the business decision, the resulting events, the projection required by the UI, any subsequent automation, the external translation and the tests can all be related back to the same piece of the blueprint. That traceability matters to me far more than the amount of code an agent can generate.
From a slice in the Event Model, I want to find its scenarios, implementation and tests. From a piece of implementation, I want to navigate back to the business behaviour that justified its existence. From a test failure, I want to understand which business scenario is no longer being satisfied. From an event, I want to know which decision produced it.
At that point AI-assisted development starts becoming much less mysterious. The agent is implementing constrained, understood behaviour instead of interpreting a pile of loosely related requirements and trying to guess what everybody meant.
I would also resist recreating the old architecture
There is another consequence of starting from the business blueprint. I would not begin by creating ten or twenty new microservices simply because the existing platform happened to have ten or twenty services.
For the first implementation I would probably choose a modular monolith. That will sound unfashionable to some people, and I am fine with that. A modular monolith gives us space to discover the right boundaries without paying the distributed-systems tax before we know whether those boundaries deserve to be distributed.
The Event Model gives us behavioral boundaries first. Operational evidence can later tell us where independent scaling, deployment, resilience, security requirements or ownership justify physical separation. This is almost the reverse of how many enterprise systems were built. Instead of drawing service boundaries and then trying to push business processes through them, I would let the business processes expose the boundaries.
On the write side, however, I would make a much stronger choice.
I would use Event Sourcing.
For a system of this complexity, CRUD would not be an option for the core business model.
A logistics platform is fundamentally concerned with things that happen over time. A shipment was accepted. It was collected. It entered a depot. It was assigned to a route. Its destination changed. A delivery was attempted. The customer was not present. Another attempt was scheduled. The parcel was eventually delivered, damaged, returned or lost. Later decisions depend not only on what the shipment looks like now, but also on what happened before, when it happened and sometimes why.
Reducing that history to the latest mutable row throws away information the business actually cares about. In a simple CRUD model we continually overwrite yesterday’s truth with today’s state and then spend enormous effort elsewhere trying to reconstruct what happened from audit tables, logs, integration messages and snapshots. In a system where the history of decisions matters, that strikes me as solving the wrong problem.
The events should be the record of the business.
Current state can always be derived from them.
I would combine this with Dynamic Consistency Boundaries rather than forcing every decision into a predefined aggregate. A decision about redirecting a shipment should load the business facts required to make that decision, no more and no less. Perhaps it needs to know that the shipment was accepted, that it has reached a particular depot, that it has not yet been loaded for final delivery and that no incompatible customs process is underway. Those facts define the consistency boundary for that decision.
If the relevant facts change before the resulting event is committed, then we have a consistency conflict. We reload the relevant context and evaluate the decision again against the new reality. There is no reason to pretend that every decision about a shipment must lock or load one enormous conceptual Shipment aggregate containing everything that has ever been associated with it.
This also fits naturally with Event Modeling because the things we model as business events become the things we actually store. The blueprint and the implementation speak the same language.
On the read side I would make the opposite choice and avoid creating one glorious canonical shipment model that everybody depends on. The dispatcher needs one representation. Customer tracking needs another. Billing needs something else. The warehouse worker scanning cargo at a depot may need only a tiny view. Management reporting may require yet another perspective.
Those views can be built as purpose-specific projections from the event history.
Projections are cheap.
Coupling is expensive.
The organization has to change with the architecture
None of this works particularly well if we keep the old handovers. Business analysts cannot model one piece, hand it to a domain representative, who hands stories to engineers, who later hand the implementation to testers, while everybody assumes that the previous group captured all the necessary context.
That process is exactly how information disappears.
For each chapter I would put a small group around the same model. Someone who understands the business, someone who can implement it, someone who thinks deeply about testing, and perhaps an architect or product person depending on the chapter. Titles matter less than having the necessary perspectives in the room.
They model together. They challenge assumptions together. They decide the scenarios together. Then they implement the slices end to end.
The service ownership map is no longer the work breakdown structure. The business behaviour is.
This is the part I think we risk missing in the current excitement about agentic software development. If we keep the same fragmented solution-design process and simply put powerful agents behind every role, we may only industrialise the handovers. Product generates more detailed requirements. Architecture generates more detailed designs. Development generates more code. QA generates more tests. Everybody becomes faster locally while the organization can still be wrong globally.
The agents may even make that fragmentation harder to notice because every local artifact suddenly looks much more polished.
How would I know whether the experiment worked?
I certainly would not measure success by how much code the agents produced. I would choose one meaningful logistics chapter and see whether a small cross-functional group could take it from modeling through validation into working software.
I would want to know how long a slice takes from an agreed scenario to running behaviour. I would want to see whether we can trace that behaviour from the Event Model into code and tests. I would measure how many contradictions between existing behaviour, documentation and intended business rules we discover along the way. I would watch whether the implementation remains understandable as more slices are added, and whether the common infrastructure stays small while most business behaviour remains local to the slices that own it.
Most importantly, I would want to know whether adding a new business rule still requires coordinating changes across half the architecture. If the blueprint and the implementation really follow the business, the blast radius of many changes should become much easier to understand.
Those results would tell me far more than a demonstration in which an agent generates an impressive application from a very large prompt.
The rewrite is almost secondary
The interesting part of this experiment is not really whether AI can rewrite a logistics platform. I am quite sure increasingly capable models will be able to produce enormous amounts of software. The more interesting question is what we choose to give them.
For decades the cost of implementation encouraged us to tolerate a surprising amount of ambiguity upstream because, eventually, experienced engineers would interpret the requirements, discover the missing cases and make the system work. AI changes that equation. When implementation becomes dramatically cheaper, ambiguity becomes more expensive, not less, because an agent can implement a misunderstood requirement with remarkable speed.
So I would use AI aggressively. I would use it to investigate the old system, expose hidden behaviour, draft models, suggest scenarios, trace dependencies, generate slices, write tests and accelerate implementation. I would use Event Sourcing so that the resulting system retains the complete history of the business rather than repeatedly overwriting it. I would let the Event Model define the language and shape of the system, and I would allow architecture to emerge from that understanding rather than treating yesterday’s service map as tomorrow’s blueprint.
But I would put one thing in front of all of it: a business blueprint that humans can inspect, discuss and agree on.
Then the agents can run.
And they will finally know where we want them to go.
Originally published on LinkedIn (2026-09-20): https://www.linkedin.com/pulse/rebuilding-enterprise-system-from-business-outward-schenker-5ywoe
