Por que a IA não fez você entregar mais rápido — Gabriel Spencer-Harper, Meticulous

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: Why AI Didn’t Actually Make You Ship Faster — Gabriel Spencer-Harper, Meticulous · Canal: AI Engineer · 10:51 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA

Resumo

Gabriel Spencer-Harper argumenta que a IA acelerou a escrita de código, mas a revisão e a verificação agora são os gargalos que limitam a entrega. A Meticulous busca resolver esse problema verificando mudanças no frontend por meio da gravação e reprodução de workflows, com comparação visual antes e depois de cada alteração. A ferramenta combina isolamento de testes, um browser determinístico e seleção de workflows baseada na cobertura de código para reduzir flakiness e ampliar a verificação. Assim, equipes podem revisar mudanças com mais confiança e dedicar menos tempo à manutenção de testes.

Pontos-chave

• A velocidade de geração de código por IA pode superar a capacidade humana de revisar e verificar as mudanças.
• Testes baseados apenas em asserções não conseguem cobrir todas as possíveis regressões e combinações de configurações.
• A Meticulous grava workflows de uso da aplicação e os reproduz em pull requests para comparar capturas de tela antes e depois das mudanças.
• A ferramenta mostra diferenças visuais, mas deixa a decisão sobre se elas são esperadas a cargo de uma pessoa ou de um agent.
• As requisições e respostas de rede são registradas e simuladas durante a reprodução para tornar os testes isolados e repetíveis.
• A Meticulous modifica o comportamento do browser para reduzir fontes de aleatoriedade e a flakiness dos testes.
• A ferramenta seleciona workflows com base nas linhas de código executadas para maximizar a cobertura da aplicação.
• A captura de tela em vários momentos de cada workflow permite detectar alterações visuais que testes com poucas asserções poderiam não identificar.

Capítulos

Início	Capítulo	Resumo
00:01	IA, velocidade de entrega e o gargalo da verificação	Gabriel apresenta a Meticulous e explica por que a revisão e a verificação de código passaram a limitar a velocidade de entrega.
03:04	Demonstração da verificação visual	A apresentação mostra como a Meticulous grava e reproduz workflows, compara capturas de tela e expõe diferenças em pull requests.
06:12	Isolamento de testes e browser determinístico	Gabriel descreve como a simulação de tráfego de rede e o controle da aleatoriedade ajudam a tornar os testes repetíveis e reduzir flakiness.
08:48	Seleção de workflows e cobertura ampla	A Meticulous mapeia workflows às linhas de código executadas e combina essa seleção com capturas em vários momentos para ampliar a verificação.

Citações

Se você tiver verificação exaustiva, poderá entregar código na velocidade em que seus agents o escrevem. — 00:32

A IA escreve código mais rápido do que as pessoas conseguem revisar. — 01:33

A Meticulous não diz se há um bug; ela mostra o que mudou na aplicação. — 06:12

Código coberto não é o mesmo que código testado. — 09:19

Conceitos e entidades

• Meticulous (empresa): Empresa que oferece verificação visual automatizada de mudanças em aplicações frontend.
• Gabriel Spencer-Harper (pessoa): Co-fundador e CEO da Meticulous, que apresenta a abordagem de verificação da empresa.
• Cypress (ferramenta): Ferramenta de testes de aplicações web usada como referência na comparação sobre flakiness.
• Playwright (ferramenta): Ferramenta de automação e testes web mencionada na comparação sobre flakiness.
• verificação visual (conceito): Abordagem que compara capturas de tela da aplicação antes e depois de uma mudança para revelar diferenças.
• determinismo do browser (conceito): Controle de fontes de aleatoriedade no browser para tornar a reprodução de testes mais consistente.
• cobertura de código (conceito): Medida usada pela Meticulous para relacionar workflows às linhas executadas e escolher um subconjunto de reprodução.
• flakiness (conceito): Inconsistência em que um teste pode produzir resultados diferentes em execuções repetidas.

Tradução completa (pt-BR)

00:01 [música] Olá, pessoal. Oi. Meu nome é Gabe. Sou um dos cofundadores e CEO da Meticulus. Vou esperar mais um minuto para as pessoas entrarem e depois podemos começar. Na demonstração ou palestra de hoje, vou falar sobre verificação de código. Vou passar um

00:32 minuto apresentando a Meticulus, depois um minuto dando um pouco de contexto sobre a empresa e, em seguida, cerca de oito minutos fazendo uma demonstração e uma visão geral técnica. Se você tiver verificação exaustiva, poderá enviar código na mesma velocidade em que seus agents o escrevem. Se não tiver, alguém na sua organização estará gastando tempo verificando código, e isso agora será o seu novo gargalo, e você ficará

01:03 forçado a escolher entre velocidade e bugs e experiência do usuário. Vou dar um contexto bem rápido sobre a Meticulus. A Meticulus oferece verificação exaustiva ou quase exaustiva da sua base de código de frontend, sem exigir esforço dos desenvolvedores. Ela está implementada em toda a organização de engenharia de empresas como Discord, Whiz, Dropbox, Notion, 11

01:33 Labs, Launch Darkly e muitas outras empresas excelentes. Então, se um engenheiro mexe no código de frontend em uma dessas empresas, ele usa a Meticulus todos os dias. Mas, antes de entrarmos no produto e falarmos mais sobre verificação, vamos abordar o estado atual das coisas. A IA escreve código mais rápido do que as pessoas conseguem revisar. A revisão e a verificação agora são o novo gargalo.

02:04 Outro aspecto do estado atual das coisas é que testes baseados apenas em asserções não são suficientes. Por mais que uma pessoa ou um agent tente definir antecipadamente o comportamento correto do software em asserções, o espaço de possíveis regressões é vasto demais para ser coberto exaustivamente. Então, uma boa pergunta para esclarecer a situação é: se um engenheiro da sua organização

02:34 gerasse este pull request com IA, você se sentiria à vontade para clicar no botão de mesclar e enviar? Na maioria das organizações, a resposta é não. Você teria que verificar todas as diferentes feature flags, funções, permissões, configurações, parametrizações e os vários casos extremos para entender o impacto exaustivo dessa alteração e ver se consegue identificar algum problema.

03:04 Há três consequências desse estado atual. A primeira são bugs ou regressões, que têm impacto nos negócios. A segunda é que organizações de engenharia vão gastar percentuais de dois dígitos do seu tempo mantendo conjuntos de testes de ponta a ponta. Somando validação manual, revisão, depuração de testes instáveis, atualização ou manutenção do conjunto de testes, todos

03:34 gastam muito tempo mantendo, mantendo, mantendo testes. E o terceiro problema, ou consequência desse estado atual, é que, se você conseguir verificação exaustiva, poderá programar de uma maneira nova e diferente. De repente, poderá atualizar todas as suas dependências, fazer refatorações abrangentes e realizar qualquer alteração gerada por IA com total confiança. Então, a pergunta passa a ser:

04:06 isso parece ótimo. Como conseguir verificação exaustiva? Como ela é e como chegar lá? Agora vou mostrar uma demonstração de como a Meticulus funciona. Só um segundo para preparar tudo. Ótimo. A Meticulus fornece uma linha de

04:38 JavaScript para injetar em ambientes que não são de produção. Ou seja, localhost, QA, desenvolvimento e staging. Esse JavaScript instrumenta o navegador da web e registra milhares ou dezenas de milhares de fluxos ou workflows. Por exemplo, alguém clicando no botão de login, no painel de configurações ou no painel de análise. Depois, quando você abre um pull request no seu runner de CI, inicia a aplicação web em localhost 3000, e a Meticulus seleciona um subconjunto desses workflows registrados e os reproduz.

05:10 Ela despacha cada evento, um por um. Enquanto despacha esses eventos — clicar no botão de login, no painel de permissões, no painel de análise —, faz uma captura de tela a cada instante atômico ao longo do tempo. Assim, gera uma sequência de capturas de tela para cada workflow: uma antes da alteração no código e outra depois. Em seguida, compara as duas sequências para mostrar o que mudaria na sua aplicação se você mesclasse esse código, antes de fazer isso. Então, neste

05:41 exemplo, há duas alterações. Uma é alguém ter mudado o nome; a outra é ter introduzido um erro em uma lista suspensa. Quando você abre um pull request, a Meticulus publica um comentário, geralmente em poucos minutos. Quando o desenvolvedor clica nesse comentário, como o Wi-Fi está lento, vou trocar de aba. Mas, quando o desenvolvedor clica nesse comentário, a Meticulus não diz se há um bug ou não. O que ela mostra é um conjunto de diferenças

06:12 que mostram o que mudaria na aplicação se você mesclasse esse código. Cada diferença tem um estado anterior e um estado posterior. Ao revisar a diferença, você pode determinar se a alteração é esperada ou inesperada. Aqui está a mudança de nome no modo claro. Aqui está a mudança de nome no modo escuro. E esta é uma manifestação desse erro lógico. Em geral, quando você escreve um teste baseado em asserções, usa seu

06:43 contexto de negócios e seu julgamento para definir antecipadamente o comportamento correto do software e codificá-lo no teste baseado em asserções. Na Meticulus, simplesmente mostramos o que mudou, e você exerce seu julgamento no momento da revisão, ou um agent faz isso. Só um segundo para voltar à tela anterior. Legal. Há três

07:14 tecnologias muito importantes para ajudar a criar um modelo mental da ferramenta, de como ela funciona e por que funciona. A primeira é que tudo é simulado. No momento do registro, registramos todas as solicitações e respostas de rede e, no momento da reprodução, usamos substitutos para elas e fazemos essa simulação por dois motivos. Um é tornar os testes idempotentes. Assim, você pode executá-los mil vezes seguidas e obter os mesmos resultados todas as vezes. O segundo motivo é que isso

07:45 significa que cada teste fica isolado de todos os outros, o que elimina o risco de condições de corrida e permite executar os testes em paralelo, horizontalmente, e obter os resultados em poucos minutos. A segunda tecnologia essencial é que, com a Meticulus, você tem muito menos testes instáveis — ordens de grandeza menos — do que com qualquer outra ferramenta, incluindo Cypress ou Playwright. Isso acontece porque modificamos o navegador desde a camada do mecanismo de agendamento para torná-lo totalmente determinístico. Quando os navegadores foram projetados, o determinismo não era um

08:17 objetivo do projeto. Por isso, há muitas fontes diferentes de aleatoriedade. Por exemplo, uma animação de carregamento depende da velocidade do relógio da CPU da máquina que renderiza o navegador ou da intercalação entre set timeout e set interval. Lidamos com toda essa aleatoriedade e tornamos o navegador determinístico, ou quase determinístico, para que você tenha muito menos testes instáveis. A terceira tecnologia, que é a mais importante para entender por que isso funciona, é que, se você quer que isso

08:48 seja exaustivo, precisa abranger todas as combinações de planos e funcionalidades, todas as permissões, todas as funções, todas as configurações e todos os caminhos possíveis pela aplicação. Como fazer isso? Uma técnica que usamos é reproduzir cada sessão ou fluxo registrado uma vez na branch principal e monitorar quais linhas de código são executadas. Depois, criamos um mapa ou índice que relaciona cada workflow individual às linhas de código executadas e escolhemos um subconjunto de

09:19 workflows que maximize a cobertura de código na sua aplicação. Normalmente — só um segundo. Normalmente, na nossa visão, a cobertura de código é uma métrica péssima para todas as ferramentas do mundo, exceto a Meticulus. O motivo é que você pode escrever um teste de Cypress ou Playwright que cubra 100% da sua base de código, mas faça apenas uma asserção. Portanto, código coberto não é o mesmo que código testado, mas, com a Meticulus, na verdade…

09:50 é aproximadamente o mesmo porque fazemos algo realmente incomum e radical: tiramos uma captura de tela em cada momento possível ao longo de um fluxo. Então, se há um fluxo de 412 etapas e existe uma diferença de um único pixel, a Meticulous vai sinalizá-la. E assim você começa a ver como todas essas tecnologias se combinam. Você só consegue fazer uma verificação exaustiva por causa desse algoritmo de cobertura de código. Esse algoritmo só funciona mesmo porque tiramos uma captura de tela em cada momento possível

10:20 Se você tira uma captura de tela em cada momento possível, está tirando dezenas ou centenas de milhões de capturas de tela. E, tradicionalmente, você acabaria soterrado pelo ruído ou por instabilidades. Então, é preciso resolver a instabilidade desde a raiz. É isso que fazemos ao aprimorar o navegador. Aqui estão algumas coisas legais que nossos clientes disseram sobre nós. E isso conclui a palestra de hoje. Se quiser saber mais

10:51 então venha ao estande LG6. Muito obrigado por ouvirem. [aplausos] >> [música]

Transcrição original

[00:01] [music] Hello everyone. Hi. Um, my name is Gabe. I’m one of the co-founders and CEO of Meticulus. Um, I’ll just wait one more minute for people to come in and then we can and then we can get started. Um so in today’s demo or talk I’ll talk about verification of code. Um I’ll spend one

[00:32] minute introducing meticulous and then one minute giving some background context on the company and then sort of eight minutes giving a demo and technical technical overview. Um so if you have exhaustive verification then you can ship code at the speed that your agents write it. If you don’t, then someone somewhere at your organization is spending time verifying code and that is now your new bottleneck and you’re

[01:03] forced into a position where you’re trading off velocity against bugs and user experience. So I’ll give um super quick context on Meticulus. So, Meticulus gives you exhaustive or near exhaustive verification of your front-end codebase with zero developer effort. Um, it’s deployed across the entire engine organization at all of these companies like Discord, Whiz, Dropbox, Notion, 11

[01:33] Labs, Launch Darkly, and many, many other great companies. So, if an engineer touches front-end code at one of these companies, they use Meticulus every every day. However, before we get into the product and talk more about verification, um, let’s just cover the current sort of state of the world. So, AI writes code faster than humans can review it. And review and verification is now the new bottleneck.

[02:04] The other state of the world is that assertionbased testing alone isn’t enough. So no matter how hard a human or an agent tries to define the correct behavior of software a priority upfront in assertions the space of possible regressions is too vast to exhaustively cover. And so a good clarifying question is if an engineer in your organization

[02:34] uh AI generated this pull request, would you feel comfortable hitting the the merge merge and ship button? And in most organizations, the answer is no. You would want to go and do the hard work of checking out all the different feature flags, all the different roles, permissions, settings, configurations, and the various different edge cases in order to understand the exhaustive impact of this of this change and see if you can spot any issues.

[03:04] So there are three sort of like downstream consequences of that current state. The first one is bugs or regressions uh which have a a business impact. The second one is engine organizations will spend doubledigit percentages of their time maintaining end to-end test suites. So across manual validation, review, uh debugging flakes or updating or maintaining the test suite, um all

[03:34] spend a lot of time maintaining maintaining maintaining tests. And then the third like problem or downstream downstream consequence of of the state of the world is that um if you if you can get exhaustive verification then you can program in a new and different way. So all of a sudden you can bump all your dependencies, you can do sweeping refactors, you can make any AI generated change with complete complete confidence. So then the question becomes

[04:06] um that sounds great. How do you how do you get exhaustive verification? What does it look like and how do you how do you get there? Um so I’ll now give you a demo of how how meticulous meticulous works. So, we give you uh give me one second to set this up. Great. Um, so we give you one line of

[04:38] JavaScript to inject onto nonproduction environments. So that’s localhost, QA, dev, staging. That JavaScript instruments the web browser and records thousands or tens of thousands of flows or workflows. So someone clicking the login button, clicking the settings panel, clicking the analytics panel. And then when you open a pull request on your CI runner, you spin up your web application on localhost 3000 and Meticulus takes a subset of those recorded workflows and it replays them.

[05:10] So it dispatches each event one by one. And as it dispatches those events, so click the login button, click the senses panel, click the analytics panel, it takes a screenshot at each atomic moment throughout time. And so it generates a sequence of screenshots for every workflow, one before your code change and one after your code change. It then diffs those two sequences together to show you what would be different about your application if you were to merge that code in before before you do. So in

[05:41] this example, there’s two changes here. One is someone’s changed the name and the second is they’ve introduced an error to a to a drop down. And so when you open a pull request, Meticulus posts a comment typically within a few minutes. And when the developer clicks into this comment, the Wi-Fi is slow, so I’m just going to switch tabs. But when a developer clicks into this comment, Meticulus will not tell you whether or not there’s a bug. What it will show you is a set of diffs

[06:12] that show you what’s different about the application if you were to merge that code in. And so each diff has a before state and an after state. And so by reviewing the diff, you can determine whether that change is expected or unexpected. So here’s the name change on light mode. Here’s the name change on dark mode. And then this is a manifestation of that logical logical error. So typically when you write an assertionbased test, you um use your

[06:43] business context and judgment to encapsulate the correct behavior of software up front and and encapsulate that into your assertion based test. In meticulous, we just show you what’s different and you exercise your judgment at review time or or or an agent agent does. Um give me one second to switch this back. Cool. Um, so there are sort of three

[07:14] technologies that are really important for helping build a mental model of the tool and how it works, how it works and why it works. So the first one is that everything is mocked out. So um at record time we record all the network requests and responses and then at replay time we stub those in and we perform that mocking for two reasons. One is to make the test item potent. So you can run them a thousand times in a row and get the same results each and every time. And the second reason is it

[07:45] means that every test is isolated from every other test which eliminates the risk of race conditions and allows you to paralyze the test horizontally and get get the results in it in a few minutes. The second key technology is that you get radically less or orders of magnitude less flakes with meticulous than any other tool including cypus or playright. And the reason why is we augment the browser from the scheduling engine layer up to be fully deterministic. So when browsers were first designed determinism was not a

[08:17] design goal. And so there’s many different sources of randomness. For instance, an animation spinner depends upon the clock speed of the CPU of the machine rendering the browser or the interle between set timeout and set interval. And so we handle all of that randomness and uh make the browser deterministic or near deterministic so that you have radically radically less flakes. And then the third technology which is the most um important one for grocking like why this works is if you want this

[08:48] to be exhaustive it has to cover every feature plan combination every permission every role every config every possible branching through the application. So how do you how do you do that? So one technique that we use is that for every session or flow that we record, we replay it once against main branch or master branch and we monitor what lines of code get executed and then we build a map or an index that maps each individual workflow to lines lines of code executed and choose a subset of

[09:19] workflows that maximizes code coverage across your application. And typically uh give me one second. Typically I would say that code coverage in our opinionated view is a terrible metric for every tool in the world apart from meticulous and the reason why is you could write a cypress test or playright test that covers 100% of your codebase but only makes a single assertion and so code covered is not the same as code tested but with meticulous it actually

[09:50] is approximately the same because we do this really unusual and radical thing which is we’re taking a screenshot at every possible moment throughout a flow. So if there’s a 412 set flow and there’s a single pixel diff, meticulous meticulous will will will flag it. And so you can start to see how all these technologies layer together. Um you only get exhausted verification because of this code coverage algorithm. That algorithm only really works because you take a screenshot at every possible

[10:20] moment. If you take a screenshot every possible moment, you’re taking on the order of tens, hundreds of millions of screenshots. And so, traditionally, you would just drown in noise or drown in flakiness. And so, you have to solve flakiness at the root level. Um, which is which is what we what we what we do by by augmenting augmenting the browser. Um, these are some nice things that our customers customers have said about us. Um, and that concludes today’s talk. If you’re interested in finding out more

[10:51] then come to booth LG6 and thank you so much for listening. [applause] >> [music]