Second Opinion
Reach for Second Opinion the moment something is finished and its builder is about to grade its own work.
- A change is done, and the only review so far came from the vendor that wrote it. That review shares the builder's assumptions, so it proves less than it appears to.
- A reviewer came back "approved, zero findings" and pointed at a test as proof. Ask whether that test could ever have failed.
- The work is expensive to get wrong. Money, records, access and anything a customer sees deserve a second set of eyes.
- You are working alone, and nobody else will read the diff. One outside pass is cheap, so run it even when the work feels small.
Skip it for work that is still half built. A review of half a change returns findings about the half.
A reviewer that did not build the work can see what the builder cannot. A builder and a reviewer from the same vendor share habits and assumptions, so a same-vendor review tends to agree with choices already made and hand them back as proof. Second Opinion sends finished work to a reviewer from another vendor, so a different set of blind spots reads it.
The Guild's Article 50 tells the story of a status panel for a dashboard. A reviewer from the builder's own vendor approved it with zero findings and pointed to a security test as proof that nothing could leak. That test never supplied a key to the panel, so it could never fail. Two reviewers from other vendors, each shown the same change without seeing the other's answer, both caught a missing setting that fell through to "ready."
Show What Leaves Before It Leaves
Nothing is sent until you have read a dry run. It lists every file that would leave your machine and every file held back, with the reason for each hold. Fixtures, test data, exports, snapshots, captures and lock files are held back by default, because they carry real people and real figures. A file sent by mistake cannot be pulled back from a reviewer's chat, so the dry run is the step you read first and approve second. If the code belongs to someone else, its owner has to say yes before anything is sent, and one yes does not carry over to the next project.
Match The Review To The Stakes
One reviewer is right for routine work. A panel is right for work that is expensive to get wrong, such as a change to money, records, access or a public promise.
| Kind of Work | Review | Why |
|---|---|---|
| Routine change, with a test already in place | One reviewer from another vendor | One outside pass is enough, and it costs little to run |
| Money, records, access or a public promise | A panel of reviewers, each in its own separate send | No reviewer reads another's answer, so the panel is not one review wearing several names |
Route On Purpose
Paste is the default. You copy the packet into a chat with a model from another vendor, then copy the answer back into the review file. Two settings from the same vendor family can behave very differently, so check the setting you actually get, not the name on the menu. A command-line tool or an API call is faster for frequent reviews, but it needs credentials kept in environment variables, and it must keep the same dry run in front of every send.
Give Every Finding A Verdict
Nothing the reviewer returns is applied automatically. Each finding gets one of three verdicts from you.
- AGREE means the finding is right. Fix it, and add a test that would have caught it.
- DISAGREE means the finding is wrong or incomplete in context. Write down the context the reviewer lacked. It saw only the diff, so the gap it describes may be dealt with somewhere the diff does not show. Search before you accept it.
- NEEDS-A-LOOK means you cannot decide from here. Name who or what would settle it, and defer the finding with that name attached.
Expect the reviewer to be wrong some of the time, and usually in ways that teach you something. It cannot see the business rule behind a choice, so only your triage and the owner's answer may change the work.
Keep The Evidence
Save the review as a dated file beside the work, and attach it to the pull request when there is one. Answer every BLOCKING finding in writing, either by fixing it with the test that now covers it or by explaining why it is wrong. Then run a second pass on the fixed diff, because a verdict on the old diff says nothing about the new one. The file keeps which findings were accepted, which were rejected and why, and which are still open.
What The Clean Review Covers
A clean verdict covers the packet that was sent, at the confidence the reviewer was asked to report. It says nothing about the held-back files, the parts cut to fit, or behavior outside the diff. Write down what it covered and treat the rest as unreviewed. An APPROVED verdict is evidence about the diff the reviewer read. It is not proof that the work runs, and Verify is the step that checks it does.