GitHub Universe — palestra de abertura do Dia 1

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: GitHub Universe Day 1 Keynote · Canal: GitHub · 52:27 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Cibersegurança e segurança de software, Ferramentas de desenvolvimento com IA

Resumo

A palestra apresenta como o desenvolvimento de software está mudando com o uso de agents, que agora podem executar tarefas em paralelo e participar de diferentes etapas do ciclo de vida do software. O GitHub demonstra recursos do Copilot para coordenar trabalho entre repositórios, manter instruções atualizadas, automatizar tarefas e reforçar segurança e revisão de código. Também anuncia melhorias na infraestrutura do Git, projetadas para atender ao aumento de atividade provocado por desenvolvedores e agents. A apresentação termina destacando a importância da colaboração e o potencial do software que ainda será criado.

Pontos-chave

A equipe descreve uma mudança de tarefas individuais para a coordenação de vários agents e workflows.
O GitHub Copilot app reúne agents, projetos, integrações com serviços externos e automações em um só lugar.
Copilot Projects permite coordenar trabalho entre vários repositórios e delegar tarefas a subagents.
Copilot Fusion escolhe modelos e padrões de execução para realizar tarefas com desempenho e custo otimizados.
Copilot Dreaming atualiza instruções e memórias com base nas mudanças no código e nas decisões da equipe.
Copilot Automations executa workflows na nuvem em resposta a eventos, em horários programados ou sob demanda.
A apresentação destaca recursos para detecção de vulnerabilidades, proteção contra exposição de secrets e revisão de pull requests.
A nova arquitetura do Git separa armazenamento e computação e reduz a coordenação para aumentar a capacidade de processamento.
O GitHub afirma que a nova arquitetura sustentou 7.200 operações de escrita por segundo em um repositório nos testes apresentados.

Capítulos

Início	Capítulo	Resumo
01:18	Como o trabalho de desenvolvimento está mudando	Os participantes comentam a passagem do trabalho individual para a orquestração de agents e a produção de software orientada por ideias.
10:52	O crescimento do GitHub e do desenvolvimento com agents	Jay Parikh apresenta números de atividade e projetos open source, relacionando o crescimento à adoção do desenvolvimento agentic.
17:41	Demonstração do GitHub Copilot app	A demonstração usa integrações e Copilot Fusion para desenvolver e testar um recurso de passaporte de cafeterias.
25:23	Copilot Projects e trabalho entre repositórios	A equipe mostra como coordenar agents em vários repositórios e gerar materiais de demonstração por meio de automações.
29:30	Novos componentes para workflows com agents	Jay resume o aplicativo, os projetos e o Copilot Fusion, e apresenta o foco em manter a qualidade durante a aceleração do trabalho.
31:04	Continuidade de sessões e automações	A demonstração acompanha uma tarefa iniciada no celular e explica como automações na nuvem respondem a eventos e executam tarefas.
35:12	Segurança e revisão de código	São apresentados recursos de análise de código, detecção de secrets, revisão de pull requests e organização de pull requests empilhadas.
38:21	Resolução automática e qualidade do software	A demonstração mostra o Agent Merge resolvendo feedback, falhas de CI e conflitos antes de mesclar um pull request.
42:01	Escala e confiabilidade da infraestrutura	Jay descreve o aumento de capacidade e a migração para uma implantação multirregional no Azure.
45:09	A nova arquitetura do Git	A equipe explica como a nova arquitetura separa armazenamento e computação e aumenta a capacidade de escrita em repositórios.
49:21	Outras melhorias na plataforma	Jay cita trabalhos no gateway de API, no GitHub Actions e na rede para sustentar a atividade de agents.
50:24	O futuro da criação de software	A palestra conclui que developers continuam essenciais e destaca a colaboração como fonte de novas ideias e projetos.

Citações

A mudança de mentalidade é: posso implantar algo que dê resposta a essa ideia. — 03:22

O Dreaming garante que suas instruções e memórias sempre reflitam suas preferências. — 23:19

Hoje estamos apresentando nosso nível mais profundo de revisão: o code review Max. — 37:49

Você não está no trânsito; você é o trânsito. — 45:40

Acho que todo o software já escrito pode ser apenas 1% do que humanos e agents vão criar nos próximos cinco anos. — 51:56

Conceitos e entidades

GitHub (empresa): Plataforma e empresa que organiza o evento e apresenta novidades para o desenvolvimento de software.
GitHub Copilot app (ferramenta): Aplicativo apresentado como um espaço central para trabalhar com agents, projetos e integrações.
GitHub Copilot Projects (ferramenta): Recurso para definir objetivos e coordenar agents em um ou mais repositórios.
GitHub Copilot Fusion (ferramenta): Recurso que coordena a seleção de modelos e padrões de execução para completar tarefas.
Copilot Dreaming (ferramenta): Recurso que atualiza instruções e memórias para refletir mudanças no código e nas práticas da equipe.
Copilot Automations (ferramenta): Recurso para executar workflows automatizados na nuvem, acionados por eventos, por agenda ou manualmente.
Copilot code review Max (ferramenta): Versão de revisão de código do Copilot apresentada como um avanço na identificação de problemas graves.
Microsoft Foundry (ferramenta): Plataforma citada como opção para criar agents usando o harness do Copilot.
Sentry (ferramenta): Serviço usado na demonstração para monitorar problemas no sistema em produção.
Azure (ferramenta): Infraestrutura de nuvem da Microsoft para a qual o GitHub está migrando parte de seus serviços.
Jay Parikh (pessoa): Líder da equipe do GitHub e da equipe de IA mais ampla da Microsoft, segundo sua apresentação no evento.

Tradução completa (pt-BR)

01:18 Entra no que vai ser anunciado no Universe, e é simplesmente empolgante. Tipo, estou animado para que todo mundo veja, e isso é muito legal. Adoro isso, adoro isso. Certo. E você, Sam? Qual número do Universe é este para você? Este é o número dois. Número dois. Você esteve aqui no ano passado. Certo, adoro isso, adoro isso. Este é o meu número cinco, cinco ou seis. Então acho que sou o veterano aqui. Mas muito obrigado a todos por estarem aqui. Certo. O Universe é sempre um ótimo momento para refletirmos sobre o que mudou no último ano. É um ótimo momento para meio que

01:49 pensarmos no que aconteceu nos últimos 12 meses. E o último ano foi incrível, mudou tanta coisa. Então minha pergunta para cada um de vocês é: o que mais mudou na forma como vocês trabalham como desenvolvedores? Os modelos obviamente melhoraram muito, e acho que isso abriu muitas oportunidades para todos nós. Mas o que isso significa para as mudanças no seu trabalho do dia a dia? Sam, vou começar com você. Certo. Uma das coisas que mudou muito é que deixei de trabalhar mais em uma coisa de cada vez e passei a trabalhar mais com orquestração multi-agent. Então é assim que estou construindo. Mas, por outro lado, faço bastante trabalho open source. Sou mantenedor de MCP e também trabalhamos publicamente no MCP do GitHub. E é muito importante que as coisas em que estamos trabalhando com a equipe de Developer Love aqui realmente nos ajudem a estruturar isso da forma certa, para que os projetos, os projetos open source, mantenham corretamente o elemento humano e a colaboração seja divertida, sem sermos simplesmente

02:21 bombardeados com coisas bem-intencionadas, mas difíceis demais de processar. Então, sim, houve uma mudança enorme e tem sido incrível, mas a palavra que eu usaria é intenso. Certo. Ace, e você? O que mais mudou na forma como você tem trabalhado nos últimos 12 meses? Eu diria que a maior mudança foi na mentalidade, certo? Porque, até agora, nossa engenharia era focada no projeto em que você estava trabalhando. Você tinha projetos paralelos ou outros recursos que ficavam em segundo plano. Mas agora, basta pensar em

02:52 algo, na sua ideia, e a mudança de mentalidade é: posso colocar em produção algo que resolva isso. Aí eu simplesmente mudo para isso, exploro o que está acontecendo, dou estrutura para você e, quando você percebe, às vezes, enquanto está trabalhando em outra coisa, já tem um produto pronto em outro lugar. Acho que isso simplesmente muda a forma como construímos software ou até como pensamos em fazer o software avançar de modo geral. E tem sido muito empolgante explorar isso. Que ótimo. Certo. E a Maggie. Sim. Nesta época no ano passado, lembro que eu não escrevia código à mão, mas ainda analisávamos o código para fazer a revisão. Eu ainda conferia o código antes de fazermos o merge. Esses dias já ficaram para trás há muito tempo. Quer dizer,

03:22 faço parte de uma equipe de pesquisa, então somos muito mais despreocupados com isso do que uma equipe de um produto mais voltado à produção. Mas agora existem fábricas de software fazendo merge de coisas. Tudo faz merge sozinho. As coisas são testadas sozinhas. Eu atuo no nível de inserir ideias e decisões no sistema. Já não me envolvo em escrever ou lançar o código.

03:53 Por favor, recebam Jay Parikh. Bom dia. Bom dia. Boas-vindas ao Universe. É ótimo estar aqui com todos vocês em San Francisco e com todos que estão acompanhando online. Sou Jay. Lidero a equipe do GitHub e a equipe mais ampla de IA da Microsoft.

10:52 Quando estivemos aqui no ano passado, falamos sobre como 2026 seria o ano em que desenvolvedores e todos os seus agents apareceriam para trabalhar no GitHub. E foi exatamente o que aconteceu. Agora há mais de 225 milhões de desenvolvedores no GitHub, abrangendo todos os países do mundo. Na verdade, um novo desenvolvedor entrou no GitHub a cada segundo no ano passado, e

11:23 esse é o segundo ano consecutivo em que isso acontece. E todos vocês também estiveram extremamente ocupados. Estes são os números mais recentes do nosso relatório Octoverse. Os envios de código aumentaram para 34,3 ou 17,9 bilhões. Os commits saltaram para 34,3 bilhões e chegaram a 1,3 bilhão em 2026. E a comunidade open source está

11:55 lançando e compartilhando mais do que nunca. Agora há 2,5 contribuições acontecendo na comunidade open source. Há projetos open source incríveis demais para contar, mas eu queria destacar alguns. A Brasilia é uma organização sem fins lucrativos que está criando ferramentas open source com IA para a descoberta de medicamentos, destinadas a pesquisadores do mundo todo. O Openquake, da Global Earthquake Model Foundation, criou software open source que ajuda

12:26 as comunidades a avaliar riscos e perigos causados por terremotos. O AI Skills, de Matt Pocock, está ajudando todos nós com instruções e skills que funcionam em diferentes coding agents e abordam erros comuns que cometemos. E esses são apenas alguns dos projetos mais incríveis. Mas há muitos outros por aí. Na verdade, hoje já temos 566 milhões de repos públicos e open source no GitHub, um aumento de mais de 30% em relação ao ano

12:57 anterior. Mas não se trata apenas da escala dessa atividade. Trata-se também da taxa de crescimento. Basta olhar para estes gráficos. Esse tipo de taxa de crescimento é extremamente raro. É um pouco assustador. Esse crescimento é impulsionado pela mudança para o desenvolvimento de software com agents. A diferença entre 2024 e 2026 é extraordinária. Como vocês podem ver nesta

13:28 visualização de jobs do Actions. Este é um momento empolgante, e muitos de nós já estão vendo um impacto significativo do uso de agents no nosso trabalho. Mas ainda há muita coisa que precisamos construir. E é disso que quero falar hoje: como estamos evoluindo cada camada da stack do GitHub para esta era de agents. Queremos capacitar vocês, desenvolvedores do mundo todo, a

13:59 passarem mais tempo criando, colaborando e concluindo trabalho de software com agents. Mais tarde nesta manhã, também vamos mostrar como estamos ampliando a base desta nova era. Mas, primeiro, quero apresentar todo o trabalho que temos feito para ajudar vocês a construir com agents. Nosso trabalho como desenvolvedores está mudando rapidamente. Em poucos anos, passamos de digitar linhas

14:29 de código à mão para receber ajuda da IA e, agora, gerenciar dezenas, às vezes centenas, de workflows com agents. O objetivo final continua o mesmo: concluir trabalho de software significativo. Mas o caminho, os mecanismos e os sistemas que usamos são muito diferentes. Agora, muitas vezes, tudo começa com um sinal ou um evento, uma solicitação de um colega, talvez um evento em produção. O SDLC

14:59 já não é linear. Na verdade, o SDLC está se comprimindo. A maioria de nós alterna entre essas diferentes etapas dependendo da tarefa. Agora, os agents estão cuidando da maior parte da implementação e do trabalho de verificação, e tudo entra e sai dessa máquina central de aprendizado. Agora podemos construir um sistema de entrega de software realmente baseado em agents, que resolva questões de velocidade, inteligência e

15:30 qualidade. Vale a pena parar um instante para destrinchar esses três aspectos. Velocidade é ajudar vocês e seus agents a ir da ideia à produção. E queremos fazer isso de maneira rápida, eficiente e econômica. Inteligência é reunir esse contexto em toda a plataforma e usar um mecanismo de aprendizado contínuo para que vocês consigam concluir o trabalho cada vez melhor ao longo do tempo. Qualidade. É claro que, à medida que

16:04 aumentamos a velocidade, queremos manter a alta qualidade. Queremos detectar problemas de segurança antes que cheguem à produção. E também queremos encontrar outros bugs e problemas antes de lançar. No GitHub, estamos construindo o sistema de entrega de software de ponta a ponta mais abrangente do setor. Nenhum outro sistema se compara ao que estamos entregando a vocês. E, como sempre, estamos disponibilizando os elementos fundamentais

16:35 para que vocês possam transformá-los no seu próprio sistema de entrega de software com agents. E há um amplo ecossistema de ferramentas que vocês podem conectar ao sistema. Isso vai de Datadog a Figma, Cloudflare e muito, muito mais. Vamos continuar adicionando outras ferramentas, e a plataforma do GitHub continuará aberta e extensível. Hoje, vamos mostrar alguns desses elementos fundamentais em ação. Então, vamos receber Cassidy no palco para nos mostrar tudo.

17:05 disponíveis para que você possa transformá-los no seu próprio sistema agêntico de entrega de software. E há um amplo ecossistema de ferramentas que você pode integrar ao seu sistema. Isso vai do Datadog ao Figma, ao Cloudflare e muito, muito mais. Vamos continuar adicionando mais ferramentas, e a plataforma GitHub continuará aberta e extensível. E hoje vamos mostrar algumas dessas primitivas em ação. Então, vamos receber Cassidy no palco para nos mostrar como funciona.

17:41 Como todo mundo está hoje? Tudo bem. Vou aceitar isso. Como vão as coisas? Bem. Como você está hoje? Nada mal. E você? Está pronto? Estou muito animado para mostrar a todo mundo o que vamos construir. Então… Olá. Olá. Vamos trabalhar. Este é o app do GitHub Copilot. Se você ainda não o viu, é um lugar único incrível para trabalhar com agents em vários projetos, integrar ferramentas externas, automatizar tarefas e muito mais. Além disso, caso você não saiba, tem um joguinho aqui dentro

18:11 que você pode jogar. Jay, você já jogou? Já. Qual foi sua pontuação máxima? Quatro. Hoje estou mal. Tudo bem. Mas enfim, vamos até as issues. Deixe-me encontrar o mouse aqui. Certo, pronto. Vamos até as issues e trabalhar na tarefa de hoje: criar um passaporte do café. Agora, tem bastante coisa escrita aqui, mas, para dar um contexto, minha equipe e eu estamos construindo o que chamamos de plataforma para uma rede de cafeterias, e vamos

18:41 criar um passaporte do café aqui. Vou iniciar isso agora mesmo. Esta issue tem muitos locais, e o passaporte do café é para quem visita todos os locais diferentes. Essas pessoas ganham carimbos. E, quando conseguem todos os carimbos, vencem. Podem ganhar algumas guloseimas legais e coisas do tipo. Então, queremos descobrir o que conta como uma visita, o que acontece depois de visitas repetidas e assim por diante. Acabei de perguntar ao meu colega de trabalho Seth sobre esse recurso do passaporte porque, com essas questões em aberto, precisamos obter respostas. E

19:12 como conseguimos obter essas respostas aqui mesmo no app, J? Podemos usar conectores. E conectores são serviços gerenciados que ficam no app Copilot ou em qualquer outro serviço. Eles se conectam a serviços como Slack, Work IQ, Vercel, Netlify e Sentry. Assim, você se autentica uma vez e depois usa esses serviços em todos os seus serviços. Isso mesmo. Então, na aba de personalização, bem aqui, ficam todos os conectores diferentes. No topo, estão estes recursos. E, se você quiser usar aqueles gerenciados pelo GitHub, sem ter que fazer login em vários dispositivos, pode ver aquele pequeno selo de verificação. Isso significa que, depois de conectar, você só precisa fazer isso uma vez, e fica ótimo. E, se eu voltar à nossa issue e encontrar nossa sessão, parece que conseguimos as respostas para todas as nossas perguntas. E eu adoro não precisar ficar alternando o contexto e indo de um app para outro. É bom não ter que fazer suposições. Temos a fonte confiável bem aqui e, como agora temos o plano completo, com tudo mapeado, posso simplesmente iniciar esta

19:43 Os gerenciados pelo GitHub, em que você não precisa fazer login em vários dispositivos, mostram aquele pequeno selo de verificação bem ali. Isso significa que, depois de conectar, você faz isso uma vez e fica ótimo. E, se eu voltar à nossa issue e encontrar nossa sessão, parece que obtivemos as respostas para todas as nossas perguntas. E eu realmente gosto de não ter que lidar com a alternância de contexto e de ficar alternando entre vários aplicativos. É bom não ter que fazer suposições. Temos a fonte da verdade bem aqui e, como agora temos o plano de tudo completamente mapeado, posso simplesmente começar a dar início a isso

20:14 sessão aqui mesmo. Então, vamos começar a implementar esta issue. Mas que modelo eu escolho? Temos tantas opções. Adoro isso. Mas, Jake, qual devo escolher? Você deve usar o Copilot Fusion. Ah, certo. O Fusion coordena vários modelos para oferecer resultados de ponta por um custo menor. Na verdade, ele decide o que a tarefa exige e, então, escolhe o padrão de execução ideal. Há três: cascata simples

20:45 ou crítica. Há um trabalho sério de engenharia sendo feito no Copilot Fusion. E os resultados são impressionantes. Na verdade, recentemente, no índice de agents de programação da Artificial Analysis, o Copilot Fusion Max marcou 60. Isso fica a apenas dois pontos do Opus 5.5 Max. E fez tudo isso pela metade do custo por tarefa e em 40% menos tempo, sobrando mais dinheiro para o orçamento de chá de boba. Então,

21:17 eu adoro me aprofundar nessas coisas. E admito que este é um recurso bem grande. Por isso, passei para a nossa sessão recém-saída do forno, para vocês verem o que construímos de verdade. Fizemos alguns testes de verdade. Construímos tudo e está tudo prontinho, então podemos fazer alguns testes ao vivo para garantir que tudo funciona. Vou abrir a conta de demonstração de vocês, Jake, e dar uma olhada no seu passaporte. Qual é o seu pedido habitual de café? Café puro. Sem nada. Você é muito criativo, cara. É rápido. Vamos

21:48 ver. Vamos ver o que o Copilot escolhe para você. Enquanto isso acontece, o agent vai interagir com o navegador e testar esse recurso. Então, vamos ver o que acontece enquanto ele começa a se movimentar. A tela vai começar a se mover ali. Agora, isso parece um navegador, mas não é. É aqui que todo mundo faz “uau, uau, sim”. Não é um navegador. Na verdade, é o que chamamos de canvas. Este é um canvas de navegador. Mas, se eu for até o canto

22:18 superior direito, tem um pequeno sinal de mais. Se eu clicar nele, temos canvases de navegador, canvases de terminal e também canvases personalizados, sobre os quais falaremos mais tarde. Isso permite que os agents interajam com esse navegador de várias maneiras diferentes. Tenho dois canvases de navegador aqui, e ele está se movendo devagar, mas está se movendo. Acho que algumas coisas estão sendo configuradas. Mas, enquanto isso está sendo testado, muita coisa acontece nos bastidores. Há algo que vocês talvez não percebam enquanto o agent começa a clicar

22:49 por aí e a mover coisas: nós reescrevemos este app. Originalmente, ele era em Java. Entenderam? É uma cafeteria. Ainda está cedo. Cedo demais, mas tudo bem. Agora, ele está em SvelteKit. Então, embora o código possa ter mudado e, mais uma vez, esteja interagindo aqui, vocês vão ver que ele começa a fazer login. As instruções de como isso foi construído não necessariamente acompanharam a mudança. Mas deixa eu apresentar a vocês o Copilot Dreaming, J. Enquanto abro o PR, você poderia explicar o que é o Dreaming?

23:19 Claro. Então, provavelmente todo mundo aqui já escreveu instruções personalizadas para seus agents. Elas são ótimas por cerca de três semanas. Depois, a base de código muda, surgem modelos mais inteligentes, e as instruções acabam atrapalhando mais do que ajudando. O Dreaming verifica e garante que suas instruções e memórias reflitam sempre suas preferências, e acho que você tem algumas. Sim, tenho muitas. Sou muito exigente. Neste caso específico, o Copilot Dreaming abriu um pull request aqui, e estou

23:50 olhando para a alteração na div que está limpando nosso arquivo de instruções neste novo mundo sem Java. Vou revisar tudo isso como faria com qualquer outra alteração. Mas agora, qualquer agent que pegar uma tarefa terá orientações atualizadas, alinhadas com todas as nossas decisões, nossa base de código e assim por diante. E, lá no fim, mais uma vez, tem bastante texto descrevendo o que aconteceu aqui. Hoje em dia, todo mundo é muito prolixo com agents. Também temos algumas memórias do Copilot atualizadas. Vocês podem ver todas as

24:21 suas memórias, que são suas preferências aprendidas pelo Copilot e as práticas da sua equipe. Assim, dá para ver como suas respostas são personalizadas para você. E vocês podem ver todas as minhas memórias aqui. Sou muito exigente com a minha base de código, então é muito bom poder ter tudo isso para receber respostas melhores. Outra coisa legal: se eu voltar ao nosso recurso, vou voltar à nossa sessão recém-saída do forno. Dá para ver que ele fez login. Vocês viram o passaporte dele um pouco antes. Digamos que eu

24:51 tenha gostado do que vi. Tudo está funcionando como esperado, mas ainda quero investigar o código. Posso ir até aqui e abrir no VS Code para ver todas as alterações no código e investigar o que eu precisar. J, tudo isso foi muito legal e é muito divertido ver tudo acontecendo ao vivo de novo, mas tenho muitas sessões aqui na lateral, e é assim que eu gosto. Ah, estou aumentando tanto o zoom. Enfim, tenho muitas sessões aqui e gosto assim. Normalmente, tenho pilhas de repos, muitas coisas acontecendo ao mesmo tempo,

25:23 mas há outras maneiras de fazer as coisas. Você está pensando nos Projects do Copilot? Estou. Certo, obrigado. Cassidy. Vamos chamar Bert para nos mostrar os Projects. Obrigado a todos. Oi. Bom dia, pessoal. Muito obrigado por me trazerem aqui para falar sobre Copilot Projects. É minha maneira favorita de trabalhar com GitHub Copilot, e estou animado para mostrar isso no meu novíssimo Surface.

25:54 Iniciador do Laptop. Posso tentar? Vá em frente. Certo. Está demorando demais. Desculpe, desculpe. Tudo bem. Então, para começar, quero criar um projeto aqui mesmo na barra lateral do app do GitHub Copilot. Depois de fazer isso, podemos adicionar os repositórios Fourth Coffee aqui como contexto. Agora, com isso feito, eles ficam disponíveis como contexto neste chat. E aqui está o que quero fazer: criar um recurso de pedidos de sempre para que os clientes

26:24 possam reordenar facilmente o pedido de sempre com apenas um toque. Moleza. Então, vou descer e adicionar este prompt, e depois é só enviá-lo. O trabalho que Burke está fazendo agora costuma envolver vários repos. Com Projects, o Copilot inicia quantos agents forem necessários para desenvolver esse recurso e atribui esses agents de acordo com o repo em que a tarefa precisa ser concluída. Exatamente. E vou enviar aqui um contexto adicional,

26:55 como estes mockups que nossa equipe de design forneceu. Vamos precisar deles. Ah, e tivemos uma conversa no Slack em que definimos mais ou menos exatamente como isso funcionaria. Então, também vou enviar isso. Ah, e esqueci que também tivemos uma chamada no Teams com as equipes jurídica e de compliance. É um recurso de personalização. Então, queremos garantir que os agents também tenham esse contexto. Burke não precisa esperar os agents terminarem para enviar prompts adicionais. Ele não está conduzindo o ciclo de um agent individual. Na verdade, está trabalhando com o orquestrador do Copilot, então

27:25 pode continuar enviando solicitações, e o Copilot iniciará novos subagents para atendê-las. Eles responderão às perguntas e ainda terão o contexto de todo o projeto. Essa é minha parte favorita. Agora, Jay, como você sabe, e como todos vocês sabem, há muito mais para lançar algo do que apenas o código, certo? Com certeza. Por exemplo, a equipe de marketing certamente vai querer saber como esse recurso funciona para poder promovê-lo. Não seria legal se o Copilot pudesse gerar os

27:56 artefatos para nós? Acredite ou não, o Copilot consegue fazer isso. Então, vou até a biblioteca. Temos estes videozinhos que criamos para o marketing. Na verdade, eles são feitos pelo GitHub Copilot. Demos a ele uma skill, e eles são réplicas perfeitas da nossa aplicação. Assim, a equipe de marketing pode receber essas demonstrações antes mesmo de o código ser lançado. E o que eu gostaria de fazer aqui é criar uma automação para que, todos os dias, esses vídeos sejam criados automaticamente quando

28:26 um novo recurso for lançado. Assim, eles aparecem automaticamente aqui na biblioteca, bem aqui nas nossas automações. Ótimo. Agora, se olharmos, temos o quê? Cinco, seis, oito agents que estão trabalhando neste projeto. Esses agents podem ser executados localmente ou na nuvem. Então, podemos simplesmente fechar o laptop e passar para outras coisas, sem interromper o trabalho. E, como pedi ao Copilot para criar PRs,

28:57 eles aparecem automaticamente na visão geral do projeto conforme os agents terminam o trabalho. Pessoal, ninguém gosta de microgerenciar agents. Com Copilot Projects, vocês podem deixar de fazer isso completamente e se concentrar apenas nos resultados. Exatamente. E quando falamos em aumentar a velocidade, é disso que estamos falando. E estou animado para anunciar que, a partir de hoje, GitHub Copilot Projects está disponível para todos. Muito bem. Obrigado, Burke, e obrigado, Cassidy. Foi muito divertido. Então, vocês acabaram de ver alguns dos mais novos blocos de construção da GitHub para o seu sistema de entrega de software. Quero destacar alguns deles, especificamente o app do GitHub Copilot, um novo app desktop nativo para agents, que reúne seus agents e seu trabalho; e Projects, onde você pode definir o objetivo, ver o que está avançando e direcionar o que o Copilot vai assumir em seguida, em um ou vários repos. O GitHub Copilot Fusion

29:30 seleciona automaticamente os modelos certos ao longo do processo para concluir a tarefa em que você está trabalhando, oferecendo melhor desempenho a um custo menor. E mais uma observação: de hoje até o fim de novembro, queremos que vocês experimentem o Copilot Fusion. O uso terá 30% de desconto. Então, experimentem. Certo. Juntos, todos esses componentes capacitam vocês a usar agents para

30:01 fazer o trabalho avançar. Mas vocês também precisam manter o controle. Com agents escrevendo muito mais código, temos muito mais pull requests, muito mais revisões de segurança e muito mais deploys para concluir. Então, como gerenciar tudo isso e garantir que o nível de qualidade continue alto? Essa é outra grande área de foco para nós. Queremos garantir que nada atrase vocês no dia a dia. Para falar sobre isso,

30:33 vamos dar as boas-vindas ao palco. Ah, oi, Jay. O que está acontecendo? Prometo que não estou rolando sem parar pelas notícias ruins. É, não estou fazendo isso. Com certeza estou trabalhando. Prometo. Na verdade, podemos mostrar na tela. Certo, prepare isso. Há um bug no app. O recurso de pedir antecipadamente para de aceitar pedidos antes de o café fechar, o que está certo, mas o site não avisa o cliente. Então, posso iniciar uma sessão do Copilot para corrigir isso pelo meu

31:04 celular. E ele inicia uma sessão em um ambiente isolado na nuvem, que posso retomar mais tarde. Legal. Queremos garantir que haja continuidade entre todas as superfícies. Você pode começar uma tarefa no celular, retomá-la no app e levá-la para o VS Code, a CLI ou o .com, onde quer que esteja. Tudo isso é impulsionado pelo mesmo harness do Copilot, que também foi disponibilizado em toda a Microsoft. E, a partir de hoje, você também pode usar esse harness para criar um agent para o que quiser fazer no Microsoft Foundry. Sim, é uma das minhas coisas favoritas. Faço isso o tempo todo: começo em um dispositivo e continuo em outro. Então, aqui está a mesma sessão que acabei de iniciar no VS Code. Jay, prometo que, enquanto você falava, li tudo isso e verifiquei todo o código. Temos até diagramas aqui. Sim, está ótimo. Está pronto. Então, vou dizer que, para mim, parece bom. Vamos abrir um PR quando você terminar. E o importante aqui é que o agent tem um próximo passo claro, o que significa que posso pegar outro trabalho e fazer

31:35 outra coisa que precisa da minha atenção, porque não me faltam agents, J. O que me falta é atenção e tempo. Só consigo fazer uma coisa de cada vez, certo? Sei que estou esperando uma atualização de firmware, mas ela não vem, então posso passar para a próxima coisa que precisa da minha atenção. E parece que há um erro no botão “Como funciona o pedido”. Então, vou dar uma olhada rápida em “Como funciona o pedido” na nossa página. Pois é, foi um erro 500 bem rápido. Certo, agora consigo ver os detalhes desse erro

32:06 em uma tela personalizada. Se eu abrir esta sessão, estamos usando o Sentry no nosso sistema de produção para monitorar esses problemas. E podemos ver o alerta bem aqui. Mas não quero apenas ver um alerta. Quero fazer algo a respeito, então poderia criar uma issue aqui ou corrigir o problema com o Copilot. Mas por que estou clicando em botões? Estamos no ano 2000, certo? Isso deveria acontecer automaticamente. Para fazer isso acontecer automaticamente, vou usar um recurso chamado Copilot Automations. E, enquanto

32:37 algo mais que precisa da minha atenção, porque não estou sem agents, J. Estou sem atenção e tempo. Sou muito limitado a fazer uma coisa por vez, certo? Sei que tenho esperado por uma atualização de firmware, mas ela não vem, então posso passar para a próxima coisa que precisa da minha atenção. E parece que há um erro no botão “Como funciona a ordenação”. Então vou dar uma olhada rápida em como funciona a ordenação na nossa página. Pois é, foi um erro 500 muito rápido. Certo, agora consigo ver os detalhes desse erro

33:09 em uma tela personalizada. Então, se eu abrir esta sessão, estamos usando o Sentry no nosso sistema de produção para monitorar esses problemas. E podemos ver bem aqui que há um alerta. Mas não quero apenas ver um alerta. Quero fazer algo a respeito, então poderia criar uma issue aqui ou corrigir isso com o Copilot. Mas, tipo, por que estou clicando em botões? Estamos no ano 2000, certo? Eu deveria… essas coisas deveriam acontecer automaticamente. Então, para fazer isso acontecer automaticamente, vou usar um recurso chamado Copilot Automations. E enquanto

33:39 Vou abrir isso. Jay, você pode falar para todo mundo sobre automations? Claro. Copilot Automations permite criar workflows com IA para trabalhar no seu repo. Eles são executados na nuvem e permitem responder a um evento. Você pode executá-los em um cronograma ou acioná-los manualmente para que atuem como um squad de agents para você e sua equipe. Assim, você pode deixá-los cuidar da triagem e da delegação enquanto se concentra em outras coisas. Isso mesmo. Neste exemplo que estou mostrando a todos, dá para ver que ele é executado por meio de uma API ou eu

34:11 posso acioná-lo manualmente, mas também tenho todos esses acionadores automáticos que posso usar. Ele é executado na nuvem, então não preciso deixar meu laptop ligado quando vou para casa. E, o mais importante, podemos escolher quais ferramentas ele tem permissão para usar. Por exemplo, posso fazer com que ele crie pull requests, mas não permitir que faça merge deles. Isso é muito útil. Este é o meu prompt. Outro recurso muito legal é que posso controlar quanto ele gasta. Assim, sei que meus agents não vão sair do controle e consumir todos os meus créditos de IA, porque eles não são gratuitos. Não mesmo. Agora, este é apenas um

34:42 automation isolado, certo? Quero mostrar algo ainda mais legal que estamos fazendo em outro repo. Este é meu repo de assinaturas. Aqui temos uma série de automations que trabalham juntas para eliminar uma boa parte do trabalho repetitivo. Temos várias automations que captam sinais e criam issues. Depois, temos uma automation que faz a triagem dessas issues, outra que as reproduz e me fornece capturas de tela, outra que as corrige e mais uma que verifica a correção em relação à solicitação original

35:12 E agora, todas essas são automations especializadas que fazem muito bem apenas essa parte do trabalho. Um processo como esse me permite automatizar boa parte do trabalho repetitivo que tenho, para que eu possa me concentrar nas coisas que realmente exigem minha atenção. Então é isso que automations fazem por mim. Certo. Vou mudar rapidamente de assunto e vamos falar de algumas maneiras de melhorar a postura de segurança da nossa aplicação. Certo. O GitHub code scanning pode analisar toda a nossa base de código para

35:43 procurar vulnerabilidades em código novo e existente. Agora, também ampliamos o suporte a linguagens com IA, para que possamos encontrar mais problemas. Por exemplo, quando encontramos uma vulnerabilidade, recebemos todas essas informações sobre onde ela está no código, de que tipo de vulnerabilidade se trata e como normalmente a corrigiríamos. Então, mesmo que não tenhamos uma daquelas automations sofisticadas em execução, podemos simplesmente atribuir isso a uma correção automática agentic. E todas essas informações ficam disponíveis para o agent ajudar a corrigir o problema. E o

36:15 que acabamos tendo, no fim das contas, é apenas um pull request com uma correção sugerida. Isso avalia todo o código do nosso repo, certo? Mas quero mostrar uma maneira de ajudar a evitar problemas de segurança ainda mais cedo. Aqui, acidentalmente, fiz commit de um segredo em um arquivo na minha máquina local. Certo. Vou fazer git push. Não recomendo que ninguém faça isso. Não, não é uma boa ideia. No entanto, esse segredo foi detectado por IA.

36:47 Isso aconteceu antes mesmo de ele chegar ao nosso repo. E eu nem precisei fornecer um padrão para ele procurar. Ele foi detectado automaticamente. Então, com secret scanning e a proteção de push por IA, nossa postura de segurança é muito melhor. Mas e quanto à qualidade do trabalho que estamos produzindo? Certo? Vamos voltar e dar uma olhada em um pull request, um dos que Cassidy e a equipe fizeram para o endpoint do serviço Coffee Passport. E podemos ver aqui que um dos revisores é o GitHub

37:18 Copilot. Assim, garantimos que todo pull request, seja de um agent ou de uma pessoa, seja revisado pelo Copilot Code Review antes de qualquer revisão de código feita por uma pessoa. Há bastante coisa aqui, então vou… bem, tem uma sugestão que vou analisar. Enquanto faço isso, Jay, você pode atualizar as pessoas sobre o que é o Copilot Code Review? Sim, claro. Lançamos o Copilot Code Review no ano passado e, até agora, ele identificou 200 milhões de problemas para desenvolvedores. E hoje estamos apresentando nosso

37:49 nível mais avançado de revisão até agora: Code Review Max. Max representa um grande avanço. Ele obteve a maior pontuação F1 no ReviewBench para problemas de alta gravidade. E continuamos trabalhando nisso, que melhora cada vez mais com o tempo. O Copilot Code Review também está disponível para todos, sem necessidade de uma assinatura do Copilot. Você só paga pela revisão com créditos de IA. Sim, usamos bastante e isso me ajuda muito. Agora revisei esses

38:21 pull requests. Hoje estou sendo muito eficiente. Se você reparou, revisei todas aquelas sugestões. Elas parecem ótimas. Então vamos ver se podemos fazer merge daquele pull request. Na verdade, não se trata de apenas um pull request. Acontece que o trabalho que Cassidy e a equipe fizeram consiste em três partes diferentes, mas muito relacionadas. Então organizamos esse trabalho usando um novo recurso chamado pull requests empilhados. Aqui está a mudança na interface. Aqui está

38:51 o endpoint, o serviço do qual ele depende. E aqui estão também as mudanças nos dados das quais ele depende. Esse conjunto de pull requests pode ser integrado de uma só vez ou um de cada vez. Outro efeito colateral da quantidade de código que está passando pelo nosso sistema hoje em dia é que, às vezes, antes que eu consiga fazer uma revisão de código, o código muda por baixo e aquele pull request fica desatualizado, certo? Aqui está aquela sessão que começamos no início, pelo

39:22 celular, e que criou um pull request. Agora vou usar um recurso chamado Agent Merge para resolver problemas automaticamente. Ele vai verificar o contexto em segundo plano, analisar como abordar o feedback, corrigir falhas de CI e resolver conflitos. E, como temos todo esse processo de segurança e qualidade de código em vigor, sinto confiança suficiente para ativar também o merge de pull requests. Então, assim que todas as verificações forem aprovadas e todos

39:52 esses problemas forem resolvidos, ele fará merge do pull request para mim. Então, aquele problema com que comecei no início desta apresentação, quando eu estava trabalhando no celular, está praticamente resolvido. Posso passar para outra coisa. Isso é incrível. É mesmo. Sim. Então, é assim que meu dia é agora. É automatizado, organizado e seguro do começo ao fim. Obrigado, Timo. Certo. Até mais. A equipe está fazendo um ótimo trabalho. Vocês acabaram de ver um

40:24 monte de recursos que vão ajudar a manter o padrão de qualidade alto enquanto vocês entregam software. E vocês não precisam diminuir o ritmo. Quero recapitular algumas coisas importantes. A continuidade da sessão permite que vocês continuem o trabalho em várias superfícies. E tudo isso é impulsionado pelo mesmo harness rápido e eficiente. Automations permite definir o trabalho uma vez e executá-lo sob demanda, em um cronograma ou em resposta a alguma outra atividade. E o Copilot Code Review é uma

40:56 parte importante para manter esse padrão de qualidade alto, e vai apontar bugs relevantes e acionáveis para que vocês possam impedir que esses problemas cheguem à produção. Mais uma coisa. Queremos facilitar para que clientes do GitHub Enterprise aproveitem todos esses recursos do Copilot. Então, a partir de hoje, clientes do GitHub Enterprise podem usar todos os recursos do Copilot sem uma assinatura separada.

41:29 Isso significa que todo desenvolvedor Enterprise pode usar o app GitHub Copilot, o Code Review, automations e muito, muito mais. E vocês só pagam pelos créditos de IA. Certo, ao longo dessas três demonstrações, vocês viram vários dos componentes básicos que podem usar para entregar trabalho de software concluído, e podem fazer isso de forma rápida, eficiente e econômica. Ainda há muito mais por vir. Em geral, estamos lançando recursos e melhorias mais rápido do que nunca, e isso

42:01 em toda a plataforma. Agora, é claro, para fazer tudo isso, precisamos de uma base muito sólida: uma infraestrutura de alto desempenho e confiável. Neste ano, houve momentos em que tivemos dificuldades com essas questões, mas boa parte disso se deveu ao crescimento e à escala que vocês viram antes. Isso não é uma desculpa, porém. Vamos e precisamos fazer melhor. A boa notícia é

42:32 que estamos trabalhando muito nisso, e a primeira coisa que fizemos foi adicionar muita capacidade. Até agora, neste ano, adicionamos 4 milhões de núcleos de CPU, 160 PB de armazenamento de alta velocidade e 50 terabits por segundo de capacidade de rede. E o ano ainda não acabou. Também estamos avançando de forma constante na migração para uma implantação multirregional no Azure, uma das

43:03 infraestruturas de hiperescalabilidade mais poderosas do mundo. Estamos fazendo isso enquanto continuamos atendendo a todos os desenvolvedores do mundo. É um enorme desafio de engenharia, mas os benefícios serão muito significativos. Esperamos concluir a migração no início do ano que vem. É um bom progresso, mas, por si só, não basta. E, na minha experiência, sempre que sua carga aumenta de forma

43:35 significativa, é preciso repensar todas as suas premissas sobre o que construir e como operar. E é exatamente isso que estamos fazendo. Estamos evoluindo nossa infraestrutura para esta era gigantesca, começando com novos elementos fundamentais que garantirão um serviço ágil e confiável a todos os desenvolvedores da plataforma, independentemente da escala. Um exemplo dessa próxima grande evolução é nossa arquitetura do git. Temos

44:06 ampliado o git continuamente ao longo dos anos, à medida que a atividade aumentou, mas estou muito animado com nosso trabalho recente nessa área. Nossa nova arquitetura foi projetada para oferecer o maior throughput e a maior confiabilidade possíveis. Para isso, simplificamos os elementos fundamentais do sistema. Desacoplamos o armazenamento da computação e minimizamos a coordenação. Nos testes, encontramos 5.000 dos coding agents mais exigentes e

44:37 os colocamos para trabalhar em um monorepo. E esse repo sustentou 7.200 gravações por segundo. E temos mais melhorias a caminho. Então, vamos elevar esse limite. Outra forma de dar contexto a essa escala foi pegar 24 horas do repo open source mais movimentado do GitHub, ou seja, 24 horas de tráfego. Comprimimos tudo em um minuto, e a nova pilha

45:09 nem se esforçou. Então, vamos receber April no palco para uma análise mais detalhada da nova infraestrutura do git. Obrigada, Jay. Vocês acabaram de ver o que um desenvolvedor pode fazer com uma frota de agents. Agora imaginem isso para todos os

45:40 desenvolvedores e todos os repos: cada sessão de agent cria branches, lê o histórico e faz push, muitas vezes tudo ao mesmo tempo. E tudo isso, nessa escala, começa a encontrar gargalos. Outro dia, meu agent comentou sobre o trânsito, e eu tive que dizer: “Você não está no trânsito; você é o trânsito.” E já estamos vendo isso ao longo do último ano. O número de pushes e commits só continua crescendo. Em

46:13 setembro, desenvolvedores e agents fizeram mais de 7 bilhões de requisições — só em setembro. A maioria dos repositórios fica bem dentro dos limites atuais. Mas os repositórios mais movimentados já os alcançam. E, à medida que os agents ganham escala, outros também vão alcançá-los. Por isso, estamos reconstruindo a base do git. Primeiro, removemos o gargalo imediato: a hospedagem física. Ao longo do último ano, movemos quase todos os repositórios do git

46:46 para o Azure, mas, para cerca de 100 dos repositórios mais movimentados, até mesmo 25 milissegundos entre data centers faziam diferença. Então, mudamos a forma como o git coordena as gravações. Em vez de bloquear um repositório inteiro para cada gravação, bloqueamos apenas a branch que está sendo atualizada. Agora, agents trabalhando em branches diferentes podem operar em paralelo, oferecendo de 3 a 4 vezes mais capacidade. Certo, isso elevou o limite, mas nos propusemos

47:16 a remover o teto. Projetamos a nova arquitetura em estreita colaboração com a equipe de armazenamento. Repensamos tudo para um mundo de agents, com três princípios: simplificar os elementos fundamentais, desacoplar o armazenamento da computação e da coordenação. Assim, seu código fica armazenado de forma durável no armazenamento de blobs do Azure, que é a fonte da verdade. O servidor mantém esses dados em cache para agilizar o acesso, mas os servidores são efêmeros. Portanto, podemos adicionar capacidade conforme a demanda cresce. E então minimizamos a

47:48 coordenação. Apenas a pequena transação de referência permanece no caminho crítico, gerenciada por um serviço especializado de log replicado, otimizado para velocidade. E o resultado? A arquitetura antiga atingia um limite de dezenas de pushes por segundo em um único repositório. Esta foi projetada para milhares. E, como Jay mencionou antes, direcionamos 5.000 agents a um repositório e sustentamos incríveis 7.200 registros. Isso é 180 vezes

48:20 nosso throughput atual. E, para leituras, nosso próprio harness de teste de carga atingiu os próprios limites antes que a nova arquitetura atingisse os dela. Mas, vejam, os benchmarks só podem nos levar até certo ponto, então queríamos tráfego real. Fizemos uma parceria com Open Core, um dos projetos open source mais movimentados do GitHub, e conversamos com Peter Steinberg, criador de Open Core, pouco antes de ele partir para sua palestra no Ted. E foi isto que ele disse: “O GitHub mudou a forma como os objetos do git são

48:50 armazenados, e isso fará com que nossos agents consigam operar muito, muito mais rápido. Estou ainda mais animado. Animado com tudo o que podemos fazer. Assim que essa mudança entrou em vigor. Muitas vezes, nossos agents fazem coisas bobas, como ficar consultando o sistema. Suspiro. E esta é uma nova infraestrutura. Novas mudanças, como o GitHub poder nos avisar quando… Vocês estão construindo a base para isso, certo? E isso vai resolver praticamente os problemas existentes.” Obrigado

49:21 April. Um trabalho realmente impressionante. E obrigado também a Peter por conhecer o novo sistema com antecedência. Adoramos trabalhar com Peter e sua equipe. Todos devem migrar para a nova arquitetura até o início do próximo ano. Esse é apenas um exemplo do trabalho que estamos fazendo para ampliar a plataforma. Outros projetos incluem o trabalho que estamos fazendo no gateway de API do GitHub, que hoje processa trilhões de tokens. Fizemos muito trabalho aqui para otimizar o

49:52 cache de prompt do gateway, minimizar a latência e melhorar o desempenho do harness. Agora, Actions é uma área com foco em Actions, que processa bilhões de minutos por mês, e estamos adicionando mais capacidade. Estamos reforçando o controlador e simplificando a coordenação para garantir que o sistema continue fazendo seu trabalho avançar. E, na rede, estamos adicionando mais pontos de presença. Aumentamos a largura de banda dos links de backbone entre os data centers legados do GitHub e o Azure,

50:24 e fizemos otimizações em aspectos como TLS para manter todo o tráfego dos seus agents fluindo. Vamos continuar melhorando nessa área. Vocês vão perceber e sentir a diferença. Mostramos muita coisa nesta manhã e mostramos como estamos evoluindo cada camada da pilha do GitHub para esta era dos agents. Mostramos como isso ganha vida em nossa nova arquitetura do git e em novas ferramentas como o Copilot

50:56 Fusion, além da continuidade entre todas as superfícies que vocês usam, como o VSCode, a CLI e o novo aplicativo GitHub Copilot. A forma como construímos software está mudando, mas os desenvolvedores nunca foram tão importantes, porque a parte mais difícil de construir nunca foi apenas escrever código. É entender um problema, imaginar algo melhor e

51:26 ter a capacidade e a vontade de fazer o trabalho. Fazer com que funcione no mundo real. O melhor de tudo é que, aqui no GitHub, ninguém precisa construir sozinho. Alguém compartilha uma ideia, outra pessoa a aprimora. Um projeto se torna um bloco de construção para algo que seu criador jamais imaginou. A criatividade impulsiona a colaboração. A colaboração desbloqueia a

51:56 criatividade. E esse é o poder desta comunidade. Acredito, porém, que ainda estamos apenas começando. Na verdade, acho que todo o software já escrito talvez represente apenas 1% do que humanos e agents vão construir nos próximos cinco anos. Pensem nisso por um instante. Mas o objetivo não é criar mais software; é o impacto que esse software terá no mundo. Mal posso esperar

52:27 para ver o que vocês vão construir. Obrigado e tenham um universo incrível.

Transcrição original

[01:18] Goes into what’s going to be announced to universe, and it’s just exciting. Like I’m excited for everyone else sees it and that’s really cool. I love that, I love that. Okay. And Sam, what about you? What universe number is this for you? This is number two. Number two. Last year you were here last year. Okay, I love that, I love that. This is this is number five, 5 or 6 for me. So so I think I’m the veteran here. But thank you all so much for being here. All right. So universe is always a really good time for us to reflect on like what ha changed in the last year. It’s a really good time to kind of

[01:49] think about like, what has happened in the past 12 months. And the last year was a banger, like so much change. So my question for each of you is, what has changed the most about how you work as a developer? Like the models have obviously improved a ton and that’s unlocked a lot of opportunities, I think, for all of us. But what does that mean for how your work changes day to day? So Sam, I’m actually going to start with you. Okay. So one of the things that’s changed massively is I’ve gone from kind of working more on one thing at a time to sort of

[02:21] multi agent orchestration side of things. So that’s kind of how I’m building. But then on the other side of things, I do a lot of open source work. Like I’m MCP maintainer and also we work on GitHub, MCP in public. And it’s a really important that the things that we’re working on with the developer love work here are really helping us to set it up, right? So that projects kind of open source projects keep the human element correctly, so that the collaboration is kind of fun and we’re not being just

[02:52] bombarded with well-intentioned, but kind of too much to process. So yeah, like it’s a, it’s been a huge change and it’s been amazing, but it’s like intense is the word I would use intense. Okay. All right. Ace, what about you? What has changed the most about how you’ve been working in the last in the last 12 months? I would say the biggest thing is the mindset shift, right? Because for, for now, we, we went through engineering focusing on what the project you’re working on. You have side projects or other features that just take the back burner. But right now it’s as long as you think about

[03:22] stuff, your idea, the mindset shift is I can deploy something that’s addressing that. And I just, you know, switch over to it, explore what’s happening, give you structures, and then next thing you know, sometimes when you’re working on something else, you have a finished product elsewhere. And I think it just changes how we build software or even think about advancing software in general. And that’s, that’s been really exciting to explore. That’s awesome. All right. And Maggie. Yeah. This time last year, I remember I wasn’t, I wasn’t writing code by hand, but we were still looking at code to review it. I would still actually check the code before we merged it in. Those days are very long gone. I mean,

[03:53] I’m on a research team, so we’re a lot more cavalier about it than, than like a more production product. But now there’s like software factories merging stuff. Everything merges itself. Things are like testing itself. Like I, I operate at the level of like inputting ideas and decisions into the system. I am not involved in writing or shipping the code anymore

[10:52] Please welcome Jay Parikh. Good morning. Good morning. Welcome to universe. It is great to be here with all of you in San Francisco and with everyone who’s tuning in online. I’m Jay. I lead the GitHub team and the broader AI team at Microsoft.

[11:23] When we were here last year, we talked about how 2026 was going to be the year where developers and all of their agents showed up for work on GitHub. They definitely did. There are now over 225 million developers on GitHub, and that spans every country in the world. In fact, a new developer joined GitHub every second last year, and

[11:55] that’s the second straight year this has happened. Now all of you have been extremely busy as well. This is the latest numbers from our octopus report. Code pushes increased to 34.3 or 17.9 billion. Commits jumped to 34.3 billion and jumped to 1.3 billion in 2026. And the open source community is

[12:26] shipping and sharing more than it ever has. There are now 2.5 contributions happening in the open source community. Now, there are way too many amazing open source projects out there, but I did want to recognize a few. Brasilia is a nonprofit that is building open source, AI powered tools for drug discovery for researchers around the world. Open quake from the Global Earthquake Model Foundation has created open source software that helps

[12:57] communities assess risks and hazards due to earthquakes. AI Skills by Matt Pocock is helping all of us with instructions and skills that work across coding agents and address common mistakes that we have. And these are just some of the most awesome projects. But there are so many more out there. In fact, now we’re up to 566 million open source and public repos on GitHub today, and that is up over 30% year

[13:28] over year. But it’s not just the scale of this activity. It’s also the growth rate. Just look at these graphs. Now this type of growth rate is extremely rare. It’s pretty scary. It’s being driven by the shift to agentic software development. The delta between 2024 and 2026 is remarkable. As you can see from this

[13:59] visualization of actions jobs. Now, this is an exciting moment, and many of us are already seeing significant impact from using agents in our work. But there is still a lot of things that we need to build. And that’s what I want to talk about today. It’s how we’re evolving every layer of the GitHub stack for this agentic era. We want to empower you, developers of the world, to

[14:29] spend more time creating, collaborating, and completing software work using agents. Later this morning, we’re going to show you how we’re scaling the foundation of this new era as well. But first, I want to walk you through all the work that we’ve been doing to help you build with agents. Our jobs as developers are changing rapidly. In a couple of years, we’ve moved from typing lines

[14:59] of code by hand to being assisted by AI to now managing dozens, sometimes hundreds of agentic workflows. The end goal remains the same, though completing meaningful software work. But the path, the mechanisms, and the systems we use are very different. Things are now often triggered by a signal or an event, a request from a colleague, maybe an event in production. The SDLC

[15:30] is no longer linear. In fact, the Sclc is collapsing. Most of us jump between these different stages depending on the task. Now agents are handling the bulk of the implementation and the verification work, and everything feeds into and out of this central learning machine. We can now build a truly agentic software delivery system, one that solves for velocity, intelligence, and

[16:04] quality. Now, it’s worth taking a second to unpack these three. Velocity is all about helping you with your agents get from idea to production. And you want to do this quickly, efficiently, and cost effectively. Intelligence is about assembling that context platform wide and using a continuous learning engine so that you can complete work better and better over time. Quality. Now, of course, as we

[16:35] increase velocity, we want to keep the quality of our high. We want to catch security issues before they land in production. And we also want to find other bugs and issues before we ship. Now at GitHub, we are building the most comprehensive end to end software delivery system in the industry. No other system can match what we are delivering to you. And as always, we’ve done. We are making the primitives

[17:05] available so that you can make them into your own agentic software delivery system. And there’s a broad ecosystem of tools that you can plug into your system. This spans from Datadog to Figma to Cloudflare and much, much more. Now we’ll continue to add more, and the GitHub platform will remain open and extensible. And today we’re going to show you some of these primitives at work. So let’s welcome Cassidy to the stage to take us through it.

[17:41] How’s everyone doing today? Okay. I’ll take it. How’s it going? Good. How are you doing today? Not bad. You. You ready? I’m very excited to show everybody what we’re going to build, so. Hello. Hello. Let’s get some work done. So this is the GitHub copilot app. If you haven’t seen it yet. It’s a really awesome single location for working with agents across multiple projects, integration with external tools, automations, and so much more. Plus, if you don’t know, there’s a little game in here

[18:11] that you can play. Jay, have you played it? I have. What’s your high score? Four bad today. Okay. But anyway, so we are going to head over to issues. Let me find my mouse here. Okay, there we go. We’re going to head over to issues and work on our task for the day, which is building a coffee passport. Now, there’s going to be a lot of words here, but for some context, my team and I have been building what’s called a platform for a coffee shop chain, and we’re going to be

[18:41] building a coffee passport here. I’m going to kick this off right there. Now, this issue has a lot of locations, and the coffee passport is for people who visit all of the different locations. They get stamps. And then when you get all the stamps, you win. You can get some cool treats and stuff. So we want to find out what counts as a visit. What happens after repeat visits and so on and so forth. Now, I just asked my coworker Seth about this passport feature because with these open questions, we need to get answers for them. And

[19:12] how is it possible that we’re able to get these answers right here in the app J. We can use connectors and connectors. Are these managed services that sit in the copilot app or whatever service. And they connect to services like Slack, work IQ, Vercel, Netlify, and Sentry. So you can authenticate one place and then use them across all of your services. Yes. So in the customize tab right over here, these are all of the different connectors. There’s these features ones at the top. And now if you want to have those

[19:43] GitHub managed ones where you don’t have to log in across multiple devices, you can see that cool little verified badge right there. And that means once you’ve connected, you have done it once and it looks great. And if I head over back to our issue and find our session, it looks like we got the answers to all of our questions. And I really love not dealing with context switching and going between multiple apps. It’s nice to not have to make assumptions. We have the source of truth right here, and because we now have the plan of everything all mapped out, I can just start kicking off this

[20:14] session right here. So we’re going to start implementing this issue. But what model do I pick? We just have so many options. I just love that. But Jake what should I pick. You should use copilot fusion. Ooh. Okay. Fusion coordinates between multiple models to deliver frontier level results at a lower cost. In fact, it decides what task requires, and then it picks the optimal execution pattern. There’s three. There’s single cascade

[20:45] or critique. Now, some serious engineering work is going on into copilot fusion. And the results are super impressive. In fact, recently in artificial analysis, coding agent Index, Copilot fusion Max scored 60. And that’s within two points of opus five five Max. Now it did all of this at half the cost per task and at 40% less timeppt more of the boba tea budget. So

[21:17] I really love geeking out about this. And I admit this is a very large feature. So I moved to our fresh out of the oven session so you can see what we actually built. We have some actual testing that happened. We had everything built out and everything is fully baked, so we can do some fun live testing to make sure that this all works. So I’m going to be opening up your demo account, Jake, and check out your passport. What’s your typical coffee order? Plain coffee. Nothing in it. You are super creative, man. It’s fast. Let’s

[21:48] see. Let’s see what copilot picks for you. Now, as this goes, what is going to happen is the agent is going to start interacting with the browser and testing out this feature. And so we’re going to see what happens as it starts moving. The screen will start moving there. Now this looks like a browser but it isn’t. This is where you all go ooh ooh yeah. It’s not a browser. So it is actually what’s called a canvas. Now this is a canvas browser. But if I head over to the very

[22:18] top right there, there’s a little plus sign. And if I click that, we have browser canvases, we have terminal canvases. We also have custom canvases, which we will talk about later. And this allows agents to interact with this browser in a bunch of different ways. And so I have two browser canvases right here and it’s moving around slowly but surely. I think that some things are getting set up. But while this is being tested, there’s a lot happening behind the scenes. Now there’s something that you wouldn’t necessarily see as the agent is starting to click

[22:49] around and move things. We actually rewrote this app. It was originally in Java. Get it? It’s a coffee house and it’s too early. Too early, but still. So now it is in Sveltekit. So even though the code may have moved on and once again, it’s doing some interactions here, you’ll see it start logging in. The instructions for how this is built did not necessarily move on. But let me introduce you to copilot dreaming J. While I pull up the PR, would

[23:19] you mind explaining what dreaming is? Absolutely. So everyone here probably has written custom instructions for their agents. They’re great for about three weeks. And then the code base moves, more intelligent models show up and the instructions end up hurting more than they help. Dreaming goes back and ensures that your instructions and memories always reflect your preferences, which I think you have a few. Yes, I have so many. I’m very picky. So in our particular case, Copilot Dreaming opened up a pull request here and I’m

[23:50] looking at the div that it’s cleaning up our instructions file in this new non Java based world. And I’ll review all of these just like I would any other change. But now any agent that picks up a task will be going from up to date guidance. That’s up to date with all of our decisions, our code base and so on and so forth. And at the very bottom of this, once again, lots of words just describing what happened here. Everyone’s so verbose now with agents. You know, we have also some copilot memories updated as well. You can see all of

[24:21] your memories, which are your preferences that copilot has learned about and your team’s practices. So you can see how much your outputs are tailored to you. And you can actually see all of my memories here. I am very picky about my code base, and so it’s really nice to be able to have all of these so that I get better outputs. Now, what’s also cool, if I head back over to our feature, I’m going to go back to our fresh out of the oven. You can see that things have logged in. You saw his passport a little bit earlier. Let’s just say I

[24:51] liked what I saw. Everything is working as expected, but I still wanted to dig into the code. I can still go right up here and open this up in VS code and see all the code changes and dig into whatever I might need to. Now J this was all very cool and it’s really fun to once again see all this happening live, but I do have a whole lot of sessions over here on the side, and it’s just the way I like it. Oh, I’m zooming in so far. Anyway, I have a lot of sessions here and I like it. I usually have piles of repos, lots of things going on at once,

[25:23] but there are other ways to do things. Are you thinking of copilot projects? I am. All right, thank you. Cassidy. Let’s bring on Bert to show us projects. Thanks, everyone. Hey. Morning, everybody. Thank you so much for bringing me out here to talk about copilot projects. It is my favorite way to work with GitHub copilot, and I’m excited to show it to you on my brand new Surface

[25:54] Laptop launcher. Can I try? Go ahead. Okay. It’s too much time. Sorry, sorry. All right. So what I want to do to get started here is just create a project right here in the sidebar of the GitHub copilot app. And then once we do that, we can go ahead and add in the fourth coffee repositories right here as context. Now once we do this, these are now available for context in this chat. Now here’s what I want to do. I want to create a your usual feature so that customers

[26:24] can easily reorder their usual with just one tap. Easy peasy. So what I’m going to do is come down and just add this prompt, and then just go ahead and send this. So work like Burke is doing right now often involves multiple repos. And with projects, copilot spins up as many agents as it needs to tackle this feature, and it will assign those agents depending on whatever repo the task needs to be completed in. Exactly. And I’m going to send in some additional context here,

[26:55] like these mocks that our design team provided. We’re going to need those. Oh, and we did have a conversation in Slack where we figured out kind of exactly how this would work. So I’m going to send this as well. Oh, and I forgot we also had a teams call with legal and compliance. It’s a personalization feature. So we want to make sure that the agents also have that context. Now Burke doesn’t have to wait for the agents to finish before he sends his additional prompts. He’s not steering an actual individual agent loop. He’s actually working with the copilot orchestrator here so he

[27:25] can keep firing them off, and copilot will spin up new Subagents to tackle these requests. Answer the questions, and it’ll still have the context across the entire project. And that’s my favorite part of this. Now, Jay, as you know, and as all of you know, there’s way more to shipping something than just the code, right? Absolutely. For example, marketing is for sure going to want to know how this feature works so that they can promote, promote it. Wouldn’t it be cool if copilot can generate the

[27:56] artifacts for us? Believe it or not, copilot can do that. So I’m going to come over here to the library and we’ve got these little videos that we make for marketing. And these are actually built by GitHub copilot. We’ve given it a skill and these are pixel perfect match to our application. So marketing can get these little demos before the code even ships. And what I’d like to do here is I’d like to go ahead and create an automation so that every day these videos automatically get created when

[28:26] a new feature ships. So they just automatically show up over here in the library, right there in our automations. Beautiful. Now, if we look at this, we’ve got what, five, six, eight agents that have now been running on this project. And these agents can run locally or they can run in the cloud. So we can just shut the laptop and move on to other things to keep right on moving. And because I asked copilot to create PRS,

[28:57] those are automatically showing up here in our project overview as the agents finish their work. Y’all. Nobody likes micromanaging agents with copilot projects. You get to get out of that business completely so that you can just focus on the results. Exactly. And when we talk about increasing velocity, this is the kind of thing we’re talking about. And I’m excited to announce that today, GitHub Copilot Projects is available to everyone. All right. Thank

[29:30] you, Burke, and thank you, Cassidy. That was super fun. So you just saw some of the newest building blocks from in for your software delivery system, a few of them to call out, specifically the GitHub copilot app, which is a new agent native desktop, bringing your agents and your work together, and then projects where you can set the goal. You can see what’s moving and you can direct what copilot takes on next across one repo or many GitHub copilot fusion

[30:01] automatically selects the right models throughout the process for completing the task that you’re working on, and it delivers better performance at a lower cost. Now, one additional note today, today, through the end of November, we want you to try copilot fusion. So usage will be 30% off. So give it a try. Okay. So together all of these components empower, use, empower you to use agents to

[30:33] move your work forward. But you got to stay in control to. But with agents also writing so much more code, we have way many more pull requests. We have way many more security reviews, and we have many more deployments to get done. So how do you manage to do all of this and ensure that you still keep the quality bar high? This another big area of focus for us. We want to make sure that nothing slows you down day to day and to take us through that.

[31:04] Let’s welcome to the stage. Oh, hi, Jay. What’s going on? I promise I’m not doomscrolling. Yeah, I’m not doomscrolling. I’m sure doing some work. I promise we can show you actually, on the screen. All right, set that up. There’s a bug in the app. Right. So the order ahead feature stops taking orders before a cafe closes, which is right, but the site doesn’t tell the customer. So I can start a copilot session to fix this from my

[31:35] phone. And it spins up a session in a cloud sandbox, which allows me to pick it up later. Nice. So we want to make sure that you have strong continuity across all the surfaces. So you can start a task on your phone, pick it up from the app, move it to VS code or the CLI or.com, wherever you are. Now, this is all powered by the same copilot harness, which has also been rolled out across all of Microsoft. And starting today, you can take this harness and you can build an agent for whatever you want to do on

[32:06] Microsoft Foundry as well. Yeah, it’s one of my favorite things. I do this all the time. Start on one device, come into another one. So like right here, here is that same session I just started in vs code. Now I promise, Jay, while you were talking, I read through all of this and I checked all the code. We’ve even got diagrams here. Yeah it’s great. It’s ready to go. So I’m just going to say it looks good to me. Let’s do a PR when you’re done. And so the important thing here is that the agent has a clear direction forward, which means that I can pick up some other work and do

[32:37] something else that needs my focus, because I’m not short on agents J. I’m short on attention and time. I’m very single threaded, right? I know I’ve been I’ve been waiting for a firmware update, but they’re not coming so I can move on to the next thing that needs my attention. And it looks like there is an error with the how ordering works button. So I’ll just have a quick look how ordering works on our page. Sure enough, that was a very fast 500 error. Okay, now I can see the details of that error

[33:09] in a custom canvas. So if I open this session, we are using sentry in our production system to monitor these issues. And we can see right here there’s an alert. Now I don’t want to just see an alert. I want to do something about that alert so I could create an issue here or fix it with copilot. But like, why am I clicking buttons? It’s the year 2000, right? I should, this stuff should happen automatically. So to get that happening automatically, I’m going to use a feature called Copilot Automations. And while

[33:39] I open that, Jay, can you tell everyone about automations? Sure. So Copilot Automations lets you create AI powered workflows to work in your repo, and they run in the cloud and you can respond to an event with it. You can run on a schedule, or it can be triggered manually to act as a squad of agents for you and your team, so you can let them take on triaging and delegation tasks while you focus elsewhere. Yeah. So in this one that I’m showing everyone, you can see that it runs via an API or I

[34:11] can manually trigger it, but I’ve got all these automatic triggers that I can use as well. It runs in the cloud, so I don’t have to keep my laptop open when I go home. And importantly, we can choose which tools it’s allowed to use. So for example, I can get it to create pull requests, but it’s not allowed to merge them. So that’s really handy. Here’s my prompt. One other really cool feature is that I can control how much it spends. So I know that my agents aren’t going to go rogue and burn all my AI credits because they’re not free. No. Now this is just one

[34:42] isolated automation, right? I want to show you something even cooler that we’re doing in another repository. This is my subscriptions repository. And here we have a series of automations that all work together to take a lot of the toil away from me. So we have a series of automations that pick up, watch for signals and create issues. Then we have an automation that triages those issues, and then one that reproduces them and gives me screenshots, another one that fixes them, and another one that verifies the fix against the against the original

[35:12] request. And now these are all specialist automations that do just that piece of work really well. Now, a process like this means that I can automate away a lot of the toil that I have, and so I can focus on the things that actually require my attention. So that’s what automations does for me. All right. I’m going to do a quick pivot, and we’re going to talk about some ways to improve the security posture of our application. All right. So GitHub code scanning can scan through our entire code base to

[35:43] look for vulnerabilities in new and existing code. Now we’ve even expanded the language support with AI here so we can find more issues. So for example, when we find a vulnerability, we get all of this information about where in the code, the vulnerability it is, what type of vulnerability it is, and how we would typically fix that vulnerability. So even if we don’t have one of those fancy automations running, we can just assign this to a genetic auto fix. And all of that information is there for the agent to help fix it. And what

[36:15] we end up with ultimately is just a pull request with a suggested fix. Now this evaluates all the code in our repository, right. But I want to show you a way we can help prevent security issues even earlier. So here I have accidentally committed a secret to a file just on my local machine. Right. So I’m going to git push this. I wouldn’t recommend anybody does this. Nope, not a good idea. However, this secret was detected by AI.

[36:47] Now this is before it even reached our repository. And I didn’t even have to provide a pattern for it to match. It just got picked up automatically. So between secret scanning and AI push protection, our security posture is a lot better. But what about the quality of the work we’re producing? Right? Let’s jump back and have a look at a pull request, which is one of the ones that Cassidy and team worked on for the coffee service coffee passport service endpoint. And we can see here one of the reviewers is GitHub

[37:18] copilot. So we make sure that every pull request, whether it comes from an agent or a person, is reviewed by copilot code review before any human does a code review. Now there’s a lot in this, so I’m just going to well, there’s one suggestion here which I’m going to look at. So while I’m doing that, Jay, are you able to tell people catch people up on what copilot code review is? Yeah, absolutely. So copilot code review we launched last year and so far it has surfaced 200 million findings for developers. And today we’re introducing our

[37:49] deepest level of review yet code review Max. Now Max is a big step forward. It posted the highest F1 score on review bench for high severity issues. Now we’re continuing to do work here and it’s getting better and better over time. Copilot code review is also available to everyone without a copilot subscription. You just pay for the review with AI credits. Yeah, it’s something we use a lot and it helps me a huge amount. Now I’ve reviewed those

[38:21] pull requests. I’m really efficient today. If you noticed, I’ve reviewed all of those suggestions. They look great. And so we are going to look at merging that pull request. And actually it’s more than just one pull request. It turns out that this piece of work that Cassidy and team did is three different, but very related pieces of work. So we have organized this work into using a new feature called pull stacked pull requests. So here’s the UI change. Here’s

[38:51] the endpoint, the service that it depends on. And then the data changes as well that it depends on. So this stack of pull requests can be merged all together. Or it can be merged one at a time. The other side effect of these, the amount of code that’s flowing through our system these days is that sometimes before I can get to do a code review, the code changes underneath and that pull request becomes stale, right? So here is that session we started at the beginning on

[39:22] the phone, and it’s created a pull request. Now I’m going to use a feature called Agent Merge to automatically resolve issues. So it will look at background in the background. It will look at addressing feedback. It’ll fix CI failures and it’ll resolve conflicts. And because we have all of that security and code quality process in place, I feel confident enough to turn on merge pull requests as well. So once every check passes and all

[39:52] of these issues have been resolved, it will merge the pull request for me. So that issue I started on at the start of the stage when I was absolutely working on my phone. It’s effectively done. I can move on to something else. That’s amazing. It is amazing. Yeah. So that’s what my day looks like now. It’s automated, it’s organized, and it’s secure from start to finish. Thanks, Timo. All right. See you later. Now the team is doing some great work here. You just saw a

[40:24] bunch of features that will help you keep the quality bar high while you ship. And you don’t have to slow down. I want to just recap a couple of important things here. So session continuity, you can continue your work across multiple surfaces. And they’re all powered by the same fast, efficient harness automations allows you to define the job once and run it on demand on a schedule or in response to some other activity. And then copilot code review is an

[40:56] important part to keep that quality by quality bar high, and it’ll serve as meaningful and actionable bugs so that you can keep this stuff away from production. Now, one more thing here. We want to make it easier for GitHub enterprise customers to take advantage of all of these copilot features. So starting today, GitHub enterprise customers can use all the copilot features without a separate subscription.

[41:29] So this means that every enterprise developer can use the GitHub copilot app code review automations, and much, much more. And you just pay for the AI credits. Okay, so across these three demos, you’ve seen several of the building blocks that you can use to ship completed software work, and you can do it quickly, efficiently, and cost effectively. Now there’s a lot more to come. In general, here we are shipping features and improvements faster than we’ve ever done before, and it’s

[42:01] across the entire platform. Now, of course, to do all of this, you need a super strong foundation, an infrastructure that is performant and reliable. Now, there are times this year when we struggled with these things, but a lot of that was due to the growth and scale that you saw earlier. That’s not meant to be an excuse though. We will and we must do better. The good news here is

[42:32] that we’re doing a lot of work, and the first thing that we’ve done is added a ton of capacity. This year, we’ve added 4 million CPU cores so far, 160PB of high speed storage, and we’ve added 50 terabits, a second of network capacity. And the year isn’t over. We’re also making steady progress on our migration to a multi-region deployment in Azure, one of the

[43:03] most powerful hyperscale infrastructures in the world. Now we’re doing that while continuing to serve every developer in the world. And this is a massive engineering challenge, but the payoff is going to be really significant. And we expect the migration to be complete early next year. This is good progress, but on its own, it’s not enough. And in my experience, every time your load increases this

[43:35] significantly, you need to rethink all of your assumptions in terms of what you build and how you operate it. And that’s exactly what we’re doing. We’re evolving our infrastructure for this gigantic era, starting with new primitives that will ensure we can provide a responsive and reliable service to every developer on the platform, no matter what the scale. One example of this next big evolution is our git architecture. We’ve been

[44:06] scaling git steadily over the years as activity has increased, but I’m really excited about our recent work here. Our new architecture is designed to provide the highest throughput and reliability possible. To accomplish that, we’ve simplified the system’s primitives. We’ve decoupled storage from compute, and we’ve minimized coordination. In testing, we found 5000 of the angriest coding agents, and we

[44:37] sent them after a monorepo. And this one repo sustained 7200 writes per second. And we have more improvements coming. So we’ll take up this limit. Now, another way to give context to this scale is we took 24 hours of the busiest open source repo on GitHub, took 24 hours of traffic. We compressed it down to one minute and the new stack

[45:09] didn’t break a sweat. So let’s welcome April to the stage for a deeper dive in the new git infrastructure. Thanks, Jay. You just saw what one developer can do with a fleet of agents. Now imagine that across every

[45:40] developer and every repo, every agent session creates branches, reads history, and pushes is often all at the same time. And all of that land is on at this scale. Start to hit bottlenecks. Now, the other day my agent said about the traffic, I had to tell them, you’re not in traffic, you are traffic. And we’re already seeing it over the past year. Pushes and commits just keep growing. In

[46:13] September alone, developers and agents made more than 7 billion hits September alone. Most repositories comfortably within today’s limits. But the busiest repositories are. And as agents scale, more will follow. So we have been rebuilding the foundation underneath git First, we removed the immediate bottleneck physical hosting. Over the past year, we moved nearly every repository on git

[46:46] into Azure, but for roughly 100 of the busiest repositories, even 25 milliseconds between data centers mattered. So we changed how git coordinates writes. Instead of locking an entire repository for every write, we lock only the branch being updated. Agents working on different branches can now move in parallel, delivering 3 to 4 times more. Okay, so that raised the limit, but we set

[47:16] out to remove the ceiling. We designed the new architecture in deep collaboration with storage team. Rethink it for a world of agents and three principles. Simplify the primitives, decouple storage from compute coordination. So your code lives durably in Azure blob storage. Source of truth. The server is responding to cache that data for speed, but they’re ephemeral. So we can add capacity as demand grows. And then we minimized

[47:48] coordination. Only the small reference transaction stays on the critical path handled by a specialized replicated log service optimized for speed. And the result. Is the old architecture topped out at a dozens of pushes a second on a single repository. This one is designed for thousands. And as Jay noted earlier, we pointed 5000 agents at one repository and we sustained an incredible 7200 record. That’s 180 times

[48:20] our current throughput. And on reads, our own load testing harness hit its own limits before the new architecture did. But look, benchmarks only take you so far, so we wanted real traffic. We partnered with Open Core, one of the busiest open source projects on GitHub, and we caught up with Peter Steinberg, the creator of Open Core, right before he took off for his Ted talk. And here’s what he had to say. GitHub change how the git objects are

[48:50] stored, and it’ll affect us in a way that our agents will be able to operate much, much faster. I’m even more excited. Excited about all we can. Once this change landed. Many times our agents do silly things like the polling. Sigh. And this is new infrastructure. New changes like GitHub is being able to tell us when you’re building the foundation for that, right? And that will solve pretty much existing problems. Thank you

[49:21] April. Really impressive work. And also thank you to Peter for taking an early look at the new system. We love working with Peter and his team. Everyone should be migrated to the new architecture by early next. So this is just one example of the work we’re doing to scale the platform. Other projects include the work that we’re doing on GitHub’s API gateway, which today processes trillions into tokens. We’ve done a lot of work here to optimize the

[49:52] gateway prompt caching, minimize latency, and improve the harness performance. Now, actions is an area that focused on actions, handles billions of minutes every month, and we’re adding more capacity. We’re hardening the controller, and we’re simplifying coordination to ensure that the system keeps moving your work forward. And on network work, we’re adding more edge sites. We’ve pulled the backhaul between the GitHub legacy data centers and Azure,

[50:24] and we’ve done optimizations in things like TLS to keep all of your agent traffic flowing. Now, we will continue to get better here. We’ll see and feel the difference. We’ve shown you a lot this morning, and we’ve shown you how we’re evolving every layer of the GitHub stack for this agentic era. We’ve shown you how it comes to life in our new git architecture and in new tools like copilot

[50:56] fusion and the continuity across all the surfaces you use, like VSCode to the CLI, to the new GitHub copilot app, the way we build software is changing, but developers have never been more important because the hardest part of building has never been just writing code. It’s understanding a problem, imagining something better, and

[51:26] having the ability and the drive to make the work. Make it work in the real world. The best parts is that here on GitHub, nobody has to build alone. Someone shares an idea, someone else makes it better. A project becomes a building block for something its creator never imagined. Creativity feels collaboration. Collaboration unlocks

[51:56] creativity. And that’s the power of this community. I believe that we’re still scratching the surface, though. In fact, I think all the software ever written may amount to just 1% of what humans and agents will build in the next five years. Think about that for a second. But more software isn’t the goal the impact that software will have on the world? I can’t wait

[52:27] to see what you build. Thank you and have an awesome universe.