A second opinion on AI code, voiced before the code is pasted

The diff is well-written, the tests pass, and the logic is arranged as cleanly as the last three diffs from the same assistant, and there is a small lingering doubt that you cannot type: something about the retry path, or the way the error is swallowed, so the draft feels too neat to be fully trusted. The doubt is common, and it usually does not survive the first seconds of asking a second model, which then agrees with the draft, praises its style, and leaves you with exactly the same doubt plus wasted tokens, and the right briefing is the difference between a second opinion on AI code that finds a bug and one that returns a compliment. The agreement is not evidence; the second model saw the pasted code and the first model's confident style, and a review that flatters the style has reviewed the wrong thing.

The doubt worth respecting is not the technical one but the contextual one: the code may be correct and still wrong, because correctness is measured against the intent, and the intent lives in the conversation that produced the draft, not in the diff. The first model knew the intent through the prompt chain, while the second model, given only the code, reconstructs the intent from the code itself, which is a circle that flatters whatever is inside it. The nagging doubt is therefore a signal that the review should start with the requirement rather than the code, and the requirement, spoken by you, is the only material in the whole session that both models do not already share.

The cost of acting on the doubt is the question: is the full second-model pass worth the tokens and the time for every diff? Hardly, which is why the doubt has to be graded before the pass rather than after. Say the diff's risk class aloud as you create it: this changes the retry semantics, which affects money; this moves a label, which affects layout. The risk class is the filter, and the filter is what makes the two-model pass a deliberate tool rather than a reflex. A second opinion on AI code is most valuable when it is spent where the cost of being wrong is a production incident, and almost worthless when spent where the cost is a re-render.

The graded doubt does one more useful thing before the pass: it forces the doubt to be a sentence rather than a feeling. The feeling of something about the retry path becomes the sentence the retry path is unbounded in a new way, since the change added a while loop that no longer exits on the first success. A sentence is checkable, and checkable is the difference between a review that produces a verdict and a review that produces more feeling. When the sentence is on the record, the second-model pass has a question to answer, and a question with a shape is worth ten asks with a vibe.

The filter for the second pass is three questions, asked aloud and answered with a grade: does this change touch money, permissions, or data integrity; is this logic worth auditing because a silent failure would be worse than a visible one; and does the codebase have a convention here that the first model might not have seen? Three yeses means the pass, three noes means move on, and a mixed set means pass on the part that earned it rather than the whole diff. The grading is the discipline that keeps the habit affordable, and the spoken grade is the reason the habit stays honest, since a grade said out loud is a grade that can be argued with by a teammate.

The second-most important question is what the first model is unlikely to be right about, which is usually the parts where the codebase's history matters: the legacy endpoint that behaves oppositely to its name, the shared utility with the three callers and the hidden side effect, the policy that the first model read from the neighboring code and generalized in the wrong direction. Say those parts aloud and list them as the review targets, since a second-model pass aimed at the two spots the first model was structurally likely to miss vastly outperform a pass that reads the whole diff and pronounces it clean. The aim is the whole craft, and the aim comes from the team's institutional memory about what generation gets wrong in this codebase.

The pragmatic counterweight to the pass is the single-model self-check, which runs first and answers half the doubts: ask the first model to explain its own diff in three sentences regarding what this assumes, what it does not handle, and what would break it. The third sentence is the productive one, since the model that can name its own fragility has already flagged the spots the second pass should examine, and the model that cannot has just told you where to look. The self-check costs one exchange and it grades the diff automatically: a diff whose fragility is named is a diff that may not need the second model at all, while a diff whose fragility is vague is a diff that earns the full pass.

The budget should be settled before the session and stated aloud: two passes per week, three diffs per pass, and the sensitive ones only. The stated budget is what makes the choice a policy rather than a mood, and the policy is what the team can reason about, since a teammate can challenge a pass assignment that violates the grade but cannot challenge a mood. When the budget runs out mid-week, the overflow is a signal about the team's risk profile, and the signal belongs in the retro rather than in an unplanned fourth pass. The second pair of model eyes is a scarce resource by design, and scarcity is what keeps its verdicts sharp.

The second model's review is only as good as its briefing, and the briefing must be the intent rather than the code, because a model that sees the code alone will validate the code against itself. So voice the requirement in the same sentence you would have given the first model: the service should retry a charge twice on timeouts, never on a decline, and pause between the retries, and the whole thing should finish within the order's timeout. The spoken intent is the review's anchor, and the second model's job becomes checking whether the code satisfies the requirement, which is the only useful job a reviewer has. A code-first briefing flatters the author; the intent-first briefing audits the work.

The intent briefing should include the parts that are easy to forget and impossible to infer: the constraint that the request must be idempotent, the limit that the retry must never exceed the total budget, and the edge that the business considers a decline to be final. Each sentence is a clause that the first model implemented from the conversation and the second model cannot see, and each clause is exactly the place where a plausible implementation diverges from the intended one. Say the clauses slowly, and ask the second model to restate them in its own words before it reviews anything, because a model that cannot restate the constraints cannot be trusted to check them, and the restatement is the cheapest way to find a briefing with a hole in it.

There is a second reason to voice rather than to paste: the voice is the only channel through which the scope enters. Say what the change is not doing, the labels are not being repositioned, the authorization is not being changed, so that the second model does not invent a review of a refactor that never happened. A model with scope stated is a model that stays on the diff, while a model with only a diff on the table will wander into the nearest neighboring file and raise the classic non-issue that the team already settled in March. The scope sentence is the fence, and the fence is what makes the pass worth its minutes.

The final briefing element is the question, the one from the doubt grade: I want to know whether the retry path can ever spend the entire order budget on a single attempt sequence, and I want you to trace it. The question is the review, and the rest of the pass is supporting work, which is why the second model's answer should be the first thing read and the last thing argued with. A pass with a specific question returns in a hundred words, while a pass with a general prompt returns in three pages that restate the diff. The second opinion on AI code is worth exactly as much as the specificity of the question it was hired to answer.

The two models have now disagreed, which is the outcome that makes the pass worth running, and the disagreement is between two confident explanations, so weigh it as evidence rather than as votes. Read the first model's defense and the second model's objection aloud, and ask each to cite the line of code or the clause of the intent it is arguing from, since the citation is what turns an opinion into a claim. The model whose claim stands up against the code is the model to trust, and the model whose claim stands up against your sentence of the intent is the model to trust even more, because the sentence is the requirement and the code is a guess about it.

The temptation the pass has to fight is the surrender reflex: the second model sounds more confident, or has read the code with a different idea, and the engineer rewrites the implementation to satisfy the review. The surrender is the exact opposite of the goal, since the second model is an advisor and not an auditor, and the implementation belongs to the human who voiced the intent in the first place. Weigh both opinions against the requirement sentence and the code, and if the disagreement is genuinely about the requirement rather than the implementation, that is a design question to bring to the team, not a rewrite to perform on a whim. The human is the tiebreaker because the human owns the requirement.

The weighing has a spoken form that keeps the record straight: the first model says the retry is safe because the deadline check is inside the loop, and the second model says the deadline is checked only after the second retry, and I have read the line, and the second model is right, so the requirement sentence was the correct one and the code is now wrong. The sentence is the verdict, and the verdict names the loser rather than simply selecting the winner, which is what prevents the next model from re-claiming the same wrong thing a week later. The record of the weighing is the institutional memory, and the memory is what makes the third model pass a minute instead of a session.

If the two opinions agree and confirm the change, do not treat the agreement as safety, since the two models share the same general world-model and will correlate on the same blind spots. Say the agreement's limit aloud: both models consider the retry bounded, and neither has checked the interaction with the new deadline config because I did not mention it in the intent, so that check is mine. The agreement is a partial signal, and the partial signal has a boundary, and the boundary is usually the thing the human should hold. Weighing two opinions well ends with a human sentence: what I am confident about, what I still need to verify, and what I will verify before this merges.

The check keeps its value only when it is rare, because a rare check is a careful check and a daily check is a formality, so the reservation rule matters more than the rule's exceptions. The sensitive changes are the ones that touch money, credentials, access control, or irreversibility, and the reservation is stated in one spoken sentence at the start of the pass: the retry change touches charge failures, which is money, so it is a sensitive change and it earns the cross-check, while the label change does not and it gets the single-model self-check instead. The sentence is the policy and the policy is what the team can appeal, and an appeal is the health sign of a process rather than its failure.

The reservation also applies to the first model, in a way that is easy to miss: the first model earns the second review only when the change is sensitive, and the single-model self-check is the honest default for the rest. The self-check's three questions, what does this assume, what does it not handle, and what would break it, become the standing quality gate, and the pair of eyes becomes the escalation. The hierarchy is the design: everyday work gets a good fast gate, sensitive work gets a slower careful one, and neither gets skipped just because the other exists. Teams that run the two-model check on everything produce the same review quality at triple the cost, and the cost is the thing that quietly makes the check stop happening.

The sensitive change has one more property that the reservation must capture: option value. The money change is sensitive because the cost of being wrong is high, but there are changes whose cost is low and whose reversibility is zero, like the sort order that ships to the catalog, and the reserve rule should read as code against high cost or hard reversal rather than against a category list. Say the generalized rule and let it replace the list: the second pair of eyes goes to the changes where being wrong is expensive or undoable, and everything else gets the fast gate. The generalized rule survives the next reorganization, while the category list gets stale at the exact moment the team needs it.

Finally, reserve the habit itself: the pass must remain a choice that a human makes and states, not a pipeline step that runs silently, because the moment it runs silently it starts to be trusted silently, and a review that is trusted silently is a review that is no longer a review. Say the reservation sentence at the start, say the verdict at the end, and never let the check run without a name attached. The second opinion on AI code, held in reserve and spent deliberately, is the highest-leverage tool available to a developer working with a strong writing model: it costs the minutes of one conversation and it returns the certainty that a confident draft is actually right, which is the difference between merging with a doubt and merging with none.