Transcription
Здравствуйте все. Я Пирс из команды BS Code, и сегодня мы поговорим о том, чему мы научились, переведя BS Code с ежемесячных на еженедельные релизы. Надеюсь, у всех проходит замечательная сборка. Пока что было много отличных объявлений. И я думаю, что уникальное, что мы хотим вам показать в этом докладе, это то, что, как и все в своих сессиях, вам, вероятно, говорят: вот что, мы анонсировали какой-то продукт с ИИ, который вам нужно немедленно попробовать. И это, наверное, большинство сессий, верно? В этой сессии мы хотим немного поговорить о том, как нашей команде пришлось развиваться за последний год и полтора, когда мы фактически внедрили ИИ, потому что для этого изменения потребовалось много изменений в нашем процессе планирования, в нашем внутреннем цикле, в нашей инженерной системе. Итак, как я уже сказал, меня зовут Пирс. Я руковожу командой PM в VS Code. Джош, хочешь представиться? Да, я в команде, в команде VS Code уже несколько лет, и я видел наш старый процесс и наш новый процесс, и я рад показать вам всю крутую работу, которую мы проделали. Отлично. Итак, как я уже сказал, я думаю, вы знаете, наверное, у каждого начальника есть такое: ты должен больше использовать ИИ, а ты такой: отлично, мы это делаем. А потом я думаю, мы начали осознавать, что почти как бы начинаем использовать ИИ, использовать агентов, верно? Начиная с редактора, переходя от призрачного текста к правкам с помощью Copilot, к полному режиму агента внутри ES Code. Это была как бы легкая часть, кавычки, кавычки. Но потом, когда вы действительно добиваетесь успеха с агентами, я всегда спрашиваю: хорошо, вы внедрили агентов, а теперь что? Каковы на самом деле последствия успеха с ИИ? И в VS Code нам действительно пришлось значительно развивать продукт. Мы знали, что VS Code всегда развивался, чтобы удовлетворять потребности разработчиков, верно? Он начинался как очень простой редактор. Мы добавили расширения, мы добавили удаленную разработку. Последняя эволюция этого — ИИ, и, знаете, эта эволюция заняла около 7-8 лет, чтобы достичь этой точки. А потом у нас появился ИИ, и нам пришлось быстро развивать продукт за последние пару лет, чтобы он стал тем, чем должен был быть. И агенты были действительно одним из ключей к этому. Но я думаю, что когда я впервые присоединился к этой команде в 2024 году, я думаю, возможности моделей были не совсем такими, как сегодня, верно? Так вот, это интересный график, который, по сути, является метрикой выживаемости кода. Итак, наша команда, одна из вещей, которые мы отслеживаем, это, по сути, для данной модели, верно, какой процент кода, произведенного этой передовой моделью кодирования, фактически зафиксирован? Это не самая идеальная метрика, но это разумный сигнал того, что разработчик имеет некоторый уровень уверенности в том, что этот код должен попасть в кодовую базу, верно? И, возможно, год назад передовой моделью была GPD, версия 1. И мы видели, что примерно 55% кода, сгенерированного GPD 41, возвращалось в кодовые базы, что по-прежнему очень, очень хорошо. Как это было огромным улучшением по сравнению с тем, что у нас было раньше. Но эта диаграмма немного отстает. Вы можете видеть Opus 46, у нас 86% кода, сгенерированного агентом, попадает в коммит. И поэтому, когда эти модели стали лучше, вы, очевидно, можете положиться на них, чтобы делать значительно больше. Это прогресс, который мы видели за один год. Это заставляет меня задуматься, где мы будем через год, верно? И, конечно, опять же, не то, чтобы коммиты были лучшей метрикой, но это хороший прокси. Вы можете увидеть, как наши коммиты резко начали расти, особенно к концу года, например, у нас был декабрь, у нас были отпуска и тому подобное. Но когда мы вступаем в 2026 год, вы видите, что рост коммитов в команде продолжает расти. Хорошо, значит, мы делаем больше вещей, верно. Мы действительно чувствуем, что мы не просто, это не было показным, мы просто больше коммитим, отлично. Мы больше используем ИИ, как я, я действительно чувствую, что VS Code стал намного лучше за последние шесть месяцев благодаря всей этой работе, которую мы смогли сделать благодаря агентам. Но то, что, возможно, вы не услышите во многих из этих докладов, это то, что успешное использование ИИ создает для вас больше проблем, верно? Итак, это метрика только за январь этого года. Итак, вы можете видеть, что у VS Code гораздо больше проблем, чем было, примерно в 3 раза больше проблем, верно? И гораздо больше открытых запросов на слияние с января. И эта диаграмма продолжает расти, верно? И поэтому, да, мы выпускаем больше, но мы также получаем больше проблем, с которыми нам приходится иметь дело. Нам приходится просматривать больше запросов на слияние. И поэтому был момент, когда мы достигли в январе, когда мы начали выпускать функциональность продукта гораздо быстрее. Когда мы поняли, что это ежемесячное планирование всегда было большой частью культуры VS Code. Мы так гордились тем, что выпускаем каждый месяц, и у нас было такое осознание, что этого на самом деле уже недостаточно. Поэтому нам пришлось перейти на еженедельные релизы. Мы сделали это в феврале. И было несколько причин, одна из которых заключалась в том, что пространство ИИ развивалось очень быстро, верно? Поэтому мы выпускали функции в VS Code Insiders, который является нашей ежедневной сборкой VS Code, в начале месяца. А затем конкурент выпускал их через две недели. Но мы выпускаем VS Code в стабильную версию только раз в месяц. И поэтому мы слышали: "О, ну, в VS Code нет этой функции". Так что, безусловно, было конкурентное давление, чтобы выпускать более частые релизы. Игры с моделями, действительно, мы делали много специальных вещей для подсказок и тому подобного. Нам нужно было выйти на рынок. Я расскажу об этом немного позже. И, конечно, я раньше работал в Azure, и у нас были заморозки развертывания, например, на праздники. И поэтому все инженеры все еще работали. Затем вы возвращаетесь с праздников, в январе, второго или третьего числа, вы возвращаетесь после Нового года, и у всех есть все свои потрясающие функции, над которыми они работали последние полтора месяца, с момента до Дня благодарения и Черной пятницы, и всех заморозок развертывания. И вы хотите знать, что произошло, что произошло на той неделе? Вы не хотите быть на дежурстве при инцидентах, верно? И поэтому, когда у вас есть эти большие пакеты, которые вы выпускаете, это невероятный риск. И поэтому, поскольку команда делала больше каждый месяц, мы также чувствовали, что нам нужно выпускать эти меньшие пакеты, чтобы мы могли проверить и убедиться, что ничего ужасного не происходит, когда мы не выпускаем все сразу. И поэтому остальная часть этого доклада действительно заключается в следующем: да, вы можете внедрить ИИ, вы будете двигаться быстрее, вы будете предоставлять большую ценность своим клиентам быстрее, но вам также придется подумать о том, как вы работаете. Вы не можете просто сказать своим командам: используйте больше ИИ. Вам придется подумать обо всех ваших инженерных системах и процессах и о том, как они должны развиваться вместе с ИИ. И поэтому мы рассмотрим несколько различных частей этого в нашем сегодняшнем докладе, начиная с внутреннего цикла разработчика внутри VS Code. Джош покажет нам, мы поговорим о некоторых конкретных специализированных инструментах, которые мы создали внутри VS Code для инженерной системы, нативной для ИИ. А затем, наконец, немного больше о том, как мы на самом деле решаем, какая работа попадает в VS Code с точки зрения планирования и сотрудничества, и наша модель там, и как это пришлось развиваться. Итак, с этим я передаю слово Джошу, чтобы он показал переключение на три внутренних цикла для инженеров VS Code. Да, спасибо. Да. Как я уже сказал, я инженер в команде VS Code. Я видел процесс до того, как ИИ стал чем-то, и я видел, как наша команда развивалась за последние несколько лет, чтобы действительно использовать все преимущества. Итак, я хочу показать несколько разных инструментов. Есть много инструментов. Я думаю, что мы создали некоторые, которые использует вся наша команда, некоторые, которые используют только несколько человек, в соответствии с их рабочими процессами. Я хочу показать несколько, которые я считаю очень ценными для работы, которую я выполняю. Я много работаю над агентами, я думаю, много над интеграцией агентов в VS Code. Я много работаю над частями настройки этого и большим количеством пользовательского интерфейса, верно? Итак, один инструмент, который мне очень нравится, и это APR от апреля, который я написал. И это было изменение, где мы, мы, мы только что внедрили эту новую функцию под названием компонентный браузер, которая позволяет нам нарезать компоненты в VS Code таким образом, чтобы агент мог хорошо с ними работать. И мне очень нравится этот пример, потому что это было изменение, которое заняло бы время, чтобы построить, протестировать, запустить в нашей локальной среде. И все это было сделано с помощью одного запроса. И я смог провести всю необходимую проверку прямо в PR. И изменение было простым, я просто хотел добавить кнопку "назад". Вы видите, что кнопки "назад" нет, теперь есть кнопка "назад". И то, как это написано, это то, что этот инструмент очень полезен как для новой функции, так и для обнаружения проблем и регрессий, которые вводятся как побочный эффект другого изменения. Итак, это, по сути, запуск VS Code с вашим изменением и без вашего изменения, снятие скриншотов и их размещение в PR. Так что это даже проще, чем это. Мы переписали большую часть того, как строятся наши компоненты в VS Code, чтобы они могли, чтобы они могли работать вне, чтобы мы могли фактически проверять и вводить данные внутрь компонентов вне продукта. Таким образом, нам не нужно запускать полную сборку продукта и иметь эту накладную нагрузку прямо для каждого PR, с сотнями PR, которые мы видим в день, это большая накладная нагрузка, много вычислений, много времени. Вот как мы извлекли это, чтобы сделать это намного проще. И, знаете, это простое изменение, но оно экономит массу времени. Оно действительно повышает вашу уверенность в вносимых изменениях. И да, у нас есть разные. Есть, есть целая, целая куча способов нарезать это. И вы можете видеть все, все фикстуры, которые я создал здесь, и все способы, которыми это подтвердило, что это изменение было правильным. И мне нравится, что это просто в APR. Так что, если вы в пути, верно, если вы не за своим компьютером, вы можете быстро открыть мобильное приложение GitHub, прокрутить и проверить поведение там, а также. Вам не обязательно быть за своим компьютером. Полностью, и я показываю изменение, которое я сделал, но от сообщества эти тесты также работают, верно? Так что, если есть PR от сообщества, который меняет, скажем, они хотели добавить кнопку "назад" или исправили ошибку, которую они, вы знаете, они вдохновились исправить ошибку, но не знали, как запустить OSS локально на своей машине и фактически протестировать ее от начала до конца. Они могут использовать ИИ, и мы можем использовать ИИ в качестве рецензентов кода, чтобы понять, как эти изменения повлияют на последующие. Итак, это всего лишь одна вещь, которая экономит нам столько времени для всех этих PR от сообщества, которые поступают. И да, у нас это работает и в VS Code. Итак, вы можете видеть все компоненты, которые мы извлекли, у нас есть кнопки, у нас есть переключатели. Все в VS Code, где мы не хотим, чтобы пользовательский интерфейс менялся или регрессировал без нашего ведома, мы извлекли это, и это простое изменение. Но я думаю, что образ мышления о том, как мы его используем, действительно ускоряет нашу разработку. Полностью, да. И, я имею в виду, у нас есть BS Code на всех операционных системах, веб. Так что он работает везде. И поэтому существует большая тестовая матрица, необходимая для каждого из этих компонентов. Точно. И да, у нас есть, я думаю, я просто открою это снова, и я просто покажу вам в чате, как я просто попросил чат ранее поменять кнопку с синей на зеленую, и вы можете видеть, как это работает. Это то, что он сделал, он сделал снимок экрана до этого. Он смог найти фикстуру, потому что я дал ему имя фикстуры, которую я хотел, чтобы он обновил. Я сказал, продолжай итерировать, пока не будет выглядеть правильно, а затем сделай снимок экрана, чтобы показать мне, что это правильно, и она стала зеленой. И это все в чате, прямо здесь. Он смог перезагрузить браузер компонентов здесь. Так что он интерактивный, вы можете видеть, что вы можете свернуть эти или выделить, и все эти взаимодействия с пользовательским интерфейсом работают так же, как и в продукте. Это одна вещь, которую я считаю очень ценной, которую я, я думаю, не ожидал найти такой ценной, поэтому я хотел ее выделить. И она работает, как вы сказали, как это все работает в вашем цикле агента. Так что, если по какой-то причине изменение не дает того, что вы хотите, потому что оно итерирует по скриншотам и выводу из обозревателя компонентов. Оно действительно может исправить это, что приятно. Полностью, вы получаете встроенную проверку, которую они имеют от агента, и это то, когда вы используете агентов для внесения изменений в пользовательский интерфейс. Это просто угадывание, верно, здесь есть этот своего рода цикл обратной связи, которого не хватает, и именно это решает этот инструмент. Круто, круто. Так что это, да, я люблю этот инструмент. У меня он работает весь день. Другие способы, которыми мы много сотрудничаем в эти дни, — это просто использование агента для создания прототипов, верно? Вы видели, что я строил раньше, это пользовательский интерфейс настроек агента, где мы расширяем его, чтобы он стал центром для других видов конфигураций агента на всех поверхностях Copilot прямо сейчас. И мы с Гарольдом, кем-то из нашей команды, сотрудничали друг с другом над этим прототипом, который находится на этом GitHub, и просто использовали агентов для создания прототипов. Этот вид прототипа написан таким образом, что его можно легко перевести обратно в VS Code. Так что это не просто пустая работа. Это работа, которая полезна нам для общения друг с другом, с другими заинтересованными сторонами в команде. Вот наше видение продукта. И затем это действительно хорошо переводится обратно в VS Code. Так что это экономит нам много работы. Это экономит нам много обмена мнениями по написанию спецификаций или на совещаниях. Я думаю, с нашими еженедельными релизами нам приходится больше общаться. Нам приходится больше общаться. Я думаю, мы должны говорить каждый день, чтобы убедиться, что мы, и это делает это намного проще. Да, я думаю, что прототипирование очень интересно, потому что как PM, я всегда писал эти спецификации, верно? Мы никогда не делали этого в команде BS Code, но многие команды работают именно так, верно? Вы пишете какой-то документ, и никто не хочет читать этот документ, верно? И то, что я всегда находил неудовлетворительным в этом, это то, что все это гипотетично, верно? Вы на самом деле не знаете, пока не получите в свои руки опыт и не проведете с ним время. О, мне это нравится, мне это не нравится. Есть этот крайний случай, о котором мы не думали. И, конечно, до ИИ вы могли создавать прототипы, но во многих случаях это было очень дорого. И поэтому, я думаю, это был большой сдвиг для нас в нашей команде — очень часто мы делаем такие вещи, как использование этого инструмента прототипирования для исследования новых идей, иногда даже создавая сам прототип внутри VS Code. А затем, знаете, команда PM даже иногда отправляет вам PR. И суть не в том, что вы принимаете наш PR, а в том, что все это почти становится спецификацией, верно? Да, и наша команда, конечно, использует Insiders каждый день. И мы выпускаем Insiders как минимум дважды в день, часто больше, и с ежемесячным выпуском это давало нам достаточно времени, чтобы почувствовать определенные изменения в продукте. Теперь, с циклом еженедельных выпусков, нам нужен более быстрый цикл итераций, и именно это достигается благодаря этому. Есть еще несколько внутренних циклов, которые я действительно выделил в море изменений. У нас есть навыки, конечно, как и у всех остальных. Все это находится внутри репозиториев VS Code, с открытым исходным кодом. Все, что вам интересно здесь, вы можете использовать сами. Один из них, который мне кажется интересным или который я нашел очень полезным, — это навык производительности чата, который мы создали. Итак, мы создали много инструментов для моделирования сложных сценариев в нашем рендерере чата. И мы закодировали все это в навыки, которые мы используем на протяжении всего процесса разработки. И это объясняет здесь, как это работает. У нас есть некоторые инструменты, но ключевым моментом является то, что мы можем использовать навык, чтобы позволить агенту понять, приведет ли наше изменение к регрессии каких-либо показателей производительности, которые мы уже зафиксировали здесь. И выходные данные действительно хороши. Способ, которым мы можем заставить агента запрашивать. У меня есть другой чат, подготовленный. Все, что я сделал, это запустил навык / chat-perf в репозитории VS Code. Я, конечно, не вносил никаких изменений в эту ветку, поэтому он не найдет ничего интересного. Но то, что он делает и для чего мы его используем, это если мы вносим сложное изменение в рендерер или в часть кодовой базы, которая, по нашему мнению, может быть рискованной, или если агент думает, что она может быть рискованной, он знает, что нужно использовать навык, чтобы определить, следует ли нам учитывать что-либо еще. И это действительно хорошо для еженедельных выпусков, верно? Это то, на что у нас нет времени как у команды разработчиков, чтобы сидеть с этим целый месяц, как мы раньше делали в Insiders. Поэтому позволить агенту или, я бы сказал, научить агента, углы и аспекты, которые нас волнуют, действительно важны и очень полезны, верно? Это объясняет, у нас есть набор показателей, таких как ожидаемые нами временные интервалы, и это очень легко для человека прочитать. Очень легко запрашивать результаты с помощью SQL. У нас есть несколько в нашем навыке, которые мы кодируем, которые очень, которые мы нашли очень полезными. И это очень легко для человека прочитать и понять, и для агента итерировать над исправлением или, по крайней мере, сказать: "Эй, эта часть выглядит немного странно". Да, мне нравятся такие вещи, потому что я думаю, люди говорят: "О, я использовал ИИ, чтобы добавить, знаете, больше функций в продукт". Но я, я, я думаю, что для нас в VS Code производительность всегда была центральной для того, что мы там пытаемся сделать. И, конечно, мы хотим двигаться быстрее с ИИ, но вы также хотите убедиться, что, делая это, вы не ухудшаете качество и производительность продукта. И поэтому я люблю такие примеры того, как мы можем по-прежнему обеспечивать, чтобы у нас был высокопроизводительный продукт, который мы выпускаем, но мы все еще можем делать это, двигаясь быстро. Да, да. И, и есть один, я думаю, он у меня здесь. Был один недавно, который был действительно крутым, который прокрался в наш продукт. Затем мы начали внедрять этот инструмент. Мы провели эти тесты. Мы увидели, что была проблема с, я думаю, это было парсинг инструментов. Да, да. Это была ошибка парсинга инструментов, которая была найдена и сэкономила пару тысяч миллисекунд на каждом вызове инструмента, который поступал, что очень много, верно? И это было полностью сгенерировано ИИ. Как проблема, так и исправление были, по крайней мере, частично написаны ИИ, а затем, конечно, проверены здесь Полом. Но просто очень интересно видеть, что мог найти агент. И это было связано с несколькими различными процессами в VS Code. Это не простая, прямолинейная ошибка, знаете ли. И я думаю, что это два основных агентурных внутренних изменения, которые я считаю интересными. Но их так много, около дюжины навыков, которые мы добавили за последний месяц, с которыми экспериментируют наши команды. И да, есть гораздо больше, которые я не успеваю показать. И, и круто то, что эти навыки, верно? Конечно, верно, в каждой команде есть кто-то, кто говорит: "Я все знаю о производительности, верно?" И это доверенный эксперт в команде. И я думаю, что до ИИ эта проблема заключалась в том, что этот человек был узким местом, верно, для каждой вещи, связанной с производительностью. И теперь, если вы можете взять эти знания о том, каковы наши ожидания, и, возможно, инкапсулировать столько, сколько вы можете из мозга этого человека, невозможно сделать это полностью. Но если вы можете взять ключевые вещи и создать такие навыки или инструменты, то теперь вся ваша команда имеет доступ к этому человеку по производительности, с которым они могут работать непрерывно. Верно. И, я имею в виду, эти навыки были фактически написаны этими экспертами, верно? Так что это закодировано именно то, что они считают важным, и позволяет нам всем иметь агентство и брать на себя ответственность за эти ошибки, а не просто передавать их кому-то другому. Полностью. Хорошо. Это была ваша последняя демонстрация для этой секции? Хорошо, переключаемся как профессионал. Хорошо, так что еще одна вещь, о которой я хотел поговорить, это то, что, я думаю, когда люди говорят: "О, есть новые модели в GitHub Copilot", я думаю, они просто предполагают: "О, есть API, и вы просто подключаете его, и тогда происходят правильные вещи, верно?" Но на самом деле реальность такова, что существует огромное количество усилий, возможно, я не знаю, по крайней мере, 15-20 человек, которые участвуют в таких запусках. Из разных дисциплин, будь то инженерия, продукт, маркетинг, конечно, наука о данных, верно, чтобы эти модели попали в ваши руки. И поэтому мы тратим значительную часть нашего времени на это, особенно сейчас, когда, кажется, каждую неделю выходит новая модель от одного из поставщиков, которая поддерживается в Copilot, верно? Обычно это работает так: перед запуском поставщики приходят к нам, они, вы знаете, под NDA, говорят, что выходит новая модель. Они дают нам тонну информации о модели, мы интегрируемся с этой вещью под названием Copilot API, которая является, по сути, нашим шлюзом API для всех наших моделей в продукте. А затем мы, по сути, в течение нескольких недель, мы постоянно итерируем, как мы можем заставить его работать очень хорошо для этой модели. Я думаю, есть предположение, что вам не нужно ничего делать с подсказками. Но на самом деле, если вы зайдете в VS Code, он с открытым исходным кодом, если вы зайдете в VS Code и наберете, например, OpenAI prompt, вы можете увидеть фактическое динамическое построение всех подсказок, которые мы делаем в продукте. И каждое слово в этом имеет цель. И поэтому мы тратим много времени на офлайн-оценку, улучшая ее, работая с поставщиками моделей, обмениваясь информацией, как мы можем сделать это лучше, чтобы повысить уровень разрешения и также улучшить эффективность токенов. И поэтому у нас также есть внутренние группы для внутреннего тестирования, где мы получаем качественную обратную связь. И, и поэтому происходит множество вещей, и затем мы наконец запускаем модель. Так что это, по сути, то, что происходит до запуска. Но затем после запуска мы также вложили много средств в нашу инфраструктуру экспериментов внутри VS Code. Итак, у нас есть, если у вас включена телеметрия в VS Code, мы проводим A/B-эксперименты в любой момент времени, мы можем проводить, знаете ли, многие из этих экспериментов, мы специально проводим эксперименты по улучшению подсказок. И, конечно, я люблю офлайн-оценки, но у них есть недостатки, верно? Есть много вещей, которые вы не можете полностью инкапсулировать в офлайн-оценке. И поэтому онлайн-эксперименты помогают нам получать реальные данные и фактически принимать решения о наших подсказках. И поэтому очень часто, если вы шпионите за репозиторием VS Code и заходите в запросы на слияние после запуска модели, вы иногда увидите, как мы тестируем в реальных условиях две, три, четыре версии этих подсказок путем A/B-тестирования. И мы можем измерить многие из метрик, о которых мы говорили ранее. Мы можем сказать: "Хорошо, как это влияет на эффективность токенов? Как это влияет на, знаете ли, сохранение кода? То, что у нас было раньше. И поэтому обычно через две недели после запуска модели мы завершаем всю офлайн-работу, мы проводим онлайн-работу, у нас есть результаты экспериментов, и мы принимаем решения о том, что мы на самом деле будем выпускать. И поэтому обычно, как ни парадоксально, лучший опыт, который мы получим с этой моделью, обычно приходится примерно на два поста после запуска, потому что у нас было время провести как офлайн, так и онлайн-оценки. Итак, я упомянул оценки, лично мы обнаружили, что оценка, как инфраструктура, так и бенчмарки, доступные в открытом доступе, недостаточны. И поэтому, очевидно, с учетом всех выпусков моделей и всего остального, мы хотели принимать объективные решения о том, что мы делаем в продукте. И поэтому мы создали эту вещь под названием BSE bench, и это, по сути, наш специализированный стек офлайн-оценки для VS Code. И это то, на что я ссылался ранее, где у нас есть наши собственные случаи, у нас есть наша собственная инфраструктура для проведения этих оценок. И мы проводим множество, множество, множество таких каждый день с различными вариациями, чтобы понять влияние различных изменений на такие метрики, как токены и уровень разрешения. Вот пример графика общего количества токенов по сравнению с уровнем разрешения. И вы можете видеть, как это меняется, да, конечно, GBD 55, у вас лучший уровень разрешения, но иногда ценой большего количества токенов. Вы можете видеть, что здесь также наложены различные усилия по рассуждению. Так что это интересный продуктовый выбор, который мы должны сделать: не просто "оптимизировали ли мы подсказки", а "с каким усилием рассуждения мы выпускаем?". И поэтому, конечно, вы можете сказать: "Хорошо, экстра-высокое для всего, это всегда даст лучшие результаты". Но я думаю, что интересно то, что на самом деле это не так, по крайней мере, в нашем стеке офлайн-оценки для GBD 55. И есть также компромиссы, конечно, с затратами и тому подобным. Так готовы ли вы обменять, скажем, 1% прироста уровня разрешения на 20% увеличение стоимости токенов, как большинство людей не будут, верно? И это те решения, которые вам нужно рационализировать перед запуском. Итак, это VSC bench, это наш внутренний цикл и то, что мы делаем изо дня в день. Но теперь я хочу, чтобы Джош рассказал об самой инженерной системе. И я всегда, я чувствую, что у нас была более продвинутая, специализированная инженерная система, которую мы создали для VS Code, но нам действительно пришлось развивать эту вещь, в частности, за последние пару месяцев. Итак, я передаю вам, чтобы вы рассказали об этом. Спасибо, Крис. Да. Я думаю, у нас было много очень специфических инструментов для VS Code с тех пор, как я присоединился к команде, много автоматизации проблем. У нас была модель, обученная очень долго, которая, я попытаюсь вывести, кто является владельцем проблемы, и другие виды очень простых задач. Но это было так ускорено с появлением ИИ и через агентурные рабочие процессы, на которых построено многое из того, что я хочу вам показать. Но сначала эта очень впечатляющая графика дает вам хорошее представление о том, как система взаимосвязана. У нас есть три входа, верно? У нас есть события из GitHub. Это проблемы и PR, и все эти сигналы. И это, я думаю, сигналы, которые мы всегда использовали в прошлом. Это, я думаю, точка входа для любых изменений в VS Code — это проблема для начала. Но в наши дни у нас есть много запланированных заданий, которые просто делают всевозможные вещи, которые проходят через все, я думаю, все данные, которые у нас есть, и пытаются найти и понять ошибки и даже исправить их. Так что это одна из них, которую я пройду, агент ошибок, который действительно интересен. Много самовосстановления. Да, это работа, которую мы проделали, чтобы исправить наши другие рабочие процессы, чтобы инженерная система в целом оставалась здоровой, верно? Потому что это то, что, я думаю, вы можете построить много с помощью ИИ, но вам нужно убедиться, что как только вы перейдете к следующей вещи, она продолжит работать и функционировать так, как вы ожидаете. И мы обнаружили, что в нашем масштабе с количеством поступающих проблем, с количеством вносимых нами изменений, это на самом деле немного сложнее, чем фактически создавать эти инструменты, это убедиться, что они устойчивы и способны обрабатывать нагрузку, которую мы им даем. Так что много мыслей было вложено туда. И затем мы, конечно, мы также можем, мы также можем запускать их сами. У нас есть расширение Chrome здесь, которое я немного освещу некоторые из этих панелей, которые встроены в расширение Chrome Edge. Но это позволяет выполнять некоторую ручную работу над проблемой для автоматизации некоторых ручных процессов. Знаете, как, я думаю, любой инженер в команде BS Code может вам сказать, что большая часть нашего времени в прошлом и даже сейчас уходит на понимание и сортировку проблем и отправку их в нужное место. И вся цель нашей новой инженерной системы — сэкономить время наших инженеров, чтобы мы могли сосредоточиться на фактическом написании кода и фактическом создании продукта. Итак, очень высокоуровневый обзор нашей инженерной системы в наши дни. Я думаю, мы обновили это вчера, верно? Так что это постоянно меняет свою форму по мере того, как мы узнаем больше. Итак, я перейду к некоторым аспектам сортировки потока входящих проблем GitHub, потому что это, безусловно, наш самый большой сигнал, когда что-то идет не так или когда сообщество хочет что-то изменить. Ну, и я думаю, что, знаете ли, очевидно, мы используем больше ИИ, который генерирует больше проблем для нас, но также и наше сообщество использует больше ИИ, который генерирует больше вещей, больше, больше вещей для нас, с которыми нужно иметь дело, верно? И поэтому это не просто наш собственный объем проблем, которые мы генерируем. Мы являемся одним из крупнейших в мире проектов с открытым исходным кодом, и мы также получаем огромный поток вкладов от сообщества. Абсолютно. Да. А затем понимание того, является ли проблема, которая поступает, чем-то, что мы можем решить, или чем-то, что может решить, возможно, это сбой службы или что-то в этом роде. Есть целое новое царство проблем, которых у нас, как у клиентского приложения, не было четыре или пять лет назад. Да, я имею в виду, мы говорили о Copilot API, очевидно, у нас есть огромная зависимость от того, чтобы убедиться, что он работает для нас. И, как вы сказали, мы были просто клиентским приложением, риска подключения практически не было. Возможно, сервис обновления был единственным, который у нас был, верно? А теперь, чтобы использовать продукт, если вы используете какие-либо функции ИИ, конечно, вы знаете, мы используем локальные модели для некоторых вещей, но подавляющее большинство этих вещей идет на какой-то онлайн-сервис. Полностью, да. Итак, мы создали много инструментов для этого, чтобы выполнять автоматическое срабатывание для нас. У нас есть много данных, которые мы собираем и пытаемся понять, успешно ли это, когда кто-то, когда у нас есть проблема, которая автоматически сортируется, успешна ли она или ее изменил человек впоследствии. Много действительно интересных данных, которые мы здесь собираем. Так что мы узнаем больше. Вы можете просто увидеть, как это работает, что очень круто здесь. Итак, это прошло, я думаю, может быть, два часа назад, это прошло через проблему, которую оно увидело, просмотрело. Посмотрим, есть ли здесь что-нибудь интересное. Да. Но вы можете видеть, что мы просматриваем все наши проблемы и пытаемся найти для них владельцев. Это, я думаю, это показывает вам. Да. Итак, у нас была проблема, или у нас была проблема четыре часа назад. Он нашел назначенных лиц, ответственных за нее, области, которые имеют смысл. Он определил, что это запрос на функцию, а затем у нас были инструменты, чтобы, если это ошибка или какая-то регрессия, фактически исправить это для нас. Итак, как он на самом деле решает, что эти люди являются владельцами этой конкретной проблемы? Верно. Итак, у нас есть несколько источников данных для этого. Так, конечно, кодовая база, верно, если это источник истины, верно, если кто-то коммитил в этой области кодовой базы, это хороший сигнал. Очевидно, у нас есть несколько других источников данных, где мы вручную говорим: "Я владелец опыта X, поэтому я хочу, чтобы все проблемы приходили ко мне, чтобы я мог их исправить или соответствующим образом отсортировать". Итак, у нас есть много источников этого, и вы можете видеть здесь, что он дал 3 владельцев, что, вероятно, не идеальный способ, которым мы бы это разделили. Но мне нравится, что мы можем фактически зайти и увидеть, что происходит, потому что мы также должны отлаживать нашу фактическую инженерную систему для: "Хорошо, вы говорите, что здесь должно быть 3 владельца. Это, вероятно, не идеально. Хорошо, теперь мы можем фактически увидеть полный журнал для этого агента, что произошло? Отладьте это и выясните, как мы можем уменьшить это, чтобы не было проблемы с несколькими владельцами. Да, и он также очень хорошо находит дубликаты проблем и идентифицирует их. И мы можем видеть это как на стороне автоматизации, так и на стороне человека, который заходит в проблему. Итак, это введено нашим расширением Chrome, которое мы используем внутри нашей команды. Так что это не функция GitHub, а скорее то, что мы хотели бы иметь в качестве функции GitHub. Так что мы сделали это сами. Так что это позволяет нам дедуплицировать различные проблемы. И мы используем ИИ, он работает каждый час, я думаю, с последним набором проблем GitHub и пытается сопоставить дубликаты. Если бы он был уверен, он бы просто автоматически закрыл это как дубликат, чтобы опять же, наша команда сосредоточилась на том, чтобы не сортировать 20-30-40 проблем, которые имеют одну и ту же первопричину. Мы можем сосредоточиться на том, что важно, и это сэкономило массу времени нашей команде. Ну, да, и это очень, звучит просто, как просто пометить вещи как дубликаты. Но есть так много проблем, что вы не можете просто с помощью лексического поиска немедленно найти точную же проблему. И вот что круто: этот рабочий процесс фактически изучает все проблемы, весь текст в них. Это не просто сопоставление ключевых слов, но и семантическое понимание проблем и того, как они все связаны. Абсолютно. И, я имею в виду, здесь это было, как я случайно выбрал. Это отличная проблема, верно? Это очень подробно. Она предполагает, что автор думает, что мы должны делать, но есть много вещей, которые мы не получаем, которые имеют такую детализацию. Так что для фактического дедупликации требуется гораздо больше усилий. И да. Вы упомянули, что это не было нативной функцией в GitHub. И я на самом деле думаю, что одна крутая вещь, на которую я надеюсь, это то, что в результате нашей работы как одного из крупнейших в мире проектов с открытым исходным кодом и имея этот огромный поток и необходимость переизобрести нашу инженерную систему, я думаю, надежда на самом деле заключается в том, что, знаете ли, мы попробуем много вещей, которые не работают так хорошо. И вещи, которые работают, я хотел бы увидеть, как они вернутся в GitHub в качестве платформенной конструкции, верно? Нет причин, по которым эта детекция дубликатов не должна быть чем-то, что есть в GitHub. Верно. И вся эта работа основана на многих работах, предлагаемых GitHub, на многих инструментах агентурных рабочих процессов, которые выходят из GitHub, чтобы мы могли обрабатывать эти проблемы с помощью ИИ, не опасаясь, что будет какая-то инъекция подсказок из проблемы или любые другие виды опасений. Много внимания уделяется фактическому запуску ИИ на недоверенных проблемах от сообщества. Так что многое из этого мы построили, и многое, я думаю, мы могли бы поделиться. Мы также, как я сказал, заботимся о здоровье нашего конвейера, чтобы мы понимали, что все наши автоматизации работают так, как мы ожидаем. Итак, это все наши, я просто выбрал те, которые являются заданиями Cron, заданиями Cron здесь. Те, которые я покажу дальше, это эти три конвейера ошибок. Итак, я показал вам, как мы делаем автоматическую сортировку. У нас есть много информации, которую мы можем вывести из отдельной проблемы GitHub. А затем есть много того, что фактически выполнимо, и нам не нужно, чтобы человек тратил полдня на работу, если есть четкий способ воспроизвести ошибку, четкая цель. Итак, мы запускаем это время от времени, много раз в день, которое проходит через всю нашу телеметрию, и я покажу небольшой предварительный просмотр нашей страницы ошибок. Итак, это проходит через любую необработанную ошибку, и есть несколько других способов, которыми мы можем ее нарезать, и она проходит и пытается определить первопричину. Если она может определить какую-то причину, она выполнима, она создаст проблему GitHub для нас. А затем я сейчас внедряю способы, которыми опыт здесь может исправить ошибку для вас и пометить правильного владельца, что очень круто, верно? Потому что мы, я, я только что нашел эту случайным образом пять дней назад. Это была ошибка, которую наш бот нашел, прошел через нее и поделился стеком. Здесь действительно нет других данных, которые у нас были из нашей телеметрии. И я просто заглянул и увидел, что он прошел и фактически исправил это для нас, верно? Это была регрессия с мая, которую мы обнаружили. Она объяснила нам, что это было как бы Осмальдо. О нет, прости, дружище. Да. И она, и она прошла, и я думаю, что интересная часть этой ошибки заключается в том, что вы можете видеть из этой приятной диаграммы здесь, что фактическая ошибка охватывала несколько различных процессов в VS Code, хост расширений, и она проходила до основного потока. Есть своего рода обмен данными туда и обратно, сериализация данных, которая вызывала ошибку. И она смогла отступить и понять последовательность событий, которые вызывали исключение, а затем фактически исправить это для нас, верно? Итак, она определила файлы в различных частях кодовой базы, в различных процессах и смогла предложить исправление для нас. И оно было принято Робом, так что я уверен, что оно было отличным. Роб подтвердил, что все хорошо. Роб знает все, но это круто. Это как полный цикл, верно? Итак, у нас есть проблема, верно? Она появляется на нашем сайте ошибок из нашего рабочего процесса, о котором мы только что говорили. Проводится первоначальное расследование. Мы открываем проблему с этим расследованием. А затем, если, если Copilot думает, что он может справиться с этим, как он сделал в этом случае, то он проактивно предлагает исправление. А затем, знаете ли, вы видели, что у нас есть, знаете ли, десятки миллионов пользователей, использующих BS Code каждый месяц, как именно. Есть, есть много мелких вещей, которые могут возникнуть. И, знаете ли, раньше, если это не было чем-то серьезным, было трудно расставить приоритеты для этого. А теперь это просто происходит автоматически в фоновом режиме. Абсолютно. И, я имею в виду, мы все еще очень маленькая команда, верно? Да. Как у нас нет, да, 100 инженеров, работающих над этим. Точно, мы около 40 человек. Я думаю, люди думают, что мы. Тысяча человек в организации, абсолютно. Да, мы нет. Так что у нас нет времени в сутках, если мы работаем 24 часа, чтобы исправить все эти ошибки. Нам действительно нужен ИИ, чтобы сделать продукт стабильным. Да. Последнее, о чем я хотел бы поговорить, это да, еженедельные выпуски были огромными для нас. Это был большой сдвиг в том, как мы разрабатываем, как мы общаемся. Это было приятно. Мы только что увидели обновление. Так что это живые данные с нашего сервера обновлений, который каждый день, когда вы открываете, скажем, Insiders, каждую неделю, когда вы открываете стабильную версию, вы получаете обновление. И это те же данные, которые фактически управляют сервером обновлений. Так что вы можете видеть все версии VS Code, которые мы фактически выпустили. Вы можете видеть развертывание. Мы теперь делаем поэтапные развертывания, как бы медленно, чтобы мы могли наблюдать их эффекты в реальном мире, потому что, конечно, в Insiders и от нас, использующих продукт, это, конечно, очень отличается от всего мира, использующего его из 40+ миллионов пользователей. Вы можете видеть версию, которую мы активно развертываем, а затем версию, которую мы активно разрабатываем. Итак, да, эта страница растет каждый день, и, как и типы данных, которые мы представляем. У нас есть целый набор инструментов для понимания кода, который мы развертываем, и для того, чтобы сделать его действительно легким для просмотра. Это было заморожено на крошечный промежуток времени из-за проблемы после того, как мы достигли 8%, верно? Так что мы смогли быстро уловить что-то, прежде чем оно стало проблемой для большинства людей, верно? Так. И мы, инкрементальное развертывание — это, по сути, новая для нас вещь. Раньше мы просто выпускали на 100%, верно? Полностью, да. И мы, да, мы встроили процесс поэтапного развертывания и возможность замораживать сборки, чтобы откатываться к предыдущим сборкам, все на нашем сайте сборки, который мы использовали некоторое время. Но это значительно выросло, поскольку потребности, которые мы видели, расширились. Итак, да, возможность начинать развертывания, замораживать, выполнять конкретное развертывание для конкретной версии кода поэтапно, многие из этих нюансов, о которых нам никогда не приходилось по-настоящему думать, а теперь мы думаем, и мы создали много инструментов вокруг этого. Круто. Да. Так что это, я думаю, большая часть наших изменений в процессе. Конечно, как я уже сказал, есть гораздо больше, которые я не осветил, и есть гораздо больше пугающих диаграмм, которые я также не осветил. Но да, для наших следующих докладов, возможно. Да. Я имею в виду, я думаю, что, знаете ли, командам легко не отдавать приоритет такой работе, но в нашей команде это буквально работа людей, верно? Это создание этих систем, потому что если бы у нас не было этих вещей даже до ИИ, это было бы страшно, верно? И теперь, когда мы все движемся быстрее, в системе, очевидно, гораздо больше риска. Так что вам действительно нужно приложить сознательные усилия, независимо от того, насколько трудно, чтобы инвестировать в ваши инженерные системы. И это то, что я всегда ценил в команде BS Code. Хорошо, на последние несколько минут, поскольку у нас осталось всего 5 минут, я хотел быстро поговорить о некоторых изменениях в нашей модели сотрудничества в команде. И поэтому я думаю, что есть эта интересная вещь, которая, знаете ли, когда я впервые присоединился к Microsoft, я писал квартальный план или шестимесячный план. И я просматривал наш годовой план, верно? А затем это стало: "Хорошо, вам нужно составить ежемесячный план". А затем это стало: "Хорошо, вам нужно составить еженедельный план". А в некоторых случаях и ежедневный план, потому что циклы доставки настолько сжаты. И, конечно,
С ИИ, есть соблазн. Вы можете буквально сделать что угодно, верно? Мы можем добавить любую функцию в VS Code, но проницательность, чтобы добавить правильный набор функций в VS Code, очень сложна. И особенно даже при нашем размере, 40 человек, если вы знаете 40 человек, управление командой такого размера сложно. И тогда, если каждый суперзаряжен ИИ, это становится собственным риском, верно? И поэтому, как мы раньше работали, я не знаю, все ли вы заходили в репозиторий VS Code. Мы закрепляем наш ежемесячный план, он имеет назначенных владельцев из нашей команды. У нас есть проблемы, и они ссылаются на разные вещи с более подробной информацией. И поэтому то, как это работало до ИИ, заключается в том, что руководители в основном говорили: «Хорошо, вы знаете, мы думаем, что нам нужно добавить XYZ, пространство движется в этом направлении». Так что у вас есть своего рода настройка сверху вниз, а затем, очевидно, люди, которые ближе всего к работе, верно, работающие над отдельными функциями, имеют наборы вещей, которые, как я думаю, действительно важны. У нас это было. И поэтому во время нашей игровой недели, которая является неделей, когда мы проводим тестирование, планирование на следующую неделю, именно тогда мы фактически сверяем все эти вещи, прежде чем составить план, который вы все увидите в следующий понедельник. Так что это был своего рода наш процесс, и у вас были области, вы знаете, я работаю над рабочей областью. Так что вещи из рабочей области поступают, или я работаю над чатом, и поэтому чат-вещи здесь, агенты — это MCP, и у вас были бы эти предсказуемые разделы, которые оставались бы в плане месяц за месяцем. Но я думаю, как я уже говорил, вся эта модель сломалась для нас, потому что ИИ движется так быстро, верно? Вы знаете, если кто-то спросит меня, я думаю, у нас есть видение в направлении, но я не могу точно сказать вам через три месяца, какая именно функция будет выпущена в VS Code. Это больше не так работает, верно? Наши жизненные циклы доставки настолько сжаты, что это просто не работает. Так что это проблема согласованности. Я уже упомянул, как вы можете удержать 40 человек в согласованности, когда они все движутся быстрее, а затем сжатый жизненный цикл доставки. И поэтому действительно сложная вещь заключается в том, как вы можете убедиться, что ваше суждение по-прежнему применяется во всем этом процессе, чтобы вы не просто добавляли случайные вещи в свой продукт, потому что можете, а фактически применяли это. И поэтому, по сути, то, что мы знали, что нам нужно сделать в команде, это полностью изменить, как работает вся наша модель сотрудничества и планирования. И поэтому, вместо того, чтобы иметь эти долговечные, я работаю над этой вещью, и я всегда работал над этой вещью как над областью владения моим кодом, у нас есть рабочие потоки. Так что у нас все еще есть своего рода верхний и нижний уровни, но у нас есть вещи, такие как: для сборки мы запускаем эту новую модель кодирования Mai. Нам нужно убедиться, что у нас есть отличный опыт работы в продукте. Подсказки настроены, инфраструктура хорошая. Хорошо, давайте буквально создадим группу людей, которые сосредоточатся на этой проблеме на неделю или две, или на веб-сайте или документах, даже на таких вещах, которые нуждаются в обновлении. Хорошо, какова цель для этого? Давайте создадим что-то для этого. И поэтому у вас есть эти временные рабочие потоки, которые создаются и разбираются в зависимости от приоритета. У каждого есть ADRI, этот человек отвечает за планирование работы в этой области. Каждая из этих групп встречается, в некоторых случаях ежедневно, иногда несколько раз в неделю, в зависимости от темпа рабочего потока. И поэтому именно так мы остаемся в согласованности. Вы разбиваетесь на группы по два или три человека, встречаетесь утром, говорите, что нам нужно сделать сегодня? Вы работаете весь день, снова встречаетесь днем, возможно, асинхронно. И вы говорите, вот чего мы достигли. И поэтому, мы не знаем, сработает ли это для нас. Мы два месяца исследуем это. Я думаю, это сделало нас намного более гибкими. Это создало другие проблемы, верно? Потому что, если мы создаем эти рабочие потоки, которые мы постоянно создаем и разбираем, то это, очевидно, создает свои собственные проблемы, с которыми мы также справляемся. Так что, да, нам действительно пришлось полностью переосмыслить, как мы планируем VS Code и доставляем вам функции, из-за ИИ. Да. Я думаю, последнее, что я хочу вам сказать, это то, что многие из этих выступлений будут говорить: вы должны использовать лучший ИИ. Вы должны, верно? Все мы чрезвычайно увлечены ИИ в команде VS Code. Но вы также должны учитывать: хорошо, что произойдет, если я добьюсь успеха с ИИ? Вам придется изменить способ работы вашей команды. И мы были рады, что смогли поделиться несколькими стратегиями, которые работают для нас в команде VS Code, но мы будем здесь после выступления. Так что мы будем рады услышать о ваших историях и любых предложениях, которые у вас есть для нас. И мы, безусловно, можем поделиться извлеченными уроками. Так что спасибо, что пришли на наше выступление. Спасибо. Вау, это было прямо в точку. В точку.