A diagram can look complete while leaving the difficult questions unanswered. What happens when the database fails? Where does authentication happen? Which assumption makes the cost estimate plausible?
I built architecture review in Codelit to help start those conversations. Its findings are review candidates, not verified defects.
Review the relationships
A component rarely tells the whole story. A queue changes how a request fails. A replica changes the recovery path. A public boundary changes which connections deserve scrutiny.
The useful review asks about the relationships and the missing context:
| Area | Useful question | Evidence the diagram cannot supply |
|---|---|---|
| Security | Where is identity checked and access constrained? | Deployed configuration and enforcement |
| Reliability | What happens when this dependency stops? | Recovery tests and actual failover behavior |
| Capacity | Which resource is likely to saturate first? | Workload measurements and load tests |
| Cost | Which configuration assumptions drive the bill? | Current rates and real usage |
| Data governance | Where does sensitive data flow and persist? | A qualified compliance assessment |
A missing encryption label does not prove unencrypted traffic. A single database box does not prove a single instance. The first step is to distinguish omitted notation from an actual design gap.
Make a finding actionable
A finding should identify the relevant component, explain the possible consequence, name its assumptions, and suggest how to verify it.
“Add a cache” is not enough. A useful review asks whether repeated reads are a measured bottleneck, which data can become stale, and how invalidation would work. Similarly, a CDN and an application cache are not automatically redundant just because both cache data.
That is the same discipline I use in AI-generated code review: a plausible concern becomes a finding when the evidence supports it.
Keep the boundary visible
The model sees the supplied architecture and metadata. It does not see traffic that was never measured, infrastructure that was never included, or policies that were never provided.
I do not present review hit rates without a reproducible evaluation set. Nor can an AI diagram review certify security, regulatory compliance, or an uptime target.
Use the review to prepare a better discussion. Then verify the important questions against the real system.
What to do with the result
Challenge the assumptions, accept or reject findings deliberately, and make the resulting decision visible in the architecture. Use diagram failure exercises and cost estimation as additional ways to ask better questions.
The outcome I want is not a longer warning list. It is a clearer decision about what must be checked before the team commits to the design.