ИИ-агент может за минуты подготовить изменение, на которое у разработчика прежде уходил час. Но ускорение написания кода создаёт другую проблему: растёт нагрузка на проверку. Нужно изучить diff, понять предположения агента, проверить затронутые компоненты и убедиться, что решение соответствует задаче, а не просто проходит формальные проверки.
Почему агент выбрал этот модуль? Какие связанные части системы изучил? Какие варианты отбросил? На какие требования и результаты проверок опирался? Если этот контекст остаётся в закрытой сессии, следующему участнику процесса приходится собирать его заново.
В 2026 году эту проблему сформулировал Томас Домке, бывший CEO GitHub и основатель Entire. Она звучит так: «Узкое место при выпуске кода — это ревью кода, созданного агентами». Мы в «Первой Форме» к похожему выводу пришли через собственную практику. У нас ИИ-агенты работают внутри управляемого конвейера: задача получает проверяемые критерии, агенты действуют по ролям, результаты фиксируются в артефактах, а человек сохраняет за собой продуктовые решения, финальное ревью и мёрж. Расскажем подробнее.
Git хранит «что», но не «почему»
Обычный Git хорошо отвечает на вопрос, что изменилось в коде. Но в агентной разработке команде нужно понимать и другое: как агент исследовал задачу, какие ограничения обнаружил, какие проверки выполнил и почему выбрал конкретный вариант реализации.
Entire развивает эту идею через инструмент Checkpoints. Это open-source CLI, который сохраняет рабочий контекст агента в Git на служебной ветке: промпты, транскрипты, вызовы инструментов, прочитанные и изменённые файлы, решения и результаты проверок.
Формула Entire звучит так: «Код остаётся чистым. Рассуждения сохраняются рядом с ним».
Следующий шаг — shared agent memory: новая сессия получает результаты предыдущей работы, включая исследованные компоненты, ограничения и отвергнутые варианты.
Потребность понятна: контекст не должен исчезать вместе с окном терминала. Но в корпоративной разработке важно не только сохранить контекст, а сделать его удобным для ревью, безопасным для хранения и связанным с маршрутом задачи.
Сценарий — основной контейнер процесса в «Первой Форме»
В «Первой Форме» разработка строится вокруг сценария. Он хранит постановку, критерии приёмки, историю обсуждений, статусы, роли, связанные задания, результаты проверок и merge request.
Упрощённо сценарий проходит путь:
Backlog → сценарий с маршрутами и статусами → ожидание регресса → слияние в релиз → завершена.
Задания создаются как связанные подзадачи, а спринты используются для планирования. Они важны для процесса, но не являются последовательными стадиями маршрута сценария.
На дату подготовки материала в системе накоплено более 24 тысяч сценариев разработки. Встроенный Робот получает события GitLab и CI/CD и переводит сценарии по реальным условиям процесса: например, после создания MR запускается этап код-ревью, после одобрения — тестирование, после закрытия QA — тестирование заказчиком.
Критерии приёмки фиксируют ожидаемый результат и границы изменения: что должно появиться в интерфейсе, какие данные должны пересчитываться, какие пользовательские сценарии нельзя нарушить. Это общий ориентир для автора, ревьюеров, тестировщиков и владельца продукта.
Где в этом процессе появляются агенты
Не каждая задача должна автоматически уходить агенту. Сначала конвейер классифицирует её:
MR-ABLE — задачу можно довести до merge request;
NEEDS-DECISION — требуется решение владельца продукта или архитектора;
TOO-BIG — нужна декомпозиция, исследование или отдельный дизайн;
ALREADY-DONE — изменение уже закрыто другим MR.
У нас это важный элемент качества. Агент не должен угадывать продуктовые решения или «дожимать» неоднозначную задачу до правдоподобного diff. Если в требованиях нет нужного решения, фикс-трек останавливается и возвращает вопрос человеку.
Право на отказ — часть дизайна конвейера. Агент, который умеет сказать «для продолжения нужна продуктовая или архитектурная договорённость», безопаснее того, который всегда стремится выдать код.
Упрощённый путь подходящей задачи выглядит так:
проверка задачи → классификация → подготовка изменения → независимое ревью → доработка → создание MR → CI → ревью ИИ-ассистента → ревью и мёрж человеком.
Автор и ревьюер не должны быть одним и тем же агентом
В конвейере один агент готовит изменение, а другие проверяют его. Затем проводится отдельное состязательное ревью, его задача — искать контрпримеры, скрытые зависимости, уязвимости, регрессии и случаи, когда решение формально выглядит корректным, но не закрывает исходную потребность.
Автор и ревьюеры работают через разные каналы и могут использовать модели разных вендоров. Это снижает риск систематической ошибки: модель, которая сформировала решение, может быть склонна защищать собственные предположения, а независимый канал скорее заметит то, что автор пропустил.
Перед ревью действует внутренний контур проверок: агент получает обратную связь ещё в своей рабочей сессии и исправляет очевидные проблемы до передачи результата следующему проверяющему. Такой порядок позволяет не превращать внешнее ревью в поток мелких замечаний.
По данным внутреннего замера на 17–18 августа:
93% MR создаются при участии агентов;
94% агентных MR вливаются без замечаний человека;
post-merge churn за семь дней составляет 3,9%.
Последнюю цифру важно читать вместе с первой. Высокая доля MR без замечаний не означает формального «одобрения по умолчанию»: качество проверяется и после вливания. Churn 3,9% ниже актуального рыночного ориентира для AI-heavy-разработки — 5,7%.
При этом узкое место действительно смещается к человеку: работа модели в среднем занимает около 11 минут, а путь от ревью ИИ-агента до вливания MR — около 76 часов. Генерация кода перестаёт быть дефицитным этапом; ограничением становятся инженерная оценка, приоритизация и финальное решение.
Почему зелёного CI недостаточно
CI отвечает на конкретные технические вопросы: собирается ли проект, проходят ли тесты, выполнены ли обязательные проверки. Это необходимое условие, но не достаточное доказательство готовности изменения.
Изменение может пройти pipeline и всё же:
нарушить непокрытый пользовательский сценарий;
создать проблему обратной совместимости;
повлиять на интеграцию;
не соответствовать продуктовой договорённости;
внести регрессию за пределами исходного diff.
Поэтому в конвейере действует правило:
Зелёный CI означает, что механизм проверки прошёл. Он не означает, что задача полностью готова.
То же относится к локальной сборке. Она обязательна как ранняя проверка, но «локально зелёно» не равно «зелёно в CI»: среды могут различаться по архитектуре, зависимостям и конфигурации.
Тестирование также нельзя сводить к принципу «агент написал код и сам подтвердил его тестом». В таком случае автор становится собственным верификатором и может не заметить неверную постановку проверки. Поэтому в конвейере предусмотрены независимые тестовые и ревью-треки — если проверка невозможна, это фиксируется честным статусом.
Как правила исполняются кодом
В конвейере работает около ста механических гейтов, число которых постепенно растёт. Это исполнимые проверки в драйверах процесса, которые контролируют, например:
независимость автора и ревьюера;
результаты обязательных CI-job, а не только общий статус pipeline;
анализ связанных частей кода, а не одного diff;
пересечения с открытыми MR;
отсутствие секретов в публикуемых артефактах;
выполнение локальной сборки до запуска CI;
корректность маршрутизации задач между этапами.
Ключевой принцип в том, что правило без кода в драйвере не существует. Промпт задаёт намерение. Механический гейт устанавливает проверяемое ограничение. Это важно в том числе как защита от reward hacking: агент не должен иметь возможности объявить задачу решённой, опираясь только на собственный отчёт, переписанные тесты или выборочную интерпретацию результата.
Поэтому конвейер опирается на наблюдаемые артефакты:
изменения в файлах и diff;
результаты локальной сборки;
статусы конкретных CI-job;
результаты тестов;
комментарии независимых ревьюеров;
содержимое MR;
историю переходов сценария.
Scenario Workspace: как контекст связан с конкретной ревизией
Для передачи контекста между стадиями и участниками у каждой задачи есть Scenario Workspace — каталог в рабочей ветке: .agent-context/<task_id>/
В нём лежат:
runs/ записи запусков агентов artifacts рабочие артефакты стадий current.md актуальная выжимка контекста current-.md снимок контекста для конкретной ревизии MR current.json машиночитаемое представление
Записи коммитятся в ветку задачи. Когда создаётся MR, контекст попадает в него вместе с изменением кода. Ревьюер видит не только diff, но и сжатое описание проведённой работы, а следующий агент начинает не с нуля.
Такой подход даёт несколько преимуществ:
контекст привязан к ревизии кода;
его можно сравнивать между версиями;
он доступен в привычном интерфейсе GitLab;
история решений не отделена от жизненного цикла задачи;
человек и агент работают с одними и теми же артефактами.
При этом Scenario Workspace — не хранилище полного внутреннего рассуждения модели. В нём не размещаются chain-of-thought, сырые результаты вызовов инструментов, секреты и абсолютные локальные пути. Полные журналы сессий хранятся отдельно, в cc_sessions; в контексте задачи остаются ссылки на них и санитизированная выжимка.
Это отличает подход от Entire. Checkpoints сохраняет полные транскрипты и tool output на служебной ветке. В «Первой Форме» в рабочую ветку попадает высокосигнальный, пригодный для ревью контекст, а первичные журналы доступны отдельно при необходимости. Это компромисс между полнотой, шумом, безопасностью и удобством проверки.
Контекст также не является гарантией качества, он сокращает повторный брифинг: в замере объём вводного контекста снизился с 92 КБ до 14,7 КБ. Но каждый новый шаг всё равно требует проверки по коду, требованиям и наблюдаемым результатам.
Из чего состоит память агентов
В «Первой Форме» память агентов складывается из нескольких уровней:
Scenario Workspace — контекст конкретной задачи, связанный с веткой и ревизией.
Полные журналы сессий — отдельное хранилище cc_sessions.
База знаний организации — индексируемый корпус примерно из четырёх тысяч документов.
Проверенные результаты программ и источники — данные, которые можно использовать в следующих задачах и ответах.
Важно разделять технологические контуры поиска. Для dev-агентов по репозиториям используется триграммный поиск — ИИ-ассистент ищет по корпоративным знаниям каскадом: полнотекстовый поиск, векторный поиск и ранжирование PageRank.
Слишком длинный и неструктурированный контекст ухудшает точность работы модели ещё до достижения формального лимита окна. Поэтому в конвейере важна не максимальная длина истории, а минимальный достаточный набор проверяемых и релевантных сведений.
Почему важно подтверждать происхождение источников
Агент может написать: «все места проверены» или «исправление подтверждено документацией». Для рабочего процесса этого недостаточно, нам нужно понимать, что именно было вызвано, какие данные реально получены и откуда появился вывод.
В «Первой Форме» для этого работает нотариус источников. Блок «Источники» строится детерминированно из ProgramReceipt.citation[], где зафиксированы фактически выполненные шаги программы и их результаты. Сведения для списка система подставляет из кэша исполнения.
Это позволяет подтвердить:
источник действительно существует;
он был получен в рамках выполнения программы;
путь к нему можно повторить и проверить.
При этом мы учитываем, что даже если наличие и происхождение источника подтверждены, система не выполняет автоматическую семантическую проверку того, насколько точно конкретный вывод следует из этого источника. Такая проверка остаётся задачей ревьюера или пользователя.
Что изменилось в роли разработчика
О себе мы можем сказать следующее — у нас в компании разработчики почти перестали писать код руками. Их роль сместилась от непосредственного исполнения к постановке, проверке и принятию результата.
Один сотрудник может принимать 30–40 merge request в день. При этом последнее решение остаётся за человеком: агент готовит изменение, собирает материалы, выполняет проверки и передаёт результат на утверждение.
Такой подход дал измеримый эффект:
трудозатраты на сценарий снизились с 2,25 до 0,58 часа;
путь от постановки до первого MR сократился со 194 дней до 9 часов;
расчётная стоимость сценария снизилась с 6 750 до 2 016 рублей, включая токены.
Но ключевой фактор здесь в том, что агент должен работать в среде с ролями, правами, ограничениями, наблюдаемостью, журналированием и понятным маршрутом эскалации. Роль платформы — в том, чтобы дать возможность безопасно выполнять агентские циклы там, где нам это нужно.
Выводы
Агентная разработка не сводится к скорости генерации кода. Чем быстрее агенты создают изменения, тем важнее процесс, который позволяет понять, проверить и безопасно принять эти изменения.
Устойчивый конвейер требует:
постановки с проверяемыми критериями приёмки;
маршрута задачи и понятных ролей;
права агента остановиться, если требуется решение человека;
независимых каналов подготовки и ревью;
механических гейтов, закреплённых в коде;
отдельных контуров CI, тестирования и продуктовой проверки;
контекста, привязанного к ревизии кода;
наблюдаемых артефактов вместо самоописания агента;
подтверждённого происхождения данных и источников;
финального решения человека.
ИИ делает написание кода дешевле и быстрее. Но качество возникает только в среде, где результат можно наблюдать, оспорить, проверить и продолжить.
А что вы думаете об агентной разработке? Пробуете ли, применяете ли на постоянной основе?