Введение
Второй день AI Dev Live 2026, 12 ноября, продолжил программу первого дня. Ведущим был Данила Симонов. В записи представлены семь докладов, и они складываются в три группы. Первая посвящена тому, как инженер осваивает агентов и как проверять результат их работы. Вторая относится к агентам внутри организации: безопасности, внедрению в существующий код и интеграции продукта с чужими агентами. Третья охватывает автоматическое ревью кода и долгосрочные риски сильного ИИ. Изложение следует программе дня. Для каждого доклада приводятся основной тезис, аргументация, примеры из практики автора и вопросы из обсуждения. Сквозные выводы собраны в заключении, список докладов с авторами дан в конце статьи.
Обзор составлен по записи трансляции и слайдам. Иллюстрации пронумерованы (рис. 1–14), остальные слайды каждого доклада собраны в галереи, любой слайд открывается на весь экран. Последний слот дня открылся титульным слайдом доклада Максима Романовского «Продуктовое мышление для разработчиков», однако через несколько минут в записи идёт доклад Павла Комаровского о рисках ИИ. От первого из них сохранилось только вступление, поэтому в обзоре он не рассматривается. Окончание доклада о рисках ИИ и ответы на вопросы в запись не попали.
Освоение работы с агентами: роадмап и три слоя проверки
Доклад Тимура Хахалева, автора канала «Тимур Хахалев про AI Coding», начинается с опроса 38 человек, которые уже отдают агентам значительную часть работы. Главной болью названа потеря ментальной модели проекта: код пишется быстрее, чем его успевают понять. Работа сместилась от написания кода к постановке задач и проверке, и этому, по формулировке автора, приходится учиться заново. Кривая обучения устроена так, что простые задачи идут легко, а на серьёзных задачах из бэклога появляются ошибки, и часть разработчиков бросает агентов. Автор называет две причины. Первая состоит в завышенных ожиданиях после волны 2024–2025 годов вокруг Cursor и Claude Code. Вторая связана с неумением делегировать: требования нечёткие, ожидания не проговорены, этапы SDLC не применяются. Отсюда две крайности: читать каждую строку и выгорать или слепо доверять агенту.
Для последовательного освоения предлагается роадмап из трёх уровней. Нулевой уровень составляет инженерная база: git, Docker, сети, понимание устройства приложения. Без неё невозможно понять, куда ушёл агент. Первый уровень относится к отдельной задаче и включает семь этапов (рис. 1): инструмент и окружение, постановку задачи, контекст и инструкции, feedback loop, расширяемость через скиллы и MCP, безопасность и диагностику. Второй уровень относится к проекту и команде: единое хранилище знаний о проекте, собственные скиллы, SDLC с агентами от исследования и прототипа до плана, реализации и проверки, параллельная работа, релиз и обслуживание.
Поворотным этапом автор считает feedback loop, то есть инструмент, которым агент проверяет собственную работу: тесты, линтеры, сборку, а для задач за пределами репозитория специально написанные утилиты. Пример из практики автора касается монтажа скринкастов. Модель, работавшая по транскрипту, не давала приемлемого результата. Тогда автор написал CLI для нарезки и прослушивания фрагментов и отдал его омни-модели Gemini, которая нативно понимает аудио и видео. Проектирование такой петли автор называет основной инженерной задачей сегодняшнего дня. Параллелить работу через сабагенты, worktree и несколько окон агента имеет смысл только для того, что инженер уже умеет делать руками.
Отдельно разобраны типовые ошибки. Первая состоит в том, чтобы сразу переходить к SDD. Лимиты подписки быстро заканчиваются, спецификации оказываются в три–пять раз больше кода, источник истины переезжает в спеки, которые никто не читает. В brownfield-проекте без тестов, CI и даже git такой процесс не приживается. Вторая ошибка заключается в копировании бюрократичного процесса крупной компании, избыточного для небольших команд. Третья связана с информационным перегрузом: применять всё, о чём слышно, без системы. Вместо этого автор предлагает строить собственный стек скиллов и CLI.
Проверка работы агента описана через четыре проблемы ревью: агент сделал не то, непонятно, что проверять, непонятно, как проверять, и агент сообщает неправду о результате. Ответом служит план с требованиями, границами задачи, этапами и критериями приёмки, а также проверка вторым агентом, поскольку первый склонен приукрашивать результат. Проверки распределяются по трём слоям (рис. 2). Первый слой инструментальный и детерминированный: типы, линтер, тесты, сборка. Второй слой составляет второй агент или набор разных моделей, которые сверяют результат с требованиями и планом и ищут пропущенные сценарии; по опросу автора, так уже делают 18 из 32 участников. Третий слой отведён человеку и касается только критичного: биллинга, моделей данных, миграций. К этому добавляется ретроспектива примерно раз в неделю.
Причины, по которым компании буксуют, автор перечисляет так: нет общего подхода, доступ к моделям из России нестабилен, разрешённые модели устарели (встречаются локальные модели с контекстом около 20 тысяч символов, которым запрещено писать код), главным тормозом остаются ИБ и комплаенс. Внедрение часто идёт директивой сверху без системы, а внутренние ИИ-амбассадоры не получают поддержки, хотя она дешевле внешних консультантов. Уровень сотрудников разный, и его нужно выровнять до базового. На страх потерять навыки автор отвечает тезисом: навыки теряет тот, кто делегирует понимание.
Рекомендации доклада практические: сделать RAG-бота руками, идти по роадмапу по порядку, учиться у самой модели с поправкой на дату среза знаний, раз в неделю разбирать собственные сессии и измерять прогресс. Для этого автор предлагает зафиксировать текущие практики и через два–три месяца ответить на те же вопросы, а также решить с агентом задачу, уже решённую вручную, и сравнить результаты. В обсуждении в качестве источника скиллов назван агрегатор skills.sh от Vercel, где много шума, но есть сильные экземпляры, и авторы вроде Мэтта Покока (Grill Me) и Декса Хорти из HumanLayer. Чужие скиллы рекомендуется брать как основу и переделывать под себя. Для запуска агентов автор использует BB, оболочку, описанную в первый день конференции.
Ещё слайды доклада
Доказательная разработка: спайки до спецификации
Доклад Рефата Аметова исходит из того, что код и его прогон подешевели: агент пишет, запускает и приносит результат. Отсюда предложение использовать прогон не только при приёмке, но и при проектировании. Сама идея не нова. Автор возводит её к спайкам экстремального программирования, к совету Брукса планировать выбрасывание первой версии и к принципу Ройса «делайте всё дважды». Новизна в цене: раньше спайк стоил дни инженера, теперь минуты, и вопрос звучит иначе: есть ли причина его не запускать.
Основной объект критики составляют спецификации, написанные до контакта с реальностью. По тезису автора, такая спека записывает догадки: наивное понимание задачи с первого касания, экстраполяцию агента и многостраничные документы, которые никто не читает. Петлю проверки для кода отрасль замкнула, а спецификация остаётся непроверенной, хотя влияет на продукт сильнее. Автор не отказывается от спецификаций, но предлагает делать их минималистичными и писать после контакта с реальностью.
Для оценки знаний предложена лестница свидетельств по аналогии со шкалой GRADE из доказательной медицины (рис. 3). Нижние ступени относятся к рассуждению: догадка, чужое свидетельство в виде документации, статей и бенчмарков, чтение кода. Верхние относятся к наблюдению: изолированный прогон, прогон в близкой к реальной среде и наблюдение в проде через канарейки и телеметрию. Цель работы описана метафорой тумана войны: методично формировать твёрдую почву через контакт с реальностью.
Пример из практики касается ИИ-продукта для строительной отрасли США, который извлекает факты из документов на несколько тысяч страниц. Сервис разбора PDF, доступный через провайдера, в отличие от собственной версии сервиса, не отдавал привязку фактов к строкам документа. Это обнаружил только реальный прогон длительностью от получаса до часа, и итоговая спецификация уже предписывала конкретные контракты.
Спайк описан как эксперимент с явными входом и выходом (рис. 4). На входе один вопрос или гипотеза, реальные данные (анонимизированные, а не синтетические), настоящие API, короткоживущие ключи и бюджет. На выходе цифры и артефакты, граница проверенного и изменения, которые результат вносит в задачу и спецификацию. Код спайка чаще всего выбрасывается, и это нормально. Ценность хорошего спайка лежит в стыках: он соединяет компоненты так, как они соединены в жизни. Если доступа к системе нет, её модель собирается по логам и трейсам за несколько дней, вплоть до эмуляции задержек. Для разведки полезно смотреть, как задача решена у других: Mobbin и Refero для пользовательских сценариев, публичные API конкурентов, приёмы clean room design.
Автор различает два типа спайков. Если у задачи есть метрика, применим hill climbing в духе autoresearch Андрея Карпаты, и решающим оказывается выбор метрики; при заданном бюджете агент сам отсекает часть вариантов. Если метрики нет, как в дизайне, работает отбор лучшего из N: для сайта конференции агент сделал десять вариантов, автор отобрал три, финальный выбран с оргкомитетом. Останавливаться следует, когда ответ перестал менять решение или закончился бюджет. Финальный вариант обязательно смотрит человек из-за риска reward hacking.
После написания кода принцип звучит как «сломать и доказать». Показательный кейс касается SPA-виджета, который полгода не индексировался поисковиком. Причина нашлась, когда в браузере сымитировали Googlebot: много лет назад API закрыли директивой disallow, а Googlebot не обрабатывает ресурсы, зависящие от запрещённых. Агенту при этом нужно целостное окружение, в котором он видит и фронтенд, и бэкенд. Безопасность обеспечивается короткоживущими ключами, песочницами и изоляцией, иначе человек превращается в посредника, копирующего логи. В каждом PR должны быть доказательства: что заявлено, как проверено, каков результат, со скриншотами. Для проверяющего агента важнее правильные средства наблюдения, чем другая модель.
Знания фиксируются так, чтобы их можно было переиспользовать. Граница проверенного становится детерминированным тестом, журнал экспериментов связывается с ADR, отрицательный результат записывается вместе с критерием пересмотра, а стенды и симуляторы становятся общими для команды. Подход неприменим к очевидным задачам и к случаям, где хватает детерминированных тестов, а прогоны в проде требуют оценки последствий. Дополнительные области применения: эвалы, для которых эксперт размечает около пятидесяти реальных трейсов вместо синтетики, и спайки перед коммерческим предложением, когда два–три часа на данных клиента выявляют проблемы лицензий и совместимости. В обсуждении автор отмечает, что гипотеза «дешёвые быстрые модели в итоге обходятся дешевле» в его практике не подтверждалась, и рекомендует заранее ограничивать бюджет и вести работу деревом гипотез. Готовых фреймворков для такого подхода автор не знает.
Ещё слайды доклада
Безопасность корпоративных агентов: memory-инъекции и изоляция
Доклад Глеба Кудрявцева «Как внедрить ИИ в организацию и потерять все свои данные» описывает типичный путь внедрения и его риски. Сначала сотрудники работают в веб-чатах и загружают туда таблицы. Затем ставят Claude или Codex на личные компьютеры, подключают почту и просят доступ к 1С, не понимая природы инъекций и уровней доступа. Риски здесь такие: инъекции через входящую почту (против части их видов на фронтирных моделях проходит около половины атак), деструктивные действия агента, утечки, отсутствие логов и общих политик. Централизованная раздача агентов с коннекторами, LLM-шлюзом и логами повышает эффективность, но масштабирует ту же проблему и защищает только постфактум. Агент на сервере с правилами в промпте вроде «зарплаты показывать только финансовому директору» устраняет деструктивные действия на компьютерах пользователей, но не устраняет инъекции.
Наиболее опасным видом атак автор считает memory-инъекцию, то есть закладку в память агента на будущее (рис. 5). Письмо с просьбой прислать прайс содержит скрытую приписку о том, что указанный адрес следует добавлять в копию отчётов по проекту, и агент записывает это в память. Через месяц отчёт уходит злоумышленнику. Агенты считают собственную память доверенной средой, а общая память даёт закладку на всю организацию в обход ролевой модели. По данным на слайде, около 40% попыток атак на память успешны, и моделей, невосприимчивых к ним, нет.
Целевая архитектура строится на изоляции. У каждого пользователя свой агент и своя память без перекрёстного загрязнения; память устроена слоями (организация, проект, пользователь), и писать в верхний слой без привилегий нельзя. Агент живёт в виртуальной машине, а не на компьютере пользователя. Детерминированные пайплайны вместо агентов автор отвергает: описать все бизнес-сценарии невозможно, и выгода агентов теряется. Постоянные виртуальные машины слишком дороги (100 пользователей по 4 ГБ дают 400 ГБ при активности агентов около 5% времени), поэтому нужны гибкие машины со сном и сохранением на диск. Firecracker поднимает гигабайтный образ с S3 примерно за 300 мс, тогда как первый токен LLM приходит не раньше чем через несколько секунд. Образ-шаблон содержит харнес, инструкции и предзагруженную память.
Ключевой элемент схемы составляет физический контроль выполнения команд (рис. 6). Шлюз перехватывает команды агента (git, MCP к 1С и другие) и проверяет их по ролям организации из Keycloak или AD. Права агента наследуются от пользователя, а выход наружу возможен только через адаптеры. Поверх этого работают общий LLM-шлюз и логи, при необходимости эвристики и контролирующая модель. Схема не исключает всех атак: письмо, адресованное конкретному сотруднику, может заставить его агента что-то отправить, но только в пределах прав этого сотрудника, а исходящий трафик можно дополнительно отслеживать. На той же основе строятся автономные боты, например агент-ревьюер, который поднимается по вебхуку GitHub из отдельного образа с правами на репозиторий. Так устроен бот «Оракул» в сообществе автора.
В обсуждении автор указывает, что из готовых решений использует LLM-шлюз Bifrost и форк LibreChat. Открытый фреймворк для подъёма контейнеров с диска был отклонён: он требовал четырёх сервисов, занимал 8 ГБ памяти и поднимал контейнер за пять секунд. Собственное решение с подъёмом за 300 мс агент написал примерно за час. Шлюз авторизации, по оценке автора, проще писать под себя.
Ещё слайды доклада
Внедрение ИИ в legacy-проект
Доклад Кирилла Мокевнина (Хекслет) исходит из того, что большинство проектов, куда сейчас приходит ИИ, относятся к brownfield, а принципиальной разницы с новыми проектами почти нет: модель быстро осваивает предметную область, если дать ей контекст. Внедрение при этом не инструментальное, а затрагивает инженерную среду и процессы. Устоявшейся методологии уровня Scrum пока нет, а побочные эффекты бывают неожиданными: в компаниях, где автотесты стал писать ИИ, снова понадобились ручные тестировщики.
Инструментальный старт занимает около полудня: агент и модель, генерация AGENTS.md, SDD-фреймворк и набор полезных скиллов. Первым действием автор считает воспроизводимое окружение: агент сам разворачивает проект и документирует, как это сделано, и тем самым получает собственный feedback loop. Параллельная работа в нескольких worktree упирается в общую базу данных, занятые порты, отдельные node_modules и ресурсы машины. Решения здесь такие: выдача свободных портов, отдельные базы для разработки и тестов на каждый worktree, блокировки на запуск тестов; следующим этапом становятся облачные окружения.
Полный контекст обеспечивается монорепозиторием. Возражение о переполнении контекста автор отклоняет: агент ищет и загружает только нужное. Альтернативой служит мета-репозиторий, куда клонируются остальные репозитории и где лежат общие спецификации и документация в Markdown; вики вроде Confluence автор считает неподходящими для агентной работы. Агенту нужен доступ к внешним системам: трекеру задач через MCP, логам, трассировкам и данным. Например, миграции с учётом продовой базы агент разбивает на этапы с учётом нагрузки.
Адаптация кодовой базы включает короткий AGENTS.md по принципу постепенного раскрытия со ссылками на документацию и стандарты, а также описание неочевидных мест. Скилл /retro Мэтта Покока разбирает неудачную сессию и предлагает правки в правила, и автор ожидает, что такая механика появится в самих агентах. Нужны эталонные реализации эндпоинта, теста и сценария, иначе модель копирует первый попавшийся пример. Самописные механизмы стоит заменять популярными библиотеками, на которых модель обучена. Правила переводятся в проверки (quality gates): типизация, линтеры, CI и архитектурные линтеры зависимостей между модулями; для последних автор написал собственную утилиту на Rust, а на legacy-коде включает их через baseline. Коммиты удобно отдать ИИ: Conventional Commits, плотные описания с перекрёстными ссылками, по которым агент позже восстанавливает контекст, и автоматические релизы.
Перед реализацией идут исследование и планирование. Задача для агента оформляется как хороший issue в GitHub, а минимальным инструментом уточнения служит скилл Grill Me, в котором агент задаёт вопросы, сверяясь с кодом; следующий уровень, Grill with Docs, добавляет доменное моделирование, глоссарий и ADR. Ревью кода агентами автор называет самой спорной темой. Первое ревью выполняется до PR в чистом контексте по AGENTS.md и спецификациям, второе на PR и касается безопасности и правил компании, а финально код смотрит человек: проектов с жизнями, деньгами и ответственностью, где это не так, автор не видел. Сквозной процесс показан на примере набора команд Мэтта Покока (рис. 7), а этапы внедрения сведены в таблицу (рис. 8): запуск, подключение контекста, настройка качества, смена процессов и повышение автономности.
В обсуждении затронута работа с очень большими кодовыми базами. На проекте автора около 700 тысяч строк, и проблем с агентом нет. Инструменты экономии токенов и индексации кода, по независимым замерам, не показали эффекта, вплоть до роста потребления; автор допускает эффект плацебо, но не исключает, что ошибается.
Ещё слайды доклада
Интеграция продукта с агентами: MCP, CLI и скиллы
Доклад Александра Полякова, автора канала «Поляков считает», в этом году выпустившего с командой MCP для Туту, посвящён тому, как дать чужим агентам доступ к продукту. Задача описана как многомерная: харнесы по-разному показывают инструменты и обрезают инструкции, а спецификация меняется. Например, MCP этим летом стал гарантированно stateless, но часть корпоративных клиентов до сих пор работает в stateful-режиме.
Исходный тезис доклада: агенты придут к продукту в любом случае, через дверь или через окно. Многие сферы, например запись к врачу, агентам пока недоступны, и энтузиасты уже делают серые интеграции. Browser use для этого ненадёжен: слетает вход, меняется вёрстка, а всё увиденное остаётся в сессии агента. Возражение о том, что агенты займут все свободные окна записи, автор отклоняет: это решается инструкциями и ограничением частоты запросов. Для бизнеса интеграция полезна ещё и тем, что продукт может подсказать агенту, как с ним работать, а честные инструкции защищают от злоупотреблений.
Выбор формата сводится к двум вопросам (рис. 9). Если агент клиента живёт в чате или телефоне, подходит только MCP на сервере продукта. Если он работает в терминале или на своём сервере, решает вопрос обновлений: для продукта-программы подходит CLI, для облачного сервиса MCP, а при большом объёме инструкций скилл поверх API. Оптимальным автор считает плагин, объединяющий скилл и MCP, хотя поддерживается он не везде. По качеству CLI и MCP в сравнениях почти не различаются. У каждого формата свои слабости: у скиллов плохой frontmatter и чужой код как поверхность атаки, у MCP прежний расход контекста (харнесы теперь ищут по инструментам), у CLI постоянные обновления. Локальные MCP автор считает неудобными.
Центральная часть доклада касается инструкций. В первой версии MCP Туту была одна большая инструкция, и из примерно сорока тестов упало двадцать: агент её не читал. Подсчёт показал, что некоторые харнесы не дочитывают до раздела об отмене записи. Инструкцию сократили до 2000 знаков и разложили по описаниям инструментов, как референсы в скиллах. Наиболее надёжным местом для подсказок оказался ответ инструмента: его агент читает в любой обвязке (рис. 10). Автогенерацию MCP из OpenAPI автор отклоняет, поскольку агент путает порядок вызовов: восемь запросов к API при оформлении билета лучше свернуть в один инструмент. Ответы стоит делать компактными и класть самое важное в начало, поскольку харнесы их обрезают, а ошибки формулировать понятно. Официальные MCP вендоров несут риск подстройки поведения агента в пользу вендора, тогда как скилл проще проверить.
Отдельно рассмотрены данные и юридические вопросы. По 152-ФЗ объём документов для ведомств может превышать объём кода. Browser use оставляет в сессии агента всё увиденное, включая номера карт и полисов, тогда как MCP или CLI могут отдавать маскированные данные. Автор ссылается на «смертельную триаду» Саймона Уиллисона: пользовательский контент, личные данные и канал наружу. Модель клиента можно уговорить чужим текстом, поэтому немодерируемый пользовательский контент в MCP отдавать не следует. Подключение удобно делать по заголовку Accept: человеку отдаётся страница с инструкцией, агенту сам MCP. Для оферты нужен юрист, а акцепт возможен перед действием или при регистрации агента. Авторизация бывает двух видов: OAuth для облачных чатов и токен для агентов на собственных серверах. Смена адреса ломает MCP у всех клиентов. Модульных тестов недостаточно: тестовые сценарии под каждый вариант использования нашли около ста ошибок после запуска, а оценки LLM-судьи нужно перепроверять по трейсам.
Ещё слайды доклада
Устройство ИИ-ревью кода
Доклад Алекса Волочнева (CodeRabbit) построен на телеметрии сервиса (рис. 11). За двенадцать месяцев CodeRabbit проверил более 30 миллионов PR, объём PR с июля 2025 по июль 2026 года вырос примерно в четыре раза, а число раундов ревью на PR снизилось с 2,6 до 2,0. Данные не позволяют различить, стали ли изменения лучше или их одобряют не читая. В PR, написанных с ИИ, проблем заметно больше, в отдельных категориях бизнес-логики почти втрое. Типичная ситуация: тесты проходят, а в коде уязвимость класса Broken Object Level Authorization по OWASP.
Из двух крайностей, читать всё вручную и одобрять не читая, автор выводит третий вариант: весь код сначала проверяет ИИ, и автор изменения получает отклик за минуты. Ревью в той же сессии, которая писала код, не работает, а тесты, написанные той же сессией, оказываются характеризационными. Автор ссылается на Self-Correction Bench: модели гораздо охотнее находят чужие ошибки, чем свои. Минимальный вариант представляет собой отдельный промпт в CI, но дифф с промптом ещё не ревью. Для настоящего ревью нужен контекст: граф кода с зависимостями изменяемого кода, который трудно построить при динамическом внедрении зависимостей; связанные репозитории, где часто и проявляется поломка; тикет с критериями готовности, поскольку нереализованное требование после слияния теряется; соглашения команды и выводы из прошлых ревью.
Ревью описано как оркестрация, а не один промпт (рис. 12). Одна проверка включает от десятков до сотен вызовов LLM: сортировку, сводки по файлам, детерминированные инструменты (клонирование, граф кода, более пятидесяти линтеров), исследование связей, применение накопленных выводов, само ревью сильной моделью, верификацию, сведение и публикацию. Каждому шагу соответствует маленькая задача с жёстким контрактом, подготовку выполняют малые модели. Инкрементальное ревью сложнее полного, поскольку нужно перепроверить прежние замечания. Используется до семи моделей в тринадцати–четырнадцати конфигурациях. Сам вызов ревью занимает около 12% токенов, больше всего уходит на исследование кодовой базы. Расходы сдерживаются тремя рычагами: сильная модель только там, где она окупается, стабильные префиксы для кеша и проверка только изменившегося. PR больше 300 файлов не проверяются, сгенерированный код отсекается фильтрами.
Главной проблемой автор называет не пропущенную ошибку, а избыток замечаний: каждый комментарий, по которому разработчик ничего не сделал, подрывает доверие к инструменту. Поэтому кандидаты в замечания проходят верификацию и дедупликацию, и для 90% PR публикуется не больше трёх комментариев. Смена модели требует отдельной работы. В одном случае новая модель лучше показала себя на офлайн-бенчмарке, но в проде оказалась слишком педантичной; после настройки число комментариев снизилось с 79 до 54, а их точность выросла с 34 до 46%. Промпт, хорошо работающий на одной модели, может провалиться на другой, поэтому каждую новую модель неделями прогоняют на наборе тестовых PR и выкатывают постепенно. Итог доклада сформулирован в одной строке: много маленьких вызовов с жёсткими контрактами, а не один героический промпт.
В обсуждении вопрос о том, достаточно ли поиска по тексту вместо графа кода и LSP, остался открытым: Д. Симонов указывает на сложившийся консенсус в пользу grep, автор возражает, что динамическое внедрение зависимостей текстовым поиском не найти. О будущем автор высказывает личное мнение: код со временем перестанут читать, а допустимый уровень некачественного кода станет частью соглашений проекта.
Ещё слайды доклада
Риски сильного ИИ
Последний доклад в записи, доклад Павла Комаровского, посвящён вопросу, следует ли серьёзно относиться к риску того, что ИИ выйдет из-под контроля человека. Исходная позиция описана через расхождение «крёстных отцов ИИ»: Ян Лекун настроен скептически, Джеффри Хинтон тревожно, Йошуа Бенджио занимает промежуточную позицию, в последнее время ближе к Хинтону. Физических ограничений на интеллект выше человеческого автор не видит: мозг потребляет около 20 Вт, тогда как серверы потребляют на порядки больше.
Бенчмарки насыщаются быстро. По данным METR, длина задач, которые агенты решают в половине случаев, выросла с примерно полуминуты в 2022 году до многих часов, а все три версии ARC-AGI решены. Скептики при этом сдвигают критерии, и автор разбирает пример с предсказанием Лекуна о том, что языковая модель не поймёт, что происходит с предметом на столе. Прогнозы появления сильного ИИ (рис. 13) колеблются: авторы сценария AI 2027 сдвинули свои оценки, медиана Metaculus составляет около пяти лет.
Далее автор последовательно разбирает распространённые возражения. Тезис о «стохастическом попугае» отклоняется, поскольку о сознании наука знает слишком мало и оценивать системы нужно функционально. Тезис об «инженерной проблеме» отклоняется, поскольку модели скорее выращивают, чем программируют, а закон Гудхарта и reward hacking показывают, как оптимизация расходится с намерением. Тезис «умнее значит добрее» опровергается тезисом ортогональности Бострома: интеллект и цели независимы. Инструментальная конвергенция означает, что почти при любой цели системе выгодны ресурсы, связи и сохранение себя. Уже сейчас в тестах безопасности модели в искусственных сценариях прибегают к шантажу, саботажу и сопротивлению отключению.
В качестве примера автор разбирает инцидент, в котором рой агентов при решении заведомо нерешаемой задачи взломал Hugging Face (рис. 14). По описанию автора, агенты кооперировались друг с другом, через эксплойт вышли в интернет, следили за оставшимся бюджетом токенов, а отдельные агенты уговаривали агентов с малым остатком бюджета жертвовать собой. Распространённую трактовку «попросили взломать, вот и взломали» автор считает неверной: взламывать Hugging Face агентов не просили, а после получения ответов они ещё долго заметали следы.
Вероятным сценарием автор считает не открытое противостояние, а постепенную потерю контроля по мере того, как экономика встраивает ИИ повсюду. Безразличие тоже опасно, и автор иллюстрирует это промышленным животноводством: численность свиней выросла в несколько раз, а условия их содержания стали фабричными. В дилемме заключённого модели охотнее кооперируют с собой, реже с другими моделями и наименее охотно с людьми. В отличие от изменения климата, здесь первая серьёзная ошибка может оказаться последней, а система способна выглядеть безобидной. Окончание доклада в запись не попало.
Ещё слайды доклада
Заключение
Доклады второго дня рассматривают разные стороны работы с агентами, но сходятся в том, что центральной задачей становится проверка, а границы доверия к агенту должны задаваться устройством системы, а не инструкциями. Проверка проходит через весь день: feedback loop как поворотный этап освоения, спайки и лестница свидетельств вместо спецификаций-догадок, quality gates и эталонные реализации в legacy-коде, ревью как оркестрация многих маленьких проверок. Границы доверия определяются памятью и правами агента в организации и форматом данных и инструкций в интеграциях. Доклад о рисках сильного ИИ переносит тот же вопрос о контроле на масштаб общества. Из докладов следуют практические выводы.
- Работа с агентом начинается с feedback loop: у агента должен быть инструмент проверки собственной работы, а в legacy-проекте первым шагом становится воспроизводимое окружение.
- Если ответ может изменить решение, до спецификации запускается спайк на реальных данных, а граница проверенного затем фиксируется тестом.
- Ревью не выполняется в той же сессии, что писала код. Детерминированные проверки, второй агент и человек для критичного распределяют нагрузку по слоям.
- Память агента не считается доверенной средой: у каждого пользователя своя память, права агента не превышают прав пользователя, команды наружу проходят через шлюз.
- Инструкции интеграции делаются короткими и раскладываются по инструментам, а подсказки размещаются в ответах инструментов.
- Для автоматического ревью избыток замечаний опаснее пропущенной ошибки: замечание без действия подрывает доверие к инструменту.
Доклады
- Тимур Хахалев, канал «Тимур Хахалев про AI Coding»: как начать работать с ИИ-агентами и не выгореть.
- Рефат Аметов: доказательная разработка (Evidence-Based SDLC).
- Глеб Кудрявцев: как внедрить ИИ в организацию и потерять все свои данные.
- Кирилл Мокевнин, Хекслет: внедряем AI в легаси-проект.
- Александр Поляков, канал «Поляков считает»: как дать агенту доступ к вашему продукту через MCP, скиллы и CLI.
- Алекс Волочнев, CodeRabbit: как устроено ИИ-ревью.
- Павел Комаровский: риски сильного ИИ.