Проверяйте результат отдельно от реализации
Исполнитель знает собственный замысел и склонен читать diff через него. Независимый review начинает с контракта и фактического patch, повторяет проверки и пытается опровергнуть готовность. В companion-проекте часть этой работы делает детерминированный review gate - обычный код, а не мнение.
export function reviewChange(
contract: TaskContract,
changed: readonly string[],
commandResults: readonly CommandResult[]
): ReviewReport {
const findings: string[] = [];
const evidence: string[] = [];
if (changed.length === 0) {
findings.push("No files changed");
}
for (const path of changed) {
if (!allowed(path, contract)) {
findings.push(`Changed file is outside allowed scope: ${path}`);
}
}
for (const result of commandResults) {
evidence.push(`${result.label}: exit=${String(result.code)}, timeout=${String(result.timedOut)}, outputLimited=${String(result.outputLimited)}`);
if (result.code !== 0 || result.timedOut || result.outputLimited) {
findings.push(`Verification failed: ${result.label}`);
}
}
if (commandResults.length < contract.acceptanceChecks.length) {
findings.push("Not every acceptance check has command evidence");
}
return {
passed: findings.length === 0,
changedFiles: [...changed],
findings,
evidence
};
}Порядок независимого review идёт от контракта к фактам: прочитать исходный task contract без объяснения автора, проверить фактический changed file set и каждый hunk, сопоставить новое поведение с acceptance criteria, самому запустить команды или проверить неизменяемые CI artifacts, поискать отрицательные случаи (invalid input, concurrency, authorization, rollback) и отделить blocker от improvement.
Здесь важно не переоценить один удобный механизм.
Checkpoint - это не Git. Claude Code и Cursor документируют checkpoints для возврата к состоянию agent edits, и оба прямо предупреждают, что checkpoints не заменяют version control: внешние команды могут менять файлы вне механизма. Перед рискованной работой нужен чистый Git state, branch или worktree.
Работу делят два разных reviewer'а. Детерминированный gate проверяет scope, exit codes, наличие artifact, typecheck и policy обычным кодом. Модельный review ищет архитектурный риск, missing case и качество объяснения - отдельным reviewer'ом с read-only tools.
Не просите автора только подтвердить себя. Фраза "убедись, что всё правильно" сохраняет тот же контекст и предположения. Дайте reviewer'у исходный контракт, diff и команды, но не вывод "решение верное".
Инженерная модель собрана целиком. Дальше три главы разбирают её на конкретных продуктах - начнём с Codex.
Почему review проводят в свежем контексте, а не просят автора подтвердить себя?