|
Professor Seleznov
|
С интересом наблюдаю, как инженерные процессы и инструменты, к которым мы привыкли за десятки лет, переосмысливаются под ИИ-нативный подход. Например, классический CI/CD, построенный вокруг pull request-ов и человеческого темпа разработки, плохо подходит для мира, где код всё чаще пишут агенты.
До работы с агентами цикл разработки выглядел так: человек медленно пишет код → оформляет PR → CI прогоняет линтеры, тесты и сборку → другой человек ревьюит изменения → изменения попадают в основную ветку.
В такой парадигме долгое время работы CI-пайплайна часто было ожидаемым и терпимым, потому что самая большая задержка всё равно была на стороне команды: разработчик писал код часами или днями, ревью тоже ждали часами или днями, PR жил долго.
С агентами всё меняется: код генерируется быстро и относительно дёшево → задач становится больше → ветки с изменениями плодятся быстрее → PR становится слишком медленной и неудобной единицей работы → валидацию изменений нужно двигать внутрь агентного цикла.
Но CI/CD вряд ли не исчезает. Скорее он перестанет быть контуром вокруг которого происходит работа с изменениями и превратится в низкоуровневый слой для быстрой проверки изменений внутри агентного цикла. Почему так?
CI/CD в текущем виде был спроектирован для мира, где человек — главный агент.
Человек держит в голове некое намерение: например, «хочу добавить кнопку оформления заказа». Потом проходит цикл: намерение → код → pull request → CI → код-ревью → merge. На каждом этапе может быть откат назад:
- PR не по принятому формату → назад к коду
- тесты упали → назад к коду
- ревьюер попросил изменить API → назад к коду
- merge queue показывает, что ветка отстаёт от main → назад к коду
Это уже агентный цикл, просто раньше агентом был человек. И в этом цикле роль harness-а (упряжки для агента) тоже выполнял человек: разработчик сам фокусировался на цели, писал код, запускал проверки, обрабатывал обратную связь от коллег и инструментов и доводил изменение до слияния.
Когда код пишет не человек, а агент, меняются масштабы:
- много агентов могут параллельно выполнять работу
- появляется много короткоживущих веток
- растёт количество PR
- частые исправления становятся нормальной частью агентного цикла
Проблема не только в том, что CI в такой парадигме будет медленным. Проблема в том, что сам процесс слияния изменений становится бутылочным горлышком.
Если сравнить git с журналом изменений, то все сгенерированные агентами изменения должны попасть в него последовательно. Это начинает напоминать проблему из мира баз данных: транзакции, блокировки, порядок применения изменений (пресловутый serializable). Когда людей мало и они работают медленно, окно для слияния изменений может быть долгим по времени. Когда агенты генерируют пачки изменений параллельно, основная ветка постоянно обновляется, и шанс, что рабочая ветка быстро устареет, резко возрастает.
Сейчас, когда кодинговые агенты всё больше становятся привычным инструментом для команд, цикл разработки трансформируется примерно в такую схему:
Цель + план
↓
Агентный цикл:
генерация кода
внутренняя валидация: сборка, тесты, линтеры
внешняя валидация: человек или специализированные агенты
исправления по обратной связи
↓
Merge Queue
↓
Репозиторий
Кажется, следующим шагом будет сокращение участия человека внутри быстрого агентного цикла. То есть разработчику уже не придётся смотреть каждую итерацию изменений и каждый PR. Для этого появятся специализированные агенты. Можно легко представить такую агентную команду:
- основной кодинговый агент
- агент-ревьюер по безопасности
- агент-ревьюер по производительности
- агент-тестировщик
- агент-архитектор
- агент, оценивающий функциональную корректность реализации по требованиям
Человеку уже не нужно будет читать каждый diff, как это было раньше. Он будет смотреть на более высокий уровень:
- была такая цель
- вот что получилось
- вот summary изменений
- вот результат security-проверок
- вот риски
- вот демонстрация работы
И только после этого принимать решение: approve, reject или «нужны правки».
Также ставлю на то, что изменится сама концепция merge queue. Обычной очереди на слияние изменений будет недостаточно. Если много агентов параллельно меняют один и тот же код, системе придётся не просто запускать тесты перед merge, а группировать изменения, разрешать конфликты, проверять совместимость и выстраивать безопасный порядок применения.
Изменятся и окружения для агентных проверок. Они станут более stateful: с заранее подготовленными зависимостями, прогретыми кэшами, локальным контекстом и сохранённым состоянием между итерациями. Иначе агентный цикл будет слишком медленным.
В итоге мы получим не просто CI job после git push, а что-то ближе к continuous compute: вычислительную среду, которая постоянно работает вокруг intent-а, кода, валидации и изменений-кандидатов на слияние с основной веткой.-P.S. Пишу про прикладную ИИ разработку у себя в канале и блоге.-Источник
|
