Everyday Programmer
AI Workflows

Stop Asking AI if the Code Looks Right — Ask What Would Prove It

A second model saying 'looks good' isn't verification. A practical workflow for turning AI review into claims, risks, and real evidence.

3 min readai workflows, code review, verification
Illustration for "Stop Asking AI if the Code Looks Right — Ask What Would Prove It" — Everyday Programmer

A second model saying "looks good" is not strong verification.

Too many AI-assisted workflows end with the same weak step: we show the code to another model, it says the code looks right, and we call it verified.

That's an agent grading its own homework.

Why "looks good" fails

When a model reviews a diff, it has no runtime. No browser. No users. No logs, no metrics, no rendered output. It can reason about what might break — and that reasoning is genuinely useful — but it cannot observe what does break.

Worse, there's a structural problem: if the same family of models wrote the code and reviews the code, shared blind spots come along for the ride. A misunderstanding of the requirement that shaped the implementation will often shape the review too.

AI confidence is not engineering evidence.

The shift: claims → risks → checks

Stop asking AI if the code looks right. Ask what would prove it.

Every change makes claims, whether or not we write them down:

  • This button submits the form.
  • This refactor preserves behavior.
  • This new component is accessible.
  • This query is fast enough.

Each claim implies a risk — what breaks if the claim is false. Each risk implies a check that could produce real evidence:

claims-to-evidence.txt
text

Tests, browsers, scanners, observability, and engineers provide the evidence. AI's job is to enumerate the claims and design the checks — not to be the check.

A prompt template that actually helps

The practical version of this shift is a different closing prompt. Instead of ending a session with "does this look right?", end it with something like this:

proof-prompt.md
md

The output of that prompt isn't a verdict. It's a work order.

Then run the checks

Here's the workflow end to end:

  1. Implement with your agent of choice, as usual.
  2. Enumerate claims. Ask the model to list what the change asserts about behavior.
  3. Map claims to checks. Existing tests, Playwright interactions, axe scans, visual diffs, type checks, log queries.
  4. Run them for real. Evidence comes from execution, not evaluation.
  5. Close the gap. For claims with no existing check, add the smallest one that would catch the failure.
  6. Record what's still uncertain. Some things can't be proven pre-merge — say so in the PR instead of pretending they were verified.

The future is an evidence broker, not a judge

The future of AI-assisted engineering isn't a smarter judge. It's a better evidence broker — one that turns "looks good to me" into "here is what is proven, here is what isn't, and here is what is still uncertain."

That distinction is what separates a workflow that feels verified from one that actually is.

Keep reading

Related articles