Как выпускать enterprise-quality код с AI agents без технического долга
Как повысить скорость разработки с помощью AI-assisted coding без похмелья от неконтролируемого технического долга
Разработчики разрываются между радостью — или давлением — от использования agents, которые позволяют сегодня выпускать код в 10 раз быстрее, и страхом того, как они будут поддерживать этот код завтра. Пропасть между «vibe» code и кодом, который можно разворачивать для миллионов пользователей, огромна и ее легко недооценить. Сокращение этого разрыва требует аккуратности, опыта и усилий, а отдача приходит позже. Agents уже способны выполнять все более сложные задачи программирования, но без нужного качества. Чего не хватает и как заполнить этот разрыв?
Почему code, созданный агентами, деградирует: проблема bloat
Enterprise code должен проходить три проверки: быть поддерживаемым, надежным и безопасным. Готовые AI agents могут не справляться со всеми тремя. Сосредоточимся на самой заметной проблеме поддержки — bloat: избыточной валидации, защитных проверках, которые не могут сработать, почти дублирующихся функциях, мертвом коде, который никто не удаляет. Проверка None для параметра, типизированного как dict. try/except вокруг вызова, который никогда не выбрасывает исключение. Две функции, идентичные, кроме отрицания в операторе возврата.
Bloat сильно зависит от модели. LLM Leaderboard от Sonar прогоняет каждую frontier-модель через 4 400+ Java-задач и анализирует сгенерированный код. Чтобы пройти бенчмарк, GPT-5.4 High сгенерировала 1 159 000 строк кода при показателе прохождения 81,05%, тогда как Claude Opus 4.7 Thinking сгенерировала лишь 336 000 строк кода и показала результат выше 82,52%. Разные модели создают радикально разный код, добиваясь похожих результатов.
Bloat — это не просто неряшливость. Исследователи Carnegie Mellon изучили 807 open-source-проектов, которые начали использовать Cursor, сопоставив их с 1 380 контрольными проектами и измеряя их через SonarQube. К третьему месяцу краткосрочный прирост скорости исчез, а предупреждения статического анализа выросли на 30%, а сложность кода — на 41%; оба показателя остались на этом уровне. Чем труднее становилось менять кодовую базу и чем больше багов в ней было, тем сильнее падала скорость. Любой опытный разработчик знает, чем это заканчивается: проблемы качества накапливаются, пока код не начинает казаться невозможным для изменений, и остается только страшный rewrite.
Когда модель используется на практике, bloat создают три силы:
- Агенты не чувствуют бремя поддержки. Armin Ronacher, создатель Flask, говорил об этом в подкасте Pragmatic Engineer в конце апреля. Люди со временем ощущают цену плохого кода, и, как выразился Ronacher, «если боль становится слишком сильной, у вас как у человека появляется стимул устранить причину этой боли» — поэтому мы делаем refactor. Agents этого не чувствуют. Они бездумно наращивают плохую структуру бесконечно. Задача senior engineer — говорить «нет» ненужной абстракции. У агента нет такого рефлекса.
- Обучение поощряет видимую полноту. Корпуса pretraining полны объясняющих материалов — ответов Stack Overflow, туториалов, фрагментов README — специально самодостаточных и многословных. Post-training усиливает эффект: человеческие оценщики предпочитают ответы, которые выглядят обстоятельно, поэтому модели учатся, что «comprehensive» выглядит лучше. Если неясно, какой edge case важен, безопаснее обработать их все. Каждая отдельная проверка локально оправдана. В сумме получается bloat.
- Итеративная генерация не создает давления на удаление. Агенты добавляют, но редко удаляют. Удаление мертвого кода не делает ни один тест green, поэтому устаревшие функции накапливаются рядом со своими заменами. SlopCodeBench, мартовский бенчмарк 2026 года по 11 coding-моделям, показал рост структурной сложности в 80% траекторий и рост многословности в 89,8%. Агенты продолжают латать плохой код, словно каждая задача у них последняя.
AC/DC: петля, которая компенсирует
Разрыв закрывает цикл вокруг каждой итерации работы агента. Агент делает то, что умеет лучше всего, — генерирует код, — а наша задача состоит в том, чтобы обернуть это тремя шагами, которые агент не может надежно выполнять сам по себе. В Sonar это называют Agent Centric Development Cycle, или AC/DC: guide, verify, solve.
Guide
Многие команды чрезмерно компенсируют контекст. Они вставляют в инструкции агента style guide, трехлетнюю историю архитектурных решений и весь onboarding doc и ожидают, что результат улучшится. Исследователи ETH Zurich проверили это и обнаружили обратное: большие контекстные файлы часто снижали успешность выполнения задачи по сравнению с полным отсутствием контекста и добавляли 20% или больше к стоимости inference.
Контекст для агента должен быть коротким — полезный ориентир: меньше 200 строк — и содержать только базовые вещи, которые нельзя легко вывести из кода: соглашения по именованию, архитектурные инварианты, что уже пробовали и что не сработало. Но этого хватит только до определенной степени, поэтому для каждой задачи нужно давать конкретный контекст. Если у вас есть архитектурные ожидания, не рассчитывайте, что агент их угадает. Дополнительный контекст в фазе guide могут давать инструменты software architecture.
Форма задачи тоже важна. Разбейте работу на шаги и согласуйте план; попросите агента предложить три решения и оценить влияние каждого на качество. Идеальной software architecture не существует, а trade-offs в вашей codebase лучше всех понимаете вы, поэтому критически оцените изменения до их появления. Без этого агент уверенно выберет вариант, как будто случайно, а чем дальше он зайдет, тем сложнее будет все «распутывать». Если хотите проверить это, попросите три экземпляра предпочитаемого агента выполнить задачу с некоторой polymorphism и посмотрите, как каждый уверенно предложит разное решение.
Verify
Самая дорогая ошибка верификации — делать ее последней. Просмотр pull requests по 200 строк после того, как агент закончил работу, и лежит в основе цифр Faros/DORA, на которые ссылался Addy Osmani: в командах с высоким уровнем внедрения PR-ов мержится на 98% больше, а время ревью растет на 91%. Верификация внутри цикла устроена иначе. Прогоны unit tests, static analysis и security scanners дают вывод, на который агент может сразу реагировать. Именно здесь и должно быть AI-native tooling: инструментам нужно быть специально созданными для вызова агентом, а не только для просмотра человеком через UI.
Люди-ревьюеры не успевают. Когда агенты мержат вдвое больше PR в неделю, а на проверку каждого уходит почти вдвое больше времени, удвоение числа ревьюеров все равно оставляет вас позади. Автоматическая верификация — единственный масштабируемый ответ. Быстрая обратная связь всегда была фундаментальным принципом хорошей software engineering. Если отдавать ее агенту напрямую, это защищает разработчика от простых ошибок и оставляет ему ресурс на более сложные.
Solve
Если верификация происходит внутри agentic loop, агент может исправлять проблемы прямо во время генерации кода, без дорогих remediation-этапов. Инструменты static analysis могут подсказывать агенту, как быстро устранить проблему. В некоторых случаях нужен человеческий judgment — например, проверка None на границе системы может фиксировать реальную precondition. Но большая часть работы механическая. Автоматизируйте очевидные исправления и дайте инженерам тратить внимание на те случаи, которые не очевидны.
Инвестиция, которая накапливается
Более совершенные модели будут появляться и дальше. Возможно, они не изменят механизм bloat или динамику накопления деградации. Это делает именно цикл — ограниченные задачи, точный контекст, верификация внутри цикла и осознанный шаг solve, который убирает bloat до того, как он накопится.
Та же логика определяет, как должна расширяться автономность. Сокращайте число вмешательств человека только тогда, когда цикл guide, verify, solve действительно делает их лишними. Здесь наши когнитивные искажения могут сыграть против нас: способность агента писать код может заставить нас соглашаться с ним чаще, чем следует. Не доверяйте слепо; ждите доказательств.
Команды, которые будут выпускать enterprise-quality code с AI agents через 18 месяцев, — это не те, кто используют «лучшую модель». Это те, кто относятся к workflow как к инженерной инвестиции, с той же серьезностью, с какой раньше относились к build systems и CI. Модель — это инструмент, workflow — это дисциплина. Именно здесь и накапливается устойчивое преимущество.
—
New Tech Forum предоставляет площадку для технологических лидеров — включая вендоров и других внешних авторов — чтобы подробно обсуждать новые enterprise-технологии. Отбор субъективен и основан на том, какие технологии редакция считает важными и наиболее интересными для читателей InfoWorld. InfoWorld не принимает к публикации маркетинговые материалы и оставляет за собой право редактировать все присланные материалы. Все запросы направляйте на doug_dineley@foundryco.com.
Материал — перевод статьи с английского.