Почему агентам для программирования нужен владелец до того, как накопится работа

Что ломается, когда за агентами никто не отвечает

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

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

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

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

Объем работы тоже растет быстрее, чем команда успевает его проверить. Два инженера обычно могут спокойно просмотреть десять человеческих pull request за день. Но пять больших диффов, сгенерированных агентами, они, как правило, не смогут проверить с тем же вниманием. Работа скапливается в ревью, конфликтов при слиянии становится больше, и люди начинают одобрять изменения просто чтобы очередь двигалась.

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

Что должен решить ответственный до первого дня

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

Ему не обязательно писать каждую строку кода. Но ему нужен достаточный технический кругозор, чтобы говорить да, нет и стоп. В небольшой компании этим человеком может быть CTO или основатель, у которого по-прежнему широкий инженерный опыт. Если такого человека в команде нет, gap может закрыть fractional CTO и принять эти решения заранее.

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

Второе решение — размер изменения. Большие pull request выглядят продуктивно ровно до того момента, когда их никто не может проверить. До начала работы нужен жесткий потолок. Для большинства команд это означает маленькие PR с одной узкой целью, ограниченным числом файлов и диффом, который один ревьюер может быстро понять.

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

Стартовые правила могут быть очень простыми:

• Один назначенный ответственный задает правила и обновляет их.
• Агенты пишут только в разрешенных папках или сервисах.
• PR должны быть достаточно маленькими для быстрого ревью.
• Один человек может заморозить вывод агента, как только появляются проблемы.

Это не про жесткий контроль. Это про спокойный репозиторий. Команды двигаются быстрее, когда границы понятны.

Правила репозитория, которые держат вывод под контролем

Самый быстрый способ потерять контроль над выводом агента — дать репозиторию слишком широкие права. Агенты двигаются быстро. Без границ эта скорость превращается в хаос.

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

Обычно нескольких правил достаточно, чтобы закрыть большую часть проблем. Защитите main и release-ветки, чтобы агенты никогда не пушили туда напрямую. Ограничьте работу по путям, чтобы задача в billing не уходила в общий auth или в файлы деплоя. Храните промпт задачи и заметки о приемке в самом репозитории, чтобы проверяющие видели, что именно было сказано агенту. Требуйте номер тикета или короткий письменный бриф: что менять, что не менять и когда остановиться.

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

Небольшой пример показывает, почему это важно. Если агенту сказать "улучши checkout", задача слишком расплывчата. Если правила репозитория требуют тикет, разрешенные папки и сохраненный промпт, тот же запрос становится понятным: обнови округление налогов в сервисе checkout, не трогай логику цен, добавь тесты, указанные в брифе, и остановись после одного pull request.

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

Тестовые проверки и лимиты на слияние, которые удерживают линию

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

Для каждой ветки должен быть один и тот же путь проверок, неважно, писал код человек или агент. Перед обсуждением слияния нужно запускать linting, unit-тесты, type checks и те smoke-тесты, которые важны для этого сервиса. Команды попадают в неприятности, когда считают агентские ветки черновиками и ради экономии времени пропускают pipeline.

Если сборка не прошла, слияние должно быть заблокировано. Всегда. Фраза "дополним в следующем PR" звучит безобидно, пока агентский вывод не начинает копиться. Одна красная сборка превращается в три поспешных follow-up, и вскоре никто уже не знает, какое изменение все сломало.

Некоторые зоны все равно требуют человека каждый раз. Auth, billing, права доступа, изменения схемы и код деплоя могут за один плохой merge сломать доверие, движение денег или production-данные. Агент может предложить код, но человек должен прочитать дифф, проверить крайние случаи и решить, безопасно ли это.

Размер слияния важен не меньше тестовых проверок. Если один ревьюер не может понять изменение примерно за 10–15 минут, PR слишком большой. Крупные диффы от агентов скрывают глупые ошибки: дублирование логики, неверные имена полей, тихие дыры в безопасности или тесты, которые проходят по неправильной причине.

Сами правила не обязаны быть сложными:

• Запускайте CI на каждой ветке.
• Блокируйте любое слияние при провале проверки.
• Требуйте человеческого одобрения для auth, billing, схемы и инфраструктуры.
• Делите PR, пока один ревьюер не сможет читать их быстро.

Небольшому стартапу не нужен гигантский процесс. Ему нужны правила, которые работают даже в загруженный день.

Простой план запуска на первые две недели

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

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

Неделя 1

Запишите пять правил, которым команда сможет следовать уже сегодня, даже если поначалу они кажутся строгими:

• Агенты работают только в одном репозитории.
• Агенты открывают маленькие pull request, а не широкие рефакторинги.
• Каждое изменение должно пройти linting, тесты и сборку.
• Каждое слияние проверяет человек.
• Если проверки не прошли, агент останавливается и ждет.

Держите правила короткими. Если новый инженер не может прочитать их за две минуты, они слишком длинные.

Сначала включите базовые проверки. Linting ловит неаккуратные правки. Тесты ловят сломанное поведение. Проверки сборки ловят отсутствующие импорты, неправильные типы и ошибки упаковки. Это дешевые защитные барьеры, и они отсекают много шума еще до начала ревью.

Неделя 2

Внимательно следите за первыми десятью слияниями. Не спрашивайте только: "Прошло ли?" Спрашивайте, что отнимало время. Может быть, агент все время трогает лишние файлы. Может быть, пишет длинные комментарии, которые никому не нужны. Может быть, исправляет один баг, а заодно меняет названия в шести папках. Эти паттерны подскажут, какое правило стоит ужесточить следующим.

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

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

Пример небольшой команды

Стартап из шести человек добавляет двух кодирующих агентов, чтобы помочь с исправлением багов. Команда небольшая: три инженера, продакт-менеджер, дизайнер и основатель, который по-прежнему участвует в проверках перед релизом. Пару дней все кажется отличным. Баги уходят быстрее. Pull request накапливаются. Потом один агент превращает простое исправление в изменения сразу в нескольких сервисах, и ревью начинает тормозить.

Технический лидер вмешивается и вводит одно правило, которое звучит жестко, но работает: каждая задача агента может затрагивать один сервис и один тикет. Если баг живет в billing, агент остается в billing. Он не переименовывает общие хелперы, не обновляет другой сервис и не чистит чужой код по пути. Такое ограничение делает репозиторий предсказуемым и сильно упрощает откат, если что-то просочится.

Команда также проводит жесткую линию по тестам. Если агент открыл PR, а тестовый набор упал, работа возвращается назад еще до того, как ее посмотрит инженер. Люди не тратят время на разбор lint-ошибок, сломанных сборок или упавших проверок, которые агент должен был закрыть сам. Одно это правило экономит удивительно много внимания.

Наибольшую разницу дают маленькие слияния. Владелец ограничивает PR от агентов размером, который уставший инженер может просмотреть за несколько минут. В маленьком диффе ревьюер замечает плохой запрос, пропущенную проверку на null или рискованную миграцию. В огромном диффе люди скользят по поверхности. Именно так плохие изменения проходят дальше.

Агенты при этом все равно помогают. Просто они помогают внутри системы, которую команда контролирует.

Ошибки, которые команды совершают с выводом агентов

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

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

Другая ошибка — измерять сырую активность вместо полезного результата. Больше pull request, больше измененных строк и больше закрытых задач могут выглядеть впечатляюще в течение недели. Потом команда замечает, что половина диффов шумная, тесты падают по посторонним причинам, а утро уходит на разбор движухи вместо выпуска продукта.

Лучшие сигналы менее эффектны: сколько PR от агента сливается без доработок, сколько времени занимает ревью, как часто изменения откатывают и как часто после правок агента падают сборки или тесты. Именно эти цифры показывают, работает ли процесс.

Еще одно слабое место — откат. Команды позволяют агентам генерировать широкие изменения, сливают их и думают, что потом все исправят по ходу. Это работает до тех пор, пока агент не обновит общую миграцию, не перепишет конфиг или не изменит общий формат API. Когда что-то ломается, нужен чистый путь отката. Коммит с revert, feature flag или изолированная ветка могут сэкономить часы споров.

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

Быстрые проверки перед расширением использования агентов

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

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

Ревьюер должен уметь прочитать типичное слияние примерно за десять минут. Если одна задача создает 40 измененных файлов, разбейте работу или ужесточите правила репозитория. Тесты должны быстро падать в рискованных областях. Auth, billing, права доступа, изменения схемы и код деплоя должны останавливать плохой вывод за минуты, а не после долгого прогона pipeline. Каждая задача должна вести к тикету, заметке или короткому письменному запросу. Если у изменения нет источника, люди перестают спрашивать, зачем оно вообще существует. А если ревьюер обходит тесты или сливает изменения вне обычного пути, команда должна фиксировать, кто одобрил исключение и почему.

Эти проверки звучат базово, потому что они и правда базовые. В этом и смысл. Они показывают, контролирует ли команда агентов или уже агенты управляют темпом.

Небольшой пример это хорошо иллюстрирует. Допустим, агент открыл восемь pull request за один день. Код собирается, но два слияния затрагивают права доступа, одно меняет общий API, а у трех нет тикета. Если команда не может разобрать это за одну короткую сессию ревью, ей не нужна большая мощность агентов. Ей нужны более жесткие ограничения.

Внешнее техническое руководство здесь может помочь, особенно в командах, где основатель ведет продукт и никто не хочет каждый день следить за merge-правилами. Человек, который стоит выше очереди тикетов, может задать правила, удерживать линию по исключениям и поддерживать один стандарт во всем репозитории.

Что делать дальше

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

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

Сначала запишите защитные барьеры, а уже потом добавляйте больше агентов. Определите, какие файлы агенты могут менять без одобрения. Задайте тесты, которые обязан пройти каждый pull request. Ограничьте размер PR и дневное число слияний. Запретите прямое слияние в защищенные ветки. Требуйте человеческого ревью для изменений схемы, auth, billing и инфраструктуры.

Инструмент может быстро писать код. Но он не может решить, сколько риска ваша команда способна принять на этой неделе.

Если в команде нет человека, у которого есть время и кругозор, чтобы вести этот процесс, внешняя помощь может все изменить. Олег Сотников через oleg.is работает со стартапами именно над этой задачей: помогает настраивать границы репозитория, тестовые проверки и правила слияния, чтобы AI-assisted разработка оставалась полезной, а не превращалась в бесконечную уборку.

Не запускайте это везде сразу. Проведите настройку в одном репозитории в течение недели или двух. Смотрите на нагрузку на ревью, число упавших тестов и частоту откатов. Если pull request становятся меньше, комментарии на ревью короче, а число сломанных слияний падает, правила работают.

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