Рабочий процесс AI-кодинга: критерии приёмки, автотесты и проверки CI

Главная проблема AI-кодинга не в том, что модель пишет слишком быстро. Проблема в том, что команды часто проверяют этот быстрый вывод самым медленным способом: уставший разработчик после генерации смотрит на большой diff глазами и пытается почувствовать контроль. Это выглядит ответственно, но слабее, чем короткий контракт приёмки, написанный до запуска ассистента.

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

Практический порядок такой: сначала work order, потом генерация. В нём должны быть цель, разрешённая область изменений, non-goals, критерии приёмки, негативные кейсы, команды проверки и условия остановки. Например, не “сделай JWT login”, а “оставь текущий hashing-сервис, не меняй схему без указанной миграции, отклоняй disabled users, ротируй refresh tokens, проверь replay, rate limit и audit events”. Такой запрос длиннее, зато снимает двусмысленность.

Именно к этому подталкивают современные инструменты. Материалы Anthropic по Claude Code говорят о контексте проекта, инструкциях репозитория и контролируемом запуске команд. Документация GitHub Copilot coding agent описывает работу от issue к pull request, журналы выполнения и человеческое утверждение. Руководства OpenAI по Codex и prompting подчёркивают цели, ограничения и проверку результата. Общий вывод простой: агенту нужна не просьба, а проверяемое задание.

Здесь есть культурная ловушка. В IT долго ценились видимые действия: печатать код, строго смотреть PR, оставлять замечания. А формулирование критериев выглядит как “бумажка”, хотя именно оно теперь часто и есть инженерная работа. Инвариант “заблокированный пользователь не может обновить токен через старую cookie” ценнее, чем ручное чтение helper-функции, которая этот случай пропустила.

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

Гейты должны быть исполняемыми. Unit-тесты ловят локальную логику, интеграционные тесты — границы, типизация и lint — рутину, security scan — типовые зависимости. Ручный чек-лист нужен для того, что машина видит хуже: продуктовый смысл, приватность, стоимость поддержки, миграционные последствия и возможность отката.

Безопасность нельзя оставлять “на потом”. В промпты легко попадают куски логов, production-похожие данные, секреты или внутренние правила. Команда должна понимать retention, обучение на данных, права инструмента и границы репозитория. В контракте стоит явно писать: не использовать реальные customer records, не добавлять телеметрию без review, не расширять permissions без причины, не вставлять secrets в примеры.

Кому это подходит? Командам, которые уже дают Copilot, Claude Code, Codex или похожим агентам реальные задачи: backend, auth, billing, внутренние панели, миграции, API. Кому лучше притормозить? Командам без тестов, без staging, без политики данных и без rollback. Для них первым AI-проектом должен стать не новый feature, а сама система проверки.

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

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

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

Минимальный шаблон можно хранить прямо в issue: цель, scope, запреты, критерии, негативные случаи, команды проверки, владелец review и rollback. Через несколько недель он становится общей привычкой. Новые участники быстрее понимают, что можно поручать агенту, а что требует архитектурного разговора. Старшие разработчики меньше тратят силы на косметику и больше — на реальные границы системы.