Skip to content
Verify the result

Is it actually finished?

Generated code looks finished. Contractor work looks finished. The question is whether it does what it was supposed to do, and what else it touched on the way.

What this covers

Reading work the way a reviewer reads it

Against the task

What was asked for, what was delivered, and the difference between the two stated plainly.

What it broke

The parts that were working before and are quietly different now, which is where AI-assisted changes hurt most.

What is missing

Error handling, edge cases, migrations, tests. The parts that get skipped when the happy path demos well.

What nobody can explain

Code that exists, runs, and cannot be justified by anyone on the team. It is a risk even when it works.

How it goes

A second reader who was not the author

  1. The task comes first

    Without knowing what it was supposed to do, review turns into opinion about style.

  2. The work gets read

    By me, or by an AI agent with a prompt written to check this specific thing, and then by me.

  3. Findings are separated by severity

    Blocking, worth fixing, and taste. Mixing those three is how review gets ignored.

  4. You get a verdict you can act on

    Accept, accept with fixes, or send back, with the reason in language you can forward to whoever did the work.

When this matters most

Less useful if

The work has no agreed scope to check it against

You want an opinion on code style rather than on correctness

The decision has already been made and cannot change

Most useful if

A contractor just delivered and you are about to pay

An AI agent produced a large change nobody fully read

Something works in the demo and you are not sure why

You are about to ship to real users

Start with the area that worries you most

Pick the level of involvement that fits, describe your product, and we begin there.