PromptAtWork
Prompt / Coding / Advanced

AI-Assisted Systems Engineering: Architecture, Edge-Case and Artifact Review

How I use Claude as an engineering partner across these systems: to stress-test an architecture, generate edge cases and tests, and verify generated artifacts against their source. This template is the review step; it is used alongside, not instead of, my own design and code review.

Prompt

You are a senior reviewer. Review the design or artifact below. Be specific and critical; do not praise.

Context: {system_context}
Constraints: {constraints}

Return these sections:
1. FAILURE MODES: what breaks under load, concurrency, partial failure, retries, duplicate events and malicious input. For each: trigger, impact, and the cheapest fix.
2. EDGE CASES: concrete inputs or sequences to test, written as test names (e.g. test_two_simultaneous_bookings_for_one_slot_only_one_wins).
3. SECURITY BOUNDARIES: where data or permissions cross a trust boundary and what must be checked there.
4. CLAIM CHECK: list every factual claim or number in the artifact and mark it SUPPORTED (quote where in the source) or UNSUPPORTED.
5. QUESTIONS: what you would need to know to be more certain.

Do not invent facts about the system. If something isn't stated, ask.

Design or artifact:
{artifact}

Source material (for the claim check):
{source}
PROCESS FLOW

Three review checkpoints

  1. 1. AI

    Architecture review

    Before building

  2. 2. AI

    Edge cases and tests

    Before merging

  3. 3. AI

    Claim check vs source

    Before publishing

  4. 4. Human

    Engineer decides

The same review prompt runs before building, before merging and before publishing, each time in a fresh context, and a person decides what to act on.

Variables

{{system_context}}{{constraints}}{{artifact}}{{source}}

Example Input

artifact: a draft case study and its architecture notes; source: the author's raw project notes

Example Output

Failure modes with fixes, a list of test names, trust-boundary checks, every claim marked supported or unsupported, and open questions.

Expected Behavior

Concrete, testable findings; unsupported claims called out rather than accepted; questions instead of assumptions.

Failure Modes

  • −Reviews drift into generic advice; asking for test names and the cheapest fix keeps them concrete.
  • −The model may accept its own earlier output; run the review in a fresh context, not the one that wrote the artifact.

Tips

Use it at three points: before building (architecture), before merging (edge cases and tests), and before publishing (claim check against the source).