Агенты в командной работе: ревью, договорённости, ответственность

В одиночку работа с агентом самокорректируется. Вы сгенерировали диф на восемьсот строк — вы же его и читаете. Боль от плохого промпта возвращается к вам в тот же час, и через неделю вы сами, без всяких регламентов, перестаёте просить «отрефактори весь модуль».

В команде эта петля разрывается. Диф генерирует один человек, читает — другой. Сэкономленный час автора становится потраченным часом ревьюера, причём автор этого не чувствует, а ревьюер не может отказаться. Это классическая экстерналия: издержки решения ложатся не на того, кто решение принял.

Вся глава — про то, как эту петлю восстановить. Не «как внедрить ИИ в команде» (такой главы честно написать нельзя, у каждой команды свой контекст), а про конкретный набор договорённостей, каждая из которых чинит конкретный разрыв обратной связи. И про один вопрос, у которого есть единственный правильный ответ: кто отвечает за код, который написал агент. Предыдущие главы дали инструменты для одного человека — ревью агентского кода, типология отказов, проверяемость, цена; здесь всё то же самое, но с поправкой на то, что участников больше одного.

Что именно ломается при переходе от одного к команде

Узкое место переезжает в чужой календарь

Механика простая и она не про ИИ — она про очереди. Если приток задач растёт, а пропускная способность обработки нет, растёт очередь, а вместе с ней — время ожидания. Формулировка известна как закон Литтла: среднее время в системе равно среднему количеству элементов в ней, делённому на среднюю пропускную способность. Дональд Рейнертсен в «The Principles of Product Development Flow» (2009) построил на этом всю аргументацию против больших партий работы: очередь невидима, в отличие от склада деталей, поэтому её не замечают, пока не начинает разъезжаться срок поставки. Агент действует ровно на левую часть картинки. Он не увеличивает вашу способность читать чужой код — он увеличивает количество кода, который надо прочитать. Причём генерацию действительно можно масштабировать: две параллельные сессии стоят вдвое дороже и всё. Ревью так не масштабируется — оно упирается в часы внимания конкретных людей, знающих эту часть системы.

Честная оговорка: рост генерации — это гипотеза

Прежде чем строить процесс вокруг «агенты ускоряют разработку», стоит знать, что это утверждение измеряли и результат оказался неочевидным.

METR провела рандомизированное контролируемое исследование с шестнадцатью опытными разработчиками открытого кода на их собственных зрелых репозиториях: «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity» (июль 2025). Разработчики ожидали ускорения; после эксперимента они считали, что ускорились. Измеренное время выполнения задач с доступом к ИИ-инструментам оказалось больше, чем без него, примерно на 19%.

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

Второй источник в ту же сторону: отчёты DORA (dora.dev/research). В отчёте 2024 года команда DORA обнаружила, что рост внедрения ИИ у респондентов связан со снижением пропускной способности поставки и стабильности — при том, что индивидуальная продуктивность и удовлетворённость росли. Это корреляции по самоотчётам, не причинность, и авторы это оговаривают явно. Но направление совпадает с картинкой очереди: локальное ускорение при неизменной пропускной способности ниже по потоку даёт ухудшение сквозного результата.

Ревью теряет вторую функцию

Ревью в команде выполняет как минимум две работы. Первая очевидная — поиск дефектов. Вторая менее очевидная и, по данным исследований, часто более ценная: передача знаний и осведомлённость о том, что происходит в системе. Классическая работа Bacchelli и Bird «Expectations, Outcomes, and Challenges of Modern Code Review» (ICSE 2013) показала расхождение: разработчики называют главной целью поиск багов, а фактические результаты чаще относятся к обмену знаниями, обсуждению альтернатив и распространению понимания кодовой базы.

Агент бьёт именно по второй функции, и незаметно. Раньше знание передавалось в обе стороны: автор объяснял решение, ревьюер приносил контекст. Теперь возможна ситуация, когда автор знает про свой диф меньше, чем ревьюер. Он не проходил путь принятия решений; он прочитал результат. Обсуждать альтернативы не с кем: агент, как разобрано в главе про ревью, не помнит своих причин и генерирует правдоподобное объяснение постфактум.

Это не аргумент против агентов. Это аргумент за то, чтобы обязанность «уметь защитить диф» была записана явно — раньше она держалась сама собой.

Ответственность размывается по умолчанию

Третий разрыв — самый тихий. Когда что-то ломается в проде, у команды появляется соблазн назвать причиной «это сгенерировал агент». Формулировка выглядит как объяснение, но объяснением не является: она не называет ни одного контроля, который должен был сработать и не сработал. С точки зрения разбора инцидента это то же самое, что сказать «код написал стажёр» — констатация, из которой не следует ни одного действия.

Пять договорённостей, которые стоит записать

Ниже — минимальный набор. Не потому, что больше не нужно, а потому, что регламент, который не помещается на страницу, никто не читает — и это верно и для людей, и для контракта агента (см. «Промпт как спецификация»).

1. У дифа всегда есть человек

Формулировка нормы, которую стоит внести в CONTRIBUTING.md дословно:

## Авторство и ответственность

Автор pull request отвечает за каждую строку изменения так же, как если бы
написал её сам. Это относится к коду, тестам, миграциям, конфигурации и
тексту описания PR.

«Это сгенерировал агент» — не объяснение поведения кода, не смягчающее
обстоятельство при разборе инцидента и не основание для ускоренного ревью.

Если вы не можете объяснить, почему изменение выглядит именно так, PR не
готов к ревью — независимо от того, зелёный ли CI.

Почему это не бюрократия, а необходимость — три независимых аргумента.

Технический. У агента нельзя узнать намерение. Он не хранит состояние между ходами (модель исполнения), и на вопрос «почему здесь ретрай» выдаст правдоподобную реконструкцию по вашему же дифу. Через полгода, когда этот ретрай начнёт маскировать реальную ошибку, спросить будет некого — кроме человека, который нажал merge.

Правовой и лицензионный. Подпись под коммитом — юридически значимое действие в большинстве открытых проектов. Developer Certificate of Origin требует от подписывающего утверждать происхождение кода и право на его передачу под лицензией проекта; выполнить это может только человек. Статус машинно-сгенерированного материала как объекта авторского права неустойчив и отличается по юрисдикциям — Бюро авторского права США публикует свою позицию и материалы по теме на copyright.gov/ai.

Проекты реагируют по-разному, и обе стратегии имеют смысл в своём контексте:

Если вы работаете с открытым кодом — политика конкретного проекта важнее вашей внутренней. Проверьте её до того, как отправите PR, а не после.

Операционный. В постмортеме причиной может быть только отсутствовавший или не сработавший контроль. Сравните формулировки:

Все правые формулировки чинятся конфигурацией и договорённостью. Все левые не чинятся ничем.

2. Контракт репозитория — это код, а не заметка

Файл CLAUDE.md, AGENTS.md или аналог в вашем инструменте меняет поведение агента у всех членов команды. Строка, добавленная в него одним человеком без обсуждения, — это изменение конфигурации, которое молча применилось ко всем сессиям. Anthropic описывает практику такого файла в «Claude Code Best Practices»; отраслевого стандарта на формат нет, детали отличаются между инструментами и версиями.

Что из этого следует практически:

• Файл лежит в git и меняется через PR. С ревью. Это не документация, это конфигурация исполнения.
• У файла есть владелец — человек, а не «команда». Иначе он гниёт.
• У каждого правила сформулировано наблюдаемое нарушение. Правило, нарушение которого нельзя увидеть в дифе или отчёте, — украшение. Это критерий из нашего собственного пакета шаблонов products/workbench/templates/memory/: там правила пронумерованы (RSN-02, CODE-11, MEM-51), и у каждого явно записано, как выглядит его нарушение. Смысл нумерации ровно командный: в комментарии к PR пишется «нарушено CODE-11», а не пересказ прозы на три абзаца.
• Каждая строка контракта умножается на количество людей и сессий. Контракт входит в каждый запрос каждой сессии каждого инженера. Двести лишних строк — это токены, которые вы платите тысячи раз в месяц, и место, вытесняющее из окна полезный контекст (глава про окно, глава про цену).

И честная оговорка, без которой пункт превращается в культ: проверить правило контракта так, как проверяют код, нельзя. Юнит-теста на промпт не бывает. Вы не можете доказать, что строка «всегда запускай тесты перед отчётом» изменила поведение — вы можете только наблюдать частоту нарушений до и после на выборке сессий. Из этого следует скромный, но выполнимый режим: правило вносится с гипотезой о наблюдаемом эффекте, а через месяц либо подтверждается наблюдениями, либо удаляется. Контракт, из которого никогда ничего не удаляли, — это свалка.

Что где лежит:

3. Границы: где агент не работает и почему

Запретные зоны — это не про «агент не справится». Часто справится. Это про асимметрию цены ошибки: есть места, где неверное изменение стоит несопоставимо дороже сэкономленного времени, и где ревью не ловит ошибку с приемлемой вероятностью.

Правый верхний угол — то, где агент как исполнитель не оправдан, но полезен как советчик: пусть предложит варианты, найдёт похожие места в кодовой базе, напишет чек-лист; решение и диф — человека. Левый верхний угол (ошибка дорогая, но проверить дёшево) — самый выгодный случай для агента при условии, что проверка действительно выполняется: там нужен обязательный второй ревьюер и жёсткий гейт в CI, а не доверие.

Отдельно про то, что попадает в границы всегда, независимо от квадранта: права процесса агента и доступ к секретам. Это тема главы про безопасность; здесь достаточно командного следствия — агент с чужими правами в общем репозитории создаёт риск, который никто не согласовывал. Личное решение инженера «дам-ка ему токен с записью в прод» становится риском всей команды.

4. Ревью: правило взаимности

Ключевая договорённость, которая чинит экстерналию из начала главы, звучит так:

Кто сгенерировал — тот и подготовил ревью. Автор обязан привести PR в состояние, в котором ревьюер тратит внимание на суть, а не на выяснение, что вообще произошло.

Практически это означает пакет свидетельств в описании PR. Не декларацию «я всё проверил», а конкретные артефакты:

Последние два пункта дают больше, чем первые четыре. Раздел «не проверено» переводит умолчания в явное; в пакете products/workbench/templates/memory/ это правило RSN-15, и оно же — самое полезное, что можно потребовать от агента в отчёте. Проверяемая часть требования автоматизируется — пример гейта, который не пропускает PR без раздела со свидетельствами и ограничивает размер:

# .github/workflows/pr-hygiene.yml
name: pr-hygiene
on:
  pull_request:
    types: [opened, edited, synchronize]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Описание содержит раздел со свидетельствами
        env:
          BODY: ${{ github.event.pull_request.body }}
        run: |
          # Разделы обязательны. Их содержимое проверяет человек, не CI.
          for section in '## Свидетельства' '## Не проверено'; do
            echo "$BODY" | grep -qF "$section" || {
              echo "::error::В описании PR нет раздела '$section'"; exit 1; }
          done          

      - name: Размер изменения в пределах договорённости
        run: |
          # Лимит — предмет договорённости команды, а не универсальная истина.
          LIMIT=400
          BASE="origin/${{ github.event.pull_request.base.ref }}"
          # Исключаем сгенерированное и залоченные зависимости: их не читают глазами.
          CHANGED=$(git diff --numstat "$BASE"...HEAD \
            -- . ':(exclude)**/*.lock' ':(exclude)**/generated/**' \
            | awk '{added += $1; removed += $2} END {print added + removed}')
          echo "Изменено строк: ${CHANGED:-0} (лимит $LIMIT)"
          if [ "${CHANGED:-0}" -gt "$LIMIT" ]; then
            echo "::error::PR больше лимита. Разбейте на части или обоснуйте меткой oversized-approved"
            exit 1
          fi          

Важно понимать границу такой автоматизации: CI проверяет наличие раздела, а не его правдивость. Автор может написать в «Свидетельства» три строки вымысла, и гейт пропустит. Ценность не в защите от злого умысла, а в том, что отсутствие раздела перестаёт быть нормой по умолчанию.

Почему лимит на размер PR стал обязательным

Раньше размер PR ограничивался естественно: писать тысячу строк долго и скучно, поэтому их писали редко. Агент это ограничение снял. Значит, ограничение должно появиться как договорённость — иначе его не будет вовсе.

Аргументы в пользу мелких изменений появились задолго до агентов. Руководство Google по код-ревью (google.github.io/eng-practices/review) отдельным документом объясняет, почему маленькие CL ревьюятся быстрее и качественнее. Исследование «Modern Code Review: A Case Study at Google» (Sadowski et al., ICSE-SEIP 2018) описывает практику, где изменения в подавляющем большинстве маленькие, ревьюер обычно один, а оборот ревью измеряется часами — и связывает скорость именно с размером.

Конкретное число (400 строк, 300, 200) — предмет вашей договорённости, а не универсальная константа: чужие числа переносить бессмысленно, они зависят от языка, домена и того, насколько команда знает этот код. Не является предметом договорённости другое — сам факт наличия лимита и видимость исключений из него.

Право вернуть PR не читая

Вторая половина правила взаимности, и без неё первая не работает:

Ревьюер имеет право вернуть PR без ревью, если в нём нет обязательных разделов, он превышает лимит без обоснования или его описание не соответствует дифу. Возврат не является конфликтом и не требует объяснений сверх ссылки на договорённость.

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

Состояние «Возвращён» — самое важное на схеме, и его чаще всего нет в реальных процессах. Без него любой PR, попавший в очередь, обязан быть прочитан, каким бы он ни был.

5. Что мерить

Метрика, по которой оценивают людей, перестаёт быть метрикой — это закон Гудхарта, и с агентами он срабатывает мгновенно. Строки кода и число PR всегда были плохими метриками; с агентом они стали ещё и бесплатно накручиваемыми.

Метрики поставки (частота релизов, время цикла, доля неудачных изменений, время восстановления) разбираются в треке управления проектами — «DORA и инженерные метрики». Про то, почему одномерные измерения продуктивности разработчиков не работают, — фреймворк SPACE: Forsgren et al., ACM Queue, 2021.

И самое честное, что можно сказать про этот раздел: ни одна из правых метрик не доказывает, что агенты приносят пользу. Они детектируют деградацию. Доказать пользу в вашей конкретной команде очень трудно — контролируемого эксперимента у вас не будет, а до/после смешивается с десятком других изменений. Поэтому разумная позиция — не «докажем выгоду», а «поймаем ухудшение достаточно рано».

Жизненный цикл PR: кто за что отвечает

Две вещи на этой диаграмме стоит выделить.

Шаг «автор читает диф» не является формальностью. Это единственное место, где стоимость возвращается к тому, кто её создал. Если автор пересылает диф дальше не читая, вся конструкция превращается в перекладывание работы, и никакие регламенты этого не исправят.

Бот и человек работают параллельно, а не последовательно. Бот не предварительный фильтр, после которого человек может расслабиться: он не находит класса проблем, который находит человек, и наоборот. Об этом — следующий раздел.

Агент в роли ревьюера

Соблазн очевидный: если ревью — узкое место, поставим на ревью агента. Разберём честно, потому что здесь легко и переоценить, и недооценить.

Что он делает хорошо

• Механическая полнота: пройтись по чек-листу и не пропустить пункт от усталости.
• Первый проход по большому дифу: где нет обработки ошибки, где изменилась сигнатура и не изменились все вызовы, где тест не проверяет ничего.
• Сверка описания PR с дифом: описание говорит одно, диф делает другое — частый и легко ловимый случай.
• Поиск похожих мест: «этот же паттерн есть ещё в трёх файлах, там он реализован иначе».
• Черновая проверка на соответствие записанным правилам проекта — с оговоркой, что вывод бота остаётся утверждением, а не наблюдением.

Что он делает плохо

• Коррелированные слепые зоны. Если диф написала модель, а ревьюит модель того же семейства, они систематически не видят одного и того же. Независимости, ради которой существует ревью, здесь нет — есть её имитация. Подробнее в главе про многоагентные схемы.
• Суждение о нужности. «Эту фичу мы решили не делать», «здесь нельзя добавлять зависимость», «этот сервис через месяц удаляется» — знание, которого нет ни в коде, ни в контракте.
• Приоритизация. Бот выдаёт двадцать замечаний одного визуального веса: три важных и семнадцать стилистических. Отделять — снова работа человека.

Проблема точности: как ломается канал

Самый недооценённый риск — не в том, что бот пропустит ошибку, а в том, что он обесценит комментарии как таковые. Динамика хорошо изучена на статических анализаторах. В работе «Lessons from Building Static Analysis Tools at Google» (Sadowski et al., CACM 61(4), 2018) описан наблюдавшийся эффект: если доля ложных срабатываний заметно превышает примерно десять процентов, разработчики перестают доверять инструменту и начинают игнорировать его вывод целиком — включая верные замечания. Google использовал этот порог как условие включения проверки для всех.

К комментариям LLM-ревьюера это применимо прямо, и даже жёстче: они выглядят убедительнее вывода линтера, тратят больше внимания на разбор и легко генерируются в количестве. Отсюда рабочие ограничения:

1. Комментарии бота не блокируют merge. Блокировать могут только детерминированные проверки: компиляция, тесты, форматирование, поиск секретов. Там, где решает суждение модели, — только совет.
2. Точность измеряется. Простейший способ: раз в две недели пройти по последним PR и посчитать долю комментариев бота, которые привели к изменению кода. Если доля падает — сокращайте область проверки, а не расширяйте.
3. Бот высказывается по своей зоне. Общий промпт «сделай ревью» даёт поток общих слов. Узкие проверки («только про обработку ошибок и границы транзакций») дают выше точность и меньше шума.
4. Бот не голосует. Approve от бота не существует как понятия; в правилах ветки он не входит в число обязательных одобрений.

Отдельно повторю очевидное, потому что нарушается оно постоянно: утверждение бота-ревьюера — это утверждение, а не наблюдение. «Здесь возможен состояние гонки» проверяется тестом или рассуждением человека, а не принимается на веру, потому что написано уверенным тоном (глава 10).

Ветки и история

Мелкая, но заметно облегчающая жизнь деталь. Агентская сессия хорошо ложится на отдельную ветку, а её результат — на серию коммитов, где механическое отделено от осмысленного.

Смысл разделения: массовое механическое изменение (переименование, форматирование, автоматическая замена) ревьюится за минуту при условии, что оно одно в PR — и превращается в непроверяемую кашу, если размазано по осмысленному дифу. Это правило CODE-14 из нашего пакета шаблонов («одно изменение — одно намерение») и одновременно обычная гигиена работы с историей, разобранная в треке git: «Ветвление» и «Совместная работа». Практическое следствие: если агент в одной сессии и отрефакторил, и починил баг — просите разделить до открытия PR. Разделять чужой смешанный диф дороже, чем сгенерировать заново.

Общая память команды

Из всего, что можно сделать общим у агентов в команде, наибольшую отдачу даёт одно: записи об опровергнутых гипотезах. Инженер потратил два часа, выясняя, что библиотека молча игнорирует таймаут в определённом режиме. Если эта запись осталась в его личной истории, остальные потратят те же два часа каждый. Если она лежит в общем хранилище с адресом источника и датой — не потратит никто.

Правила из пакета products/workbench/templates/memory/, которые важны именно в командном режиме:

• MEM-51 — совпавшая рефутация блокирует путь: агент, нашедший запись «так не работает по такой-то причине», обязан либо не идти этим путём, либо явно объяснить, чем случай отличается.
• MEM-52 — цитата из памяти несёт дату проверки: запись о стороннем сервисе старше вашего окна устаревания — гипотеза, а не факт.
• MEM-21 и MEM-22 — в общую память не попадают секреты, локальные детали машины и то, что выводится из репозитория. Общее хранилище утекает шире личного, а мусор в нём стоит токенов у всех.

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

Джуны, онбординг и обратный поток знания

Тема, где обе стороны реальны и врать особенно не хочется.

Сторона пользы. На незнакомой кодовой базе агент — это лучший из существующих инструментов ориентации. «Где обрабатывается вот этот вебхук», «покажи все места, где меняется этот статус», «какой слой отвечает за ретраи» — вопросы, на которые новичок раньше тратил дни или чужое время. Ответ надо проверять, но проверить готовый ответ дешевле, чем искать с нуля.

Сторона вреда. Навык отладки вырабатывается через переживание тупика. Если тупик снимается за тридцать секунд чужим ответом, навык не появляется — появляется зависимость от инструмента. Это не гипотеза про ИИ, это общее свойство обучения: усилие извлечения из памяти и есть механизм обучения.

Договорённость, которая балансирует обе стороны и при этом проверяема одним вопросом на ревью:

Автор обязан уметь защитить диф без агента. На ревью допустим вопрос «объясни, что здесь произойдёт, если список пустой». Ответ «сейчас спрошу» означает, что PR не готов.

Это не наказание, а способ сохранить обучающую функцию ревью и починить обратный поток знания: если автор способен защитить диф, значит, он его понял, а не переслал. Второе полезное правило для новичков — первые недели без агента на задачах, которые учат системе: не из идеологии, а потому что цель этих задач не результат, а понимание. Где именно провести границу — вопрос конкретной команды, однозначного ответа у отрасли нет.

Смежные материалы портала: «Роли и команды» и «Делегирование задач» — механика делегирования человеку удивительно хорошо переносится на постановку задачи агенту (глава про планирование).

Кто должен ревьюить этот диф

Маршрутизация — недооценённая часть процесса. Агент меняет распределение дефектов (глава 08), а значит, меняет и требования к тому, кто смотрит.

Ветка «механическое однородное изменение» — единственный честный способ ревьюить диф на три тысячи строк. Проверяется не диф, а процедура, которая его породила: чем именно сделано переименование, воспроизводится ли результат повторным запуском, и совпадает ли выборочная проверка двадцати случайных мест с ожиданием. Если процедуры нет и изменение сделано «агент прошёлся по файлам», то это не механическое изменение, а три тысячи строк ручной работы неизвестного качества — и его надо возвращать.

Антипаттерны

Последнюю строку стоит развернуть, потому что вопрос спорный и решается по-разному.

За обязательную пометку происхождения: ревьюер калибрует внимание, распределение дефектов у агентского кода другое, для открытых проектов это ещё и требование лицензионной чистоты.

Против: пометка неверифицируема (проверить нельзя, держится на честности), быстро превращается в стигму, а при стигме — просто перестаёт ставиться. И главное: она смещает разговор с «чем подтверждено» на «кто написал», хотя проверять надо первое.

Рабочий компромисс, который встречается чаще всего: происхождение фиксируется там, где этого требует лицензия или регламент проекта, а во внутренних репозиториях требуются свидетельства независимо от происхождения. Требование, одинаковое для всех дифов, не создаёт стигмы и не нуждается в проверке честности — либо прогон приложен, либо нет.

С чего начать: первая неделя

Если агенты в команде уже используются, а договорённостей нет, порядок внедрения по убыванию отдачи:

1. Зафиксировать ответственность. Три абзаца в CONTRIBUTING.md из раздела выше. Ноль затрат, снимает будущий спор в момент инцидента.
2. Ввести лимит на размер PR и право вернуть не читая. Это две половины одного механизма; по отдельности не работают.
3. Потребовать раздел «Свидетельства» и «Не проверено» в описании PR. Автоматизировать наличие раздела в CI (пример выше) — правдивость всё равно проверяет человек.
4. Перенести контракт агента в git и назначить владельца. Заодно вычистить из него всё, для чего нельзя назвать наблюдаемое нарушение.
5. Определить запретные зоны. Начните с трёх: миграции схемы, права доступа, инфраструктурный код. Расширять по мере накопления собственных инцидентов, а не по чужим спискам.
6. Начать смотреть на очередь. Время ожидания первого ревью и распределение размеров PR — два числа, которые покажут деградацию раньше всего.
7. Только потом — боты-ревьюеры. Они не решают проблему очереди и добавляют шум; включать их имеет смысл, когда есть чем измерить их точность.

Мини-итог

• В команде агент не экономит время, а перемещает его: от автора к ревьюеру. Договорённости нужны ровно затем, чтобы вернуть стоимость туда, где она возникла.
• Утверждение «агенты нас ускорили» — гипотеза о вашей команде. Измеренные результаты (METR, DORA) показывают, что ощущение ускорения расходится с секундомером и что локальное ускорение может ухудшать сквозную поставку.
• За диф отвечает человек, который его открыл. «Агент написал» не является ни объяснением, ни смягчающим обстоятельством, ни причиной в постмортеме.
• Контракт агента — конфигурация, действующая на всех: в git, через PR, с владельцем, с удалением правил, у которых нет наблюдаемого нарушения.
• Лимит на размер PR обязан стать явной договорённостью, потому что естественное ограничение усилием исчезло.
• Правило взаимности («сгенерировал — подготовь ревью») плюс право вернуть PR не читая — минимальный механизм, который держит всю конструкцию.
• Бот-ревьюер полезен как параллельный дешёвый слой и вреден как гейт: коррелированные слепые зоны и падение точности разрушают доверие к каналу комментариев целиком.
• Метрики ловят деградацию, а не доказывают пользу. Пользу в конкретной команде доказать почти невозможно — и честнее это признать, чем нарисовать график экономии.

Источники

• Donald G. Reinertsen. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009 — очереди, размер партии и почему невидимая очередь дороже видимого склада.
• METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025 — РКИ на шестнадцати разработчиках: измеренное замедление при ощущаемом ускорении.
• DORA. Отчёты о состоянии DevOps — связь внедрения ИИ с показателями поставки; корреляции по самоотчётам, не причинность.
• Alberto Bacchelli, Christian Bird. Expectations, Outcomes, and Challenges of Modern Code Review, ICSE 2013 — вторая функция ревью: обмен знаниями.
• Caitlin Sadowski et al. Modern Code Review: A Case Study at Google, ICSE-SEIP 2018 — маленькие изменения, один ревьюер, быстрый оборот.
• Caitlin Sadowski et al. Lessons from Building Static Analysis Tools at Google, CACM 61(4), 2018 — порог ложных срабатываний и потеря доверия к инструменту.
• Google. Engineering Practices: Code Review — руководство ревьюера и автора, включая аргументацию за маленькие CL.
• Nicole Forsgren et al. The SPACE of Developer Productivity, ACM Queue, 2021 — почему одномерные метрики продуктивности не работают.
• Developer Certificate of Origin — что именно утверждает человек, подписывая коммит.
• U.S. Copyright Office. Copyright and Artificial Intelligence — позиция и материалы по авторству машинно-сгенерированного материала.
• Gentoo AI policy и QEMU Code provenance — два противоположных подхода открытых проектов.
• Anthropic. Claude Code Best Practices — практика файла-контракта репозитория; детали зависят от версии инструмента.
• products/workbench/templates/memory/ — наш собственный пакет правил: REASONING-DISCIPLINE.md (RSN-15 — отчёт заканчивается списком непроверенного), VERIFIED-CODE.md (CODE-14 — одно изменение, одно намерение), MEMORY-PROTOCOL.md (MEM-21, MEM-22, MEM-51, MEM-52 — что не кладут в общую память и как работает рефутация). Рабочий стандарт портала, не отраслевой.

Смежные главы портала: «Код-ревью и стандарты кода», «Тесты в CI», «Основы CI», «ИИ в жизненном цикле разработки», «Антипаттерны».

Что дальше

Договорённости описывают, как команда работает с агентом. Остаётся вопрос, каким именно агентом и как встроить его в существующий инструментарий, не перестраивая всё вокруг него: «Инструменты и практика: что выбрать и как встроить в свой процесс».