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

Аргумент, который я не сам придумал

В отчёте DORA за 2025 год есть отсылка к критерию Найквиста: "система управления должна работать минимум вдвое быстрее системы, которой она управляет. Иначе это не управление, а наблюдение с запозданием"

Теперь переложите это на свою организацию. Скорее всего, если вы уже используете AI, то у вас любые изменения ужимаются до пары дней. А вот ваш контур согласования скорее всего работает в ритме двухнедельного спринта и релизного окна. И тут я вас поздравляю :) По формальному критерию это уже не контроль. Это отчётность постфактум, оформленная как разрешение.

Это было известно до всякого AI В отчете DORA нет свидетельств, что более формальный внешний процесс ревью связан с меньшей долей неудачных изменений. Зато организации с внешними согласованиями в 2,6 раза чаще оказываются низкоэффективными. Quality Gates не ловили дефекты, они укрупняли батчи. И держали их не потому, что они работали, а потому, что их наличие можно предъявить - да да да, найти виноватого, но не решить проблему.

А с приходом и масштабом внедрения AI у нас будет в десять раз больше изменений, проходящих через контур контроля, который и раньше не работал.

Давайте уберем quality gates? DORA 2025: связь AI с throughput стала положительной, а нестабильность поставок осталась повышенной. Получается, что без  надёжных механизмов контроля рост объёма изменений даёт нестабильность. AI работает усилителем и катализатором этой нестабильности. При этом объем хорошей инженерии и объем бардака примерно одинаков.

Получается что вопрос не в «меньше governance или больше»…

ИМХО #1 как это чинить: управлять генератором, а не артефактом

Двадцатикратный поток диффов вы не отревьюите. Skill, hook, промпт, scope - это вполне легитимные элементы процесса с AI. Их единицы, они меняются редко, и именно они определяют всё, что будет сгенерировано дальше. Ревью конфигурации даёт больше, чем ревью её выхлопа. Для этого конфигурация должна лежать в git, а не в чьей-то домашней папке (я уже писал об этом ранее - https://set.ki/post/JdukHX9).

Отсюда же ответственность: после инцидента спрашивать надо не того, кто написал промпт/skill/hook, а того, кто закоммитил это и утвердил права!

ИМХО #2: инженерия обратимости

Предварительный контроль дорогой и медленный. Последующий контроль это мониторинг, флаги, откат, kill switch уже дешёвый и быстрый, но работает только там, где ущерб откатывается.

Значит настоящая работа governance не «согласовать больше», а расширять зону обратимого. Чем больше изменений можно безопасно откатить, тем меньше нужно разрешать заранее. С этом случае quality gates остаются там, где откатить нельзя: деньги, публичные контракты, доступы, удаление данных, миграции

Это инженерная задача, а не регламентная. И она никогда не попадает в roadmap, потому что выглядит как техдолг.

Контрольные вопросы и проверки - Добавляет ли контур независимую информацию? - Плюс теперь второй вопрос: успевает ли он сказать «нет» раньше, чем система наделает необратимого?

Контур, который не проходит оба, — не контроль. Это запись в системе, и её стоимость вы платите каждый день.

Самое неприятное в том, что убрать такой контур обычно нельзя, потому что он кому-то предъявляется. Поэтому организации будут не убирать, а ускорять — прикручивать агентов к согласованиям. Формально станет быстрее. Найквист по-прежнему не выполнится, потому что информации в контуре как не было, так и нет.

#разработка #ai #it #governance #devops #процессы #инженернаякультура