Разбор: «дефицит вины» — что делать, если прод упал из-за кода, который написал ИИ

Google AI Overview по запросу «The Blame Deficit in Software Engineering» теперь синтезирует определение этого термина как основной результат. В списке источников, которые модель собрала, оказались публикация в Hashnode вместе с обсуждением в комментариях и материалы ACM Queue. Само по себе это курьёз из мира поисковой выдачи. Но формулировка, которую сгенерировал Google, описывает ситуацию, в которую попадает почти любая команда, где код пишет модель.

Определение звучит так:

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

Почему это касается вас, даже если вы ИИ не пользуетесь

Цепочка выглядит безобидно. Модель выдаёт дифф. Ревьюер ставит approve — правдоподобный, аккуратный, стилистически чистый. CI зелёный. Деплой. Инцидент. И дальше начинается самое интересное: постмортем ищет виноватого, а виноватого нет. Автор изменения формально прав, ревьюер формально прав, тесты формально прошли.

Именно этот нюанс и разбирали в комментариях под исходной публикацией — где проходит граница между «ленивым провалом CI» и настоящим семантическим сбоем под распределённой нагрузкой. Google выкачал и это обсуждение. Реальный инженерный спор попал в индекс, а не сухая формулировка из учебника. Приятная деталь, но полезная: значит, модель считает такие обсуждения значимой частью определения термина.

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

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

Это основной тезис книги The Unshakeable Developer, из которой вырос весь разговор. Наборы визуальных схем и полевых чек-листов аудита, с которых всё началось, автор выложил в открытом репозитории на GitHub.

Что делегируется модели, а что остаётся на человеке

Как закрыть дефицит вины в своей команде

1. Помечайте код, пришедший от модели. Метка в PR или трейлер в коммите. Не для охоты на ведьм — для статистики: где и на каких участках чаще прилетает.
2. Владелец изменения — всегда человек. Approve означает «я отвечаю за поведение этого кода в проде», а не «дифф выглядит нормально».
3. Ревью смещайте на семантику. Что будет под нагрузкой, при ретрае, при частичном отказе, на границах. Стилистику как раз можно оставить линтерам.
4. Ограничивайте радиус поражения. Флаги, канареечный выкат, лимиты, быстрый откат — это дешевле и надёжнее любого запрета на ИИ-код.
5. В постмортеме фиксируйте точку прохода. Где именно решение прошло без человека и какой шаг оказался формальностью. Это и есть полезный вывод из разбора, а не имя виноватого.

Частые ошибки

• Искать виноватого в авторе диффа. Он мог не написать ни одной строки руками.
• Считать зелёный CI доказательством корректности. Он доказывает, что проверки прошли, и ничего больше.
• Запрещать ИИ-код целиком. Запрет не создаёт ответственности, зато создаёт обходные пути.
• Писать в постмортеме «виноват ИИ». Это фиксация беспомощности, а следующий сбой повторится тем же маршрутом.

Когда схема не сработает

Если в команде нет человека, который реально может остановить деплой, любой чек-лист превращается в бумагу. И обратный случай: в маленьком проекте, где один человек и пишет, и выкатывает, вся конструкция сводится к его личной дисциплине — метки и трейлеры там только мешают.

Поисковая выдача ничего не изменила. Она просто вслух произнесла то, что и так происходило в командах. Ответственность не генерируется вместе с диффом, и если за изменение некому держать ответ, дефицит будет расти ровно с тем же темпом, с каким растёт объём кода от моделей.