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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

• Репозиторий на GitHub
• Навигатор на GitHub Pages

Частые вопросы