Reconstruindo o CI para o volume de commits em escala de IA — Gautam Korlam, SonarSource

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

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

Idioma original: inglês

Vídeo original: Rebuilding CI for AI-Scale Commit Volume — Gautam Korlam, SonarSource · Canal: AI Engineer · 19:15 · Assistir no YouTube

Tópicos: Engenharia de software com IA, Governança e regulação de IA

Resumo

Gautam Korlam explica como o aumento no volume de código gerado por agentes pressiona filas de CI, revisão e aprovação concebidas para o ritmo de trabalho humano. Com base na experiência na Uber e na Qodo, ele apresenta estratégias para acelerar o CI, antecipar verificações e automatizar revisões e aprovações de baixo risco. Para setores regulados, destaca a importância de políticas explícitas e de registros auditáveis sobre a origem das mudanças, os testes realizados e as decisões tomadas. A combinação dessas medidas pode reduzir gargalos sem abrir mão da qualidade e da conformidade.

Pontos-chave

• Agentes podem abrir muito mais PRs do que as filas de CI e revisão, projetadas para pessoas, conseguem processar.
• Testar mudanças em combinação ajuda a evitar que PRs individualmente aprovados quebrem a branch principal quando integrados.
• CI mais rápido, com cache, paralelização, divisão de tarefas e menos recompilações, reduz o tempo necessário para corrigir falhas.
• Revisões automatizadas podem encontrar problemas e sugerir correções antes de consumir o tempo de revisores humanos.
• Verificações devem ser antecipadas sempre que possível, pois agentes podem ter mais contexto para corrigir problemas localmente.
• Políticas baseadas em risco podem permitir aprovação automática de mudanças rotineiras e exigir aprovação humana para áreas sensíveis.
• Em setores regulados, o status verde do CI não basta: é necessário registrar quais verificações foram feitas e como as falhas foram resolvidas.
• Agentes não devem aprovar as próprias mudanças; decisões e exceções precisam ter responsáveis e justificativas identificáveis.

Capítulos

Início	Capítulo	Resumo
00:00	O desafio do CI em escala de IA	Korlam apresenta o tema e sua experiência com infraestrutura de build, merge e verificação de código.
01:01	Lições da infraestrutura de monorepo na Uber	Ele descreve o problema de integrar milhares de mudanças e o sistema criado para testar combinações de commits.
03:08	Filas humanas sob pressão dos agentes	O aumento de PRs e workflows automatizados sobrecarrega CI e revisão concebidos para um ritmo humano.
05:13	Falhas, revisões e conformidade	O palestrante detalha atrasos causados por builds, testes instáveis, revisões e falta de registros para auditoria.
08:19	Como reduzir gargalos no fluxo de desenvolvimento	Ele recomenda acelerar o CI, oferecer sinais de revisão mais rápidos, antecipar verificações e aplicar políticas.
10:23	Aceleração do CI e revisão automatizada	Korlam relata como cache e outras otimizações reduziram o tempo de CI e exemplifica o uso de revisão automatizada.
13:31	Aprovações baseadas em risco	Ele apresenta regras para aprovar automaticamente mudanças rotineiras e escalar mudanças sensíveis para aprovação humana.
15:04	Registros auditáveis e próximos passos	A palestra termina com os dados que convém registrar e com a proposta de automatizar tarefas sem perder rastreabilidade.

Citações

Essas filas foram construídas para a velocidade humana. — 03:08

O mais óbvio, claro, é tornar seu CI realmente rápido. — 08:19

Você precisa ter uma forma de fazer cumprir essas regras além do CI. — 09:21

O que quer que você consiga registrar no PR ou em outro sistema de registro será uma fonte de verdade. — 15:35

Conceitos e entidades

• Gautam Korlam (pessoa): Engenheiro que apresenta estratégias para adaptar CI e revisão ao aumento de código produzido por agentes.
• SonarSource (empresa): Empresa à qual Korlam se juntou como engenheiro principal.
• Qodo (empresa): Empresa de revisão de código mencionada por Korlam, onde ele relata práticas de CI, revisão e aprovação.
• Uber (empresa): Empresa em que Korlam trabalhou por quase uma década com infraestrutura de build e merge para monorepos.
• CI (conceito): Integração contínua, cuja velocidade e capacidade se tornam gargalos com o aumento do volume de mudanças.
• Submit Queue (conceito): Sistema desenvolvido na Uber para testar combinações de commits e manter a branch principal íntegra.
• políticas de aprovação (conceito): Regras que determinam quais mudanças podem ser aprovadas automaticamente e quais exigem revisão humana.
• auditabilidade (conceito): Capacidade de reconstruir quais verificações, aprovações e decisões acompanharam uma mudança.

Tradução completa (pt-BR)

00:00 Olá, pessoal. Sejam bem-vindos à minha palestra. Hoje vamos falar sobre como estamos reconstruindo a CI para acompanhar o volume de commits em escala de IA. Isso vem de muita experiência com infraestrutura de build e merge, na qual trabalho há mais de uma década. Quero explicar os novos gargalos que estamos vendo nas fábricas de software, especialmente em setores altamente regulamentados e em bancos. Como isso se traduz na prática? Como mantemos as coisas mais em conformidade e auditáveis,

00:30 sem deixar de avançar rápido? Vamos começar. Meu nome é Goautam. Sou cofundador e CTO da QAR e, recentemente, entrei para a Sonar como engenheiro principal. Antes da aquisição, trabalhei na Uber por quase uma década com infraestrutura de build e merge para monorepos. Isso incluía tudo: build, CI/CD, IDs e o que mais fosse necessário para garantir a produtividade dos desenvolvedores. Agora, na QAR, como parte da Solar, estou tentando garantir que o código enviado para o repo seja

01:01 verificado e que todo o código escrito por agents seja de alta qualidade antes de entrar. Antes de começar, quero dar um pouco de contexto histórico. Na Uber, já tínhamos um volume de commits em escala de agents antes mesmo de existirem agents. Com isso, quero dizer que tínhamos um monorepo gigante e fazíamos milhares de mudanças por dia, com builds muito demorados. Isso significava que, se mantivéssemos tudo serializado e fizéssemos merge de uma mudança por vez para não quebrar a

01:33 branch principal, levaríamos muito tempo — até 20 dias, neste caso — para garantir que tudo estivesse verde. E, se ignorássemos tudo e deixássemos todo mundo fazer merge na branch principal, ela ficaria vermelha o tempo todo, porque as mudanças entrariam em conflito umas com as outras. Mesmo que a CI de cada uma delas estivesse verde, juntas elas poderiam causar problemas. Então, por exemplo, nosso monitor de iOS ficava vermelho o tempo todo, o que não era produtivo para os desenvolvedores. Para resolver isso, criamos um sistema chamado Submit Queue, sobre o qual temos um artigo, e testamos

02:06 todas as combinações possíveis dos commits que estavam chegando, garantindo que pudéssemos reduzir o tempo de espera ao testá-las em paralelo. Também podíamos prever o que poderia quebrar testando todas as combinações. Assim, quando sabíamos que um PR poderia causar problemas, podíamos tirá-lo da fila e avisar o autor que precisava corrigir o problema antes de enviá-lo de novo, depois de fazer rebase. Por fim, para manter o trunk limpo, uma mudança só entrava diretamente no

02:37 trunk se passasse em todas as combinações de commits que estavam chegando. Queríamos garantir que o custo adicional valesse a pena para manter o trunk limpo. Esse sistema ainda está em funcionamento na Uber. Hoje, temos as filas de merge que o GitHub e outros hosts de código criaram, mas, naquela época, não havia um sistema assim. Então, nós o desenvolvemos. O problema dessa abordagem é que as filas que temos atualmente — seja de CI ou de revisão — são gargalos centralizados no SDLC. Todas essas filas foram criadas para a velocidade humana e, quando são projetadas para isso, não conseguem

03:08 acompanhar o ritmo quando passamos a usar agents, porque antes os humanos geravam mudanças apenas algumas vezes por hora. Podíamos testar e revisar uma mudança de cada vez. Agora, com agents, os desenvolvedores escrevem vários PRs em um dia e nem sempre esperam na fila: todos querem entrar ao mesmo tempo. Isso significa que as filas de CI e de revisão vão se acumulando e ficam sobrecarregadas. Some-se a isso os padrões das fábricas de software e os agents em segundo plano que são acionados por diferentes

03:39 workflows, e, de repente, tudo começa a se arrastar, porque os gargalos continuam sendo a CI e a revisão, que ficam acima da capacidade. O que isso significa para as equipes hoje? Para dar uma ideia da escala, nossa própria taxa de commits aumentou quase 10 vezes desde que começamos a QAR, há cerca de três anos. É simplesmente impressionante: com uma equipe do mesmo tamanho, que ainda é bem pequena, conseguimos enviar muito mais

04:10 código. Também vemos isso nas tendências do setor na QAR. Este gráfico mostra o número de PRs que a QAR revisa ao longo do tempo. Se olharmos para a trajetória de crescimento, ela é bastante exponencial. Quase todo mês, crescemos 25% em relação ao mês anterior apenas na quantidade de PRs que precisam de revisão, correções na CI e outras coisas. Acho que isso também é corroborado por evidências divulgadas por participantes do setor, como o GitHub, que têm observado um crescimento impressionante no número de PRs. E isso agora está acontecendo com todas as

04:41 equipes. Se uma equipe pequena como a nossa está vendo isso, tenho certeza de que equipes maiores e bancos estão vendo isso em uma escala muito maior, à medida que avançam na adoção de IA. O problema de que eu estava falando é o seguinte: se agents abrem PRs e você manda cada um deles passar individualmente por todo o sistema de CI, eles podem passar nos testes, mas, quando você faz merge deles de volta na branch principal, o trunk ainda pode ficar quebrado. Então, como resolvemos isso? Como mantemos tudo verde nesse ritmo acelerado? Isso é muito importante.

05:13 De certa forma, é parecido com a maneira como resolvemos isso com o Submit Queue: as mudanças não são testadas umas contra as outras. Portanto, é preciso mudar alguma coisa no sistema de CI e também na arquitetura do código e nas filas, para que sejam mais inteligentes e consigam resolver o problema. Outro problema que estamos vendo com todo mundo tentando adotar fábricas de software — em que agents escrevem todo o código com base na especificação e os humanos ficam responsáveis pela especificação e pela revisão — é que a linha de produção existente hoje foi criada para

05:44 a velocidade humana, como mencionei. Isso significa que, à medida que os agents enviam mais mudanças, cada etapa da linha de produção fica mais lenta. Por exemplo, no build e nos testes, pode haver muitos builds refeitos quando a compilação falha, testes de integração ou testes instáveis que não podem ser reproduzidos localmente, e isso deixa tudo mais lento. É preciso executá-los de novo, e, em muitos casos, isso pode levar horas quando o build é complexo. Some-se a isso o fato de que agora temos revisão e aprovação. Muitos de vocês provavelmente

06:15 já usam IA para revisar o código. Espero que vocês não estejam fazendo todas as revisões com humanos. O ideal é fazer uma primeira revisão com IA. Se esse sistema não estiver implementado, os revisores se tornam a fila. E, mesmo depois da revisão, pode haver critérios adicionais que vocês queiram verificar para garantir a aprovação completa, porque o que está acontecendo no setor agora é que muita gente está apenas aprovando sem analisar, pois não consegue acompanhar o alto volume de PRs. As pessoas passaram a depender de outros sinais para conseguir avançar. Portanto, o processo precisa mudar.

06:46 Outro problema que temos agora é que muitas dessas verificações estão sendo executadas e há muitos registros que mantemos, mas que acabam expirando. Por exemplo, os logs antigos deixam de existir quando expiram. Não há um registro do que foi realmente verificado, porque há apenas um carimbo de aprovação. Portanto, é preciso manter registros dessas coisas para que auditorias e verificações de conformidade possam ser feitas. Outro problema que estamos vendo é que, à medida que o volume de código aumenta, o tempo necessário para corrigir os problemas também está acrescentando uma enorme quantidade de

07:18 sobrecarga. O que vemos na nossa plataforma é que pelo menos 13% dos PRs tiveram uma falha de CI registrada. Isso significa uma ou mais falhas de CI. Em todos esses casos, há uma rodada adicional: é preciso voltar à máquina do desenvolvedor ou fazer com que um agent entenda os logs e a causa raiz da falha, corrija o problema, envie outro commit e continue iterando até tudo ficar verde. E isso é só CI, porque, na maioria das vezes, se um revisor humano quiser analisar um PR, não vai examiná-lo enquanto o CI não estiver verde, porque essa é

07:48 a primeira linha de defesa. Isso também desacelera o processo de revisão, porque as etapas não podem acontecer em paralelo. Normalmente, queremos analisar algo quando estiver finalizado, e agora todo laboratório está pagando pelo processo de revisão. Então, se seus comentários de revisão chegam e você faz outra rodada, a mesma interrupção acontece de novo, e o ciclo meio que se repete. Como podemos melhorar isso? O que podemos fazer para tornar esse problema mais administrável à medida que os agents produzem cada vez mais código? Descobrimos isso…

08:19 obviamente também no GitHub agora. Mas a coisa mais óbvia é, claro, deixar seu CI realmente rápido, o que significa que talvez você queira remover muitas das verificações caras. Tente transferi-las para depois do merge e deixar a etapa de CI em si realmente rápida, porque assim seus reparos serão muito mais eficientes. Você pode paralelizar as coisas, dividir em partes e usar cache. Também vamos falar sobre algumas das técnicas que usamos. Você também quer garantir que a revisão seja rápida. Então, não

08:49 apenas fazer uma revisão aprofundada, mas também talvez ter várias rodadas que deem um retorno mais rápido aos desenvolvedores. Assim, eles podem usá-las para entender em quais situações talvez seja necessário investigar mais a fundo mudanças de maior risco ou, no caso de mudanças de menor risco, até mesmo deixar a IA aprovar e fazer o merge. E, no caso das verificações que já estão sendo executadas no CI, se você puder antecipá-las, será muito mais barato detectá-las. Isso também é muito relevante para verificações que acontecem mesmo depois do CI. Por exemplo, você pode ter testes de regressão caros

09:21 ou coisas que podem falhar em produção. Nem sempre é possível antecipar as verificações, mas, quanto mais você conseguir fazer isso, menos gargalos haverá nas etapas seguintes. Além disso, localmente, os agents já têm mais contexto para corrigir o problema que estão enfrentando. Você também quer ter políticas. Isso é muito importante em setores regulamentados. Uma história que temos da época em que eu estava na Uber é que perdemos a licença para operar em Londres porque houve uma falha no software que permitiu que motoristas entrassem na plataforma sem todas as verificações adequadas.

09:51 Isso aconteceu por causa de uma alteração em uma feature flag. Então, tivemos que implementar um processo para que toda mudança que afetasse Londres e passasse pelo SDLC tivesse algum tipo de rastreabilidade: essa mudança afeta Londres? Se sim, quais controles estão em vigor? E conseguimos recuperar nossa licença. Muitos de vocês talvez estejam enfrentando esse tipo de desafio, em que os agents tornam muito mais difícil entender o que está acontecendo na sua base de código. Então, como garantir que suas políticas estejam sendo respeitadas? É preciso ter uma forma de aplicar essas regras além do

10:23 CI. O fato de o código compilar não significa que ele esteja seguindo determinadas especificações. Pode ser HIPAA. Pode ser Tora. Há muitas outras políticas das quais esses agents não terão conhecimento, a menos que seus agents as apliquem. Você também precisa garantir que fique registrado que elas foram aplicadas, para fins de auditoria. Uma breve história sobre como também aceleramos nosso CI. No início, nosso CI levava cerca de 10 minutos. Eu diria que ainda era rápido, mas era muito irritante quando você

10:54 tentava enviar mais código. Queríamos reduzir esse tempo significativamente. Então, começamos a analisar como poderíamos armazenar os resultados em cache. Usamos Rust no nosso sistema de build, então começamos a armazenar o máximo possível em cache e reutilizar os resultados. Também buscamos maneiras de reduzir a atividade do compilador. Fizemos algumas correções para garantir que a etapa de compilação pudesse aproveitar melhor o cache e que o cache fosse invalidado com menos frequência. Com mais correções, dividindo o trabalho em partes e removendo

11:24 essas sobrecargas, conseguimos reduzir o tempo de CI para menos de um minuto nas etapas incrementais. Isso significa que, depois que o CI inicial termina de aquecer o cache, os builds incrementais ficam muito, muito mais rápidos, e podemos enviar muito mais código. O outro problema é a revisão. O curioso é que, quando medíamos o tempo P90 para os PRs chegarem à produção, a maior parte do tempo era gasta na revisão, na Uber. E, mesmo hoje, para ser sincero, a maioria das equipes passa mais tempo

11:55 revisando código e fazendo outros tipos de teste antes de se sentir confortável para fazer o merge do código na branch principal. Isso também precisa ser abordado, além do CI, porque agora o que está acontecendo é que os agents geram código e, ao mesmo tempo, os agents de IA encontram problemas no seu sistema de revisão de código. Essas revisões automatizadas também apontam problemas que você precisa voltar e resolver. Então, você precisa trazer o contexto para o ambiente local do seu agent ou fazer um agent no CI iterar e corrigir os problemas, e

12:28 os humanos podem revisar o que restar depois que a IA fizer a primeira rodada. Isso precisa fazer parte da equação para que você não desperdice ciclos humanos preciosos com um número cada vez maior de PRs gerados por agents. Aqui está um exemplo nosso. Estávamos refatorando nossa base de código para acelerar o CI. Usávamos o Nextest para paralelizar nossos testes e tínhamos um banco de dados compartilhado que inicializávamos para configurá-lo uma vez e permitir que todos os nossos testes de banco de dados

12:58 o reutilizassem. Mas o problema era que não implementamos algumas proteções, o que significava que, quando o CI ficava muito ocupado, havia contaminação cruzada e os testes podiam ficar instáveis. O Sonar atua como revisor de código. Ele detectou o problema no nosso PR antes de fazermos o merge. Assim, não precisamos perder tempo com isso depois. O Sonar também corrigiu o problema para nós: sugeriu a correção, fez o commit e adicionou o engenheiro como coautor. Com isso, conseguimos evitar erros caros antes que o código chegasse à branch principal. Outra coisa que fazemos na Sonar

13:31 é que, curiosamente, estamos vendo cada vez mais clientes começarem a fazer isso: usamos políticas e critérios para decidir quando é apropriado aprovar mudanças. Muitas mudanças são rotineiras ou de baixo risco — atualizações de documentação, atualizações de dependências, desde que não quebrem APIs, patches de segurança e até mudanças de menor risco em ferramentas internas — e podem ser aprovadas automaticamente. O Sonar oferece suporte a isso pronto para uso, e você também pode adicionar regras adicionais

14:01 personalizadas, escritas em inglês simples, para definir os critérios de aprovação e merge. Estamos vendo equipes muito voltadas para IA começarem a adotar cada vez mais essas práticas. Acho que, na nossa plataforma, a adoção da aprovação automática e do merge automático está crescendo muito rápido entre as equipes, inclusive em equipes grandes, com mais de 100 ou mais de 1.000 desenvolvedores. Aqui está um exemplo de políticas de aprovação. Se for uma atualização de dependência ou uma mudança na documentação, devemos aprová-la. Qualquer mudança em áreas sensíveis, como pagamentos ou…

14:34 talvez seja necessário um aprovador humano além disso. E, claro, você não quer que o agent que fez a alteração aprove a própria alteração, porque isso não seria confiança zero. Então, neste caso, conforme os agents geram PRs, os PRs são aprovados. Quando há uma nova alteração que não atende aos critérios, precisamos escalá-la para outro aprovador. Isso pode ser feito com seus próprios agents, claro, mas também com o Gitar pronto para uso, se quiser experimentá-lo. E o outro problema de simplesmente

15:04 depender do CI hoje é que o fato de o CI estar verde, como mencionei, não significa que o código esteja em conformidade em muitos casos. Então, neste caso, o CI passa e temos alguns metadados sobre isso. Na nova execução, um teste instável vai falhar, o que significa que, quando você faz um force push para corrigir aquilo, o branch passa a apontar para outro trecho de código. O problema é que, com o tempo, a maioria dos dados do CI vai expirar. Portanto, a menos que você tenha um registro do

15:35 que aconteceu e do que foi corrigido, não será possível garantir a conformidade nem auditar o que de fato aconteceu. Por isso, acho que coisas como as trajetórias dos agents e os resultados após cada push são muito importantes. Então, qualquer informação que você possa registrar no PR ou em outro sistema de registro será uma fonte de verdade quando seus artefatos expirarem. O controle, neste caso, é garantir que a alteração tenha sido aprovada e testada por alguém que não a escreveu. Se você não tiver essas informações, isso pode ser

16:05 um problema. Aqui está um exemplo. Temos um pipeline que falhou à esquerda e um pipeline que passou. Mas a diferença é que, se você registrar corretamente por que a falha ocorreu e outra pessoa puder aprová-la porque se tratava de um modo de falha conhecido, e isso ficar registrado junto com a alteração incorporada, então essa alteração realmente passa pelas suas verificações. Isso é diferente de não ter um registro do que aconteceu e simplesmente confiar cegamente no agent que envia o código, porque pode ser que o teste não fosse de alta qualidade. Não havia

16:36 registro de todas as verificações de conformidade realizadas. Então, em setores mais sensíveis, é importante registrar todas essas decisões como regras ou verificações de conformidade no PR, além da revisão de código. Que tipos de registros devemos manter? Aqui estão alguns que mantemos e que, na minha opinião, são apenas exemplos. Pode ser diferente para cada um. Por exemplo, qual coding agent criou o PR? De onde veio o PR?

17:08 Qual sessão deu origem a ele? E quem de fato a iniciou? Pode ter sido um acionamento de um workflow automatizado ou simplesmente um engenheiro escrevendo prompts. E, para cada execução de CI, qual é o commit em que o CI foi considerado confiável e o relatório de teste salvo, não apenas um status? Também é importante garantir que haja um registro de como cada achado foi resolvido. Foi descartado? Houve acompanhamento? Foi corrigido no PR? E, então, garantir que o aprovador seja alguém diferente do bot que foi

17:40 acionado pela mesma pessoa. Também é importante garantir que qualquer exceção seja identificada explicitamente. Então, se o build estiver vermelho ou se a verificação da cobertura de código tiver sido ignorada, é preciso registrar por que a verificação falhou e por que aceitamos isso naquele caso. E garantir que o código incorporado tenha tudo isso, e que não seja apenas uma pequena alteração adicional que foi incorporada. Assim, todas as verificações são feitas sempre. Neste caso, queremos garantir que os agents não possam aprovar as próprias alterações. O engenheiro que criou o prompt também não é autor. E, se você tiver

18:12 essas práticas em vigor, podemos começar a eliminar alguns desses gargalos, porque um CI mais rápido vai liberar seus builds. Assim, seu fluxo fica muito melhor, e adiantar algumas verificações também ajuda a reduzir bastante a carga de testes. Do lado do CI, se você puder automatizar a revisão na maior parte dos casos e escalar para humanos apenas os casos excepcionais, e talvez até aprovar automaticamente alterações de baixo risco ou internas, você elimina outros

18:43 gargalos e reduz o que chega às pessoas, permitindo que uma fábrica de software opere em todo o seu potencial. E, claro, depois de cada aprovação e merge, você deve registrar o que aconteceu, porque, à medida que as fábricas aumentarem o ritmo, esse contexto será muito útil para iterar e aprimorar seu software ao longo do tempo. É isso da minha parte. Gostaria muito que vocês também experimentassem o Gitar e vissem como podem melhorar suas fábricas de software. E

19:15 com isso, muito obrigado pela atenção.

Transcrição original

[00:00] Hello everyone. Uh welcome to my talk. Uh today we’re going to be talking about how we are rebuilding CI for AI scale commit volume. And this comes from a lot of experience from build and merge infrastructure that I have been working on for a decade plus at this point. And kind of want to walk you through all the new bottlenecks we’re seeing in software factories and also specifically for highly regulated industries and banks. How does that translate? How do we keep things more compliant and auditable

[00:30] while being able to move fast? So let’s dive in. My name is Goautam. I am a co-founder and CTO at QAR and recently joined Sonar as a principal engineer. After the acquisition pre previous to I was at Uber for almost a decade working on build and merge infrastructure for mono repos. So everything from build, CI/CD, ids, you name it to make sure developers are productive. And now at QAR as part of Solar I’m trying to make sure that code that’s been checked in is

[01:01] verified and all the code written by agents is of high quality before it goes in. So before I get started I want to just paint a bit of history picture. Uh at Uber we had agent scale coming volume before they were agents. So what I mean by this is we had one giant monor repo and we were doing like thousands of changes a day and with very long running builds. This meant that if you just kept everything serialized and merged them one at a time so as not to break your uh

[01:33] main branch you would take a really long time up to days so 20 days in this case to make sure that everything was green. And if he skipped everything and just let everyone merge to me, we would see red main all the time because changes would conflict with each other and even though the CI would be green on one of them combined, they might actually break. So we would see like our iOS monitor would be like red all the time and that was not productive for our developers. To fix this, what we did was we made a system called summit cube which we have a paper on and we tested

[02:06] all the likely possibilities of commits that are coming in uh and making sure that we can like reduce the wait time so we can test these things in parallel. We could also predict what could break by testing all the combinations. So once we know that a PR might break, we might remove it back from the queue and let the author know that they have to go fix it before they can push it back up after rebasing. And finally like to keep the trunk clean only if it passes with all the combination of commits coming in it would be let into go directly onto the

[02:37] trunk. So you want to make sure that the overhead was worth it for keeping our trunk clean. And this is still running today at Uber. I’m sure now we have like merge cues that GitHub came up with and all the other code hosts but for back then there was not a system. So we developed this. [snorts] So the problem with this approach is currently all these cues that we have. So that’s either PCI or review are a centralized bottleneck in the SDLC. So all these cues were built for human speed and once you build it from human speed what happens is they are not able

[03:08] to keep up once you go to agents because humans generate changes used to generate changes like few times an hour. So we could do testing and review one at a time. Now with agents developers are writing like several PRs uh in many in a day and they don’t always wait for the queue they all want to like come in at the same time which means your CI and review cues are piling up and having pressure and add to that like the patterns of software factories and background agents triggering on like

[03:39] various workflows suddenly you see like everything slowing down to a crawl because your bottlenecks are still going BCI in review and they’re over capacity in this So what does this mean uh for teams today? Right? So just to put things into perspective uh our own uh rate of commits has almost like 10xed since we started guitar uh about 3 years ago and it’s just like uh unbelievable with the same size team we’re still very small we’re able to like push so much more

[04:10] code uh and we even see this in the industry trends on guitar. So this graph shows you the number of PRs that we see that guitar reviews over time. And if you look at the growth trajectory, it’s pretty exponential. Every month almost we’re growing 25% month over month of just the amount of PRs that have to review fixed CI and other things. So this is also I think like corroborated by evidence that industry players like GitHub have been putting out where they’re seeing like uh staggering growth in PRs and this is now coming for every

[04:41] single team not if our small team is seeing this I’m sure like the larger teams and banks are seeing it like at a much higher degree as they are going through their AI adoption journeys. [snorts] So the problem I was talking about right so if agents are opening PRs and if you make them uh check everything through the CI system uh individually they might pass but once you kind of merge them back on domain your truck might still be broken. So how do you like solve for this like how do you keep things green uh at this high rate of pace right so this is very important

[05:13] kind of like how we solve submit Q the changes themselves are not uh testing against each other so there needs to be some sort of change in either the CI system as well as how you architecture code and in the cues to be smarter to be able to solve this and the problem we’re also seeing with everyone trying to adopt like software factories which is having agents write all the code uh from the spec and then just having humans be responsible for the spec and review is that the factory line that exists today was built for

[05:44] human speed as I mentioned which means that as agents push more changes uh every part of the factory line is going to be slowing down. So for example with build and test you might have lots of rebuilds whenever uh compilation breaks or you might have integration tests you might have flaky tests that are not reproducible locally and that just slows everything down. So because you have to retry them and it could take hours in many cases with a complex build. Add to the fact that now you have review and approval. So a lot of you probably

[06:15] already use like AI to review your code. Hopefully uh you’re not doing every single review with with humans. You ideally are reviewing with AI as a first pass. Now the reviewers become the cue if you don’t have that system in place. And even after you review, there might be some criteria you might want additionally to make sure that it’s approved fully because what’s happening now in the industry is a lot of folks are just rubber stamping them because they cannot keep up with the high rate of PR. They were relying on other signals now to be able to just get through. So the process has to change.

[06:46] And the other problem right now we’re having is like a lot of these checks are running. There’s uh a lot of records that we keep that are expiring. So like your old logs don’t exist as they expire out. There is no stamp of like what was actually checked because there is like just an approval stamp. So there needs to be some record of these things for auditability and compliance checks to happen. The other issue we’re seeing is that as the code volume increases the time taken for repair also is adding a ton of

[07:18] overhead. Uh what we see on our platform at least 13% of PRs had a recorded CI failure. This is just one or more CI failures. Which means in all these cases there is a separate round trip to go either back to the developer machine or for an agent to understand the logs root cause of failure fix it push another commit and then keep iterating till it’s green. And this is just CI because most of the time if a human reviewer wants to look at a PR they’re not going to take a look unless CI is green because that’s

[07:48] the first line of defense. So that also like slows uh the review process because they can’t go in parallel because usually we want to look at something once it’s finalized and every lab is now paying for review. So if your review comments come in and you’re doing another pass same at break again and it kind of like repeats the cycle. So how do we make this better like what what do we do to make this problem more manageable as agents are pushing down more code. So we have discovered this uh

[08:19] obviously back to but also in guitar steam right now. But the most obvious thing is of course like make your CI really quick and fast which means that you may want to like remove a lot of the expensive checks. Try to offload them to like post merge even and try to make the CI step itself really quick because your repairs will be much more efficient. So you can paralyze things, you can chart, you can do like uh caching. And we’ll talk about some of the techniques that we have used as well. You also want to make sure the review is fast. So not

[08:49] just like a deep review, but you also want to have maybe multiple passes that are like giving quicker signal to your developers. So they’re able to like use them as a way to understand in what scenarios they may want to go deeper for higher risk changes or maybe for like lower risk ones even like let the AI approve and merge them. And for the checks that are already running in CI, if you can move them to the left, it’s way cheaper to catch them. And this actually uh is very relevant to checks that happen even past CI. For example, you might have like expensive regression

[09:21] tests or like things that might fail in production. Uh not every time it’s possible to like move things to the left, but as much as possible, if you can move them, it means you have less bottlenecks down the line. And locally, agents have done more context anyway to fix the issue that they’re facing. And you also want to have policies. This is very important for regulated industries. So a story we have at Back at Uber is we lost like the license to operate in London because there was a glitch in the software that allowed drivers to get on the platform without all the proper

[09:51] checks and that was because of a feature flag change. So we had to put in a process in place so that every change affecting London that was going through the SDLC would need some sort of like a a lineage of okay does this change affect London? If so, what are the controls in place and we were able to win our license back? Now, a lot of you might be facing these kind of like challenges where agents just make it much harder to understand what’s happening in your codebase. So, how do you ensure your policies are actually being respected? So, you need to have a way to like enforce these rules beyond

[10:23] CI like just because the code compiles doesn’t mean that it’s following a particular specifications. It could be like HIPPA. It could be like uh Tora. There’s so many other policies that these agents are not going to be aware of unless your agents are enforcing it on the other end. And also you want to make sure that you record that it was enforced for auditability. So just a quick story about how we made our CI faster as well. So we were at a baseline, we were I would say like still fast but like very annoying when you’re

[10:54] trying to like push more code. uh we were around like 10 minutes for our CI and we wanted to like bring that down significantly. So we started think looking at how can we cache outputs uh we use rust for our build system. So we started like caching as much as possible and reusing them. And we also looked at ways to like reduce churn in the compiler. So we added some more fixes to like ensure that the compilation part is more cachable and is invalidated less often. And by adding more fixes on top of this, by sharding and by removing

[11:24] like these overheads, we’re able to bring the time of CI almost like less than a minute for incremental steps, which means once the cold CI is warmed up, incremental builds are way way quick quicker and we can push a ton more code. The other issue is also review. So just because the CI is green, what was funny was when we were measuring our uh P90 time of like PRs making into production, the vast majority of time was spent in review back at Uber and even today to be honest like most teams spend more time

[11:55] reviewing code and doing other kinds of testing before they are comfortable merging the code into main. So this is something that needs to be addressed on top of CI as well because right now what’s happening is agents are of course like generating code at the same time the AI agents are also like finding issues on on your uh code review system and these automated reviews are also findings that you would have to now go back and address. So either you have to pull context locally for your agent or have an agent on CI iterate and fix and

[12:28] humans are able to review whatever is left after the AI took its first pass. And this needs to be part of the equation so you’re not wasting precious human cycles on more and more agent generated PRs. Uh here’s an example for us. Uh we were refactoring our code base to have faster CI. So we were using next text to parallelize our uh tests and we had this like shared database that we were spinning up to make sure that we could set it up once and all our database

[12:58] tests would reuse it. But the problem was that there were some guards we didn’t put in place which meant that when CI gets very busy uh there is like uh crosscontamination and test might become flaky. Guitar actually is a code reviewer. It caught it on our PR before we merged it. So we didn’t have to waste time after. And GAR also fixed the issue for us because it suggested the fix, committed it, and added the engineer as a co-author. By doing this, we’re able to like prevent expensive mistakes before the code made it all the way into main. The other thing that we do at Qar

[13:31] uh interestingly and as we see more and more of our customers start doing is we’re using policies and criteria to decide when is it appropriate to actually even like approve changes. There’s a lot of changes that are like routine or lower risk documentation dependency bumps of course if they’re not breaking any APIs security patches uh even things like uh lower risk changes for internal tooling that can potentially be auto approved. Uh so guitar supports these things out of the box and you can also add additional

[14:01] custom rules which are plain English that you can use to like create the approval and merge on and we are seeing like teams uh who are like very AI native starting to adopt these more and more. We see I think on our platform the rate at which folks are adopting like the auto approval and automerge grow really quickly across teams even from large teams to like 100 plus,000 plus developers. So here’s an example of approval policies. So if it’s a dependency bump and doc changes, we should be approving them. Any changes under sensitive stuff like payments or o

[14:34] might need a human approver on top. And then of course you don’t want to have the agent who made the change approve its change because that would not be uh zero trust. So in this case as agents are generating PRs the PRs are getting approved. When there is a new change that doesn’t meet the criteria then we would have to escalate to another approver. And this can be done with your own agents of course but also gitas out of the box if you want to try it. And the other problem with uh just

[15:04] relying on CI today is that just because CI is green as I mentioned doesn’t mean the code is compliant in many cases. So in this case uh the CI is passing and there is some metadata that we have about it on the rerun a flaky test uh is going to fail which means that when you force push to fix that thing now the branch is pointing at another piece of code. So the problem with this is that over time most CI data is going to be expired. So unless you have a record of

[15:35] what happened and what was fixed, you will not be able to like be compliant or be able to audit what actually happened. Which is why I think things like agent trajectories and like your uh outcomes after each push are very very important. So whatever information you can record on the PR or any other system of record is going to be a source of truth as your artifacts expire. So the control here is making sure that the change was approved and tested by someone who did not write it. If you don’t have that information, it could be

[16:05] a problem. So here’s an example. We have a pipeline that failed in the left and a pipeline that passed. But the difference here is that if you record properly why the failure occurred and someone else was able to approve it because it was a known failure mode and [snorts] it was saved with the change that made it in. This thing actually passes your checks versus something where you don’t have a record of what happened but you just blindly trust the agent pushing code because it could be a test that was actually uh not high quality. There was

[16:36] no record of all the compliance checks that were like recorded. So you want to make sure that on the uh more sensitive uh industries you want to have all of these decisions recorded as rules or compliance checks on top of your PR in addition to code review. So the what are some of the kinds of records that we want to keep. So here’s a few that we keep on which I think are just examples. It could be different for folks. So for example, which coding agent made uh the PR? Where did the PR

[17:08] originate from? What was the session that originated it? And who actually started it? Could it be a trigger from like automated workflow or could it be just an engineer doing prompting? And for each of these like CIS that run, what is a commit where CI was trusted and a save test report, not just a status? And making sure that each finding has like a record of how it was resolved. Was it dismissed? Was it followed up? Was it like fixed on the PR? And then making sure the approver is someone a apart from the bot that was

[17:40] prompted by the same person. And making sure that any overrides are explicitly named. So if there is a red build or like a control code coverage skipped, you want to make sure there’s a reason for when why that check failed and why we’re okay with that in that scenario. And making sure that the code that merges actually has all this and it’s not like a small change on top that was merged. So all the checks are done every single time. So in this case we want to make sure that agents cannot approve their own changes. Engineer who prompted it is also not an author. And if you have

[18:12] these practices in place now we can actually start removing some of these bottlenecks because the CI being faster will unblock your builds. So your flow is much nicer and making sure you can like move some checks left will also make sure that your test load is going to be reduced quite a bit. On the CI side, if you can automate review for the most part and only escalate to humans for exceptional cases and potentially even auto approve lowrisk or internal changes, then you remove further

[18:43] bottlenecks and then you have less that has reaching humans uh for a software factory to perform to its uh potential. And of course after every single approval and merge you want to record what happened because as factories are going to ramp up if you don’t have an idea of what happened in the past that context is going to be very useful on how to like iterate and make your software better over time. Uh that’s it for me. Uh would love for you folks to also try out guitar and see how you can improve your software factories. And

[19:15] with that uh thank you so much for for your