Review an AI proposed architecture against actual requirements

An AI architecture proposal can be coherent, detailed, and poorly suited to the problem. A simple appointment application becomes a collection of gateways, event buses, separate services, and independent databases. Each component has a plausible explanation, but the proposal never establishes which user requirement needs it. Reviewing the diagram for internal consistency is not enough. The reviewer must compare the proposed system with actual requirements and the team's ability to operate it.

Use an illustrative appointment scheduling product maintained by one small team. The requirements include preventing double booking, sending reminders, and letting users reschedule. There is no supplied evidence of extreme traffic or independent release teams. Those unknowns must remain unknown rather than becoming assumptions that justify a larger architecture.

Extract claims before judging components

Read the proposal and list the claims that drive its structure. Common examples include independent scaling, high availability, regulatory isolation, and future team autonomy. For each claim, identify the requirement, measurement, or documented constraint supporting it. If none exists, mark it as an assumption.

Separate a desirable property from a required one. Independent deployments may sound useful while the actual team releases all features together. A queue may be necessary for reminders, but that does not imply asynchronous messaging for every read. Ask the assistant to restate the minimum user outcomes without technology names. This step often reveals that several components solve hypothetical problems while the real invariant, such as double-booking prevention, remains underspecified.

Follow one consequential operation

Trace booking creation from the browser through permission checks, availability validation, persistence, confirmation, and reminders. Ask where the no-double-booking invariant is enforced under concurrency. If two services separately check availability and then create bookings, the proposal needs a concrete atomic mechanism, not a statement that eventual consistency handles it.

Identify partial outcomes. A booking can be stored while reminder scheduling fails. The UI must distinguish durable booking success from future notification delivery. A client timeout can leave an uncertain result. These states exist regardless of the number of boxes. Use a sequence with failure points to review the architecture before spending time on cloud service configuration. See drawing a system boundary from a journey for the mapping method.

Charge every component its real cost

For each service, write its owner, deployment procedure, credentials, data, observability, compatibility contract, and recovery responsibility. For each queue, define duplicate processing, retries, retention, and exhausted-message handling. For each database, define migration, backup, restore, and consistency requirements. A component without an owner is an operational risk even when its technical purpose is reasonable.

Compare the total with a simpler baseline. A modular application with a reminder worker may meet the scheduling requirements. The comparison should include debugging and incident response, not only source code organization. Distributed tracing and deployment automation are valuable capabilities, but they are also work the team must support. An AI-generated architecture should not treat those prerequisites as free or already implemented unless the repository and operating process demonstrate them.

Validate proposed technologies and APIs

Check the installed versions, documented capabilities, and deployment environment. An assistant may combine features from different releases or invent a library operation. Verify specific claims against primary documentation rather than accepting a confident explanation. Avoid importing a new dependency simply because generated code references it.

Use a small proof of concept for a disputed boundary. For scheduling, exercise concurrent booking attempts against the actual storage mechanism with synthetic data. For reminder delivery, test durable acceptance and a worker interruption. Clearly state what the experiment proves and what it does not. A local container starting successfully does not prove regional recovery or provider availability. Keep undocumented provider claims out of the final decision until they have been checked.

Compare alternatives through counterexamples

Ask how the design behaves when a dependency is unavailable, a message arrives twice, an old client calls a new service, or a user changes permissions between request and execution. Then apply the same counterexamples to the simpler alternative. This prevents the review from focusing only on the proposal's happy path.

A useful artifact has one row per requirement: proposed mechanism, simpler mechanism, failure case, and verification evidence. For double-booking prevention, the important comparison is the atomic storage invariant, not whether the application has a booking service. For reminder latency, a bounded background worker may be sufficient. For genuinely independent organizational ownership, a service boundary may win. The architecture should emerge from these differences instead of from a predefined list of fashionable components.

Reduce the proposal to a reviewable increment

Do not accept or reject the entire diagram as one indivisible choice. Identify the smallest increment that resolves the present problem. Introduce the booking invariant and clear module ownership first. Add a reminder worker if synchronous delivery affects the request. Defer service extraction until a concrete release, capacity, or isolation requirement appears.

Define the contracts that keep later options open, but avoid speculative abstraction everywhere. A stable module operation is often enough before a remote API is justified. Record the choice and its accepted limitations in an architecture decision. Include the evidence that would change the answer. This makes simplification deliberate rather than an unexplained preference for fewer components.

Verify the revised design honestly

Review the repository and deployment process against the reduced proposal. Mark each component as implemented, proposed, or absent. Run checks for the critical journey and its failure states in an appropriate isolated environment. Record failures and skipped checks with reasons instead of giving the architecture a blanket approval.

Be especially careful with nonfunctional promises. Availability, recovery time, security, and capacity require evidence specific to the deployment and operating process. A design can aim for those properties without having established them. Keep an evidence list that distinguishes tests, documentation analysis, and unresolved decisions. This prevents polished AI text from becoming the basis for customer commitments that engineering has not verified.

Make AI review adversarial and bounded

Ask a second pass of the assistant to challenge its own assumptions: which components can be removed, which invariants are not enforced, and which facts were inferred without evidence? Supply the actual requirements and forbid invented traffic, compliance obligations, or team structure. Require direct references to repository files where it describes existing behavior.

Use the model to generate alternatives and counterexamples, then make the decision yourself with the team. If its proposal changes repeatedly with prompt wording, treat that as a reason to ground the discussion more firmly, not as a vote between answers. Architecture review succeeds when it produces a smaller, explicit, verifiable plan with known costs. Fluent explanations are useful only when they help the team inspect those concrete decisions.

Sources

Martin Fowler's Monolith First provides context for uncertain early boundaries.

The original architecture decision record article supports recording the chosen tradeoff. The scheduling requirements and review matrix are illustrative.