31 августа 2026 года The New Stack разобрал вроде бы скучную, но дорогую деталь агентной разработки: токены ИИ-агентов сгорают не только на генерации кода, но и на том, как инструменты упаковывают данные для модели. Для команд, которые уже гоняют агентов по репозиториям, тикетам и логам, это означает неприятную вещь: лишние расходы часто сидят не в выборе модели, а в формате ответа от devtools.
Как пишет The New Stack, до первой сгенерированной строки кода агент уже успевает потратить контекст на входные данные: исходники, описания задач, логи сборки, результаты проверок качества и предупреждения по зависимостям. И если эти данные приходят в тяжеловесном виде, например в длинном JSON со множеством одинаковых полей, модель платит токенами не только за смысл, но и за служебную упаковку: имена ключей, кавычки, скобки и повторяющуюся структуру. На человеческий глаз это мелочь. На длинной агентной сессии это уже статья расходов.
Главная мысль публикации проста: формат вывода инструмента для ИИ-агента стал инженерным решением, а не косметикой для удобства чтения. В материале приводится пример с Sonar CLI, который умеет отдавать список проблем не только в JSON, но и в формате TOON, то есть Token-Oriented Object Notation. Этот формат рассчитан именно на LLM-вход: там, где JSON раз за разом повторяет одни и те же названия полей в массиве однотипных объектов, TOON старается вынести общую структуру наверх и оставить в строках только сами значения. Проще говоря, если агенту нужно переварить сотни однотипных записей, ему лучше не таскать за собой килограммы синтаксической упаковки.
Здесь важен нюанс, который в статье отдельно проговаривается: JSON никто не отменял. Для вложенных, нерегулярных или смешанных структур он по-прежнему может быть уместнее и даже компактнее. Но если инструмент возвращает длинную, ровную таблицу однотипных сущностей, именно такая форма чаще всего и встречается в линтерах, сканерах качества, issue-listing и отчетах проверок, то выбор более плотного представления выглядит не прихотью, а нормальной оптимизацией. То есть вопрос уже не в том, красив ли формат, а в том, сколько раз команда готова платить за повторяющиеся поля вроде severity, status, component и message.
Статья бьет и по другой привычке рынка: когда разговор заходит о стоимости агентной разработки, команды обычно крутят три ручки, модель, длину промпта и лимиты запросов. Все три полезны, но публикация показывает еще один слой оптимизации, который до сих пор часто остается в тени, интерфейсы между агентом и инструментами разработки. Если на каждом вызове агент получает раздутый ответ от системы качества, таск-трекера или внутреннего API, то никакой героический тюнинг промптов не спасет. Денег утечет меньше только тогда, когда сокращать начнут не смысл, а упаковку смысла.
Практическая часть у материала тоже без магии. Автор предлагает не верить обещаниям на слово, а мерить собственный workflow на реальных данных. В публикации упоминается типовой сценарий: сначала выгрузить список проблем в JSON через Sonar CLI, затем прогнать тот же ответ через утилиту npx @toon-format/cli --stats и посмотреть разницу. Подход здравый: на синтетических бенчмарках почти все выглядит победно, а вот в боевом проекте важны конкретные payload, конкретный tokenizer и конкретная модель. Иными словами, разговор не о том, что TOON якобы волшебным образом победит все форматы сразу, а о том, что у каждой команды теперь есть довольно дешевая проверка гипотезы на собственном стеке.
Для русскоязычной IT-аудитории здесь несколько вполне прикладных выводов. Разработчикам это лишний повод смотреть на AI tooling как на обычную инженерную систему, где стоимость сидит в деталях протокола, а не только в маркетинговом названии модели. Тимлидам и продактам материал полезен как аргумент против наивной метрики в духе агент написал pull request, значит все окупилось. Нет, сначала стоит посчитать, сколько токенов ИИ-агентов ушло на подготовительный шум вокруг этого pull request. А для CTO и тех, кто отвечает за внутренние платформы, статья вообще звучит как рекомендация провести ревизию всех точек, где LLM общается с CI, анализаторами качества, системами инцидентов и корпоративными API. Возможно, самый дешевый способ сократить счет окажется не в миграции на новую модель, а в том, чтобы научить старые инструменты говорить короче.
На фоне общего бума агентной разработки этот сюжет выглядит особенно своевременным. Пока рынок спорит, какой кодовый агент умнее, быстрее и автономнее, более приземленный вопрос звучит так: сколько компания платит за то, что агент читает одно и то же, только завернутое в разный синтаксис. Если эта логика закрепится, в ближайшее время мы увидим новый класс конкуренции среди devtools: не только кто точнее находит проблемы, но и кто умеет отдавать их LLM так, чтобы не сжигать бюджет на фигурных скобках.