Написано ИИ

Каковы настоящие риски выпуска программы, которую никто не прочитал целиком?

Не «ИИ пишет плохой код». Семь уязвимостей, возникающих оттого, что понимание не поспевает за продакшеном.

Короткий ответ

Риск не в качестве кода, а в том, что никто в компании не может ответить на вопросы о системе, от которой компания зависит, — и что обычных признаков этого состояния нет. Отсюда семь конкретных уязвимостей: молчаливые сбои, непроверенная документация, неповторяемые ответы, дублирующиеся подходы, тонкие несчастливые пути, бесхозная работа по расписанию и передача, которой не может произойти, потому что передавать нечего. У каждой своя цена и своя проверка.

#Правильная рамка

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

Настоящая уязвимость

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

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

#Семь уязвимостей

  1. Молчаливый сбой

    Обработку сбоев надо вообразить, а не описать, поэтому она чаще всего и оказывается тонкой. Задача, которая падает молча; интеграция, которая встала в прошлом месяце; выгрузка, чьё неприбытие никто не замечает.

    Проверка: порождает ли каждый путь сбоя что-то, что увидит человек?

  2. Непроверенная документация, которой верят

    Сгенерированная документация гладкая, обширная и неотличимая от проверенной. Люди по ней действуют. Там, где она неверна, она неверна уверенно и в подробностях.

    Проверка: возьмите пять конкретных утверждений из неё и сверьте каждое с кодом.

  3. Ответы, которые нельзя повторить

    Спросить агента — значит получить хороший ответ сегодня и ничего завтра. Спросите снова через квартал — получите другой ответ, без способа сравнить их и без записи, какой из них был верен и когда.

    Проверка: может ли кто-нибудь показать, как система выглядела три месяца назад?

  4. Три решения одной задачи

    Разные сессии решали одно и то же по-разному, и каждое локально разумно. Цена не эстетическая: изменение надо внести трижды, а кто-то внесёт его дважды.

    Проверка: есть ли в этой системе больше одного способа делать кеширование, валидацию, повторы или отчёты об ошибках?

  5. Бесхозная работа по расписанию

    Задачи, работающие по расписанию и добавленные в одной сессии. Никто их не помнит, никто за ними не следит, и ничто не оповещает, когда одна останавливается.

    Проверка: перечислите всё, что работает по расписанию, по коду, по консоли и по crontab. Сравните три списка.

  6. Допущения о доступе, которые никто не проверял

    Эндпоинт, который должен был быть внутренним. Вебхук, не проверяющий отправителя. Отсутствующая проверка владения на маршруте, который проходит любой тест, где пользователь один.

    Проверка: пройдите по списку маршрутов явно и пометьте каждый как «задуман публичным» или «задуман приватным».

  7. Передача, которой не может произойти

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

    Проверка: смогли бы вы передать это другой команде в следующем месяце и что бы вы им передали?

#Во что каждая обходится

Уязвимость и место, где приходит счёт
УязвимостьЦенаПриходит
Молчаливый сбойПотеря данных, невыполненные обязательства, партнёр, который перестал что-то получатьЧерез месяцы, снаружи
Непроверенная документацияРешение, принятое из ложной посылкиКогда решение исполняется
Неповторяемые ответыКаждый вопрос задаётся с нуля, всегдаПостоянно и незаметно
Дублирующиеся подходыИсправления, применённые в двух местах из трёхВ виде бага, который уже чинили
Бесхозная работа по расписаниюЧто-то остановилось, и никто не заметилКогда пожалуется кто-то снаружи
Допущения о доступеУтечка данных или доступ к операцииГде-то между «никогда» и «на этой неделе»
Невозможная передачаМесяцы восстановления картины, оплаченные по полной ставкеВ момент, когда кто-то уходит

#Как понять, относится ли это к вам

Шесть вопросов. Если три из них неприятны, эта страница про вашу систему.

  • Смог бы кто-то в компании назвать каждый компонент и сказать, что он делает?
  • Проверял ли кто-нибудь ту документацию, которая есть?
  • Смог бы кто-нибудь сказать, что структурно изменилось за последние два месяца, не читая пул-реквесты?
  • Знает ли кто-нибудь всё, что работает по расписанию?
  • Если бы ваш самый активный разработчик был недоступен месяц, остальные смогли бы выпускать изменения?
  • Есть ли в системе что-то, о заказе чего никто не помнит?

#Что это снижает

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

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

Проверка: чек-лист перед продакшеном, пройденный один раз до настоящего трафика и ещё раз после каждого значимого пуша.

#Что идёт не так

Сделать вывод, что решение — меньше писать код агентами.

Вместо этого Скорость — настоящий выигрыш. Менять надо то, что понимание теперь производится намеренно, а не побочным эффектом.

Добавить процесс код-ревью и считать, что готово.

Вместо этого Ревью ловит дефекты в изменении. Ни одна из семи уязвимостей выше не дефект в изменении: это свойства целого.

Сгенерировать ещё документации.

Вместо этого Сначала проверьте то, что есть, а потом добавляйте. Проблема не в объёме, а в том, что ничего из этого никто не проверял.

Ждать, пока что-нибудь сломается.

Вместо этого Четыре из семи молчаливы по построению. Ждать сигнала здесь значит ждать, пока его подаст кто-то вне компании.

Считать это поводом не доверять команде.

Вместо этого Никто ничего плохого не сделал. Изменилась скорость производства софта; механизм, производивший понимание, вместе с ней не масштабировался.

#Чего это не покрывает

Чего это не делает

  • Лучше или хуже код, написанный ИИ, чем написанный руками. Неразрешимо и не является уязвимостью.
  • Оценку безопасности. Две из семи пересекаются с гигиеной безопасности; ничто из этого не является ревью безопасности.
  • Юридические и регуляторные последствия того, как софт был произведён.
  • Всё, что касается интеллектуальной собственности в сгенерированном коде: вопрос настоящий и юридический.

Установите, что там на самом деле.

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

Построить карту проекта — бесплатно Чек-лист перед продакшеном