AI-код под контролем

Когда использовать

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

Материал нужен, когда:

• AI помогает писать или менять код;
• команда ускоряет миграцию, cleanup или типовые правки;
• разработчик приносит большой AI-generated diff на review;
• тимлид хочет разрешить AI без потери качества;
• есть спор: “если тесты зеленые, значит можно мержить?”;
• изменение попадет в production, а не останется локальным экспериментом.

Главная граница

AI может быть участником работы. Владельцем результата остается человек и команда.

Перед merge нужно уметь ответить:

Кто понимает это изменение, кто проверил риск и кто будет владеть последствиями
после релиза?

Если ответ звучит как “AI предложил”, изменение еще не готово. Если человек может объяснить намерение, ограничения, тесты, риски и rollback, AI был инструментом, а не источником ответственности.

1. Разделить тип AI-работы

Не весь AI-код одинаково рискованный.

Чем ближе изменение к данным, безопасности, совместимости и эксплуатации, тем меньше подходит аргумент “AI ускорил”.

2. Назвать lasting code

Полезно отделить временную помощь от кода, который останется жить.

Lasting code - это код, который:

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

Если AI помог написать lasting code, review должен проверять не только стиль, но и владение:

• автор понимает доменный смысл изменения;
• есть критерии, которые изменение должно выполнить;
• тесты защищают важный сценарий;
• edge cases названы явно;
• ограничения первой версии записаны;
• есть сигнал, по которому команда увидит проблему после релиза.

3. Привязать AI-код к задаче, а не к диффу

Большой diff может выглядеть убедительно, но задача команды не “принять код”. Задача - получить проверяемое изменение.

Перед review стоит приложить короткий контекст:

Что меняем:
Какой сценарий должен заработать:
Что не входит:
Где AI помог:
Что автор проверил сам:
Какие риски остаются:
Какие тесты или smoke-check защищают изменение:

Эта форма не нужна для каждого маленького изменения. Она нужна, когда AI существенно расширил объем diff или затронул зону, где ошибка дорогая.

4. Определить, где человек в петле обязателен

Человек должен оставаться в петле, если изменение:

• выбирает архитектурную границу;
• меняет контракт API или формат данных;
• касается авторизации, персональных данных, логов или секретов;
• меняет обработку ошибок, повторов, статусов или ручных сценариев;
• влияет на backward compatibility;
• переносит данные или меняет схему;
• ускоряет delivery ценой технического долга;
• требует объяснения владельцу продукта, эксплуатации или соседней команде.

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

5. Использовать review как проверку владения

Для AI-generated кода review должен отвечать на вопросы:

• автор может объяснить, почему код устроен именно так;
• замечания привязаны к риску, тестируемости, поддержке или договоренности;
• нет лишней сложности, которую никто не будет поддерживать;
• нет “магического” кода, который работает только потому, что прошел один сценарий;
• тесты написаны не под реализацию, а под ожидаемое поведение;
• ошибка будет видна после deploy.

Если автор не может объяснить фрагмент, его нельзя защищать фразой “так сгенерировалось”. Код должен стать командным знанием до merge.

6. Не путать скорость с готовностью

AI может резко сократить время до первого рабочего варианта. Но delivery заканчивается не на первом варианте.

Нужно проверить:

• что изменение делает нужную работу;
• что важные NFR не потерялись;
• что тесты и smoke-check действительно ловят поломку;
• что release-readiness названа до deploy;
• что откат или forward-fix понятен;
• что после релиза есть первый сигнал результата.

Если этих проверок нет, AI ускорил не delivery, а появление непроверенного изменения.

Шаблон AI-code проверки

Изменение:
Какой сценарий или риск закрываем.

Роль AI:
Черновик / рефакторинг / тесты / миграция / поиск вариантов / объяснение.

Lasting code:
Что останется в системе после merge.

Человек-владелец:
Кто понимает изменение и отвечает за последствия.

Проверки:
Тесты:
Preview или тестовый контур:
Smoke-check:
Наблюдаемость:

Риски:
Данные:
Безопасность:
Совместимость:
Поддержка:

Решение:
Что нужно зафиксировать отдельно, если риск или trade-off важен.

Пример

Слабая формулировка:

AI переписал обработку ошибок, тесты проходят.

Лучше:

AI помог набросать новый разбор ошибок внешнего API. Автор вручную сверил
статусы с контрактом, добавил тесты на retryable и non-retryable ошибки,
проверил маскирование payload в логах и оставил decision record о том, какие
ошибки не повторяем автоматически.

Во втором варианте видно не то, что AI написал код. Видно, что команда владеет последствиями.

Антипаттерны

Стоит остановиться, если:

• AI-generated diff большой, а задача не объясняет сценарий;
• автор не может рассказать, зачем нужен фрагмент кода;
• тесты проверяют только happy path;
• review обсуждает стиль, но не обсуждает риск;
• код меняет данные или безопасность без отдельной проверки;
• команда принимает архитектурное решение внутри PR без decision record;
• “быстро получилось” используется как аргумент против smoke-check;
• после релиза непонятно, как увидеть проблему.

Хорошая AI-assisted разработка не отменяет инженерную ответственность. Она делает черновик дешевле, но не делает владение, проверку и последствия автоматическими.