Границы использования ИИ при генерации кода для рискованных участков

Что идет не так, когда ИИ пишет рискованный код

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

Настоящая проблема — скорость. ИИ может сгенерировать код за секунды, команды работают быстро, и плохие изменения распространяются прежде, чем кто-то успевает их остановить. Баг в кнопке интерфейса раздражает. Баг в ценообразовании, контроле доступа или структуре базы данных может утечь данные, списать неправильную сумму или превратить восстановление в медленный и дорогой хаос.

Самые рискованные участки обычно делятся на три группы:

• потоки данных: изменения схемы, backfill, удаление и задачи импорта
• денежные потоки: скидки, налоговая логика, счета, кредиты и правила подписок
• потоки доступа: роли, права, действия администратора, токены и границы аккаунтов

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

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

Та же схема появляется и в работе с данными. ИИ предлагает миграцию, которая переименовывает колонку и обновляет код приложения. Но он пропускает один скрипт отчетности и одну задачу экспорта. Приложение по-прежнему открывается, поэтому pull request выглядит нормальным. Ночью отчеты становятся пустыми, и команде приходится распутывать, какие записи изменились до того, как это кто-то заметил.

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

Вот почему границы для ИИ при генерации кода действительно важны. Рискованный код редко ломается только в той строке, которую изменили. Он ломается во взаимосвязанных системах, старых клиентских договорах, сценариях поддержки и предположениях команды. На таких участках даже маленькие изменения все равно нужно проверять медленно.

Какие участки кода требуют жесткой остановки

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

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

Логике биллинга нужен тот же уровень внимания. Цены часто зависят от правил тарифа, дат пробного периода, купонов, количества мест, налоговых правил, кредитов и округления. Одно неверное условие может месяцами занижать оплату, и никто этого не заметит. Переплата еще хуже, потому что клиенты замечают ее быстро и запоминают надолго.

Возьмем SaaS-приложение с месячными и годовыми планами, скидкой для больших команд и налогом по странам. ИИ обновляет одну функцию ценообразования после изменения схемы. Тестовый заказ покрывает один тариф в одной стране, поэтому тест проходит. Настоящие пользователи, которые переходят посреди цикла, начинают получать суммы, отличающиеся на несколько долларов. Это звучит мелко, пока финансовой команде не приходится исправлять сотни счетов.

Границы безопасности тоже требуют строгой проверки человеком. Сюда входят сценарии входа, сброс пароля, хранение токенов, проверки сессий, admin-маршруты, области API и правила доступа к файлам. Модели часто идут по счастливому пути и пропускают ветку, где доступ должен быть запрещен. Атакующие как раз и ищут такие ветки.

Для большинства продуктов достаточно короткого списка зон только для ревью:

• изменения схемы, backfill и разрушительная очистка
• код, который определяет, сколько платит пользователь
• код, который выдает, запрещает или расширяет доступ
• аутентификация, сессии и работа с секретами

Риск не в том, что модели всегда ломают эти области. Риск в том, что они могут сломать их тихо. Миграция может завершиться успешно и все равно записать неверное значение по умолчанию в половину строк. Проверка прав может работать для обычных пользователей и все же раскрывать одно админское действие.

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

Как провести границу в вашем продукте

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

Большинство команд и так понимают, какие области выглядят рискованно. Проблема в том, что правило часто живет только в чьей-то голове. Поместите его в репозиторий, чтобы каждый разработчик, ревьюер и подрядчик видел одну и ту же границу.

Отметьте код, который может быстро навредить

Создайте короткий набор меток для защищенных путей. Держите их простыми и скучными. Для этого не нужна отдельная framework-система.

Используйте метки для изменений данных, денежной логики и контроля доступа. На практике это означает миграции, backfill, удаление, импорт, pricing, скидки, налоги, возвраты, кредиты, вход, роли, права, токены, API-ключи и работу с секретами.

Используйте одни и те же метки везде, где работает команда: в папках, pull request, шаблонах ревью и системе задач. Если изменение затрагивает один из таких участков, автор добавляет метку до начала проверки. Если есть сомнения, метку все равно ставят.

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

Назначайте людей, а не только команды

Для каждого защищенного участка нужен конкретный ревьюер. «Backend team» — слишком расплывчато. Один человек должен отвечать за ревью миграций, один — за денежные правила, и один — за auth и секреты. Второй ревьюер может подключиться, но основной владелец должен быть понятен.

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

Небольшой стартап может сделать это без тяжелого процесса. Один founder или CTO может сначала проверять все три участка. Это все равно намного лучше, чем относиться ко всем pull request одинаково.

Хорошая граница должна быть понятна в загруженный день. Если команда не может объяснить ее за минуту, значит, она все еще слишком размыта.

Простой процесс ревью для чувствительных изменений

Чувствительному коду нужен более медленный путь. Позвольте модели помогать там, где ошибки остаются небольшими, а потом остановите ее до того, как изменения затронут миграции, биллинг, права доступа или что-то, что может заблокировать пользователей или списать неправильную сумму.

Такой раздел сохраняет скорость там, где это безопасно, и добавляет трение там, где оно оправдано. Цель не в том, чтобы запретить ИИ. Цель — остановить слепое доверие.

Процесс ревью может остаться простым:

1. Используйте ИИ для черновика, вспомогательных функций, тест-кейсов или пробной реализации.
2. Если изменение затрагивает защищенный участок, оставьте его как patch для ревью, а не как прямое редактирование.
3. Назначенный ревьюер должен прочитать логику до того, как кто-то начнет спорить о стиле.
4. Запускайте тесты, которые соответствуют риску, а не только самой функции.

Эти тесты должны отражать реальные сценарии отказа. Для миграций используйте копию реальных данных или seed-данные, похожие на production. Для ценообразования проверяйте округление, скидки, налоги, кредиты и пропорциональный расчет. Для правил доступа проверяйте и разрешенные, и запрещенные действия для каждой роли. Потом зафиксируйте, кто проверил изменение и кто его утвердил.

Назначенный ревьюер важнее, чем кажется. Если никто не хочет ставить свое имя под изменением в ценах или правах доступа, команде стоит остановиться. Обычно это значит, что код все еще неясен, тесты слабые или изменение слишком большое.

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

Команды, которые работают так, все равно двигаются быстро. ИИ берет на себя скучные части. Люди сохраняют контроль над рискованными решениями.

Реалистичный пример с логикой биллинга

Небольшая SaaS-команда хочет запустить годовые планы до следующего квартала. Они добавляют новую скидку 15% для клиентов, которые переходят с месячной оплаты на годовую.

Изменение звучит просто, поэтому они просят инструмент ИИ обновить логику checkout, предпросмотр счета и настройки промо в админке. Сгенерированный код выглядит аккуратно. Тесты проходят. Ничего не падает.

Проблема скрыта в старом правиле купона, которое модель не до конца учла. В продукте уже есть старый купон на «$100 off annual» из прошлой кампании, и этот купон никогда не должен сочетаться ни с одной процентной скидкой.

ИИ меняет функцию ценообразования и оставляет старую проверку купона, но переносит ее слишком поздно в поток. Теперь checkout сначала применяет новую годовую скидку 15%, а потом все еще разрешает фиксированный купон. Тариф, который должен стоить $490 при одной скидке, в итоге оказывается заметно дешевле, чем хотела команда.

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

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

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

Несоответствие становится очевидным:

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

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

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

Частые ошибки команд

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

Одна частая ошибка — доверять зеленым тестам, которые покрывают только легкие случаи. Правило цены может пройти все тесты и все равно списывать неправильную сумму, когда скидка заканчивается в полночь, клиент меняет план посреди биллингового цикла или возврат пересекается с налоговой логикой. Отчет говорит «pass». Клиент видит баг.

Время тоже создает проблемы. Команды позволяют ИИ редактировать миграцию базы данных поздно в пятницу, потому что дифф выглядит маленьким и легко мержится. Но и короткая миграция может заблокировать таблицу, удалить колонку слишком рано или сломать код, который все еще ожидает старую схему. Пятница — плохое время, чтобы выяснять, что вам нужен ручной ремонт.

Еще одна проблема — скорость ревью. Сгенерированный код часто выглядит аккуратнее, чем торопливый человеческий код. Имена переменных красивые. Комментарии звучат уверенно. Ревьюеры пробегают глазами, потому что ничего не выглядит грязным. Именно тогда ошибки и проскакивают. Чистый код все равно может скрывать плохое значение по умолчанию, пропущенную проверку на null или тихое изменение бизнес-правил.

Команды также относятся к проверкам прав как к обычной логике приложения. Это опасно. Одно слабое условие может превратить «пользователь может видеть свой счет» в «пользователь может видеть любой счет, если угадает ID». Модели часто копируют широкие шаблоны, а код с правами доступа наказывает за широкие шаблоны особенно жестко.

Для работы с базой нужен план отката до того, как кто-то нажмет merge. Если команда не может ответить на вопрос «как мы отменим это без потери данных?», значит, она еще не готова выпускать изменение. Обратимая миграция, резервная копия или поэтапный релиз кажутся медленными. Но потом они экономят очень много боли.

Сигналы тревоги обычно очевидны:

• ревьюеры тратят меньше времени на изменения в биллинге или правах, чем на визуальные правки
• миграции выходят без проверенного шага отката
• команды мержат мелкие пятничные правки базы, потому что они кажутся безобидными
• тесты не ловят крайние случаи с датами, повторными попытками, частичными сбоями и областью доступа
• люди считают, что читаемый код — это безопасный код

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

Быстрая проверка перед merge

Последние пять минут перед merge очень важны. Если изменение затрагивает деньги, идентичность или сохраненные данные, беглого взгляда недостаточно. Кто-то в команде должен остановиться и ответить на несколько простых вопросов.

Если изменение может создать плохие записи, списать неверную сумму или открыть не ту дверь, считайте его чувствительным, даже если дифф выглядит маленьким.

• Меняет ли оно схемы, миграции, значения по умолчанию или то, как читаются старые записи?
• Влияет ли оно на цену, налог, скидки, кредиты, пропорциональный расчет или итог счета?
• Затрагивает ли оно роли, проверки прав, API-токены, пароли, логику сессий или секреты?
• Был ли один назначенный ревьюер, который вел проверку от начала до конца?
• Реален ли rollback, а не только теоретически?

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

Для этого не нужен тяжелый процесс. Один ревьюер, один короткий чек-лист и одна заметка об откате могут поймать большинство плохих merge. Команды, которые быстро работают с ИИ, обычно нуждаются в этом не меньше, а больше, потому что код приходит быстро и выглядит чисто даже тогда, когда поведение неверно.

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

Следующие шаги для более безопасного процесса AI-разработки

Большинству команд не нужен большой framework. Им нужна одна страница, где написано, где ИИ может писать свободно, где только делает черновик, а где управление переходит человеку. Понятные границы снимают споры во время code review и экономят время, когда давление растет.

Начните с трех областей, которые причиняют больше всего вреда, когда ломаются: миграции базы данных, логика ценообразования и проверки безопасности. Плохая подсказка для интерфейса просто раздражает пользователей. Плохая миграция может заблокировать таблицу, удалить данные или превратить быстрый deploy в аварию с восстановлением. Маленький баг в цене может утекать выручку неделями. Слабая проверка прав может открыть данные клиентов уже днем.

Напишите первую политику

Сделайте ее достаточно короткой, чтобы каждый инженер мог запомнить. Первая версия может быть такой:

• ИИ может предлагать изменения в более безопасных областях, например в тексте интерфейса, тестах и внутренних инструментах.
• ИИ может делать черновики кода для миграций, ценообразования и путей безопасности, но человек проверяет каждую строку до merge.
• Два человека проверяют любое изменение, которое затрагивает деньги, контроль доступа, секреты или изменения схемы.
• В pull request должны быть описаны риск, шаги отката и то, что команда протестировала.

Обычно это работает лучше, чем добавлять еще одного ассистента, плагин или библиотеку промптов. Инструменты не исправляют слабые привычки ревью. Это делают правила.

Сначала настройте путь проверки, а уже потом расширяйте использование ИИ. Если команда добавит больше моделей и агентов без правил ревью, скорость сначала вырастет, а потом появится сожаление. Начните с малого, поработайте по политике пару недель, а потом уточните формулировки там, где люди запутались.

Полезно и простое правило ответственности: за каждый рискованный участок отвечает один инженер. Этот человек не блокирует работу, но следит за тем, чтобы стандарт оставался понятным. В небольшой компании это может быть tech lead или founder. В растущей команде — тот, кто лучше всех знает биллинг, auth или изменения данных.

Если небольшой команде нужна помощь в настройке таких ограничителей, Oleg Sotnikov на oleg.is работает со стартапами как временный CTO и советник по архитектуре, инфраструктуре и практичной AI-first разработке. Внешний взгляд часто полезен, когда команда хочет двигаться быстрее, не снижая планку.

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