Контроль AI-generated кода в прикладной разработке
AI ускоряет написание кода, но не принимает ответственность за поведение системы. Поэтому полезно разделять скорость генерации и инженерный контроль.
В моём процессе AI-assisted разработка означает, что модель помогает исследовать кодовую базу, формировать изменения и выполнять рутинные операции. Архитектурные решения, границы задачи, критерии приёмки и финальная проверка остаются зоной ответственности инженера.
Сначала контракт, затем генерация
Перед изменением кода фиксируются четыре вещи:
- какой пользовательский или операционный сценарий меняется;
- какие модули и данные затрагиваются;
- что считается успешным результатом;
- какие регрессии недопустимы.
Без этого модель оптимизирует локальный фрагмент и легко создаёт несовместимость на соседнем слое.
Для интеграционной задачи контракт может включать формат входных данных, idempotency, timeout, retry, журналирование и поведение при частичном отказе. Для интерфейса — состояния загрузки, пустого результата, ошибки, клавиатурную навигацию и mobile layout.
Repo truth важнее предположений
Перед правкой нужно прочитать действующие схемы, маршруты, тесты, конфигурацию и инструкции репозитория. AI особенно склонен достраивать отсутствующий контекст знакомыми шаблонами.
Практическое правило простое: если утверждение можно проверить в коде, конфигурации, логах или рабочем интерфейсе, его не нужно угадывать.
Это относится и к аудиту. Замечание без доказательства создаёт шум; подтверждённая проблема должна иметь конкретный источник и воспроизводимый сценарий.
Маленький diff проще проверить
AI может быстро развернуть большой рефакторинг, но размер изменения напрямую влияет на стоимость проверки. Поэтому рабочий цикл строится вокруг минимального безопасного diff:
- не менять имена и структуру без необходимости;
- не исправлять соседние проблемы в том же изменении;
- не добавлять абстракцию, если текущий контракт решается проще;
- сохранять существующие conventions проекта.
Небольшой diff легче прочитать, протестировать и откатить.
Проверка по слоям
После реализации проверка идёт от узкого сценария к широкому.
Статическая проверка
Типы, линтер, schema validation и сборка ловят несовместимые импорты, ошибки контрактов и проблемы генерации страниц.
Тесты изменённой логики
Сначала запускаются тесты ближайшего модуля. Если изменение связано с API или данными, проверяются позитивный и негативный сценарии.
Интеграционный путь
Важно проверить не функцию отдельно, а проход данных через реальные слои: интерфейс, API, очередь, базу, внешний сервис и обратно.
Визуальный и browser QA
Для пользовательских экранов нужны реальные viewport, клавиатурная навигация, console errors, responsive layout и основные CTA.
Release gate
Перед выпуском выполняется заранее определённый набор команд и smoke-сценариев. Он должен быть воспроизводимым, а не зависеть от памяти разработчика.
Что нельзя делегировать модели
Модель не должна самостоятельно определять приемлемый бизнес-риск. Инженер проверяет корректность доступа к данным, работу с секретами и персональными данными, финансовую логику, миграции и соответствие результата реальному процессу пользователя.
AI полезен как ускоритель исполнения. Качество появляется из архитектурных ограничений, наблюдаемого результата и дисциплины проверки.
Критерий завершения
Изменение закончено не тогда, когда код сгенерирован, а когда выполнен согласованный сценарий, пройдены проверки и зафиксированы оставшиеся ограничения.
Такой подход позволяет использовать скорость AI без подмены инженерной ответственности.