Stop Debating Architecture: Start Prototyping It

Every architect has lived this meeting. Six people around a whiteboard, three competing proposals, ninety minutes of “well, what about this edge case” and “I’ve seen that pattern fail before.” Everyone’s drawing boxes and arrows. Nobody’s wrong, exactly. Nobody’s provably right either. You leave with a decision that’s really just consensus fatigue. Whoever argued longest or had the most seniority wins.

That meeting has been the default mode of architecture work for decades. And it made sense, because the cost of being wrong was high. If you picked the wrong approach, you burned weeks or months before you found out. So you front-loaded the thinking. You debated. You drew diagrams. You wrote decision documents that nobody read after the first week. All of it trying to derisk a choice you couldn’t actually validate without building the thing.

That cost structure has changed.

The cost of trying just dropped to near zero

When I say AI compresses the feedback loop, this is the most concrete place it shows up. The thing that used to take a spike team three days (standing up a rough version of an approach to see if it holds) can now happen before the meeting starts.

I don’t mean “ask ChatGPT which architecture is best.” That’s the wrong instinct, and it’s where a lot of teams go first. The AI doesn’t know your org. It doesn’t know your team’s capabilities, your existing systems, your operational constraints, the political realities of who owns what. It can’t pick for you.

But it can help you build each option, quickly, so you have something real to evaluate instead of something theoretical to argue about.

Here’s what that looks like in practice: instead of walking into a meeting and saying “I’m thinking option A, maybe option B, possibly C, let’s discuss,” you walk in with rough prototypes of all three. You’ve documented the trade-offs of each. (If you’re using AI coding tools as a strategic advantage, this is where they pay for themselves many times over.) You have something tangible that people can poke at, ask questions of, stress-test against real scenarios. The conversation shifts from “I think this would work” to “here’s how this actually behaves when you do X.”

That’s a fundamentally different meeting. You’re making evidence-driven decisions instead of opinion-driven ones.

I tested this recently on a client engagement. A core business system, mathematically deterministic, needed to migrate from a distributed monolith to a service-oriented architecture. High stakes. The kind of system where outputs either match exactly or they’re wrong. The client was understandably nervous about a migration of this complexity.

Rather than walking in with proposed architectures and diagrams, I spent a week with AI assistance introspecting the combined repos — the kind of deep legacy discovery I write about in The 95% Map — understanding the system deeply enough to replicate its logic, and building a functional end-to-end prototype deployed on AWS. When I walked into the architecture conversation, the question wasn’t “do you think this approach would work?” It was “here are the results validated against tens of thousands of production records. Does this match what you expected?” Evidence replaced opinion. Client nervousness met something it could actually evaluate rather than something it had to take on faith.

This isn’t new, but the economics are

We’ve always known that building the thing teaches you more than talking about the thing. That’s why spikes exist. The problem was always cost. A spike meant pulling one or two people off their current work for days. It meant justifying that investment to a PM or a delivery lead. It meant being very focused about which specific question the spike was answering, because you couldn’t afford to explore broadly.

Now the exploration itself is nearly free. The cost isn’t developer-days anymore. It’s a few hours of someone who knows the right questions to ask, working with AI to stand up rough versions of each approach. You’re not building production code. You’re building something you can introspect on, something that makes the real trade-offs visible.

And this scales down further than most people realize. It’s not just “should we use microservices or a modular monolith.” It works all the way down to individual components. How should this data model be structured? What validation approach makes sense here? Should this be an event-driven flow or request-response? At every level where you’d normally debate the options, you can now prototype them instead.

Even the failures are valuable

Here’s the part most people skip: even if you prototype three options and throw all three away, you still won. You learned something from each one. You discovered constraints you didn’t know existed. You found the edge case that would have bitten you three weeks into implementation.

And unlike a whiteboard debate where the reasoning lives in people’s heads and evaporates after the meeting, a prototype leaves artifacts. You can document the approaches, their trade-offs, why each was or wasn’t selected. That decision record is genuinely useful. Not in the “we wrote an ADR for compliance” sense, but in the “six months from now when someone asks why we did it this way” sense.

The traditional approach to architecture decisions treats being wrong as expensive, so it optimizes for avoiding mistakes. The new approach treats being wrong as cheap, so it optimizes for learning fast. That’s not a subtle distinction. It changes how teams operate — and it changes how developers grow, because cheap failure is the best teacher we’ve ever had.

The expert still matters, but differently

None of this works without someone who knows what questions to ask. AI is excellent at generating options, proposing patterns, even surfacing things you haven’t considered. It’s very good at research. It’s very bad at judgment.

The person driving this process needs to know enough about the problem space to evaluate what comes back. They need to know which trade-offs matter for this org, this team, this system. They need to recognize when a prototype is papering over a real problem with a clever-looking solution that will fall apart under load or at scale or when requirements shift.

This is actually a higher bar, not a lower one. When you were debating at a whiteboard, you could get by on pattern recognition and past experience. Now you’re evaluating working code, and the failure modes are more subtle. A prototype can look right and be fundamentally wrong in ways that only someone with real depth will catch.

So the expert’s role shifts from “person who proposes the architecture” to “person who evaluates architectures and asks the right follow-up questions.” That’s a more valuable use of their time, and frankly, it’s a more interesting job. It’s the same tension I explored in The Artisan’s Dilemma — balancing the craft of architecture with the pragmatism of shipping.

The calibration question

Not everything needs this treatment. A core system component that five other services depend on? Yes, prototype the options, evaluate rigorously, document the decision. A single CRUD endpoint with straightforward validation? Just describe what it needs to do and build it.

The question is always: how much do you need to know before you start, and how deep does the specification need to go? That’s a judgment call, and it’s the same judgment call architects have always made. What’s different is the default. The old default was “we can’t afford to prototype, so we’ll specify and debate.” The new default can be “prototyping is cheap, so let’s try it and see.”

That doesn’t mean specification is dead. Spec-driven development, contract-first design, interface documentation: all of that still matters, especially at integration boundaries. But the specification can be informed by prototyping instead of being a substitute for it.

What this means for how teams work

If you’re leading an engineering team, the practical implication is this: architecture reviews should increasingly involve working artifacts, not just diagrams. When someone proposes an approach, the question isn’t “did you think about X” but “did you try X? What happened?”

When someone brings a prototype to a review meeting and it survives scrutiny, you’ve just compressed what used to be weeks of design-then-build-then-discover-the-problem into days or hours. When a prototype doesn’t survive scrutiny, when the team pokes holes in it in real time, that’s even more valuable, because you killed a bad idea before anyone invested real effort in it.

The teams that will move fastest aren’t the ones using AI the hardest. They’re the ones who’ve restructured their decision-making process around the fact that trying things is no longer expensive.

Stop debating architecture. Start prototyping it. The meeting will be shorter and the decision will be better.

---

This is the first article in the “Rewiring the Feedback Loop” series on how AI compresses feedback loops across software delivery: from discovery through architecture, build, validation, and talent development.