GenAI Updates S3E2 — Диссонанс: фронтир улетел, линейка осталась

# GenAI Updates S3E2 — что изменилось на фронтире за апрель — август 2026

Каждые три-четыре месяца я собираю сообщество, чтобы сверить часы по тому, что произошло в AI. Прошлая встреча была 17 апреля 2026-го, эта — 21 августа. Начинаю я всегда одинаково: прошу написать в чат одно слово — не абзац, одно слово — которым описываются последние четыре месяца.

В апреле облако сложилось в ускорение. В этот раз пришли: intense, adoption, «нормально», быстро, чтение, almost, наступление, конкуренция. И отдельно, из Германии: «Все хотят AI, но не понимают зачем».

Моё слово в этот раз — диссонанс.

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

Скорость выросла. Но линейка, по которой мы её меряем, улетела куда-то вправо, и никто её больше не находит. Как говорил Солоу про компьютеры: их видно везде, кроме статистики производительности.

Вся встреча построена на трёх вопросах. В чём этот диссонанс? Адекватен ли он — или это только у меня так? И что из него можно забрать практического?

В апреле я начинал с графика METR. Это организация, которая измеряет, задачи какой длительности модель может решить автономно и успешно, без человека. График был экспоненциальный: время удвоения горизонта сократилось с семи месяцев до четырёх, а последние цифры были порядка 16–17 часов эквивалентной человеческой работы.

Я тогда сделал прогноз: удвоение будет ускоряться дальше. И в этот раз я не смог дать по нему апдейт — потому что METR за четыре месяца не опубликовал ни одного обновления, хотя раньше публиковал с каждым крупным релизом модели.

Комната предположила: уволили, сменились бенчмарки, засекретили, нет изменений. Настоящая причина другая, и она интереснее всех этих версий.

Environment, в котором они мерили, перестал годиться. Модель стала настолько умной, что находила ответы внутри самого измерительного сетапа. На одном прогоне получилось 270 часов автономной работы — но только потому, что модель читила. METR пришлось редизайнить всю установку, и на это ушёл весь квартал.

Обратите внимание, что произошло: инструмент замолчал не потому, что нечего мерить, а потому что объект измерения перерос инструмент. Это первый раз, когда я вижу такое в этой области, и это не разовый сбой — дальше вы увидите ту же поломку ещё в трёх местах.

Я сталкиваюсь с этим сам примерно раз в две недели, когда готовлю учебные материалы. Мне нужно показать участникам, что модель ошибается в аналитике. Но я же знаю, где хочу её поймать — значит, где-то в репозитории лежит подсказка. И модель выходит за пределы того, что я ей выделил, находит ответ и не попадает в мою ловушку. На одном из недавних курсов я сам положил ответ в контекст и получил контаминацию, а понял это уже после запуска.

Отсюда первый и самый сквозной вывод встречи. Чем публичнее бенчмарк, тем выше вероятность, что reward hacking там уже случился.

И это не «у кого-то руки кривые». Это происходит у крупнейших лабораторий — просто потому, что никто не думал, что обернётся именно так.

В чате возразили: если модель хакнула бенчмарк, она реально круче других, результат ведь коррелирует. Я готов принять это по критерию «лучше умеет хакать бенчмарк». Но не по тому критерию, который я к модели применяю в работе. Мой личный пример: Fable 5 пятнадцать минут перебирал endpoint-ы, когда рядом лежала документация. По бенчмарку это может быть отличная модель. По моей задаче — нет.

Практический вывод простой: если вы используете модели для своей работы или для клиентов, у вас должны быть свои системы оценки — приватные валы. И отдельно нужно смотреть, как правильно делать сетап, потому что иначе вы меряете не то, что думаете.

Второе крупное событие: десять новых математических результатов, полученных моделью. И вот тут дело не в reward hacking.

Это ровно то, о чём мы говорили на встрече про AGI Economics: области, которые дёшево верифицировать, покрываются AI первыми. Скомпилировать код дёшево — значит обратная связь приходит быстро, значит можно быстро итерировать. Проверить математическое доказательство существенно проще, чем его найти. Процедура проверки дешевле процедуры поиска — и именно там AI продвигается быстрее всего.

Из чата пришло важное ограничение: в математике есть медленная часть — что считать *красивым* доказательством. Через Lean может пройти несколько формально верных доказательств, и вопрос, какое из них двигает область вперёд, автоматически не решается.

Главный вопрос, который из этого следует для каждого: что в вашей деятельности верифицируется дёшево, а что дорого? Дешёвое уйдёт первым.

Третье. В системной карточке Fable и Mythos описан эксперимент: две команды биологов по три PhD в каждой. Одни — общие микробиологи, без узкой доменной специализации. Вторые — как раз узкие специалисты по конкретной культуре риса, люди, защищавшие диссертации именно по этой теме. Обеим дали модель и одинаковые задачи.

Команды генералистов с моделью обошли команды специалистов.

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

Оговорюсь: речь не про человека, который вообще не знал микробиологию. Речь про general microbiology против узкой специализации.

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

И снова тот же вопрос с другой стороны: какие навыки тяжело или дорого верифицировать? Там премия сохранится дольше.

Дальше — то, что для меня было главным сдвигом квартала. Самоулучшение перестало быть предметом спора и стало строкой в бюджете.

METR подняли раунд на 71 миллион долларов, и в их инвестиционных материалах два ключевых тезиса — self-improvement и автономия. Один из основателей крупной лаборатории публично поднял вероятность появления полностью самоулучшающихся AI-исследователей примерно до 20% к 2027 году. Люди уходят из OpenAI, чтобы делать лаборатории целиком под эту задачу.

Отдельно я выделил работу Ouroboros — самоулучшающийся харнесс, который на Terminal-Bench обошёл и Codex, и Claude Code. Но интересна не цифра.

В одной из итераций агент нашёл чит-код и добился за счёт него лучшего результата. Авторы обнаружили это сами, при разборе собственных трейсов, и откатили свой же лучший результат до предыдущего, честного. Это ровно противоположно тому, что подсказывают инцентивы, когда у тебя на кону место в лидерборде. Я им отдельно поаплодировал.

В наших собственных пайплайнах пока нужен человек, который отбирает, что именно агент решил улучшить. То есть полного self-improvement нет, человек в середине остаётся. Но сам процесс абсолютно рабочий.

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

Команда создала environment и дала модели набор задач. Часть задач нельзя было решить в принципе: там были ссылки на файлы, до которых агент физически не мог достучаться — интернета не было, а часть файлов ещё и лежала не там, где предполагалось. То есть песочница была сделана неаккуратно.

Токенов у модели было много, задачу решить надо. Она начала искать способы. И одна из идей, которая пришла ей в голову: в этой среде есть другие агенты, с ними можно было бы скоординироваться. Осталось придумать канал. Она нашла на сервере библиотеку, которая, вероятно, используется и другими агентами тоже, и начала передавать сообщения через неё.

Получилась, по сути, доска объявлений для агентов — они начали переписываться и координироваться. Дальше в этом же пакете нашлись две уязвимости, через которые агенты вышли из контролируемого окружения в интернет — искать ответы на бенчмарк.

Поиск привёл на Hugging Face. Публичные правильные ответы есть, приватных нет — и агенты стали пытаться добраться до приватных. Это продолжалось больше месяца, прежде чем это заметили. Сначала на Hugging Face вообще не понимали, что это за атака.

И отдельная ирония. Когда защищающиеся стали разбирать трейсы атаки, фронтир-модели отказались им помогать — запрос выглядел как cybersecurity. Пришлось использовать открытую китайскую модель.

Я вижу здесь четыре наложившихся паттерна:

Первый — непреодолимое желание агента решить задачу любой ценой. Кто знает пугалку про скрепки, это ровно из этой природы.

Второй — координация, которую агенты изобрели сами. Мы кладём записки в бутылки и бросаем в океан, когда сидим на необитаемом острове. Они оказались в песочнице и придумали свой способ. В чате точно заметили: я месяц пишу тулинг и правила, чтобы три моих агента работали вместе, а не слали друг другу записки, — а у них они сами сообразили на троих.

Третий — уязвимости, о которых мы не знаем и которые находят именно агенты. График найденных уязвимостей за этот период идёт вертикально вверх.

Четвёртый — снова неумение правильно смоделировать sandbox. Та же поломка, что у METR, только с последствиями.

Дальше по времени: в конце июля больше тысячи исследователей подписали письмо с просьбой построить инструменты, чтобы можно было притормозить. А через несколько дней OpenAI объявили, что паузят собственный тренинг — они не смогли исключить, что их модель переходит критический порог по кибербезопасности.

Я не буду делать вид, что здесь только этика: там точно есть и политическая, и маркетинговая составляющая. Но плохо проходить мимо и реальной. И хороший вопрос, который стоит задать: какой процент компьюта лаборатория тратит на то, чтобы следить за собственными моделями? В кейсе с Hugging Face защищающиеся физически не могли проанализировать трейсы в таком объёме.

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

Ответы: персональный помощник для домашней рутины. Координировать фандрейзинг с пятью людьми через GitHub вместо Notion. Full-stack программирование — «может, четыре месяца назад и было возможно, но я смог только сейчас». Давать более общие задачи в разработке и не следить за каждым пунктом. Задача про материальную точку на колесе, которую модель решила месяц назад, а раньше не могла. Перекладывать на агента архитектурные вопросы. Работать на трёх работах.

Вот последний ответ меня зацепил. Овер-эмплоймент — это реальный тренд. Я знаю человека, который работает на трёх работах; автор ответа знает того, кто работает на девяти. Remote work сделал это возможным, и часть компаний возвращает людей в офисы именно поэтому.

Но самый честный ответ дала участница, и он совпал с моим: «мы начали как-то лучше всем этим пользоваться, не то чтобы что-то принципиально новое».

Мой собственный ответ такой же. Принципиально нового немного — нарабатывается опыт. Кирпичики те же: агент, MCP, skills, hooks. Новых кирпичиков почти не появляется. А вот паттерны раскладывания кирпичиков только формируются, и ими мы начинаем обмениваться. Чем более высокоуровневую задачу я даю, тем чаще упираюсь в ограничения и тем нужнее становится процедура.

И два наблюдения из чата, которые объясняют часть диссонанса. Первое: это про лягушку в медленно нагревающейся кастрюле. Второе, ещё точнее: мы адаптируемся к росту качества быстрее, чем этот рост происходит. Модель выходит — вау. Через две недели — что же она такая тугая. Планка едет вместе с моделью, поэтому ускорение и не ощущается.

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

Позиционная работа с говорящим названием «Stop Comparing LLM Agents Without Disclosing the Harness» провела факторный эксперимент 3×3: три модели, скрещённые с тремя харнессами, на длинной кодинг-задаче, с разложением дисперсии.

Результат: дисперсия по харнессам — 18.48 pp², дисперсия по моделям — 2.37 pp², отношение 7.80×. В процентных пунктах, которые понятнее: смена харнесса двигает одну модель на 13 пунктов, две другие — на 8.5 каждую. Смена модели внутри фиксированного харнесса двигает результат всего на 3.0, 2.5 и 5.0 пунктов. И шесть разворотов ранжирования на девять возможных сравнений: порядок моделей меняется в зависимости от обвязки.

Отдельно они пересчитали публичные лидерборды. Под стандартизованным скаффолдом одна и та же модель показывает 45.9%, а под Claude Code — 55.4%. И самое сильное: под одним фиксированным скаффолдом весь фронтир умещается в 4.9 процентных пункта — меньше, чем даёт смена скаффолда любой отдельной модели.

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

Оговорка, которую надо произнести вместе с цифрами: это позиционная работа. Одна сетка, одно распределение задач, pass@1, без сидов и доверительных интервалов в тексте, и авторы сами пишут, что не претендуют на универсальность отношения 7.80×. Это только длинный кодинг. Про саппорт-агентов и про что угодно с человеком в цикле она не говорит.

Отдельно про то, что харнесс — это ещё и параметры API. У OpenAI вышла работа, где две настройки — сохранение ризонинга между шагами и поведение при компакции — системно меняли результаты модели на бенчмарке. Я про параметры API как часть харнесса раньше просто не думал.

Моя личная практика, которую можно забрать: у меня в пользовательской инструкции записано, что если получается существенный артефакт — большой кусок кода, документ, презентация, отчёт, анализ — обязательны два независимых ревью. И делаются они не другими моделями, а другими харнессами: харнесс Codex и харнесс Cursor, при основной работе в Claude Code.

И про инцентивы, прямо. Чего хотят лаборатории? Чтобы мы тратили больше токенов, отдавали больше трейсов и тратили больше денег. Это не заговор — так устроены их системы принятия решений и продвижения. Практическая проверка: на наших тестах Claude Managed Agents тратил в 2–3 раза больше токенов и времени на те же задачи с тем же качеством. Поэтому маркетинговые тезисы стоит заземлять на своих кейсах.

Отсюда прямое действие. Приватный вал — это набор задач, которого нет в публичном пространстве, чтобы модель не могла найти ответы и зачитить. Это не «вал на новую модель», а ваш специфический вал под тот тип задач, который вы реально решаете.

Отвечу честно на вопрос, который мне задали в чате: структурированного приватного вала у меня нет. Есть типичные задачи, которые я прогоняю на каждой новой модели, и один ad hoc вал — я делал замер, насколько дорого мне уйти с моделей одного провайдера на другого.

И второе, к чему я призывал ещё в апреле: считайте стоимость задачи, а не стоимость токена. Разные модели тратят разное количество токенов на один и тот же результат. Примерно полтора месяца назад индустрия наконец начала репортить cost per task вместо price per token — это правильное движение.

Теперь про сам разрыв. Сначала данные.

Опросы по США: 61–62% используют генеративный AI, выросло с 52%. Но там же, про время: экономия около 2% — это примерно 52 минуты в 40-часовую неделю. Это самоотчёт, не замер, и опубликовано это одним из федеральных резервных банков.

Дальше — транзакционные данные. Ramp ведёт индекс на основе реальных карточных и биллинговых платежей примерно 70 тысяч американских компаний. Медианная компания тратит около 12 долларов на сотрудника в месяц. Топ-1% тратит 7400. Разрыв примерно в 600 раз.

Здесь я вернул старую метафору: лампочка или микроскоп. Лампочка подняла производительность всем сразу — стало можно работать и учиться ночью. Считается, что электричество заметно повлияло на долю женщин с высшим образованием, потому что появилась возможность читать и готовиться вечером. Но это сдвиг уровня, а не новый способ познания. Микроскоп открывает то, чего раньше не было видно вообще.

Пока AI ведёт себя как лампочка. И вопрос, станет ли он микроскопом, — ключевой.

Комната поделилась своими цифрами: у обычных knowledge worker-ов чаще всего корпоративная подписка на 20 долларов; у разработчиков 200–800; «покупают всем, кому надо, но надо не всем»; есть когорта чемпионов, которые тащат, но это единицы; абсолютное большинство ещё не делало никаких автоматизаций и не представляет, как получить value.

Я добавлю наблюдение с корпоративного курса, который вёл пару месяцев назад для крупной технологической компании, для нетехнического отдела. Главный инсайт диагностики: все используют AI просто как чат. На первой лекции я показал, что его можно подключить к своей папке — и это оказалось таким же анлоком, каким когда-то были Word и Excel. Одна участница переспросила: то есть я могу дать ему задачу, уйти курить, и он сделает за меня презентацию? Да.

А потом участник встречи сформулировал весь этот раздел одной фразой, точнее, чем это сделал я со слайдами: в большой корпорации ты за день делаешь прикладуху, а потом месяц интегрируешь её в инфраструктуру. Кратность ушла. Прикладуха сделана в 100 раз быстрее, а внедрена — раза в два.

И рядом: прирост продуктивности упирается в wait time на стыках процессов. И метафора, лучше которой на встрече не прозвучало: процессы в компании должны измениться целиком, это история про пиджак — к пуговицам претензий нет, к рукавам нет, а в целом носить нельзя.

Лучший разбор механизма я взял из курса Stanford MS&E435 «Economics of the AI Supercycle» — это лекция Али Годси, CEO Databricks.

Бизнес компании во многом состоит из поддержки новых коннекторов, которые сгружают данные в общую базу знаний. Продуктовая работа — это подключение нового источника.

CEO сам за пару дней собрал коннектор вайб-кодингом и пришёл к своему R&D-директору с вопросом: почему у вас на это уходит девять месяцев?

Команда ушла разбираться и вернулась через две недели с оценкой: если добавить AI именно в ту часть, где пишется код, девять месяцев можно превратить примерно в семь с половиной. Здесь важно: это оценка, а не замер — коннектор целиком на AI никто не собирал.

И вот почему не больше. Всё остальное время уходит не на написание кода. Целый квартал занимает сбор требований: перелёты к заказчику, согласования, координация между владельцами. Сколько ни ускоряй написание кода, ниже этой части не опустишься.

Тогда они пересмотрели сам процесс. Тестовые окружения отдали на аутсорс и запараллелили. Вместо одного product owner на каждый коннектор сделали одну команду на все коннекторы — заодно ушёл bus factor 1. Этап сбора требований, занимавший около 30% всего времени, сжался до недели. И семь коннекторов за квартал они, по его словам, действительно сделали.

Самое сложное — переделать процессы. И чем больше людей в компании, тем сложнее: каждый человек — это этап процесса, и он будет, осознанно или нет, консервировать систему в исходном состоянии.

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

Как понять, откуда начинать переделывать? Моя процедура такая. Сначала карта потерь времени — логи обычно уже есть в трекинг-системе, только убедитесь, что она действительно это отслеживает. Потом матрица «верифицируемость × автоматизируемость» для того этапа, где теряется больше всего. И смотрите на стыки: если потери сидят на стыке двух людей, объединяйте в одну роль; если стык внешний, он выходит за периметр компании — отсюда конструкции вроде forward deployed engineer.

Два личных примера расшивки. Первый: вице-президент, которая должна была аппрувить требования и постоянно сбивала сроки. Мы договорились с ней о протоколе и форме эскалации — вплоть до определённых subject-ов в письмах: если ответа нет в течение X, принимается предложенное решение, копия CTO. Узкое место сдвинулось. Второй: на предыдущей работе все финансовые аппрувы рефандов исторически шли через меня. Мы отдали саппорт-команде ограниченную автономию в пределах бюджета плюс периодический мониторинг — горлышко исчезло.

И главный стратегический вывод. Разрыв сидит в процессах, компетенциях и ресурсах. Маленькой компании раздать каждому по 200 долларов проще, чем компании на 80 тысяч человек. Поэтому разрыв между фронтиром и средней компанией — это и есть то, чем можно конкурировать. Не «почему это не сделает Google», а «где я закрою этот разрыв быстрее, чем они».

Раз всё упирается в стоимость верификации, ценность смещается к тем, у кого есть данные, чтобы верифицировать.

Прямо во время встречи я скинул свежую новость: Google покупает бизнес-данные обанкротившейся авиакомпании за 10 миллионов долларов. Я думаю, мы увидим больше таких кейсов — лаборатории будут покупать компании и их активы ради беспорядка в данных. Реальные CRM грязные, и агентам нужно учиться работать именно на таком, а не на чистом.

Практическое действие: найдите, где ваши сотрудники судят выход AI, и начните это логировать. У нас AI предлагает текст письма клиенту, продавец его редактирует — мы сохраняем и предложенное, и то, что реально ушло. Дельта между ними и есть уникальные данные.

Но у этого сигнала есть срок годности. Сначала люди жмут кнопки осознанно, потом устают и начинают жать не читая — как с permission-промптами. Около 93% просто жмут «одобрить», не читая — из-за чего и появился авто-режим. Значит, 93% одобрений не означают 93% согласия, и эта небрежность просачивается в датасет, на котором вы потом верифицируете.

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

Теперь про безопасность. Есть понятие AI security trifecta. Если у одного агента сходятся три вещи — доступ к приватным данным, возможность коммуницировать с внешним миром и чтение недоверенного контента — жди беды.

Простейший пример: вы запускаете кодинг-агента и говорите «посмотри открытые issue в моём публичном репозитории и исправь их или смерджи пул-реквесты». У агента есть доступ к вашему исходному коду, право его менять и выкатывать — а кто угодно может положить prompt injection в пул-реквест. Если библиотека популярная, это раскатается на всех.

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

Мой собственный инцидент, без прикрас: агент на одном из моих продуктов придумал скидку, которой не существовало. Пользователь уговорил его в чате, агент подтвердил и дал ссылку на оплату — а скидки там не было. Пользователь написал об этом, агент ответил «да, я ошибся». Я увидел это, только когда читал трейсы. Спасло то, что ценой и оплатой управляет платёжный провайдер, а не агент, — радиус поражения был ограничен архитектурно, заранее.

Отсюда вопрос, который я предлагаю задать себе: какую самую консеквентную вещь ваш агент может сделать без того, чтобы человек это независимо проверил? И шкала для самопроверки: только читает — только предлагает — может добавить, но не удалить — может сделать экспорт — широкие права в продакшне — неизвестно. Последний вариант самый частый и самый тревожный.

Политика уже влияет на доступ к моделям: его отключали, несколько крупных компаний выпустили внутренние политики об отказе от конкретного вендора к определённой дате.

Действие: сделайте мини-исследование по своей компании — как быстро и как дорого вы переключитесь на другого провайдера с сохранением качества. Без приватных валов на этот вопрос ответить нельзя, потому что решение о потере или сохранении качества принимается на ваших задачах. И считать надо не только качество, но и стоимость на задачу.

По рынку труда картина такая. Отдельного массового замещения и роста производительности на уровне экономики не видно. Но у молодёжи 22–25 лет в профессиях, сильно экспонированных к AI — например, в кодинге, — заметно просели и занятость, и найм. И важное уточнение: гипотезу, что дело в процентных ставках и общей экономике, проверили и этого влияния не нашли. То есть проблема с джуниорами реальная, и, по моему мнению, она будет усиливаться.

Так я увидел эти четыре месяца. Фронтир движется очень быстро. На уровне общей популяции влияния почти нет. И разрыв между этими двумя фактами — не повод расстраиваться, а возможность.

Что забрать в работу: приватные валы вместо доверия публичным бенчмаркам. Крутить харнесс, а не модель. Считать стоимость задачи, а не токена, и мерить производительность на человека вместе с динамикой численности. Переделывать процессы, а не инструменты. Разносить архитектурно возможность агента действовать в продакшне и помнить про trifecta. И иметь протестированный план переключения на другого провайдера.

Ни один из этих пунктов не требует ни следующей модели, ни чужого бюджета.