Программирование с помощью агентов: круглый стол с лидерами отрасли

Всем привет!

На этой неделе, или за последние два дня, вы слышали много сотрудников Google, работающих над Android.

Поэтому мы решили, что было бы здорово завершить конференцию, услышав мнения людей со стороны, из сообщества, из сообщества разработчиков Android.

Мы поговорим об агентном программировании и его влиянии на реальный мир.

Давайте начнем со знакомства.

Меня зовут Бен, я работаю в Android DevRel.

Вы уже слышали меня на этой конференции, но давайте пройдемся по панели.

Привет, ребята.

Меня зовут Винай, и я занимаюсь поддержкой ИИ-инструментов в Databricks.

Рад быть здесь.

Здравствуйте, меня зовут Луис Артола.

Я работаю в Google Картах.

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

Привет, меня зовут Аннис Дэвис.

Я работаю в компании Ford.

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

Привет, ребята.

Меня зовут Тай Смит.

Я работаю в Uber и помогаю нашим разработчикам.

Это уже давно мобильное устройство.

В последние пару лет мы уделяли много внимания ИИ-инструментам.

Привет, ребята.

Меня зовут Каушик Гопал.

Я работаю главным инженером в Instacart и веду подкаст Fragmented о разработке для Android.

Как сказал Тай, сейчас мы немного изменили стратегию и говорим о развитии ИИ.

Теперь

Итак, у нас есть 30 минут.

Думаю, время пролетит незаметно, поэтому мы сразу перейдем к самым важным вопросам.

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

Теперь появился ИИ, и вы слышали, как мы говорили: "Да, это так.

Мы считаем, что создавать приложения стало быстрее и проще".

Но я хочу спросить: действительно ли мы выпускаем приложения быстрее или просто генерируем кучу кода, который никуда не идет?

Пойдем, Винай.

Окей.

Да, мы все смотрим друг на друга.

у Two Dots.

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

И это ускорение очень реально.

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

Но я определенно вижу это в действии.

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

И в результате, я думаю, наша стратегия изменилась в отношении того, как измерять производительность, верно?

Потому что есть разные способы думать об этом.

Мы пытаемся понять, как поднять медиану, верно?

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

Мы видим сочетание ролей.

Некоторые люди двигаются намного быстрее.

Есть люди, которые делают по сто пул-реквестов в день и выполняют невероятную работу.

Но это тип пространства, в котором они работают.

Возможно, это более новая область или они лучше разбираются в инструментах.

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

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

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

Первые сигналы говорят о том, что да, но это выглядит совсем не так, как просто личные рекорды.

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

Но я думаю, что даже сейчас многие думают: "Как нам взять ИИ и своего рода этот инструмент, который у нас есть, и ускорить существующие процессы?"

Все верно?

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

Но сейчас мы видим, что это работает.

Мы отправляем больше.

Но мы сталкиваемся со всеми узкими местами, которых в прежнем мире вы бы не увидели, верно?

Раньше мы не сталкивались с такими проблемами, но теперь мы, например, ускоряем одну часть многоэтапного цикла, и я думаю, что именно здесь становится интересно, например: "Хорошо.

Мы делаем больше, но теперь это похоже на пожарный шланг эффектов».

Поэтому мы сталкиваемся с другими проблемами.

Это очень интересная мысль, потому что, если подумать, существует много разных шагов, но с точки зрения высокого уровня их можно разделить на три этапа, верно?

Например, программирование, которое явно ускоряется.

Есть готовность рабочей версии, которая включает в себя ряд вещей, таких как юридические вопросы, конфиденциальность и вещи, которые позволяют вам что-то выпустить, а затем запустить, верно?

И потом, доставка действительно означает разные вещи в зависимости от того, где вы находитесь, верно?

Если вы работаете с серверным продуктом, то, скорее всего, отправка означает более оптимизированный процесс, тогда как при отправке чего-то, что идет к потребителю, экспериментирование – это только середина пути.

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

Я двигаюсь очень быстро", но теперь вы упираетесь в следующее узкое место.

И что он делает, как ИИ делает очень очевидным, так это то, что вы более четко видите точки трения, и некоторые из них не имеют ничего общего с кодированием или технологиями.

Она связана с процессами и людьми, а также с тем, как вы оптимизируете это с помощью ИИ.

Это действительно интересная задача – как оптимизировать весь процесс.

Один из интересных способов, которым мы думаем об этом пространстве, заключается в том, насколько человек или команда могут полностью его реализовать?

Если мы посмотрим на внутренние процессы, то увидим, что многие команды создают внутренние инструменты или вещи, которые не поставляются клиенту.

Они доставляют намного быстрее, верно?

Они имеют полное право немедленно донести это до своих клиентов.

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

И поэтому они просто сталкиваются с остальными узкими местами в системе.

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

Да, я согласен, и я чувствую, честно говоря, инженерия никогда не была узким местом.

Я говорю об этом уже много лет.

В инженерном деле все очень строго, и бизнес всегда спрашивает: "В чем проблема?"

Вы получите 10 разных ответов.

А потом: "Ладно.

Теперь давайте посмотрим, как это можно реализовать на практике.

Давайте немного подумаем над этим.

О, давайте, может быть, немного поговорим о дизайне.

Пни его туда".

К тому времени, когда дело доходит до разработки, мы уже более или менее знаем, что нам нужно делать.

Затем мы просто заходим на Stack Overflow, копируем и вставляем код и выпускаем продукт.

ИИ помогает мне быстрее всего именно с соблюдением требований.

Например, вы давно хотели модернизировать XYZ или быстро обновить версию Spring Boot.

Мы делаем это очень быстро.

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

Итак, вы все затронули тему того, что, возможно, узкое место переместилось, и вы сталкиваетесь с процессами, которые раньше не были узким местом, но теперь стали им.

Но эти процессы, вероятно, возникли из-за трудно усвоенных уроков в прошлом, верно?

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

Каким мы видим будущее код-ревью?

Что мы делаем сейчас?

Так что да, я бы хотел услышать.

Это возвращает нас к тому, о чем я говорил.

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

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

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

Мы попросили ИИ написать их, все в порядке.

Нет, я имею в виду, вы будете работать лучше, чем тот агент?

Не знаю, например, не тратить время на проверку.

Но если вы собираетесь выпустить баг и вам звонит генеральный директор и говорит: "Эй, эта штука стоит нам X долларов", то, возможно, стоит определить области и системы, где "Эй, это критическая область.

Это не критическая область", а затем попробуйте переосмыслить.

Насколько я знаю, сейчас мы так не делаем.

Сегодня это выглядит так: "Эй, у нас есть PR.

Я инженер.

Я сосредоточен на этом.

Она будет расти.

Я прошу Виная проверить код посреди ночи, потому что хочу поскорее его объединить".

А может, нам стоит переосмыслить многие из них.

Я полностью согласен и считаю проверку кода проблемой верификации. И я имею в виду, что в мире, где я полностью уверен в своей способности что-то проверить, буду ли я по-прежнему проверять код 100% своих PR?

Скорее всего, нет.

Итак, проверки кода служат двум целям.

Первая – это, конечно, проверка того, что мы все делаем правильно, а вторая – обучение.

Например, люди вокруг вас знают, что вы делаете, и согласны они с этим решением или нет.

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

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

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

Не знали, куда бежать.

Верхняя часть воронки очень широкая, и на разных платформах можно создавать больше PR-кампаний.

И вы так же быстры, как и самый медленный шаг процесса.

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

Да, и если быть честными с самими собой, я бы сказал, что 70 % PR, которые я видел, выглядят хорошо.

Если бы мы просто искали по всем базам кода в мире, комментарии к PR были бы просто "выглядит хорошо", LGTM, по всей доске.

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

Мы действительно думаем, что мы там.

"Использовали ли они шаблон команды?"

Нет, мы просто говорим: "Хорошо.

Да, по-моему, все хорошо".

Почему бы не поручить это агенту?

Я думаю, что в будущем мы увидим, что именно нам нравится, какие характеристики и поведение вызывают у нас такие чувства.

А затем убедитесь, что агент ищет то же самое.

Или, с другой стороны, также попробуйте подумать о разных способах проверки, верно?

Например, я знаю людей, которые сидят в Твиттере и говорят:

Например, когда вы проверяете PR, попросите агентов визуализировать его по-другому.

Покажи, как было до.

Покажи, что получилось.

Покажи мне тесты, которые ты написал, а не построчный обзор кода.

Но это бросает вызов... Вы хотели что-то сказать, Луис?

Нет, я думаю, что это заставляет задуматься, верно?

Например, мы собираемся достичь такого уровня, когда вы будете чувствовать себя комфортно, позволяя CL или PR проходить без вмешательства человека.

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

И я думаю, что отзывы по-прежнему относятся к категории хороших трений.

Вопрос в том, как сделать это менее обременительным для разработчиков, верно?

Иногда дело не в том, как сделать проверку в определенный момент времени лучше или эффективнее.

Как сделать разработку более точной с помощью ИИ?

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

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

Поэтому у разработчиков возникает меньше проблем с проверками.

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

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

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

Например, должны ли мы проводить построчный обзор в PR по сравнению с обзором намерения, которое они, знаете ли, пытаются продвинуть после?

Мы думаем об этом в нескольких разных направлениях.

Во-первых, как мы можем предоставить пользователю более релевантную информацию, чтобы он мог начать расставлять приоритеты?

Другой вопрос: в каких областях мы можем экспериментировать и быстрее продвигаться в подобных программах?

Как говорил Каушик, не все области требуют одинаковой строгости.

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

были правильными.

Например, рефакторинг нового модуля Android в приложении Uber, возможно, в порядке.

Бесплатные поездки для всех разработчиков Android. Наверное, стоит проверить этот код.

Мне нужно уточнить это у генерального директора.

Извините, Каушик.

Но я также считаю, что эта проблема решена.

У нас уже есть флаги функций.

У нас уже есть сине-зеленое развертывание.

У нас уже есть много фрагментов.

Проблема в том, что мы были слишком заняты, чтобы сделать это.

Мы уже отслеживаем поведение пользователей.

У нас есть все эти данные, но они хранятся в разных системах.

Мы уже отслеживаем инциденты.

У нас так много данных, но собрать их все вместе в один всеобъемлющий след — вот чего не хватает.

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

Потому что мы знаем, что у нас есть флаг функции.

У нас есть сине-зеленое развертывание.

У нас есть все возможности для наблюдения.

И тогда вы сможете с уверенностью сказать: "О, добавьте это в конвейер".

Если что-то пойдет не так, у нас есть все эти охранники и ворота на пути.

Я думаю, что скорость реагирования также очень важна, верно?

Если вы, например, выпускаете изменение для Android, которое должно пройти через Google Play, а затем дойти до пользователей, то у вас не получится сразу же выпустить исправление. Но если вы делаете что-то, что имеет внутреннее развертывание с внутренней наблюдаемостью и агентом, который сразу же на это реагирует, у вас гораздо больше возможностей действовать быстрее.

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

Я знаю, что многие из вас работают над огромными приложениями, верно?

Мне интересно, что вы думаете по этому поводу.

Вы говорите генеральному директору: "Дайте мне три месяца, чтобы подготовить приложение к внедрению ИИ"? Или вы добавляете его каждый день?

Да.

Они никогда этого не делают.

Не думаю.

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

Я думаю, что мы просто должны посвятить этому то же самое время, которое мы привыкли тратить на технический долг, например, использовать 20 % своего времени на это, и использовать 5 % из этого времени на улучшение подсказки.

и даже понять, что делает запрос, и улучшить контекст.

Как мы уже говорили, многие инженеры до сих пор не понимают, как это работает.

Они до сих пор воспринимают его как нечто магическое и мистическое, поэтому не настраивают его так, чтобы получать максимальную пользу и эффективность.

Поэтому я думаю, что должен наступить момент, когда лидеры скажут: "Что нам нужно сделать, чтобы повысить уровень нашей команды, чтобы они могли понять, как это работает, и тогда мы сможем получить больше?"

Это также его продолжение.

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

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

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

Но сейчас это проблема для всех в отрасли.

Я бы хотел немного разнообразить их.

Многие из вас работают в инфраструктуре разработчиков.

Тысячи PR, ваша тестовая инфраструктура, ваши серверы, все плавится?

И я бы с удовольствием послушал истории о битвах.

Тай?

Да.

Они в огне.

Мой ИИ плачет, чтобы я засыпал под его плач каждую ночь.

Практически все наши команды разработчиков инфраструктуры сейчас борются с проблемами масштабирования в области вычислений и эффективности.

Там, знаете ли, красные коды.

Они видят огромный рост объема.

Мы меняем архитектуру агентов.

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

Но это очень сложно.

Да, я согласен со всем, что только что сказал Тай, но я думаю, что это также заставляет нас задуматься и честно спросить, готовы ли мы, если с этого момента мы увеличим масштаб в 10 раз?

И для большинства людей ответ, вероятно, отрицательный.

Поэтому, думая о будущем, мы стараемся соизмерять свои амбиции с возможностями инфраструктуры.

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

Верно, мы думаем о том, какая ещё система сломается или, как мы ожидаем, сломается, и что мы можем сделать, чтобы просто опередить её, чтобы это не стало сюрпризом?

И на самом деле мы пытаемся избежать сюрпризов.

Верно, пока мы чувствуем, что контролируем ситуацию, все счастливы.

Как только мы сталкиваемся с сюрпризом, я знаю, что это плохие новости для всех.

Все верно?

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

Это неизбежно.

Мы просто хотим опередить его.

Мне запомнилась цитата генерального директора Inflow.

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

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

Кстати, об этом. Устанавливают ли ваши компании лимит расходов?

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

Например, есть ли у вас какие-то стратегии или лучше просто дать им свободу, потому что эксперименты приводят к отличным результатам?

Прошлый год был годом экспериментов.

Выполняйте все задачи.

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

А теперь, с сентября, у нас есть лимиты токенов.

Поэтому у нас есть ограничения на использование токенов для разработчиков.

А ещё у нас есть инструменты, которые помогают понять, насколько эффективны тренировки.

Что такое здоровый сеанс?

У вас столько реплик за сеанс?

Что такое ход?

Поэтому мы стараемся использовать инструменты, чтобы обучать разработчиков.

Я думаю, что это только первый шаг.

Знаете, вы должны знать, что у вас есть проблема, прежде чем вы сможете ее исправить.

И поэтому, как и они, по крайней мере, видят, что это не бесплатно.

Раньше казалось, что ИИ – это бесплатно.

И люди просто пользовались им.

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

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

Поэтому я думаю, что мы начнем обучать инженеров реальной стоимости.

Скорее, я бы не стал просто запускать экземпляры ECS и просто убегать от них.

Возможно, когда AWS только появился, мы думали: "Да, я могу потратить свой собственный экземпляр".

И мы просто стоили компании столько денег.

Думаю, то же самое сейчас происходит с токенами.

Я думаю, что практические ограничения также предоставляют действительно интересные возможности, верно?

Потому что, если вспомнить, как мы начинали использовать LLM, мы закидывали в них всё подряд, верно?

Они бы проанализировали код, разобрались в нем и сделали бы за вас всю работу.

Но за это пришлось заплатить.

И мы на самом деле реальны – вы знаете, индустрия это понимает.

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

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

Так что у вас есть много возможностей использовать ограничения на токены и использование в своих интересах и фактически стать более эффективными.

Да, и в связи с этим мы ввели ограничения, по крайней мере в Instacart.

Но я думаю, что цель не обязательно состоит в том, чтобы ограничить использование ИИ, а в том, чтобы привнести своего рода гигиену или, как вы говорите, самоанализ, верно?

Например, когда вам следует использовать определенные модели по сравнению с другими моделями.

Знаете, вам, вероятно, не нужны Fable или Astra, чтобы узнать время или сменить ветку Git.

Все верно?

Вы можете потратить время на написание скрипта, и он будет бесплатным навсегда.

Токены не будут потрачены впустую.

Все верно?

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

Все верно?

Мне нравится, как вы сказали: прошлый год был годом экспериментов.

А в этом году мы уже думаем, как эффективно использовать эту технологию.

Да.

Истории, которые мы здесь видим, находят у нас большой отклик.

Особенно когда вы переходите от экспериментов к сбалансированному сочетанию эффективности и ответственности.

Это происходит благодаря различным инвестициям.

Это и обучение разработчиков, и повышение видимости.

Как говорила Аннис, это может быть стоимость активного сеанса и информация о нем.

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

и отчитываться о расходах.

У нас есть ограничения на количество токенов.

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

Если у вас есть отличные идеи, мы хотим, чтобы вы их реализовали.

Но если они делают что-то более расточительное или экспериментальное, они не могут объяснить своему менеджеру, почему они должны тратить на это деньги, тогда это также помогает им держать это под контролем.

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

Это правильный вес?

Очевидно, что стоимость этих токенов начала снижаться из-за конкуренции.

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

А в долгосрочной перспективе – полностью избавить их от необходимости принимать такие решения.

Все верно?

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

Но пока это здоровое состояние.

Да.

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

Но также важно иметь правильные растяжки.

Поэтому мы рассматриваем лимиты токенов с нескольких точек зрения.

Мы не хотим блокировать разработчика.

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

Например, дневные лимиты – это просто предохранитель, который разработчик может отключить самостоятельно.

Всё, что им нужно сделать, это зайти на портал, нажать кнопку и сказать: «Эй, ничего удивительного не произошло.

Я все контролирую".

Все верно?

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

Так что это вполне разумно.

С другой стороны, мы хотим, чтобы разработчикам были доступны лучшие модели.

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

Поэтому у нас есть месячный бюджет.

Достаточно высоко.

Вы не заблокированы.

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

Отправляется вашему менеджеру.

Это момент, когда вы описываете, что вы делаете.

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

Что касается использования передовой модели, мы снова даем вам полную гибкость с потолком.

Это работает, потому что в конечном итоге вносит в процесс предсказуемость.

Все верно?

Мы хотим быть уверены, что при планировании бюджета на токены (а это непростая задача для всех) мы учли все, что планировали, и эти рычаги позволяют нам это сделать.

Знаешь, что меня больше всего поражает в этих разговорах?

Я думаю, это потому, что все мы работаем в компаниях.

И, наконец, предприятия.

Поэтому мы должны платить за каждый токен.

Все верно?

Но есть и другая сторона интернета, где люди платят за подписку.

И поэтому для них это совсем другой расчет.

Все верно?

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

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

Или вы работаете в передовой лаборатории с неограниченным бюджетом.

А затем вы просто продолжаете работать и создавать множество этих действительно захватывающих, например, нативных способов работы с ИИ, которые есть во всем Твиттере.

Все наши компании хотят отразить это, но они не думают, что хотят тратить токены, которые…

Здесь есть люди, которые работают в Google.

Мне очень интересно.

на странице просмотра?

Какой бюджет выделяет Google?

Луис, хочешь ответить?

Я не думаю, что я тот человек, который должен говорить об экономике.

Google – очень большая компания, в которой много разных подразделений.

Но это на самом деле идеально завершает нас, потому что мы как раз вовремя.

Это было удобно.

Спасены звонком.

Вот это я понимаю – модерация на высшем уровне!

PR-специалисты…

В любом случае, спасибо нашим экспертам и спасибо, что пришли на ADS.