🙋 Практики пост

Одно из лучших улучшений моих workflow - это добавление в них technical-premortem

Далее можно ничего не читать, воткнуть к себе этот скилл и вызывать его на планировании.

—-

С осени 2025 года я разрабатывал такой подход, чтобы в solo тащить проекты, где я являюсь единственным фаундером и вообще единственным живым человеком.
К апрелю 2026 у меня уже полностью сформировался ai-firendly подход к разработке проектов.
Однако уже в мае я добавил в него technical-premortem skill.

Чем он помогаети почему он так хорош?

Если посмотреть на мой процесс работы верхнеуровнево, то ядро разработки состоит из двух крупных блоков/циклов: планирования и реализации. Внутри каждого есть этапы разработки и проверки.

Да, review планов выходят дешевле, чем review на реализации.
Да, review необходимо делать другой моделью, отличной от той, которая писала план.

Написали план -> кросс-ревью.
Внесли изменения в проект/написали код -> кросс-ревью.
Это если на пальцах.

Но и у этого подхода есть проблемы.

Мы знаем, что модель склонна защищать свои решения. При этом написанные современными моделями планы всегда выглядит убедительно. Кросс-ревью другой моделью снимает часть проблем, но не убирает главную порблему - модель делает слабую задачу в неправильной рамке.

Слабая задача - проверь/оцени
Неправильная рамка - а вдруг тут что-то не так

Из трёх проблем:
- кто проверяет,
- что проверяет,
- как проверяет,
при использовании другой модели мы решили только первую.

И тут на помощь приходит классика когнитивной психологии.
Представь, что событие уже произошло и претерпело провал - это повышает способность как человека так и модели назвать причины негативного исхода и сбивает необоснованную уверенность в плане намного эффективнее, чем обычная проверка.

Для агента это работает даже лучше, чем для людей, потому что меняется как сам тип задачи, так и рамка.

Вместо "найди ошибки в плане", мы переводим модель в режим рассуждений, где план уже реализован и провалился.
Мы требуем от модели объяснить, что сломалось, т.е. сгенерировать причинно-следственные объяснения по свершившемуся факту.
А генерировать правдоподобные объяснения - это то, что современные модели делают лучше всего.

Способность к коррекциям планов у моделей есть, но эту способность нужно активировать снаружи.
technical-premortem skill и есть такой внешний активатор

Что делает мой technical-premortem skill?

Перед реализацией любого изменения агент принимает установку о том, что изменение уже смёржено, задеплоено и провалилось и работает в обратную сторону:

👁 восстанавливает blast radius: что меняется → что от этого зависит → что разделяется;
👁 прогоняет таксономию из 13 категорий сбоев — от необратимых миграций до отдельной обязательной категории «ошибка самого агента-исполнителя»;
👁 сортирует риски:
👁 выдаёт план отката, pre-flight чек-лист и вердикт Go / No-Go.

Ключевое - смена роли. Модель больше не защищает план, а расследует уже случившуюся катастрофу.
Туннельное зрение и слепые пятна убираются комбинацией другой модели, другой задачи и другой рамкой

P.S. Не смотря на то, что у меня за месяц до внедрения этого skill были решены основные проблемы разработки на ии-агентах, этот skill дал значительный буст в скорости разработки.

P.P.S. Skill написан и доработан с помощью codex и claude code на основе имеющейся в открытом доступе информации специально для технического премортем. Использую уже более 2-х месяцев. Можно брать и допиливать под себя. Представлена русскоязычная версия для лучшего восприятия, можно перевести на english и use it.

P.P.P.S. Можно использовать в рамках одной модели, но лучше на более высоком effort level и в другой сессии с чистым контекстом.

#skills #opensource