Статья
Практический разбор: короткие циклы исправлений, небольшие правки, доверие к тестам и путь к зелёному CI без войны с кодовой базой.
Громкие падения — это легко. Опаснее версия с AI, в которой CI зеленеет, потому что команда тихо передоговорилась, что значит «зелёный».
AI нужен, чтобы сокращать путь к правильному изменению. Когда он начинает торговаться с реальностью, пора выключать.
Гнать до зелёного
Система продолжает править файлы, пока тесты не перестанут жаловаться.
Дисциплинированный цикл исправлений
Команда сначала понимает, где именно разошлись ожидание и факт.
Репозиторий зелёный, когда код собирается, тестам можно верить, контракты означают то, что команда думает, и правка достаточно понятна, чтобы её можно было взять на себя через квартал. «Все проверки прошли» — условие необходимое, не достаточное.
AI умеет довести тесты до прохода очень разными способами. Полезны не все. Остальные тихо размывают кодовую базу так, что никто не замечает до ноября.
Когда изменение ломает тесты, обычно три варианта. Сломан код. Сломан тест. Оба разошлись с задумкой. Не ново. И именно здесь разваливаются циклы исправлений с AI.
Модель хорошо предлагает патчи. Хуже определяет, какой слой надо двигать, если замысел нигде не зафиксирован. Поэтому цикл исправлений начинается с диагностики. Какое поведение ожидалось? Какой файл выражает это ожидание убедительнее? Это ошибка логики, контракта, окружения или устаревшей тестовой гипотезы?
Если этот шаг пропустить, агент начинает договариваться с тестами.
Если фикс трогает слишком много файлов, ревью падает, диагностика портится. С AI это острее. Модель генерирует «правдоподобные» широкие правки быстрее, чем человек успевает их осмыслить.
Ритм, который я предпочитаю:
На бумаге медленнее. На практике быстрее, потому что не приходится вечером распутывать патч на четырнадцать файлов, который убрал два симптома и породил ещё пять.
Нет ничего умного в том, чтобы держать сломанный тест из принципа, и ничего дисциплинированного в удалении теста, потому что он мешает.
Критерий простой. Меняем тест, если он описывает поведение, которое системе больше не нужно. Меняем код, если тест правильно фиксирует ожидаемый контракт. Меняем оба слоя, только когда дизайн уже изменился, а ни тест, ни код его не отражают.
Эмоциональная защита теста тут ни при чём. Цель — оставить набор контрактом, которому ещё можно верить.
Сильнее всего модель в задачах с локальной структурой. Шаблонный код. Повторяющиеся рефакторинги. Заготовки тестов. Механика миграций. Очевидные правки на согласованность.
Слабее там, где работа в основном — инженерное суждение. Выбрать контракт. Решить, какой компромисс верный. Определить путь отката. Договориться, что считать «готово».
Это не значит, что модель бесполезна. Рамку держит инженер.
Исследования DORA много лет говорят одно. Маленькие изменения и быстрый цикл обратной связи здоровее больших залпов. AI это не отменяет, только усиливает.
Когда генерация стала дешёвой, появляется соблазн отложить суждение. Полезнее наоборот. Раньше прогонять проверки, раньше падать, раньше сужать задачу, раньше откатываться. AI ускоряет движение и не делает проверку необязательной.
Откат должен быть не героизмом, а нормой. Сначала добавляющие изменения, потом ломающие старую форму. Понятные границы ответственности по файлам, ясные границы коммитов, без смешивания целей в одной правке, возможность откатить один шаг, не уничтожая сеанс.
По кодовой базе должно быть видно, что произошло во вторник вечером, без догадок.
Системе безразлично, откуда регрессия. От человека, от code model, от слишком бодрого вечера. Позже имеет значение другое. Кто отвечает за сценарий поломки. Достаточно ли хороши логи. Читается ли контракт. Можно ли откатиться.
Именно поэтому мне близка human-in-the-loop модель. Причина не в слабости модели, а в том, что ответственности нужен адрес.
Для исправлений с AI:
Не кинематографично. Тот, которому верю.
Зелёные тесты — хорошая новость. Не мировоззрение.
