Классическая разработка + ИИ: почему премортем, призма и ADR - первые шаги, а не опция

Я зашёл в AI-агентов с бэкграундом 23 лет в DevOps. Terraform, Ansible, Kubernetes, Docker - классическая инженерия, где сначала план, потом код, потом прод.

Когда я начал работать с агентами, первое, что бросилось в глаза: модель пишет код быстрее, чем я успеваю подумать, надо ли это вообще писать. Она не останавливается и не спрашивает "а какое решение мы принимаем?". Она сразу выдаёт реализацию.

И это проблема.

Эпистемология: почему мы не знаем, что знает модель

У LLM нет внутреннего состояния "я уверен" vs "я гадаю". Она выдаёт токены, максимизируя правдоподобие. Когда агент пишет код - мы не знаем, понимает он архитектуру или повторяет паттерн из обучающей выборки.

Это не теоретическая придирка. Это означает: решение, принятое агентом, нельзя принимать на веру без внешней валидации.

Отсюда первое правило zero tolerance: никакой код от агента не идёт в прод без формализованного решения до него. Не после - до.

ADR-first: решение до кода

Architecture Decision Record - простая практика: перед тем как писать код, записать:

▪ Контекст: что мы решаем

▪ Альтернативы: какие были варианты

▪ Обоснование: почему выбрали этот

▪ Риски: что может пойти не так

Когда я отдаю эту задачу агенту, он получает не "напиши код для X", а "вот ADR, вот решение, реализуй его". Разница в качестве ответов - как день и ночь.

Без ADR агент галлюцинирует архитектуру. С ADR - реализует принятое решение.

Premortem: найди проблемы до того, как они найдут тебя

Техника Гэри Кляйна (Harvard Business Review, 2007). Вместо "что может пойти не так?" - общий вопрос, дающий общие ответы - мы говорим агенту: "прошло 6 месяцев, решение провалилось. Объясни почему".

Мозг (и модель) переключается из режима одобрения в режим поиска проблем. Premortem на ADR - до того, как написана первая строка кода - выявляет 5-6 причин провала, которые иначе вскрылись бы на этапе эксплуатации.

Prism: структурный анализ, который агент сам не сделает

Prism - это multi-pass анализ: смотришь на решение с разных перспектив. Адвокат дьявола. Экономический анализ. Безопасность. Масштабирование.

Каждый pass - отдельный запрос к агенту с другой рамкой. Не "оцени решение", а "найди уязвимость", "найди узкое место по производительности", "найди скрытое допущение".

В сумме - полная картина рисков, которую ни один single-pass запрос не даст.

Zero tolerance к AI-решениям без процесса

Ни один ответ агента не принимается как финальный без прохождения через pipeline:

1. ADR - формализация решения

2. Premortem - поиск причин провала

3. Prism - multi-pass структурный анализ

4. Только потом - реализация и код-ревью

Это не паранойя. Это та же самая инженерная культура, которая работает в DevOps: сначала спецификация, потом код, потом тесты, потом прод. Только теперь код пишет агент, а решение принимает человек.

Час на ТЗ экономит дни переделок

Я замерял: час на написание ADR + premortem + prism даёт агенту контекст, который сокращает количество итераций с 5-7 до 1-2.

Без ТЗ:

▪ Первая итерация - агент угадал архитектуру (вероятность 30%)

▪ Вторая - переписывает (ещё 30%)

▪ Третья - переписывает снова

▪ В результате: день работы, 70% кода в мусорку

С ТЗ:

▪ Одна-две итерации

▪ Код соответствует решению

▪ Нет архитектурных разворотов на полпути

Разница не в модели. Разница в процессе вокруг неё.

А что насчёт доверия к моделям?

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

Почему так происходит - почему модель может быть уверена в неверном решении, почему Chain-of-Thought не помогает, а иногда мешает, и почему "отличное решение, сеньор-левел" от агента - это шум, а не сигнал - об этом в следующей статье.

---

🌐 hermes-agent.ru

ℹ️ Хотите попробовать, но нет времени разбираться? Напишите в контакты на сайте - поможем с настройкой и подбором сценария под ваши задачи.