I have sat in roughly four hundred architecture review meetings. I have run a fair number of them. I have seen reviews that produced beautiful systems and reviews that produced expensive mistakes. The single biggest predictor of which kind a review will produce is not the talent in the room. It is whether the conversation is grounded in evidence or grounded in opinion.
The default review is grounded in opinion. The senior engineer who has been around longest gets the deciding vote. The architect with the strongest narrative arc carries the room. The newest engineer with the best idea — and increasingly, the right idea — gets talked over because they cannot point to anything beyond a diagram. This is not a culture problem. It is a tooling problem. When you have nothing concrete to argue from, all you can argue from is authority.
An architecture review without simulation data is a debate. An architecture review with simulation data is a decision.
The five ways architecture reviews fail
Across the reviews I have observed, the failure modes cluster into a depressingly stable set:
Loudest voice wins
The most assertive engineer carries the day, regardless of whether the assertion is right. Junior engineers learn to stay quiet. Compound this over years and you have a team that does not surface real disagreement.
The senior-engineer veto
Someone with ten years on the team blocks a change because "we tried that in 2019 and it didn't work." The 2019 context is no longer relevant. The veto holds anyway because no one in the room has a way to disprove it cheaply.
The whiteboard fallacy
A diagram with five boxes and four arrows convinces everyone the design is sound. Two months later in production, the implementation surfaces problems that the diagram was incapable of expressing.
Cost is left to FinOps
Engineering decides what to build; FinOps gets the bill three months later. By then the architecture is in production and "we'll optimise next quarter" becomes the standing excuse.
The decision is undocumented
Someone writes a brief decision-log entry that says "we picked X because Y." Six months later, when X is causing pain, no one remembers what Y was or whether it still applies.
The meeting that should not exist
A review that has no decision to make, because the decision was already made before the meeting. The meeting is theatre. Everyone leaves more cynical.
What changes when you bring simulation into the room
Once the review has access to live, replayable simulation data of the proposed architecture, the dynamics shift. Concretely:
- Disagreements become testable. Two engineers disagree about whether Lambda will saturate at the expected traffic. Instead of arguing, someone opens the canvas, sets the traffic shape, and runs the simulation. The answer takes 90 seconds. The disagreement resolves.
- Cost is part of the design. A live monthly cost figure sits next to the architecture on screen. "What does this cost?" is no longer a question deferred to a future spreadsheet. It is an answer that updates as the design changes.
- Junior engineers gain leverage. A graduate engineer can validate their idea by running the simulation themselves. The senior engineer's veto needs to be backed by something other than tenure.
- The decision is documented in the artefact. The reviewed canvas, with the simulation results, is the documentation. There is no separate "decision doc" that drifts from reality.
None of this removes the need for human judgment. The simulation does not tell you whether to optimise for cost, latency, or operational simplicity — that is still a leadership call. But it removes most of the bad-faith arguments and a lot of the honest disagreements that simply could not be resolved without data.
A practical playbook for moving the review
Adopting simulation in architecture reviews is a process change, not a tool change. The teams I have seen do this successfully share four habits:
1. The canvas is the artefact, not the deck
If you are reviewing an architecture and someone has prepared slides, ask for the canvas. The slides are a static abstraction of the canvas. Reviewing the slides means reviewing the abstraction. Review the artefact that will produce the deployment.
2. No review without a simulation run
The author of the proposal arrives with at least one simulation run already in the canvas's execution history. The traffic shape should be at or above expected peak. If the run is not there, the review is postponed. This is non-negotiable and the single highest-leverage change.
3. Disagreements get queued, not adjudicated
When two engineers disagree, they queue a simulation variant. "Let's see what the cost looks like if we replace the Aurora cluster with RDS." Run the variant. Continue the meeting. By the time the review ends, every meaningful what-if has been answered.
4. The decision is captured as a version snapshot
The reviewed canvas gets saved as a named version: "v1 — approved by review on 2026-05-21." When the architecture is later deployed and the bill arrives, this snapshot is what you compare against. Drift becomes visible. Reasons become recoverable.
The economics of the change
The objection I hear most often is that simulation is "too much process" — that it will slow reviews down. The data does not support this. We track three numbers across the teams that have adopted simulation-led review:
Reviews get shorter because most of the debate is structurally avoidable when the answer is available. Post-deployment surprises drop because the surprises were caught at design time. And — counter-intuitively — teams explore more variants, not fewer, because the cost of evaluating a variant has dropped from "a week of prototyping" to "ninety seconds on the canvas."
The cases simulation does not fix
I want to be honest about what this change does not solve. Simulation does not fix:
- Reviews where the team's incentives are misaligned. If you are reviewing an architecture proposed by someone whose bonus depends on shipping fast regardless of quality, the simulation data does not change the politics.
- Strategic decisions that are not technical. "Should we standardise on AWS or stay multi-cloud?" has a technical component, but the answer is mostly organisational and commercial.
- Reviews dominated by an executive who is unfamiliar with the technical detail. Simulation gives engineers leverage. It does not redistribute organisational power.
These are real limits. The intervention I am describing is not a panacea. It is, in my experience, the single highest-leverage change you can make to engineering process if your team has any meaningful production AWS, GCP, or Azure surface.
How design → simulate → deploy → manage reshapes the review
The four-step Pinpole workflow maps directly onto the architecture review as a process:
Design (before the review)
The proposal author builds the canvas. Connection compatibility is validated as they go. The canvas is shared with the review group 48 hours before the meeting. Reviewers explore the canvas asynchronously.
Simulate (during the review)
The author shows the baseline simulation. Disagreements get queued as simulation variants. Each variant runs in ninety seconds. The decision falls out of the diff.
Deploy (after the review)
The approved canvas exports validated Terraform or CDK. The version is named and locked. The deployment that goes to staging is the one that was approved in the room.
Manage (after deployment)
Quarterly, the team replays the simulation against the live architecture. Drift surfaces. The next review starts from the latest snapshot. Decisions accumulate as artefacts, not anecdotes.
The thing I did not expect, the first time we ran a simulation-led review, was how much quieter the meeting got. Not because people had less to say — because the things they had to say no longer needed the volume of authority behind them. The data did the load-bearing work. The conversation became collaborative again.
How to start, this week
- Pick the next architecture review on the calendar. Ask the author to put the proposal on a canvas. Tell them they have until the meeting to attach one simulation run.
- Open the meeting with the simulation. Do not let it slip into the second half. The visible cost figure changes the conversation immediately.
- When someone disagrees, queue a variant. Resist the urge to litigate the disagreement in conversation.
- End the meeting with a named version snapshot. "Approved as v1 by [reviewers] on [date]." This is your decision log.
You can run this pilot in a single review cycle. The first time you watch a simulation resolve a disagreement that would have taken thirty minutes of senior-engineer debate, you will not go back.
The most expensive architecture decisions are the ones made on opinion.
Move your next review to the canvas. The first run will tell you whether the proposal survives the traffic you expect.
Start 14-day free trial →