Designing AI review loops

AI makes it easier to produce a first draft. That is not the same as making good work easier.

The important question is what happens after the draft exists. Does anyone pressure-test the states? Does the copy survive real context? Does the component match the system? Does the code preserve behavior? Does the release note explain risk? Does the human still know why the decision is right?

That is where review loops matter. I do not want AI to be only a builder. I want it to be part of a loop: generate, inspect, critique, revise, verify, and ship. The loop should make the work more legible and less fragile.

Used well, AI can help expose weak assumptions. Used badly, it can make weak assumptions sound finished.

DraftMake it visible

Generate a screen, spec, test, article, migration, or PR candidate.

CritiqueFind risk

Ask for missing states, false assumptions, accessibility issues, and system drift.

ProofVerify

Run commands, browser checks, route checks, schema checks, and human review.

Define the loop before using the tool

The workflow should say what AI is allowed to produce, what it must review, and what proof is required before shipping.

I would pressure-test that decision with four questions:

• What is the artifact?
• What is the critique lens?
• Who decides?
• What verification is required?

The failure mode here is asking for output and treating the first plausible version as the final version. In AI-assisted product work that needs critique, verification, and human judgment before it becomes real, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a loop definition with draft, critique, revise, verify, and ship steps. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is a process where speed increases without losing accountability. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a loop definition with draft, critique, revise, verify, and ship steps beside the question “What is the artifact?” before the first implementation review. The next pass would use “What is the critique lens?” to test the boundary, then “Who decides?” to expose the state most likely to be missed. I would keep “What verification is required?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports a process where speed increases without losing accountability.

Use AI as a second reviewer

A second model pass can catch issues the builder missed, especially when the prompt asks for specific risks.

The practical review starts here:

• What states are missing?
• What copy is vague?
• What data assumption is hidden?
• What accessibility path could fail?

Those questions keep asking AI whether the work is good and accepting a generic answer from becoming the default. I would capture the decision in a critique prompt targeted to the artifact and the risk, then use it while the work is still cheap to change. For AI-assisted product workflow, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like a review that surfaces concrete risks early. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a critique prompt targeted to the artifact and the risk part of the working surface. I would use it to answer “What states are missing?” while scope is still flexible, and “What copy is vague?” before code or content becomes expensive to unwind. During QA, “What data assumption is hidden?” and “What accessibility path could fail?” become concrete checks rather than discussion prompts. That sequence turns AI-assisted product workflow into something the team can operate and gives me a specific outcome to report: a review that surfaces concrete risks early.

DesignHierarchy

Information, copy, density, state clarity, and product promise.

EngineeringContract

Data shape, state model, accessibility, performance, and tests.

ReleaseRisk

Migration, rollback, support notes, analytics, and first-hour watch.

Give the reviewer real context

AI critique is weak without context. The review prompt needs product goal, constraints, target audience, and known boundaries.

Before implementation, I would answer:

• What is the product promise?
• What should not change?
• Which design system exists?
• Which constraints matter?

The artifact is a review context block pasted above the artifact. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is asking for critique without the criteria needed to judge the work; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is feedback that matches the actual product rather than generic taste. That connects review loops that make AI output more inspectable instead of merely faster to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “What is the product promise?” easy to answer. The boundary should force a decision about “What should not change?” and “Which design system exists?.” I would record both in a review context block pasted above the artifact, including the part that stayed unresolved after the first pass. The final check, “Which constraints matter?,” is where the artifact earns its place: it either supports feedback that matches the actual product rather than generic taste, or it shows exactly why another iteration is needed.

Ask for failure modes

AI review gets more useful when it is asked to find failure modes instead of praise.

I would use these prompts during the working review:

• How can this break?
• What happens with bad data?
• Where can users misunderstand?
• What would support hear?

If the team slips into using AI review only to polish language or confirm the chosen direction, the product can still look complete while its operating rule stays ambiguous. I would make a failure-mode review pass for UI, code, content, and release notes the shared reference and keep it small enough to update as evidence changes.

The standard is a draft that gets stronger before it reaches production. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a failure-mode review pass for UI, code, content, and release notes, review it against “How can this break?,” implement the narrowest useful path, and then return with evidence for “What happens with bad data?.” I would use “Where can users misunderstand?” to inspect product consequence and “What would support hear?” to decide whether the result is stable enough to ship. This keeps using AI review only to polish language or confirm the chosen direction visible as a known risk and makes a draft that gets stronger before it reaches production the release receipt rather than a hopeful conclusion.

SurfaceWhat to inspect

Route, component, article, migration, flow, or PR diff.

LensHow to inspect

Accessibility, state coverage, design-system fit, copy, data, or release risk.

ReceiptWhat to return

Findings with location, impact, fix, and confidence.

Separate suggestion from decision

A model suggestion is not a decision. The human should record what was accepted, rejected, or deferred.

I would pressure-test that decision with four questions:

• Which findings are real?
• Which are out of scope?
• Which are wrong?
• Which need a follow-up ticket?

The failure mode here is letting generated critique create churn without human prioritization. In AI-assisted product work that needs critique, verification, and human judgment before it becomes real, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a review disposition table with accepted, rejected, deferred, and why. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is a cleaner review trail and less arbitrary iteration. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a review disposition table with accepted, rejected, deferred, and why beside the question “Which findings are real?” before the first implementation review. The next pass would use “Which are out of scope?” to test the boundary, then “Which are wrong?” to expose the state most likely to be missed. I would keep “Which need a follow-up ticket?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports a cleaner review trail and less arbitrary iteration.

Review for design-system fit

AI-generated UI often invents patterns that look plausible but do not belong to the local system.

The practical review starts here:

• Which components should be used?
• Which tokens exist?
• Which variants are missing?
• Which local styles are suspicious?

Those questions keep shipping a pretty draft that creates new design debt from becoming the default. I would capture the decision in a system-fit checklist that maps output to existing components and tokens, then use it while the work is still cheap to change. For AI-assisted product workflow, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like AI output that respects the product's operating model. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a system-fit checklist that maps output to existing components and tokens part of the working surface. I would use it to answer “Which components should be used?” while scope is still flexible, and “Which tokens exist?” before code or content becomes expensive to unwind. During QA, “Which variants are missing?” and “Which local styles are suspicious?” become concrete checks rather than discussion prompts. That sequence turns AI-assisted product workflow into something the team can operate and gives me a specific outcome to report: AI output that respects the product's operating model.

Review for data realism

AI drafts usually assume clean data. A review loop should force ugly records, missing values, stale states, permissions, and long content.

Before implementation, I would answer:

• What data shape is assumed?
• Which fixtures are ugly?
• What state is missing?
• Does mobile still work?

The artifact is a fixture review pass with ideal, damaged, and restricted data. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is approving a screen that only works with model-perfect content; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is a UI that survives production-shaped data. That connects review loops that make AI output more inspectable instead of merely faster to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “What data shape is assumed?” easy to answer. The boundary should force a decision about “Which fixtures are ugly?” and “What state is missing?.” I would record both in a fixture review pass with ideal, damaged, and restricted data, including the part that stayed unresolved after the first pass. The final check, “Does mobile still work?,” is where the artifact earns its place: it either supports a UI that survives production-shaped data, or it shows exactly why another iteration is needed.

Attach verification to the loop

The loop ends with proof, not with a better paragraph from the model.

I would use these prompts during the working review:

• Which command proves it?
• Which route was opened?
• Which screenshot matters?
• Which migration or asset was checked?

If the team slips into using AI critique as a substitute for running the product, the product can still look complete while its operating rule stays ambiguous. I would make a verification receipt attached to the AI review notes the shared reference and keep it small enough to update as evidence changes.

The standard is work that stays grounded in actual behavior. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a verification receipt attached to the AI review notes, review it against “Which command proves it?,” implement the narrowest useful path, and then return with evidence for “Which route was opened?.” I would use “Which screenshot matters?” to inspect product consequence and “Which migration or asset was checked?” to decide whether the result is stable enough to ship. This keeps using AI critique as a substitute for running the product visible as a known risk and makes work that stays grounded in actual behavior the release receipt rather than a hopeful conclusion.

Keep prompts reusable but not generic

Reusable review prompts are useful when they include slots for context, artifact, constraints, and expected output.

I would pressure-test that decision with four questions:

• What repeats?
• What must be customized?
• Which examples help?
• What output format reduces review cost?

The failure mode here is saving vague prompts that produce vague critique. In AI-assisted product work that needs critique, verification, and human judgment before it becomes real, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a small prompt library with task-specific review lenses. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is a repeatable AI workflow that still respects each product problem. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a small prompt library with task-specific review lenses beside the question “What repeats?” before the first implementation review. The next pass would use “What must be customized?” to test the boundary, then “Which examples help?” to expose the state most likely to be missed. I would keep “What output format reduces review cost?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports a repeatable AI workflow that still respects each product problem.

Show AI loops as candidate evidence

The hiring signal is not that I used AI. The signal is that I used it with judgment, review discipline, and verification.

The practical review starts here:

• What did AI accelerate?
• What did human review change?
• What proof was added?
• What risk was avoided?

Those questions keep presenting AI work as magic output without showing ownership from becoming the default. I would capture the decision in a case-study sidebar with AI loop, accepted critique, rejected critique, and QA receipt, then use it while the work is still cheap to change. For AI-assisted product workflow, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like a portfolio story that shows modern workflow and senior judgment. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a case-study sidebar with AI loop, accepted critique, rejected critique, and QA receipt part of the working surface. I would use it to answer “What did AI accelerate?” while scope is still flexible, and “What did human review change?” before code or content becomes expensive to unwind. During QA, “What proof was added?” and “What risk was avoided?” become concrete checks rather than discussion prompts. That sequence turns AI-assisted product workflow into something the team can operate and gives me a specific outcome to report: a portfolio story that shows modern workflow and senior judgment.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a loop definition with draft, critique, revise, verify, and ship steps
• a critique prompt targeted to the artifact and the risk
• a review context block pasted above the artifact
• a failure-mode review pass for UI, code, content, and release notes
• a review disposition table with accepted, rejected, deferred, and why

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because review loops that make AI output more inspectable instead of merely faster becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

AcceptKeep

The critique is valid and the change improves the product.

RejectExplain

The critique is plausible but not relevant to this scope.

DeferTrack

The critique is real but belongs to a follow-up.

Resource path

The practical follow-up I would build is an AI review-loop prompt sheet for UI critique, code review, content QA, accessibility, and release risk. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• What is the artifact?
• What states are missing?
• What is the product promise?
• How can this break?
• Which findings are real?
• Which components should be used?
• What data shape is assumed?
• Which command proves it?
• What repeats?
• What did AI accelerate?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For AI-assisted product workflow, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• AI output that respects the product's operating model
• a UI that survives production-shaped data
• work that stays grounded in actual behavior
• a repeatable AI workflow that still respects each product problem
• a portfolio story that shows modern workflow and senior judgment

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• A useful AI loop creates output, critique, revision, and proof.
• Different reviewers should pressure-test different layers.
• AI critique prompts should be specific enough to be useful.
• The human should own the final decision and the verification path.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to AI-assisted product work that needs critique, verification, and human judgment before it becomes real: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through review loops that make AI output more inspectable instead of merely faster. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

AI review loops are a hiring signal because they show I can use AI as leverage while keeping taste, verification, and product responsibility human.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.