DEKSDEN notes

🙋 Практики пост Одно из лучших улучшений моих 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

🙋 Практики пост Одно из лучших улучшений моих 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 и в другой сессии с чистым контекстом.