“Start With a Monolith” Was Good Advice. AI Is Changing That. | by Hiroyuki Yamada | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

“Start With a Monolith” Was Good Advice. AI Is Changing That.

Hiroyuki Yamada

4 min read·<br>Just now

Listen

Share

Press enter or click to view image in full size

Part 1 of “Architecture in the AI Era,” a series on how AI is reshaping the way we build systems.<br>“Don’t reach for microservices too early — start with a monolith.” For most of the last decade, that was the right call. Plenty of teams split their systems up long before they had a reason to, and paid for it in operational complexity and distributed-systems problems they hadn’t earned yet.<br>AI is changing the calculus behind that advice. Not because microservices became fashionable again, but because the economics of writing software are shifting — and some of the assumptions that made “monolith first” correct no longer hold the same way.<br>What changed<br>A large and growing share of code is now written by AI under human direction, and increasingly by agents that generate code with limited supervision and work several tasks in parallel. This makes development faster. But speed isn’t the only consequence — it also changes which architectures work with the way code now gets produced, and which work against it.<br>Three effects matter.<br>Smaller context produces better output. Models do better work when you hand them a tightly scoped problem. Keeping the relevant surface area small is now basic engineering hygiene, and the cleanest way to keep it small is to keep the software itself in small, well-bounded units.<br>Boundaries contain what an agent can change. When an agent writes code with limited supervision, the failure you most want to prevent is a change in one area silently reaching into something unrelated. In a single large codebase, scoping the agent’s context narrows what it sees but not what it can touch. Independent units put a physical boundary around the blast radius of any one change.<br>Independent release became a security property. A service you can deploy on its own — independent of the rest of the system — is also a service you can patch on its own. AI is getting rapidly better at finding vulnerabilities, and that cuts both ways: defenders surface issues faster, and so do attackers. As the window between a flaw being discovered and exploited shrinks, the ability to fix and ship one service without rebuilding and re-verifying the entire system stops being a convenience and starts being a security posture.<br>One caveat I’d insist on: none of this is an argument for microservices specifically. A modular monolith — one application cleanly divided inside — captures much of the same benefit. The principle is small, well-bounded units. Splitting into services is one way to get there, not the only one.<br>The variable everyone argues about is the wrong one<br>The benefit of separating services is usually framed around organizational size: big company, many teams, therefore microservices. That framing quietly tells every mid-sized team that the question isn’t theirs to ask.<br>It’s the wrong variable. What drives the benefit is the size and complexity of the software, not the size of the org. Teams fragment because the software grew — not the other way around. A thirty-person company with genuinely complex software gets the full return; a large company with simple software gets almost none. Framed correctly, the question isn’t “are we big enough for this?” It’s “is our software complex enough that keeping it in one block is slowing us down?” For many teams that was already true before AI. AI just raises the stakes, because the speed it unlocks compounds.<br>This is a business decision, not an engineering preference<br>It’s tempting to file architecture under engineering taste. I don’t think that holds here. When independent units let teams build and ship in parallel without blocking each other, the payoff isn’t a cleaner codebase — it’s shorter time to market and a faster response to change. In a market where AI is compressing how long it takes anyone to ship anything, that responsiveness is a competitive position, not a byproduct of it. Which is why the choice of architecture deserves attention at the level where business outcomes are owned — not only inside the engineering team.<br>The part that’s easy to underestimate<br>Splitting an application into services carries a cost that tends to surface later than the benefits do. Calls that were once in-process function calls become calls across a network, and you inherit a class of problems that didn’t exist inside a single process: latency, partial failure, services that are healthy while their dependencies are not.<br>The hardest of these is also the most boring to state: keeping data consistent when a single business operation spans several services, each owning its own database. Inside one database, “all of it commits or none of it does” is...