Самая опасная версия разработки с AI — не та, что падает громко. А та, что добирается до зелёного CI, тихо обесценив само слово «зелёный».
Гнать до зелёного
Система продолжает править файлы, пока тесты не перестанут жаловаться.
- тесты ослабляются почти случайно
- дизайн начинает плыть
- diff становится всё труднее ревьюить
Дисциплинированный цикл исправлений
Команда сначала понимает, где именно разошлись ожидание и факт.
- код, тесты и документация сводятся осознанно
- изменения остаются обратимыми
- зелёный CI по-прежнему что-то значит
1. Зелёное состояние — это состояние доверия
Репозиторий действительно зелёный, когда:
- код собирается
- тестам можно верить
- контракты всё ещё означают то, что команда думает
- правка достаточно понятна, чтобы её потом можно было взять на себя
Именно поэтому формула «все проверки прошли» необходима, но всё равно недостаточна.
AI-инструмент умеет довести тесты до проходящего состояния очень разными способами. Полезны не все.
2. Первая диагностика важнее четвёртого патча
Когда изменение ломает тесты, обычно есть три варианта:
- сломан рабочий код
- сломан тест
- оба слоя уже разошлись с тем, как система должна себя вести
Эта мысль не выглядит новой. Именно здесь чаще всего и разваливаются циклы исправлений с AI.
Модель хорошо предлагает патчи. Гораздо хуже она сама по себе определяет, какой слой надо двигать, если исходный замысел нигде явно не зафиксирован.
Поэтому цикл исправлений должен начинаться с диагностики:
- какое поведение ожидалось
- какой файл выражает это ожидание достовернее всего
- это ошибка логики, контракта, окружения или устаревшей тестовой гипотезы
Если этот шаг пропустить, агент начинает договариваться с тестами вместо того, чтобы чинить систему.
3. Небольшие правки — это не эстетика, а способ держать систему под контролем
Если фикс сразу трогает слишком много файлов, резко падает качество ревью и почти всегда ухудшается диагностика.
В разработке с AI это особенно чувствительно: модель умеет генерировать широкие «правдоподобные» правки быстрее, чем человек успевает их осмыслить.
Поэтому я предпочитаю такой ритм:
- воспроизвести падение
- локализовать причину
- поправить один слой
- сразу прогнать проверки
- идти дальше только если реально устранён сам класс ошибки
На бумаге это выглядит медленнее. На практике это часто быстрее, потому что не приходится весь вечер распутывать патч на четырнадцать файлов, который убрал два симптома и породил ещё пять.
4. Тесты не священны, но и не одноразовые
Нет ничего умного в том, чтобы держать сломанный тест из принципа.
И точно так же нет ничего дисциплинированного в том, чтобы удалять или ослаблять тест только потому, что он мешает двигаться.
Здоровый критерий такой:
- меняем тест, если он описывает поведение, которое системе больше не нужно
- меняем код, если тест правильно фиксирует ожидаемый контракт
- меняем оба слоя только тогда, когда дизайн успел измениться, а ни тест, ни код уже не отражают его целиком
Речь не о том, чтобы защищать тесты эмоционально. Речь о том, чтобы тестовый набор оставался внятным контрактом.
5. AI помогает больше всего там, где уже есть структура
AI-инструменты сильнее всего в задачах с локальной структурой:
- шаблонный код
- повторяющиеся рефакторинги
- заготовки для тестов
- механика миграций
- очевидные правки на согласованность
Слабее всего они там, где работа в основном состоит из инженерного суждения:
- выбрать контракт
- решить, какой компромисс здесь правильный
- определить путь отката
- договориться, что вообще считать завершённой работой
Это не значит, что модель тут бесполезна. Это значит, что рамку по-прежнему держит инженер.
6. Быстрая обратная связь лучше одной героической сессии исправлений
Исследования про разработку уже много лет повторяют примерно одно и то же: маленькие изменения и быстрый цикл обратной связи здоровее больших залпов.
AI это не отменяет. Скорее усиливает.
Когда генерация стала дешёвой, появляется соблазн отложить инженерное суждение. Полезнее сделать наоборот:
- раньше запускать проверки
- раньше падать
- раньше сужать задачу
- раньше откатываться, если нужно
AI может ускорить движение. Но он не делает проверку необязательной.
7. Обратимость — часть дизайна
Хороший процесс с AI делает откат не героизмом, а нормальной опцией.
Это значит:
- сначала добавляющие изменения, потом ломающие старую форму
- понятные границы ответственности по файлам
- ясные границы коммитов
- без смешивания разных целей в одной правке
- возможность откатить один шаг, не уничтожая весь сеанс работы
Кодовая база не должна потом вызывать медиума, чтобы понять, что произошло.
8. Код, написанный с AI, всё равно наследует обычную инженерную ответственность
Системе безразлично, откуда пришла регрессия: от человека, от code model или от слишком бодрого вечера.
Позже имеет значение другое:
- кто отвечает за сценарий поломки
- достаточно ли хороши логи
- сохранился ли контракт читаемым
- можно ли нормально откатиться
Именно поэтому мне до сих пор близка human-in-the-loop модель. Не потому, что модель слаба. А потому, что ответственности всё ещё нужен адрес.
9. Нормальный путь к зелёному CI
Если нужен рабочий стандарт для исправлений с AI, я бы держался примерно такого контура:
- воспроизвести падение
- диагностировать: код, тест или дрейф замысла
- поправить самый маленький правдоподобный слой
- сразу прогнать type-check и тесты
- остановиться, когда правку уже трудно ревьюить
- остаток работы вынести отдельно, а не добивать всё одним широким патчем
Это не самый кинематографичный процесс. Зато ему можно доверять.
Что я бы просто запретил
Есть несколько анти-паттернов, которые лучше назвать прямо:
- удалять тесты без явного объяснения
- мёржить широкие рефакторинги, сгенерированные AI, которые никто не может объяснить
- менять код и тесты одновременно, не проговорив, какой слой был неправ
- считать зелёный CI доказательством того, что система теперь стала здоровее
Зелёные тесты — это хорошая новость. Но это ещё не мировоззрение.