How to Settle Architecture Debates: Build, Don’t Meet

Two of your developers are arguing about an architecture decision, it’s week three, and you have no idea who’s right. I can take some pressure off: they don’t know either. Everyone in that room has an opinion, and nobody has evidence.

I’ve sat through a lot of these debates in twenty years. I’ve watched senior engineers argue hard for designs that fell over in their first week of live traffic, and I’ve watched choices everyone hated run reliably for years. The conference room can’t tell you which one you’re looking at. Production is the truth.

On a recent AI product build, I had to pick how to orchestrate the pipeline that turns a user’s quiz answers into a personalized lesson. Microsoft’s Agent Framework was the serious option, and on paper it fit perfectly. Instead of debating it, I spent two days building a thin prototype of the real flow and put a stopwatch on it. The framework wanted each stage of the work fully finished before anything moved forward, which meant the first words of the AI’s response hit the screen noticeably late. A user would be staring at a spinner wondering if the thing broke. None of that showed up in the documentation.

I dropped it, kept the simpler design, and wrote a one-page note on why so we can revisit when the framework matures. The whole decision cost two days. The meeting version takes weeks and picks whatever the most confident person in the room wanted anyway.

You don’t need to referee the technical arguments. Ask your team one question: what’s the smallest thing we can build to find out? Good teams light up at that. If the answer is another meeting, pay attention to that.

What’s the longest debate your team has had that a week of building could have settled?