Как работать с ИИ-агентами и не терять контроль над разработкой

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

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

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

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

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

Особенно показателен здесь опыт работы с внешними API: агент может неверно интерпретировать документацию и построить реализацию на ошибочном предположении. С такой ситуацией мы столкнулись при интеграции с сервисом электронного документооборота:

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

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

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

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

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

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

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

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

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

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

С несколькими агентами к этому добавляется координация. В другом эксперименте Anthropic 16 экземпляров Claude параллельно работали над C-компилятором на Rust. За две недели они создали около 100 тысяч строк кода и добились компиляции ядра Linux. При этом параллельная работа потребовала дополнительных механизмов координации: агенты могли конфликтовать при изменении общих файлов, а проверки становились узким местом.

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

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

Харнесс помогает автоматизировать часть этого пути. Агент получает правила проекта, запускает проверки и исправляет найденные ошибки до передачи работы дальше. При надежных тестах и налаженном CI/CD это может сократить срок от постановки задачи до релиза, но перегруженное ревью и неудобный процесс выкладки тоже придется разбирать.

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

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

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

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

Я бы отдавала агенту максимум механической работы, но оставляла контроль там, где ошибка дорого обойдется проекту. На практике это можно оформить в несколько правил:

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