A single model asked to design a system will produce something coherent and confident, and confidence is not the property we need most from an architectural proposal.
Why a second pass beats a better prompt
We tried improving the first model's output by refining the prompt — more context, clearer constraints, explicit trade-off framing. It helped, marginally. What helped more was a completely separate step: taking the finished proposal and asking a fresh session, with no memory of how the proposal was produced, to find its weakest assumption.
What the critique pass actually looks for
- The assumption that was never stated — most proposals quietly assume something about scale, consistency requirements, or team size that was never in the brief and may not hold.
- The part that was copied from a different kind of system — models trained on a huge amount of architecture writing default towards patterns that are popular rather than appropriate, and a fresh critique pass is more likely to notice a pattern applied out of context than the model that proposed it.
- The operational cost nobody priced — a proposal that reads cleanly on a whiteboard and requires a team twice the client's actual size to operate.
Why this has to be a genuinely separate pass
Asking the same session to critique its own proposal produces a much weaker critique, because the model has a kind of continuity bias towards defending what it already committed to. A fresh session with only the finished proposal as input, no visibility into how it was produced, argues with it far more honestly.
The value of a second opinion comes from it not knowing how the first opinion was arrived at.
Where a human still has to adjudicate
Neither pass knows the client's actual constraints — the engineer they are about to hire, the budget for infrastructure, the regulatory requirement that was mentioned once in a meeting and never written down. The critique pass narrows the space of reasonable proposals; a person who has sat in the discovery conversations makes the final call.
What changed in practice
On projects where we now run this two-pass approach as standard, the architecture documents we take into a build kick-off name their trade-offs explicitly far more often than they used to, because the critique pass forces the trade-off to be written down rather than left implicit in a diagram.