От скорости агента к скорости системы
Александр Поломодов начинает с вопроса о нагрузке, которую создаёт множество параллельных агентов. Каждый из них не только потребляет токены: ему нужна копия кода, среда, сохранение результатов и проверки. Опыт больших лабораторий интересен как источник инженерных приёмов, хотя их доступ к вычислениям и возможность экспериментировать отличаются от условий большинства команд.
Алексей Литвинов описывает напряжение внутри команды, когда один инженер создаёт изменений больше, чем соседние участники успевают обработать. Евгений Сергеев отмечает, что нагрузку от агентов сложнее предсказать по числу сотрудников: одна задача может породить несколько параллельных рабочих копий. Ускорение генерации кода переносит ограничение на хранение, CI, ревью и принятие изменений.
Параллельная работа и очереди
Несколько агентов могут одновременно исправлять одну проблему или менять связанные части системы. Пессимистический подход заранее ограничивает доступ к области работы; оптимистический допускает параллельные изменения и разрешает конфликты позже. Но синтаксически совместимые изменения ещё не обязательно совместимы по смыслу: они способны нарушить общее бизнес-правило, которое нигде не было явно записано.
Ведущие обсуждают очереди задач, проверок и слияния как способ управлять потоком. Очередь помогает дозировать работу, но сама может стать узким местом. Евгений рассказывает и об очереди входящих запросов от агентов: человек собирает вопросы и результаты в одном месте и отвечает в собственном темпе, сокращая число вынужденных переключений контекста.
Александр проводит аналогию с координацией большой организации: один центральный координатор не обязательно выдержит рост потока. Иерархия распределяет работу, но, как замечает Алексей, роли на разных уровнях не одинаковы. Простого добавления ещё одного агента-руководителя недостаточно: нужно проектировать обязанности и время жизни таких участников.
Ревью и проверка результата
Евгений пересказывает обсуждение с инженерными командами: число подготовленных изменений растёт, однако ценность может не доходить до пользователей быстрее, если пул-реквесты ожидают проверки. Ревью, первоначально служившее и обмену знаниями, превращается также в механизм упорядочивания потока. При этом участники не считают, что у индустрии уже есть универсальная замена этой стадии.
Один вариант — классифицировать изменения по риску и автоматизировать рутинные решения. Евгений приводит пример эксперимента с небольшими обновлениями зависимостей: если автоматические проверки и ревью проходят, часть изменений можно сливать без человека. Критичность затронутой системы и последствия ошибки должны влиять на решение; зелёный CI сам по себе не объясняет, подходит ли новое поведение пользователю.
Другой подход переносит часть проверок после слияния или опирается на наблюдаемость в production. Он повышает пропускную способность ценой необходимости обнаруживать и исправлять сбои. Алексей отдельно подчёркивает трудность проверки нового поведения и интерфейса. Даже если код появляется быстро, для оценки реакции пользователей нужно накопить достаточно данных: обратная связь реального мира ограничивает темп изменений.
Инструменты под собственный поток
Ведущие обсуждают Scion от Anthropic как пример инфраструктуры, спроектированной под поток изменений агентов. Александр описывает хранение метаданных изменений в распределённой базе и содержимого в объектном хранилище, а также необходимость сохранять связи между изменениями. Важно не только записать результат, но и понять, от каких предыдущих изменений он зависит и как объединён с другими.
Эта архитектура отражает конкретный выбор: дать агентам работать параллельно и выполнять часть проверок после объединения. Участники не предлагают каждой команде писать собственную систему контроля версий. Их интересуют переносимые принципы и компромиссы; масштаб лаборатории и её внутренние задачи могут не совпадать с задачами слушателя.
Евгений приводит Symphony как другой способ координации: агент берёт работу из трекера, а человек рассматривает результат и подтверждения вокруг задачи. Его заинтересовала публикация не только реализации, но и спецификации, которую команда может адаптировать к своей среде. Это переносит часть обсуждения с конкретного кода на описание желаемой системы.
Циклы обратной связи
Александр описывает внутренний цикл агента: изменение, запуск приложения, логи и метрики, статические проверки и тесты; при ошибке агент возвращается к исправлению. После подготовки изменения подключается человек. Если на ревью обнаружилась повторяющаяся ошибка процесса, её можно выразить как правило, тест или автоматическую проверку, чтобы не расходовать внимание на одно и то же замечание снова.
Такая автоматизация полезна лишь тогда, когда правило действительно проверяет нужное свойство. Линтер не заменяет смысловую оценку, а результаты тестов зависят от того, какие сценарии в них представлены. Ведущие связывают локальные циклы агента с более длинной петлёй: наблюдение за поведением системы и пользователей помогает менять сами проверки и способ работы.
Полномочия и границы
При обсуждении доступа участники отмечают соблазн выдать агенту широкие права ради непрерывной работы. Но удобство не устраняет вопрос о том, какие действия допустимы и как ограничить ущерб. Александр приводит пример облачной среды, где секреты не передаются непосредственно агенту, а нужные данные подставляются посредником при разрешённом обращении.
Изоляция среды, правила доступа и проверки образуют несколько слоёв защиты. Каждый слой имеет пределы: модель может ошибиться, а инструменты и среда — содержать уязвимости. Поэтому обсуждение полномочий связано не только с доверием к модели, но и с тем, какие операции доступны, как их наблюдают и что произойдёт при ошибке.
Стоимость принятого изменения
В конце разговора участники возвращаются к экономике. Цена не заканчивается расходом токенов на первую попытку: к ней добавляются повторные запуски, машинное ревью, CI, работа человека и возможное исправление после выпуска. Александр предлагает связывать эти расходы с конкретным принятым изменением, чтобы сравнивать варианты на общей основе.
Евгений замечает, что затраты на AI становятся дополнительной строкой бюджета команды, а оценить ценность каждого изменения трудно. Алексей предлагает смотреть на показатели поставки и высвобождённую ёмкость, но подчёркивает организационный вопрос: руководству нужно понимать, зачем выросли расходы. Участники рассматривают измерение как незавершённую задачу, а не обещают готовую формулу окупаемости.
Главные выводы
- Рост числа изменений переносит узкое место на проверку, интеграцию и получение обратной связи от пользователей.
- Очереди и явные правила помогают управлять параллельной работой, но сами требуют контроля пропускной способности.
- Разграничивайте права агентов и выбирайте глубину проверки с учётом последствий ошибки.