10 идей конференции AI Engineer о том, как меняется разработка, когда код пишут агенты.
В начале 2026 года небольшая команда OpenAI рассказала о необычном эксперименте.
Три инженера за пять месяцев создали внутренний продукт объёмом около миллиона строк кода и провели через репозиторий примерно 1500 pull request’ов. Продуктом пользовались сотни сотрудников. При этом люди не написали вручную ни одной строки: прикладной код, тесты, CI‑конфигурацию, документацию, observability и внутренние инструменты генерировал Codex.
По оценке команды, разработка заняла примерно десятую часть времени, которое потребовалось бы при традиционном подходе.
Но наиболее интересным результатом эксперимента оказался не миллион строк кода. Им стало открытие нового узкого места.
Когда код можно производить практически непрерывно, ограничением становится не скорость печати и даже не интеллект модели. Ограничением становится способность людей объяснить, что именно следует построить, организовать работу автономных исполнителей, проверить результат и не позволить автоматизации разрушить систему быстрее, чем команда успеет это заметить.
Именно этот сдвиг лучше всего описывают выступления AI Engineer 2026 — весенней конференции Europe в Лондоне и летней World's Fair в Сан‑Франциско.
Доклады посвящены разным темам: контексту, памяти, длительным циклам, командной координации, верификации и безопасности. При этом важно не сводить их к одной заранее выбранной теории. Каждый спикер предлагает собственную модель AI‑first разработки, основанную на своём опыте и профессиональной перспективе.
Вместе эти выступления показывают, что модель постепенно становится не всей системой, а её двигателем.
А мощный двигатель, лежащий на полу мастерской, — ещё не фабрика.
1. Ryan Lopopolo: люди направляют, агенты исполняют
Harness Engineering: How to Build Software When Humans Steer and Agents ExecuteAI Engineer Europe · 9 апреля 2026 · Смотреть доклад

Ryan Lopopolo — Member of Technical Staff в OpenAI и автор самого термина harness engineering. За его плечами техлид‑роли в Stripe в период быстрого роста компании, руководство developer productivity в Brex для организации из 350 инженеров и работа над data marketplace в Snowflake; он же создатель альтернативной реализации Ruby — Artichoke.
Lopopolo предлагает пересмотреть привычное разделение труда между человеком и программным агентом. Центральную мысль своего доклада он формулирует так:
Люди направляют. Агенты исполняют.
По мнению Lopopolo, в AI‑first разработке инженер всё реже должен лично переводить каждое требование в код. Его основной задачей становится проектирование среды, в которой агент сможет самостоятельно понять задачу, внести изменения, проверить результат и исправить обнаруженные ошибки.
Эту среду Lopopolo называет harness.
В его понимании harness включает не только инструкции для модели, но и окружающую инженерную инфраструктуру: документацию, тесты, архитектурные ограничения, правила работы с репозиторием, инструменты диагностики и механизмы обратной связи.
Само слово harness можно перевести как «упряжь», но выступление Lopopolo описывает не просто набор ограничений, удерживающих модель. Скорее, речь идёт о станке вокруг универсального двигателя: направляющих, датчиках, измерительных приборах, формах заготовки и аварийных выключателях.
В качестве главного примера Lopopolo приводит эксперимент OpenAI с полностью генерируемым Codex репозиторием. Файл AGENTS.md в этом проекте не пытался вместить все знания о системе. Он служил оглавлением, которое направляло агента к подробной документации, спецификациям, планам и архитектурным решениям.
Lopopolo подчёркивает, что такая документация должна оставаться актуальной автоматически. Для этого команда использовала структурные проверки и специальные «агенты‑садовники», которые искали устаревшие материалы и открывали pull request’ы с исправлениями.
Докладчик также обращает внимание на то, что одной текстовой документации недостаточно. Чтобы Codex мог не только написать код, но и оценить его работу, команда предоставила агенту доступ к Chrome DevTools, DOM‑снимкам, скриншотам, логам, метрикам и трассировкам.
Благодаря этому агент мог пройти полный цикл: запустить приложение, воспроизвести проблему, увидеть результат в интерфейсе, внести изменение и проверить, действительно ли ошибка исчезла.
Из этого опыта Lopopolo выводит практический принцип: если существенная информация недоступна агенту во время выполнения задачи, для агентной системы она фактически не существует.
Решение, оставшееся в Slack, устная договорённость между разработчиками или архитектурное ограничение, причины которого помнит только один сотрудник, не могут надёжно направлять автономного исполнителя. Такие знания необходимо переносить в документы, тесты, инструменты и автоматически проверяемые правила.
В докладе постоянно повторяется и другая идея: если агент систематически совершает одну и ту же ошибку, не всегда следует просто усиливать промпт. Сначала стоит проверить, не отсутствует ли в harness нужный инструмент, источник информации или механизм обратной связи.
Lopopolo предлагает рассматривать ошибки агентов как диагностический сигнал. Они показывают не только слабости модели, но и пробелы в инженерной среде вокруг неё.
Почему это важно. В более широком смысле доклад Lopopolo описывает переход от непосредственного написания кода к проектированию системы его производства. Человеческий опыт постепенно переводится в машиночитаемую форму: повторяющееся замечание на review становится правилом, типичная ошибка — тестом, архитектурная договорённость — линтером, а привычный способ диагностики — инструментом агента.
Инженер по‑прежнему принимает ключевые решения. Но теперь он стремится принимать их так, чтобы однажды сформулированное суждение автоматически влияло на каждую следующую итерацию работы.
2. Ash Prabaker и Andrew Wilson: как не потерять цель за несколько часов работы
How to Build Agents That Run for Hours
AI Engineer Europe · 8 апреля 2026 · Смотреть доклад

Если Lopopolo проектирует harness в пространстве — документацию, инструменты и обратную связь вокруг агента, — Ash Prabaker и Andrew Wilson из Anthropic борются со временем: что происходит, когда автономная работа растягивается на часы.
Оба — инженеры команды Applied AI в Anthropic, которые внедряют Claude у корпоративных клиентов; сам доклад вырос из их инженерного поста о длительных агентах.
Они начинают с различия между двумя способностями агента: выполнить короткую задачу и последовательно работать над большим проектом в течение нескольких часов.
По их мнению, это принципиально разные инженерные проблемы.
В докладе Prabaker и Wilson выделяют несколько причин, по которым длительные запуски начинают деградировать. У агента конечный контекст; он склонен строить слишком амбициозные планы; наконец, он плохо оценивает собственную работу.
По мере заполнения контекста агент может сохранять исходные инструкции буквально, но постепенно терять их смысл. Он начинает отклоняться от цели, повторять уже сделанные шаги, менять собственный план или объявлять работу завершённой после реализации лишь наиболее заметной её части.
Этот эффект докладчики описывают через понятия вроде context rot (порча контекста), context anxiety (тревога за заполненное окно) и coherence drift (дрейф связности): накопленный контекст перестаёт поддерживать последовательность и начинает ей мешать.
Prabaker и Wilson предлагают искать решение не только в более вместительных моделях, но и во внешней организации работы.
Они сравнивают долгий агентный процесс с проектом, над которым трудятся сменяющие друг друга инженеры. Каждый новый исполнитель приходит на смену без памяти о предыдущей. В такой ситуации качество зависит не только от способностей отдельных специалистов, но и от журналов, чек‑листов, структуры проекта и процедуры передачи работы.
В экспериментах Anthropic использовались две основные роли. Инициализирующий агент создавал каркас проекта, список требуемых функций и критерии готовности. Следующие агенты работали небольшими итерациями: читали Git‑историю и журнал прогресса, выбирали одну незавершённую функцию, реализовывали её и оставляли репозиторий в понятном рабочем состоянии для следующей сессии.
Prabaker и Wilson подчёркивают, что состояние работы необходимо выносить из диалога в устойчивые артефакты. Истинной памятью процесса становятся файловая система, Git, планы, списки функций и результаты тестов, а не внутреннее ощущение модели, что она «помнит» предыдущие действия.
Для списка функций Anthropic использовала JSON: в таком формате модель реже самовольно меняла структуру документа, чем в Markdown. Для end‑to‑end‑проверки веб‑приложений агенту предоставляли браузерные инструменты, чтобы он взаимодействовал с интерфейсом как настоящий пользователь.
Отдельную часть выступления Prabaker и Wilson посвящают adversarial evaluation.
По их мнению, генератор не должен быть единственным судьёй собственной работы. Поэтому они экспериментируют с раздельными ролями: один агент строит результат, другой получает более критическую инструкцию и пытается обнаружить дефекты.
Evaluator не просто читает diff. Он может открыть приложение через Playwright, нажать на элементы интерфейса и проверить, действительно ли реализованное поведение соответствует требованиям. Затем критика возвращается генератору, который выполняет следующую итерацию.
Prabaker и Wilson проводят аналогию с генеративно‑состязательными системами: настроить критика на строгость часто проще, чем заставить создателя результата быть столь же строгим к самому себе.
Ещё один важный тезис докладчиков состоит в том, что harness не является завершённой архитектурой. По мере улучшения моделей часть внешних механизмов становится ненужной, а другие проблемы перемещаются на новый уровень.
Prabaker формулирует это как движущийся фронтир: сильная модель не отменяет harness, а меняет место, где проходит самая сложная инженерная граница.
Что из этого следует. Доклад Prabaker и Wilson показывает, что продолжительность автономной работы зависит не столько от размера контекстного окна, сколько от качества внешнего состояния и передачи работы (handoff).
В этом отношении долгоживущий агент больше похож не на очень сосредоточенного отдельного программиста, а на круглосуточную сменную бригаду. Её продуктивность определяется тем, насколько точно следующий исполнитель может восстановить состояние проекта и насколько независимо система способна проверить результат предыдущего.
3. Maggie Appleton: двадцать четыре агента ещё не образуют команду
One Developer, Two Dozen Agents, Zero Alignment
AI Engineer Europe · 9 апреля 2026 · Смотреть доклад

Prabaker и Wilson показывают, как сохранить цель у одного долгоживущего процесса. Maggie Appleton ставит следующий вопрос: что происходит, когда таких процессов становится двадцать четыре — и все они работают параллельно.
Она рассматривает AI‑first разработку с необычной профессиональной позиции. Appleton работает на пересечении дизайна, культурной антропологии и программирования, а сейчас исследует будущее AI‑инструментов в GitHub Next. Сама она описывает себя как «дизайнера, антрополога и посредственного разработчика».
Поэтому в проблеме coding agents она видит не только техническое, но и социальное измерение.
Appleton начинает с популярного образа максимальной производительности: один разработчик открывает множество терминалов и запускает десятки параллельных агентов. В этой картине один человек получает «флот» исполнителей и начинает производить объём работы, для которого раньше требовалась целая команда.
Appleton не отрицает, что такой подход способен резко увеличить индивидуальный объём работы. Но она утверждает, что индивидуальная производительность и командная производительность — не одно и то же.
По её словам, десятки агентов не превращаются в команду автоматически. Каждый из них может локально выполнить свою задачу правильно, но вместе они начинают реализовывать несовместимые планы, дублировать исследования, изменять одни и те же компоненты и исходить из разных представлений о требованиях.
Appleton называет возникающую проблему alignment debt — долгом согласования.
Её основной аргумент состоит в том, что агентная разработка сжимает время между идеей и реализацией. Раньше до появления pull request проходили дни или недели, в течение которых команда обсуждала направление, дизайн, ограничения и архитектуру. Теперь агент способен предоставить готовую реализацию раньше, чем коллеги успеют узнать, что решение вообще обсуждалось.
В результате согласование не исчезает. Оно переносится на более поздний и дорогой этап, когда код уже написан, а автор идеи психологически и организационно заинтересован в его сохранении.
Appleton предупреждает, что ускорение индивидуального производства может увеличить общий объём координационной работы. Инженеры начинают выпускать больше изменений, но способность команды обсуждать и связывать их остаётся ограниченной.
Для исследования альтернативы GitHub Next разрабатывает Ace — multiplayer‑среду, сочетающую групповой чат, coding agent, GitHub и облачную машину.
Appleton показывает Ace как пространство, в котором участники видят общий разговор, план, терминал, запущенное приложение и действия агента. Сессия работает в изолированной microVM и сохраняется в облаке, поэтому работа не прекращается после закрытия ноутбука. Команда может совместно редактировать план до того, как агент превратит его в большой объём кода.
Важная для Appleton деталь состоит в том, что такая среда должна быть доступна не только программистам. Дизайнеры, product‑менеджеры, исследователи и сотрудники поддержки обладают контекстом, которого нет в репозитории, но который может радикально изменить правильное техническое решение.
Поэтому Appleton предлагает проектировать инструменты не только для связи «человек — модель», но и для более сложной системы:
команда → множество агентов → общий продукт.
Она завершает доклад оптимистическим тезисом. Если агенты действительно возвращают разработчикам часть времени, необязательно использовать его для производства ещё большего числа функций. Appleton предлагает направить этот ресурс на пользовательские исследования, дизайн, архитектурные размышления и качество — на те части разработки, которыми команды часто жертвовали из‑за стоимости реализации.
Здесь сдвигается масштаб. Appleton переносит разговор об AI‑first разработке с уровня персональной эффективности на уровень организации.
Её доклад показывает, что главным дефицитом может стать не код и не количество агентов, а общая картина происходящего. Двадцать четыре самолёта не образуют авиакомпанию без диспетчерской службы. По той же причине десятки автономных исполнителей не образуют команду без общей среды решений, зависимостей и ответственности.
4. Armin Ronacher и Cristina Poncela Cubeiro: трение как носитель инженерного суждения
The Friction Is Your Judgment
AI Engineer Europe · 10 апреля 2026 · Смотреть доклад

Если Appleton показывает, как ускорение производства кода переносит согласование на более поздний этап, Armin Ronacher и Cristina Poncelaubeiro спрашивают, какое сопротивление в разработке стоит сохранить намеренно.
Ronacher известен как создатель Flask и один из авторов экосистемы, в которую входят Jinja, Werkzeug, Click и другие инструменты Python‑разработки; сейчас он сооснователь Earendil. Значительная часть его карьеры связана с созданием удобных абстракций, упрощающих работу программиста.
Cristina Poncela Cubeiro — инженер той же Earendil, поэтому их доводы опираются на год работы с агентами в реальном продакшене.
Совместный доклад Ronacher и Poncela Cubeiro строится на почти парадоксальном тезисе: не всякое сопротивление в разработке необходимо устранять.
Авторы выступления обращают внимание на то, что AI‑инструменты продаются через обещание frictionless development. Разработчик описывает желание, агент быстро создаёт реализацию, а переход от идеи к работающему продукту становится почти бесшовным.
Ronacher и Poncela Cubeiro не спорят с тем, что многие формы трения бессмысленны. Медленный CI, ручное копирование данных, сложный локальный запуск и бюрократические согласования действительно следует устранять.
Но докладчики утверждают, что в разработке существует и другой тип трения. Оно возникает в точках, где человек чувствует стоимость решения, замечает сложность системы и вынужден применить собственное суждение.
Агент, по их словам, оптимизирует ближайший наблюдаемый результат. Он стремится сделать так, чтобы код запускался, тест проходил, а задача выглядела завершённой.
Однако эти признаки не отвечают на более трудные вопросы. Будет ли решение поддерживаемым? Не скрывает ли обработка ошибки реальную проблему? Не разрушает ли новая абстракция архитектурные границы? Не создаёт ли быстрое исправление неожиданные режимы отказа?
Ronacher и Poncela Cubeiro подчёркивают, что агент не способен чувствовать давление ответственности за созданную систему. Ответственность остаётся у человека, хотя объём генерируемого кода многократно увеличивается.
Они описывают опасный эффект: разработчики оказываются «в меньшинстве» по отношению к исполнителям, которые способны создавать изменения, но не способны нести ответственность за последствия.
В практической части доклада авторы предлагают делать кодовую базу понятной (*legible*) для агентов: создавать ясные модули, избегать скрытой магии, поддерживать устойчивые соглашения и механически закреплять важные границы.
Среди их примеров — запрет слишком широких catch‑блоков, raw SQL за пределами выделенного слоя, динамических импортов и неуникальных имён функций. Такие правила заставляют агента использовать существующие интерфейсы и затрудняют создание незаметных обходных путей.
Докладчики также предлагают намеренно увеличивать friction вокруг областей, где человеческое суждение особенно важно: миграций данных, изменений разрешений, архитектурных решений и необратимых операций.
Ronacher и Poncela Cubeiro не призывают замедлить всю разработку. Они предлагают различать трение, вызванное плохими инструментами, и трение, выполняющее роль точки контроля.
Удачная аналогия. Их позицию можно сравнить с электрическим предохранителем.
Предохранитель мешает току беспрепятственно течь не потому, что система плохо спроектирована. Он разрывает цепь именно в тот момент, когда свободное движение становится опасным.
В этом смысле доклад Ronacher и Poncela Cubeiro является важным контртезисом безусловной автоматизации. Хорошая AI‑first система не обязательно устраняет человека из каждого процесса. Иногда её задача — точно определить момент, в котором человек обязан в него вернуться.
5. Great Loops Debate: достаточно ли просто повторять агента
Dex Horthy, Geoff Huntley, Ian Livingstone и Greg Pstrucha
AI Engineer World's Fair · 2 июля 2026 · Смотреть дебаты

Ronacher и Poncela Cubeiro защищают точки, где человек обязан вмешаться. Great Loops Debate ставит соседний вопрос об архитектуре самой автономии: достаточно ли многократно запускать агента — или нужен настоящий контур управления.
Дебаты отличались от большинства выступлений тем, что не предлагали единой позиции. Участники были разделены на два лагеря и спорили о том, существует ли разрыв между популярностью agent loops и их практической эффективностью.
Geoff Huntley и Ian Livingstone защищали идею, что современные циклы уже дают значительный инженерный рычаг. Huntley, ранее техлид в Canva и Optiver, известен как автор Ralph Wiggum Loop; Livingstone — CEO и сооснователь Keycard (идентичность и доступ для агентов), а до этого сооснователь Manifold, купленной Snyk.
Ralph Wiggum Loop — предельно простая архитектура, в которой агент многократно запускается с общей целью, а состояние сохраняется в файловой системе и Git. Контекст регулярно очищается, и каждая новая сессия заново исследует текущее состояние проекта.
Сторонники этого подхода утверждали, что простота является преимуществом. Необязательно создавать сложный оркестратор, если сильная модель способна прочитать репозиторий, найти незавершённую работу, выполнить один шаг и оставить результат следующему запуску.
По их мнению, циклы особенно эффективны в задачах, которые можно разбить на небольшие проверяемые части: при портировании кода, исправлении тестов, реализации большого списка функций или массовой обработке репозитория.
Dex Horthy и Greg Pstrucha представляли противоположную сторону. Horthy — CEO и сооснователь HumanLayer, автор манифеста «12-Factor Agents» и человек, закрепивший термин context engineering; Pstrucha — инженер Sentry и основатель Subroutine, ранее staff‑инженер Robinhood и Facebook. Они не отрицали полезность повторных запусков, но утверждали, что вокруг loops возникло слишком много магического мышления.
Главную формулу этой стороны Horthy выразил так:
Перестаньте писать циклы. Начните писать контуры управления.
По его мнению, голый while true, внутри которого повторно вызывается агент, ещё не является производственной архитектурой.
Настоящий control loop должен знать желаемое состояние, уметь определить текущее, измерить разницу между ними, выполнить ограниченное действие и проверить, уменьшилось ли отклонение.
Horthy сравнивает такой подход с Kubernetes reconciliation loop. Система не просто выполняет одну и ту же команду. Она постоянно сравнивает фактическое состояние с целевым и выбирает следующий шаг на основании этой разницы.
Характерный вопрос Horthy к демонстрациям агентных циклов звучит так: «Где условие повторения?» Если система не может формально объяснить, почему делает ещё одну итерацию и при каком условии остановится, перед нами не управление, а автоматизированное движение.
Сторона Horthy также подчёркивала необходимость детерминированной проверки. Без независимого verifier агент может находить обходные пути, оптимизировать формальный показатель и убеждать себя, что приближается к цели.
Участники дебатов обсуждали и экономическую сторону: бесконечный цикл способен не только создавать code slop, но и чрезвычайно быстро расходовать токены. Поэтому критерий сходимости одновременно является механизмом качества и контроля стоимости.
При этом спор не закончился полным отрицанием одной из позиций.
Даже критики loops признавали, что простые циклы могут работать для хорошо определённых механических задач. А сторонники Ralph не утверждали, что повторный запуск способен самостоятельно принимать продуктовые или архитектурные решения любого уровня.
Почему этот спор важен. Дебаты показывают конкуренцию двух представлений об AI‑first разработке.
Первое делает ставку на возможности сильной модели и минимальную инфраструктуру: дайте агенту цель, состояние и возможность повторять попытки.
Второе рассматривает модель как ненадёжный компонент внутри классической системы управления: необходимы измерение, обратная связь, бюджет, независимая проверка и условие остановки.
Вероятно, сильные production‑системы будут сочетать обе идеи. Простота Ralph полезна внутри ограниченной задачи, но внешний control loop должен определять, какую задачу выполнять, как измерять прогресс и когда остановить процесс.
6. Patrick Debois: контекст становится новым кодом
Context Is the New Code
AI Engineer Europe · 10 апреля 2026 · Смотреть доклад

Если Great Loops Debate спорит о том, как устроить повторные запуски, Patrick Debois спрашивает, чем вообще питается каждый такой запуск: качеством контекста, который организация передаёт агенту.
Биография Debois придаёт его тезису особый вес.
В 2009 году Debois организовал первый DevOpsDays и стал одним из людей, с которыми связывают появление термина DevOps. В дальнейшем он работал на пересечении разработки, эксплуатации, безопасности и организационных трансформаций.
Теперь Debois утверждает, что отрасль переживает похожий сдвиг — только новой инженерной дисциплины требует не инфраструктура, а контекст, передаваемый агентам.
Основной тезис его выступления состоит в том, что контекст больше нельзя рассматривать как вспомогательный текст вокруг промпта.
Каждая новая сессия coding agent похожа, по выражению Debois, на нового сотрудника. Агент может хорошо программировать, но не знает истории системы, причин архитектурных решений, продуктовых ограничений и договорённостей, которые команда считает очевидными.
Разработчик с многолетним опытом носит этот контекст как мышечную память. Агент получает только то, что команда смогла сделать явным.
Debois включает в понятие контекста не только system prompt. К нему относятся AGENTS.md, CLAUDE.md, specifications, skills, MCP‑инструменты, архитектурная документация, примеры правильного кода, бизнес‑правила и история решений.
По мнению Debois, по мере удешевления генерации именно качество этих материалов становится новым узким местом.
Недостаточно научиться быстро писать инструкции. Контекстом необходимо управлять так же дисциплинированно, как кодом. Для этого Debois предлагает Context Development Lifecycle:
Generate → Evaluate → Distribute → Observe.
На стадии Generate организация превращает неявные знания в инструкции, спецификации и skills.
На стадии Evaluate она проверяет, приводит ли этот контекст к желаемому поведению: запускает evals, сравнивает разные модели и тестирует результат в sandbox.
На стадии Distribute контекст превращается в версионируемый артефакт, который можно подключать к проектам и обновлять как зависимость.
На стадии Observe команда изучает traces и ошибки агентов, чтобы обнаружить недостающие, устаревшие или противоречивые инструкции.
Debois отдельно предупреждает о context drift.
Команда может заменить тестовый фреймворк, изменить архитектурный принцип или переименовать ключевое понятие. При этом прежние сведения сохранятся в части документов, skills и примеров.
Агент получит несколько формально правдоподобных, но несовместимых версий реальности. Проблема будет выглядеть как ошибка модели, хотя фактически модель действует внутри противоречивой информационной среды.
Debois предлагает применять к контексту уже знакомые инженерные практики: версионирование, тестирование, dependency management, security scanning и observability.
Фактически он описывает CI/CD для организационных знаний.
Главный вклад. Debois переносит разговор с отдельных промптов на жизненный цикл знаний.
История DevOps показала, что недостаточно один раз собрать приложение: нужен процесс, связывающий создание, доставку, эксплуатацию и обратную связь.
Debois утверждает, что то же самое теперь происходит с контекстом. Не нужно пытаться однажды написать идеальный AGENTS.md. Нужно построить систему, которая быстро покажет, когда этот файл перестал соответствовать действительности.
7. Stefania Druga: память как инфраструктура исследования
Memory Harnesses for Long‑Running Research Agents
AI Engineer World's Fair · 1 июля 2026 · Смотреть доклад

Debois описывает, как превращать организационные знания в версионируемый контекст. Stefania Druga продолжает эту линию для долгоживущих исследовательских агентов: недостаточно передать инструкции — нужна память, которая сохраняет причинность выводов.
Druga работает над памятью и observability для долгоживущих исследовательских агентов в Sakana AI. До этого она занималась мультимодальными системами в Google DeepMind, а её нынешние проекты связаны с self‑improving research agents, которые проводят длинные циклы экспериментов и рассуждают на основании накопленных доказательств.
Судя по доступным материалам и интервью по теме, Druga предлагает не отождествлять память агента с полным архивом диалога.
По её логике, сохранение всех сообщений и действий ещё не создаёт полезную память. Напротив, по мере роста такого архива агенту становится сложнее определить, какие сведения важны, какие выводы были опровергнуты и почему было принято конкретное решение.
Для долгого исследовательского процесса особенно важна не хронология, а причинность.
Агенту недостаточно восстановить запись: «мы решили использовать метод B». Ему необходимо понимать, почему метод A был отвергнут, какие данные подтвердили выбор B, насколько надёжны эти данные и при каких условиях решение следует пересмотреть.
Druga развивает идею memory harness — инфраструктуры, которая помогает агенту не просто извлекать прошлый текст, а поддерживать связность исследования.
Такая память должна различать наблюдения, доказательства, гипотезы, решения, открытые вопросы и накопленный опыт. Она также должна связывать выводы с источниками и действиями, на основании которых они появились.
В публичных описаниях своей работы Druga подчёркивает связь памяти с observability и координацией нескольких моделей. Исследовательская система должна видеть, какие решения принимались, как менялась уверенность и где именно агент потерял нить рассуждения.
В этом подходе память не является пассивным хранилищем. Она участвует в управлении дальнейшим поведением агента.
Особенно опасна не забывчивость, а ошибочная память.
Если агент не может найти прежний факт, он может провести поиск или эксперимент повторно. Если же он извлекает ложное или устаревшее воспоминание как надёжное основание, следующие десятки действий могут быть логичными, последовательными — и полностью неверными.
Поэтому из позиции Druga следует необходимость управлять качеством памяти: хранить происхождение сведений (*provenance*), уровни уверенности, сроки актуальности и связи между утверждениями и доказательствами.
Удачная аналогия. Memory harness здесь ближе не к человеческому мозгу и не к складу документов, а к лабораторному журналу.
Хороший лабораторный журнал не просто записывает всё происходящее. Он позволяет восстановить ход исследования: что наблюдалось, что предполагалось, какой эксперимент был проведён и почему вывод считается обоснованным.
В такой логике для действительно долгоживущих агентов память становится не функцией интерфейса, а отдельным инфраструктурным слоем. Именно он определяет, способен ли агент накапливать знания, а не только текст.
8. Tariq Shaukat: в мире агентов власть переходит к верификаторам
In the Land of AI Agents, the Verifiers Are King
AI Engineer World's Fair · 1 июля 2026 · Смотреть доклад

Память помогает агенту не потерять нить рассуждения. Tariq Shaukat ставит следующий предел автономии: даже связный и уверенный результат бесполезен, если организация не умеет достаточно быстро его проверить.
До прихода в Sonar Shaukat был президентом Google Cloud и Bumble. Его опыт связан не только с программными инструментами, но и с масштабированием крупных технологических компаний и инфраструктурных бизнесов.
Поэтому в своём докладе Shaukat рассматривает coding agents как часть производственной системы.
Его центральный тезис заключается в том, что предел автономии определяется не возможностями генератора, а возможностями проверки.
По мнению Shaukat, организации могут делегировать агентам только тот объём работы, который способны достаточно быстро и надёжно верифицировать.
Если агент за час производит код, который человек проверяет несколько дней, автоматизация не устраняет узкое место. Она просто переносит его на этап review.
Более того, резкое увеличение потока изменений может снизить качество человеческой проверки. Разработчики начинают читать pull request’ы по диагонали, доверять уверенным отчётам агентов и пропускать проблемы из‑за ограниченного внимания.
Shaukat предлагает Agent Centric Development Cycle — AC/DC. В версии Sonar цикл организован вокруг стадий Guide, Generate, Verify и Solve.
На стадии Guide агент получает не только описание задачи, но и контекст существующей архитектуры, организационные стандарты и ограничения.
На стадии Generate модель создаёт изменение.
На стадии Verify результат проходит многоуровневую проверку.
На стадии Solve обнаруженные проблемы возвращаются специализированному агенту исправления.
Shaukat подчёркивает принцип нулевого доверия (*zero trust*): AI‑generated code не должен считаться надёжным только потому, что он выглядит убедительно или прошёл собственную самопроверку агента.
При этом верификация должна сочетать вероятностные и детерминированные методы.
LLM‑verifier способен оценить соответствие намерению, заметить смысловую неполноту и обнаружить подозрительное решение. Но он остаётся моделью, подверженной тем же классам ошибок, что и генератор.
Статический анализ, проверка типов, security scanning, архитектурные правила и quality gates (жёсткие пороги качества) дают воспроизводимый результат и могут выполнять роль жёсткого условия остановки. Sonar прямо настаивает, что независимая модель полезна как критик, но не должна быть единственным финальным gate.
Эту концепцию компания реализует в Sonar Vortex. Инструмент может передавать агенту архитектурный контекст до генерации, а затем проверять локальные изменения с использованием информации, ранее собранной в CI: зависимостей, типов, структуры проекта и compiled artifacts.
Sonar Vortex совместим с Claude Code, Cursor, Codex и другими AI‑enabled IDE и CLI.
Shaukat таким образом предлагает перенести верификацию внутрь агентного цикла, а не оставлять её финальной человеческой процедурой после создания огромного pull request.
Почему это важно. Позиция Shaukat напоминает одновременно научное рецензирование и двойную бухгалтерию.
Автор исследования не считается единственным судьёй достоверности своей работы. А наличие одной записи о финансовой операции не доказывает правильность баланса.
По той же причине создатель результата не должен самостоятельно выдавать ему сертификат качества
В мире дешёвой генерации одним из самых ценных компонентов software factory становится не очередной генератор, а надёжная функция done — механизм, имеющий право сказать агенту как «да», так и «нет».
9. Mike Chambers: свобода внутри production cage
Harness Engineering: Building the Production Cage for Powerful Domain Agents
AI Engineer World's Fair · 2 июля 2026 · Смотреть доклад

Shaukat показывает, что предел автономии задаёт проверка. Mike Chambers переносит тот же вопрос на production: даже проверенный агент опасен, если у него слишком широкие полномочия.
Chambers — Senior Developer Advocate по генеративному AI в AWS, признанный AWS Machine Learning Hero и соавтор одного из самых популярных курсов DeepLearning.AI по большим языковым моделям; до этого он двадцать лет работал архитектором решений и безопасности.
Он рассматривает переход от прототипа к production как отдельную инженерную задачу.
В связанных выступлениях о production‑ready agents он подчёркивает, что работающий demo‑agent и агент, которому можно доверить реальные данные и действия, — принципиально разные системы.
Production требует инфраструктуры исполнения, идентичности, памяти, наблюдаемости, изоляции, обработки отказов и контроля доступа.
Метафора production cage хорошо передаёт предлагаемую Chambers логику.
Он не призывает заставлять агента спрашивать разрешение перед каждым чтением файла или запуском теста. При таком устройстве автоматизация потеряла бы смысл.
Вместо этого агенту необходимо создать заранее определённый периметр, внутри которого он способен действовать самостоятельно.
Агент может редактировать код, запускать проверки, читать разрешённые логи, обращаться к определённым инструментам и создавать pull request. Но он не должен автоматически получать неограниченный доступ к production, секретам, сети и критической инфраструктуре.
В основе этого подхода находится различие между способностью и полномочием.
Модель может знать, как удалить таблицу или изменить инфраструктуру. Из этого не следует, что у неё должна быть техническая возможность выполнить такое действие напрямую.
Chambers предлагает думать не только о логике агента, но и об окружающей его production‑архитектуре: runtime, gateway, managed memory, identity и observability.
Практическим воплощением этой модели в экосистеме AWS стал Bedrock AgentCore. В документации и связанных материалах он разделяет исполнение агента, доступ к инструментам, память, идентичность и наблюдение на отдельные управляемые компоненты.
Такое разделение позволяет предоставлять агенту полезные возможности без выдачи универсальных credentials. Инструмент может быть обёрнут в отдельный gateway, код исполняться в изолированной среде, а действия — записываться для последующего аудита.
Метафору Chambers поэтому точнее понимать не как клетку, а как испытательный полигон. Внутри него можно двигаться быстро и даже ошибаться, поскольку возможный радиус поражения ограничен заранее.
Из этой позиции также следует связь автономии с обратимостью.
Создание локального файла или ветки почти полностью обратимо. Отправка сообщения клиенту, изменение production‑базы или финансовая транзакция имеют другую стоимость ошибки и требуют более узких полномочий либо человеческого подтверждения.
Сдвиг вопроса. Chambers переносит акцент с «насколько умён агент?» на «что произойдёт, когда он ошибётся?».
Production cage не делает модель надёжной. Он делает её ошибку ограниченной, наблюдаемой и, по возможности, обратимой.
Это фундаментальное различие. Безопасная автономия строится не на надежде, что агент всегда примет правильное решение, а на архитектуре, которая не позволяет одному неправильному решению получить неограниченные последствия.
10. Steve Yegge: у агентного кода появляется цепочка происхождения
Permissions, Provenance, and the Agent Supply Chain
AI Engineer World's Fair · 30 июня 2026 · Смотреть доклад

Chambers ограничивает радиус поражения одного агента. Steve Yegge расширяет рамку ещё на один уровень: у агентного кода появляется целая цепочка происхождения — модели, skills, MCP‑серверы, зависимости и делегирование между агентами.
Yegge пришёл к теме агентной безопасности после нескольких десятилетий работы в программной индустрии. Он занимал инженерные и руководящие позиции в Amazon и Google, а до начала карьеры программиста проходил подготовку оператора ядерной энергетической установки в Военно‑морских силах США. Сейчас Yegge экспериментирует с системами оркестрации coding agents, включая Gas Town.
Его выступление начинается практически с предупреждения: относиться к новой агентной инфраструктуре следует серьёзно и с определённой долей страха.
Yegge утверждает, что AI‑разработка создаёт новую software supply chain.
В обычном приложении уже существует цепочка компиляторов, библиотек, контейнеров, CI‑систем и сторонних сервисов. Agentic development добавляет в неё модели, system prompts, skills, MCP‑серверы, внешние документы, браузерные данные, сгенерированные зависимости и агентов, которые могут делегировать работу другим агентам.
Каждый элемент получает возможность повлиять на конечный артефакт и создать дополнительный канал атаки.
Одним из характерных рисков Yegge называет slop squatting — захват имён, которые модели склонны «галлюцинировать».
Модель может придумать правдоподобное название несуществующего пакета. Злоумышленник публикует библиотеку с таким именем, добавляя ожидаемую функциональность и скрытый backdoor. При следующей генерации агент устанавливает уже настоящий вредоносный пакет.
Сборка может оставаться зелёной, а зависимость — выглядеть вполне естественно. Поэтому Yegge настаивает, что происхождение AI‑generated dependencies должно проверяться отдельно.
В качестве ещё одного примера Yegge рассказывает о security hardening своего многолетнего игрового проекта.
Агент провёл специальный проход, обработал credentials и сообщил, что работа выполнена. После этого специализированный сканер Snyk обнаружил 241 уязвимость, которые агент не искал или не распознал.
Yegge использует этот эпизод, чтобы обосновать необходимость раздельных проходов.
Нельзя включить безопасность в длинный универсальный промпт и считать задачу решённой. Security review должен иметь отдельные инструменты, инструкции, scanners и adversarial agents.
По мнению Yegge, за основным исполнителем должны наблюдать специализированные системы, которые проверяют credentials, зависимости, разрешения и поведение других агентов.
При этом security scanner решает лишь часть проблемы. Необходимо также отслеживать provenance — происхождение каждого действия и артефакта. В агентной системе этот вопрос становится ещё шире, чем в классической supply chain.
В традиционной supply chain команда спрашивает, кто опубликовал библиотеку и была ли она изменена.
В агентной системе список вопросов расширяется:
— какая модель инициировала изменение;
— какой контекст она получила;
— какими инструментами воспользовалась;
— от чьего имени действовала;
— какие разрешения имела;
— кто проверил результат;
— можно ли воспроизвести цепочку решения.
Yegge фактически предлагает относиться к агентному процессу как к цепочке хранения улик. Недостаточно получить работающий артефакт. Необходимо сохранить возможность доказать, как он появился.
Политическая рамка. Yegge переводит разговор от организации отдельных агентов к архитектуре доверия всей системы.
Как только один агент способен делегировать работу другому, вызывать сторонние инструменты и действовать от имени пользователя, в системе появляются идентичности, полномочия, доверие, надзор и ответственность.
Это уже не только вопрос удобной оркестрации. Это вопрос о том, кто имеет право действовать, на каком основании и кто сможет восстановить произошедшее после ошибки или атаки.
Какую общую картину создают эти выступления
Ни один из десяти докладчиков не предлагает всю архитектуру AI‑first разработки целиком.
Lopopolo говорит прежде всего о harness. Prabaker и Wilson — о длительной связности и adversarial evaluation. Appleton — о командной координации. Ronacher и Poncela Cubeiro — о сохранении человеческого суждения. Участники Great Loops Debate спорят об архитектуре циклов. Debois проектирует жизненный цикл контекста. Druga — инфраструктуру памяти. Shaukat ставит в центр верификацию. Chambers — ограничение полномочий. Yegge — provenance и безопасность supply chain.
Но если сопоставить их позиции, можно увидеть общую тенденцию.
Человек задаёт намерение → контекст формализует знания → harness организует работу → координация согласует параллельных исполнителей → память сохраняет связность → агенты выполняют действия → verifiers проверяют результат → permissions ограничивают последствия → provenance сохраняет ответственность.
Это уже наш синтез, а не тезис одного из выступлений.
Контекст объясняет, чего хочет организация. Harness превращает намерение в воспроизводимый процесс. Координация предотвращает конфликт между параллельными исполнителями. Память не даёт потерять причинную нить. Verifiers определяют, достаточно ли хорош результат. Permissions ограничивают стоимость ошибки. Provenance позволяет восстановить цепочку ответственности.
AI‑first разработка поэтому всё меньше напоминает разговор талантливого программиста с умным ассистентом.
Она начинает напоминать проектирование операционной системы.
Модель предоставляет вычислительную способность. Контекст определяет доступное ей представление мира. Harness организует процессы. Координация связывает параллельных исполнителей. Память хранит состояние. Verifiers выполняют роль механизмов контроля. Permissions регулируют доступ к ресурсам. Provenance становится журналом аудита.
Можно использовать и политическую метафору.
В зрелой агентной системе появляются идентичности, полномочия, юрисдикции, механизмы надзора, арбитры и право вето. Но строить такое «государство для агентов» — не самоцель. Это цена возможности предоставить нечеловеческим исполнителям реальную свободу действий.
Главный сдвиг, который показывают доклады AI Engineer, состоит не просто в том, что агенты научились писать больше кода.
Код постепенно становится дешёвым промежуточным материалом.
Новой инженерной работой становится проектирование системы, которая решает:
— какой код вообще стоит создавать;
— какой информации можно доверять;
— как сохранить цель на длинном горизонте;
— когда агент действительно закончил;
— какие ошибки допустимы;
— где необходимо человеческое решение;
— кто имеет право совершить действие;
— кто отвечает за его последствия.
Будущий AI‑инженер — не тот, кто лучше других разговаривает с моделью. Это архитектор среды, в которой нечеловеческие исполнители могут действовать быстро, не теряя цели, качества и ответственности.