Вайбкодинг · 21 октября 2026 г.
25 триллионов токенов: выводы для разработчиков
На QCon AI Brendan O’Leary (Kilo Code) объяснил, почему команды не переходят от автодополнения к оркестрации агентов — и как контекст, маршрутизация моделей и обратные петли мешают масштабированию.


Что произошло
На QCon AI Brendan O’Leary, founding developer relations engineer Kilo Code, представил анализ поведения разработчиков на основе данных платформы и шлюза Kilo Code. По словам докладчика, объём обработанных данных вырос с 25 триллионов токенов до более чем 40 триллионов к моменту выступления (источник).
Главный вывод доклада — для реального принятия агентных инструментов важнее выстроенное доверие между инструментом и разработчиком, а не рекордные показатели моделей на бенчмарках.
Четвёхступенчатая «лестница доверия»
O’Leary описывает четыре уровня взаимодействия с AI: автодополнение (ghost text), чат‑взаимодействие, агент, который может читать и править файлы и запускать команды, и финальная стадия — оркестрация множества агентов. С переходом на каждый следующий уровень время обратной связи увеличивается, и растёт стоимость ошибки: то, что на автодополнении можно быстро отменить, у агентов может привести к сбою сборки или другим серьёзным последствиям.
По наблюдению докладчика, многие команды застревают на первых двух уровнях из‑за проблем с подачей контекста, маршрутизацией моделей и недостаточными обратными петлями, без которых не безопасно повышать автономность агентов.
Три ключевые точки отказа
1) Контекстная конструкция. Перед отправкой запроса важно, какие файлы и представления кода попадают в контекст, как выбираются релевантные фрагменты и не устарели ли семантические индексы. Ошибки на этом этапе — неверная выборка, устаревшие представления или нерелевантные фрагменты — приводят к неправильным рассуждениям и затем умножаются при оркестрации агентов (источник).
2) Маршрутизация моделей. Kilo Code фиксирует заметное мульти‑модельное поведение: в апреле 68% разработчиков, вручную выбиравших модель, использовали модели из двух и более лабораторий в том же месяце, а 45% переключали модель в пределах часа. Среди корпоративных пользователей 71% запускали модели от двух и более провайдеров. По интенсивности использования доля мульти‑лабораторий растёт: от 34% у лёгких пользователей (~100 запросов в месяц) до 92% у power‑пользователей (>10 000 запросов). Эти данные указывают, что разработчики подбирают модели под конкретные задачи, а не пользуются одной «универсальной» моделью.
3) Обратные петли. Чем выше автономность агентов, тем более редким и отсроченным становится сигнал о корректности работы. Без инструментов для мониторинга и быстрых коррекций накопленные ошибки становятся критичными.
Числовые иллюстрации и ограничения данных
Доклад подчёркивает важную оговорку: выборка Kilo Code не случайна — платформа притягивает ранних адоптеров и команды, которые ищут настраиваемые open‑source решения. Поэтому проценты и паттерны описывают поведение этой когорты, а не всей индустрии в целом (источник).
Одно наблюдение — разнообразие используемых моделей: топ‑10 по объёму запросов в датасете пришли из шести разных лабораторий, а в отдельные дни лидировали модели с невысокой публичной известностью, что указывает на практическую разницу «чувства» моделей для разных задач.
Практический смысл для инженерных команд
Чтобы безопасно масштабировать agentic‑workflows, команды должны прежде всего наладить три вещи: доставку релевантного и актуального контекста; гибкую стратегию маршрутизации моделей; и короткие, измеримые обратные петли для обнаружения и исправления ошибок. Работа над этими точками снизит риск при переходе к более автономным уровням и позволит постепенно наращивать доверие.
Все числовые примеры и выводы в материале относятся к выступлению Brendan O’Leary на QCon AI и основаны на данных Kilo Code, как это зафиксировано в транскрипте и презентации (источник).