Сейчас агентов пишут все. Ваш сосед пишет агента. Ваш кот, вероятно, тоже, просто пока не пушит на GitHub. И если вы ещё не начали, то как минимум думали об этом в душе, прикидывая архитектуру между шампунем и кондиционером.
Чем интересен именно кодинг-агент? Это идеальная ловушка для самоуверенного разработчика.
Цель кристально ясна: читай код, пойми его, измени, проверь. Что может пойти не так? (Спойлер: вообще всё.) Под этой обманчивой простотой скрывается хаос — модели, которые обходят ваши ограничения с грацией уличного кота, инструменты, ломающиеся способами, о которых вы не подозревали, и промпты, которые прекрасно работают ровно до момента обновления модели на одну минорную версию. (да да, я тоже чувствую что это писал AI, но в таком мире живем)
Я построил такого агента, тут расскажу что я узнал — и, надеюсь, этого хватит, чтобы вы захотели повторить мой путь. Или хотя бы посочувствовать.
Что я собственно построил
Назвал я его QuillCode. Звучит солидно, а внутри — вот что:
Терминальный UI на ratatui: два потока ОС, один для интерфейса, другой для агента. Пока один рисует красивые рамочки, второй решает судьбу вашего кода.
Цикл агента: вызвать LLM, выбрать инструмент, выполнить его, скормить результат обратно. Повторять до просветления (или исчерпания токенов — что наступит раньше).
Восемь инструментов: поиск файлов, чтение кода через AST (не просто тупой дамп строк), патчинг через unified diff, выполнение shell-команд, веб-поиск и TODO-список, который агент ведёт сам. Да, он организованнее меня.
Система разрешений: чтение — пожалуйста, запись и shell-команды — только с одобрения. Демократия в рамках отдельно взятого терминала.
Сжатие контекста, режим планирования и режим поведенческого дерева, который заставляет агента идти по фиксированной последовательности шагов, хочет он того или нет. Иногда нужна твёрдая рука.
Работает ли это? Да, реально работает. Я гонял его на настоящих задачах — крупный рефакторинг через режим плана, где агент методично прошёл через список из 12 пунктов, пока я одобрял каждый шаг; небольшая LMS-система, которую я подкинул ему как бенчмарк — он собрал что-то похожее на правду и довольно функциональное.
Все же оговорюсь, что значит «работает». Он заметно менее эффективен, чем Claude Code. Требует больше присмотра. Иногда принимает решения, от которых хочется закрыть крышку ноутбука и пойти гулять. Для серьёзной работы я возьму Claude Code не задумываясь.
Но эффективность не была целью. Целью было понимание. И вот как оно выглядит.
Инструменты: кажется просто, пока не попробуешь
Восемь инструментов. Больше вам, скорее всего, не нужно.
Исследования поведения агентов стабильно показывают деградацию после примерно десяти инструментов. Модели начинают путать похожие инструменты, вызывать их не в том порядке и — мой любимый баг — изобретать инструменты, которых не существует. «А давайте-ка я вызову super_mega_refactor!» Нет, дружок, такого у тебя нет.
Восемь — это уже достаточная площадь для катастрофы.
Возьмём read_objects. Наивный инструмент «прочитай файл» на файле в 4000 строк мгновенно забивает контекстное окно — модель вываливает всё содержимое и у неё не остаётся места даже подумать. Поэтому read_objects принимает диапазоны строк и имена символов через парсинг AST. Модель вынуждена просить именно то, что ей нужно. Описание начинается так: «Используйте для чтения конкретных секций файла. Не вызывайте на весь файл, если он не маленький.» Это ограничение не зашито в код. Оно зашито в текст на английском языке. В тот день, когда я убрал это предложение, потому что оно показалось избыточным, качество вызовов заметно просело. Одно предложение. На естественном языке. Определяло поведение системы. Добро пожаловать в 2026 год.
Или patch_files — патчинг через unified diff вместо замены всего файла. Diff меньше (меньше токенов), его можно проверить глазами (видно, что именно изменилось) и сложнее случайно повредить соседний код. Компромисс: генерировать валидные диффы для модели сложнее, чем выплюнуть весь файл целиком. Вы будете видеть кривые диффы. Контекст не совпадёт, номера строк уедут на единицу, патч применится не к той функции. Надежность здесь — это и есть настоящая задача.
Когда инструмент ломается, модель импровизирует
Вот об этом вас никто не предупреждает. И это, пожалуй, самое увлекательное наблюдение.
Я раз за разом видел это в трейсах. patch_files падает — кривой diff, несовпадение контекста, что угодно — и следующий вызов в трейсе: shell_exec с sed -i, чтобы сделать ту же правку через шелл. И это работает. Но обходит валидацию патча, отслеживание разрешений, аудит. Модель не была злонамеренной. У неё была цель, основной путь заблокировался, и она нашла обходной. Абсолютно логичное поведение, которое создаёт именно ту поверхность атаки, от которой вы строили всю систему инструментов.
Ещё парочка граблей, на которые я наступил:
find_filesс настолько широким glob-паттерном, что он нашёл сотни файлов, после чего агент началread_objectsна каждом последовательно — весь бюджет вызовов сгорел в одной фазе разведки. Как турист, который фотографирует каждый камень в музее.shell_execсcatsomefile.rs, когда рядом лежал специальный инструмент для чтения. Модель просто забыла, какой инструмент для чего. Так и не смог от этого полностью отучить.Агент зацикливается на одном и том же падающем вызове три раза подряд, каждый раз чуть меняя аргументы, вместо того чтобы остановиться и подумать.
Unicode и ANSI escape-коды в результатах инструментов ломают парсинг следующего ответа LLM, что триггерит очередной
shell_execдля очистки. Домино из костылей.
Рецепт один и тот же: сделайте основные инструменты настолько надёжными, чтобы аварийный выход через шелл был непривлекателен. И конкретные сообщения об ошибках решают всё. «Error: patch failed» — модель попробует что-то другое. «Hunk 2 did not apply: expected fn process( on line 47, found fn process_item( — try re-reading the file before patching» — модель обычно сделает именно это, и следующая попытка будет успешной.
Проблема разрешений, или демократия в терминале
Принцип прост: чтение — автоматически, запись и шелл — с подтверждением. Реализация тоже проста. Калибровка — вот где начинается настоящая боль.
Если каждый shell_exec — включая рутинные cargo check, npm test, git status — требует явного подтверждения, пользователь через десять минут жмёт «разрешить на всю сессию». И вот вы потратили кучу инженерных усилий на систему, которая на практике производит один результат: один клик в начале сессии. Театр безопасности, билет в один конец.
Настоящий вызов — не сама проверка разрешений. А понимание, когда система должна доверять контексту, а когда — настаивать на вопросе. Я пока не нашёл правильный баланс. Возможно, это самая сложная дизайн-задача во всём проекте. (И, честно говоря, я не вижу, чтобы кто-то решил её хорошо в других агентах — разве что считать YOLO за решение).
Один агент, много диалектов
Моё наивное предположение номер два: раз OpenAI интеграция работает, добавить другого провайдера — дело часа. Новые DTO, новый транслятор, подключить. Подержите моё пиво.
Механическая часть действительно была нормальной. Поведенческая — всё сломала.
Каждая модель — каждая версия каждой модели — настроена по-разному, реагирует на промпты по-разному, ломается по-разному и по-разному терпит ваши формулировки. Нельзя написать один системный промпт, один набор описаний инструментов, один набор инструкций и ожидать консистентного поведения. Что для одной модели — чёткая команда, для другой — философское размышление. Что одну держит в фокусе, другую парализует.
Мне даже не пришлось менять провайдера, чтобы это увидеть. В середине разработки OpenAI выпустил gpt5.3-codex. Я обновился, ожидая плавного перехода. Вместо этого агент перестал действовать. Он читал файлы, выдавал вдумчивый анализ того, что нужно изменить — и... ничего не делал. Просто пересказывал. Никаких патчей, никаких правок, никаких вызовов инструментов, которые реально трогали код. Из деятеля превратился в литературного критика.
Те же самые промпты, которые прекрасно работали с gpt5.2-codex, теперь производили агента-рассказчика.
После ковыряния в исходниках codex и переписывания фрейминга действий в системном промпте, подсказок по бюджету вызовов и нескольких описаний инструментов — он снова начал работать. Но до пиковой производительности так и не дотянул. Я сдался. Жизнь коротка.
Поэтому мой агент поддерживает только OpenAI. Не потому что добавить HTTP-клиент другого провайдера сложно — это как раз тривиально. А потому что каждая модель — это новая поведенческая поверхность, которую нужно настраивать, тестировать и поддерживать. Это не инфраструктурная проблема. Это проблема бесконечной калибровки, и стоимость растёт с каждым добавленным провайдером.
Заглядываем под капот другим агентам
Я интегрировал трейсинг-платформу OpenAI в своего агента — каждый запуск становится трейсом с дочерними спанами на каждый вызов LLM, каждое использование инструмента, каждую проверку разрешений. Полные пейлоады, счётчики токенов, латенси. Когда что-то идёт не так (а с LLM вы почти никогда не можете воспроизвести баг детерминированно — это вам не NullPointerException), открываешь дашборд и смотришь выполнение шаг за шагом.
Это быстро стал самым полезным инструментом отладки в проекте.
Потом я подключил тот же трейсинг к Codex и OpenCode. Запустил одинаковые задачи. Сравнил трейсы бок о бок.
Скелет тот же. Тот же цикл. Та же цепочка: вызов-инструмента / наблюдение / вызов-инструмента / наблюдение. Тот же паттерн «сначала читай, потом пиши».
Их агенты, конечно же, существенно отполированнее — лучше описания инструментов, более изощрённое управление контекстом, более элегантная обработка краевых случаев — но фундаментальная форма узнаётся мгновенно. Никакой секретной архитектуры. Просто цикл и месяцы кропотливой итерации над всем, что его окружает.
Это было прояснительно так, как чтение статей об агентах никогда не было.
RAG? Спасибо, нет
Также закрыл для себя вопрос, над которым я колебался: стоит ли пробовать RAG.
В начале 2024-го общепринятая мудрость гласила: собери векторное хранилище, заэмбедди документы, доставай релевантные куски перед каждой генерацией. Для некоторых приложений — разумно. Для кодинг-агента — путь в никуда.
Кодинг-агенту не нужен вероятностный поиск. Ему нужно знать точно, как выглядит код.
RAG добавляет индексирующий пайплайн, который должен оставаться синхронизированным по мере изменения файлов, шаг извлечения, который может выдать не тот кусок из-за семантического пересечения между несвязанными функциями, и слой косвенности между агентом и тем, что ему реально нужно увидеть. Файл — это ground truth. У агента есть инструменты, чтобы его прочитать. Просто дайте ему прочитать.
Инфраструктурная рутина, или Claude Code + Opus 4.5
Всё вышеописанное — про новые, действительно новые проблемы, с которыми до эпохи агентов никто, в таких количествах, не сталкивался. Этот раздел — про старую добрую инженерную боль: построить инфраструктуру, на которой всё это крутится.
Для выбранного мною языка не было официальной клиентской библиотеки OpenAI. «Не проблема», — подумал я. У меня есть Claude Code с Opus 4.5. Документация API есть, опенсорсные примеры на других языках есть. Один хороший промпт — и готово.
Не готово. API LLM-провайдеров на удивление нетривиальны. SSE-стриминг, который нужно парсить инкрементально. Формат ответа, который меняет форму в зависимости от того, возвращает модель текст, вызов инструмента или частичный поток токенов. Обработка ошибок на двух уровнях — HTTP и API. Мне пришлось самому читать документацию (я знаю, шокирующе), проходить через падающие запросы в отладчике и принимать осознанные архитектурные решения, прежде чем Claude Code смог построить что-то надёжное.
Вот паттерн, в который я упирался снова и снова: Claude Code был быстр, когда я давал ему структуру, но не мог надежно создать эту структуру сам. До того, как ключевые дизайн-решения были приняты, каждая сгенерированная попытка содержала тонкие баги, проявлявшиеся только в рантайме. После — работало замечательно.
Модель разговора в моём агенте:Session└─ Request (один на пользовательский промпт) └─ Steps[] ├─ UserPrompt ├─ AssistantMessage ├─ ToolCall { name, args } └─ ToolResult { output }
API OpenAI ожидает плоский массив сообщений с полем role и пейлоадами, меняющими форму в зависимости от роли. Маппинг между моими доменными типами и wire-форматом кодирует решения о том, что означает история разговора — какие шаги становятся контекстом, как результаты инструментов вплетаются обратно, что выбрасывается при сжатии. Эти решения не генерируются из API-спеки. Их нужно принять.
src/infrastructure/openai/
├── client.rs # HTTP, аутентификация, ретраи
├── dto/
│ ├── request.rs # ChatCompletionRequest и вложенные типы
│ └── response.rs # ChatCompletionResponse, ToolCall и т.д.
└── translator.rs # ChainStep → ChatMessage ← самый интересный файл
Зато потом, когда этот слой был надёжен, добавление поддержки изображений — вставить скриншот, чтобы агент рассуждал о нём через vision API — я полностью отдал Claude Code. Заработало с первого раза. Инвестиция в фундамент окупилась.
Зачем вам это строить
Мой агент — это и близко не конкурент Claude Code. Он менее надёжен, требует больше присмотра, и разрыв в качестве на сложных задачах — значительный. Большую часть этого разрыва не закроешь инженерией — это фундаментальная сложность работы с чем-то недетерминированным, непрозрачным и не обученным специально под эту задачу.
Но путь стоил каждого мучительного вечера. Отладки трейсов. Погоня за описанием инструмента, в котором не хватало одного предложения. Открытие, что ваш инструмент работает в 95% случаев, но этих 5% хватает, чтобы модель перенаправила всё через shell_exec.
Инженерная поверхность необычно разнообразна — потокобезопасность, парсинг AST, промпт-инжиниринг, управление контекстом, персистентность сессий, системы разрешений — всё в одном проекте, всё взаимодействует друг с другом. Это инженерно интересно так, как большинство пет-проектов обычно не бывают.
А за пределами инженерии вы выходите с интуицией, которую невозможно получить иначе. Когда Claude Code принимает странное решение, жжет токены в цикле или задаёт неожиданный уточняющий вопрос — я теперь вижу почему. Я вижу цикл, цепочку, бюджет инструментов. Эта ментальная модель определяет, как я пишу промпты, как структурирую задачи и — самое полезное — как решаю, что отдать ИИ, а что делать самому.
Попробуйте сами. Потратите сильно больше одних выходных.
Комментарии (28)
powerman
07.03.2026 15:46Как побороли неспособность моделей надёжно формировать diff? Вообще кто-то из крупных игроков (Cursor, Copilot, Claude Code, …) использует diff как основной формат для редактирования файлов моделями?
Удалось ли полностью избавиться от использования шелла для тех задач, которые решать должен другой инструмент?
John_Carter Автор
07.03.2026 15:46Codex использует немного модифицированный Unified Diff (тот что уже сто лет использует git) - поэтому OpenAI модели очень хорошо умеют под него генерировать изменения, даже множественных файлов в одном вызове - с этим не было проблем. И на сколько понимаю это стандарт, все модели стараются уметь под него генерировать патч. Вот так же сделано и в OpenCode который использует это для разных моделей.
А избавится от использования шелла полностью конечно ж не получается, причем чем больше контекста, тем более вероятно модель будет использовать только shell - в codex/opencode в общем то такая же проблема (видно по трейсам последнем скрине)
diffnotes-tech
07.03.2026 15:46Aider вообще отказался от tool_call для правок. Модель пишет search/replace блоки прямо в тексте ответа, парсер на клиенте их вытаскивает и применяет. Не надо выбирать инструмент, не надо считать строки в diff - и фоллбэков в shell заметно меньше
powerman
07.03.2026 15:46Отказался или изначально не поддерживал? Я на него последний раз смотрел давно, и мне тогда показалось, что он просто отстал от актуальных технологий и отказался от реализации того, что сделали все остальные и что уже стало стандартом. Может, конечно, у Aider просто свой путь, это тоже норм. Но с точки зрения обычных юзеров этот путь явно менее привлекательный, чем путь Cursor/Copilot/Claude Code/etc.
milinsky
07.03.2026 15:46Большинство существующих агентов для коддинга - мусор. И судя по написанному в статье, ваш не исключение, без обид. Создание качественного агента это не промпт за бутылкой пива, а серьёзная исследовательская работа. То, как агент взаимодействует с моделью, операционной системой и пользователем напрямую влияет на инференс. Поэтому когда на просторах интернета вайбкоддеры начинают сравнивать модели, используя, при этом разные агенты, не вызывает у меня ничего кроме желания сделать facepalm.
RAG? Спасибо, нет
Что же, жаль что вы не смогли осознать как его применять в коддинге. Это весьма полезная вещь если уметь её готовить. Проблема состоит лишь в том, что для конкретного проекта нужен свой подход в применении RAG. Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
John_Carter Автор
07.03.2026 15:46Создание качественного агента это не промпт за бутылкой пива, а серьёзная исследовательская работа.
именно такой и был посыл в статье!
то что все пишут что это простой цикл с вызовом тулов - большое заблуждение
milinsky
07.03.2026 15:46К сожалению, ваш агент не далеко ушёл от этого самого простого цикла.
Вот простой минимум контрольных вопросов.
Меняет ли ваш агент системный промпт после первого сообщения пользователя? Например: вы работаете с моделью делая предварительный ресёрч перед запуском основного флоу. Вы задали изначальный промпт (не важно, будет это текст или файл с промптом), после чего получили ответ и продолжаете итеративно менеджить процесс. В первом сообщении, у вас должен быть один системный промпт, в последующих - другой. И так не только для ресёрчей.
Использует ли ваш агент кеш?
Есть ли инструмент позволяющий автоматически запускать субагентов? А не автоматически?
Допустим есть. А как он это делает? Как будет обработан агентом результат работы субагента? Какие инструкции будут даны основному агенту вместе с результатом работы субагента?
Использует ли агент LSP? А как использует? Какие инструкции получает модель вместе с результатом работы LSP?
Использует ли ваш агент правила? Какие инструкции получает модель от агента вместе с правилами?Про MCP я вообще промолчу.
И повторю, это лишь несколько примеров из того что ваш агент должен уметь для того что бы не быть очередным мусором.
Ну и не могу не упомянуть про суммаризацию. По своей сути, этот механизм был придуман для вайбкодеров, которые не особо то думают головой когда используют LLM для разработки. При более качественном подходе в работе с LLM, этот механизм не нужен вообще. Если в вашей работе с LLM вам необходима суммаризация - вы вероятно не умеете планировать и ставить задачи.John_Carter Автор
07.03.2026 15:46вот это вы токенов потратили на то чтобы сказать то что и так написано в статье: это поделка, учебный пет-проект, конечно там много чего нет и миллион компромиссов
milinsky
07.03.2026 15:46Не понял вашего сарказма по поводу токенов. Но да ладно. Всё это я написал только для того, что бы у читателя не возникло ощущения, что вы своим пет проектом раскрыли всем глаза. Только и всего. Но я желаю вам успехов в ваших исследованиях. И да, за Rust респект.
John_Carter Автор
07.03.2026 15:46что бы у читателя не возникло ощущения, что вы своим пет проектом раскрыли всем глаза
полностью поддерживаю, спасибо!
powerman
07.03.2026 15:46В первом сообщении, у вас должен быть один системный промпт, в последующих - другой.
Чтобы что? В системном промпте обычно задаётся общее поведение агента, та его часть, которая не специфична ни для конкретного проекта, ни для конкретной задачи. Информация о проекте берётся из файлов вроде
AGENT.md. Она обычно тоже передаётся в системном промпте, но она тоже не специфична для конкретной задачи. Информация о текущей задаче передаётся в обычном промпте пользователя. Да, к ней иногда желательно прикладывать контекст в стилеAGENT.mdтолько специфичный для конкретного типа задач, и да, этот контекст тоже идёт в системный промпт - но в этом возникает необходимость не настолько часто, чтобы требовать обязательно разных системных промптов в каждом запросе, как это описали Вы.Есть ли инструмент позволяющий автоматически запускать субагентов?
Субагенты сегодня - довольно сомнительная фича. Мне вообще кажется, что её придумали ради кратного увеличения затрат на токены. Допускаю, что в каких-то задачах/workflow от них есть польза, но вряд ли это тянет на обязательное критичное требование для абсолютно всех агентов.
Ну и не могу не упомянуть про суммаризацию. По своей сути, этот механизм был придуман для вайбкодеров, которые не особо то думают головой когда используют LLM для разработки. При более качественном подходе в работе с LLM, этот механизм не нужен вообще.
Оставим за кадром вопрос пруфов на тему для кого был придуман этот механизм, давайте обсудим определение "более качественный подход".
Довольно очевидно, что для того, чтобы не возникало нужды в продолжении текущей задачи в новом чате, необходимо чтобы текущая задача была завершена полностью (не важно успехом или провалом) в рамках одной сессии. Лично мне не известны рабочие способы решения этой проблемы: невозможно заранее предсказать сколько токенов потребуется модели для обработки запроса, и не превысит ли это количество оставшееся количество токенов в текущей сессии.
А когда сессия оборвалась в процессе работы над задачей нам в любом случае нужно какое-то саммари для продолжения работы в новой сессии. Генерировать его автоматически и использовать без ревью - да, это типичный выбор вайб-кодеров. Но никто же не мешает генерировать его и использовать результат как вспомогательный материал для ручного формирования первого промпта в новой сессии.
Автоматизированные агенты могут использовать саммари оборванной сессии для того, чтобы попытаться переформулировать/декомпозировать задачу оборванной сессии, чтобы повысить шанс что новая попытка выполнения задачи впишется по объёму в новую сессию.
Ну т.е. говорить о полной бесполезности и ненужности саммари довольно странно. Если у вас есть рабочее решение этой проблемы, конкретное описание упомянутого Вами "более качественного подхода" - расскажите, что это за подход и как он решает эту проблему.
milinsky
07.03.2026 15:46Чтобы что?
Речь не о замене промпта на что-то принципиально другое6 а добалении инструкций говорящих модели об итерации. И это не я придумал.
Субагенты сегодня - довольно сомнительная фича. Мне вообще кажется, что её придумали ради кратного увеличения затрат на токены.
Использование субагентов позволяет атомизировать подзадачи, и как следствие - повышать их качество выполнения за счёт маленьких, но гарантированно решаемых задач. Вопрос токенов тут не стоит. Как показывает практика, затраты токенов на применение субагентов, примерно равносильны затратам при их неиспользовании. Это происходит из-за увеличения итераций доработок при линейном подходе.
Оставим за кадром вопрос пруфов на тему для кого был придуман этот механизм, давайте обсудим определение "более качественный подход".
В чём необходимость пруфов не ясно. Однако ясно, появление механизма сжатия - это решения проблемы переплонения контекстного окна в угоду процесса (именно процесса, который для многих кажется правильным, когда готовият огромную задачу и тупо ждут результата). С момента появления механизма сжатия контекста, мне ни разу он не понадобился, с учётом большого количества решаемых задач с помощью LLM.
А когда сессия оборвалась в процессе работы над задачей нам в любом случае нужно какое-то саммари для продолжения работы в новой сессии.
Повторю, при атомарности задач и контроля их размера это не нужно. Ты просто повторяешь задачу и если надо, с чекаутом предыдущих изменений либо указанием предварительно проанализировать прогресс. Проблемы нет от слова совсем. И это так же может быть автоматизировано в выбранном флоу.
powerman
07.03.2026 15:46В чём необходимость пруфов не ясно.
Ну, вы сделали сомнительное заявление что фича была разработана именно для нужд вайб-кодеров, отсюда и необходимость пруфов - если бы для меня было важно для кого её разрабатывали, но мне не важно, так что пруфы можно опустить. Впрочем, если они у Вас есть - я бы с интересом почитал, чисто для самообразования.
Повторю, при атомарности задач и контроля их размера это не нужно
Идея что "маленькая" задача не потребует большого количества токенов - это иллюзия. Типичный пример: багфикс. Вроде баг мелкий, на первый взгляд. Но количество дополнительной работы в процессе фикса может в любой момент взорваться по токенам - потому что вылезет что-то не предусмотренное и пойдёт процесс отладки в процессе понять, что происходит и почему. Да, можно отловить необходимость этого процесса отладки и выделить его в отдельную подзадачу, но никаких гарантий что эта подзадача влезет в контекст у нас всё-равно нет.
Саммари в таких ситуациях позволяет получить обзор того, что уже было попробовано и не дало результата плюс идей которые запланировали попробовать но на которые не хватило предыдущей сессии.
Использование субагентов позволяет атомизировать подзадачи, и как следствие - повышать их качество выполнения за счёт маленьких, но гарантированно решаемых задач.
Давайте возьмём для примера самый типичный кейс: промпт пользователя просит добавить фичу (уже спроектированную, с описанием как именно её добавлять) либо починить баг (с описанием как он проявляется и как его воспроизвести). Для решения задачи модели нужно: проанализировать код, реализовать функционал, покрыть его тестами, прогнать форматирование/линтеры/тесты и исправить все проблемы. Обычно всё это делается одним промптом, результат в 95% случаев влезает в одну сессию. Как именно тут помогут субагенты? Это же традиционный цикл построить теорию → изменить код → прогнать тест → повторить пока не заработает, и для его качественного выполнения на следующих шагах нужно знать историю предыдущих шагов, а разделив его на несколько сессий субагентов мы эту историю… того.
Я уже молчу о том, что при использовании тарифных планов с оплатой за запросы, а не токены, вместо оплаты одного запроса (которого часто хватает на полное решение вышеупомянутых задач) будет дробление на субагенты и N запросов вместо 1.
milinsky
07.03.2026 15:46Лично мне не известны рабочие способы решения этой проблемы: невозможно заранее предсказать сколько токенов потребуется модели для обработки запроса, и не превысит ли это количество оставшееся количество токенов в текущей сессии.
Лично мне известно несколько таких способов. Самый простой из них, когда ты просишь создать задачи на основе ресёрча бизнес-задачи, указать, что каждая задача не должна превышать например 2 или 3 или сколько ты хочешь (вычисляется эмпирическим путём) дней по оценки трудозатрат. Таким образом, задачи будут созданы с учётом этого и будут предсказуемы. Если вы не используете разделение задач контроль их размера - вы получаете проблему о которой сами же и сказали.
powerman
07.03.2026 15:46Проблема состоит лишь в том, что для конкретного проекта нужен свой подход в применении RAG.
Расскажите подробнее, о чём речь. Потому что, насколько я понимаю, консенсус на сегодня заключается в том, что работа с кодом требует чтобы модель видела код полностью, причём в его текущей версии, а не выдернутые из RAG кусочки, причём нередко не содержащие самых последних изменений сделанных секунды назад. Т.е. RAG остался для документов, но для кода от него практически отказались. Плюс размер контекста сильно вырос с тех времён, когда придумали RAG, так что никакой проблемы сегодня модели читать (полностью или кусками) реальные файлы с кодом уже нет. Сейчас в качестве RAG для кода экспериментируют с использованием AST для поиска всего нужного кода, этот подход хотя бы гарантирует что будут найдены абсолютно все нужные части кода и выданы цельными кусками (напр. функция целиком), причём используя текущий, актуальный вариант кода. Но и это пока на уровне экспериментов, и пока неясно, даст ли это что-то полезное в сравнении с прямым чтением файлов с кодом моделью.
Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
Это чушь и передёргивание. Вайбкодингом оно станет только если сгенерированный код принимать без тщательного ревью. А с ревью это очень близко к обычному процессу парного программирования.
milinsky
07.03.2026 15:46Расскажите подробнее, о чём речь. Потому что, насколько я понимаю, консенсус на сегодня заключается в том, что работа с кодом требует чтобы модель видела код полностью, причём в его текущей версии
Не следует в RAG хранить код. В RAG есть документация проекта. При этом, для корректной работы, документация должна быть соответствующе подготовлена. Таким образом, задавая контекст, какие то вещи будут взяты моделью из базы знаний. База знаний пополняется по мере работы над проектом и это должно входить в флоу работы с LLM. Например, предоставив модели тул с описанием, что тул предоставляет оглавления документации, позволит модели посмотреть оглавления и вызвать нужное если это потребуется.
Это чушь и передёргивание. Вайбкодингом оно станет только если сгенерированный код принимать без тщательного ревью. А с ревью это очень близко к обычному процессу парного программирования.
Ревью обязателен в любом случае. Однако ревью целого проекта или всей бизнес-задачи созданного одним промптом и ревью небольших итераций (в том числе по средствам самой LLM) это не одно и тоже.
Зачастую люди применяют второе, отсюда и разговоры, что LLM может гененировать только нейрослом.
powerman
07.03.2026 15:46Ревью целого проекта - это отдельный сложный проект, обычно называемый аудитом. Применять это в ежедневной разработке - нереально.
Отношение к ревью небольших итераций определяется исключительно тем, что в эту итерацию включить. Если только генерацию кода моделью - да, это будет нейрослоп, на ревью которого будет уходить неоправданно много усилий. Если генерацию кода, тестов, выполнение линтеров/тестов и исправление ошибок - то никакого нейрослопа не будет, будет совершенно обычное ревью типичного PR.
При этом нужно заметить, что второй вариант (с тестами) полностью подходит под Ваше определение:
Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
что означает, что, как минимум, это определение неверно в текущей формулировке и требует дополнительных уточнений.
Kaluchi
07.03.2026 15:46Не следует в RAG хранить код
Расскажите, зачем вообще нужен RAG в 2026 году? Получать ответ за одну итерацию инференса? Добивать промт от юзера релевантным мусором? Я просто хочу разобраться.. как это ПРАВИЛЬНО готовить? Поверх серч резалтов выполнять саммаризацию, как это делает гугл? Но компилятору требуется точный ответ, а не отписка... Какой профит с этого? Наличие полученной по неизвестным для модели правилам RAG-выдачи в контексте как-то побуждает её серьезнее относиться к задаче, она будет меньше сочинять и выдумывать? Где эта ниша, где RAG -- непоколебимый король?
Pubert
07.03.2026 15:46Я бы не давал полный доступ ИИшке к шеллу. Вместо этого создал бы обёртку над bash. В этой обёртке есть разрешенные команды-алиасы. На некоторые требуется подтверждение, на некоторые - нет. Это и будет набором инструментов, только которые интуитивно понятны системе. Если ИИ пытается выполнить `cat largefile.txt` - выдаётся ошибка "файл слишком большой. Укажите диапазон в формате старт:стоп", или что-то подобное. Команд для записи просто не должно быть - всё через патчи. На npm/TS/RS/PHP/docker/yarn и т.д. будут "прозрачные" алиасы без подтверждений. Или с подтверждением. На остальные команды писать "permission denied" или "unsupported in this project"
Получится как middleware для шелла. Полная изоляция, абсолютно интуитивное управление. Можно будет сколько угодно инструментов впихнуть. Попробуйте :)
Master_Yoda_810
Количество статей об агентах начинает утомлять.
Хотя, наверняка до сих пор пишутся книги в стиле "Как стать миллионером, не вставая с дивана".