GenAI Update S3E3: три года размышлений об AI — что я пересмотрел

Отредактированный и сокращённый текст выступления и обсуждения 9 октября 2026 года.

Сегодня я хочу вернуться к тому, что говорил об AI за последние три года. Поводом стал анонс Sign in with ChatGPT: я вспомнил свой старый пост и попросил Codex поднять другие мои рассуждения, выступления и прогнозы. Но мне интереснее посмотреть, как менялось мышление, какие решения из него следовали и чему научили результаты.

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

Начали мы с вопроса к участникам: какое ваше убеждение об AI за год, два или три серьёзно изменилось? Кто-то ожидал полной замены профессий, которой пока не увидел. Кто-то думал, что учиться станет легче, а сейчас чувствует, что информации слишком много. У меня обучение, наоборот, стало гораздо проще, но я понимаю ощущение: входящий поток растёт быстрее, чем мы успеваем его переработать. Другие участники говорили о задачах, которые прежде не могли решить, а теперь решают с моделями.

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

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

В конце 2023 года я писал о распределённом знании, опираясь на Хайека. Знание о рынке существует у множества людей: каждый знает свою ситуацию, ограничения и обстоятельства. Именно этот индивидуальный контекст влияет на решения. Его трудно собрать в одном месте и выразить полностью.

ChatGPT демократизирует доступ к явному, кодифицированному знанию — тому, что можно найти в книгах и других источниках. Но у человека остаётся личное контекстное знание, включая необычные случаи из своей практики. Я предполагал, что важной компетенцией станет умение применить общедоступное знание к конкретной ситуации. Часть такого опыта мы, возможно, научимся кодифицировать; часть пока остаётся с человеком.

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

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

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

Другой участник сказал, что за последний год он не нашёл в собственной практике ни одной узкой задачи, где ему требовалось бы дополнительно «заземлять» знания модели. Ещё прозвучала мысль, что оптимизация расходов вполне уместна для простых задач, а важнее всего правильно подобрать инструмент.

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

В одном из прежних постов я писал о возможности Sign in with OpenAI. Причины были две. Первая — перенос контекста: мы постоянно переносим информацию из одного ассистента или приложения в другое. Вторая — использование своей подписки в стороннем продукте, чтобы пользователь мог расходовать доступные ему ресурсы там, где они нужны.

На встрече я предложил оценить этот прогноз: полное попадание, частичное попадание или слишком расплывчатая формулировка. В чате преобладали частичное попадание и сомнения. Я тоже выбрал частичное попадание.

В анонсированном Sign in with ChatGPT появилась возможность использовать подписку в других продуктах с предусмотренными платформой ограничениями. Но ожидавшегося мной переноса истории разговоров и полноценного доступа к памяти там нет. Партнёрский продукт также может отдельно брать оплату. Поэтому я считаю, что направление угадал, но детали существенно отличаются.

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

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

Я сделал открытый инструмент Retain, который собирает мои разговоры с разными ассистентами. Это попытка владеть своей историей и упростить перенос контекста. Если весь мой рабочий контекст остаётся у одного поставщика, переключаться на другого становится труднее.

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

Сегодня часть контекста можно хранить локально в MD-файлах и перенести в другой инструмент. Я предполагаю, что персонализация может всё больше уходить на сервер — например, в формы индивидуальной настройки модели. Тогда переносить её будет сложнее. Увидим, подтвердится ли этот прогноз; к нему тоже стоит вернуться позже.

Весной 2025 года, на фоне сообщений о покупке Windsurf компанией OpenAI, я написал, почему считал такую покупку логичной и какие риски видел для независимых coding-ассистентов. Самая важная поправка сегодня: сделка с OpenAI не состоялась. Нельзя записывать её в успешные прогнозы.

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

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

Я много раз говорил о будущем App Store вокруг AI и несколько раз сдвигал ожидаемые сроки. С датами не попал. Первые версии не дали того, на что я рассчитывал. Теперь я вижу признаки более реальной продуктовой платформы: появляется входящий трафик, а разработчикам дают инструменты для проблем, с которыми они сталкиваются.

Особенно заметно это было с нашим плагином. Я писал, что сложно сделать нормальный онбординг и не хватает событий. Затем появились возможности описать onboarding skill и подписываться на события. Это напомнило ранние годы WWDC: ты знаешь проблемы платформы, а на конференции слышишь анонсы, которые прямо на них отвечают.

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

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

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

Раньше я рассказывал о задаче квалификации входящего трафика. Мы подписали контракт с ценой 50 центов за задачу, хотя тогда расходы на выполнение с помощью моделей составляли 59 центов. Нужного качества мы уже добились; я рассчитывал, что через год-полтора стоимость снизится.

На момент этой встречи клиент продолжает работать с нами, контракт продлён, цена остаётся прежней, а сопоставимый расход на модели составляет около 15 центов за выполненную задачу. Это снижение примерно на 75%. Для меня такой результат поддерживает исходную логику решения в этом конкретном случае. При этом раньше я говорил о падении стоимости примерно на 90% за 18 месяцев; сейчас вижу некоторое замедление её снижения.

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

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

Я предложил аудитории гипотетическую задачу с тремя вариантами. В первом услуга продаётся за 50 центов, попытка стоит 5 центов, но качество слабее. Во втором цена та же, попытка стоит 18 центов, зато качество и устойчивость процесса выше. В третьем цена — 35 центов, попытка — 8 центов; набор решаемых задач уже, но результат легче проверить.

Это учебные цифры, а не тарифы или результаты нашего продукта. Я специально не дал всей информации и спросил: что вы выберете и чего вам не хватает для уверенного решения?

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

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

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

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

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

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

Теперь мы готовим голосовой AI-прескрининг до встречи с человеком. Некоторые вопросы легче уточнить голосом, чем добавлять в форму новые поля. Мы хотим проверить, сможет ли это уменьшить нагрузку и сохранить полезный поток клиентов. Результата этого теста у нас пока нет: на встрече я говорил о следующем шаге.

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

Нужно считать время и деньги, которые уходят на проверку и исправление результата. Меня всё больше интересует стоимость accepted task — задачи, результат которой действительно признан подходящим.

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

Здесь сходятся выбор модели, устройство процесса и стоимость человеческого внимания. Можно получить большой объём дешёвых попыток, который всё равно приходится долго разбирать. Можно сузить задачу и получить результат с более доступной проверкой. Важна вся комбинация, а не одна цена в таблице поставщика.

В июне я говорил о TeamOS и агенте в роли Chief of Staff, который помогает передавать контекст. Личная производительность растёт, а командная может не расти: остаются ожидания и координация. Теперь я считаю, что одного инструмента передачи контекста мало. Нужно менять организацию труда.

Моя текущая позиция — строить работу вокруг людей, которые могут вести продуктовую область от идеи до production. Название роли менее важно: Product Owner или продакт-менеджер. Один из участников предложил формулировку «бизнес-оператор плюс технический оператор» — возможно, такое сочетание тоже подходит. Важна ответственность за весь результат и способность понимать, как соединяются части продукта.

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

По моему личному ощущению от недавней работы, координация между функциями может съедать огромную долю потенциального ускорения. На встрече я назвал около 80%. Это моя оценка, а не универсальный показатель и не результат контролируемого сравнения команд. Через полгода я могу пересмотреть позицию.

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

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

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

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

Этот опыт усилил мою веру в end-to-end ownership. Однако он остаётся наблюдением из моей работы. Из него нельзя автоматически вывести, что любая компания получит такое же снижение расходов или что один фактор объясняет весь эффект.

На работу Дугласа Энгельбарта об усилении человеческого интеллекта мне раньше обратил внимание один из участников сегодняшней встречи. Благодаря ему я погрузился в неё. В конце 2025 года я пытался разобраться, как применить её к своей работе, и просил AI помочь мне с этим. Мне дали рекомендации, но я их не впитал. Тогда я сел читать оригинальный текст.

Чтение было непростым, зато связи с собственной работой стали понятнее. Я выделил две причины. Первая — примеры: форма инструмента, пространство для работы, способ организации действий. Они помогали увидеть, почему нельзя просто заменить инструмент и оставить всё остальное прежним.

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

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

Я показал процесс подготовки недавнего поста про рой агентов. Сначала попросил Codex напомнить, какие источники мне стоит прочитать. Идеи и ссылки уже были сохранены заранее. Затем я прочитал материалы и попросил помочь развить мысль.

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

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

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

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

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

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

Ещё мне интересна будущая коммерция между агентами: смогут ли они заключать транзакции через программные правила, без лишнего перевода всего в человеческий текст? Это вопрос о возможном направлении развития. К нему, как и к остальным сегодняшним прогнозам, стоит вернуться с реальными наблюдениями.