Агенты пишут быстрее, чем мы успеваем принимать изменения

19 октября 2026 · 5 минут чтения

Агент быстро подготовил правку. Пока она ждала проверки, основная версия изменилась — и часть работы пришлось повторить. Когда очередь растёт, быстрее писать код уже недостаточно: нужно менять процесс принятия и выпуска изменений.

Что начинает тормозить

Четыре возможных узких места:

• Служебные операции. Каждый агент создаёт ветку — отдельную линию изменений, оформляет запрос на включение правки (PR) и следит за статусами.
• Несовместимые предположения. Правки успешно объединяются, но вместе ломают поведение.
• Повторные проверки. Автоматическая сборка и тесты многократно выполняют одинаковую работу.
• Внимание человека. Поток построчных сравнений, или diff, превышает возможности ревью — проверки предложенных изменений.

Условный пример: один агент переводит цену из рублей в копейки. Другой добавляет скидку в сто рублей, вычитая число 100. Файлы разные, текстового конфликта нет. После объединения скидка составляет один рубль.

Git не требует PR, ручного одобрения или всех тестов после каждой правки. Прежде чем менять систему контроля версий, нужно измерить задержки: количество агентов само по себе не доказывает наличия очереди.

Что показывает история Anthropic

По данным Anthropic, поток вырос примерно с 2500 до более чем 30 000 вливаемых изменений в день. Компания перешла с Git на Scion: операции выполняет сервер, клиенты получают данные по требованию. Это пример адаптации к нагрузке; совместимость поведения новая система хранения сама по себе не обеспечивает.

Шесть направлений решения

Это авторская карта подходов разных уровней. Их можно сочетать; эффективность сочетания ещё предстоит измерить.

1. Сервис изменений поверх Git

Агент предлагает правки через программный интерфейс. Сервис управляет изолированными рабочими копиями, проверками и интеграцией, Git хранит историю.

Координатор централизует повторяющиеся действия и восстановление после сбоев. Но новый интерфейс сам по себе ничего не ускоряет. Собственный сервис оправдан, если готовая очередь интеграции и автоматизация платформы не устраняют измеренную задержку.

2. Маленькие изменения, пакетные проверки

Задачи остаются небольшими, дорогие совместные проверки выполняются для неизменяемого кандидата выпуска — точного набора версий кода и зависимостей. Новые правки идут в следующий пакет. Выпускается проверенный артефакт.

Кеш сохраняет результаты воспроизводимых действий, пакетирование объединяет запуски. Кеш должен учитывать значимые входы и окружение, включая состояние внешних сервисов. Большие пакеты увеличивают ожидание и усложняют поиск ошибки, которую может вызывать сочетание правок.

3. Транзакции над структурой программы

Абстрактное синтаксическое дерево (AST) представляет функции, параметры и вызовы как узлы программы. Агент предлагает добавить параметр и обновить вызовы. Сервер применяет их как транзакцию — целиком либо никак.

Нужно проверять версии изменённых сущностей и заявленных зависимостей: в примере с ценой — контракт единиц измерения. Полноту зависимостей механизм не гарантирует; структура и типы не доказывают правильность поведения.

Начать можно с переименования. Тело функции по-прежнему передавать текстом: генерировать весь AST необязательно.

4. Совместная модель с CRDT

Бесконфликтные реплицируемые типы данных (CRDT) позволяют независимым копиям сходиться при объединении изменений. Такие структуры предоставляет Yjs.

Сходимость данных не означает правильности программы. Сохранение конкурирующих реализаций и выбор принятой требуют отдельной политики. CRDT стоит проверять, когда нужны независимые реплики; при единственном сервере может хватить журнала транзакций.

5. База определений вместо файлов

Программу можно хранить как граф версий функций и зависимостей. В Unison определения идентифицируются хешами — вычисленными идентификаторами, имена хранятся отдельно. Обновление зависимости становится явным действием. Хеш фиксирует версию, но не доказывает эквивалентность поведения.

Переход затрагивает сборку, отладку и библиотеки. Я бы начал с языка для правил и расчётов, прежде чем переносить весь продукт.

6. Версии компонентов и манифест исполнения

Среда исполнения выбирает реализации по манифесту — записи точных версий компонентов. Совместимую функцию можно включить для части трафика, закрепляя согласованный набор версий на время запроса. Флаг функции — переключатель поведения — применим и в обычном проекте с Git.

Сложность — общее изменяемое состояние и миграции данных. Возврат прежнего кода не отменяет платёж или отправленное сообщение.

С чего начать

Выбрать одно узкое место и один эксперимент на ограниченном участке. Повторяются проверки — проверить кеш. Ошибки после переименований — структурную операцию. Правки ждут интеграции — настройку существующей очереди.

На сопоставимых задачах сравнить ожидание, время до использования правки в продукте, затраты вычислений и человека, дефекты за одинаковый период после выпуска. Ускорение ценой большего числа ошибок — не успех.

Для каждого изменения сохранять связку: цель → правка → доказательства → версия выпуска. Карточка ведёт к коду и проверкам; пересказ агента доказательством не считается. При рефакторинге — перестройке реализации без изменения поведения — подтверждаются сохранение контракта и заявленное улучшение.

Моя гипотеза: среда агентной разработки станет сервисом управления проверяемыми изменениями. Глубину перехода стоит выбирать по результатам эксперимента.

5 минут чтения

Автор: Данил Письменный · Дата: 19 октября 2026