The pull request is 800 lines. It builds, the tests pass, and nobody can tell whether it's right without reading all of it, which costs more than writing it would have. This is the new normal with coding agents, and the data agrees: pull requests are getting bigger, reviews take longer, and refactoring has nearly stopped. We've made writing code almost free while leaving the cost of changing it exactly where it was. So what happens to architecture when the machine writes faster than we read? Which structure is actually cheapest to verify and change? And what stops our most prolific contributor, one that never tires and never develops judgment, from rebuilding the big ball of mud faster than we can tear it down?

In this session, we'll look at why vertical slices hold up when an agent is doing the typing: a change that fits in one context window, a blast radius that stops at the slice boundary, and tests that still mean something after a refactor.

We'll also walk through a layered application and reorganizing it around slices, comparing what each style costs to change. We'll cover the tradeoffs, because slices remove guardrails at exactly the moment we need them most. Finally, we'll look at the mechanical guardrails that replace team discipline: architecture tests, conventions that live in the repository, and a reference slice worth copying.