The Other Half of Two-Pizza
written by Stefan Christoph
Prefer YouTube? Watch the walkthrough on YouTube.
I read Werner Vogels’ new post, “A return to two-pizza culture” [1], in one sitting, and kept nodding. He tells the story of a principal scientist who spent a single evening with a coding agent and walked out with the first working prototype of what became Amazon Quick Desktop. By the next morning the project had owners. Within a week it had a team. The idea didn’t wait for permission, and the tool didn’t get in the way.
Four things in that post landed for me, because they describe how I already work.
What Resonated
The first is ownership. “Build it, you own it” has been an Amazon line for as long as I’ve been here, but Werner ties it to something concrete: a small group of people who trust each other, own a problem end to end, and act on their conviction. No handing rough edges to someone else’s sprint.
The second is reversible decisions. As Werner puts it, the cost of a wrong reversible decision is almost always lower than the cost of making that decision slowly [1]. When you can undo it, you don’t ask permission. You decide, you learn, and if you were wrong you reverse it.
The third surprised me, because it’s about writing. Amazon’s Working Backwards process starts with a press release and an FAQ, written before anyone builds [2]. Werner isn’t retiring that. He’s moving it. When a coding agent can produce a working shell of a product in an evening, the most honest document is the one you write after you’ve used the thing. Clare Liguori, who led the development of Kiro, describes the same shift: when a prototype takes days instead of months, it makes more sense to prototype first and write the doc once you have something real to click through [3]. Writing didn’t die. It moved to after the prototype.
The fourth follows from the third: prototype-first inverts the order I learned. The 2006 version of Working Backwards went press release, FAQ, customer experience, user manual, and only then code [2]. The new version starts with conviction about the problem, builds a prototype to probe the solution, and writes the crisp document once the idea has been pressure-tested. Same destination. Reversed route.
The Personal Mirror
Here’s why it resonated so directly. For a while now, my own daily workflow has run on kiro-cli with an Obsidian vault as its backbone [4]. It gives one person the same loop Werner describes: build something, use it for real work, learn what’s wrong, iterate, and own all of it. The vault holds what I know. The session holds what I’m doing right now. The small workflows I refine between sessions hold how I work. I dogfood it every day, and the rule is the same as on the Quick Desktop team: if I notice something is wrong while I’m using it, I fix it, because I own it.
That loop used to need a team. The interesting part of Werner’s story is that the tools have compressed it enough that it can now fit around a single person without losing the ownership that made it work.
The ownership loop: build, use, learn, iterate, own, repeat.
The Other Half
So here’s the part I want to add, because it’s the half that gets less applause.
Getting buy-in for an idea got radically easier. That’s the revolution Werner describes, and it’s real: an evening of building beats two weeks of writing about what you think will happen. The prototype is the argument. People see it, they want it, and they line up to own pieces of it.
Getting that idea all the way to production is still the climb.
A prototype that delights a room of colleagues is a wonderful thing. It is also not the same as a product hundreds of thousands of people rely on every day. Werner is honest about this in the post: the Quick Desktop team grew to several hundred people, because that’s the natural trajectory of something that real usage depends on. Between the overnight demo and the daily-driver product sits everything that makes software trustworthy: it has to scale, it has to stay up, and it has to behave responsibly when real people and real data are involved.
None of that is a knock on the tools, and it is not a reason to be nervous about building this way. It’s the opposite. The agent gave us a running start on the part that used to be slow. The climb to production is shorter than it used to be. It’s just still a climb, and the climb is engineering: load you didn’t have at demo scale, failure modes you only meet under real traffic, and the guardrails that turn “it works on my laptop” into “it’s safe for everyone.” This is the work I spend a lot of my time on with customers, taking promising pilots and getting them production-ready, and putting the responsible-AI guardrails in place that make “production-ready” mean something. It’s good, satisfying, craftsmanlike work. It just doesn’t fit in a single evening.
The Loop Was Always the Same
What I find genuinely optimistic about Werner’s post is the closing idea: two pizzas were always about ownership, and the tools have caught up to the culture [1]. The culture didn’t change. We always wanted small teams that owned problems end to end and moved without asking permission. What changed is that the build-use-learn-iterate loop is now fast enough that one person, or a handful, can run it from the first prototype.
The starting line moved. Getting an idea taken seriously is no longer the bottleneck. That means the craft, the part where the human earns their keep, has moved too. It now lives in finishing: in the taste to know when the experience is right, the discipline to make it scale, and the responsibility to ship it in a way you’d be happy to put your name on.
Werner says prototype before you write. He’s right. That’s the easy half now. The other half, the one that’s still hard and still worth doing well, is where I’d encourage you to point your attention.
Where does the hard work live in your own setup now: at the start, or at the finish?
Sources
- [1] Werner Vogels — A return to two-pizza culture — the trigger and primary source: ownership culture, reversible decisions, and the overnight Quick Desktop prototype built with Kiro.
- [2] Werner Vogels — Working Backwards (2006) — the original four-step process: press release, FAQ, customer experience, user manual, written before building.
- [3] Clare Liguori — Prototypes Before PRFAQs — when a prototype takes days, prototype first and write the doc afterward; the Kiro team used the IDE full-time from the first working prototype.
- [4] kiro.dev — the agentic coding tool behind the kiro-cli I use daily.
About the Author
Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.
This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.