Coding-агенты в enterprise: где они работают, а где ломаются

За 2024–2025 годы coding-агенты перестали быть демо-роликами. Anthropic выпустила Claude Code — терминальный агент, который читает репозиторий и вносит правки; Cursor превратился из редактора в среду с автономным режимом; GitHub довёл Copilot до уровня, где тот открывает pull request'ы сам; стартап Cognition показал Devin, который позиционируется как автономный инженер. Все они решают одну задачу — переложить рутину написания кода на модель. И все упираются в одну и ту же стену, когда попадают из пет-проекта в контур крупной компании.

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

Что вообще умеет coding-агент

Coding-агент¹ — это не автодополнение в редакторе. Это цикл, в котором модель получает задачу, читает контекст (файлы, историю git, вывод тестов), формирует план, вносит изменения, запускает проверки и по результату корректирует себя. От обычного автокомплита его отличает автономность: он делает несколько шагов подряд без участия человека.

На практике это разворачивается в три уровня зрелости, и путать их — главная причина завышенных ожиданий:

• Подсказка в строке. Копайлот дописывает текущую функцию. Контекст — открытый файл и пара соседних. Риск минимальный, человек видит каждый символ.
• Задача в чате. Вы просите «добавь эндпоинт и тест к нему», агент трогает несколько файлов, показывает диф. Человек проверяет и принимает.
• Автономный прогон. Агент получает тикет, сам разбивает на шаги, правит код, гоняет тесты, открывает PR. Человек включается только на ревью — и вот здесь начинаются настоящие вопросы enterprise.

Сравнение популярных инструментов

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

Числовых бенчмарков в таблице нет намеренно: публичные метрики вроде SWE-bench меряют способность закрывать изолированные issue из open-source, а не работу внутри закрытого легаси с внутренними зависимостями. Переносить процент с бенчмарка на вашу кодовую базу некорректно.

Где агент ломается в enterprise

Контекст не помещается

Контекстное окно² современных моделей выросло до сотен тысяч токенов, но корпоративный монолит на этом фоне — капля. Агент физически не может «увидеть» всю систему целиком. Он работает по фрагментам, а значит не знает про неявные контракты: что вон тот сервис ждёт поле в определённом формате, а вот эта таблица не индексируется по бизнес-причине. RAG³ и индексация репозитория смягчают проблему, но не убирают её: агент восстанавливает картину по кускам и иногда достраивает несуществующее.

Данные, которые нельзя показывать

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

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

Цена ошибки и ревью-бутылочное горлышко

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

Ответственность

Кто отвечает за баг, который написал агент? Юридически и организационно — тот, кто нажал «merge». Модель ответственности не несёт. Это значит, что агент никогда не выходит за пределы зоны, которую человек готов подписать своим именем. В enterprise эта зона очерчена регламентами, и она уже, чем в стартапе.

Кому это пригодится, а кому нет

Пригодится:

• Командам с плотным покрытием тестами: у агента есть объективный сигнал «сломал / не сломал», и автономный прогон становится безопаснее.
• На типовой рутине: миграции, переименования по всей базе, генерация boilerplate, написание тестов к существующему коду, разбор незнакомого репозитория.
• Для быстрого прототипа внутреннего инструмента, который не идёт в прод и не касается чувствительных данных.

Не стоит рассчитывать:

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

Как встроить агента без сюрпризов

1. Определите, какие данные вообще можно показывать модели, и выберите режим или развёртывание под это ограничение — до первого запуска, а не после.
2. Начните с уровня «задача в чате», где человек принимает каждый диф, и поднимайтесь к автономности постепенно.
3. Запускайте автономные прогоны только там, где есть тесты и CI, которые ловят регресс.
4. Не сокращайте ревью под предлогом «код же написал агент» — наоборот, к сгенерированному коду ревью строже.
5. Замеряйте не строки кода, а время до мёржа и число багов в проде: только так видно, экономит агент или перекладывает работу.

¹ Coding-агент — программа на базе языковой модели, которая автономно выполняет цикл «прочитать контекст → спланировать → изменить код → проверить», а не просто дополняет текст.

² Контекстное окно — объём текста (в токенах), который модель может держать «в поле зрения» за один запрос. Всё, что не влезло, для модели не существует.

³ RAG (retrieval-augmented generation) — подход, при котором нужные фрагменты кода или документации находятся поиском и подставляются в запрос к модели, вместо того чтобы держать всё в контексте сразу.