Агент пишет быстрее, команда релизит медленнее: 30 дней с coding agent на реальном проекте

Первые несколько дней с AI агентом легко создают ощущение, что разработку наконец‑то «сломали». Даёшь задачу, через несколько минут получаешь diff на несколько файлов, тесты и уверенный отчёт о том, что всё готово. Если мерить производительность от момента, когда ты сформулировал prompt, до появления кода, результат действительно впечатляет.

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

Поэтому в течение месяца я смотрел не на количество сгенерированного кода, а на полный цикл изменения: задача → понимание контекста → реализация → review → тесты → интеграция → release. И именно здесь эффект оказался гораздо интереснее простого «AI ускоряет разработчика».

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

Где агент действительно быстрый

Речь идёт о зрелом backend: несколько сервисов, PostgreSQL, Redis, внешние API, фоновые задачи, async‑код, retries, транзакции и события. То есть о системе, где поведение конкретной функции часто зависит от контекста, который не помещается в один файл.

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

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

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

Diff стал дешёвым, понимание — нет

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

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

Сам код стал появляться намного быстрее, но разбираться в нём быстрее почти не стало.

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

В итоге часть работы никуда не исчезает — она просто смещается с написания кода на его проверку.

И чем дороже потенциальная ошибка, тем сложнее эту проверку автоматизировать. Тесты могут подтвердить, что код работает так, как мы ожидаем, но не всегда способны определить, правильно ли мы вообще поняли бизнес‑логику или ограничения системы.

Самые неприятные ошибки выглядят правильно

Syntax error почти ничего не стоит. IDE покажет проблему, тест упадёт, исправление займёт минуту.

Гораздо хуже решение, которое технически корректно, хорошо оформлено и даже выглядит как улучшение.

Допустим, есть вызов внешнего API, и агент добавляет к нему retry с timeout и backoff:

@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1),
)
async def create_ticket(payload):
    return await provider.create_ticket(payload)

С точки зрения локальной надёжности решение выглядит разумно. Но если create_ticket на стороне провайдера не идемпотентен, timeout не означает, что операция не произошла. Провайдер мог успешно создать ticket, а ответ потерялся по дороге. Повторный запрос создаст второй.

В таком случае ошибка находится не в Python‑коде. Она находится в знании контракта: поддерживает ли провайдер idempotency key, можно ли безопасно повторять операцию и какое состояние считается неопределённым после сетевого сбоя.

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

Похожий пример легко получить и с async. Модель видит три последовательных I/O‑вызова и предлагает asyncio.gather(). Локально это выглядит как очевидная оптимизация. Но если все вызовы используют один SQLAlchemy AsyncSession, это уже нарушение модели конкурентного использования session: документация SQLAlchemy прямо рекомендует отдельный AsyncSession на каждую concurrent task.

То есть агент хорошо знает паттерн «параллелить независимый I/O», но не всегда видит, почему именно в этом месте его применять нельзя.

Bottleneck переехал в review

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

Большой diff появляется быстро, но его всё равно нужно прочитать. Нужно убедиться, что изменение не затронуло границы транзакций, не добавило неожиданных побочных эффектов, правильно обрабатывает частичные сбои и не ломает обратную совместимость. И отдельно проверить, что тесты действительно покрывают нужное бизнес‑поведение, а не просто подтверждают работу написанного кода.

Причём AI‑код часто выглядит аккуратнее случайного человеческого черновика. Хорошие имена, комментарии, понятная структура, тесты рядом. Это снижает визуальный сигнал «здесь что‑то подозрительно» и иногда делает review даже сложнее.

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

Например, предположить, что любой заказ со статусом FAILED можно повторить. Тест будет зелёным. Coverage — прекрасным. Но реальное правило может требовать сначала проверить состояние операции у внешнего провайдера, если запрос уже успел уйти.

Получается идеально протестированная ошибка.

На этом месте исследования становятся особенно интересными

В 2025 году METR провели рандомизированный эксперимент с 16 опытными open‑source разработчиками. Они работали над 246 реальными задачами в знакомых им зрелых репозиториях. До эксперимента разработчики ожидали, что AI сократит время выполнения задач примерно на 24%. После эксперимента они всё ещё считали, что ускорились примерно на 20%.

Фактический результат для этой выборки оказался обратным: с AI задачи занимали в среднем на 19% больше времени.

Источник: METR — Measuring the Impact of Early-2025 AI on Experienced Open‑Source Developer Productivity ^[1]

Эту цифру важно не превращать в универсальный тезис «AI замедляет разработчиков». Исследование измеряло инструменты начала 2025 года. В феврале 2026 METR выпустили обновление и прямо написали, что более современные агенты, вероятно, уже дают большее ускорение. При этом новый эксперимент столкнулся с сильным selection bias: разработчики, которым AI особенно полезен, не хотели регулярно работать без него, поэтому исследователи считают новые оценки ненадёжными для точного определения размера эффекта.

Источник: METR — We are Changing our Developer Productivity Experiment Design, 2026 ^[2]

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

Похожий конфликт виден и в DORA. В отчёте 2024 года рост AI adoption на 25% был связан с улучшением качества документации, качества кода и скорости code review. При этом тот же рост adoption был связан примерно с 1,5% снижением delivery throughput и 7,2% снижением delivery stability.

Источник: DORA — Accelerate State of DevOps Report 2024 ^[3]

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

В более свежем отчёте за 2025 год вывод уже не выглядит как «AI замедляет разработку». DORA скорее описывает его как усилитель существующих процессов в команде. Там, где разработка, тестирование и выпуск изменений хорошо организованы, AI помогает быстрее доставлять изменения. Но одновременно с ростом скорости увеличивается и нестабильность системы.

В обзоре 2026 года авторы сформулировали эту мысль ещё точнее: время, которое разработчик экономит на написании кода, не обязательно исчезает из процесса. Часто оно просто переносится на проверку результата — чтение сгенерированного кода, тестирование и поиск ошибок.

Источники: DORA — State of AI‑assisted Software Development 2025 ^[4] и DORA — Balancing AI tensions, 2026 ^[5].

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

Через три недели я стал давать агенту меньше свободы

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

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

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

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

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

Код перестал быть дефицитом

Это, пожалуй, самое заметное изменение.

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

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

Получается странная ситуация: создавать новый код стало намного дешевле, а понимать и сопровождать его — почти нет.

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

Что получилось через 30 дней

Я не стал пользоваться агентом меньше. Скорее наоборот. Просто перестал воспринимать количество сгенерированного кода как главный показатель его пользы.

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

Я специально не пишу, что с агентом разработка стала, например, на 37% быстрее. Чтобы делать такие выводы, нужно сравнивать хотя бы общее время от начала задачи до релиза, длительность ревью, количество возвратов на доработку и число проблем после выпуска. Такого чистого эксперимента я не проводил, поэтому придумывать красивую цифру здесь было бы неправильно.

Но одно изменение видно и без красивой метрики: когда производство кода стало дешёвым, bottleneck просто переехал.

Сначала — в понимание задачи. Потом — в review. Потом — в verification, интеграцию и release.