“Não dá para tirar o pé do acelerador”, diz VP do GitHub sobre escalada de tráfego causada pelos agentes de IA

Manter de pé uma plataforma em que 225 milhões de desenvolvedores trabalham já seria um desafio. Agora, some a isso um exército de agentes de inteligência artificial (IA) que não dorme, não tira férias e faz o trabalho de muitos de uma vez. É essa a missão de Jakub Oleksy, vice-presidente de engenharia do GitHub. “Os fluxos de trabalho com agentes de IA estão, sem dúvida, impulsionando o tráfego”, afirma ele, em entrevista ao IT Forum durante a GitHub Universe*, em San Francisco, nos Estados Unidos.

O que mudou, explica o executivo, não é só o número de pessoas na plataforma, que segue crescendo, mas a quantidade de trabalho que cada uma consegue fazer com agentes ao seu lado. Os números do Octoverse 2026, divulgados nesta quarta-feira (28), reforçam o cenário. Segundo o levantamento, mais de 40% dos pull requests no GitHub já começam com um rascunho gerado por um agente de IA. A fronteira entre o que é feito por humanos e por máquinas ficou tão difusa que nem separar um do outro é simples, diz Oleksy.

De acordo com ele, a virada desse quadro começou a ficar mais evidente em novembro do ano passado, com a chegada de uma nova geração de modelos de código, como o Claude Opus 4.5. Desde então, o comportamento do tráfego tem sido, nas palavras dele, “dinâmico”. “O crescimento continuou ao longo do ano, mas vimos vários picos. E às vezes é difícil saber por que um pico está acontecendo. Saiu um modelo novo? Algum harness ganhou mais atenção? Não necessariamente sabemos, porque o GitHub representa todos os desenvolvedores do mundo, usando qualquer ferramenta que exista”, indica.

Isso mudou a forma de planejar a infraestrutura. Além do crescimento constante e dos saltos de patamar, há picos dentro dos picos. “Tivemos de pensar em como absorver um pico que pode acontecer, e não só um crescimento estável. O tema principal é que tem sido imprevisível e muito grande”, resume. Na conversa, Oleksy citou um crescimento de 20% de um mês para o outro como exemplo do ritmo que os desenvolvedores entendem bem o que significa para um sistema.

O executivo faz questão de enquadrar o tema. “Não digo isso como desculpa, mas como contexto. Para que as pessoas entendam que não são só problemas de código. O crescimento é a pedra fundamental dos nossos desafios”, afirma, em referência às instabilidades que a plataforma enfrentou ao longo do ano. “Não estamos exatamente onde queremos estar, mas o fato de estarmos melhores e termos absorvido todo esse crescimento mostra o investimento que fizemos. No fim, nosso sucesso vai ser medido pela disponibilidade e pela confiabilidade do sistema”, reforça.

Um novo Git para outra escala

A resposta mais visível a esse desafio foi apresentada no palco do GitHub Universe: 2026 uma nova arquitetura para o Git, desenvolvida pelo time de Oleksy, que nos testes sustentou mais de 7 mil alterações por segundo em um único repositório. “Ao pensar em um crescimento de cem ou mil vezes, o código que o desenvolvedor escreveu para resolver as restrições do sistema atual não vai necessariamente funcionar mais”, diz. “O sistema atual nos trouxe até aqui, mas precisamos de um novo para seguir em frente”, reflete.

Além de suportar mais carga, a nova estrutura é mais fácil de escalar e de gerenciar, o que, segundo ele, animou a equipe. “Em vez de ter de administrar o sistema atual, podemos evoluir este e gerenciar uma escala muito maior com menos trabalho do time. Claro que ir de A para B dá muito trabalho.” E tudo isso com o alvo em movimento: “O crescimento continua enquanto desenvolvemos novas funcionalidades”, conta.

Os próximos passos seguem a mesma lógica. A migração para uma implantação multirregião no Azure deve dar capacidade em várias regiões, enquanto o time reescreve partes do sistema e passa a adotar serviços gerenciados de nuvem.

“Historicamente, rodamos nossos próprios data centers, o que significa que tivemos de fazer muita coisa sozinhos. Rodando no Azure, tenho a oportunidade de trazer serviços gerenciados para o portfólio, o que idealmente tira trabalho repetitivo da minha equipe.” Para ele, o crescimento “não estabilizou” e deve continuar “por meses”.

Dentro do GitHub, conta Oleksy, todo desenvolvedor usa IA de alguma forma todos os dias, mas o uso varia muito de equipe para equipe. No time de infraestrutura que ele lidera, o ganho não está no volume de código, e sim na operação de sistemas em escala: criar automações, monitorar e entender dados.

“Um sistema na nossa escala produz uma quantidade enorme de dados de observabilidade. Um humano consegue raciocinar sobre tudo isso e achar os pontos fora da curva? Não necessariamente. Mas a IA é muito boa em olhar muitos dados e apontar: houve um pico aqui, vale dar uma olhada”, explica. A partir daí, o engenheiro avalia e orienta os agentes a investigar se alguma mudança de código ou de tráfego explica o problema.

No outro extremo estão equipes que já nasceram com IA, como a do Copilot CLI, que desde o primeiro dia escreveu código com agentes e opera de forma muito diferente de um time que cuida da infraestrutura de Kubernetes. Há ainda usos fora da engenharia, como o suporte ao cliente, em que agentes fazem a primeira análise dos chamados e reúnem os dados relevantes. “Quando o engenheiro recebe, já tem todo o contexto para dar o próximo passo. Ou talvez parte desses casos possa ser resolvida sem nem envolver um engenheiro”, diz.

Como acompanhar a corrida da IA

Para as empresas que tentam acompanhar a velocidade das novidades, o conselho de Oleksy combina o individual e o organizacional. Há desenvolvedores que gostam de estar na fronteira e devem ser apoiados, e outros que preferem esperar que alguém teste primeiro, o que também é legítimo. Mas a decisão não pode ficar só nas mãos de cada um.

“As organizações precisam ter algum tipo de plano. Existe um time central encarregado de olhar as ferramentas que surgem e de definir como elas são adotadas na organização, em vez de deixar isso para cada desenvolvedor?”, questiona. Em grandes empresas, esse papel costuma caber a times dedicados de experiência do desenvolvedor.

E o medo de ficar para trás? “O engraçado é que, se você perde alguma coisa, não importa muito, porque duas semanas depois aquilo nem é mais relevante. Já tem outra coisa que virou a novidade”, brinca. O próprio executivo admite a dificuldade: “Sinceramente, é difícil acompanhar tudo”.

Parcerias para crescer

Com o GitHub agora no CoreAI da Microsoft, Oleksy descreve a parceria com as equipes do Azure como decisiva para a migração. “A escala em que operamos é bem intensa. Tentar fazer isso sozinho, sem essa expertise, provavelmente daria, mas cometeríamos muitos erros”, afirma, citando o trabalho conjunto com os times de Azure Blob Storage, Kubernetes e bancos de dados, além do VS Code.

Ao mesmo tempo, ele reforça a independência da plataforma. “O GitHub continua sendo uma plataforma aberta. Não temos receio de querer suportar todas as nuvens”, diz, lembrando que o GitHub Actions já tem runners rodando na AWS e que a empresa avalia o que uma estratégia multicloud significa daqui para a frente. “A relação é forte, mas o GitHub também tem a sua identidade, a de ser o destino de todos os desenvolvedores, independentemente da plataforma em que estão.”

Sobre a relação com uma comunidade conhecida por ser exigente, Oleksy diz que os desenvolvedores são “os melhores clientes”. “Eles desafiam, empurram com força, têm expectativas altas e são muito opinativos. Mas também são empáticos, porque são desenvolvedores e sabem que o que fazemos é desafiador”, afirma. Por isso, ele aposta na transparência, com posts técnicos sobre os avanços de engenharia. E deixa claro que não há folga à vista: “Não dá para tirar o pé do acelerador. Precisamos continuar acelerando”, encerra.

*A jornalista viajou a convite do GitHub

Siga o IT Forum no LinkedIn e fique por dentro de todas as notícias!