AI-агенты и техдолг: помогают чинить или копят новый

За 2024–2025 годы генерация кода перестала быть автодополнением строки. GitHub Copilot получил режим агента, Anthropic выпустила Claude Code как терминальный инструмент, а OpenAI и другие показали агентов, которые сами читают репозиторий, вносят правки в несколько файлов и открывают пул-реквест. Продают их в том числе как средство от техдолга: попросите агента отрефакторить модуль, добавить тесты, обновить зависимости. Вопрос в том, действительно ли агент сокращает долг или переносит его в будущее в укрупнённом виде.

Что вообще изменилось

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

Это меняет и характер риска. Одну строку от Copilot разработчик прочитывал глазами за секунду. Пул-реквест на 600 строк, который агент собрал за пять минут, прочитать за пять минут невозможно. И вот здесь начинается разговор про техдолг.

Где агенты реально уменьшают долг

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

• Массовые механические миграции. Переезд с одной версии библиотеки на другую, замена устаревшего API по всему репозиторию, переименование во всех местах использования. Компилятор и тесты ловят ошибки сразу.
• Написание недостающих тестов для существующего кода. Тесты, которые никто не успел написать, — это тоже долг. Агент покрывает граничные случаи, о которых человек забывает.
• Разбор непонятного legacy-модуля. Не переписать, а объяснить: агент читает код и выдаёт документацию к тому, что делает функция. Это снижает не сам долг, а стоимость входа в него.
• Одноразовые скрипты и инфраструктурная рутина: парсеры логов, миграции данных, конфиги CI. Код, который живёт один раз, — идеальный кандидат: если он сработал, качество внутри вторично.

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

Где агенты долг наращивают

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

Техдолг — это не плохой код. Это код, чьё устройство никто в команде не может объяснить и не готов защищать на ревью. Агент производит именно такой код быстрее, чем человек успевает его понять.

Типичные способы нарастить долг:

• Дублирование вместо переиспользования. Агенту проще написать новую функцию, чем найти существующую с той же логикой. В большом репозитории появляются три реализации одного и того же.
• Локальные костыли под тест. Задача «сделай, чтобы тесты прошли» иногда решается подгонкой кода под тест, а не исправлением сути.
• Согласие вместо возражения. Модель не скажет «эту фичу вообще не стоит делать так». Она сделает, как попросили, даже если правильный ответ — отказаться.
• Иллюзия проверенности. Раз PR открыл агент и тесты зелёные, ревьюер расслабляется. Ответственность за код размывается.

Есть ли измерения

Публичных исследований, которые бы прямо мерили «прирост техдолга от агентов», на сегодня немного, и к громким цифрам стоит относиться осторожно. Отраслевые отчёты вроде ежегодного State of DevOps и исследований DORA фиксируют неоднозначную связь между интенсивным использованием ИИ и стабильностью поставки: скорость доставки растёт, но не всегда вместе с надёжностью. Конкретные проценты меняются от отчёта к отчёту — сверяйтесь с первоисточником за нужный год, а не с пересказом.

Сравнение подходов

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

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

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

Пригодится:

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

Скорее навредит:

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

Как не превратить агента в генератор долга

1. Давайте агенту задачи с измеримым результатом: есть тест, есть спецификация, есть чёткий diff-критерий приёмки.
2. Ограничивайте размер изменений. PR на 600 строк, который никто не прочитает, хуже, чем пять PR по 120.
3. Не отключайте человеческое ревью для агентских PR — наоборот, ужесточайте его.
4. Держите агента подальше от архитектурных решений: «как устроить модуль» — это к человеку, «примени решение по всему коду» — можно к агенту.
5. Периодически считайте, сколько времени команда тратит на исправление за агентом. Если больше, чем он экономит, режим нужно менять.

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