Код‑ревью сломалось.
Принятый в индустрии процесс код‑ревью, «ревью перед коммитом» (review‑then‑commit), был довольно простым механизмом, который позволял совместно работать группе инженеров с относительно низким уровнем доверия друг к другу.
По‑видимому, впервые этот подход сформировался в 1990-х в опенсорсном проекте Apache Server, в начале 2000-х был поставлен на корпоративные рельсы в Google, а затем распространился по всей индустрии. Немалую роль в этом сыграли разные инструменты, и прежде всего PR на GitHub.
Все было очень просто:
Человек вносит изменение.
Изменение оформляется и отправляется другому человеку на ревью.
Ревьюер оставляет комментарии, автор вносит правки, и так продолжается, пока ревьюер не одобрит изменение — не поставит LGTM.
Изменение коммитится.
Это не работа Майкла Фейгана по анализу дефектов и не процессы, похожие на работу с тикетами, которые применяются при критически важных изменениях в таких областях, как аэрокосмическая отрасль. Такой процесс не поймает ваши баги. Зато он позволяет доносить изменения в дизайне до других инженеров, которые держат в голове модель кодовой базы, а ревьюеры могут через него объяснять контрибьюторам принятые в проекте нормы.
У такого подхода есть свои преимущества, а поскольку перед попаданием изменений в основную ветку стоит контрольный барьер, высокого уровня доверия между участниками не требуется.
Поэтому он отлично подходит для масштабирования компании: когда команда становится больше 10–12 инженеров — вырастает за пределы той самой «команды на две пиццы», как ее еще называют, — уровень взаимного доверия быстро снижается.
По той же причине этот подход хорошо масштабируется и в open source. Основная нагрузка ложится на ревьюеров, но и человек, который вносит изменение, тоже проделывает немало работы. Дисбаланс был, но обычно оставался терпимым.
Кризис код‑ревью
ИИ‑агенты всё это сломали. Если просто встроить агента в существующий процесс, в лучшем случае получится так:
Человек поручает машине внести изменение.
Человек проверяет код и через комментарии итеративно доводит его до состояния, которое сам считает приемлемым.
Изменение оформляется и отправляется другому человеку на ревью.
Ревьюер оставляет комментарии, автор вносит правки, и так продолжается, пока ревьюер не одобрит изменение — не поставит LGTM.
Изменение коммитится.
Объем ревью при этом удваивается. А компании и без того уже упирались в ресурс на ревью. В действительно хорошо работающей команде один цикл код‑ревью мог занимать день. Если два инженера отлично сработались и прекрасно знают код друг друга, это время можно сократить примерно до часа. Но в среднем по индустрии еще до появления агентов на то, чтобы пройти ревью и смержить изменение, в хорошем случае уходили дни.
К тому же инженеры используют агентов именно потому, что те повышают производительность. Изменений в итоге становится больше. То есть мы удвоили объем ревью и одновременно увеличили общее число изменений. Если пытаться просто приспособить старую модель к новым условиям, ресурс на ревью закончится раньше, чем вы успеете получить от агентов всю возможную пользу. А если судить по личным наблюдениям, он заканчивается еще до того, как удается извлечь хотя бы заметную долю этой пользы.
Но дальше становится еще хуже, потому что в реальности старый процесс таким образом почти никто не дополняет.
Проблема «принципал — агент» в эпоху ИИ‑агентов
На практике процесс чаще выглядит так:
Человек поручает машине внести изменение.
Получившийся результат поверхностно проверяют, оформляют и отправляют другому человеку на ревью.
Ревьюер присылает комментарии, а их целиком передают машине на доработку, и так до тех пор, пока ревьюер не одобрит изменение — не поставит LGTM.
Изменение коммитится.
Это пример того, что экономисты называют проблемой «принципал — агент»: ревьюер здесь выступает принципалом, контрибьютор — агентом. Код‑ревью работало потому, что по самому коду ревьюер мог довольно дешево понять, сколько усилий вложил автор. ИИ‑агенты уничтожают этот сигнал. Именно это сейчас убивает опенсорс, и явление уже получило название «мусорные пулл‑реквесты» (slop PRs). У человека, управляющего агентом, просто нет стимула самому читать код или тратить время на то, чтобы вдумываться в комментарии ревьюера.
В результате возникает чудовищный дисбаланс. «Контрибьютор» набирает одно‑два предложения на уровне плохого баг‑репорта, пять минут тыкает получившуюся программу, а затем создает серьезную нагрузку на другого инженера, которому приходится все это ревьюить.
И для этого вообще не нужно понимать сам проект, его ограничения или инструменты, на которых он построен. Управлять таким процессом невозможно. Он не работает даже там, где ревьюеру платят именно за эту работу: он был бы продуктивнее, если бы сам дал агенту нужный промпт.
Возможные решения
Небольшие команды с высоким уровнем доверия могут перейти на довольно простой процесс:
Человек поручает машине внести изменение.
Сам проверяет код и через комментарии итеративно доводит его до состояния, которое считает приемлемым.
Сам отправляет изменение в прод и деплоит его.
Человек по‑прежнему остается в контуре. Ревьюер по‑прежнему есть, и при этом он не успевает слишком глубоко погрузиться в детали того, как именно решалась задача. Но главное — здесь нет проблемы «принципал — агент», потому что человек, управляющий машиной, берет на себя ответственность за ее действия, отвечая за деплой.
По моим наблюдениям, для небольших команд это работает. В exe.dev нас девять человек, и мы смогли выстроить такой процесс. Мы гораздо больше времени тратим на интеграционные и e2e‑тесты, а также создаем пайплайны на основе агентов, которые анализируют коммиты на риски, проблемы с производительностью и юзабилити. Все это нужно, чтобы снизить вероятность неприятных сюрпризов. Обычно команды начинают строить такую инфраструктуру, только когда становятся гораздо крупнее и зрелее.
С другой стороны, благодаря агентам делать ее теперь заметно проще. Нам также приходится очень тщательно выбирать коллег и осознанно выстраивать коммуникацию. Но мы действительно выкатываем изменения именно так.
В среде с низким уровнем доверия, то есть в крупных компаниях, такой подход нежизнеспособен. Нужно доверять коллегам настолько, чтобы они сами начали обсуждение архитектурных изменений до того, как возьмутся их реализовывать.
В условной BigCo никто не доверит коллеге радикально переделывать сервис, которым тот якобы «владеет». И никто в BigCo не хочет в одиночку отвечать за крупный инцидент без подстраховки в виде код‑ревью, которое позволяет размазать ответственность между несколькими людьми. (Среда с низким уровнем доверия — вообще ужасное место для работы.)
Я уверен, что в больших компаниях есть небольшие изолированные команды, которые отошли от стандартных практик и действительно получают от агентов ощутимую пользу. Уверен и в том, что есть индивидуальные специалисты, чья работа позволяет выжимать из агента максимум, почти не вовлекая коллег. Например, если вы занимаетесь качеством, агенты могут помогать вам запускать бесконечные масштабные эксперименты, которые вообще не нужно отдавать на ревью: достаточно потом разослать результаты тех, что сработали.
Но подавляющее большинство инженеров в крупных компаниях не может вносить изменения, особенно те, что затрагивают несколько команд и функции и с которыми агенты как раз особенно хороши, без того, чтобы код‑ревью съело весь прирост производительности.
Несколько подсказок из истории
На момент написания этой статьи я еще не встречал описания процесса, который позволял бы «масштабировать» разработку с ИИ‑агентами в крупной компании. Но история показывает, что это, похоже, возможно. Я бы вспомнил Microsoft 1990-х, где обязательного ревью перед коммитом не было.
В отдельных командах такая практика, возможно, существовала, но в целом большая компания была устроена как множество независимых команд, которые постоянно синхронизировались через процессы QA. Сторонники процессов для больших команд, появившихся еще до ИИ‑агентов, считают такой подход старомодной «ковбойской» разработкой. Но он работал.
Именно так появились одни из самых успешных и долгоживущих продуктов Microsoft, например Win32 API. Да, API тридцатилетней давности можно критиковать бесконечно, но он до сих пор с нами и во многом лучше некоторых своих «замен», которые уже разрабатывались с код‑ревью. Об этом периоде истории Microsoft, похоже, написано совсем немного. Если вы тогда там работали, я бы с удовольствием послушал или почитал о вашем опыте.
Пока кто‑нибудь не придумает надежные процессы работы с агентами для среды с низким уровнем доверия, у маленьких команд остается мощный фактор, резко повышающий производительность, которого нет у больших. Выкатывайте изменения, пока можете.
ИИ‑агенты ускоряют разработку, но вместе с этим повышают цену поверхностной проверки: чем больше кода генерируется автоматически, тем важнее понимать, где заканчивается помощь модели и начинается ответственность инженера.
Если хочется встроить ИИ в рабочие процессы так, чтобы он действительно снимал рутину, а не создавал новое узкое место для команды, на открытых уроках разберём практические сценарии работы с ИИ‑кодом, распределением ответственности и внедрением новых процессов.
3 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться
9 сентября, 20:00. «Как тимлиду распределять ответственность и не становиться узким местом команды». Записаться
22 сентября, 20:00. «Можно ли доверять ИИ‑коду: как находить галлюцинации, уязвимости и устаревшие решения». Записаться
Больше бесплатных уроков августа можно найти в дайджесте.
