Не гоните на болиде в супермаркет: как подобрать стек ИИ-агента под задачу и не переплатить

Когда обсуждают разработку с ИИ, чаще всего говорят о моделях:

• Какая модель самая сильная?
• Какая лучше пишет код?
• Почему бы не использовать лучшую модель для всех задач?

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

Но модель определяет не весь результат. На него влияет вся цепочка:

Модель → Агент → Фреймворк разработки → IDE → Кодовая база → Задача

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

Модель: двигатель

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

Чем сложнее и неопределеннее задача, тем важнее возможности модели. Но для небольшого рефакторинга, типового теста или локального исправления самая дорогая модель может быть избыточна.

Проблема в том, что заранее выбрать идеальную модель сложно.

Разные модели могут взяться за одну задачу, но результаты будут отличаться:

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

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

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

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

Агент: шасси и управление

Агент определяет, как возможности модели превращаются в действия.

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

Поэтому одна и та же модель в разных агентах может по-разному рассуждать, планировать, выбирать инструменты и оценивать результат.

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

Поэтому агента приходится оценивать на практике:

• насколько предсказуемо он работает
• удобно ли контролировать изменения
• сколько лишних действий и итераций он совершает

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

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

Агент — это шасси и управление. Мощность дает модель, но агент определяет, как она будет использована на дороге.

Фреймворк разработки: правила движения

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

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

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

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

Model Context Protocol, или MCP, дает агенту доступ к внешним источникам и инструментам: документации, трекеру задач, базе знаний или внутреннему сервису.

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

Принцип простой:

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

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

Но сами спецификации относятся уже к конкретной задаче. И их создание не бесплатно.

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

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

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

IDE: приборная панель

Агент может работать без IDE: напрямую с репозиторием, терминалом или удаленной средой.

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

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

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

IDE — это приборная панель. Она влияет на то, что видит водитель.

Кодовая база: дорога

Агент работает с тем проектом, который уже существует.

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

На результат особенно влияют:

• структура проекта
• качество имен
• единый стиль
• актуальная документация
• воспроизводимый запуск
• автоматические проверки

ИИ продолжает существующие закономерности.

Если кодовая база пахнет, код ИИ тоже будет пахнуть.

Тесты и статические проверки создают обратную связь:

изменить → проверить → увидеть ошибку → исправить

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

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

Кодовая база — это дорога. На ровной трассе можно ехать быстро. На разбитом участке даже хорошая машина вынуждена снижать скорость.

Задача: пункт назначения

Качество задачи определяет, понимает ли агент, куда нужно приехать.

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

Задачи различаются по масштабу, неопределенности и цене ошибки.

Переименование переменной часто проще выполнить встроенным рефакторингом без ИИ. Неизвестный баг потребует исследования. Крупная фича — плана и спецификации. Критическое изменение — дополнительных проверок и участия человека.

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

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

Вывод

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

Но это дорогая компенсация.

Модель потратит больше контекста на исследование, сделает лишние попытки и создаст больше работы на ревью. При этом она не сможет соблюдать правило, которое нигде не записано, или пройти проверку, которой нет.

Поэтому не каждую проблему нужно решать повышением мощности.

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

Но и эти улучшения не бесплатны. Спецификации, skills, тесты, дополнительные итерации и проверки тоже расходуют время, токены и лимиты.

Результат определяет весь контур:

Модель → Агент → Фреймворк разработки → IDE → Кодовая база → Задача

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

Нет лучшей машины для всех дорог. Нет и лучшего стека для всех задач.

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

Так мы оптимизируем не мощность отдельных инструментов, а ценность результата.

ИИ выполняет работу. Человек выбирает машину, маршрут и правила движения.