A staff engineer pastes a five-page architecture doc into an AI assistant and types, "review this architecture." The model returns a cheerful summary, notes the design "looks solid overall," lists four generic concerns — scaling, observability, security, cost — and signs off with "consider monitoring from day one." Nothing surfaces the actual weak spot, a subtle coupling between two services that nobody on the team had articulated out loud.
The problem is not that AI cannot review architecture. It can. The problem is that "review this architecture" is not a prompt. It is an invitation to produce architecture-review-shaped text, and the most common shape is affirmation with a sprinkle of boilerplate. Useful critique requires the same ingredients a human review requires: a clear role, concrete context, and specific criteria.
Three patterns shift AI architecture review from affirmation theatre to real critique. Targeted critique applies named concerns to a named design. Alternative generation produces two or three competing approaches with explicit trade-offs. Stress-testing interrogates a single decision — "why this database," "why this sync/async boundary" — until the justification either holds or cracks.
This post sits in the engineering track of our prompt engineering for business teams guide and pairs with AI technical spec prompts, AI incident postmortem prompts, and spec-driven AI coding.
Why "Review This Architecture" Prompts Fail
Three failure modes conspire. First, a model with no specified concerns defaults to the average of architecture reviews in training — broad, polite, non-committal. It covers scaling, observability, and security because those words sit near "architecture review" everywhere; it does not probe a specific coupling unless you make it care. Second, default completions lean toward agreement — agreement-shaped text is more common in polite professional writing. Paste a design and the most probable continuation is "yes, with some minor considerations." That is sentiment rendered in paragraphs, not a review. Third, architecture docs contain structure — components, edges, data flows — that prose descriptions leave implicit, asking the model to guess at half the system.
Fix all three and the output changes shape. Specify the role ("senior infrastructure engineer reviewing before a production launch"). Specify the criteria ("evaluate against failure modes, data consistency, operational cost"). Specify the output ("list each concern with the specific component it applies to"). The model stops averaging and starts critiquing.
Pattern 1: Targeted Critique
Targeted critique is the workhorse. You give the model a design, a role, and a fixed list of concerns. The model evaluates the design against each concern, naming the specific component where the concern lands and saying whether the design handles it, partially handles it, or leaves it unaddressed. The output is structured so nothing drifts into affirmation.
Concerns vary by system; a good default list covers what a senior reviewer would hit in a live meeting:
| Concern | What the review is checking |
|---|---|
| Failure modes | What happens when each component or dependency fails — does the system degrade, retry, or cascade? |
| Data consistency | Where the consistency boundaries sit, and whether the chosen guarantees (strong, eventual, read-your-writes) match the read/write patterns |
| Scaling limits | Which components have known throughput ceilings, and what the first bottleneck is under projected load |
| Operational cost | Which components dominate cost, and whether the cost scales linearly, sublinearly, or superlinearly with usage |
| Security surface | Which boundaries accept untrusted input, and what the blast radius is if one component is compromised |
| Coupling | Which components must be deployed together, share schemas, or break when either side changes |
| Observability | Whether each failure mode is detectable from logs, metrics, or traces — and how long detection takes |
The prompt names concerns explicitly and forbids generic additions. That constraint is load-bearing: without it, the model adds "consider monitoring" to every review by default.
ROLE:
You are a senior infrastructure engineer reviewing a proposed
architecture before a production launch. You critique against
specific named concerns. You do not add generic advice. You do
not affirm the design before critiquing it.
CONTEXT:
Proposed architecture (components, edges, data flows):
[paste structured description — see "Feeding Diagrams" below]
Expected load and growth assumptions:
[paste]
Hard constraints (latency, compliance, budget):
[paste]
TASK:
Evaluate the design against these concerns, in order:
1. Failure modes — what happens when each component or external
dependency fails.
2. Data consistency — where the consistency boundaries sit and
whether the guarantees match the usage patterns.
3. Scaling — which component is the first bottleneck under
projected load, and at what load level.
4. Operational cost — which component dominates cost and how
cost scales with usage.
5. Security surface — which boundaries accept untrusted input.
6. Coupling — which components must be deployed together or
share schemas.
7. Observability — whether each failure mode in (1) is detectable
from logs, metrics, or traces.
For each concern, produce:
- The specific component or interaction the concern lands on.
- A status: ADDRESSED, PARTIAL, or UNADDRESSED.
- A one-sentence justification citing the part of the design
that addresses it (for ADDRESSED/PARTIAL) or the missing piece
(for UNADDRESSED).
FORMAT:
Markdown table: concern, component, status, justification.
ACCEPTANCE:
- Every row names a specific component from the design — no
"the system" or "the architecture" as the subject.
- No generic advice not tied to a named concern.
- No affirmation preamble — the output starts with the table.
- If the design does not describe a component needed to evaluate
a concern, mark status UNADDRESSED and name the missing
description.The status column has three values because "partial" is where the interesting conversation lives. "Addressed" and "unaddressed" are easy to act on; "partial" forces the reader to decide whether the gap matters.
Pattern 2: Alternative Generation
Targeted critique tells you what is wrong with one design. It does not tell you what else you could have done. Alternative generation asks the model to produce two or three competing approaches, each with explicit trade-offs, so the team sees the design space instead of debating a single point on it.
The trick is forcing alternatives to be actually different. Ask for "three approaches" with no constraints and the model produces three variations of the design you showed it, with minor parameter changes. Ask for "three approaches that differ along a specific axis" — sync versus async, centralized versus federated, build versus buy — and the alternatives become genuinely distinct. Specify the axis of variation and the trade-offs to surface. Output is a comparison table, not prose, because prose lets the model smooth over differences a table forces it to name.
Trade-offs worth naming: operational complexity, failure blast radius, cost at baseline and at 10x load, p99 latency, consistency guarantees, time to implement, and reversibility — how hard it is to migrate away once committed. Reversibility is the one most often missed in live reviews, because teams get excited about their preferred design and stop asking how to undo it.
Pattern 3: Stress-Testing a Decision
The third pattern narrows focus to a single decision: "why this database," "why this sync-versus-async split," "why this service boundary here and not one layer up." Most reviews are a pile of decisions, each individually defensible but collectively untested. Stress-testing pulls one out and interrogates it until the reasoning either holds or breaks.
The stress-test prompt supplies the decision, the stated reasoning, and a list of attack vectors — assumptions the reasoning depends on, alternative choices, operational realities that could invalidate the choice. The model is instructed to argue against the decision, not for it. That inversion is deliberate: left to defaults, the model argues for whatever is in front of it. The pattern pairs with role prompting — casting the model as a skeptical senior engineer whose job is to find the flaw — so the role anchors output in critique-shaped language.
A hypothetical: a team proposes a relational database for a write-heavy event ingestion service, reasoning "the team knows SQL and we already run Postgres." The stress-test prompt attacks that reasoning — at what write volume does write amplification become the bottleneck; what happens when the write-ahead log saturates disk I/O; does "the team knows SQL" still hold when operational burden shifts from queries to vacuum tuning and partition management. The job is to surface failure cases, not agree Postgres is fine.
Role + Context Framing
Across all three patterns the shared ingredient is a role that constrains output style. "You are a senior infrastructure engineer reviewing a design before a production launch" produces different output than "You are an AI assistant helping review architecture." The first carries implicit norms — skepticism, operational concern, willingness to surface risk — that the second does not.
The role should be specific about seniority, domain, and stance. Seniority sets depth. Domain anchors concerns (a security engineer surfaces different issues than an SRE). Stance picks a register: "reviewing" and "stress-testing" produce different output than "helping with." Context is the other half — every unstated assumption becomes a gap the model ignores or invents around. Paste assumptions explicitly, uncertain values included, and the model will critique the uncertainty instead of assuming a convenient value.
Feeding Diagrams and Pseudocode
Architecture is structural; prose descriptions lose structure. Translate the design into a form the model can reason over directly: a component list (each named, with its responsibility in one sentence), an edge list (each edge named with direction, protocol, and sync/async), and a data-flow description (for each major operation, the sequence of components touched and the consistency requirement at each step). With that structure in place, the model can answer structural questions — "which component is the single point of failure for operation X" — because the structure is explicit in the input.
Pseudocode is useful when the review is about a specific algorithm rather than a whole system. It strips incidental syntax and leaves the decisions — branch conditions, loop structures, state transitions — visible for critique against named invariants.
Common Anti-Patterns
- "Review this architecture" with no role or concerns. Produces affirmation-shaped text. Fix: specify role, concerns, output structure.
- Asking the model to "score" the design. A scalar score from a language model is false precision. Fix: use status per concern (ADDRESSED, PARTIAL, UNADDRESSED).
- Alternative generation with no axis of variation. Produces three copies of the original design. Fix: specify the axis (sync vs. async, centralized vs. federated, build vs. buy).
- Stress-testing with agree-or-disagree framing. Produces agreement. Fix: instruct the model to argue against the decision.
- Design docs with unstated assumptions. Model invents convenient ones. Fix: paste assumptions explicitly.
- Ignoring the output-first rule. Lets the model preamble. Fix: acceptance clause that the output starts with the table, not a summary.
For adjacent engineering prompts, pair this guide with AI technical spec prompts, AI incident postmortem prompts, and spec-driven AI coding.
FAQ
Can AI replace a human architecture review?
No. Human review brings organizational context — which team can operate this, what the roadmap says in six months, which past incident informs current skepticism. AI applies consistent criteria to the design in front of it. The value is breadth and consistency, not judgment. Use both.
How long should the design be before AI review becomes useful?
Long enough to have components and edges, short enough to fit in a single prompt. A one-line sketch produces a one-line review. For a forty-page doc, chunk by subsystem, review separately, reconcile the outputs.
What if the model's disagreement is wrong?
Treat disagreement as a prompt to check the reasoning, not a verdict. A good review surfaces concerns; a human decides which are real. If the model insists on a false concern, inspect the inputs — usually an assumption was missing or a component was described ambiguously. Fix the input before arguing with the output.
Can this catch security issues?
Partially. The security surface concern flags boundaries that accept untrusted input and names obvious blast-radius issues. It does not replace a dedicated threat model or penetration test. Surface the obvious here, then run a real security review on what surfaces.
AI architecture review is not magic and not a rubber stamp. It applies consistent criteria faster than a human can, surfaces decisions a busy team forgot to stress-test, and widens the decision space before commitment. Adapt the concern lists to your domain, tighten roles to your team's seniority, and treat the output as a prompt for the next conversation, not the end of one.