Transcription
Доброе утро всем. >> Я Ромен. >> Привет всем, я Александр. >> Ого, этот зал невероятен. Здесь сегодня более 7 000 инженеров по ИИ. И, знаете, дело не только в том, кто говорит об этой технологии. Дело ещё и в том, кто действительно использует её и каждый день раздвигает границы. Так что мы не могли бы гордиться больше, находясь здесь с вами сегодня. И когда мы думали об этом мероприятии с Алексом, мы постоянно возвращались к Всемирной выставке. А Всемирная выставка сделала будущее видимым для всех, создавая его публично, понимаете? Идеи, которые раньше казались невозможными, вдруг оказывались здесь. Люди могли их увидеть. Могли войти в них. И даже начинали в них верить. И, честно говоря, это мероприятие обладает той же энергией. Будущее инженерии не приходит откуда-то извне. Оно действительно строится здесь, людьми в этом зале, и гораздо быстрее, чем большинство ожидало. И именно поэтому немного удивительно, что люди продолжают говорить, что инженеры исчезают. Аргумент в том, что программирование, знаете, абстрагируется, и поэтому со временем нам не понадобятся инженеры. Ну, на самом деле, мы считаем, что всё наоборот. Знаете, программное обеспечение поглотило мир. Затем ИИ поглотил программное обеспечение. Но теперь мы здесь, чтобы сказать: инженеры по ИИ поглощают мир. Инженеры по ИИ — это люди, которые здесь раздвигают границы. Да. И вы все выясняете, как эта новая возможность может достичь каждого. И никогда не было лучшего времени, чтобы быть инженером, потому что инженерия никогда не была о написании кода. Инженерия всегда была о решении проблем для себя и для других людей. О том, чтобы взять последние достижения науки и объединить их с дизайном, со вкусом, с суждением и, прежде всего, с воображением, чтобы создать что-то, что люди действительно могут использовать. И в этом смысле это не конец инженерии. Мы считаем, что это возвращение к корням инженерии.
>> И технология, на которой мы строим, ускоряется, становится всё быстрее и быстрее. Например, раньше мы выпускали новую модель примерно каждые 15 месяцев, а теперь — примерно каждые 6 недель. И если вы пропустили, на прошлой неделе мы запустили предварительную версию серии 5.6, и мы очень рады, что она попадёт в ваши руки. Теперь, строя на основе всех этих моделей, темп прогресса продуктов неумолим. И в результате мне не нужно вам говорить — инженерия ощущается совершенно иначе. Итак, просто чтобы вспомнить несколько лет, которые для меня были последовательными, прямо-таки умопомрачительными переживаниями. Знаете, очевидно, долгое время у нас было завершение, затем мы перешли к встроенному предсказанию, а затем, наконец, у нас появилась команда K, где можно попросить модель внести изменение, но они не проверяли работу. Затем модели начали проверять работу, и теперь у нас есть модели, которые берутся за долгие, сложные цели, пока не завершат их. И для меня каждый из этих этапов — я помню, первый раз был просто умопомрачительным, а затем, очевидно, потом ты просто привыкаешь и пытаешься сделать свою работу.
>> Да, на самом деле я не могу поверить, что цикл сборки и тестирования не был частью моделей всего 2 года назад. Это моё фото с Dev Day 2024, и я тогда использовал 01 в предварительной версии, чтобы создать мини-дрон с интерфейсом дрона с нуля. И самая безумная часть в том, что модель на самом деле не могла запустить код или проверить свою работу, и я знал, что демо сработает в большинстве случаев, но точно не всегда. Так что мне приходилось скрещивать пальцы. Вы, наверное, видите здесь, что я был довольно нервным, но, эй, это я. Я делаю только живые демо, так что никогда не знаю, что на самом деле произойдёт каждый раз. К счастью, это сработало, и к Dev Day в прошлом году, в 2025-м, я уже был достаточно уверен, что модели могут проверять свою работу, чтобы управлять целой системой камер и освещения вживую. Но да, мы прошли долгий путь.
>> Да, мы называем его богом демо, и, знаете, перед демо я спрашиваю его: «Ну, как часто демо работает?» Он отвечает: «Знаете, три раза из четырёх», и мы такие: «Ладно, удачи». Очевидно, мы прошли огромный путь с тех пор, и этот год был безумным. Итак, то, что мы здесь показываем, — это всё, что мы выпустили на данный момент. На самом деле даже не всё, а подборка того, что мы выпустили в этом году. Мои любимые вещи, которые мы выпустили, — это приложение Codex, целевой режим, удалённый доступ. Это вещи, которые действительно меняют то, как ощущается работа.
>> Знаете, очевидно, мы не могли бы делать эти вещи, если бы не использовали Codex для создания Codex, но, мне кажется, самое интересное в том, что теперь Codex может, и агенты могут выполнять любую задачу, которую вы можете выполнять на своём собственном компьютере. И это означает, что они не просто помогают вам с программированием, но и помогают с тем, что происходит до программирования, и помогают с тем, что происходит после программирования. И это действительно ключевой момент, верно? Я думаю, было много разговоров, и будет много разговоров сегодня о циклах: если вы можете подключить агента не только к работе, которую вам нужно сделать, но и к тому, зачем её нужно сделать, то вы можете заставить агента начинать гораздо больше работы. А затем, если вы можете подключить его к тому, что вы делаете после — рецензированию и развёртыванию, то вы помогаете ему доводить до конца гораздо больше работы. Итак, со всем этим мы, конечно, можем двигаться гораздо быстрее, но для меня как для человека, работающего с продуктом, самое захватывающее — это то, что мы принимаем лучшие решения о том, что строить. Например, мы пробуем, прототипируем гораздо больше идей и проводим гораздо больше времени с пользователями. Итак, да, это все вы. Поэтому я хотел сделать паузу и просто сказать вам всем большое спасибо и за любовь, и за конструктивную обратную связь. Я бы сказал, что можно с уверенностью сказать, что Codex и, по сути, вся индустрия не были бы здесь без вас.
>> Да, большое спасибо за всю обратную связь. Мы постоянно слушаем всех вас. Спасибо. >> [аплодисменты] >> Хорошо. Итак, модели становятся действительно хорошими. Я бы сказал, если взять среднюю по сложности компьютерную задачу и дать мне и модели одинаковое время на её выполнение, вероятно, по крайней мере в моём случае, модель справится лучше, чем я, для средней задачи. Итак, мы получаем эти модели — в некотором смысле они умнее нас. Они могут делать почти всё. Как нам это сформировать? Какими должны быть продукты, которые мы используем? И чтобы ответить на этот вопрос, мы обращаемся к нашей миссии. Часть её, которую я здесь вывел, — это, знаете, ИИ общего назначения, приносящий пользу всему человечеству. И я думаю, чтобы сделать это, есть два главных вопроса, о которых я сейчас думаю. Первый: как настроить агентов, чтобы они действительно что-то делали в мире? Итак, что они могут делать? Знаете, постепенно агенты подключаются ко всё большему количеству вещей. Затем — где они работают? Об этом позже. И второй вопрос: как нам использовать этих агентов? Для нас, знаете, каким должен быть продукт вокруг них? И для нас цель определённо не в том, чтобы автоматизировать инженеров. Вместо этого форма продукта, которую мы хотим, — это та, которая максимально расширяет возможности инженеров. Итак, если мы подумаем о том, какова эта форма продукта, мы на самом деле считаем, что это довольно просто. Я читаю много научной фантастики и, знаете, смотрю фильмы о супергероях. И я на самом деле думаю, что простые идеи там примерно верны. Итак, есть два режима, примерно. Чат. Я на самом деле думаю — некоторые считают, что чат мёртв. Я считаю, что чат недооценён. И какой-то практический опыт. Итак, вам нужна единая сущность, у которой можно попросить помощи с чем угодно, где угодно. А затем вам нужен мощный совместный интерфейс, который можно использовать, когда вы хотите проверить, направить или сформировать что-то самостоятельно. Итак, я попросил Codex сгенерировать мне изображение этого, чтобы помочь понять, когда вы можете захотеть использовать эти вещи. Итак, моя аналогия для вас — да, надеюсь, вам понравилась генерация изображений. Моя аналогия для вас: это как работа в команде. Большую часть времени вы просто обсуждаете дела, а ваша команда просто делает дела. Вы не хотите постоянно заглядывать через плечо или подходить к рабочему месту коллеги для каждой единицы работы. В основном вы просто хотите говорить и позволить им творить. А время от времени вы хотите углубиться и действительно докопаться до самых мелочей, решая эту проблему вместе. И для нас, когда мы строим продукт, у нас есть идея: мы хотим сделать так, чтобы вы сохраняли чувство мастерства над работой, которую мы делаем, потому что это действительно мощно. Мы не хотим, чтобы было действительно трудно добраться до деталей и, знаете, разобрать оборудование в данном случае. Итак, то, как мы воплощаем это в жизнь, — это только начало, но именно поэтому мы создали приложение Codex. У вас есть очень простой интерфейс чата, который вы можете использовать для программирования и для всего остального. И, знаете, вы можете вести беседу, а затем углубляться настолько, насколько хотите. В данном случае у нас есть прогноз Ромена по счёту предстоящего матча чемпионата мира. >> Надеюсь, я прав. Надеюсь, я прав. Посмотрим. >> [смех] >> Хорошо. И что вы можете здесь сделать — вы можете зайти и указать на что-то конкретное и сказать: «Эй, я хочу, чтобы ты внёс это изменение». Или вы можете сделать это изменение сами. И забавная история: на самом деле я помню, как я рассказывал эту идею некоторым из вас, кто, я знаю, находится в зале, до того, как мы начали, и мне прямо сказали: «Мы никогда не будем использовать такой инструмент. Я никогда не покину свой терминал». Или Vim, или Emacs. Но на самом деле эти люди теперь используют его. И даже внутри компании, в нашей команде, было много вопросов: «Зачем нам это строить? Люди любят CLI, любят IDE». И это немного тонко, но наша позиция такова: вы не можете построить такой совместный интерфейс для любой работы в CLI. В основном это чат. А в IDE порядок неправильный — вы начинаете с кода, но сейчас пришло время перейти к работе с коллегами, где вы сначала общаетесь в чате, а затем углубляетесь, когда это необходимо.
>> Полностью согласен. И мы движемся очень быстро в этом направлении — на уровне продукта и, конечно, на уровне моделей, но мы также стараемся не отставать от всех вас, верно? Честно говоря, половину времени, когда я открываю X, я вижу кого-то из этого зала, делающего что-то, о чём я не подозревал, что Codex может сделать. И, честно говоря, именно так поступают пионеры. Вы экспериментируете, настраиваете инструменты для себя, для своей команды, и в ответ мы вдохновляемся. Мы учимся у вас, и в конечном итоге выигрывают все. Итак, мы помогаем — на самом деле вы помогаете нам понять, что строить дальше и как должно выглядеть будущее инженерии. Но чтобы это работало, одна вещь, которая нам действительно важна, — это то, что Codex не может быть закрытым продуктом, который может улучшать только OpenAI. Поэтому мы намеренно спроектировали Codex как набор уровней, на которых кто угодно может строить. И мы хотим показать вам немного этого стека сегодня и то, как он проявляется. Во-первых, всё начинается с модели, и Александр показал, как быстро мы прогрессируем в моделях. И вы, ребята, используете эти модели через Responses API, и угадайте что? Именно так мы построили приложение Codex, верно? Мы используем те же модели и через тот же API. Мы на самом деле строим на том же, что даём разработчикам. И когда Codex нуждается в чём-то новом, мы всегда стараемся сначала встроить это в API, чтобы вы тоже могли извлечь пользу. Недавний пример — компактизация. Codex понадобился способ компактизировать длинные контексты для длительных задач, и мы встроили это в API. Это означает, что ваши агенты могут использовать те же примитивы, которые мы построили для себя. Переходя к следующему уровню, обвязка Codex также является открытым исходным кодом, так что вы можете изучить её, форкнуть, адаптировать. И мы применили тот же подход к Agent MD. Вместо того чтобы изобретать новый формат файла для Codex для следования инструкциям, мы решили выбрать имя, которое смогут использовать и другие агенты. Модели жёстко заданы по умолчанию в обвязке — модели от OpenAI, но они не жёстко закодированы. Так что если вы хотите использовать открытую модель и сохранить тот же цикл агента, вы можете. И мы также встраиваем эту обвязку Codex в процесс пост-тренировки наших моделей. Это означает, что модели могут учиться вызывать инструменты и ориентироваться в среде, которая на самом деле является открытым исходным кодом. Возьмём, к примеру, Open Code Team. Они смогли изучить, как у нас устроена эта эталонная реализация, и могли повторно использовать части, которые им подходят, или полностью изменить всё остальное и сделать другой выбор. Я знаю, например, они пытались понять, как мы делали вход в систему через ChatGPT, и поэтому могли посмотреть код и учиться на нём. И мы считаем, что это лучше, чем заставлять разработчиков заниматься обратной разработкой того, как и что мы строим и как запускаем. Но теперь, скажем, говоря о подписках, мы хотим подняться на уровень выше. Как встроить эту обвязку в приложение? И как позволить людям входить в систему с их существующей подпиской Codex, например? Ну, оказалось, у нас была та же проблема, потому что мы хотели создать расширение для VS Code и приложение Codex. И мы хотели иметь унифицированный способ управления этой обвязкой. Поэтому мы создали App Server и также сделали его открытым исходным кодом. И App Server — это не какой-то адаптер сообщества, это действительно путь, который мы используем для наших собственных продуктов. И вы можете использовать его тоже. Тома, например, он же Демилян в X, создал своё собственное нативное приложение для Codex под названием Codex Monitor ещё до того, как мы запустили приложение Codex. Потому что он мог создать его, используя App Server. И теперь он работает в нашей команде и на самом деле создал Codex для iOS. И, поднимаясь по стеку, на уровне приложений мы также хотим убедиться, что инновации не блокируются нашими собственными идеями. Поэтому мы создали здесь расширяемые примитивы, такие как встроенный браузер, который мы показали на экране, и плагины. Так, например, browser use и computer use были созданы как плагины с использованием тех же самых точек расширения, которые доступны и вам. И наконец, мы также недавно создали ролевые плагины для Codex, например, чтобы упростить настройку для людей, работающих в области науки о данных или дизайна. И эти плагины также имеют открытый исходный код. Вы можете заглянуть под капот и вдохновиться ими, если это полезно. Наша цель — действительно продолжать делать это максимально открытым и гибким. И лучшая часть в том, что люди могут использовать свою существующую подписку во всё большем количестве мест: от Open Code, Pi, Droids, Open Claw до Xcode и JetBrains в качестве IDE. И вы можете видеть, как они становятся довольно значимой частью того, как люди используют эти инструменты, и именно поэтому мы хотим заботиться о создании этой открытой экосистемы вместе с вами. Так что, если есть одна вещь, которую я хочу, чтобы вы вынесли из этой части и этого выступления, то это следующее: мы не создаём одну систему для OpenAI и вторую, упрощённую для разработчиков. На каждом уровне мы на самом деле используем то, что даём вам. И мы хотим поблагодарить всех вас, потому что каждый раз, когда вы форкаете обвязку, каждый раз, когда вы находите границы возможностей моделей, это означает, что мы можем учиться и улучшаться. И, честно говоря, с 7 000 лучших инженеров по ИИ в этом зале сегодня я уверен, что все вы во многом определите то, как мы будем взаимодействовать с ИИ и как мир будет взаимодействовать с ИИ в будущем. Так что спасибо. >> [аплодисменты] >> Я хочу выразить признательность тому, кто там впрыскивает энергию. Это вы, ладно, большое спасибо. Итак, с вашей помощью мы делаем агентов взрывоопасно полезными. И теперь вопрос: как получить от них ценность? И это не максимизация токенов. У нас есть термин для этого, который, возможно, вы тоже используете. Не знаю, он на экране? Максимизация ценности. Итак, когда мы общаемся с руководителями инженерных отделов, большая часть разговора вращается вокруг тем, связанных с идеей максимизации ценности. Итак, мы проведём вас через несколько распространённых тем, которые возникают, некоторые вещи, где мы уже достигли большого прогресса, и некоторые вещи, где ещё предстоит много прогресса. Первая из них — экономическая эффективность. Все хотят передовой интеллект. Выберите свой любимый бенчмарк — вы хотите лучшую модель. Так, например, с Terminal Bench здесь — это GPT 5.6 Sol, и, как я уже сказал, нам не терпится, чтобы он у вас был. Но, ладно, вы также хотите получить как можно больше интеллекта, и здесь вступает эффективность. Экономическая эффективность была для нас в центре внимания уже довольно долгое время, и результаты продолжают окупаться. Например, GPT 5.6 Terra, я думаю, он тёмно-синим на графике, приносит интеллект уровня GPT 5.5, но вдвое дешевле. А Luna там превосходит некоторые довольно известные модели в этом бенчмарке. Но при цене всего 1 доллар за миллион входных токенов и 6 долларов за миллион выходных токенов. Я предоставлю вам самим сравнить эти цены, но это безумная ценность.
>> Да, нам действительно не терпится увидеть, как вы все будете строить с GPT 5.6 и этим новым семейством моделей. Теперь следующее, что я хочу затронуть, — это скорость, верно? GPT 5.3 Spark показал вам, что может открыть скорость, но мы также знаем, что вы все хотите передовой интеллект. Вы не хотите иметь модель, которая не так хороша, как та, с которой вы можете работать на самом высоком уровне. Так вот, это GPT 5.6 Soul, работающий на Cerebras, — передовой интеллект со скоростью 750 токенов в секунду. Нам не терпится увидеть, что вы сможете построить с ним в следующем месяце. И, честно говоря, чтобы поместить это в контекст: это всё равно что написать довольно большой PR за 10 секунд. И дело не только в том, чтобы получить один ответ быстрее, верно? Дело в том, что вы можете сделать с такой скоростью. Вы можете представить агента, применяющего разные подходы, возможно, пять или шесть параллельно, возможно, возвращающегося и выбирающего лучший за то время, которое вы бы потратили на генерацию даже не одного. Так что нам действительно не терпится увидеть, что может открыть такая скорость, когда у вас есть передовой интеллект, самый лучший, на такой скорости. Это начинает ощущаться не как ожидание ответа от ИИ, а гораздо больше как коллега, который уже показывает вам результаты по ходу дела.
>> Говоря о работе с коллегами, могу ли я попросить поднять руки? Кто знаком с такой картиной в офисах? Хорошо. Ого, многие из вас очень дисциплинированны. Я вижу несколько человек впереди. Итак, да, многие люди держат свои ноутбуки открытыми, чтобы агенты могли продолжать работать. И это забавно, но, знаете, на самом деле мы хотим иметь возможность закрывать свои компьютеры и запускать множество задач параллельно, изолированно, на своих собственных машинах. Мы на самом деле стремились к этому с самого начала. Нашим первым крупным запуском был Codex Cloud, и вскоре его ждут крупные обновления. Но, что ещё лучше, когда мы думаем об этом, будущее не должно иметь этого неловкого разграничения между локальной задачей и облачной задачей, когда вам нужно решать, где всё запускать. На самом деле, что у вас должно быть — это возвращаясь к тому, что я говорил ранее: у вас должен быть агент, вы общаетесь с ним где угодно, когда угодно, о чём угодно, и он должен выяснять: «Окей, что мне нужно сделать, какая среда подходит для моей работы» — и использовать то, что доступно.
>> На самом деле Тео сделал прогноз в эти выходные на эту тему. И это довольно точный твит. Алекс, что ты думаешь? Раньше или позже, чем через 6 месяцев? >> Я думаю, не в точных деталях, но настроение этого твита — гораздо раньше, чем через 6 месяцев. >> Да, я имею в виду, при тех темпах, с которыми всё происходит, я не удивлюсь, если это действительно будет раньше. Итак, теперь вы, возможно, задаётесь вопросом: а где сегодня живое демо? Ну, для этого инженерного события по ИИ мы хотели сделать что-то немного другое на этот раз. И мы считаем, что это уникальный момент для всех нас, чтобы переосмыслить то, как мы работаем и как строим. И поэтому мы хотели пригласить специального гостя, который согнул границы возможного с агентами и действительно подтолкнул нас к тому, чтобы мы стали более «пилюльными» в отношении AGI в OpenAI. Итак, поприветствуйте на сцене крёстного отца когтей, Питера Штайнбергера. >> [аплодисменты] >> Питер, передаю слово. Спасибо всем. >> Спасибо, Эл. >> Доброе утро всем. Знаете, я люблю эту картинку, потому что она напоминает мне, как много изменилось за несколько месяцев. Я жонглировал 10 или более окнами терминала, всегда ожидая, пока одно из них закончит, чтобы забрать агента и поставить в очередь новую работу. В январе это казалось пиком продуктивности. Сегодня это кажется немного глупым. Я думал, что оркестрирую. На самом деле я опрашивал. Я был планировщиком, маршрутизатором и памятью. Знаете, сначала я работал в паре с одним агентом. С 10 терминалами я больше не работал в паре. Я управлял 10 прямыми подчинёнными. Теперь я в основном общаюсь с долгоживущим менеджером, который делегирует работу команде. Для сложной работы я всё ещё могу спуститься на уровень ниже и работать в паре напрямую с исполнителем, но мой режим по умолчанию изменился. Я управляю менеджером небольшой компании агентов. Три изменения сделали это возможным. Номер один: серверная компактизация сделала длительные задачи достаточно надёжными, чтобы я перестал оптимизировать первые сессии. Координация позволяет одному потоку создавать и направлять правильные проекты. И третье: автоматизация может пробудить того же менеджера, когда что-то происходит. Итак, у нас есть постоянный контекст, делегирование и триггеры. Вот ваш цикл. И как только цикл начинает работать, вы обнаруживаете следующую проблему — узкое место продолжает смещаться. Знаете, в прошлом году я был в основном ограничен токенами. Теперь я это исправил, присоединившись к OpenAI. Я знаю, я знаю, эта стратегия не масштабируется. Затем моё ограничение сместилось на токены — на вычисления. Все эти потоки работают одновременно, и мой MacBook начинает звучать как реактивный двигатель. Это в основном решается использованием тестовых машин. Так что агенты могут запускать тесты на отдельной машине. Теперь я в основном ограничен вниманием. И в отличие от токенов или вычислений, я не могу просто добавить его больше. Так что самый важный навык сегодня — это решать, куда его направить. Вы всё ещё смотрите на агента, пока код пролетает мимо? Я знаю, я знаю, это выглядит круто, но с более ранними моделями это было необходимо. Знаете, вы видите, как агент идёт в нежелательном направлении, вы нажимаете Escape, направляете его, возвращаете обратно. Но последнее поколение моделей настолько хорошо понимает намерения, что смотреть, как агент генерирует код, — это немного пустая трата времени. Представьте, кто-то создаёт задачу в одном из моих проектов с открытым исходным кодом. Менеджер просыпается, читает её в сопоставлении с целями проекта, заметками и видением и решает, подходит ли она. Если да, он создаёт исполнителя. Этот исполнитель исследует, реализует изменение, запускает тесты, и другой агент может проверить результат. Мне не нужно смотреть, как эти агенты работают, или потреблять каждое промежуточное сообщение. Когда менеджеру нужен я, он возвращает PR, исходную задачу, предлагаемый дифф, возможно, видео или даже работающую сборку, в которую я могу войти через VNC. Я проверяю один раз, оставляю заметку, возможно, одобряю, цикл продолжается, и он может быть принят после прохождения проверок. Агент выполняет внутренний цикл выполнения. Я задаю направление и принимаю решения во внешнем цикле. Знаете, Пол думает, что он уже использует такую версию. Он закрепил своего руководителя штаба. Он просыпается каждые 10 минут и координирует его работу в GitHub. Агент создаёт потоки на боковой панели, чтобы Пол мог вмешиваться, когда работа требует дополнительного направления. Знаете, когда менеджер долгоживущий, привязывать его к ноутбуку кажется неправильным. Codex уже может перемещать работу между хостами. У Open Claw есть шлюз и узлы. Но ни то, ни другое не кажется окончательной формой. Я даже не хочу думать о том, где я работаю. Мой агент должен иметь возможность подключаться к любой из моих машин. Он должен знать, какую работу можно выполнить в облаке, а какая требует моей локальной машины. Менеджер не должен быть сессией, запертой внутри вашего приложения. Это должен быть агент, которому я могу написать, которым могу управлять из Slack или слышать, где бы я ни находился. В самом деле, почему я не могу поговорить со своим агентом и попросить его спроектировать весь цикл за меня? Мы ещё не решили эту задачу. Модели продвигаются быстрее, чем обвязки и организации вокруг них. Проектирование этих вещей — следующая инженерная проблема. Вот где появляетесь вы все. Будущее — это не 20 терминалов. Это лучшие циклы. Давайте их строить. Спасибо. >> Спасибо.