Last week I was about to start a new feature. Muscle memory kicked in. I grabbed a whiteboard marker, uncapped it, and started drawing boxes. Service A talks to Service B. Data flows left. Cache sits here.
Thirty minutes in, I looked at my diagram. Then I looked at my terminal. Then back at the diagram.
I could have built three versions of this in the time I spent drawing one.
I put the marker down. Opened three terminal windows. Gave each agent a different approach to the same problem. Fifteen minutes later I had three working implementations. Not drawings. Not plans. Running code.
One of them had a concurrency bug I never would have caught on the whiteboard. One of them was elegant in a way I never would have designed on purpose. I picked the elegant one, trashed the other two, and moved on with my day.
The whiteboard is still there. Half-drawn. I haven’t erased it yet. It feels like a memorial.
When Building Was Expensive
This would have been insane five years ago. Twenty prototypes? For one feature? That’s not engineering. That’s chaos.
But the reason we think before we build is because building used to be expensive. Writing a prototype took days. Writing twenty of them was a luxury reserved for NASA and defense contractors with unlimited budgets.
For the rest of us, thinking was cheap and building was costly. A day of whiteboarding could save a week of wrong implementation. The entire culture of software architecture exists because of this math. Design reviews. Architecture decision records. RFC documents. Those meetings where six people stare at a diagram and argue about whether the arrow should point left or right.
All of it exists because building the wrong thing was so expensive that we needed to be really, really sure before we started.
That math made sense. For decades, it was correct.
The Cost Flip
It’s not correct anymore.
An AI agent can scaffold a working implementation in minutes. Not a sketch. Not pseudocode. Working code. The cost of building just fell through the floor.
When building was expensive, thinking first was smart. When building is nearly free, thinking first is waste. You’re spending your most expensive resource (time making decisions in the abstract) to save your cheapest resource (an agent’s time writing code).
Here’s the part nobody says out loud: decisions are better when you have real options in front of you. You pick a better couch in a furniture store than from a catalog. You write a better API after you’ve seen three different approaches running side by side. Abstract plans are guesses. Running code is data.
“I’ve never made a great architectural decision on a whiteboard. I’ve made some beautiful diagrams, though.” – Hans Scharler
Yes, I’m quoting myself on my own blog. It’s fine. I’m a thought leader now.
Twenty Prototypes
What does this look like in practice?
You have a decision to make. SQL or NoSQL. Event-driven or request-response. Monolith or microservice. The old way was to debate it. Write a design doc. Schedule a meeting. Get six opinions. Pick one and hope.
The new way: build all of them.
I’m not being metaphorical. You describe the problem to three different agents with three different constraints. “Build this with Postgres and a REST API.” “Build this with DynamoDB and event streams.” “Build this with SQLite and keep it dead simple.” Twenty minutes later you have three working prototypes. Real enough to test. Real enough to break. Real enough to learn from.
You throw edge cases at them. You read the code. You find the one where the tradeoffs actually work for your situation. Not the theoretical situation you imagined on a whiteboard. Your actual situation.
The losing prototypes cost you twenty minutes. The winning one has a head start on production.
Steve Yegge calls this “slot machine programming.” Pull the handle, get an implementation. Pull again, get a different one. I think that undersells it. Slot machines are random. This is deliberate. You’re choosing what to build and comparing the results with engineering judgment. It’s more like a taste test than a gamble.
What Design Becomes
I want to be clear. This is not the death of software architecture.
Design didn’t die. It moved.
You’re still the one making architectural decisions. You’re still evaluating tradeoffs, thinking about maintainability, asking what happens at scale. The difference is you’re doing it with twenty working examples in front of you instead of a whiteboard drawing.
That’s not less rigorous. It’s more rigorous. You’re choosing between things that exist instead of things you hope will work.
Toyota figured this out decades ago in manufacturing. They called it “set-based concurrent engineering.” Build multiple alternatives in parallel. Converge late, after you have real data. The car industry learned this lesson. Software is catching up now because we finally have tools cheap enough to make it practical.
The whiteboard isn’t gone. But it’s a sketchpad now. You doodle on it while your agents build the real thing.
Your Homework
Next time you sit down to start a new feature, or solve a hard problem, or make an architectural decision: skip the design doc.
Build two versions instead. Three if you’re feeling wild.
Different approaches. Different structures. Different tradeoffs. Run them. Compare them. Pick the one that actually works best, not the one that sounded best in a meeting.