Ran writes Founder Mode as the builder, not the pundit, and this is his most old-fashioned argument yet: the way to build software with agents is the way we have raised towers for a century. Decompose the system into blocks simple enough that whoever lays them - a junior, you at 2am, or a model with a finite context window - cannot get it catastrophically wrong. It reads like a call back to boring engineering discipline, and that is the point. The interfaces and tight scopes that always felt like overhead are exactly what made the work delegable. We just finally have something fast enough to delegate to. — Muximus
The best way to build software is the way we build towers
Go look at how a hundred-story tower gets built. It isn't raised by geniuses. It's raised by laborers, and each one is doing something almost insultingly simple: put this block here, spread the mortar, put the next block on top. No single person on that site is holding the whole building in their head. Each piece is laid, checked, and finished on its own, and only at the very end do all those simple pieces add up to something that stands.
The magic was never in the laborer. It was in the plan that made the work simple enough to hand off in the first place. Civil engineers have built this way for a very long time. It's roughly how software engineers should be building now.
The analogy, made explicit
Civil engineer is to software engineer as the architect's drawings are to system design.
The civil engineer doesn't lay bricks. They decide what gets built, in what order, to what spec, so that the people - or the machines - doing the laying can't get it catastrophically wrong. The spec is where the intelligence lives. The laying is meant to be simple, because simple is what makes it safe to delegate.
That is exactly the software engineer's job now. Not to type the code. To decompose the system so the execution layer can be simple and safe. This is the architect I've written about before - the hybrid of product owner, PM, senior engineer, and team lead. The person who can draw the whole system on a whiteboard from memory and tell you why every decision was made the way it was. Decomposition isn't a side effect of that role. It's the core craft of it.
Decomposition was always right
I want to be careful here, because this is easy to mistake for an "agents changed everything" take, and it isn't one. Decomposition was the right way to build software long before any of us handed work to a model. Agents didn't invent the discipline. They just took away your option to ignore it.
The discipline is the same at every scale: break the system into small, clearly-scoped blocks; make each one testable and verifiable on its own; compose them at the end. The intelligence lives in the plan, not in the execution. That was true when the executor was a room full of engineers, and it's true now that some of the executors are machines.
Why it works, all the way up the ladder
Start with a solo developer. Small blocks mean you hold exactly one thing in your head at a time - less surface area for bugs, and you get to test each piece before you move to the next. You never have to carry the whole system in working memory, because you designed it so you wouldn't have to.
Now a team. Clear interfaces let people work in parallel without stepping on each other. The contract between two blocks - what goes in, what comes out - is the coordination. You don't need a meeting to sync two people whose blocks meet at a well-defined seam. The seam does the coordinating.
Now agents. Same discipline, except now it's load-bearing. An agent has a finite context window. Tight scope isn't a nicety anymore; it's literally what makes the work fit in the space the agent has to think in. Hand a model a sprawling, half-defined job and it runs out of room and starts guessing. Hand it a small, sharply bounded block and it can actually finish it.
The real point: decomposition is context control
Here's the part I care about most, because it's the part people miss when they file this under "modularity, good."
A human juggling one giant module and an agent drowning in one giant prompt are the same failure. Too much unscoped surface. In both cases the executor is trying to hold more than it can, and the output degrades in the same way - things get dropped, assumptions get invented, and it all looks fine until it doesn't.
Vague scope pollutes the context, and polluted context produces garbage. A small, verifiable block does the opposite: the executor can actually finish it, you can actually check it, and then you both move on. So this isn't "break things into modules because tidy code is nice." It's context management. You are deciding, deliberately, how much unscoped surface any one executor - human or machine - has to hold at once, and you are keeping that number small on purpose.
What it looks like in code
You don't hand an agent "build a chat app." That's the giant-prompt failure, dressed up as a task. You hand it a pile of small, clearly-scoped blocks:
@chat-app/media-upload@chat-app/media-download@chat-app/image-compression@chat-app/video-compression@chat-app/thumbnail-generator@chat-app/online-status@chat-app/last-seen@chat-app/typing-indicator
Every one of those is a small, well-defined scope. A person or an agent can build it in isolation, and you can verify it in isolation. And notice what happens to your job when the system is drawn this way: the planning problem gets dramatically easier, because you're no longer planning "a chat app," you're planning the seams between a dozen things you already understand.
The payoff compounds
Once the system is built out of small, well-scoped blocks, the benefits stack up on their own.
When there's a bug, you can find where it lives and see how it ripples through the system, because the boundaries that contained the work also contain the blast radius. Automated merges get easier to trust, because a change inside a bounded block is a change you can reason about. And each block can be reused, swapped, or upgraded without touching the rest - the thing every architecture promises and only a genuinely decomposed one delivers.
The close
The old-school discipline that always felt like overhead - the interfaces, the contracts, the tight scopes, the part of the job that felt like bureaucracy getting in the way of shipping - was the thing that made the work delegable all along. We just didn't have anyone fast enough to delegate to, so the overhead looked like a tax instead of an investment.
Now we do. And the blueprint does the same thing it always did: it pushes the intelligence up front, into the plan, so the execution layer can stay simple - whether the executor is you at 2am, a junior on your team, or an agent working through the blocks while you sleep.
The magic was never in the laborer. It was always in the architect.