🥹 Результатов исследования пост (часть 3)

Вместо итога.

📖 Классический premortem обещает конкретный когнитивный эффект: рамка «представь, что реализовали и сломалось, и объясни почему» якобы генерирует находки, которые прямой вопрос «что тут плохо?» не даёт.

🫤 Исследование это опровергло - модель без скилла, без всякой premortem-рамки, с прямым «проверь план» нашла столько же и иногда больше во всех кейсах. То есть premortem как техника поиска не подтвердился. Если бы скилл был ценен именно «премортемностью», мы бы увидели прирост находок, но его нет.

Что реально работает?

Это четыре ограничителя:

🟣 докажи, прежде чем заявить - прежде чем написать «в плане дыра», ревьюер обязан сначала сам попытаться опровергнуть своё подозрение по коду. Заявлять находку можно, только если после этой попытки он может показать: вот файл и строка, где видна причина, и вот цепочка «поэтому сломается вот это».

Это блокирует привычку делать уверенные заявления.
Классика: ревьюер пишет «здесь нет проверки прав доступа!» — а она есть, тремя строками ниже, просто он не дочитал.
Тонкость, ради которой правило написано именно так: ссылка на файл и строку сама по себе — не доказательство. Главный способ, которым врёт такое ревью, — это правильная цитата из кода, из которой не следует сделанный вывод. Код процитирован честно, строка существует, а вывод — фантазия. Поэтому правило требует не «дай ссылку», а «покажи, что из этой ссылки твой вывод действительно вытекает».

🟣 записанные решения важнее варианта ревьюера - если в проекте письменно зафиксировано решение (ADR, инвариант, действующий контракт), то для ревьюера это стена, а не мнение. Он может предписывать только те механизмы, которые проект санкционирует сегодня.

Если ретивый джун на ревью говорит - а давайте перепишем это на микросервисы, так правильнее 🌟 - может оно, и правильнее, но это не его компетенция, а ревью не место для таких решений!

Роль ревьюера сказать «план конфликтует с записанным решением X»!

🟣 к каждой находке - falsifier
Falsifier — это одна конкретная операция, которая доказала бы, что находки нет: один запрос к базе, один тест, один файл, который надо открыть. Формат находки: не «здесь риск гонки», а «здесь гонка, потому что …; проверка: открой file.ts:163 — если там есть FOR UPDATE, я не прав и риска нет».

Это убирает поток непроверяемой тревожности: «а вдруг под нагрузкой что-то пойдёт не так», «возможны проблемы с производительностью». Такое утверждение нельзя ни подтвердить, ни опровергнуть — значит, оно неотличимо от догадки и не является работой. Без этого Opus выдавал до 28 таких тревог на один отчёт, Sol был менее тревожен.

Зачем это читателю отчёта? Находка с falsifier-ом проверяется за минуту: выполнил одну операцию — либо подтвердил и пошёл чинить, либо закрыл. Находка без falsifier-а вешает на команду бессрочный «а посмотрите там вообще всё». Ревью, которое дорого проверять, перестают читать — и оно умирает.

Жалоба «в квартире где-то дует» бесполезна; «дует из-под левого окна — поднеси свечку, если пламя ровное, я ошибся» — это работа.


🟣 вердикт с различием машрута «правки/владелец/можно».

Итог ревью — это не оценка «плохо/хорошо», а указание следующего действия, и действий ровно три, и у каждого свой адресат:
➖PASS — «делайте как написано». Адресат — исполнитель. Работа продолжается.
➖REVISE — «исполнимо, но сначала внесите вот эти правки в текст плана». Адресат — автор плана. Правки — обязательные, это поправки к спеке, а не советы.
➖BLOCK — «стоп, тут вопрос, который не вправе решить ни ревьюер, ни исполнитель: нарушение записанного решения, неприемлемый риск, не тот масштаб». Адресат — владелец проекта.

‼️ Заметьте, чего в этих четырёх правилах нет: ни слова о том, как искать проблемы, где искать, по какому чек-листу идти.

Сильную модель учить не надо. Она ищет сама. Это измерено
Все четыре правила — про обращение с уже найденным.

Шлюз допуска запрещает сочинять, приоритет записанных решений - перепроектировать чужое, falsifier - непроверяемо тревожиться, словарь вердиктов - путать, кому и что делать дальше.

Это те требования, которые хороший тимлид предъявляет к ревью живого сеньора: не гадай — проверь, не переигрывай принятые решения — эскалируй, каждую претензию делай проверяемой и говори внятно, что дальше.
Ничего специфически «ИИшного» тут нет.
Скилл просто заставляет модель соблюдать требования всегда, а не когда получится.

И всё это — дисциплина обычного ревью 😄

#opensource #claude #codex #skills #premortem #research