technical-premortem skill, продолжение...Следующие выводы исследования кратко:
5. ❤️🩹Скилл может активно вредить — если требует от ревьюера решений.
Самый коварный результат. По него когда-нибудь сделаю отдельный пост.
При использовании тяжёлых версий skill модели предписывали механизмы, которые репозиторий явно запретил, оформляя это как осознанное отклонение (solution-forcing).
Когда появлялась развилка, как решать задачу:
🔤 задачу можно было решить механизмом А (который в проекте официально запрещён и об этом есть записанное архитектурное решение, ADR)
🔤 или механизмом Б (правильным).
✔️ Модели без скилла спокойно выбирали 🔤
❌ А модели с тяжёлыми скиллами… предписывали запрещённый А!
Один раз модель даже процитировала документ о запрете и всё равно предписала А, назвав это «осознанным отклонением»!
Почему так?
В тяжёлых скиллах были строки вроде «для каждого риска предложи готовое решение: guard, feature flag, изменение подхода» и «выдай copy-ready список правок».
То есть инструкция требовала от ревьюера выдать решение. А когда модель заставляют решать, она тянется к самому типовому паттерну из своего обучения — а типовой паттерн быть именно тем, что конкретно ваш проект запретил.
Это и называется solution-forcing — «принуждение к решению».
Урок: роль ревьюера — найти проблему и проверить её, а не спроектировать систему. Если план требует нарушить записанное решение — правильный ответ «BLOCK, спросите владельца», а не «вот вам готовая правка».
Исправленные версии skill прошли эту развилку.
Но помните: инструкция «выдай copy-ready решение» — это источник вреда для review'ера
6. 🌧Эффект «прогноза невыводимых фактов» не воспроизвёлся.
Урок про честность с самим собой.
В первой серии исследования я заметил красивый эффект - прогоны со скиллом якобы лучше предсказывали проблемы, которые невозможно вычитать из кода. Цифры выглядели эффектно: 6 из 6 против 1 из 5.
Во второй части исследования эффект исчез: доли сравнялись. Первый результат был случайностью маленькой выборки — как выпадение орла четыре раза подряд.
Почему этот пункт в списке важного: это демонстрация, зачем нужны повторные проверки. Если бы я сразу объявил эффект доказанным, и не проводил дальнейших исследований, то сейчас строил бы на нём решения.
❤️✖️🙅
Не влюбляйтесь в свой первый красивый результат исследования, перепроверяйте.
7. Sol vs Opus
☀️Sol находит больше, пишет вдвое короче и без скилла непригоден для вынесения вердиктов
🫶 Opus без скилла лучше калиброван по вердикту, но в два раза шумнее и медленее.
Если вердикт ревьюера исполняется конвейером автоматически, то без скилла нельзя использовать ни одну из двух моделей по противоположным причинам.
Главное: не кто лучше, а кто как ломается
У двух этих моделей противоположные режимы отказа. Выбирать лучше ту модель, чей отказ будет компенсирован вашим workflow.
☀️ Sol — «жёсткий следователь». Копает глубже, пишет короче, паникует вердиктом.
🫶 Opus — «осторожный эксперт». Вердикт держит адекватно, но более шумный, больше недоказанных находок.
Как ревьюеры:
☀️Sol нашёл больше подтверждённых проблем, чем 🫶Opus. Причём самые редкие пункты почти все принадлежат ☀️Sol
Вынесение вердикта:
☀️ Sol без скилла: BLOCK/NO-GO 100% прогонов, включая рабочий план, который был реализовали без единой проблемы. Его «стоп» не значил ничего.
🫶Opus без скилла: 0% жёстких вердиктов, лучше калиброван «из коробки».
Но! Со скиллом Sol опустился до 16% жёстких BLOCK/NO-GO и «стоп» снова стал событием.
Объём.
☀️ Sol пишет вдвое короче при большем количестве находок (7–15 КБ против 14–33 КБ у 🫶Opus). Плотность сигнала на килобайт у ☀️ Sol заметно выше.
Шум.
Зеркальная картина: у 🫶Opus без скилла — рекорды по непроверяемым тревогам (по счёту одного судьи — до 28 на прогон) и пересказу плана; у ☀️ Sol отчёты суше, его проблема не вода, а вес вердикта.
Что скилл делает каждому?
Это, пожалуй, самое интересное: один и тот же текст инструкции чинит разные болезни.
☀️ Солу он снимает панику
🫶Опусу режет воду и шум.
Цена.
Связка «Sol + скилл» — самая дешёвая рабочая точка на единицу пользы из измеренных.
Как судьи
☀️ Sol-судья — буквалист: применяет правило по букве, даже когда это сурово.
😡 Fable-судья — интерпретатор: смягчает с аргументацией.
И тут появился интересный вывод. Если у вас два судьи, то усреднять - плохая практика.
Аналогия: два строителя. Где на чертеже стоят размеры, там стены у обоих одинаковые. Где написано «сделайте красиво» — у одного арка, у другого колонна. Стены разные не потому, что строители плохие, а потому что чертёж оставляет неопределённость. И «усреднить» (полуарка-полуколонна) — очевидный абсурд; чинить надо чертёж.
Самая тяжёлая проблема любых критериев оценки (рубрикаторов, чек-листов, определений «что считать багом») в том, что автору его текст всегда кажется однозначным. Найти в собственной формулировке двусмысленность почти невозможно — ты же знаешь, что имел в виду.
А два судьи с разными характерами (буквалист и интерпретатор) работают как тест на двусмысленность: везде, где текст однозначен, они совпадают и расходятся ровно там, где текст оставляет пробелы. Каждое расхождение — это стрелка: «вот в ЭТОМ предложении дыра».
Дальше процедура на пять минут: открыть спорный отчёт, решить, что вы имели в виду, переписать предложение в рубрикаторе. У нас каждый такой спор решился однозначно именно так.
Поэтому расхождение судей — это бесплатный поиск багов в ваших критериях, с точными координатами.
Все, кто использует LLM для оценки чего угодно: гоняет бенчмарки, ставит ИИ-судью в CI («оцени качество ответа от 1 до 10»), сравнивает агентов, принимает работы по чек-листу, индустрия рекомендует стандартный приём — усреднение.
Наши данные показывают протокол лучше и дешевле:
1. Напишите критерии по каждому пункту: что засчитывается, что наполовину, что нет.
2. Возьмите двух судей разных вендоров (разные характеры чтения бесплатно прилагаются).
3. Совпали — верьте. Разошлись — не голосуйте: откройте спорное место, почините формулировку критерия, пересудите.
Два судьи нужны не чтобы усреднять их оценки, а чтобы их несогласие показывало, где критерии написаны плохо. Согласие судей — валидация ответа; несогласие — баг-репорт на рубрикатор.
👨🏻🎓Ещё один важный урок: в задании судье надо явно фиксировать, каким артефактом что можно опровергать.
#opensource #claude #codex #skills #premortem #research