Código gerado por IA já compete com código humano — Daksh Gupta, Greptile

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: AI-Generated Code Is Already Competing With Human Code — Daksh Gupta, Greptile · Canal: AI Engineer · 12:22 · Assistir no YouTube

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

Resumo

Daksh Gupta, cofundador da Greptile, apresenta dados sobre o uso de agentes autônomos de programação em empresas. A análise de mais de um milhão de pull requests por mês indica que cerca de um quarto deles é total ou majoritariamente gerado por IA, e essa proporção cresceu rapidamente. Nas métricas analisadas — reversões, comentários de revisão e ciclos até a aprovação — o código gerado por agentes teve qualidade semelhante à do código humano, embora os tipos de falhas variassem entre agentes. A palestra termina com uma proposta de validação baseada em verificar contratos de usuário, prevenir violações e confirmar se o código atende à intenção descrita.

Pontos-chave

A evolução da programação com IA passou da conclusão de código à edição de vários arquivos e, depois, a agentes autônomos capazes de abrir pull requests.
A Greptile identificou pull requests possivelmente gerados por IA usando autoria, descrições e prefixos de nomes de branches.
Cerca de um quarto dos pull requests analisados era total ou majoritariamente gerado por IA, ante menos de 1% no início do ano anterior.
As taxas de reversão foram semelhantes entre agentes e pessoas; no estudo, as pull requests do Codex foram revertidas cerca de uma vez a cada mil.
Em comentários de revisão e número de ciclos até a aprovação, os resultados de agentes e pessoas também foram parecidos.
Os agentes apresentaram diferentes padrões de falha: por exemplo, Claude teve maior propensão a erros de SQL injection que as pessoas.
A Greptile propõe avaliar se uma mudança viola o contrato de usuário, aumenta o risco de violações futuras ou cumpre a intenção descrita.
Quase um quinto das pull requests revisadas pela Greptile foi aprovado sem revisão ou testes humanos.

Capítulos

Início	Capítulo	Resumo
00:12	Da conclusão de código aos agentes autônomos	Daksh Gupta descreve a evolução da programação com IA e a chegada de agentes capazes de criar pull requests completos.
02:48	Como estimar o uso de código gerado por IA	A Greptile usa sinais como autoria, descrição e nome de branch para estimar a proporção de pull requests geradas por IA.
05:26	Comparação da qualidade das pull requests	A palestra compara reversões, comentários de revisão e ciclos de aprovação entre código de agentes e código humano.
08:36	Padrões de falha e uso em empresas	Os dados mostram diferenças nos tipos de erro dos agentes e sustentam seu uso em ambientes empresariais.
10:44	Validação de código em escala	Gupta propõe validar contratos de usuário e intenção, recorrendo a agentes que executam o código em um sandbox.

Citações

Cerca de um quarto de todas as pull requests que a Greptile revisava em qualquer mês era total ou majoritariamente gerado por IA. — 04:23

De modo geral, as pull requests geradas por pessoas tinham qualidade aproximadamente igual à das geradas por agentes. — 07:03

As evidências parecem indicar que esses agentes chegaram e podem contribuir de maneiras realmente significativas em ambientes empresariais. — 09:40

A mudança viola o contrato de usuário? Aumenta a probabilidade de uma violação futura? Cumpre a intenção descrita pelo autor? — 11:17

Conceitos e entidades

Daksh Gupta (pessoa): Cofundador da Greptile e palestrante que apresenta dados sobre agentes de programação.
Greptile (empresa): Empresa que analisa pull requests com agentes de IA e compartilha dados sobre sua qualidade.
Codex (ferramenta): Agente de programação citado na comparação de pull requests geradas por IA.
Claude (modelo): Modelo citado na análise de padrões de falha, incluindo erros de SQL injection.
Devin (ferramenta): Agente de programação cujas pull requests foram comparadas às de pessoas e de outros agentes.
agentes autônomos de programação (conceito): Sistemas que recebem uma tarefa de programação e podem implementá-la e abrir pull requests.
contrato de usuário (conceito): Comportamento esperado de uma aplicação que a validação de código deve preservar.

Tradução completa (pt-BR)

00:12 Como vocês estão? Ótimo. Meu nome é Du. Sou um dos cofundadores de uma empresa chamada Gravile. Na Grapile, estamos trabalhando em agentes de IA que validam pull requests com todo o contexto do codebase. A maneira como a Graval faz isso é: sempre que há um pull request, temos um enxame de agentes que analisa cada arquivo alterado e cada arquivo relacionado aos arquivos alterados para descobrir se há bugs. Eles também iniciam seu código em um ambiente isolado, instalam as dependências, iniciam o

00:42 host local, clicam por aí para tentar quebrar as coisas, simulam entradas e fazem todo o resto para descobrir se o código está quebrado. Mas vou falar de algo um pouco diferente: agentes de programação totalmente autônomos. Mudei-me para San Francisco há três anos para trabalhar com programação por IA. Isso porque o GBT 3.5, lançado em 2022, foi o primeiro modelo que parecia realmente bom em programação na época. A principal forma de programar era o preenchimento automático de código e de tabulações.

01:13 A coisa mais empolgante que estava acontecendo era o preenchimento automático por tabulação do cursor e o preenchimento automático de código do Copilot. Era assim que funcionava a programação por IA. Em 2024, pela primeira vez, a edição de vários arquivos começou a funcionar. Cursor foi o primeiro a fazer isso, e alguns outros produtos vieram em seguida. Mas, pela primeira vez, a IA podia editar vários arquivos simultaneamente. As coisas ficaram realmente interessantes em 2025 porque, pela primeira vez, tínhamos agentes autônomos. Era possível dar uma tarefa a eles, e eles podiam executá-la e criar pull requests inteiros de uma só vez. E

01:43 isso chegou a um ponto culminante em dezembro do ano passado, quando os agentes de programação se tornaram literalmente totalmente autônomos. Qualquer pessoa que trabalhe com programação por IA sabe que dezembro, quando os novos modelos foram lançados, foi uma espécie de divisor de águas na história da programação por IA, porque, pela primeira vez, esses produtos eram realmente autônomos na forma como programavam. E o Twitter estava cheio de histórias malucas de pessoas que colocavam esses agentes para trabalhar e abriam 100 pull requests por dia. Elas estavam experimentando o sono polifásico para conseguir ficar acordadas e reativar os agentes de tempos em tempos. E

02:14 Como alguém que começou a programar antes dos agentes, eu era muito cético quanto à possibilidade de empresas de verdade programarem dessa forma. Então, estava muito curioso: esses pull requests totalmente gerados por IA são realmente bons? Isso é só uma onda de hype no Twitter, algo que desenvolvedores independentes e talvez pequenas startups sem clientes de verdade podem fazer? Mas empresas com clientes de verdade e um codebase comercialmente viável conseguiriam usar esses agentes de programação de ponta a ponta? Na Grubile, temos a sorte de trabalhar com algumas empresas muito grandes. Trabalhamos com a Nvidia, a Coinbase, a Scale,

02:48 a Data Dog e a American Express. Ficamos muito empolgados para descobrir se esses agentes de programação estavam sendo usados de verdade nessas grandes empresas e se eram bons em programar no mundo real. Então, como cientista de dados amador, decidi investigar nossos dados. Analisamos mais de um milhão de pull requests por mês e costumamos obter muitos dados interessantes sobre o que há de bom e de ruim nesses pull requests. Fazemos isso para milhares e milhares de empresas, geralmente grandes empresas ou, pelo menos, empresas com produtos sérios e clientes reais. Então, pensamos que

03:20 estudar esses dados produziria resultados realmente interessantes. Foi surpreendentemente difícil descobrir, entre todos os pull requests analisados pela GR, quais tinham sido gerados por IA. A primeira coisa que tentei foi olhar o campo de autor do GitHub. Todo commit no GitHub tem um campo de autor, então examinei os autores e descobri que menos de 1% dos pull requests tinham codex, clawed ou cursor como autor. Mas não me parecia intuitivo que apenas 1% de todo o código fosse totalmente gerado por IA. Simplesmente parecia intuitivo que esse número

03:52 fosse muito maior. Então, comecei a procurar outros sinais. Felizmente, Claude, Codex e alguns outros produtos deixam uma descrição do PR no rodapé. Na descrição do PR, eles colocam algo como “coautorado por claude” ou “coautorado por cursor”, e assim por diante. Isso me deu um pouco mais de sinal, um pouco mais de dados sobre quais PRs eram, supostamente, em grande parte, se não totalmente, gerados por IA. A terceira coisa que examinei foram os prefixos dos nomes de branch. Se você usa o Codex, sabe que ele dá nomes às branches. E me pareceu razoável que, se alguém estivesse usando esses agentes de programação a ponto de eles escreverem

04:23 os nomes das branches ou as descrições dos PRs, então os PRs seriam em grande parte gerados por IA. Essa me pareceu uma suposição razoável. Assim, passei a ter um bom conjunto de sinais para indicar se um pull request era, de fato, total ou majoritariamente gerado por IA. Cheguei à conclusão de que cerca de um quarto de todos os pull requests analisados pela Graal em qualquer mês eram totalmente ou, pelo menos, majoritariamente gerados por IA. Depois, voltei aos dados dos últimos 12 meses e descobri que esse número está crescendo muito rápido. Na verdade, no começo do ano passado, menos de 1% dos pull

04:54 requests tinha qualquer evidência de ter sido totalmente gerado por IA. Portanto, esse número está crescendo muito, muito rápido à medida que o desempenho dos modelos melhora. Outra coisa interessante é que não dá para identificar no gráfico quando novos modelos foram lançados. O progresso parece muito contínuo. Essas coisas estão simplesmente se difundindo pela economia em um ritmo geralmente alto. Então veio a próxima pergunta. Todo mundo está fazendo vibe coding. Todo mundo está produzindo esses PRs que são antienticos. Não são humanos mais IA, mas literalmente IA. A pergunta é: esses PRs são bons? Primeiro: o que significa um PR ser bom? Essa parecia, na verdade, uma pergunta muito importante

05:26 para responder antes de começarmos a avaliar esses PRs gerados por IA. Então, usei alguns métodos para tentar descobrir. O primeiro que experimentei foram as taxas de reversão. Se um pull request era revertido, provavelmente era bem ruim. Parecia uma estimativa bastante honesta do que poderia ser um PR ruim. Então, comecei a acompanhar quais PRs eram de fato revertidos. O GitHub dá nomes convenientes às branches no formato revert-traço-número do PR e nome do PR. Assim, consegui acompanhar a taxa de reversão dessas coisas. E encontrei dados interessantes. Cerca de um em cada mil pull requests do Codex é revertido. O Devon,

06:00 uma vez a cada três mil e quinhentos pull requests. Os humanos ficam no meio, com cerca de dois e meio. Portanto, no meu estudo, não parece haver uma diferença muito grande entre a taxa de reversão dos pull requests feitos por pessoas e a dos feitos por agentes. Eu era bastante cético quanto a isso e pensei: tudo bem, provavelmente é porque os humanos deixam os agentes fazerem o trabalho mais fácil, os pull requests mais simples e bem delimitados, enquanto os humanos fazem o trabalho mais complexo. E, claro, o trabalho complexo tem maior probabilidade de ser revertido, porque os pull requests são mais complicados, têm uma área de impacto maior, mais riscos e assim por diante. Então, decidi medir o tamanho médio dos PRs e se as taxas de reversão

06:33 estavam mais ou menos alinhadas nos dois casos, e encontrei dados realmente interessantes. Acontece que há pouquíssima correlação, se é que há alguma, entre o tamanho dos PRs feitos por humanos que são revertidos e o tamanho dos PRs feitos por agentes que são revertidos. Portanto, isso não parece ser uma evidência muito forte de que os PRs feitos por humanos sejam melhores do que os PRs feitos por agentes. O segundo conjunto de sinais que comecei a analisar foram os comentários da Graile. Agora, a Grapple está analisando todos esses pull requests, e a Graile identifica problemas P0, P1 e P2 em todas essas alterações. Parecia razoável que, se a Grapile

07:03 encontrando mais bugs no código, provavelmente o código era pior. Então comecei a acompanhar a quantidade de P0, P1 e P2 em todas essas mudanças. E, curiosamente, mais uma vez, não havia tanta diferença. Na verdade, três dos quatro agents que testamos tiveram desempenho melhor do que os humanos em termos da taxa de produção de P0. Eles produziam menos P0 do que os humanos. O mesmo aconteceu com P1 e P2. De modo geral, PRs feitos por humanos tinham qualidade mais ou menos igual à de PRs feitos por agents, com base nesses

07:33 dados. Peça ao agent para analisar esses comentários, resolvê-los e fazer um novo commit na branch do pull request. Essa é a maneira mais comum de usar o Greptile. Portanto, parece razoável que, se os pull requests tivessem qualidade mais alta, fossem necessárias menos iterações até serem mesclados. Então comecei a acompanhar o número de iterações, o número de rodadas de revisão entre a abertura do pull request e sua mesclagem.

08:04 Como esperado, a diferença foi muito pequena. Os PRs do Devin tiveram 2,1; os PRs do Codex, 2,45; quatro, cinco ciclos de revisão até a mesclagem, e os humanos ficaram bem no meio. Mais uma vez, houve pouca ou nenhuma diferença estatística entre pull requests feitos por humanos e por IA em termos de quantas iterações eram necessárias até estarem prontos para serem mesclados. Como não havia evidências fortes de que PRs feitos por agents fossem piores do que os feitos por humanos, fiquei curioso para saber se havia diferenças qualitativas. Talvez os tipos de falhas dos agents fossem diferentes dos tipos de falhas dos humanos.

08:36 Então analisei o conjunto de comentários que o Greptile faz. Em média, ele faz cerca de quatro comentários por pull request. Portanto, tínhamos um conjunto de vários milhões de comentários dos últimos meses. Comecei a procurar nele frases e palavras específicas, como injeção de SQL ou consulta N+1. Depois, representei em um gráfico a frequência com que esses termos apareciam nos comentários do Greptile para esses vários agents. Assim, criei este gráfico de padrões de falha. Para interpretar o gráfico, considere que 1x representa a propensão humana a produzir esse tipo de erro ao longo de todo o

09:08 gráfico. Dá para ver que, na verdade, há bastante variação nos tipos de falhas que esses agents parecem produzir. Por exemplo, Claude tem uma probabilidade uma vez e meia maior do que os humanos de produzir um erro de injeção de SQL. Devin tem cerca de metade da probabilidade dos humanos de produzir um problema de desvio de autenticação. Achei muito interessante haver tanta variação no desempenho desses agents e os modos de falha deles serem tão diferentes dos dos humanos. Então, apesar do meu

09:40 ceticismo inicial quanto à usabilidade empresarial dos agents de programação de ponta a ponta, as evidências parecem indicar que eles vieram para ficar e provavelmente podem contribuir de maneiras realmente significativas em ambientes empresariais de programação. Então começamos a pensar um pouco mais sobre como seria a revisão de código nesse mundo. Aqui vai uma estatística interessante. Hoje, várias dezenas de milhares de engenheiros usam o Greptile toda semana para revisar todo o código que produzem. Também sabemos, em geral, quantos pull requests cada uma dessas pessoas escreve. O usuário mediano do Greptile escreve 50 pull requests por

10:14 mês. Ou seja, cerca de dois ou mais por dia útil. O percentil 90 escreve 500 pull requests por mês. Há uma diferença enorme entre a mediana e o P90. O P99 está na casa dos milhares de pull requests. Isso é muito interessante por si só, porque significa que as pessoas nos extremos estão produzindo pull requests no ritmo em que têm novas ideias. Além de ser interessante, isso também faz você se perguntar se os sistemas existentes para validar esse código — revisão manual de código, claro, testes, talvez uma empresa de QA com a qual você trabalhe —

10:44 conseguem naturalmente escalar nesse mesmo nível. Na Greptile, decidimos adotar uma abordagem de primeiros princípios para pensar no que seria uma validação realmente boa. Em vez de dizer que queríamos automatizar QA, testes ou revisão de código, demos um passo atrás e perguntamos: o que seria necessário para que qualquer pessoa pudesse mesclar centenas de pull requests por mês em um ambiente empresarial, onde é muito importante que o código esteja correto? O que precisaria acontecer entre o momento em que o código é apresentado em um pull request e o momento em que ele é mesclado e colocado em produção com segurança? Concluímos que, na verdade, só precisávamos responder a três perguntas. A primeira: essa mudança viola o contrato com o usuário?

11:17 A segunda: ela aumenta a probabilidade de uma violação futura do contrato com o usuário, seja qual for o contrato com o usuário daquela aplicação? E, terceiro: ela atende à intenção descrita pelo autor? O pull request fez o que o autor queria? Então começamos a abordar esse problema desde os princípios básicos e dissemos: certo, provavelmente os agents conseguem descobrir se algo vai violar o contrato com o usuário e detectar bugs. Se você os deixar iniciar o código em um sandbox, instalar as dependências, simular as entradas e executar os agents de navegador, provavelmente poderá começar

11:47 a descobrir a maioria dos problemas que poderiam ocorrer e obter um grau bastante alto de confiança na mesclagem. Hoje, quase um quinto de todos os pull requests, ou das revisões do Greptile, é mesclado sem revisão humana ou sem testes feitos por humanos. Acho isso muito interessante. É um número com o qual nos importamos bastante e que queremos aumentar cada vez mais, claro, dentro dos limites necessários para produzir código de altíssima qualidade. Muito obrigado. Meu nome é Daksh, um dos cofundadores da Greptile. Temos um estande aqui, onde vocês deveriam passar. Se tiverem interesse em experimentar a Greptile, podem nos encontrar em greptile.com e testá-la gratuitamente hoje mesmo. Adoraríamos ouvir

12:22 o feedback de vocês. Muito obrigado.

Transcrição original

[00:12] How’s everyone doing? Awesome. Uh, my name is Du. I’m one of the co-founders of a company called Gravile. And at Grapile, we’re working on AI agents that validate poll requests with full context of the codebase. The way Graval does this is every time there’s a pull request, we have a swarm of agents and they go and look at every file that’s changed, every file that’s related to the files that changed to figure out if there’s bugs. And it also spins up your code in a sandbox, installs the dependencies, spins up

[00:42] local host, clicks around to try to break things, mocks inputs, and everything else to figure out if the code is broken. But I’m going to talk about something a little bit different, which is fully autonomous coding agents. So I first moved to San Francisco three years ago to work on AI coding. And this is because GBT 3.5 which came out in 2022 was the first model that seemed like it was really good at programming at the time. Code complete tab complete was like the main paradigm for coding.

[01:13] The most exciting thing that was happening was you had tab complete from cursor and you had co-pilots code complete and that was like the way in which AI coding works. In 2024, for the first time, multifile editing started to work. Cursor was the first to do this and then a couple of other products followed. But now, for the first time, AI could simultaneously edit multiple files at once. But things got really interesting in 2025 because for the first time, we had autonomous agents. They could be given a task and they could go and fulfill the task and create entire pull requests all at once. And

[01:43] this came to a precipice in December of last year when coding agents became literally completely autonomous. And anyone that’s working in AI coding knows that December when the new models came out was sort of this like watershed moment in the history of AI coding because these products for the first time were like truly autonomous in how they programmed. And all over Twitter were all these crazy stories of people that were having these agents spin off and open a 100 pull requests a day. They were experimenting with polyphasic sleep so they could stay awake to re-trigger their agents from time to time. And as

[02:14] someone that started programming before agents, I was very skeptical that real companies could program this way. So I was really really curious, are these fully vi PRs really actually good? Is this something that’s sort of a Twitter hype and you can have independent developers and and maybe like small startups with no real customers do this? But anyone with real customers with an actually commercially viable code base, could they still use these end-to-end coding agents? And at Grubile, we’re fortunate to work with some very large companies. We work with Nvidia, with Coinbase, with Scale,

[02:48] with Data Dog, with American Express. And we got really excited to see if these coding agents were being used really at these large companies and if they were any good at doing real world coding. So, as an amateur data scientist, I decided to go and dive into our data. We review more than a million poll requests a month and we tend to get a lot of interesting data on what’s good and bad about these poll requests. We do this for thousands and thousands of companies and they’re usually enterprises or at least companies with serious products with real customers. And so we figured

[03:20] actually studying this data would yield some really interesting results. Was a surprisingly hard to figure out from all the poll requests that GR was reviewing which of the poll requests was actually generated by AI. Surprisingly difficult to do this. The first thing that I tried was I started looking at the GitHub author field. GitHub every commit has an author field and so went through the authors and turns out that less than 1% of pull requests had codeex or clawed or cursor as the author. But it wasn’t intuitive to me that only but 1% of all code was fully AI generated. It just seemed intuitive that that number would

[03:52] be much higher. So I started to look for other signals. Now thankfully Claude and Codex and some other products leave a PR description in the footer. In the PR description, they put something along the lines of co-authored by claude or co-authored by cursor and so on. And this gave me a little bit more signal, a little bit more data on which PRs were ostensibly largely, if not completely AI generated. The third thing I looked at was branch name prefixes. If you use Codex, you know that Codex names as branches. And it seemed reasonable that if someone was using these coding agents in such a sense that they were writing

[04:23] the branch names or writing the PR descriptions that the PRs were largely AI generated. That seemed like a reasonable assumption to me. So now I had a good set of signals to indicate whether a poll request was in fact completely or largely AI generated or not. And I came to the result that about a quarter of all the poll requests that Graal was reviewing in any given month were completely or at least largely generated by AI. Then I backtracked this data to the last 12 months and it turns out that this number is growing really fast. In fact, early last year, fewer than 1% of pull

[04:54] requests had any evidence of being completely AI generated. So this number is going very very fast as model performance is getting better. What’s also interesting is that you can’t tell when new models came out on this chart. It seemed like the progress is very continuous. These things are just generally diffusing into the economy at a generally high pace. So then came the next question. Everyone’s vibe coding. Everyone’s producing these PRs that are antiendentic. Not human plus AI but literally AI. The question is are these PRs any good? First question, what does it mean for PR to be good? That seemed like actually a very important question

[05:26] to answer before we got into judging these AI generated PRs. And so I took a few methods to try this. The first one I tried was revert rates. If a pull request reverted, it was probably pretty bad. And so that seemed like a pretty sincere sort of guess at what a bad PR could be. And so I started tracking, okay, which PRs were in fact reverted. GitHub conveniently names its branches with a revert dash PR number and PR name. And so I was able to track the rate at which these things were being reverted. And I found some interesting data. Codex PR is reverted about one out of every thousand poll requests. Devon

[06:00] once every three and a half times every thousand poll requests. Humans right in the middle at about two and a half. So there doesn’t seem to be very big difference between the rate at which poll requests were reverted from people versus agents in my study. Now I was very skeptical of this and I figured okay this is probably because humans are making agents do the easier work the simpler well scoped pull requests and the more complex work was being done by humans and of course complex work had a higher propensity to be reverted because the poll requests were more complicated had larger surface areas risks and so on. So I decided to measure the average size of PR and whether the revert rates

[06:33] were sort of aligned for both of those and I found really interesting data. Turns out there’s actually very little correlation, if any, between the size of PRs of humans were getting reverted versus size of PRs from agents that were being reverted. So this does not seem like actually very strong evidence that the human PRs are any better than the agent PRs. The second set of signals I started looking at was Graile comments. Now, now Grapple is reviewing all these poll requests and Graile finds P 0’s, P1’s, P2s across all these changes and it seemed reasonable that if Grapile was

[07:03] finding more bugs in the code that the code was most likely worse. So then I started tracking the counts of P 0, P1’s and P2s in all these changes. And interestingly, once again, there was not that much of a difference. In fact, three out of the four agents that we tested performed better than humans in terms of the rate at which they were producing P 0. they were producing fewer P 0 than humans were. Similarly the case with P1’s and P2s. Broadly speaking, human generated PRs were about equal in quality to agent generated PRs based on

[07:33] this data. have the agent go and look at those comments, address them, and make a new commit on the pull request branch. That is the most common way to use guptile. And so it seems reasonable that if the pull requests were higher quality, it would require fewer iterations before they would be merged. And so I started tracking the number of iterations, the number of review rounds between when the poll request was opened and when it was merged.

[08:04] Sure enough, very little difference. Devon’s PRs 2.1, Codex PR is 2.45, four, five number of review cycles to merge and humans right in the middle. Once again, very little if any statistical difference between human generated and AI generated pull request in terms of how many iterations before they were ready to merge. So now that there wasn’t any strong evidence that agent generated PRs were worse than human generated PRs, I got curious if there were qualitative differences. Maybe the types of ways in which agents failed were different from the types of ways that humans failed.

[08:36] And so then I looked at the corpus of reptiles comments. It makes on average about four comments per pull request. So we had this corpus of several million comments across the last several months. And so I started scanning them for specific phrases and words. For instance, SQL injection or N plus1 query. And I plotted the frequency with which these terms occur in graphile comments for these various agents. And so I made this chart of patterns of failure. To interpret this chart, you can assume that 1x is the human propensity for producing that type of error across the

[09:08] entire chart. And you can kind of see that there’s actually quite a lot of variation in the types of failures that these agents seem to produce. For instance, Claude is one and a half times more likely to produce a SQL injection error than humans. Devon is about half as likely as humans to produce a off bypass issue. I found it very interesting that there was this much variation in how these agents were performing and how different their failure modes were from humans. So it turns out that in spite of my

[09:40] initial skepticism around the enterprise usability of endto-end coding agents, the evidence seems to suggest that they’re here and they probably can contribute in real meaningful ways to enterprise coding environments. And so we started to think a little bit more about what code review would look like in such a world. Here’s an interesting stat. Today, Graal is used by several tens of thousands of engineers every single week to review all of their code. So, we also know generally speaking the number of pull requests that each of these people are writing. The median grubile user writes 50 pull requests a

[10:14] month. So, call it about two plus per workday. The 90th percentile writes 500 poll requests per month. That is a drastic difference between the median and the P90. The P99 is in the thousands of pull requests. That is very interesting in its own sense because that means that the people on the margins are actually producing poll requests at the rate at which they’re coming up with new ideas. And beyond being interesting, it also makes you wonder well there existing systems for validating this code which is manual code review of course testing maybe you have a QA firm that you work with

[10:44] naturally can scale to that same degree. And at Grav, we decided to take sort of a first principles view at what really good validation could look like. Instead of saying that we wanted to automate QA or automate testing or automate code review, we took a step back and said, what would we need to do for anyone to be able to merge hundreds of pull requests a month in an enterprise environment where it really matters that the code is correct? What would need to happen between when the code was expressed into a pull request and when it was merged and deployed safely? We figured we only actually had to answer three questions. The first one is does this change violate the user contract?

[11:17] The second one, does it increase the propensity of a future violation of the user contract, whatever the user contract might be for that application? And third, does it fulfill the intent that the author described? Did the poll request do the thing that the author wanted to do? And so we started approaching this problem from base ground level and said, okay, agents can probably figure out if something’s going to violate the user contract and detect bugs. If you let it spin up the code in a sandbox, have it install the dependencies, mock the inputs, run the browser agents, you can probably start

[11:47] to discover most of the issues that could occur, you get a pretty high degree of confidence on merge. Today, almost a fifth of all the poll request or gravile reviews are merged without any human review or without any human testing, which I find very interesting and that is a number that we care a lot about and want to bring higher and higher, of course, within the guard rails of producing really high quality code. Thank you so much. My name is D, one of the co-founders of Graptile. We have a booth here which you should come to. And if you’re interested in trying Graptile, you can find us at gretile.com and try it today for free. And we’d love to hear

[12:22] your feedback. Thank you so much.