Как я начал использовать ИИ-агентов для разработки в 2026 году

Последние пару лет я ежедневно читал статьи об очередном прорыве технологий или успешном внедрении ИИ и росте продуктивности x10. Не потому что это интересно — просто ничего другого почти и нет.

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

Содержание

Предыстория

На одном из моих проектов одно время была поддержка двух версий API с одинаковым отображением данных. Для этого было реализовано приведение ответов к общему формату, который не соответствовал ни одной из версий.

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

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

На основании изученного опыта успешных экспертов разработки с LLM, я пошёл по эталонному сценарию: планирование -> ревью планирования -> реализация -> …

PR получился так себе. Сейчас мне сложно привести конкретные примеры, что именно было не так. Скорее просто интуитивно не готов сливать или даже отдавать в тестирование/ревью. Местами кажется, что что-то не учтено, местами просто что-то не то.

Всё это заняло порядка 30 часов. В каждой новой сессии модель с 200k контекста делала сжатие контекста почти на старте.

С этим неудовлетворительным результатом я пошёл к более продвинутому пользователю ИИ. Он взял мой исходный промпт и дописал что-то на уровне «сделай». Через пару часов был готов второй PR, который выглядел намного лучше. Были стилистические комментарии или замечания в местах, где нужно принять более жёсткое решение, но, в целом, было похоже на правду.

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

Осознание пользы

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

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

Мой опыт совпадает с этим комментарием с HN:

I find that some of my friends and acquaintances have gotten obsessed with prompting style, “prompt engineering”, which skills to use, which skills to build, “context engineering”, and a billion other variations on “how to write smart things so the model does good”.

Friends, look at the prompts that Anthropic’s own people are putting into the machine:

> A few hours after the first message, we found that Claude was still searching for simple attacks and sent a message: “no again the goal is that we have highly inteligent [sic] model as good top researcher, we want to find new attacks”;

> The next morning, Claude wanted to try to change the target to a different cipher; we reminded the model: “no we don’t want to change the targets […] agian [sic] we need to find something that worth [sic] publishing”;

> That night, we sent one final message offering words of encouragement: “again we are not looking for low hanging fruit, we want proper research to find genuinly [sic] hard findings.”

All of that RLHF and fine-tuning effort is going toward making prompts like this, or worse, work with no fuss.

Подробнее про использование

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

В первую очередь стоит обозначить границы. Я мейнтейнер на проекте: мне совсем не всё равно, какими будут код и реализация в каждой отдельной задаче. Также я веду продуктовый и технический бэклог как в трекере, так и в голове. Я понимаю как может измениться проект через 3-6 месяцев и постоянно учитываю это.

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

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

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

Мне важно, чтобы оставленные мной комментарии не требовали повторения при каждом ревью. Так агентская разработка становится ближе к аналогии цифрового двойника или управления разработчиком. Но мне не нравятся обе эти аналогии. Я потратил около недели, пытаясь заставить LLM не притворяться человеком, но сдался.

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

Агенту нужны инструменты: как MCP, так и локальные скрипты или тесты. Без инструментов агент, скорее всего, не сможет провалидировать результат или провести более глубокое исследование. Иногда инструменты нужны и для работы с агентом. Например, для одного из проектов я создал локальный инстанс Gitea, чтобы взаимодействовать с агентом через issues, pull requests и комментарии в них.

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

Ретро на начало года

В начале года я уже писал о том, как использую ИИ-агентов для разработки (никак). Несмотря на категоричность предыдущей статьи, я почти во всём согласен с ней. Я был не прав только относительно автономности работы агентов. Причиной было большое количество шума вокруг prompt engineering.

Забавно, что мне действительно потребовалась всего неделя, чтобы внедрить ИИ в свою работу. Пара дней ушла на настройку инструментов (чаще всего я просто говорил агенту донастроить себя) и ещё несколько дней на наполнение «памяти» моими паттернами разработки и информацией о проектах. Порог входа практически отсутствует. Я не понимаю, на что делают ставку разработчики с небольшим опытом, которые работают исключительно через LLM.

И, несмотря на ощутимую пользу, я всё ещё считаю себя скептиком. Не вдаваясь в подробности, оставлю ссылку на статью Why I remain a skeptic, с которой согласен практически по всем пунктам.

Также хочется упомянуть хороший разбор драмы вокруг Zig и Bun: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke. По-моему, статья освещает важный факт, который обычно игнорируют: Anthropic не может считаться доверенным источником информации. Они просто не могут быть объективны и имеют прямую заинтересованность в продаже технологии. Я считаю, что весь хайп вокруг ИИ инициирован именно маркетингом Anthropic и других компаний, а не успешностью технологии.

А ещё в этой статье затраты на миграцию оцениваются в $165,000 стоимости токенов на 11 дней работы. Думаю, за ~13 миллионов рублей многие люди были бы готовы выполнить аналогичную миграцию в те же сроки.