I recently talked with one of our lead engineers, and the conversation stayed with me. He finds the new reality hard to accept, and he isn't the only one. AI and agentic coding are changing how we work. A team of AI agents can take over real parts of delivery. The architectures we grew up with, layered and hexagonal, are giving way to vertical slices. Aggregates and business entities are giving way to decisions protected by Dynamic Consistency Boundaries (DCB).
I understand the resistance. These patterns took years to master, and they served us well. Being asked to let go of them, at the same moment agents start writing code, is a lot. So I don't want to argue that those engineers were wrong. I want to explain what I think changed.
What layers and aggregates hide
Layered and hexagonal architectures organise code around technical concerns: controllers, services, repositories, ports and adapters. Aggregates organise it around entities. Both are sound engineering, and neither looks like the work the business actually does. That gap is one reason business and tech end up as two camps, which I wrote about in The telephone game between business and tech. Ask a business expert to find "change the delivery address" in a typical layered codebase and they won't find it. Splitting the system into services doesn't fix this either: a service is just a bigger technical container, and a single use case still cuts across several of them. A slice is the one unit that matches a use case exactly.
The code now mirrors the use case
Event Modeling and its four building blocks (state change, state view, automation and translation) close that gap. Every slice in the model is one business use case, and the code follows the same structure: each slice has its own place in the code, with one decision, the events it records, and the scenarios that say what correct means.
DCB is what makes this hold at the decision level. I wrote about it in Consistency Belongs to Decisions, Not to Aggregates. Each decision loads only the facts it needs and protects only those facts. You don't have to force the use case into an aggregate first, so the code can stay as close to the business story as the model is.
The result is that even a non-technical person can find their way around the code. The folder names are the use cases they talked about in the workshop, and they can read the scenarios. The two camps finally look at the same structure.
A slice is a work package an agent can handle
This matters even more now that agents write code. A slice is small and simple. It has a clear input, one decision, defined events and scenarios that pass or fail. That makes it a limited work package you can hand to an agent completely. The scenarios are executable acceptance checks, as I argued in How we test just became the specification. People agree on them before the work starts, and the agent can't change them. So the agent verifies its own work against a fixed definition of correct: it builds the slice, runs the scenarios and knows whether it's done. Building and verifying are both delegated, and nobody has to sit in the middle as a bottleneck.
Compare that with handing an agent a layered codebase and a vague ticket. The agent has to work out where the change belongs across several layers and entities, and nothing tells it whether it guessed right, so a human ends up checking. With slices, the scenarios answer that question, and the agent can answer it on its own.
It also makes the agents themselves easier to set up. Because every slice follows one of four shapes, the skills you give an agent are fairly straightforward to write: one skill for how to build a state change, one for a state view, and so on. You're describing four patterns, not a whole architecture.
What this asks of experienced engineers
None of this makes engineering judgment less important. Someone still has to get the model right, choose which facts a decision depends on, and decide when a slice deserves its own deployment. Those are hard questions, and they are exactly where experienced engineers are most valuable.
What changes is where that experience goes. Less of it goes into keeping layers and aggregates tidy. More goes into the model and the scenarios, where people define what correct means. Once that's defined, the agents can build and verify the slice on their own. For engineers who are good at their craft, I think that's a promotion, not a loss.
If you lead engineers who are wary of this shift, what's the part they find hardest to let go of?
Originally published on LinkedIn on 23 Oct 2026: https://www.linkedin.com/pulse/slices-services-gabriel-n-schenker-9yaoe/
