Почему AI-агенты такие медленные? Часть 1: Путь вайбкодера

Странный вопрос, не правда ли? У AI-агентов, конечно, есть разные проблемы, но вряд ли их можно обвинить в медлительности. Спросите, как говорится, любого, какие у него ощущения от AI, и первое, что вы услышите, будет что-то вроде: «AI за 3 часа сгенерировал мне 100 тысяч строк кода». Разве это можно назвать медлительностью?

На этом месте можно было бы и разойтись: 100 тысяч за 3 часа. Покажите мне человека, который способен хотя бы в половину этого, — и «я съем свою шляпу». Но я по‑прежнему утверждаю, что AI-агенты слишком медленные. Не верите? Добро пожаловать под кат…

Содержание

Данный материал состоит из двух статей.

• Первая — «Путь вайбкодера» — уже перед вами.

• Вторая — «Путь программиста» — появится немного позже.

Приятного чтения.

Путь вайбкодера

Первый вопрос программиста, услышавшего фразу про «100 тысяч за 3 часа», обычно такой: «Как ты отревьюил 100 тысяч строк за 3 часа?». Если в ответ вы слышите: «А зачем их ревьюить — я проверил, оно работает», поздравляю: перед вами типичный представитель клана вайбкодеров. «Как же ты будешь вносить изменения в кодовую базу на 100 тысяч строк?» — хотите спросить вы, на что получите ответ вида: «А я не буду там что-то править — за меня это сделает AI-агент».

Фраза «С AI-агентами программисты больше не нужны» — это, кажется, грааль IT-индустрии, золотая мечта. Опишите в паре абзацев, что вы хотите от системы, отдайте это AI-агенту — и вуаля: всё готово, перед вами система с дополненным функционалом. Похожий нарратив сейчас звучит повсюду: блогеры и инфлюенсеры рассказывают, что достаточно написать пару запросов в AI-агент — и система готова (обычно параллельно предлагая научить этому «простому навыку» на курсах). Но давайте вернёмся в реальность…

В реальности настоящие вайбкодеры работают с AI-агентами совсем по‑другому. Всё начинается с конфигурирования агента: добавления субагентов с нужными ролями (аналитик, разработчик, QA, специалист в конкретной области), настройки MCP, подключения набора навыков и команд.

Дальше пишется подробное ТЗ на предстоящую систему. Часто это выглядит как диалог: вайбкодер вместе с AI-агентом описывают поведение будущей системы или нового функционала в текущей. Всё начинается с одного‑двух абзацев, но документ быстро растёт, и вы замечаете, что скорость внесения изменений с помощью AI-агента заметно деградирует. Теперь, попросив AI-агента удалить одну строчку или одно требование, вы уже ждёте десятки секунд, а иногда и минуты, чтобы увидеть результат. Как же так вышло?

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

На первом этапе вы создали агента:

Ну что же: теперь, попросив нашего AI-агента‑аналитика написать постановку по любому входному промпту, вы с высокой вероятностью получите документ на 1000+ строк. В нём будут расписаны не только требования, но и этапы работ, модель данных, примеры API и много чего полезного для разработки. Кажется, отличный результат: за 10–15 минут ожидания у нас есть готовое ТЗ. Да, оно может быть излишне подробным, но, как говорится, больше — не меньше. Естественно, его нужно прочитать хотя бы по функциональным требованиям. Понимаю: это непросто, но всё же необходимо.

И вот, читая функциональные требования, вы замечаете, что какое-то из них вас не устраивает или его нужно поменять. Можно отредактировать самому, но кто знает, как это повлияет на остальной документ? Да и вообще: зачем делать самому, если есть AI-агент — попросим его внести нужные правки.

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

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

Ещё 20 минут назад у нас вообще не было никакого документа с требованиями. Чего мы на самом деле хотели? Описать функциональные требования к будущей системе. Однако теперь перед глазами документ, который включает набор информации, в будущем, возможно, полезной, но сейчас — малополезной. И мы пытаемся поддерживать его консистентность. Поэтому что? Правильно: эту часть можно просто удалить. Понимаю, это может быть непросто: «а вдруг там что-то важное». Но помните: ещё недавно этого текста вообще не было. Да, его можно прочитать перед удалением — но подумайте, стоит ли это вашего времени.

Можно, конечно, на время отказаться от редактирования через агента. Так и вправду можно поступить, но это, скорее всего, снизит вашу скорость. А в конце всё равно придётся попросить AI-агента переписать остальной документ в соответствии с новыми требованиями — то есть почти заново.

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

Проделав это, вы почувствуете, что отзывчивость AI-агента улучшится в разы. А теперь представьте, сколько бы пришлось ждать Льву Толстому, если бы после каждой правки «агент» переписывал половину главы, чтобы сохранить связность текста.

Дальше, осталось только попросить Senior Developer Agent последовательно запрограммировать все фичи, Senior QA Agent — их протестировать, а Senior DevOps — подготовить всё необходимое, чтобы приложение задеплоить в Kubernetes. Если раньше не было уверенности, что AI-агент сможет запрограммировать, протестировать и развернуть целую систему, то сейчас всё больше задач AI-агенты могут делать «под ключ». Вопрос часто упирается только в количество доступных долларов и токенов.

Правда, в итоге может получиться так, что сделано «не совсем то» и работает «не совсем так». Но разве не так же иногда работают команды людей? Уверен, каждый из нас оказывался в ситуации, когда функционал запрограммирован, протестирован и отдан заказчику, а потом заказчик приходит с требованием всё исправить — потому что он хотел, чтобы всё работало по‑другому. Но благо у нас то AI-агент: пишем ещё один промпт, чтобы сделал «как надо». Главное — не забудьте закоммитить изменения и создать ветку.

Поскольку вероятность того, что AI-агент признается в том, что чего-то не смог, ничтожно мала, он будет корпеть над задачей до тех пор, пока не «решит» проблему. Готовьтесь: это время может оказаться значительным — кодовая база уже, скорее всего, не маленькая. Если всё сложится успешно, AI-агент даст подходящее решение — поздравляю: вы получили «готовую систему за пару часов».

Но что если AI-агент ошибётся? К сожалению, в этой ситуации выход часто только один: просить AI-агента снова и снова чинить то, что не работает, в надежде на успех. Вы вошли с AI-агентом в «клинч»: будет казаться, что время уходит сквозь пальцы. Таков путь вайбкодера.

Вы скажете: «Я позову программиста — он потратит 2% времени, и всё заработает». Такое мнение и правда существовало ещё полгода назад, но сейчас, кажется, многие сходятся в том, что чинить то, что напрограммировал AI-агент в режиме вайбкодинга, крайне тяжело. Зачастую проще всё выкинуть и написать заново.

Можно попробовать начать сначала (завайбкодить), сменить модель, как-то подсказать AI, чтобы не попасть в «клинч» вновь, и надеяться, что в этот раз всё пройдёт благополучно — для вас и для AI-агента. Но можно ли снизить этот риск и при этом не потерять скорость?

Кажется, можно: нам всего лишь нужен тот самый 10х сотрудник с навыками программирования, тестирования и деплоймента. Издеваюсь ли я?

Сделать из обычного разработчика 10х специалиста будет очень тяжело, а может и невозможно. Но добиться результата в 3–5х, вероятно, реально — для этого нужно несколько вещей. Во‑первых, дать ему набор инструментов (в том числе AI-агента, но не только). Во‑вторых, научить его этими инструментами пользоваться — и это, конечно, сложнее, чем просто «выдать доступ». Но что мы получим на выходе и чем заплатим за эту производительность?

Самое важное свойство, которое у нас теперь появляется, — система больше не воспринимается как чёрный ящик (black box). Есть человек или команда, которые понимают, как эта система устроена, следят за качеством кода и архитектуры, а также за уровнем технического долга. А значит, в любой ситуации, когда AI не может справиться с задачей, есть человек, который пусть и со скоростью 0,25×, но разберётся, в чём всё‑таки проблема и как её исправить. Но об этом — в следующей части…

Если вы пишите на Spring с использованием ИИ-агентов, то попробуйте Spring MCP. Spring MCP – это тот набор инструментов, который нужен LLM для эффективной, корректной, быстрой и комфортной (как бы это не звучало :D) работы с проектом на Spring.