AI Engineer World’s Fair 2026: разбор докладов и куда движется AI-инженерия

TL;DR: AI Engineer World’s Fair — ежегодная конференция инженеров, которые строят продукты на моделях, а не обучают их. В расписании 2026 года было 560 сессий, и почти все сводились к одной мысли: узкое место переехало с самой модели на харнесс вокруг неё, то есть на трейсы, песочницы, эвалы, границы и UI. Ниже разбор по доступным записям: какие паттерны повторялись из доклада в доклад, как теперь чинят агентов после провала и что посмотреть, если время есть только на пять роликов.

AI Engineer World’s Fair 2026 ^[1] уже прошла, а у меня осталось стойкое ощущение, что я пропустил что-то важное. Годовой срез прикладной AI-инженерии в одном месте. В официальном расписании 560 сессий. Пять сотен докладов, воркшопов и кейноутов за несколько дней. Посмотреть это глазами не может никто, и я решил собрать русскоязычный навигатор, чтобы понять, что там вообще происходило.

Ещё пару лет назад главный вопрос звучал как “когда модель станет умнее”, и от ответа зависело всё. Сейчас модели стали достаточно хороши, чтобы доверить им почти всё, и внезапно оказалось, что ломается уже не интеллект ^[2]. Ломается среда вокруг него: как агенту дать инструменты, где поставить границы, как записать каждый шаг, как повторить падение и как понять, что он вообще стал лучше. Про это и была вся конференция. Не про модель, а про ее harness.

Как я это разбирал (и почему это уже часть вывода)

Смотреть 560 сессий подряд бессмысленно, поэтому я собрал агентный пайплайн. Он тянет официальное расписание, метаданные YouTube, субтитры к доступным записям и прогоняет каждую через саммаризацию, складывая всё в один реестр с темами, ссылками и таймкодами.

Из 560 сессий расписания публично на YouTube к моменту сбора нашлось 82 уникальных видео. Ещё три многочасовые трансляции главной сцены я разобрал на 55 тематических сегментов. А более пятисот сессий я вообще не смог достать как отдельные записи: их пока просто нет в открытом доступе. Так что полным архивом конференции это не назвать. Это навигатор по доступной части.

Грабли прилагались. Один доклад про RL-агента для ETL-пайплайнов отдавал HTTP 429 на субтитрах, так что пришлось качать аудио и гонять его через локальный whisper.cpp, пометив качество расшифровки как fallback. Мелочь, но показательная: даже чтобы просто изучить конференцию про агентов, мне понадобилась свой маленький харнесс с обработкой ошибок и запасными путями.

Всё, что получилось, я выложил отдельно: русскоязычный навигатор в репозитории на GitHub ^[3] и SPA поверх него на GitHub Pages ^[4]. Там русские саммари, тематическая карта, watchlist и ссылки на оригиналы. Это навигатор по доступным материалам, оригиналы он не заменяет. Дальше по тексту я буду ссылаться на конкретные доклады, их все можно открыть и проверить.

Агент это система исполнения, а не “модель с инструментами”

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

Харнесс вышел на первый план не вместо прогресса моделей, а благодаря ему. Пока модель ошибалась на каждом втором шаге, спорить про журналы и границы было рано. Как только она стала достаточно надёжной, чтобы ей доверили реальное действие, цена вопроса сместилась: теперь важно не “поумнеет ли она ещё ^[5]“, а можно ли объяснить, повторить и ограничить то, что она уже делает.

Лучше всего это сформулировано в докладе с говорящим названием What if the harness mattered more than the model? ^[6]: рычаг качества всё чаще не в весах модели, а в harness вокруг неё. В том же направлении бьёт разговор про детерминированную инфраструктуру для агентов ^[7]. А на главной сцене отдельным блоком разбирали идею разделения задачи и модели: задачу описывает и контролирует платформа, модель лишь исполняет свой кусок. Это был сегмент внутри длинной трансляции, без отдельных глав на YouTube, так что ссылку даю на таймкод в потоке ^[8], а не как точную цитату.

Если держать в голове только одну мысль с конференции, то вот эту. Всё остальное её частные случаи.

Упал в проде? Покажи чек

Первый частный случай неприятный. Агент что-то сделал в продакшене, всё сломалось, и вы стоите перед логами, пытаясь понять, что произошло. Сказать “модель сгаллюцинировала” мало. Нужно знать, что агент видел, какие инструменты вызвал, почему выбрал именно это действие и как теперь повторить сбой.

Разработчики выкатывают простую метафору: агенту нужны чеки. Как квитанция из магазина, только на каждое действие. Что вызвал, с какими входами, что подтвердилось. В докладе Agents Need Receipts ^[9] это ровно про проверяемый след вместо “я вроде дёрнул нужный инструмент”.

Отдельно бьёт по популярному заблуждению доклад Your Agent Failed in Prod. Good Luck Reproducing It ^[10]. Многие верят, что достаточно выставить temperature=0, и агент станет воспроизводимым. Не станет. Воспроизводимость даёт не нулевая температура, а record/replay: вы записываете весь прогон целиком, потом стабите узлы с LLM и заново прогоняете инструменты ^[11]. Инцидент из прода превращается в тест, который защищает вас от того же падения в будущем.

А доклад The Log Is The Agent ^[12] договаривает мысль до конца: журнал событий это не побочный продукт работы агента, а его основа. Архитектура начинается с того, что и как вы записываете, а промпт уже вторичен.

Сто инструментов в промпте это не суперсила

Есть соблазн думать, что чем больше инструментов у агента, тем он мощнее. Засунул сотню функций в промпт, и пусть выбирает. На практике так вы получаете агента, который путается в собственном арсенале и всё чаще ошибается выбором.

Доклад с прямым названием The 100-Tool Agent Is a Trap ^[13] показывает, почему толстый агент проваливается, и что делать вместо этого. Рецепт похож на обычный поиск: инструменты складывают в индекс, ищут релевантные под конкретный запрос и подгружают только их ^[14]. Не весь тулбокс в каждом обращении, а semantic routing ^[15] и подгрузка по необходимости.

Рядом стоит доклад Skills are the New SDKs ^[16], и он мне особенно близок. Навыки становятся тем, чем раньше были SDK: их надо индексировать, версионировать, тестировать и исполнять в контролируемой среде. То есть с навыками агента поступают как с нормальным программным активом, а не как со списком заклинаний в системном промпте.

Оценка живёт в проде, а не на слайде

Дальше конференция бьёт по бенчмаркам, любимой болячке индустрии. Одна красивая цифра в лидерборде давно ничего не гарантирует.

В докладе Production Evals For Agentic AI Systems ^[17] оценку разбирают как продакшен-контур. Мерить надо исходы сценариев ^[18]: дошёл ли агент до цели, насколько удачно вызывал инструменты, как часто эскалировал, где нарушал безопасность, сколько стоил и как восстанавливался после сбоя. Это уже не “76% на бенчмарке”, а набор сигналов, по которым видно, живой продукт или нет.

Обратную сторону той же проблемы показывает доклад с грустным названием User Signal Dies at the Retrieval Boundary ^[19]. Сигнал качества умирает на границе поиска: пользователь отметил, что ответ был бесполезен, это осело в трейсе, но retrieval ^[20] на следующем запросе снова достаёт ровно тот же нерелевантный документ, потому что оценка до него не дошла. Если трейсы и оценки остаются красивым дашбордом, из которого поиск ничего не извлекает, одна и та же ошибка ^[21] повторяется на каждом запуске.

Ответ модели это ещё не интерфейс

Многие агентные продукты спотыкаются об одно и то же: о прокладку между монитором и креслом.

Доклад Agent Output Is Not UX ^[22] прямым текстом говорит: сырой вывод модели это ещё не интерфейс. Пользователю нужен слой поверх: состояние, отмена, понятное отображение того, что агент сделал, и контроль над его действиями. В The UX of AI ^[23] это разворачивают в конкретику для продуктов с документами и файлами: guided workflows, источники, боковые панели, undo/redo.

Отдельно стоит мой любимый заголовок всей конференции, Browser Agents Don’t Need Better Models. They Need Better Eyes ^[24]. Браузерным агентам не нужна модель побольше. Им нужно нормальное зрение ^[25]: компактное структурное представление страницы вместо простыни скриншотов, диффы между состояниями и обратная связь о том, что действие не удалось. И совсем приземлённый, но важный доклад Your Agents Need a Save Button ^[26]: кнопка сохранения для агента это не мелочь UI, а контроль над состоянием долгой работы.

Ни один из этих докладов не просит модель получше. Все просят харнесс получше.

Скорость кода это ещё и долг

Сильнее всего меня зацепила именно скорость генерации кода, потому что она бьёт по главному хайпу года.

История продаётся так: coding-агенты пишут код быстрее, значит команда работает быстрее, значит прогресс. Доклад Your Coding Agent Is Creating Review Debt ^[27] аккуратно вскрывает подмену. Код действительно генерируется быстрее. Вот только понимать его, ревьюить и сопровождать всё равно приходится людям, и их пропускная способность не выросла. Разница уходит в долг. Не технический долг в старом смысле, а review debt: очередь изменений, которые никто толком не понял, но которые уже в системе.

Мысль звучит скучно, а последствия нет. Если код пишется быстрее, чем команда успевает его осмысливать и проверять, вы не ускорили разработку, вы переложили нагрузку с написания на ревью и сопровождение и сделали вид, что стало лучше.

Что оценка таких агентов сама по себе непростая задача, показывает SWE-Marathon: Evaluating Coding Agents at Billion-Token Scale ^[28]: гонять coding-агентов приходится на огромных масштабах, миллиардами токенов, чтобы вообще увидеть, где они ломаются. А на главной сцене отдельно разбирали урок с анализа миллиона AI-сгенерированных PR. Это тоже был сегмент длинной трансляции без отдельной главы, ссылку даю на таймкод ^[29], сам масштаб в миллион пул-реквестов уже говорит, что тема из разряда “померещилось” перешла в разряд измеримого.

Куда это всё сходится

Если собрать выводы вместе, вырисовывается один сдвиг. Индустрия движется не к тому, что “агенты сделают всё сами”, а к появлению отдельного слоя инфраструктуры, на котором агенты работают безопасно и повторяемо. Харнесс, трейсы, песочницы, разрешения, наблюдаемость, эвалы, UI и понятная эскалация к человеку. Агентные продукты потихоньку начинают проектировать как распределённые системы, а не как чат с приделанными функциями.

Те же повторяющиеся паттерны, если собрать их в табличку:

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

С чего начать, если времени в обрез

Главную мысль повторю ещё раз, потому что она стоит того. Я строил агентный пайплайн, чтобы разобрать конференцию, которая сама оказалась про harness. В этом весь 2026 год для AI engineering: побеждает не тот, у кого модель заработала больше попугаев, а тот, кто может объяснить, повторить, ограничить и проверить то, что его агент делает.

Я разобрал 82 публично доступные записи из 560 сессий расписания. Больше пятисот сессий в этот разбор не попали просто потому, что их пока нет в открытом доступе. Так что это взгляд по доступной части, а не приговор всей конференции.

Если же смотреть прямо сейчас и только пять роликов, я бы начал с этих: Browser Agents Don’t Need Better Models ^[35], Your Agent Failed in Prod ^[31], The 100-Tool Agent Is a Trap ^[33], What if the harness mattered more than the model? ^[30] и Skills are the New SDKs ^[37]. Остальное, с саммари и таймкодами, лежит в навигаторе ^[4].

Оставайтесь любопытными.

Пишу об искусственном интеллекте, языковых моделях и инструментах для разработчиков. Тестирую модели и сервисы на реальных задачах, а выводами делюсь в телеграм-канале ^[38].

Ссылки

• Репозиторий на GitHub ^[3]

• Навигатор на GitHub Pages ^[4]