Como o VS Code passou de lançamentos mensais para semanais com IA — Harald Kirschner

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How VS Code Went from Monthly to Weekly Releases with AI — Harald Kirschner · Canal: AI Engineer · 19:33 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

Harald Kirschner explica como o VS Code passou de um ciclo de lançamentos mensal para semanal usando agentes de IA em todo o processo de desenvolvimento, e não apenas para escrever código mais rápido. A equipe melhorou a preparação do repo para agentes, os ciclos de feedback de interface e o code review, além de automatizar a triagem de issues e a correção de erros. Também adotou lançamentos graduais, evals do produto e protótipos para aprender mais depressa e reduzir riscos. A ideia central é melhorar continuamente o sistema e seus ciclos de feedback para entregar software com mais velocidade e qualidade.

Pontos-chave

A proporção de código escrito por agentes que é efetivamente commitado subiu de 55% com GPT 4.1 para 86% com Claude Opus 4.6, acompanhando melhorias no harness e nos modelos.
O aumento de velocidade trouxe mais issues e pull requests; ao mesmo tempo, também cresceram as contribuições da comunidade que são integradas.
Documentação do repo e skills com conhecimento especializado ajudam agentes e ampliam a participação de pessoas que não são especialistas em cada área.
A migração para TypeScript Go acelerou os builds em dez vezes, reduzindo um gargalo que se acumula quando muitos agentes executam tarefas em paralelo.
O component browser e o uso de Playwright permitem inspecionar mudanças visuais e validar a aplicação em ciclos de feedback automatizados.
A equipe usa IA para filtrar, enriquecer, traduzir e encaminhar issues, além de combinar telemetria e agentes para identificar e corrigir erros.
Lançamentos graduais ajudam a reduzir o risco, pois reverter uma versão já instalada é custoso.
O VSC bench permite ampliar os evals com cenários vindos de issues e acompanhar melhorias offline e em experimentos online.
Protótipos e sprints diários ajudam a discutir ideias e obter feedback antes de transformar uma proposta em uma mudança no produto.

Capítulos

Início	Capítulo	Resumo
00:12	Da cadência mensal à semanal	Harald apresenta a mudança no ciclo de lançamentos e explica como o uso de agentes afeta o desenvolvimento e a operação do VS Code.
03:18	Acelerar o desenvolvimento sem perder qualidade	A palestra organiza o desafio em escrever código mais rápido, revisar com qualidade e aprender para decidir o que deve ser lançado.
04:53	Preparar o repo para agentes	Documentação, skills e melhorias de build ajudam agentes e mais integrantes da equipe a trabalhar no repo.
08:30	Ciclos de feedback para a interface	O component browser e a automação com Playwright ajudam a detectar mudanças visuais inesperadas e verificar correções.
11:08	Code review, triagem e correção de erros	A equipe combina code review automatizado, triagem de issues, análise de telemetria e agentes para encontrar e corrigir problemas.
15:25	Lançamentos graduais e evals	Lançamentos em etapas reduzem riscos, enquanto o VSC bench permite testar cenários e acompanhar o comportamento do produto.
17:29	Prototipagem e melhoria contínua	Protótipos e sprints curtos aceleram as conversas sobre o produto, e a equipe busca continuamente o próximo gargalo.

Citações

Passamos de um lançamento mensal para um ciclo semanal graças à IA. — 00:12

Não se trata de usar mais IA no dia a dia; trata-se de evoluir o sistema inteiro de entrega de software. — 03:18

Se o agente não consegue usar sua aplicação diretamente para obter feedback, esse é um investimento que compensa. — 08:30

Não ajuste apenas como você trabalha com agentes; ajuste como eles recebem feedback. — 18:31

Conceitos e entidades

VS Code (ferramenta): Editor de código cuja equipe adotou um ciclo de lançamentos semanais e processos de desenvolvimento apoiados por agentes.
Harald Kirschner (pessoa): Integrante da equipe do VS Code que apresenta as mudanças no processo de desenvolvimento e lançamento.
GPT-4.1 (modelo): Modelo citado como ponto de partida para a métrica de código escrito por agentes que acaba commitado.
Claude Opus 4.6 (modelo): Modelo citado junto à medição mais recente de código escrito por agentes que acaba commitado.
TypeScript Go (ferramenta): Tecnologia cuja adoção, segundo a palestra, acelerou os builds do projeto em dez vezes.
Playwright (ferramenta): Ferramenta usada para automatizar interações com o VS Code e validar cenários na aplicação.
Xcode MCP (ferramenta): Ferramenta mencionada para criar, abrir e testar aplicativos iOS, incluindo cliques e capturas de tela.
GitHub Copilot (ferramenta): Ferramenta citada por seus recursos de code review automatizado em pull requests.
VSC bench (conceito): Conjunto de evals do produto usado para testar cenários de uso de agentes no VS Code.
component browser (ferramenta): Processo automatizado que captura componentes do VS Code e destaca diferenças visuais entre versões.

Tradução completa (pt-BR)

00:12 Olá, pessoal. É difícil falar depois dessa apresentação. Por que todo mundo foi embora? Não. Esta é a reprise de uma palestra que ela deu ontem, lá em cima. Então esta vai ser melhor do que a de ontem. Parabéns por terem vindo assistir a esta. Trabalho no VS Code, e passamos de um ciclo de lançamento mensal para um semanal graças à IA. Vou falar sobre o que aprendemos e sobre os sistemas que tornaram isso possível — não só para lançar mais rápido, mas para lançar com mais eficácia.

00:43 Então, não vou falar sobre como criamos agents no VS Code — vocês podem testar isso quando quiserem. Podem passar pelo estande e nos ver demonstrando agents. Vou falar sobre como usamos agents para criar o próprio produto. E isso inclui o VS Code, o Copilot e outras áreas, mas também como, quando vocês usam agents e mais IA, as coisas começam a dar errado e é preciso repensar a forma como se trabalha. E tudo isso com uma equipe bem pequena, que atende mais de 50 milhões de usuários. O que aconteceu ao longo do último ano foi:

01:15 Começamos a acompanhar, bem cedo, métricas de sobrevivência do código no VS Code. Isso significa a porcentagem de código escrito por agents que realmente acaba em um commit. Quanto lixo o agent produziu, que vocês jogaram fora ou em que não confiaram, que leram e descartaram? O GPT-4.1 começou em 55%. Mas, com o tempo, as melhorias no harness e os novos modelos, o Claude Opus 4.6 chegou hoje a 86%.

01:46 Esse aumento mostra claramente que os desenvolvedores confiam mais e se sentem mais seguros para lançar código gerado por IA mais rapidamente e em maior quantidade. Esse sucesso criou problemas para o VS Code. Somos um dos maiores — ou o maior — projeto open source no GitHub. Por isso, vimos um aumento enorme de issues, porque a IA ajuda a abrir issues. Então, vemos um aumento de issues de qualidade, mas também o outro lado: mais issues de baixa qualidade automatizadas. Também

02:17 vemos mais PRs abertos pela equipe, graças à nossa própria velocidade, e pela comunidade. E o interessante é que todo mundo presumiria que veríamos um monte de PRs inúteis, mas, na verdade, o número de PRs da comunidade que são integrados também está aumentando. É incrível que possamos viabilizar mais contribuições da comunidade. Como parte desse novo workflow, há vários meses passamos de lançamentos mensais — um modelo que durou mais de 10 anos. Desde o lançamento do VS Code 1.0, temos

02:48 lançado uma nova versão do VS Code todos os meses. Isso inclui curiosidades, como a versão de janeiro, que na verdade é lançada em fevereiro. Então, quando leem as notas da versão do VS Code, vocês se perguntam por que é fevereiro e estão lendo as notas da versão de janeiro, se estiverem um mês atrasados. Não, é só assim que acompanhávamos nossas iterações. Esse ritmo acompanhava nossa velocidade, mas também nos mostrou que não se trata de usar mais IA no trabalho

03:18 do dia a dia, como muitas empresas defendem. Não se trata de maximizar o uso de tokens. Não é preciso passar todos os dias usando IA. Trata-se de evoluir o sistema como um todo, de mudar a forma como lançamos software para aproveitar melhor a IA em todo o processo. É isso que permite alcançar essa velocidade sem simplesmente gerar mais código. Vou dividir isso em partes. A primeira é algo que muita gente já vem vivenciando: vejo código sendo lançado mais rápido, e essa é a parte fácil. Você tem esses engenheiros 100x que criaram um

03:50 belo sistema de plugins com skills e MCP e estão lançando código a todo vapor. Aos poucos, talvez mais pessoas da equipe adotem os mesmos padrões, e você vê muito mais código sendo lançado mais rápido. Mas o problema é que, quando você lança mais rápido, precisa fazer code review. É preciso descobrir como lançar código de alta qualidade que não fique quebrando o tempo todo. Isso é importante para nós no VS Code. Lançamos binários nas máquinas dos usuários. Então, se algo quebra, a recuperação custa ainda mais.

04:22 Mas, depois que você alcança essa velocidade e consegue lançar código de alta qualidade mais rápido e com confiança, como sabe se está lançando a coisa certa, ou se deveria lançá-la? É aí que a IA entra: para, no fim das contas, aprender mais rápido e criar produtos melhores. Muita gente deixa isso de lado quando começa a escrever mais código: aplicar o próprio senso de produto e aprender com o processo. Então, vamos começar a lançar mais rápido. Agora que todo mundo pode fazer vibe coding, todos podemos

04:53 lançar mais rápido. Uma parte importante disso é preparar seu codebase. Esse é o slide óbvio que todo mundo já deveria conhecer: pensar em como deixar os codebases prontos para agents, criando arquivos agents.md leves o suficiente e que deem aos agents um bom mapa do codebase, indicando onde procurar. Mapeie o que for necessário. Assim, cada agent fica ao alcance de vocês, com um slash command que gera um bom rascunho, e então vocês continuam iterando. São documentos vivos

05:24 que devem evoluir à medida que o agent comete erros e trabalha. É aí que vejo muitas equipes que investiram na experiência do desenvolvedor ganharem bastante, porque, quando têm boa documentação e um bom processo de integração para um codebase, o agent também consegue ler esse material, que pode ajudá-lo muito. Em seguida, temos as skills. O VS Code sempre investiu bastante em acessibilidade. Uma das primeiras skills que adicionamos reunia as melhores práticas de acessibilidade e nossa forma de pensar sobre o tema

05:54 em uma skill que todos poderiam usar. Antes, era preciso chamar uma pessoa para participar ou dar feedback; agora, essa skill foi revisada e é mantida pela pessoa responsável pela área de acessibilidade. Assim, colocamos essa acessibilidade, que deve funcionar em todos os lugares, nas mãos de todo mundo. Pensem em como codificar seu conhecimento especializado para que algumas pessoas que sempre são chamadas a dar esse tipo de opinião possam compartilhar esse conhecimento por meio de uma skill. E, por último, quando

06:26 vocês fazem isso direito, nosso teste decisivo no VS Code é: eu, como PM, consigo fazer vibe coding com eficácia no repo do VS Code — e faço isso — e como a engenharia recebe esse trabalho? Quanto trabalho isso dá? Funciona de imediato? Funciona localmente para mim? Ou acaba quebrando quando eu faço o deploy? Muitas dessas melhorias de qualidade vão mostrar, no fim, que vocês podem permitir que todo mundo

06:57 seja mais eficaz no repo. Outra melhoria, e essa é enorme, foi a migração para TypeScript Go. Se vocês já trabalharam em qualquer codebase de desenvolvimento que demora para compilar, executar a verificação de lint ou rodar CI/CD, sabem como isso já é irritante. Mas os desenvolvedores encontram outras maneiras de contornar o problema. Podem fazer code review de um PR. Podem mudar o foco para outra coisa enquanto o processo roda e, depois, fazer outra coisa. Mas, quando isso acontece com agents — vocês têm 10 agents, 20

07:28 agents rodando e esbarrando no mesmo gargalo — qualquer parte lenta do CI/CD acaba causando um efeito cumulativo. Para nós, o TypeScript Go trouxe uma melhoria de 10 vezes no tempo de compilação. Na escala de PRs automáticos executados por agents, que precisam corrigir problemas e dependem desse ciclo de CI/CD para receber feedback e melhorar o código, isso é uma melhoria enorme. E isso me leva a abrir PRs grandes.

07:59 Foi no começo do ano que abri um PR para criar a ferramenta de fazer perguntas, algo de que, na minha opinião, realmente precisávamos. Depois, levei a ideia para a equipe e mostrei para que pudessem experimentar no produto. Em poucas semanas, tínhamos uma experiência perfeitamente polida e projetada, baseada no meu PR inicial, que era bem improvisado. Mas isso destravou as discussões e a participação de todo mundo, porque já tínhamos estabelecido a base, e a ideia e a experiência estavam claras.

08:30 Em seguida, quando os agents trabalham na interface, todos já passamos por isso: o agent cria uma interface e diz que está perfeita; aí você abre e está tudo desalinhado. Mesmo com SVG e com os modelos mais recentes, isso ainda acontece. E é a principal coisa que vivo dizendo a todo mundo hoje em dia: se o agent não consegue usar seu aplicativo, seu produto diretamente, para fechar esse ciclo de feedback e verificar se está tudo funcionando, então investir nisso é algo que vale muito a pena sempre que você trabalha na interface.

09:02 E há duas áreas nas quais investimos. Uma é o navegador de componentes, que é uma compilação automatizada executada sempre que algo muda no VS Code. Deixe-me abrir este issue como exemplo. Neste caso, adicionamos um botão Voltar à nossa tela de personalização. E, como isso afeta várias partes, temos um processo automatizado nos bastidores que captura imagens de cada componente do VS Code e aponta as diferenças.

09:33 Isso nos permite detectar mudanças inesperadas, como quando alteramos um componente como efeito colateral de alguma outra coisa se mover, ou quando outro ícone desaparece. Também permite revisar rapidamente um PR, porque você tem acesso direto a uma visualização do que o PR está realmente fazendo. E é isso que pedimos a cada desenvolvedor: antes de tudo, que anexe pelo menos um vídeo ou uma captura de tela do que implementou, para não precisarmos executar tudo do zero e podermos avaliar rapidamente, dar feedback e… Agora, isso é automatizado com o explorador de componentes.

10:07 Em seguida, temos o ciclo de autocorreção, porque no VS Code executamos um navegador da web e abrimos um site. Basicamente, é isso que o VS Code é: tudo é HTML. Na verdade, podemos usar Playwright para automatizar muita coisa no navegador. Então, temos uma skill /launch que simplesmente abre o VS Code e apresenta um cenário específico para percorrer no VS Code. É uma forma muito poderosa de diagnosticar problemas, porque você também pode obter os logs ao longo do caminho e validar quaisquer correções que tenha feito antes e

10:37 depois, sem precisar clicar em tudo. Então, você pode simplesmente iniciar com launch, passar para a próxima tarefa e voltar depois que o agent verificar que funcionou, porque ele consegue acessar seu aplicativo. E vale destacar que isso é ótimo porque temos Playwright e somos um aplicativo da web executado no Electron, mas há muitas outras soluções disponíveis. Uma das minhas favoritas é o Xcode MCP, porque, no meu caso, trabalho com aplicativos iOS. E quando você vê o Xcode MCP criando algo no VS Code, sem envolver o Xcode, simplesmente criando um…

11:08 aplicativo iOS, abrindo-o, clicando nele e fazendo capturas de tela… Esses momentos são mágicos e também proporcionam um ciclo de feedback muito rápido. Há outras ferramentas disponíveis para Android que permitem fazer isso. Vamos falar sobre revisão de código, que, na minha opinião, é o próximo grande investimento. Sabemos que, no passado, quando habilitamos a revisão de código no GitHub, não estávamos convencidos com o GitHub Copilot automatizado. Mas, nos últimos meses e semanas, ele melhorou muito e agora é obrigatória uma revisão sempre que alguém…

11:38 abre um PR. E, na verdade, estão chegando mais melhorias para ajustar o esforço dedicado à revisão de código conforme o nível de risco neste repo. Assim, há níveis de esforço baixo, médio e alto para a revisão de código, para que você também possa ajustar o equilíbrio entre custo e benefício. Mas, para nós, quando uma revisão é concluída, as pessoas não olham para o PR até que todos os comentários tenham sido resolvidos e atendidos. Certo, agora estamos segurando… Estamos lançando mais rápido. Precisamos manter a qualidade. E um grande indicador para nós, já que estamos no…

12:10 GitHub, são, claro, os issues. Quem já abriu um issue no GitHub? Quem já teve problemas com o VS Code? Sim, legal. Mais ou menos o mesmo número. Ótimo. A plateia anterior levantou menos mãos, então isso é bom. Sim. É um indicador muito bom. E, como eu disse, às vezes recebemos issues ainda melhores por causa da IA e porque mais pessoas, com diferentes idiomas como língua de origem, conseguem abrir issues muito bons. Mas também recebemos muitos issues. Antes, os engenheiros faziam a triagem manualmente. Agora, a IA faz…

12:42 a filtragem para remover spam, enriquecer e, por fim, traduzir, além de atribuir responsáveis pelas áreas a todos os issues, para melhorar a relação entre sinal e ruído. Também adicionamos uma camada humana a esse processo, porque o agent cometerá erros quando estiver lidando com um issue, e precisamos desse ciclo de feedback quando isso acontecer. Criamos uma extensão do Chrome que também permite corrigir issues duplicados. Assim, deixamos o agent fazer o trabalho e temos um ciclo de feedback em que as pessoas ainda podem corrigir os erros, e podemos incorporar isso ao…

13:14 trabalho inicial do agent. É muito importante pensar nisso quando os agents fazem o trabalho: você também precisa obter o feedback das pessoas. Outra entrada que temos são muitas pilhas de erros. Sempre que ocorre uma exceção — e isso acontece na maioria dos aplicativos —, uma pilha de erros é reportada. Na verdade, não usamos nenhuma ferramenta externa para isso. Tudo fica nos nossos próprios dados, e criamos todas as ferramentas em torno disso. Na maior parte, já tínhamos tudo. Já tínhamos um modelo de ML fazendo a classificação, e agora isso é feito com uma combinação de critérios.

13:48 Primeiro, coletamos a telemetria bruta. Filtramos os dados — são cerca de 51 bilhões por dia — até ficarmos apenas com as pilhas de erros que realmente têm a pilha completa. Depois, agrupamos e organizamos em categorias. Isso é mais um exercício de identificação por impressão digital. E, no fim, depois de tudo isso, temos 10 issues abertos e atribuídos a responsáveis por áreas específicas, com um PR criado automaticamente para tentar corrigir o problema. Esta é a nossa página de erros, onde vemos todas as pilhas, incluindo o número de ocorrências e…

14:18 o número de usuários afetados, para podermos reagir rapidamente a qualquer coisa que surgir. E, quando isso está funcionando, um issue é aberto e um PR é criado automaticamente. Este é o issue. É o erro, com um diagnóstico inicial. Depois, o PR é aberto, e o agent investiga por que isso acontece e quem foi responsável. Neste caso, alguém adicionou uma alteração relacionada a encontrar símbolos e, então, ele…

14:50 percebeu que a solicitação de cancelamento não estava no protocolo RPC. Então, o agent já abriu o PR, e nós só precisamos fazer o merge. Essa é uma forma automatizada excelente: você não quer se preocupar com erros, só quer uma base de código mais estável. Assim, todo esse processo é automatizado: a triagem inicial combina agents e sistemas determinísticos; depois, o issue é aberto e encaminhado a um agent no sistema multi-agent de PR; e, no fim, as correções são incorporadas, na maioria das vezes automaticamente, com alguma supervisão humana para ainda aprovar o PR.

15:25 Pronto. Antes, o VS Code fazia lançamentos no estilo YOLO: no dia do lançamento, tudo estava estável. Fazíamos os testes e disponibilizávamos a versão para 100% dos usuários. Simplesmente abríamos as comportas. Mas, por causa dos agents, queremos reduzir os riscos desse processo. Provavelmente deveríamos ter feito isso antes. Então, agora fazemos lançamentos em etapas e, durante a implantação, monitoramos os logs de erros, os issues e todo o resto. Assim como bons cidadãos em um aplicativo da web, agora fazemos o mesmo, porque reverter uma instalação de aplicativo…

15:56 é muito caro. Certo, agora estamos lançando mais rápido e mantendo a qualidade. Como fazemos isso com a velocidade necessária para aprender mais rápido, que é o maior desafio com IA? Na verdade, você quer criar um produto melhor mais rapidamente. Um exemplo é o nosso VSC bench. Estamos lançando um produto com agents, então é importante termos sempre à mão as nossas próprias evals do produto e que seja muito fácil ampliá-las. Tudo fica no issue do GitHub. Tudo fica no GitHub.

16:26 Quando abrimos um issue para adicionar um novo cenário, um agent pega um modelo e prepara o cenário para você. Assim, facilitamos ao máximo a inclusão de todos os cenários de desenvolvimento que surgem nos issues, nas conversas com clientes e em todos esses canais, para trazê-los de volta às nossas evals. Depois, começamos a escalá-los e também confirmamos que tudo está melhorando offline e, em seguida, por meio de experimentação online. Então, esse é o ciclo de vida clássico de produto para nós, e…

16:58 ver essas coisas interessantes na nossa stack. Entender seus evals é fundamental. Um experimento que fizemos, sobre o qual você pode ler no nosso blog, foi propor um cenário de eval bem simples: apenas escrever um arquivo com “hello world”, só para testar nosso harness de eval de ponta a ponta e ver como diferentes modelos reagem. O mesmo arquivo de cinco caracteres fez o modelo mais caro usar 70 vezes mais tokens, e esse nem era o modelo de raciocínio avançado. Você pode ler mais sobre Unblock. Na verdade, não falamos sobre os modelos,

17:29 mas essa percepção de como seus modelos reagem ao seu harness é um exercício extremamente importante. Em seguida, temos a prototipagem, que faço bastante porque percebi que, na verdade, não quero incorporar a maior parte do meu trabalho aos PRs do próprio VS Code. É uma ótima maneira de iniciar uma conversa, mas, na maioria das vezes, quero ter uma conversa rápida, porque agora nos reunimos diariamente e queremos ter ciclos de feedback muito rápidos: “aqui está a ideia, aqui está como ela poderia ficar”,

18:00 “e se fizermos assim?”. No dia seguinte, você volta com protótipos atualizados e continua essa conversa. O feedback chega muito mais rápido: passamos de um ciclo de lançamento mensal para sprints semanais e diárias, em que continuamos trabalhando nos problemas, e os protótipos possibilitam discussões mais aprofundadas sobre como a experiência deveria ser. Isso também significa que temos uma responsabilidade contínua pelo trabalho interno, como mencionei: sprints diárias, equipes menores, frentes de trabalho menores que realmente

18:31 priorizam e conduzem conjuntos menores de áreas para avançar mais rápido. Então, experimentem essas coisas, descubram quais são seus gargalos para entregar com mais qualidade, entregar mais rápido e aprender mais rápido, e encontrem e resolvam o próximo gargalo. E não ajustem apenas como trabalham com agents; ajustem também como eles recebem feedback. Como vocês constroem esses ciclos? Depois de terem esses momentos de sucesso, descubram como podem melhorar esse ciclo de feedback para o próximo momento em que algo estiver impedindo vocês de avançar ainda

19:02 mais rápido. É um ciclo iterativo constante em todos esses ciclos. É isso. Passem no estande do Code. Vai ser um prazer conversar agora. Caso contrário, boa programação. >> [aplausos]

19:33 [música]

Transcrição original

[00:12] Hey uh everyone. This is a hard tone to follow. Why did everybody leave? No. Um this is the rerun of a talk that she gave yesterday upstairs. So this will be better than the one yesterday. So uh kudos to you for catching this one. I’m working on VS Code and we move from a monthly release to a weekly release cycle thanks to AI. And this is about the things we learned, the systems that made this work, not just to ship faster, but actually to ship more effectively.

[00:43] So, it’s not about how we build agents into VS Code, which we can try out anytime. You can come by the booth and see us showing of agents, but this is about how we use agents to build the product itself. And that’s VS Code, that’s the copci and other areas, but also how as you use agents and more AI, things are breaking and you have to rethink actually how you work. And that’s a very small team shipping to over 50 million users. What happened is over the past year is

[01:15] we started tracking already early on this code survival metrics in VS code. So that means the percent of agent written code that actually gets committed. how much kind of garbage has the agent produced that you threw out the window again or didn’t trust and that you that you read it u and and scrapped. So GBD 4.1 started at 55%. But then over time and over improving the harness and new models cloud opus 4.6 is now today at 86%.

[01:46] And that increase clearly shows developer trust and confidence in shipping AI code faster and more AI code generated. And this success created problems on the VS code side. We’re one of the biggest or the biggest open-source project on GitHub. So we saw a massive increase in issues because AI helps to file issues. So we actually see an increase in quality issues but also the counterpart of more automated lowquality issues. We

[02:17] also see more open PRs by the team by our own velocity and by our community. And interesting part we actually see everybody would assume we see a lot of garbage PRs but actually the number of community merged PRs is going up as well which is really amazing that we can unlock more community contributions as well. And as part of this new workflow, we actually moved several months ago, we moved from monthly releases, which happened over 10 years. Since the inception of VS Code 1.0, we have been

[02:48] shipping a new version of VS Code on a monthly basis. Including fun facts like the January release actually ships in February. So when you read the release notes in VS Code, you’re wondering why it’s February and you’re reading the January release notes if you’re a month late. No, that’s just how we tracked our iterations. So that cadence was to match to velocity, but it also showed us that the it’s not about using more AI as you work

[03:18] dayto-day, which a lot of companies are pushing. Like you’re not token maxing. You’re not spending every day using AI. It’s about evolving the whole system, how you’re shipping software to evolve to actually make better use of AI along the whole process. And that what makes this velocity actually work and doesn’t just generate more code. I’m breaking this down into this first part which a lot of people have been experiencing. I see shipping code faster and that’s the easy part. You have like this 100x engineers that has built this

[03:50] beautiful skill MCP plug-in system and they’re just shipping code like crazy and slowly maybe more in the more people in the team uh adopt the same patterns and you see a lot more code shipping faster. But the problem is once you ship faster, you get into code review. You get into how do you actually ship high quality code that doesn’t constantly break. And that’s important for us as VS Code. We’re shipping binaries to user machines. So if something breaks, that recovery is even more costly.

[04:22] But once you hit that velocity with shipping high quality code faster with confidence, how do you actually know you’re shipping the right thing or if we should ship this thing? And that’s where AI kicks in to actually learn faster in the end and shipping better products which a lot of people are missing out as as they write more code is applying that product taste and applying that learning. So let’s start shipping faster. Now that everybody can vibe, we can really all

[04:53] ship faster. And it’s a big part is getting your codebasation ready. So that’s kind of the no-brainer slide that everybody should already been doing is thinking about how to get your code bases agent ready is creating agents.mmd that give it that are lightweight enough and give the agents a good kind of map of the codebase where to look at mapping out that is every agent now at your uh at your fingertips has a slash in it that gives you a good draft and then you keep itering those are living documents

[05:24] that should evolve as the agent makes mistakes and works. And that’s where I see a lot of teams that have invested in developer experience actually gain a lot because once they have good documentation and onboarding for a codebase that is read by the agent as well and that can help the agent as much. Next up you have skills. VS Code has always messed heavily in accessibility. So one skill we added early on was infusing all the accessibility best practices and how we think about

[05:54] accessibility into a skill that everybody will use and that previously was one person that had to then got get pulled in or give feedback and now that skill was reviewed and is maintained by the kind of area owner of accessibility. So to bring that that accessibility that short work everywhere into everybody’s hands. So think how you can encode your expert knowledge to unblock this like few users that might be always asked for this input into a skill. And lastly once

[06:26] you do it right for us in VS Code the litmus test is can I as a PM effectively VIP code in the VS code repo which I do um and how is that accepted by engineering? How much work does it cost? Is it out of the box working? Is it for me working locally? Or is it eventually breaking when I ship it? So, a lot of these quality improvements will show in the end that you can allow everybody to

[06:57] be more effective in the repo. Another improvement, and that’s a massive one, is we switched to TypeScript Go. And if you’ve been in any developer codebase that takes some time to build or run linting or run CI/CD, you’ve noticed it’s already annoying. But developers find other ways. They can review a PR. They can context switch into something else while runs and then do something else. But once you hit that with agents, you have 10 agents, 20

[07:28] agents running and hitting the same bottleneck, these any slow part of your CI/CD will compound. And for us, Typescript Go was a 10 times improvements in our builds, which at the scale of automatic PRs running with agents and them fixing getting needing that CI/CD loop for feedback to improve the code is a massive improvement. And that leads to me uh filing big PRs.

[07:59] That was beginning of the year to get the ask questions tool in which I believe we really needed and then bringing it to the team to show to let them try it out in the product. Within a few weeks we had a perfectly polished and designed experience based on my initially very scrappy PR. But it unblocked that this these discussions the participation of everybody else because we had the ground set laid and the idea and the experience was clear.

[08:30] Next up, when agents actually work on UI, and we all had this, that the agent gives you a UI and it says it looks perfect, then you open it and it’s all misaligned. Even with SVG, even with the latest models, you still get it. And it’s like the number one thing I keep telling everybody now these days. If your agent cannot use your application, your product directly to get this feedback loop of is it all working, then that’s a really big investment that pays off every time you work on UI.

[09:02] And there’s two areas we invested in. One is the component browser, which is an automated build that runs every time VS Code changes something. Let me open this in this issue as an example. In this case, we added a back button to our customization screen. And because it’s changing wide, we actually have this automated process in the back that takes screenshots of every component in VS Code and points out the differences.

[09:33] It allows us to detect unexpected changes like we’re changing one component as the ripple effect of something else moving or some other icon disappearing. and allows you to quickly review a PR as well because you also get directly a view and what the PR is actually doing and that’s what we ask every developer before we ask them to at least attach a video or screenshot on what they have been implementing so we don’t have to run everything from scratch and we can quickly assess and and give feedback and this is now automated with the component explorer

[10:07] next up we have the self-correcting loop because in VS Code we run uh a web browser and open a website. Basically, that’s what VS Code is. It’s all HTML. We can actually use Playright to automate a lot in the browser. So, we have a /launch skill that would just open up VS Code and give it a specific scenario to click through in VS Code. So, it’s a really powerful way to diagnose issues because you can also get the locks along the way, but also validate any fixes you did before and

[10:37] after without you having to click through it. So you can just hit launch move on to the next task and then come back once the agent verified it’s worked because it can access your application and to call out this is nice because we have playright and we are a web app uh running in electron but there’s many other solutions out there one of my favorites is Xcode MCP because on my site I work on iOS apps and once you see Xcode MCP just creating in VS code without Xcode involvement just making an

[11:08] iOS app opening it up clicking through it, taking screenshots. These moments are magical and give you a really tight feedback loop as well. So there’s other tools available for Android as well to make this work. Let’s talk about code review, which I think is the next big investment. We know in the past when we enabled code we on GitHub the automated GitHub copiloted one we’re not convinced yet but over the next months and weeks they have massively improved and now it’s a mandatory uh review every time somebody

[11:38] opens a PR and there’s more improvements coming actually dial in the uh the effort that a code review does depending on how much risk you have in this repo so you have a low medium high effort for code review so you can dial in kind of the cost benefit as well but for us is if a review after review is done, humans will not even look at PR until all the comments are resolved and and addressed. Okay, now we’re holding we’re shipping faster. We got to hold quality. And a big signal for us because we’re on

[12:10] GitHub is of course issues. Uh who has filed a GitHub issue? Who has had problems in VS Code before? Yeah, cool. Kind of similar. Awesome. This the last crowd had less hands up. So it’s good. Um, yeah. So it’s a massive, it’s a really good signal. And as I said, we get sometimes even better issues now because of AI and more people with different language backgrounds being able to file very good issues. But we also get a lot of issues. And previously engineers actually triage them manually. And now we have AI doing

[12:42] the filtering to get out spam enriching and translating in the end assigning area owners for all the issues to raise the signal to noise quality of this. We also add a human layer to that once you are in issue because the agent will make mistakes and we need that feedback loop when it makes mistakes. We create a Chrome extension that allows you to fix duplicated issues as well. So we have the agent doing the work and we have a feedback loop where humans can still fix it that we can bring back into the into

[13:14] the agent work up front. That’s a really important thing to think about as you have agents doing the work that you get the human feedback as well. The other input we have is a lot of error stacks. Every time there’s an exception and most apps will have this you get an error stack reported and we actually don’t use any external tool for that. It’s all in our own data and we built all the tooling around it and it’s mostly we already had it. We already had an ML doing sorting on top and this is now actually done by a mix of criteria.

[13:48] So one is we collect the raw telemetry. We filter it down and that’s like 51 billion per day. We filter it down to just error stacks that actually have the full stack. Then we group it and bucket it. That’s more of the fingerprinting exercise. And then in the end after we all of that we have 10 issues filed assigned to specific area owners that a PR is autocreated to actually already try to fix the problem. This is our error page where we see all the stacks including how many hits and

[14:18] how many users affected so we can quickly react to anything that’s coming. And once we have this working we get a issue filed and a PR automatically opened. This is the issue. is the error with some initial diagnosis and then the PR got opened with and the agent actually goes in and finds out why does this happen who was responsible in this case um added a change that was connected to this to find f find symbols and then it

[14:50] figured that the on cancellation request wasn’t in the RPC protocol so the agent already opened the PR we could just merge it and that’s a really great automated way you don’t care about errors you just want to get a more stable code base. So all of this automated the triage initially mix of agents and deterministic systems then the issue is filed handed off to an agent in the PR multi- aent system and in the end we have fixing fixes landing mostly automatically with some human oversight to still approve the PR.

[15:25] There you go. So previously VS Code did yolo releases in a way that it was release day everything was stable. We did our testing and we shipped the release to 100%. We just opened the floodgates but because of agents we want to derisk that process. We should have probably done it earlier. So now actually we do stage rollouts and as we do the roll out we monitor error locks and issues and everything else. So just like good citizens in a in an web application, we now apply the same because rollbacks on an install app are

[15:56] so expensive. Okay, now we have this shipping faster, shipping at quality. How do we actually do this in a in a speed that we actually learn faster, which is the which is a bigger challenge with AI? You actually want to build a better product faster. So one of the examples is our VSC bench. We’re shipping an agentic product. So it’s important that we have our own evals of our product always at hand and being really easy to extend. It’s all in the GitHub issue. It’s all in GitHub.

[16:26] When we file an issue to add a new scenario, it’s actually an agent picking up from a template and bootstrapping the scenario for you. So we make it as easy as possible to bring in all the developer scenarios that are coming up in issues through customer conversations through all these channels to bring them back into our emails. So we then start hill climbing actually against them and then com also confirm that it’s all improving offline and then an online experimentation. So classic product life cycle for um for us and we

[16:58] see these interesting things in our stack. Understanding your evals is critical. One experiment we did that you can read about on our blog is that we gave a very simple eval scenario of just write a file with hello world just testing out our eval harness end to end and how different models react. The same five character file took the most expensive model 70x more tokens and that was not the high reasoning model. You can read more about unblock. We actually don’t talk about the models,

[17:29] but just that insight in how your models react with your harness is extremely is a very important exercise. Next up, we have prototyping, which I do a lot of because I noticed that I don’t actually want to land most of my work into VS Code PRs itself. It’s a great way to start a conversation, but most often I want to have a quick conversation because now we’re meeting on a daily basis where we just want to have very quick feedback loops on here’s the idea, here’s how it could look like,

[18:00] what if we do this. Next day you come back with updated uh prototypes and you just keep having this conversation. So much quicker feedback from a month release cycle to weekly to daily sprints where you just keep working on problems and prototypes unlock those deeper discussions and how the experience should look like. It also means that we have the durable ownership in internal work as I mentioned daily sprints um smaller squads, smaller work streams that really

[18:31] prioritize and drive smaller sets um of areas to move faster. So try these things, find out where your bottlenecks are to actually ship higher quality, ship faster and learn faster and find fix that next bottleneck. And don’t just tune how you work with agents, but tune where how how do they get feedback? How do you build these loops? And then figure out after you have these these success moments, how can you improve that feedback loop for the next moment of what’s blocking you to move even

[19:02] faster and it’s a constant iterative cycle across all these cycle ones. That’s it. Come by code booth. Happy to chat now. Otherwise, happy coding. >> [applause]

[19:33] [music]