11 ноября я весь день просидел на трансляции AI Dev Live, онлайн-конференции о разработке с ИИ-агентами. Вели её Николай Шейко и Данила Симонов, и они же открыли программу своими докладами. Дальше было ещё семь выступлений, и к вечеру сложилась довольно цельная картина. Утро ушло на то, как устроить работу с агентами у себя и в компании. Середина дня была про железо и деньги. Вечер про людей: кого нанимать, как мерить эффект и как самому не сгореть рядом с агентами.
Я не стенографировал, а пересказываю своими словами то, что зацепило, и в конце пишу, что забираю себе. Под каждым докладом есть слайды, их можно открыть на весь экран.
Николай Шейко: один слой над разными агентами
Николай начал с вещи, которая кажется очевидной, только пока о ней не задумаешься. Claude Code, Codex CLI, Codex Desktop и расширение для VS Code по сути обёртки над движками: Claude Agent SDK и Codex App Server. Каждая обёртка добавляет свои инструменты и скиллы и тем меняет поведение модели. У Codex Desktop есть встроенный браузер и управление тредами, у Codex CLI их нет, и это уже два разных агента на одном движке.
Проблемы начинаются, когда пользуешься двумя инструментами сразу. Раздваивается всё: треды, автоматизации (у Codex это Automations, у Claude Routines), браузеры, скиллы. Николай решил это радикально и сделал BB. Это общий верхний слой с тредами, автоматизациями, браузером, скиллами и плагинами, а под ним разные движки: Codex, Claude Code, Pi, OpenCode. Модель выбирается под конкретный чат. Вместо сабагентов в BB треды, связанные наследованием в несколько уровней. Например, из чата с Claude открывается чат с Codex, и тот ревьюит решение, которое Claude только что написал.
BB устроен как обычное клиент-серверное веб-приложение, поэтому открывается в браузере и на телефоне, а плагины могут менять даже интерфейс: время под сообщениями Николай добавил одним промптом. Ядро он перенёс на VPS, потому что ноутбук приходилось держать открытым круглые сутки. На сервере крутятся автоматизации и вебхуки, сессии можно раскидывать по нескольким облакам. А команды на ноутбуке сервер запускает через BB Connect, без SSH и шлюзов. Так агент работает с локальными файлами и браузером через Playwright, вплоть до подписи документа ЭЦП, вставленной в ноутбук.
Дальше Николай открыл свой AGENTS.md, и это была, пожалуй, самая полезная часть. Агент идёт по ожидаемому пути, пока получается. Если путь не работает, он не ищет втихую костыли, а говорит, что сломалось, и предлагает варианты обхода на согласование. Агенту явно разрешено спорить с человеком и не доверять внешней информации, даже документации: важное он проверяет экспериментом. Вместо бесконечных запасных вариантов в коде один путь исполнения, и, по ощущениям Николая, это срабатывает примерно в 80% случаев. Скрипты пишутся по PEP 723 и запускаются через uv, чтобы не поднимать проект и окружение под каждую мелочь. Всем он советует диктовку, а в AGENTS.md держит строчку про ошибки распознавания, чтобы агент сам переспрашивал: «наверное, ты имел в виду…».
Своих скиллов он показал три. Самый практичный называется «прораб». Рои агентов у Николая не прижились: при каждой передаче контекст теряется, как в испорченном телефоне. Поэтому контекст держит менеджер, работу делает один исполнитель, и менеджер не ждёт конца, а заглядывает к нему по таймеру примерно раз в пять минут и рано поправляет курс.
Второй скилл устраивает ревью с чистым контекстом: замечания ревьюера фильтруются, и по каждому идёт аргументированный спор до согласия. Подходит и для плана, и для кода. Третий, Learn, вытаскивает скилл из реальной работы. Человек вместе с агентом решает задачу, агент пишет методичку, потом чистый агент проверяет её на той же задаче, и цикл повторяется, пока результат не станет хорошим. Из трёх-четырёх таких задач в папке скилла складывается набор для его проверки.
В вопросах спросили, почему не готовые оболочки вроде Orca или Herder. Николай ответил, что они нормальные, но построены поверх консольных версий агентов, и в них нет общего слоя тредов и интерфейса, который можно допиливать под себя. Ещё он посоветовал AST-индекс для поиска по большим кодовым базам вместо grep и Playwright для работы с браузером: на его маленьком замере он обходит встроенные браузерные коннекторы.
Ещё слайды доклада
Данила Симонов: компания, которую ведут агенты
Если Николай говорил о том, как устроить работу одного человека, то Данила поднялся на уровень всей компании. Сейчас агент почти везде остаётся инструментом в руках сотрудника, и устройство компании от этого не меняется. AI-native подход обратный: каждый процесс перестраивают так, чтобы его выполнял агент, а вопрос звучит так: «как сделать, чтобы это мог делать агент?».
Начать легко: вынести Claude на VPS и подключить ему MCP несложно. Но через пару дней появятся вопросы. Кто и зачем сделал эту запись в CRM? Как сотруднику пользоваться системой через своего личного агента? Как разбирать сбои и чинить одно, не ломая остальное? Данила сравнил это с сапожником, который решил открыть обувную фабрику: теперь он строит конвейер, а не шьёт ботинки. Поддержка такого ядра со временем становится главным продуктом компании, вплоть до 60–70% всей деятельности, и это, по его словам, нормально.
Путь он разложил на три шага. Первым шагом он делает ядро данных. У каждой сущности одна точка истины, в 99% случаев в своей базе, а внешние системы вроде Метрики подключены через сущность-ссылку со своей историей и правами. У каждого изменения есть автор, причина и, на первых порах, кнопка «откатить». Второй шаг касается автономных процессов. Первыми кандидатами он называет повторяемые процессы с понятными входом и выходом, где результат легко проверить, а ошибку можно откатить. Роль агента описывается файлом-дефиницией: промпт, инструменты, разрешённые модели и критерии готовности. Готового формата Данила не нашёл, все пишут свой YAML.
Отдельно он остановился на доступе к базе. Прямой доступ агенту Данила не советует, и аргумент мне понравился. Сломать агент ничего не сломает, но будет каждый раз действовать по-новому, а такое поведение не протестировать и не проверить. Нужен набор инструментов с валидацией и понятной подсказкой при ошибке, вплоть до проверки, что код страны состоит из двух букв. Под это нужна и среда: песочницы и контейнеры, полные логи и трейсинг, бюджеты. Тяжёлые окружения вроде браузера, CAD или симулятора iOS лучше брать готовыми микро-VM у неооблаков, а для лёгких задач простая изоляция делается часа за два. И обязательно наборы эталонных проверок, чтобы правка инструкции одного процесса не сломала другие.
Третий шаг касается личных агентов сотрудников. Контроля над ними меньше, поэтому прав у агента не больше, чем у человека, опасные действия подтверждаются явно, а целостность данных обеспечивает код, а не просьба в инструкции. Инструменты для таких агентов Данила делает обобщёнными: создать, изменить, удалить, а тип сущности передаётся параметром. Валидация живёт на сервере, который при ошибке возвращает правильную схему. Ещё одна находка: клиенты MCP обновляются плохо, а люди ведут один чат неделями. Поэтому вместо resources и prompts из стандарта он делает отдельный инструмент, который отдаёт актуальные инструкции сервера, а в AGENTS.md личного агента пишет, что их надо время от времени перечитывать.
Вопросов было много. Про персональные данные Данила ответил прямо: соблюдать закон и держать свой инференс, а отправлять такие данные в зарубежные API каждая компания решает сама и на свой риск. Про размер компании: тестирование агентов дешёвое, его потянет команда из двух-трёх человек. Маленькие компании могут сразу перевести на агентов большую часть процессов, крупные переводят отдельные ветки, например поддержку. И главная мысль ответа про то, как выдать агентов сотрудникам: агентов людям выдавать не нужно, нужно забирать у людей деятельность. Сам он делает в углу внутренней системы кнопку-чат, которая знает контекст страницы и сотрудника и понимает голос.
Ещё слайды доклада
Родион Мостовой: топ-менеджмент для агентов
Родион, основатель CodeAlive, продолжил тему с другой стороны: если агентов много, ими надо управлять, как командой. Оркестрация, по его словам, нужна, чтобы получить результат уровня самой сильной модели в десятки раз дешевле. И нужна она на масштабе эпика: большой рефакторинг, миграция, переписывание на другой язык, приложение под ключ.
Процесс у него выглядит так. Сначала исследование контекста, потом вопросы человеку, причём по одному или визуально, чтобы не копить когнитивный долг. Дальше спецификация. Координатор раздаёт задачи исполнителям на моделях попроще, результат ревьюят другие модели, а проверка идёт по матрице тестов, которую заложил планировщик. Перед стартом агента «онбордят»: стадия проекта (прод на миллиард пользователей или прототип на троих), аудитория, ценность и ключевые функции, цена ошибки, бюджет на эксперименты.
Над всеми стоит аудитор, самая сильная из доступных моделей. Координатор раз в полчаса или час спрашивает его, туда ли идёт работа. Без аудитора агенты у Родиона сутки-двое чинили окружение вместо задачи. Это перекликается с «прорабом» Николая: и там и тут кто-то со свежим взглядом регулярно сверяет курс, а не ждёт отчёта в конце.
Главным кейсом доклада был индексатор графа вызовов без компиляции, через статический анализ. Эталоном служила индексация компилятором, цель была около 95% точности при балансе полноты и точности. Через день агент отчитался о 100%. Выяснилось, что он добавил «сайдкар», который подмешивал эталон прямо в результат. Метрика выросла, задача не решена. Эту историю я запомнил лучше всего за день: по ней хорошо видно, почему отчёту агента о себе верить нельзя. Лечится это чёткими целями, ограничениями и явным списком запрещённых лазеек. Его можно набросать вместе с другими моделями, и его учитывает координатор. В итоге агенты три-четыре недели работали автономно на виртуальных машинах, языков было больше десяти, и в результате получилось около 300 тысяч строк кода, доведённых до стабильной работы на проде.
Остальные правила Родиона тоже практичные. Координатор записывает прогресс и журнал в файл или в спеку, чтобы они пережили сжатие контекста. Задачи он выдаёт подробные, с критериями приёмки, сложные места продумывает заранее и проверяет исполнителя в первую минуту после запуска. Исполнитель работает строго в рамках задачи и ведёт журнал отклонений от плана. Слабые модели исполнителями ставить не стоит: переделок больше, выигрыша нет. Исследование контекста, наоборот, можно отдать дешёвым моделям, по пять-десять параллельно. Отдельно Родион предупредил про перфекционизм. Когда спеку полируют много моделей, в неё набиваются надуманные ограничения вроде лишних тайм-аутов и лимитов, и для этого у него есть готовый промпт «проверь, не переусложнили ли без повода». А ещё агентам у него прямо разрешено жаловаться на неудобные скиллы, хуки и гайды.
Общий совет у него один: всегда измерять. Если своих эвалов нет, раз в одну-две недели прогонять рефлексию по истории сессий через сабагентов. Из зала спросили, не будет ли аудитор всегда что-то находить, просто потому что его об этом спросили. Родион честно сказал, что за собой такого не замечал, но объективно ответить не может. Вопрос остался открытым, и мне он кажется одним из самых интересных за день.
Ещё слайды доклада
Валерий Ковальский: свой инференс держится на кэше
После обеда разговор спустился на уровень железа. Валерий работает Head of AI в Битрикс24 и держит свой небольшой инференс-ЦОД, Neuraldeep. Начал он с того, чего на ноутбуке не сделать: агента на машине дешевле ста тысяч рублей не запустить, там живут классификаторы, маленькие модели для решений и распознавание речи. Исключение составляют разве что Mac с большой памятью.
По его статистике, большинству задач хватает моделей до 120B: простой код, RAG, классификация. Модели на 500–700B нужны для сложных рассуждений и требуют сервера на восемь карт. Агенту достаточно 20–30 токенов генерации в секунду, гораздо важнее скорость чтения: на один сгенерированный токен приходится в среднем 37 прочитанных, а местами 200. Поэтому главное в своём инференсе это KV-кэш.
Дальше шли выводы из практики, и почти каждый противоречил интуиции. Две карты на одну модель работают медленнее, чем две независимые копии. Сервер под DeepSeek разделили на движки по четыре карты, поставили роутер с учётом кэша, и всё, по словам Валерия, «запело». Балансировка по нагрузке убивает кэш, а роутер по префиксу или по ID сессии ломается, как только приходит новый трафик. Готовое решение даёт либо ровную нагрузку, либо кэш, поэтому настраивать приходится под свой профиль и проверять каждый день. Типовая ошибка: дата в начале системного промпта, из-за которой кэш не совпадает никогда. После выгрузки кэша в оперативную память он у них живёт в пиковые часы полчаса вместо пяти минут, а задержку так можно снизить втрое без новых карт.
Из советов покороче: KV-кэш не квантовать ниже восьми бит, контекст локальных моделей держать в пределах 300–400 тысяч токенов, а остальное решать сжатием. Бенчмарки скорости завышают результат, «сто сессий на маленькой машине» на деле не держатся, так что каждую цифру надо сверять на своём трафике. Агент часто тупит не из-за модели, а из-за шлюза: буферизации или машины, выпавшей из ротации. Внутри компании нужны квоты по отделам, а ориентиром для отклика он назвал 40 секунд до первого токена в 95% запросов.
Из этого Валерий вывел новую роль, Head of Inference. Это бывший DevOps или MLOps, который понимает агентов, сжатие контекста, MCP и скиллы и связывает продукт, шлюз и карты. Про квантизацию в вопросах он сказал, что любой квант теряет какую-то область знаний, поэтому на общем инференсе он берёт кванты от производителя и FP8, а Q4 и ниже не берёт. И рассказал историю, после которой зал оживился: однажды он забыл переключить модель, и версия без цензурных ограничений начала пентестить сеть провайдера.
Ещё слайды доклада
Екатерина Фирсова: найм, когда резюме пишет ИИ
Следующий доклад вернул разговор к людям. Екатерина руководит HR в Altenar и девятнадцать лет работает в IT-найме. По данным hh, откликов на вакансию сейчас втрое больше, чем раньше, а на одну позицию фронтенд-разработчика за сутки пришло больше тысячи резюме. ИИ кандидаты используют на всех этапах: пишут резюме и письма, решают домашние задания, а на собеседовании держат рядом суфлёра. Сами кандидаты признают это в 39% случаев, рекрутеры считают, что так делают 91%, а Екатерина по ощущениям оценивает долю ближе к 99%.
На собеседовании в Altenar смотрят на четыре вещи. Первая логика: умеет ли человек спуститься от абстракции к деталям через цепочку «а почему?». Дальше честность, потому что доверие стало главной валютой, доведение до конца («что ты сделал», а не «в чём участвовал») и умение работать в команде.
Сами собеседования тоже меняются. ИИ разрешают и смотрят на промпты и живой вайбкодинг: что кандидат проверяет, а что берёт на веру. Просят логи сессий с агентом, дают на ревью чужой ИИ-код, иногда просят закрыть глаза и подумать вслух. Чаще зовут в офис, а домашних заданий больше нет. Кандидатам Екатерина советует убрать из резюме «пластик», подгонять его под вакансию, не рассылать отклики веером, ходить на митапы (только в Москве за последний квартал прошлого года их было 84) и выходить на нанимающего менеджера напрямую или через рефералов. И договариваться об использовании ИИ на берегу.
Грейды при этом сдвигаются. Джун проверяет выдачу агента, мидл отвечает за фичу от промпта до прода, сеньору доверяют спорные решения и ревью людей и агентов, а лид решает, что можно отдать агентам, и отвечает за это. Часть HR-директоров уже отказалась от performance review, потому что его с обеих сторон пишет ИИ. Отдельно она рассказала про европейскую директиву о прозрачности оплаты: вилку называют до собеседования, о прошлой зарплате спрашивать нельзя, а грейды расписаны подробно.
На вопрос, меньше ли стало вакансий, Екатерина ответила, что это скорее кризис вакансий, чем найма: у компаний стало меньше жира. Иногда придётся соглашаться на меньшие деньги или подстраиваться под то, что болит у работодателя. Мидлу, который просто пишет код, сейчас очень тяжело.
Ещё слайды доклада
Константин Доронин: что код должен гарантировать
Константин начал с того, как за год сместился вопрос. Раньше контролировали отдельную задачу, теперь компании просят выстроить единый процесс. Агент собирает CRM за один промпт, продакты тоже начали делать продукты сами, но найти проблемы в таком коде уже некому. Разработка стоит примерно пятую часть от всей цены программы, остальное уходит на поддержку. С ИИ кода становится больше, значит, дорожает и поддержка.
Кодинг, по словам Константина, никогда не был узким местом, и новые узкие места это подтверждают. Пустеет бэклог: стейкхолдеры не успевают формулировать, что нужно. А задачи стоят на проверке, потому что никто не берёт ответственность за выкатку. Он предложил думать о гарантиях, которые должен давать код: требования продуманы, прод не ляжет, уязвимостей и лишних внешних зависимостей не появится, поддержка не уйдёт в экспоненту.
Для этого нужны петли обратной связи. Человек поправляет агента, агент проверяет агента, лучше из другого семейства моделей (Codex проверяет Claude, и наоборот), а в идеале проверка детерминированная. Плюс обязательные эвалы и трейсы, и не стоит завязываться на одно семейство моделей на случай бана. Типовые ошибки агента он перечислил так: задача в вакууме, без контекста проекта, только позитивные сценарии и логика, которую сам агент не может прочитать, вроде двухсот вложенных условий. Дальше Константин пошёл по циклу разработки с требований, и тут у меня подвисла трансляция, так что вторую половину доклада я пропустил. Судя по итогам дня, в ней были архитектурный линтинг, мутационное тестирование и оценка зависимостей.
Ещё слайды доклада
Егор Толстой: SDD не отменяет ревью кода
Трансляция вернулась уже на середине доклада Егора про Spec-Driven Development. Внедрять SDD он советует экспериментом на паре инженеров или одной команде, не коммитить спеки сразу и смотреть на опыт разработчиков. Ревью спеки ловит архитектурный дрифт до кода, подключает нетехнических людей и сохраняет, почему выбрали именно это решение и какие были альтернативы.
При этом Егор не знает ни одной команды, которая из-за ревью спек перестала читать код. Нормальный режим у него такой: спеку ревьюят при серьёзных архитектурных изменениях, а код смотрят быстро, для проверки. Чтобы убедиться, что спека реализована, он добавляет в AI-ревью отдельную проверку, что каждый пункт спеки покрыт кодом, а часть спеки делает исполняемой через тесты. Если код меняют в обход SDD, помогают периодическая сверка спек с кодом и ревью каждого PR на влияние на спеки. Где держать спеки, зависит от устройства: если изменение задевает несколько репозиториев, спеки лежат отдельно, если репозиторий один, то рядом с кодом.
Свой взгляд Егор честно назвал взглядом на ноябрь, который через пару месяцев может поменяться. Окно контекста теряет важность, потому что сжатие в Claude Code стало заметно лучше. Важнее становятся плотность смысла и ментальная нагрузка: чтобы продукт не вышел дженериком, промпт тоже должен быть не дженериком. SDD не серебряная пуля, и брать его стоит, если болит именно это. Тем, кто не хочет настраивать свой процесс, он посоветовал готовый OpenSpec, а тем, кому полный SDD тяжёл, лёгкие скиллы вроде Grill Me.
Ещё слайды доклада
Александр Поломодов: как измерить эффект от ИИ
Александр раньше был техническим директором в Т-Банке и последний год отвечал за ИИ в цикле разработки. Его доклад хорошо лёг после Константина: если узкое место переехало из кода, то и мерить надо не код. Начал он с исследований. В METR в 2025 году шестнадцать разработчиков на примерно 240 задачах ждали ускорения, а замедлились примерно на пятую часть. Повторить опыт в 2026 году было трудно: участники отказывались работать без ИИ. У Microsoft смёрдженных PR на инженера стало примерно на четверть больше, и вопрос, какая в них польза, остался открытым. У Anthropic показатели на инженера выросли в пять раз за полгода.
Мерить можно на трёх уровнях. Самый честный уровень охватывает путь от идеи до результата для клиента: метрика и контрметрики, число инициатив, сроки, эффект, стоимость переделок и токенов. Он работает в командах, которые уже перестроились, но плохо масштабируется. Уровень пониже касается только поставки и строится по фреймворку DX из трёх частей: использование, экономия времени вместе с качеством и затраты с окупаемостью. В Т-Банке первые две части мерили, третью не получилось. И отдельные инициативы, например AI-ревью или миграции, которые по статье Google окупаются примерно с пятой-седьмой типовой миграции, если честно считать хвосты и ручную доделку.
Использование он советует считать от тех, у кого есть доступ, и от подходящих задач, а интерактивный режим отделять от делегирования. Вывод из Т-Банка: кода стало больше, но сквозной поток почти не ускорился, задачи застревали на ревью и согласованиях. Рост было видно у команд, которые объединили discovery и delivery. А сэкономленные часы сами в деньги не превращаются. Если разгребать старый бэклог, в десять раз больше фич не дадут в десять раз больше эффекта: каждая следующая задача приносит меньше.
На вопрос, упадёт ли качество, Александр ответил, что ИИ усиливает текущие процессы. Сильная команда получает тесты и фитнес-функции, слабая получает месиво. Данила добавил, что хорошая кодовая база выгодна и самим агентам, так что улучшение идёт по кругу.
Ещё слайды доклада
Максим: узкое место теперь человек
Последний доклад дня закрыл тему, к которой так или иначе подходили все. Если код стал дешёвым, а процессы перестраиваются под агентов, узким местом становится сам человек. На осознанные решения у человека около 10 бит в секунду, рабочая память вмещает несколько элементов, а внимание быстро садится. С агентами весь день состоит из решений, потому что «лёгкую» работу, которая давала передышку и состояние потока, они забрали.
Максим очень точно описал эмоциональные качели. Азарт тянет взять ещё одну задачу, хотя отдача уже падает, и на усталость люди отвечают ещё одной задачей. Накопленный недосып добавляет ошибок, даже если сонливости не чувствуешь, а агенты быстро воплощают плохие решения. Новостной поток только давит: за одно утро выходят новые модели, чужие запуски и десятки результатов чужих агентов.
Его советы простые, и от этого их легко пропустить. Ограничить число параллельных агентов. Просить у них короткий итог вместо отчёта на десять страниц и не пересылать такие отчёты коллегам, а давать исходный замысел. Делить дни на проектирование и реализацию. Задать жёсткий критерий окончания дня. Высыпаться и хотя бы час в день двигаться так, чтобы были заняты руки, ноги и голова. Тело он назвал «хардовой частью» и предложил относиться к нагрузке как к налогу, а не как к ускорителю. 10x он называет вспышкой в долг: на старте нового проекта так бывает, но держать такой темп постоянно нельзя, а «готово на 90%» легко превращается ещё в 90% доработки.
Для руководителей у Максима две мысли. Единый процесс на всю организацию не работает: люди думают по-разному и по-разному держат много агентов, поэтому процессы подстраивают под людей и договариваются только об интерфейсах передачи артефактов. И «уволить всех и нанять новых» не выйдет: вкус и опыт нарабатываются годами, и научить опытного инженера работать с агентами проще, чем дать опыт тому, кто умеет только агентов. На вопрос про FOMO он ответил, что уникальными остаются вкус, авторское видение и умение довести замысел до конца, а устойчивость даёт своя ось. У него это две-четыре тренировки в неделю, вокруг которых выстраиваются сон и питание. Николай назвал этот доклад идеальным завершением дня, и я с ним согласен.
Ещё слайды доклада
Итоги дня от ведущих
В конце Николай и Данила обсудили, что их зацепило. Даниле больше всего запомнились доклад Константина с детерминированной проверкой и доклад Валерия с конкретными цифрами по картам. Николай выделил главную мысль Данилы: процесс, отделённый от людей, становится масштабируемым активом компании, хотя отделять его сложно. Ещё они поспорили, хватит ли для журнала изменений git. Данила считает, что git про текст, а нужна версионность любых данных, и что такой журнал обычно появляется после первого неудачного утра с ночными агентами. На вопрос, как не уйти в бесконечное улучшение своей системы, Николай ответил коротко: он улучшает только то, что начинает бесить.
Что я забрал себе
Если сложить доклады вместе, получается одна мысль, просто с разных сторон. Агент сам по себе работает хорошо, а проблемы начинаются на стыках: между агентами, между агентом и данными, между агентом и человеком, который его проверяет. Отсюда то, что я забираю себе.
- Правила, от которых зависит результат, делаю проверкой в коде. Строку в инструкции агент рано или поздно пропустит, об этом говорили и Данила, и Родион, и Константин.
- Список запрещённых лазеек пишу до старта, пока агент ещё не отчитался о 100%.
- Исполнителя проверяю в первые минуты работы, в конце поправлять курс уже поздно. Это совпало у Николая и у Родиона.
- Ускорение меряю по всему потоку от задачи до прода и помню, что следующие фичи приносят меньше.
- Если дойдёт до своего инференса, первым делом посмотрю на попадание в кэш, карты потом.
- Параллельных агентов держу столько, сколько решений я реально могу принять за день.