Habr AI: how expensive LLMs became state managers and reduced development costs

На Habr AI вышел разбор архитектуры AI-разработки, в которой дорогая LLM больше не пишет код сама, а управляет более дешёвым исполнителем. Автор утверждает, что такая перестройка помогла убрать бесконечные циклы ошибок, сократить контекст и заметно снизить расходы на API.

Где ломались агенты

Команда начала с популярного пути: взяла Aider и встроила его в CI/CD, чтобы агент автоматически обновлял документацию после изменений в коде. Для этой задачи инструмент сработал хорошо и снял часть технического долга. Но когда ему попытались отдать полный контур разработки — от бэклога и ТЗ до кода и тестов — система быстро упёрлась в ограничения.

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

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

Зачем менять роли

Во время тестов команда заметила, что у разных моделей действительно есть рабочий «характер». Gemini 3 Pro ведёт себя как слишком уверенный разработчик и может уйти от исходного ТЗ. MiniMax M2.5, наоборот, осторожничает и читает полпроекта, прежде чем сделать первый шаг. Claude Sonnet 4.6 показал лучший баланс между автономностью и дисциплиной, но использовать его на каждом мелком действии оказалось слишком дорого для стартапа. Именно отсюда и выросла новая идея: сильную модель нужно ставить не на рутину, а на контроль.

«Генеральный директор не делает холодные звонки».

Вместо схемы, где дорогая LLM пишет самый сложный код, команда ввела несколько жёстких правил: * Один агент ведёт одно ТЗ от начала до конца и сам же исправляет свои ошибки.

• Агент работает только с ограниченным «рабочим столом» из 5–8 файлов, а не со всем репозиторием.
• При закрытии файла он сохраняет краткую память о полезных находках, чтобы не таскать в контекст исходники целиком.
• Самая умная модель не кодит руками, а выступает менеджером состояния для дешёвого воркера.

Как работает менеджер В новой архитектуре дешёвая и быстрая LLM

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

• Обновляет память: переменные, решения, найденные конфликты библиотек и тупики.
• Проверяет, есть ли смысл продолжать, или задача упёрлась в ограничения инструментов.
• Формулирует чёткую директиву, как воркеру двигаться дальше и обходить ошибки. Самый интересный приём — способ передачи этих указаний. Рекомендации менеджера, кроме блока памяти, подаются воркеру как новое сообщение пользователя. За счёт этого исполнитель воспринимает инструкции как приоритетные и меньше спорит с ними. Параллельно система очищает его прошлую переписку с логами и ошибками, чтобы начать новый цикл с «чистым окном». Риск у такой схемы тоже есть: если менеджер неверно интерпретирует логи и запишет ложный факт в память, воркер будет упрямо следовать ошибочному курсу. Но автор пишет, что в аналитической роли дорогая модель галлюцинирует гораздо реже, чем при прямой генерации кода. Дополнительный эффект — тесты и документация начинают появляться вместе с задачей по умолчанию, а разработчики смещаются из роли ручных исполнителей в роль операторов и архитекторов процесса.

Что это значит

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