Ensine seu agent a provar que terminou — Nick Nisi e Zack Proser, WorkOS

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: Teach Your Agent to Prove It’s Done — Nick Nisi & Zack Proser, WorkOS · Canal: AI Engineer · 1:00:54 · Assistir no YouTube

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

Resumo

Nick Nisi e Zack Proser mostram como dar aos agents meios confiáveis de verificar o próprio trabalho, em vez de depender apenas de relatos ou revisão manual de código. Usando uma aplicação de demonstração, apresentam ferramentas e verificações determinísticas que identificam problemas como dados que aparecem na interface, mas não são persistidos. Também discutem evals, receipts e modelos system one como formas de fechar o ciclo de feedback, permitir correções autônomas e acumular evidências do comportamento da aplicação. A recomendação central é criar verificadores específicos para cada aplicação e integrá-los ao trabalho local e, quando adequado, ao CI.

Pontos-chave

• Um agent só pode confirmar que terminou quando consegue verificar resultados observáveis, não apenas afirmar que o código está pronto.
• Testar a interface sem verificar persistência pode deixar passar falhas: um dado pode aparecer na página e desaparecer após recarregá-la.
• Verificadores determinísticos, como scripts e CLI específicos da aplicação, tornam as checagens repetíveis e fornecem erros concretos para o agent corrigir.
• As verificações devem cobrir o que importa para o produto — por exemplo, interface, armazenamento, rede e erros — e ser adaptadas à aplicação e à equipe.
• Dê ao agent um resultado desejado e meios para saber se o alcançou, sem prescrever necessariamente cada passo da solução.
• Screenshots e outras evidências ajudam, mas não são prova por si só: é preciso confirmar que o fluxo foi executado corretamente e chegou ao estado esperado.
• Receipts de execuções anteriores podem embasar evals, identificar falhas recorrentes e ajudar a melhorar sistemas ao longo do tempo.
• Erros claros e detalhados facilitam que agents entendam falhas e tentem se recuperar sem intervenção humana.
• Verificações podem ser executadas localmente, em hooks ou no CI; a escolha depende do fluxo da equipe e da necessidade de feedback rápido.
• Evidências acumuladas ajudam a evitar regressões e podem dar mais confiança para paralelizar o trabalho em vários agents.

Capítulos

Início	Capítulo	Resumo
00:01	O problema de confiar em agents sem verificação	Os apresentadores introduzem o risco de erros graves e a necessidade de construir confiança nos agents por meio de verificações.
04:10	Demonstração: interface não garante persistência	A aplicação de exemplo mostra que uma ação pode parecer bem-sucedida na interface, mas não salvar os dados.
07:16	Verificação como fundamento para escalar	Os apresentadores defendem evals e critérios claros para que agents reconheçam falhas e avancem com mais segurança.
11:27	Verificadores centralizados e ferramentas de acompanhamento	São apresentados experimentos com CTX e Ryker para delegar trabalho, verificar resultados e guardar evidências.
16:36	Como um desenvolvedor verifica uma aplicação	O público e os apresentadores enumeram checagens humanas que podem ser transformadas em ferramentas para agents.
20:12	A CLI snack e as verificações da aplicação	A ferramenta snack oferece comandos para controlar a aplicação, inspecionar seu estado e executar verificações.
25:20	Fechar o ciclo de feedback com provas reproduzíveis	Os exemplos mostram como detectar dados não persistidos e transformar falhas em informação útil para o agent.
30:00	Testes de ponta a ponta, screenshots e autocorreção	Uma verificação com Playwright ilustra como testar o fluxo completo, com o alerta de que uma screenshot isolada não prova sucesso.
33:09	Restrições, criatividade e resultados esperados	Os apresentadores recomendam definir claramente o destino e a forma de comprová-lo, sem limitar desnecessariamente o caminho do agent.
37:52	Receipts e modelos system one	A conversa aborda registros de execução e o uso de um modelo system one para avaliar resultados que não correspondem literalmente a um texto esperado.
42:00	Jogo de detetive e avaliação de bugs	Os participantes experimentam encontrar um bug oculto e discutem critérios para julgar se o agent identificou o problema com evidências.
47:18	Verificadores próprios e evidências de execução	Os apresentadores recomendam CLIs de verificação específicas, acesso a sinais da aplicação e armazenamento de receipts para melhorar evals.
53:31	Executar verificações no fluxo da equipe	A conversa compara CI, hooks e instruções no repositório, destacando a rapidez do feedback local e o trabalho paralelo.
59:53	Monitoramento após o deploy e encerramento	Os apresentadores mencionam verificações em ambientes de preview e monitoramento de produção antes de encerrar o workshop.

Citações

O status vem dos registros, não das promessas do modelo. — 11:27

Seu agent não consegue fazer tudo isso apenas no terminal; ele precisa de ferramentas. — 18:08

Uma screenshot bem-sucedida não é prova. — 31:03

Dê a ele o mapa e diga: você precisa chegar aqui. — 33:39

Conceitos e entidades

• Nick Nisi (pessoa): Engineering manager na WorkOS e um dos apresentadores do workshop.
• Zack Proser (pessoa): Engenheiro da equipe Applied AI da WorkOS e um dos apresentadores do workshop.
• WorkOS (empresa): Empresa onde os apresentadores desenvolvem e experimentam práticas de trabalho com agents.
• Beyond Done (conceito): Workshop sobre como verificar o trabalho de agents e construir confiança em seus resultados.
• snack (ferramenta): Ferramenta demonstrativa do workshop que controla a aplicação de exemplo e oferece comandos de verificação.
• Playwright (ferramenta): Ferramenta usada como exemplo para automatizar verificações de ponta a ponta em uma aplicação web.
• CTX (ferramenta): Aplicação web experimental de Zack Proser para centralizar memória, credenciais e verificadores acessíveis por MCP.
• Ryker (ferramenta): Ferramenta de engenharia criada por Nick Nisi para acompanhar tarefas e verificar o trabalho entregue por agents.
• MCP (conceito): Protocolo usado no exemplo do CTX para que agents enviem trabalho a verificadores centralizados.
• evals (conceito): Avaliações que estabelecem critérios de qualidade e ajudam a medir se uma aplicação ou mudança atende ao esperado.
• Receipts (conceito): Registros e evidências das execuções, como resultados de testes, screenshots e gravações, que permitem auditar o trabalho.
• System 1 (conceito): Abordagem de avaliação rápida usada no exemplo para julgar se um resultado está na direção certa sem exigir correspondência textual exata.
• CI (conceito): Integração contínua, apresentada como um dos lugares possíveis para executar verificações automaticamente.
• Cloudflare (empresa): Plataforma em que, segundo Zack Proser, roda a aplicação web experimental CTX.
• Lauren Tan (pessoa): Pessoa citada pelos apresentadores em uma frase sobre a importância de agents verificarem o próprio trabalho.

Tradução completa (pt-BR)

00:01 [música] >> Olá, sejam bem-vindos. Bem-vindos ao Beyond Done. Vamos começar este workshop. Temos muita coisa para abordar e queremos garantir que haja tempo para perguntas e para deixar todo mundo à vontade. Então, vamos começar. >> [limpa a garganta e tosse] >> Para explicar o que queremos dizer com Beyond Done, só para ir direto ao ponto,

00:32 talvez vocês tenham visto um tuíte sobre um incidente que aconteceu há algum tempo, em que um agent começou a apagar bancos de dados de produção. E, em 9 segundos, tudo tinha desaparecido. É isso que queremos ajudar vocês a evitar hoje, sem deixar de confiar nos seus agents e sem precisar olhar cada linha, nem mesmo cada PR. É para esse cenário que achamos que estamos caminhando. Como chegamos lá? Como tornamos isso realidade, para que, em vez de termos aquela peça quebrada,

01:02 possamos ficar tranquilos, fazer tudo funcionar e, até certo ponto, confiar nos nossos agents, mas construir essa confiança com o tempo. >> Eu diria também que não se trata apenas de evitar erros, certo? Isso também é algo que vamos analisar hoje e que é fundamental para alcançar uma verdadeira escala com agents. >> Sou Nick Nisi. Sou gerente de engenharia na WorkOS. Moro em Omaha, Nebraska, e estou lá há cerca de 2 anos. Trabalho bastante com agents. Não escrevo código desde 30 de julho de 2025. Eu

01:33 sei porque esse foi o dia em que voltei da Laracon, vi PHP e pensei: “Nunca mais.” E aqui estou. E comigo está meu melhor amigo, Zach. >> Oi, sou Zach Prosser. Sou engenheiro na equipe de Applied AI da WorkOS. Estou muito animado por estar aqui com todos vocês hoje, em Nova York. >> [limpa a garganta] >> Agora, já mostramos isto antes. Este repo é a sua bancada de trabalho. Todos os slides estão neste repo. Vocês podem acessá-lo aqui. Também podem vê-los em talks.workos.cloud/beyond-done.

02:06 Sei que o endereço é complicado, mas o próximo PR ou o próximo QR code, acredito, vai levar vocês até lá. Desculpem, é talks.workos.cloud/beyond-done. Só queria mencionar isso porque, nessa página — vou mudar para ela rapidinho —, estão todos os slides. Também há uma página para os workshops, com os exercícios que vamos fazer. Assim, vocês podem percorrer cada parte. Podem fazer isso no seu próprio ritmo. Podem fazer isso mais tarde. É um guia passo a passo para acompanhar tudo. Também há um glossário

02:36 que cobre todos os termos, grandes e pequenos, alguns que vocês já conhecem. Espero que conheçam a maioria, mas, se houver algum que não conheçam, podem conversar aqui — quer dizer, podem consultar o glossário desses termos. Também há um botão “Pergunte qualquer coisa”, e vocês podem conversar com um reg treinado com base neste conjunto de slides e, com sorte, conseguir respostas por lá. Mas também podem simplesmente falar com pessoas de verdade: nós. >> É isso mesmo. Sim, vamos deixar esta página aberta também. Percebemos que muita gente quer fazer perguntas e, por algum motivo, não consegue. Então, não deixem de conferir e usar esse recurso.

03:08 >> Legal. Vamos esperar mais um segundo. Estou vendo algumas câmeras apontadas para os QR codes. O pessoal da segurança ficaria muito bravo com a gente. Certo. Quando pensamos em terminar um trabalho, em agents terminando o trabalho, há muitas coisas envolvidas para confiarmos nisso. E, sem dúvida, a primeira é: o código está certo? O código é o que eu teria escrito? Ele gerou um bom PR? Aí eu analiso como um

03:38 revisor de código faria normalmente. Mas isso leva muito tempo. E esses agents escrevem código muito mais rápido do que nós, então não queremos depender demais disso, porque começa a surgir uma relação sinal-ruído e simplesmente temos código demais para revisar. Não estamos mais escrevendo código. E estamos menos familiarizados com esse código, então ficamos ainda mais distantes dele. Precisamos encontrar outras maneiras de fazer isso. E há várias maneiras de fazer isso. Por exemplo, usando ferramentas de navegador, como o Playwright,

04:10 para dizer: “Olha, tenho este site e enviei um formulário. O envio funcionou. Verifiquei e apareceu uma mensagem de sucesso.” Esse é um ótimo teste para escrever. Não tem nada particularmente agentic nisso, mas é algo que os agents podem usar para verificar o próprio trabalho. E eles podem relatar isso por conta própria. Muitas vezes dá para confiar nesses relatos, mas nem sempre. Então, o que queremos mesmo promover é: como fazemos para confiar de fato nesses relatos? >> Com certeza. Então, tudo o que trouxemos para vocês neste workshop hoje, como o Nick mencionou, está respaldado por um repo e é interativo. Sintam-se à vontade para aproveitar a oportunidade de executá-lo, experimentar e levar algo de volta que talvez possam usar no trabalho ou, pelo menos, vivenciar de outra maneira. >> Isso mesmo. Então, se vocês entrarem no repo, como estou fazendo, e executarem PNPM snack — se eu conseguir digitar —, snack up… É por isso que tenho atalhos para tudo. P é o meu PNPM.

04:41 chegou aqui para vocês hoje neste workshop, como o Nick mencionou, é respaldado por um repo e é interativo, então fiquem à vontade para aproveitar a oportunidade de realmente executar isso, experimentar e levar algo que talvez possam usar no trabalho ou, pelo menos, vivenciar de uma forma diferente. >> Isso mesmo. Então, se vocês entrarem no repo, como estou fazendo, e executarem PNPM snack — se eu conseguir digitar snack up… É por isso que tenho atalhos para tudo. P é meu PNPM. Hum…

05:12 Ele vai abrir o navegador e podemos dar uma olhada no app Midnight Snack Club que criamos. Vocês podem brincar com ele agora, e eu mesmo posso testá-lo. Deixa eu inserir meu endereço de e-mail. Vou colocar zach@spamhim.com. >> Valeu, amigo. >> Pois é. Olhem só: sucesso. O e-mail foi salvo. O e-mail está aqui. Consigo vê-lo. Se eu tivesse um teste para confirmar que o e-mail apareceu na página, teria funcionado muito bem. É esse o aspecto desses

05:44 exemplos. Dá para acompanhar enquanto vocês avançam. Mas, se recarregarem a página, assim, não há nada lá. Então, embora… opa, o que eu fiz? Ah, voltar. Se recarregarem, aparece que não tem ninguém aqui. Pelo visto, não sei controlar o Chrome. E isso acontece porque a página foi atualizada, mas essa informação não foi salva em lugar nenhum. Então, não tivemos nenhum tipo de verificação. Estamos

06:15 apenas verificando a interface e vendo: “Ah, isso fez alguma coisa mesmo?” E sim, fez alguma coisa na interface, mas não verificamos a outra metade. Então, nunca foi salvo de forma persistente e perdemos aquele e-mail. Desculpa, Zach, você não está inscrito. >> Tudo bem para mim. Acho que este é um ponto muito importante. Então, só para levantar as mãos: quem nesta sala está desenvolvendo bastante com agents? Essa é a primeira pergunta. Certo, ótimo, mais da metade da sala. Quantas pessoas estão usando várias abas de terminal, várias sessões de chat ou vários agents? Todo mundo que levantou a mão na

06:45 primeira vez, certo? E é isso que todos estamos vivenciando, pelo menos eu e o Nick. Se este é o 18º fluxo de trabalho que você está conduzindo hoje e você só consegue dedicar uma atenção fragmentada a ele, esses são os bugs sutis que vão aparecer, porque o agent diz: “Sim, fiz o que você pediu. O código parece bom, compila, roda, os testes passam”, mas ainda está errado. E então, o que vamos perguntar e explorar juntos neste workshop é: como resolvemos de fato esse problema, para que os agents que agora todos gerenciamos como rebanhos de

07:16 máquinas insanas de tokens conseguem descobrir sozinhas o que precisam fazer e quando cometeram um erro. >> Isso. >> E vocês vão notar que não estamos realmente olhando para o código aqui. Não vamos olhar muito para o código, porque, como eu disse, vi PHP e fiquei com medo, então não olhamos mais para código. >> [limpa a garganta] >> Mas tudo isso leva a esta ótima citação de uma famosa batata no X, chamada Lauren 10. Ela tem esta frase: “Se um agent não consegue verificar o próprio trabalho, nada mais importa.”

07:47 >> Sim, outra forma de dizer isso é que, pela minha experiência — e acho que isso também é verdade para outras pessoas —, estamos convergindo para a ideia de que a verificação, especialmente à medida que as capacidades dos modelos avançam rapidamente, é um dos principais fundamentos em que devemos nos concentrar, certo? É como confiabilidade, verificação e evals. Especialmente agora que estamos vendo cada vez mais harnesses surgirem com o conceito de RSI, ou seja, autoaperfeiçoamento recursivo, incorporado. Parece que estamos caminhando para um mundo em que talvez todos acabemos mantendo várias bases de código que evoluem sozinhas,

08:18 certo? E, nesse mundo, como estabelecemos a base de evals para que o agent realmente saiba como é um bom resultado e consiga fazer esses avanços por conta própria? E como vamos dar ao agent o feedback de que ele precisa para entender que falhou em alguma coisa? >> Sim, até conseguirmos resolver isso, não vamos confiar que esses agents acelerem nosso trabalho ao máximo. Então, precisamos resolver isso em diferentes níveis. Não é só ir de zero a um; é um gradiente. O objetivo é nos aproximarmos de um, para podermos confiar plenamente nesses agents.

08:49 >> Também quero compartilhar que, novamente, isso é algo que todos estamos vivenciando na WorkOS. Temos uma equipe de IA aplicada que está construindo um monte de coisas diferentes para outras equipes e para nós mesmos. E a experiência é completamente diferente quando você está trabalhando em uma base de código que tem uma eval fundamental implementada, uma linha de base que pode ser executada e na qual se pode confiar. Vamos falar de algumas dicas e truques, mas a capacidade de realmente ver se algo foi feito corretamente ou não, da mesma forma que nós, como desenvolvedores humanos, faríamos, certo? Então, nós, sabe, temos a metáfora de que todos nós estamos

09:20 nos tornando gerentes de agent harness, que já é bem conhecida. É assim que garantimos que cada um deles esteja realmente fazendo o trabalho corretamente e que não estejamos desperdiçando dinheiro e tempo, basicamente. >> Sim, isso equivale a dizer: “não cometa erros”, certo? Sim, se você quer ter alguma verificação, não pode simplesmente adivinhar o que precisa ser feito. Você precisa dar objetivos claros e definidos para alcançar e um jeito de observar e verificar esses objetivos. Caso contrário, o agent vai fazer alguma coisa, gastar alguns tokens e talvez chegar ao resultado que você espera,

09:52 mas não há garantia disso. Para cada detalhe que você não especifica sobre o resultado e o que realmente quer alcançar, ele vai inferir ou inventar algo. E essa suposição pode não ser a mesma que você faria ou esperava, porque você é uma pessoa racional e lógica, e vocês ainda não estavam alinhados. Então, você precisa ter esses sistemas implementados para que ele possa observar, entender o que você quer, observar isso, corrigir

10:25 e verificar de novo. >> Sim, e acho que, mais uma vez, pela nossa experiência, todos estamos percebendo que o jeito cansativo de fazer isso é ter um PR enorme e uma sessão de agent que fica rodando por três ou quatro dias, dizendo: “Corrija isto, corrija aquilo, corrija aquilo, melhore.” E o que está funcionando, essencialmente perfeitamente, para as pessoas é decompor as tarefas com bastante clareza, dando a cada tarefa um agent e especificando no prompt exatamente o que ele precisa fazer para saber que terminou de verdade e verificar o estado de conclusão. E eles vão disparar. Temos pessoas na equipe que fazem 900 PRs por

10:55 mês, sem incidentes e ainda melhorando os KPIs do software. Então, pela nossa experiência, é algo sobre o qual todos precisamos parar um pouco e refletir. Não estou mais abordando essa base de código da maneira tradicional. Estou praticamente cuidando de várias bases de código e deixando que evoluam sozinhas. Sim. >> E isso é algo que construímos e usamos nas nossas próprias ferramentas também. É assim que Zach e eu continuamos produtivos na WorkOS e fazemos nosso próprio trabalho. Cada um de nós construiu seus próprios exemplos disso e suas próprias maneiras de

11:27 abordar a questão. E realmente achamos que isso é bom neste momento. Ainda é cedo demais para classificar qualquer coisa, então a experimentação é fundamental: descobrir o que funciona e seguir em frente com isso. E uma coisa que nós dois estamos adotando é a parte de verificação, ou seja, conduzir tudo a partir desse ciclo de verificação. Porque, como diz esta citação aqui, no meu caso, “o status vem dos registros, não das promessas do modelo”. Então, é como dizer: mostre as provas. Mostre a evidência concreta de que realmente fez o que eu

11:58 espero. Não diga apenas: “Sim, passou, parece bom.” Porque não há nada que comprove isso. Preciso de capturas de tela, vídeos, resultados de testes, smoke tests, tudo isso, para me provar, sem que eu precise olhar o código, que ele está realmente fazendo o que quero. Porque, no fim das contas, não me importo tanto com o código. Importo-me com o resultado, com o que ele está fazendo e com o valor que está entregando. E, sinceramente, ele pode ter um código ruim e ainda assim entregar esse resultado muito bem. Ou pode ter um código muito bom que não me dá esse resultado de jeito nenhum. E preciso

12:28 encontrar o equilíbrio certo, que é obter o resultado que quero, não o código. >> Sim, de fato. Eu também tenho feito isso. Criei uma ferramenta que chamo de context, ou CTX. Começou como uma camada de memória compartilhada entre harnesses de diferentes agents, porque estou experimentando rapidamente, como todos nós, coisas como ChatGPT, Claude Code, Pi etc. E eu queria que todos pudessem gravar e ler memórias, e isso começou a funcionar. Depois, quanto mais eu executava vários agents e, em um dia normal, tinha umas 18 ou 30 abas de terminal abertas, mais percebia que talvez fosse uma experiência interessante centralizar

12:59 a autoridade para verificação em um serviço web. Então, o CTX é um aplicativo web simples que roda no Cloudflare. Inicialmente, foi feito com vibe coding. Funciona. Começou como memória. Conseguia entregar segredos aos agents sem que eles jamais os vissem ou obtivessem as credenciais. E isso também funcionou. Agora, como experimento adicional, estou criando verificadores. O funcionamento é o seguinte: os agents recebem tarefas, como todos fazemos com prompts. Eles vão e executam o trabalho. Depois, voltam pelo MCP para o CTX e dizem: “Isto é o que concluí. Já terminei? Por favor, verifique.” Então, digamos que, no exemplo, um dos workflows precisa verificar se um PR foi criado corretamente.

13:32 Então, isso vai executar um avaliador em um verificador conhecido. Para começar, pode ser apenas uma CLI simples, como no meu repo, e depois se torna uma peça robusta que você pode reutilizar repetidamente. Ela consulta a API do GitHub e verifica se aquele PR realmente existe, está em boas condições e passou em todas as verificações de merge. Só então marcará aquele nó como satisfeito no workflow. Caso contrário, vai redirecionar o agent e dizer: “Estas são as coisas que ainda estão falhando.” Certo? Então, mais uma vez, um…

14:02 experimento, mas é mais ou menos assim que temos tentado brincar com isso e ver quais padrões vão se firmar, o que funciona e o que não funciona. Mas também é simplesmente uma época divertida para fazer vibe coding, porque exijo pixel art esquisita em todos os meus apps. Então, neste caso, dá para ver que havia um workflow simples. E um dos gates de verificação exige que todos os pull requests tenham sido mesclados. Esse trabalho é feito pela autoridade centralizada. Ela vai até lá e usa seu verificador, confere a API ou qualquer que seja o artefato e, por fim, exibe o status aqui na barra lateral à direita, se você descer até mesmo

14:33 mais, e faz referência ao repo verificado e ao PR, certo? Então, é um exemplo simples, mas dá para imaginar verifiers padronizados em uma biblioteca, em skills ou em ferramentas que vocês compartilham na organização. Essa pode ser uma das maneiras de começar a acelerar os PRs e reduzir cada vez mais a supervisão humana. >> Uhum. >> E uma ferramenta parecida que criei se chama Ryker. Ela é mais como um Grokbot ou Muse voltado à engenharia, que tenta ser extremamente flexível na forma como você lhe atribui trabalho, mas aí

15:03 depois que você lhe atribui o trabalho, a função dela é ficar de olho nele. Não quero ter que ficar de olho em todos os PRs que estou levando até a conclusão. Em algum momento, há um nível de retorno decrescente para mim e para o foco no trabalho que estou fazendo, porque acabo só ficando de olho no PR, sabe, corrigindo os testes, resolvendo as revisões que chegam, os comentários de revisão e coisas assim. Então, quero conseguir registrar a ideia do que deveríamos fazer e como podemos verificar se o trabalho está concluído, e

15:33 aí posso repassar isso para o Riker. Ele pode fazer o trabalho de garantir que as revisões sejam concluídas e que, ao corrigir o código com base nas revisões do PR, continue alinhado ao nosso objetivo geral de ter software funcional, de alguma forma. Depois, pode verificar tudo isso e me avisar quando precisar de mim, em vez de eu ter que ficar de olho nele. Então, ele cria uma verificação, determina quais ferramentas precisa executar, executa essas ferramentas, verifica se todas passaram e mantém

16:06 essas evidências, mostrando-as para mim de diferentes maneiras, e então decide quando parar. Se puder verificar que sim, estava funcionando, corrigimos esse bug, por exemplo, juntamos as partes e funciona. Assim, evita que eu precise me envolver nos detalhes dos 10% finais do processo de entrega, e posso me concentrar naquilo em que sou valioso como ser humano: por que estamos fazendo o trabalho e, até certo ponto, como estamos fazendo isso.

16:36 >> Certo, então talvez como um experimento mental, se quiserem, vamos fazer uma votação rápida, ou podem falar em voz alta: como nós, desenvolvedores humanos, começaríamos a pensar em verificar um app web, talvez nos tempos de antes de um LLM? >> Sim, o que vocês fariam para verificar? >> Vamos apresentar alguns exemplos fáceis para começar. Por exemplo, atualizar a página: o aplicativo ainda está visível, certo? O que foi? Com certeza, sim. Abrir uma nova aba e ver se está funcionando, certo? Quais códigos de resposta estou recebendo da

17:06 API? Eles são os esperados com base no que enviei? Com certeza. >> Localhost ou armazenamento local, verificar a persistência de alguma forma, logs do console, coisas assim. A rede, como você disse. E ler o que está realmente na página. O conteúdo da página realmente… >> Interagir com ela, certo? E estamos dizendo isso para preparar a transição entre a época em que nós, desenvolvedores humanos, fazíamos isso o tempo todo — isso fazia parte das nossas responsabilidades centrais quando esculpíamos código à mão, por assim dizer — e o que mudou quando, nos primeiros tempos dos LLMs, dizíamos: “Aqui estão três parágrafos de texto. Execute estas instruções.” A diferença entre essas duas coisas é a capacidade do agent de verificar se realmente fez o que você pediu em um aplicativo real e se as mudanças não quebraram nada. Certo? Caso contrário, você só recebe as confabulações que os LLMs foram projetados para gerar, porque estão tentando processar o texto. Estão tentando agradar você.

17:37 fazendo isso e, depois, nos primeiros tempos dos LLMs, dizendo: “Aqui estão três parágrafos de texto. Execute estas instruções.” A diferença entre essas duas coisas é a capacidade do agent de verificar se realmente fez o que você pediu em uma aplicação real e se as alterações não quebraram nada. Certo? Caso contrário, você só recebe as confabulações que os LLMs foram projetados para fornecer, porque estão tentando processar o texto. Estão tentando deixar você satisfeito.

18:08 >> Seu agent não consegue fazer nada disso usando só um terminal. Ele precisa de ferramentas para isso. Felizmente, agora é muito fácil adicionar ferramentas aos >> agents. >> E só precisamos dizer a eles como usá-las. Vamos dizer especificamente o que estamos tentando comprovar. Quando fizer isso, não basta colocar um parágrafo como: “Ei, faça isso, sempre verifique a mudança em um navegador.” Seja lá o que isso signifique, é bem vago. “Lembre-se de recarregar e conferir.” Isso é um pouco mais específico. “Confira se os dados persistem.” Veja se há erros no console. Está ficando um pouco mais

18:39 específico, mas isso é muita coisa para colocar ali, e você certamente pode fazer isso. É o que muitas skills fazem. É o que muitos prompts salvos fazem. Mas, se você esquecer algo ou as coisas mudarem, isso pode deixar muita coisa sujeita a interpretação. Uma opção talvez melhor seja ter um script que comprove isso de maneiras diferentes, para que você possa executá-lo várias vezes. Assim, ele faz uma verificação mais determinística de vários aspectos e pode devolver esse resultado ao agent, que sabe exatamente o que deu errado

19:10 e como corrigir isso rapidamente. Isso fecha o ciclo, tornando o processo muito mais rápido. O agent pode simplesmente executar o script, rodá-lo de novo, conferir, verificar, executar novamente e repetir isso até que não haja mais erros. >> Isso também é uniforme, se pensarmos bem, certo? Sabemos que os LLMs são não determinísticos. Então, mesmo dando o mesmo prompt a 30 agents, há possibilidade de variação nos resultados. E restringir isso a um único comando baseado em comandos e chamadas reais do bash é significativamente mais determinístico. E, segundo relatos, pessoas como Lauren Tan e outras que

19:41 estão alcançando, aparentemente, milhares de PRs por mês e criando produtos ambiciosos que antes não era possível construir nesse prazo mencionaram que essa foi a primeira coisa em que se concentraram e que realmente liberou essa velocidade, certo? Portanto, se o seu app web específico ainda não tiver uma CLI própria que permita a qualquer agent usar plenamente os recursos cuja verificação é importante para você, será muito mais difícil, e o caminho será menos pavimentado, se você usar apenas prompts, em comparação com dar a cada

20:12 agent a capacidade de dizer: “Sim, eu realmente criei esse recurso. Ele realmente tem bom desempenho. Não causou erros, e o aplicativo está com a aparência correta.” >> Para este workshop, criamos uma pequena ferramenta. Já a executamos algumas vezes, mas ela se chama snack. Você pode executá-la com PNPM snack nesse repo. Ela não foi feita para ser uma ferramenta reutilizável, mas sim um modelo de como você poderia configurar algo específico para os aplicativos em que está trabalhando e usar isso para se conectar aos LLMs que estão trabalhando com você nesse aplicativo. E o snack consegue fazer algumas coisas

20:43 de coisas. Ele pode, ah, gerenciar a saúde do aplicativo. Pode iniciá-lo, pode encerrá-lo. Pode executar um comando de diagnóstico para ver se está mesmo, sabe, se o banco de dados está funcionando. Se tem conexão de rede. E assim por diante. Essa verificação rápida que ele pode fazer. Depois, ele tem o comando drive, então você pode mandar que ele entre. Lembre-se, esta é a nossa lista de espera do lanche da meia-noite. Então, ele pode entrar na lista de espera. Pode recarregar a página, pode apagar todos os dados para que ele não consiga encontrá-los. Você pode pedir que ele procure coisas, tire uma captura, examine o armazenamento de rede, veja o console

21:15 e os logs, veja o armazenamento local, tire uma captura de tela, execute evals, tudo isso. E, por fim, ele pode comprovar de duas maneiras. Pode executar um comando prove, que verifica se a saída é determinística. E também pode usar um juiz, que recorre a um modelo system um para ter uma ideia de se estamos indo na direção certa, sem necessariamente exigir uma correspondência exata. >> Só para desenvolver bem essa ideia: quando você faz algo assim em um repo que ainda não tinha nada parecido,

21:45 os ganhos de velocidade que você desbloqueia não são só para você, certo? São para todo mundo da sua equipe que vier depois e também puder abrir muito mais PRs, muito mais rápido e com muito mais segurança, certo? De forma mais segura, para que, sabe, todo mundo da equipe realmente se beneficie. E, de novo, é por isso que insistimos tanto que isso agora é um conceito fundamental. >> Sim. E, pensando bem, essa é uma parte muito importante. Pode até ser mais importante do que o software, do que o próprio aplicativo: a maneira como você verifica

22:15 se ele funciona, como testa, como comprova que está funcionando, porque isso é algo que você poderia usar, potencialmente. Muita gente está fazendo isso e migrando para Rust. Você poderia pegar seu aplicativo, como a equipe do Bun fez, e convertê-lo para Rust; ou para Go; converter TypeScript para Go. Não necessariamente com o mesmo nível de ajuda de LLM, mas eles usaram LLMs para ajudar nisso. E acho que o Theo acabou de convertê-lo para Rust de novo, na semana passada. >> Isso mesmo. >> Quando você quiser fazer isso, se tiver todos esses verificadores em funcionamento, então seu

22:46 código-fonte não importa tanto. Você pode reescrevê-lo e comprovar que funciona. Pode continuar. >> Com certeza. >> Então, essas ferramentas dão olhos aos seus agents. Ou, pensando bem, as ferramentas que seu agent usa dão um corpo a ele. O LLM é o cérebro, e a forma como ele se estende e interage fisicamente — ou virtualmente, no seu computador — é por meio dessas ferramentas. Então, coisas como o comando join fazem com que ele realmente execute e faça coisas, e depois possa verificar,

23:17 sabe, se aquilo deu certo de alguma forma. Verificar o armazenamento, recarregar, tirar uma captura e assim por diante. Vamos executar algumas dessas coisas e ver. P snack up. Isso abriu nosso navegador. Agora vou abrir outro navegador, ou outro terminal. Tenho terminais demais. E executar P snack snapshot.

23:47 E isso nos dá uma captura da página em JSON, que podemos ver. Se eu colocar Zack em zack.zack e adicionar isso à página, espero que apareçam alguns Zacks. Aí está. Então, essa é uma forma de verificar. Também podemos tirar uma captura de tela para facilitar. Isso deve abrir uma captura de tela. E sim.

24:18 Isso nos deu a possibilidade, por exemplo, não só de passar isso ao LLM e deixar que ele interprete, mas de ele nos apresentar uma comprovação. Esse é o objetivo final, certo? Apresentar a comprovação à pessoa. Poder tirar capturas de tela, gravar vídeos e colocá-los no pull request. Agora dá para fazer isso com a CLI do GH. >> As ferramentas de depuração do Chrome. >> Ferramentas de depuração do Chrome, sim. >> Onde está o verdadeiro gargalo? Não fique chutando e, sabe, perdendo três horas. Descubra de fato qual parte estava causando a lentidão na renderização. >> Sim. Então, o ponto principal é que não há

24:48 ah, não é só olhando o código que você consegue determinar se o aplicativo está funcionando corretamente. Você pode criar ferramentas que ajudam a comprovar que ele está funcionando direito sem precisar ler o código. Porque é só isso que importa para nós: é isso que o usuário vê? Está sendo renderizado corretamente neste navegador, nesta largura, com o modo escuro, com o modo claro e assim por diante? E você pode executar testes infinitos nisso, repetidamente, em um loop, o que, como o Zach disse, permite que toda a equipe avance mais rápido, porque você deu ao agent a capacidade de

25:20 executar essas verificações sozinho também. Então, [limpa a garganta], se executarmos isso — se executássemos assim, rodando o diagnóstico e depois adicionando ada@example.test e verificando o armazenamento —, o dado estaria lá. Se verificarmos o armazenamento, ele não está lá. Veríamos que o armazenamento local está vazio. E, se executássemos de novo o comando reload e depois snapshot, confirmaríamos que, de fato, está vazio. Assim, a própria ferramenta poderia executar tudo isso em um loop, poderia

25:51 verificar todas essas coisas e confirmar antes mesmo de voltar para nós: “Ah, estou vendo que não estamos persistindo esses dados. Esqueci de fazer essa parte.” E o agent pode simplesmente continuar a partir daí. Só um instante: queríamos parar e responder a algumas perguntas, se houver. >> Sim, senhor. >> A pergunta é: estamos usando modelos para gerar JSON e, assim, ajudar a tornar nosso código determinístico e trazer isso de volta? Para mim, a resposta é sim.

26:23 Estou usando isso e executando o código; depois, uso testes unitários para verificar de diferentes formas, detectar casos extremos e confirmar que o código é uma interpretação ou representação real do que espero receber de um modelo system um, e uso isso para comprovar que estou no caminho certo. Mas também guardo esses testes para ter outra verificação e garantir que isso não se desvie com o tempo nem mude.

26:54 >> O processo geral de que estamos falando? Sim. O que quero dizer é que, pelo menos na nossa equipe, criamos muitos aplicativos para ferramentas internas. Também temos alguns aplicativos voltados para clientes. Eles costumam usar TypeScript e ser implantados na Cloudflare. Então, são aplicativos full-stack. Funciona perfeitamente. Você pode até ter evals focados no backend ou nas operações do banco de dados. Certo, dá para ser tão granular quanto quiser. Mas, sim, funciona no full-stack, e espero que a forma como todos continuaremos interagindo com o software no futuro seja mais ou menos como jardineiros, garantindo que

27:25 eles evoluam corretamente por conta própria. Sim. >> É por isso que não estamos distribuindo uma ferramenta: neste momento, não poderíamos oferecer uma ferramenta que funcionasse genericamente para cada aplicativo em que todas as pessoas nesta sala estão trabalhando. Você precisa criar as ferramentas que se encaixam no aplicativo em que está trabalhando e depois fornecê-las aos modelos, garantindo que eles saibam usá-las bem. Bem, como… >> Eu ia dizer também que seus evals, aquilo de que vocês realmente precisam ou com que se importam como equipe, empresa ou negócio, vão ser muito diferentes, sabe, dependendo de vocês estarem no ramo de design de interiores ou em outra área.

27:56 em que, tipo, a velocidade é a única coisa que importa. Acho que vocês vão ter evals muito diferentes, e há valor em desenvolvê-las com a sua equipe. >> Sim. E há muitas maneiras diferentes de levar os dados ao modelo, de formas diferentes, para que ele possa interpretá-los e acompanhar o que está acontecendo. E isso é uma parte enorme de manter o modelo informado sobre o que está acontecendo. A equipe do AMP tem uma publicação muito boa sobre isso. Acho que se chama… não consigo lembrar o nome da publicação, mas vou procurar. Acho que se chama desenvolvimento orientado por ciclos, não sei. Eu…

28:27 não consigo lembrar. Mas, no exemplo, eles mostram um canvas com um círculo e uma bola quicando dentro dele, e há uma pequena abertura por onde a bola pode sair do círculo se acertar o ponto certo. Aí o jogo acaba. E a ideia toda é criar coisas que permitam ciclos de feedback. É isso. O modelo não consegue ver o canvas em execução nem o que está acontecendo, mas, num exemplo bem artificial, se você simplesmente imprimir as coordenadas da bola em cada instante e encontrar um bug em que, ao chegar a um ponto específico…

28:58 …ela pula para o outro lado da tela. Bem, se ela estiver se movendo mais de um pixel por vez, a cada ciclo, é possível que haja algo errado. Então, há um bug aí. Se você conseguir mostrar isso ao modelo, ele poderá ajudar a depurar, mesmo sem ter olhos para ver o canvas e perceber que a bola não está se comportando como deveria segundo a física. >> E, além disso, depois que você fizer isso, também fica livre para criar 30 variantes diferentes do software que atendam a essa eval e, então, escolher a que quiser. >> Sim. >> Isso também permite fazer…

29:28 …certo? É realmente fundamental para avançar, especialmente se esperamos que os modelos usados por agents melhorem e que os tokens fiquem mais baratos. Então, dá para imaginar que vamos todos chegar na segunda-feira e dizer: “Quero ver 35 versões desse novo recurso ou aplicativo.” >> Isso mesmo. >> E escolher uma. >> Então, como fazemos isso na prática? Como criamos isso? Bem, neste caso, como dissemos, não dá para provar tudo de forma universal. Tem que ser algo específico do seu aplicativo. Então, para a nossa página de lanches da meia-noite…

30:00 …este é um exemplo do que poderia ser o comando de prova. Basicamente, ele usa uma ferramenta como Playwright para verificar se um e-mail foi realmente salvo quando alguém entra na lista de espera. Podemos verificar se ainda não há nenhum e-mail na lista de espera; depois, inserir um e-mail na linha seguinte; então, localizar o botão e clicar nele, o botão para entrar na lista de espera; e, por fim, verificar se o elemento de status na página contém a indicação de que a pessoa entrou na lista de espera…

30:32 …e conferir o texto interno para ver se o nosso endereço de e-mail está lá. Essa é uma maneira simples de fazer isso. É muito fácil se você já escreveu um teste de ponta a ponta com ferramentas como Playwright ou React Testing Library; com certeza já usou ferramentas assim. Você pode simplesmente disponibilizá-las para o modelo, para o seu agent, e ele pode executá-las. Dê a ferramenta a ele e ele poderá comprovar por conta própria. Assim, você cria uma evidência reproduzível que poderá usar da próxima vez…

31:03 …que usar essa página. Na próxima vez que ela mudar, o agent pode executar o teste de novo e verificar se nada quebrou. Isso funciona como um teste de regressão e ajuda toda a equipe a seguir em frente. >> [limpa a garganta] >> Mas um alerta, uma palavra de cautela: uma captura de tela bem-sucedida não é uma prova. Confira se ela realmente mostra o estado esperado e se o agent executou os comandos para chegar a esse estado, porque, caso contrário, pode ser só mais uma mentira, embora você esteja vendo uma captura de tela no…

31:35 …PR e pensando: “Ah, sim, está correto.” Mas pode estar causando outros efeitos colaterais. Talvez tenha seguido um caminho diferente, que nem sequer é possível pela interface. Então, você precisa garantir que ele execute tudo do início ao fim para verificar. >> Sim. E, quando você cria esses ciclos duráveis, confiáveis, repetíveis e uniformes, o principal benefício é que uma falha começa a orientar o trabalho futuro, certo? Se o agent falha em um ciclo…

32:06 …enquanto você está ocupado conversando com alguém no trabalho ou começando mais uma tarefa, o agent pode perceber por conta própria que aquilo não está bem certo e tentar de novo. Depois, pode executar novamente o comando de verificação. “Certo, agora está tudo bem.” Se você pensar no que isso significa em escala — um único PR, ou um agent em uma única linha de trabalho, por assim dizer, que se recupera, corrige a si mesmo e resolve as coisas por conta própria —, você não vai voltar àquele PR no fim do dia e pensar: “Ah, ainda preciso levar isso até o fim.” E, se multiplicar isso, é aí que…

32:38 …voltamos a dizer que isso é fundamental para a velocidade e o ritmo de trabalho. Isso mesmo. >> Quantos de vocês escrevem boas mensagens de erro? Levantem a mão. >> Sim, ninguém sabe. Já esperávamos. >> [risos] >> Senhor, qual é a sua mensagem? >> Tenho mãos pequenas. >> Aí está. Isso mesmo. >> Muito bem. >> Bem, vocês deveriam escrever boas mensagens de erro. Acho que elas são mais importantes do que nunca porque, quando o seu aplicativo gera um erro, adivinhe quem consegue interpretá-lo e agir com base nele muito bem? Um agent. Então, se você deixar explícito por que a falha ocorreu…

33:09 …e der o máximo de detalhes possível sobre como o sistema chegou àquele estado, o seu agent poderá se recuperar sozinho. É muito fácil e vale muito a pena fazer isso. >> Sim, e esse é um conceito sobre o qual Nick e eu conversamos, certo? Pode parecer que, de certa forma, estamos tentando impor determinismo aos LLMs, mas, na verdade, não queremos fazer isso. E isso também está de acordo com o espírito do que a equipe do AMP está dizendo. Os agents…

33:39 …são inteligentes. São capazes. Na verdade, queremos que sejam criativos. Porque, muitas vezes, se tiverem as restrições certas — e, muitas vezes, as restrições podem significar liberdade, certo? —, eles vão encontrar soluções criativas e realmente resolver o que você pediu. É por isso que você dá a eles o resultado desejado. É por isso que o projeto que Nick está desenvolvendo como experimento se chama desenvolvimento orientado a resultados. Então, não se trata de ser prescritivo demais sobre como o agent deve fazer as coisas. Em alguns casos, isso pode até levar a um desempenho pior. É…

34:11 …mais uma questão de dar a ele o mapa e dizer: “Você precisa chegar aqui. Você saberá que chegou quando este comando retornar isto.” >> Sim. Você não precisa necessariamente prescrever como ele deve chegar lá. E isso é cada vez mais verdade a cada dia, com os modelos de ponta. Fable, Astra, Saul 6.1, Opus 5.5. Todos são muito bons; eu descreveria isso como a capacidade de serem criativos. Mas, se você disser: “É aqui que quero chegar”, sem necessariamente indicar o caminho que devem seguir, eles podem explorar e…

34:42 garantir que eles detectem mais casos extremos. Talvez descubram alguma coisa ou façam uma pergunta que destrave algo. Mas, se você simplesmente disser que precisam chegar aqui, depois aqui e depois aqui, talvez não se desviem desse caminho. E você quer que se desviem um pouquinho, mas que cheguem ao objetivo final certo. E, como eu disse, só começamos a valorizar isso de verdade na leva mais recente de modelos de fronteira. É quando isso está realmente se tornando possível. Então, daqui para a frente, só vai melhorar. >> Sim. >> [limpa a garganta e tosse] >> Então, quando estiver funcionando, você vai querer entrar naquele ciclo típico de TDD, de vermelho, verde e refatoração, com seu agent. E vocês já ouviram falar de ciclos em todos esses eventos AIE, e aqui não é diferente, mas dá para usar isso na própria etapa de verificação. Verifique isto, reproduza o problema, me mostre, corrija e depois me mostre a prova disso. E como você vai me mostrar a prova? Isso é tão importante quanto a correção que vai entrar, porque é isso que vai deixar você em paz e permitir que confie no modelo para realmente fazer o trabalho. E então, quando ele disser: “Ei, terminei”,

35:13 você sabe que terminou porque ele provou isso de alguma forma. >> Com certeza. >> Então, neste exemplo, você pode executar o Snack Doctor. Vamos executar isso rapidinho. P Snack Doctor. E isso foi executado e está mostrando várias verificações que fez. Está verificando se temos o Node, se o Chromium está instalado, se nossa sessão existe, se está realmente

35:43 em execução e se a compilação foi concluída com sucesso. Então, isso é o que executamos como uma verificação rápida de diagnóstico: várias coisas diferentes. Depois, executamos o próximo comando, Snack Join Ada at example.test. >> Desculpa, a gente não digita mais. >> [risos] >> Certo. Ele nos devolveu o resultado. Snack storage. O armazenamento está vazio. Na verdade, não colocou

36:15 a Ada lá. >> É nesse momento que, no mundo real, você acabou de obter valor de todo esse sistema por meio do seu agent, porque agora ele percebe que não terminou e não vai abandonar esse trabalho no meio do caminho. >> Isso. E, se você recarregar e fizer a mesma coisa mais uma vez… Pronto. Agora demos olhos ao nosso app. Ele consegue ver isso, executar essas ações, entender e mudar o mundo do aplicativo, o aplicativo Midnight Snack, e ver

36:47 os resultados disso, e então interpretar o que aconteceu a partir daí. >> [limpa a garganta] >> Então, você pode experimentar. Se aplicarmos a correção de persistência e adicionarmos um texto honesto, podemos executar a prova. Vamos executar. Isso abriu um navegador e falhou. Na verdade, não executei o teste, mas, se tivéssemos executado a correção, ela mostraria isso.

37:18 >> [limpa a garganta e tosse] >> Certo, uma das coisas em que temos pensado muito ultimamente, conversado e que estamos começando a implementar em mais aplicativos é esse conceito de recibos. Você pode pensar, por exemplo, num sistema de chamados de suporte, em que existe certo nível de qualidade na maneira como uma pessoa responderia a um chamado para que ele seja considerado bem resolvido, como uma resposta ou um atendimento excelente ao cliente. E o que significa preservar isso de alguma forma, por exemplo? Por que queremos fazer isso? Há muitos motivos, e vamos falar de alguns, mas, de novo, se você pensar

37:52 que, se todos nós — ou se parece que muita gente — está caminhando, de alguma forma, para executar harnesses de RSI e bases de código que evoluem por conta própria, tudo o que fazemos hoje, tudo o que seu agent faz hoje, cada execução durante o dia todo, é dado muito valioso. É um dado muito valioso agora, porque você pode alimentá-lo para LLMs e obter as correções necessárias. No futuro, esse dado será incrivelmente valioso à medida que as ferramentas melhorarem e ficar cada vez mais fácil configurar ciclos de RSI, porque aí você terá um conjunto de dados que mostra exatamente como seu sistema se comportou e que

38:23 poderá usar para criar evals muito abrangentes e fazer agents subirem a ladeira, isto é, repetirem o ciclo, observarem o próprio desempenho e continuarem até ficarem cada vez melhores, certo? >> Isso. E, nesse ponto, eles conseguem passar por conta própria usando as evidências das execuções anteriores. >> [limpa a garganta] >> Então, agora, se corrigirmos esse código, ele persiste, mas também pode mentir. Depois que recarregarmos a página, pode dizer que você está na lista de espera, mas a captura de tela pode, na verdade,

38:53 dizer que você conseguiu uma vaga, que seu lugar está confirmado. Isso não corresponde exatamente, então isso pode ser uma falha, porque as duas coisas não correspondem exatamente. Com isso, estamos nos afastando um pouco dos testes estáticos. Como provar que funcionou sem ficar tão fortemente acoplado ao texto exato na tela, num exemplo tão artificial? Então, se simplesmente executarmos P snack, judge,

39:24 isso deve ser executado, mas falhou porque, embora tenha funcionado e diga que conseguimos uma vaga, Jev não… o modelo não percebeu isso. É porque o texto de confirmação quebra o contrato: não é exatamente igual. Então, como corrigir isso sem criar um acoplamento forte com tudo o que estamos fazendo? A resposta são aqueles modelos de sistema um, sobre os quais vamos falar agora. >> Sim, com certeza. Só para apresentar o conceito a quem ainda não conhece: a ideia de sistema um e sistema dois vem, na verdade, da psicologia. É um modelo útil para pensar em como o cérebro humano funciona e como pensamos. O sistema um toma decisões super-rápidas. É automático. Por exemplo, alguém desvia na minha direção enquanto estou dirigindo e eu corrijo sem nem pensar, certo? Ou estou prestes a perder o equilíbrio e me corrijo. Já o sistema dois é como quando preciso decidir o que vou fazer da vida. Então vou reservar um Airbnb e pensar nisso por três dias. >> [risos] >> E, aplicado ao mundo

39:56 dos LLMs, agora temos Jev e, logo depois, temos Cleft, da Cloudflare, dois dias mais tarde. Isso é ainda mais rápido. É uma época realmente empolgante para pensar em todas as maneiras como podemos combinar essas ferramentas e criar as novas primitivas que continuaremos vendo surgir nas arquiteturas de IA em evolução. >> Sim. Para dizer de outro jeito: aquela luz ali, se eu perguntasse “De que cor é a luz que ela está projetando?”, você responderia rapidamente: amarela. Esse é o pensamento do sistema um, certo? Você simplesmente sabe a cor. Se eu perguntasse “Por que ela está projetando amarelo?”, aí pensaríamos. Poderíamos

40:27 entrar na física para entender por que a luz emite amarelo. >> Por que estamos aqui? >> [risos] >> Foi assim que chegamos ao que realmente queremos conversar com vocês hoje. >> [risos] >> Então, aqui temos outro jogo que podemos jogar dentro disso. É um jogo rápido com o Snack. Temos um sabotador e um detetive. O sabotador escolhe um lanche e insere um bug secreto, colocando um bug aleatório.

40:57 Não sabemos qual. Vai ser aleatório. Depois, você, o detetive, encontra o bug usando só o Snack. E então prova o que é. Diga o nome do bug e apresente provas de que o encontrou. É algo que você pode fazer se tiver baixado o site ou o repo: basta executar pnpm snack up –bug random, deixar rodar e ver se consegue encontrá-lo. Vamos tentar. Vamos dar um tempinho para rodar. Qual era mesmo?

41:28 –bug >> bug random >> Ah, já está rodando. Deixa eu encerrar esse processo. Encerrar o certo. Certo. Então, neste caso, ele foi executado

42:00 Não sabemos qual. Vai ser aleatório. E então você, como detetive, encontra o problema usando apenas snack. Depois, prove o que é. Dê um nome ao bug e apresente provas de que você o encontrou. Então, isso é algo que vocês podem fazer se tiverem baixado o site ou o repo: basta executar pnpm snack up –bug random e deixar rodar para ver se conseguem encontrá-lo. Então, vamos tentar. Vamos dar um tempo para ele rodar. O que era mesmo?

42:31 –bug >> bug random >> Ah, já está rodando. Deixe-me encerrar isso. Encerrar o processo certo. Certo. Então, neste… ele rodou…

43:02 tem a URL do app, está em execução, não está em modo headless, então podemos vê-lo. O bug diz “oculto até você parar de subir”. É, certo. Deixe isso em execução em outro terminal e rode pnpm snack doctor. Então, vamos rodar. Certo, isso executou tudo, e podemos ver que o Node está lá, o Chrome está lá, e há uma sessão. A prova aqui: o recibo mais recente diz “falha”, mas o código-fonte agora está

43:33 essa prova é de um código que já não existe, então não foi possível provar isso. Foi uma execução anterior. Vamos rodar de novo. A mesma coisa. Alguém consegue me dizer qual é o bug? Alguma ideia? E-mail errado? Isso, exatamente. A porta está errada.

44:06 Acho que estava rodando na porta 62174. Não, essa estava certa. Deixe-me tentar mais uma vez. Temos menos de um minuto.

44:39 Para esse, sim, você precisa. >> Mas as ferramentas tornam isso opcional, então você pode fazer todos os exercícios mesmo sem ele, e vai funcionar. Mas também é uma boa oportunidade para experimentar com um, caso você tenha. >> Sim. >> As chamadas são bem baratas. >> Eles dão US$ 5 de graça quando você se cadastra, e acho que isso vai durar uns três anos. >> Sim. >> Certo. >> Então, [limpa a garganta], pode continuar. Próximo. Sim.

45:11 >> Então, sim, rodamos algumas vezes. Acho que houve algum problema com a minha saída. Vou depurar isso. É engraçado, preciso de alguns testes de verificação para verificar meus exemplos de verificação inventados. Mas os resultados possíveis são: identificou o bug com uma saída; disse que funciona, mas não funcionava; disse que funciona e funcionava; atribuiu a culpa a um bug que não existia; e então não tinha… era o bug certo

45:42 ou não havia evidências. >> Certo. E isso só retoma aquele ponto: é claro que este é um exemplo inventado, mas sua equipe pode pontuar de outra forma ou usar critérios diferentes. Isso é muito flexível. O mais importante é começar, criar uma avaliação de referência e usá-la de forma consistente, evoluindo-a em conjunto como equipe. Depois, chegar ao ponto em que suas alterações e seus PRs executem automaticamente essa avaliação, para que você saiba se as mudanças são seguras para integrar, se estão melhorando as coisas, piorando-as ou se não estão mudando nada. >> Isso.

46:13 E, toda vez que ele roda e não detecta algo, isso é uma nova linha que pode ser adicionada ao mapa. Assim, ele pode nos dar ideias sobre as etapas para chegar lá e por que chegamos lá. E, sabe, cada vez que falha, ficamos um passo mais perto, porque podemos corrigir isso. Então, na primeira vez, só fica na memória; não é armazenado em lugar nenhum, apenas na memória. Estamos inserindo um endereço de e-mail errado. Perdemos nossa confirmação. A cada vez, podemos provar que detectamos isso e, então, não nos deparamos com o problema de novo. Mas, no caso da promessa exagerada,

46:45 a captura de tela ou o juiz em execução pode nos dizer que, na verdade, passou quando não passou. A mesma coisa com o erro no console. Talvez não haja nada no console, mas esteja no recibo; ou talvez esteja sendo detectado antes de chegar ao console. Sim, qualquer coisa assim. Ou pode simplesmente não haver nada: não há nada para encontrar. Tudo funciona. E essa também é uma resposta válida.

47:18 Se você executar o doctor, como estávamos fazendo, ele mostrava isso, os exemplos anteriores. Mostrava uma prova que já não existe. Isso acontece porque seu código pode ter mudado bastante de ontem para hoje. As circunstâncias também podem ser diferentes, como no caso de um famoso bug de data, por exemplo. Pode haver vários motivos diferentes. Então, queremos criar ferramentas flexíveis o bastante para não serem afetadas por problemas como esse.

47:48 Isso tudo retoma, de certa forma, exemplos básicos de testes unitários, mas traz esse tipo de verificação determinística para os modelos, de modo que eles possam se autocorrigir e se aprimorar a partir daí. >> Com certeza. >> [limpa a garganta e tosse] >> Certo, então, para relacionar isso ao que nós, como desenvolvedores humanos, costumávamos fazer: o que conseguíamos ver, como testaríamos a aplicação, como verificaríamos tudo. É disso que estamos falando e é isso que estamos transferindo para o código.

48:19 Ao transferir isso para o código e disponibilizá-lo em uma CLI determinística, podemos chegar ao mesmo caminho e à mesma experiência que teríamos ao testar as coisas como desenvolvedores no Chrome, tentando corrigir algo tarde da noite. É isso que libera a velocidade, a evolução e a capacidade de aumentar a quantidade de código entregue, fazendo isso de forma mais segura. De novo, a recomendação é: se você tem um app web e ainda não tem uma CLI de verificação personalizada,

48:49 essa é uma das coisas de maior impacto com que você pode começar para sua base de código: também uma avaliação de referência fundamental que mostre o que é considerado bom na sua aplicação. E também dar aos seus agents a capacidade de ver todos os aspectos de desempenho, rede, tráfego, renderização e assim por diante. Portanto, dar a eles as ferramentas de desenvolvimento do Chrome, se você trabalha com apps web. Se você estiver distribuindo clientes nativos, como apps para iOS ou macOS, há projetos alternativos — e mais surgem todos os dias — aos quais você poderá conectá-los.

49:20 Mas o fundamento comum a todos eles é que você precisa dar ao seu agent a capacidade de ver absolutamente tudo o que você normalmente veria como desenvolvedor. >> Sim, quanto mais você puder dar a ele, mais braços ou olhos puder fornecer, mais ele vai conseguir assumir no seu lugar. Aí você só precisa dar a ele a intuição de quando e como usar essas coisas. Pense em como você decide: certo, se esse bug aparecesse, como eu o reproduziria? Pense nisso e, se conseguir decompor o processo — isso depende da sua aplicação e do tipo de código que

49:51 você está escrevendo —, talvez consiga fazer isso de um jeito que permita ao agent pensar: “Ah, sabe, para nós, há muitas coisas relacionadas ao início de sessão. O cookie está sendo definido corretamente? Está sendo definida uma expiração? Tudo isso?” >> No trabalho, certo? Isso se aplica a todos os campos e setores que usam software. Mas tudo se resume a isto: “Aquele mundo em que fazia sentido todos nós talharmos código à mão o tempo todo está, no mínimo, evoluindo — ou mudando rapidamente. Quais são os fundamentos do sistema que devemos trazer para isso agora, para acelerar o desenvolvimento de software?”

50:21 >> Isso. Então, sim, fazendo pilhas de chamadas caras. Mas o importante é obter essa saída e garantir que ela forneça detalhes sobre o que aconteceu, o estado e tudo mais, para que a aplicação e o modelo possam auditá-la. Depois, você pode executar de novo; ele pode corrigir, executar novamente e verificar se as alterações realmente surtiram efeito e se o problema não existe mais.

50:53 >> E, sim, de novo, não dá para enfatizar demais o valor de guardar os comprovantes. Então, se você tiver execuções, sabe, elas podem abranger toda a jornada do usuário. Digamos que seja um app de e-commerce. Quando a pessoa faz login e acessa a página, o que aconteceu? Qual foi o fluxo? Ela chegou a ver algum erro? Teve de esperar 7 segundos até o catálogo aparecer? Conseguiu colocar algo no carrinho? Houve abandono do carrinho? Então, guarde tudo isso agora, porque cada uma dessas execuções e desses comprovantes pode ser fornecida a LLMs. Você pode até configurar um sistema que funcione a noite toda, procurando os comprovantes mais recentes

51:26 que estão sendo produzidos, agregando-os e dizendo: “Bem, hoje vimos oito falhas no módulo de cache. Então, obviamente, vou abrir um PR esta noite para corrigir isso direito.” E depois: “Ah, tenho as ferramentas de que preciso para provar neste PR que o problema que eu estava tentando resolver foi corrigido.” E também há as recomendações que estamos vendo de pessoas que estão conseguindo enviar PRs em escala altíssima, sem erros. Elas também conseguem incluir aquilo que ainda é necessário para nós, humanos, na nossa supervisão. Então,

51:56 não apenas capturas de tela do recurso, mas uma gravação mostrando: “Percorri o app desta maneira. Este foi meu fluxo. Foi isso que vivenciei. Estes foram os estados e cheguei ao objetivo.” Assim, se eu acordar e tentar revisar rapidamente 15 PRs importantes logo de manhã, posso primeiro assistir à gravação e confirmar que tudo chegou ao fim e funcionou. Depois, posso começar a olhar o código, se for algo que eu realmente vá revisar como humano. E, de novo, acho que tudo isso será imensamente valioso à medida que continuarmos vendo as ferramentas evoluírem e se autoevoluírem.

52:29 E pensem no que isso significa, porque, quando chegarmos ao ponto em que ferramentas que se autoevoluem forem o padrão e as pessoas as estiverem usando, haverá uma vantagem específica para quem tiver preservado conjuntos de dados limpos de coisas que permitam dizer: “É isso que estamos tentando alcançar neste app; queremos que você chegue até lá e o aprimore rapidamente”, certo? Se você não tiver um grande volume desses dados e seus concorrentes tiverem, e eles tiverem apps semelhantes, conseguirão acelerar bastante o ciclo de desenvolvimento. >> Isso mesmo. E isso só vai construindo essa confiança para podermos continuar aprimorando

52:59 nosso app à medida que avançamos, mas temos essas verificações para tudo o que veio antes. Então, temos testes unitários, temos evals, temos testes de fumaça, temos o que quer que nosso app precise e temos uma maneira de o modelo interpretar e executar essas verificações, além de aprimorá-las, de modo que, se adicionarmos novos recursos, possamos executar todas as verificações anteriores e garantir que não quebramos nada, que não houve regressões. E podemos simplesmente subir essa escada de evidências, reunindo evidências ao longo do caminho, e garantir que nosso app funcione exatamente como

53:31 esperado. E isso acaba se tornando a especificação que mostra o que nosso app faz. Certo, ótimo. Temos pouco mais de 5 minutos. Vou fazer uma pausa e ver se há outras perguntas. Sim, senhor. >> Então, essa escala… Pessoalmente, estou curioso para saber como você pensa a respeito. Eu, pessoalmente, tenderia a evitar skills porque, pela minha experiência, sabe, cabe ao modelo decidir se vai realmente seguir esse caminho e usar isso,

54:02 em vez de, por exemplo, fazer com que o CI realmente garanta que esses comandos sejam executados também. Sim, é isso que… >> Tipo, a resposta ou a pergunta é: como vocês executam essas verificações normalmente, certo? De forma eficaz. >> [limpa a garganta]

54:37 >> Sim, dá para executar essas verificações regularmente. Por exemplo, elas podem fazer parte do CI. Você pode ter vários hooks, como um hook do Git, embora provavelmente fosse o último recurso a que eu recorreria. Poderíamos usar um hook do Claude Code. Depende do que sua equipe está usando e de como está fazendo isso. Talvez eu criasse uma extensão completa para o Pi, para manter as coisas funcionando em segundo plano e simplesmente ir fornecendo informações conforme elas aparecem. Há várias maneiras diferentes de fazer isso, mas, de longe, a maneira mais fácil de fazer todo mundo adotar isso é

55:08 e posso dizer isso agora: basta colocar um agents.md, não um cloud.md, no seu app e pedir que ele diga algo como: “Ao fazer alterações, verifique tudo executando isto”, ou “sempre que fizer alterações significativas” ou “antes de abrir um PR, faça isto”. Use a formulação que quiser. É uma maneira fácil de fazer todo mundo adotar isso, e a pessoa teria de se esforçar para ignorar ou evitar essa instrução. >> Hooks também são relevantes se vocês estão fazendo desenvolvimento local, certo? Para a equipe toda, porque dá para compartilhar hooks com todo mundo.

55:46 Sim, com certeza. Sim. >> Bem, o CI é um recurso disso, eu acho, mas a ferramenta em si é o desenvolvimento rápido que você consegue localmente. Então, dou uma tarefa ao meu agent e posso executar algo rapidamente, deixar o agent trabalhar. Basicamente, digo onde quero chegar. Quero que a lista de espera permita adicionar um e-mail e que ele seja armazenado e salvo, e posso verificar isso. Então, é assim que você verifica: ele vai para esta tabela, blá-blá-blá. Seja lá o que for. Bem…

56:17 Sim. Não, boa pergunta. Claro. Sim. Sim, qual é a vantagem de executar isso no CI em vez de localmente? Claro. As vantagens são definitivamente…

56:47 um ciclo de feedback mais rápido, que nos permite trabalhar mais depressa e me permite trabalhar em paralelo, porque não estou mais trabalhando em uma coisa de cada vez. Neste momento, estou trabalhando com pelo menos três agents. Para mim, isso é um dia bem tranquilo, mas estou numa conferência. >> [risos] >> Normalmente, são de 10 a 15. >> Hoje ele está pegando leve mesmo. >> E a ideia toda é: vou iniciar a tarefa e não quero que ela fique esperando por mim e diga: “Pronto, fiz”, para eu ir executar e descobrir: “Não, isso não está certo”. Aí tenho que iniciar tudo de novo, me distraio com outro agent e volto a repetir esse ciclo. Estou o tempo todo alternando entre projetos. Então, quero dar a ele as ferramentas para provar para si mesmo que fez o trabalho e depois me mostrar as evidências de uma maneira em que eu possa confiar. Assim, quando eu voltar, talvez em 5 minutos, talvez em uma hora ou algumas horas, quero saber que ele fez o melhor trabalho possível para chegar a um estado de conclusão, para que eu não fique simplesmente dando outro prompt e começando todo esse ciclo de novo, porque não quero

57:18 que… essa não é a parte divertida do meu trabalho. >> Sim, eu diria que outra maneira de dizer isso é que, embora ainda não tenhamos conseguido fazer isso perfeitamente todos os dias, quero voltar no fim do dia a todas as diferentes frentes que iniciei para tarefas que considerei importantes entregar naquele dia e ver que estão basicamente concluídas corretamente. O que não quero é passar um dia inteiro, deixá-las rodando em segundo plano enquanto faço outras coisas e vou a reuniões, e depois voltar e ter que orientar cada uma delas passo a passo, porque isso atrasa muito as coisas e me impede de avançar mais rápido.

57:48 …ser, essa não é a parte divertida do meu trabalho. >> É, eu diria que outra forma de colocar isso é que, embora ainda não tenhamos conseguido fazer isso perfeitamente todos os dias, quero que todas as diferentes frentes que iniciei naquele dia para coisas que considerei importantes de entregar naquele dia estejam, no fim, basicamente concluídas corretamente. O que não quero é passar um dia inteiro com elas rodando em segundo plano, fazendo outras coisas e indo a reuniões, e depois voltar e ter que orientar cada uma delas passo a passo, porque isso causa uma lentidão significativa e me impede de avançar mais rápido.

58:19 >> E outra forma de dizer isso é que eu dependo da CI, dos testes que rodam na CI e das revisões de código. Quantas pessoas fazem revisões de código automatizadas com ferramentas como Reptile, Code Rabbit, Codo ou alguma dessas? Sim. Eu dependo delas. Nós usamos Reptile. Reptile me dá uma nota de X em cinco e, se me dá cinco de cinco e toda a minha CI está passando, fico extremamente confiante de que não vou quebrar a produção quando isso for lançado. Chegamos a esse nível de confiança com Reptile. O mais importante nisso é que eu chego a esse estado mais rápido e que

58:52 >> Com menos turnos. >> Com menos turnos, sim. E, sabe, eu posso acrescentar um monte de coisas: poderia adicionar 10 mil linhas absolutamente inúteis, que não fazem nada, e ótimo, passou. Reptile deu cinco de cinco por algum motivo terrível e, então, isso vai para produção e não faz nada, não quebra nada. Agora são só mais 10 mil linhas inúteis. E isso também serve para me ajudar a garantir que estou dizendo ao agent exatamente o que quero e que ele chega lá sem passar por um monte de código adicional ou…

59:22 código adicional, ou seja, ele se mantém no caminho certo, mas também sabe como se corrigir para continuar no caminho certo enquanto estou ocupado com outra coisa. >> Certo, talvez tenhamos tempo para mais uma pergunta rápida, mas acho que estamos… Sim, sim, senhor. >> Sim. Sim.

59:53 Sim. Você também poderia, dependendo da sua stack, usar… Há também vários provedores aos quais você poderia recorrer facilmente para primeiro fazer uma pré-visualização e, então, verificar de outra forma. Depois, iríamos para produção e monitoraríamos imediatamente. Esse é outro padrão que estamos começando a observar: quando as pessoas têm um deploy implementado em grande parte por agents, há também pelo menos um agent especificamente encarregado desse lançamento em produção, observando todas as métricas, monitorando o DataDog e os sinalizadores de funcionalidade, certo? Sendo

1:00:23 capaz de dizer: “Isso está, na verdade, dando errado, e vamos reverter.” Então, eu realmente entendo e compreendo esse desconforto que todos temos ou enfrentamos, mas vejo um caminho para isso, porque simplesmente parece inevitável. Sim. Isso mesmo. >> Nosso tempo acabou, mas, se tiverem mais perguntas, teremos prazer em conversar. Estaremos no pavilhão de exposição, no estande seis, logo à direita quando entrarem. Venham falar com a gente. Teremos prazer em conversar, mostrar no que estamos trabalhando e falar sobre o que quiserem. >> Sim. Muito obrigado por terem vindo e

1:00:54 pela atenção e por tudo. Muito obrigado. >> [aplausos]

Transcrição original

[00:01] [music] >> Hey, welcome. Welcome to Beyond Done. Uh we’re going to get started here with this workshop. We got a lot to pack in and uh we want to make sure that we have time for questions and um uh getting getting like everyone situated. So, we’re going to go ahead and get started. >> [clears throat and cough] >> So, what we mean by Beyond Done, just to

[00:32] like jump straight into it, um you probably saw a tweet about this incident that happened a while back uh where an agent just started deleting production databases. And in 9 seconds, everything was gone. Um that is what we want to help you prevent here today uh while still trusting your agents and not having to look at every line, even look at every PR. Like this is where we think things are going and how do we get there? How do we make this a reality where instead of having that broken

[01:02] piece, we can have you calm, have uh everything work, and let you to some degree trust your agents, but build that trust over time. >> I’d say also that it’s not just about preventing errors, right? But this is also what we’re going to look at today foundational to achieving true scale with it with agents as well. >> So, I’m Nick Nisi. Uh I’m an engineering manager at WorkOS. Uh I live in Omaha, Nebraska and uh I’ve been there for about 2 years. And I do a lot with agents. Uh I haven’t written code since July 30th, 2025. I

[01:33] know because that’s the day I got back from Laracon and I saw PHP and I was like, “Never again.” And uh here I am. Uh and with me is my best friend, Zach. >> Hey, I’m Zach Prosser. I’m an engineer on the Applied AI team at WorkOS. Super excited to be here with you all today in New York. >> [clears throat] >> Now, uh we had this up before. This repo is your workbench. Um all of the slides are in this repo. You can get it from here. You can also view it at um workos.cloud/umbeyond-done.

[02:06] Uh, I know that’s a mouthful, but the next PR or the next QR code, I believe, will take you there. Um, sorry, talks.workos.cloud/beyond-done. Uh, and I just wanted to call it out because on that, I’ll switch to it real quick. Um, all of the slides are out there. There’s also a page for the workshops, like the the exercises that we’re going to go through. And so, for each piece of it, you can go through it. You can go through it on your own time. You can go through it later. This is a a step-by-step guide to go through that. There’s also a glossary

[02:36] uh, covering all of the terms, big and small, uh, some that you’re familiar with. Uh, hopefully most of that you’re familiar with, but if there’s any that you’re not, uh, you can talk in here or sorry, you can look at the the glossary for those terms. There’s also an ask anything button, and you can talk to a reg that’s trained on this uh, slide deck, and uh, hopefully get your answers there. But, you can also just talk to a human, us. >> Indeed. Yeah, we’ll leave leave this up as well. We find that a lot of folks want to ask questions and for whatever reason can’t, so be sure to check that out and use that.

[03:08] >> Cool. Give it just another second. I see some cameras pointed at QR codes. Security would be so mad at us. All right. Um, so when we’re thinking about uh, being done with work, uh, agents being done, uh, there’s lots of things that go into us trusting that. And easily the first one is just is the code right? Is the code what I would have written? Did it generate a good PR? And then I go through that like a normal

[03:38] normal code reviewer. Um, but that takes a long time. And these agents can write code a lot faster than us, so we don’t want to rely on that too much because it’s uh, it just there a a signal-to-noise ratio that starts coming into play and we just have too much code to review. We’re not writing any code anymore. And we’re less familiar with that code, so we become further abstracted away from it. So, we need to find other ways to do that. And there’s plenty of ways that you can do that as well. There’s you know, using tools like browser tools like Playwright

[04:10] for example, to say like, “Hey, I have this website and I submitted a form. The submit worked. I checked that and it showed me a success message. That’s a great test to write. Not even really anything agentic about it, but it is something that agents can use to verify their work. And they can self-report that. And you can trust that often times, but not all the time. And so, that’s really what we want to drive is like, how do we make it so that we can actually trust these reports? >> Absolutely. So, everything that we’ve

[04:41] got here for you today in this workshop as Nick mentioned is backed by a repo and it is interactive, so be you know, feel free to take an opportunity to actually run this to experiment with it to take something back that you might you know, use at work or at least experience in a different way. >> Yep. In this so like if you just go into the repo like I’m doing and you do PNPM snack if I can type snack up uh This is why I have shortcuts for everything. P is my PNPM. Um

[05:12] it will pop up the browser and we can look at it and we can see this Midnight Snack Club app that we made. Um and you can play with it right now and I can test this myself. Let me just put in my email address. I’ll put in um zach@spamhim .com. >> Thanks, buddy. >> Yep. Uh and look at that, success. It saved the email. The email is here. I can see it. If I had a test that was looking to confirm that the email went on the page it worked great. So, that’s what these

[05:44] examples look like. You can kind of see it um, as you’re going. Uh, but if you reload that page, just like this, nothing’s there. So, even though, oops, what did I do? Oh. Switch back. Uh, if you reload that, uh, it shows that nobody’s here. I can’t drive Chrome, apparently. Um, and that’s because it did update, but it didn’t persist that anywhere. So, we didn’t have any kind of verification. We’re

[06:15] just checking UI, seeing, oh, did that actually do anything? And yes, it did do something to the UI, but we didn’t check the other half, and so it was never persisted, and we lost that email. So, sorry, Zach, you’re not signed up. >> It’s okay with me. Um, yeah, I think this is a really critical point. So, uh, just show of hands, who in this room is is building with a ton with agents, just to start with the first question. Okay, awesome, like more than half of the room. Uh, how many folks are running multiple terminal tabs or multiple chat sessions or multiple agents, like everybody that put their hands up the

[06:45] first time, right? And so, this is what we’re all experiencing, at least what I’m experiencing, what Nick’s experiencing. If this is the 18th, you know, lane of work that you’re driving today, and you have like, you know, diffracted attention to actually spend on it, these are the subtle bugs that will creep in because the agent’s like, yeah, I did what you said, the code looks good, it builds, it runs, the test pass, and it’s still wrong. And so, what we’re going to ask and explore in this workshop together is, how do we actually fix this problem so that the agents that we’re now all managing as like herds of

[07:16] insane token machines uh, can actually figure out what they need to do themselves and when they’ve made a mistake. >> Yep. >> And you’ll notice that we are aren’t really looking at the code for this. We’re not really going to look at the code too much for this because, uh, like I said, I saw PHP and I’m scared, so we don’t look at code anymore. >> [clears throat] >> Um, but all of this builds up to this great quote by, uh, a famous potato on, uh, X, call, uh, her her name is Lauren 10. Uh, and she has this quote, if any agent, sorry, if an agent can verify its own work, nothing can’t verify if an agent can’t verify its own work, nothing else matters.

[07:47] >> Yeah, another way to say it is is that and I think this is true in in my experience and others as well is that we’re kind of converging on the point that verification now, especially as model capabilities advance rapidly is is one of the key foundational things to focus on, right? It’s like reliability and verification and evals. Especially as we’re starting to see more and more harnesses come online that have the concept of RSI or you know, recursive self-improvement baked into them. It feels like we’re shifting to a world where we may all be maintaining multiple self-evolving code bases eventually,

[08:18] right? And in that world, how do we set the eval foundation so that the agent actually knows what good looks like and can do those hill climbs on its own and then how are we going to give the agent the feedback it needs to understand that it’s failed something. >> Yeah, until we can solve that, we’re not going to trust these agents to really accelerate our work to its fullest extent. And so we need to solve that in various degrees and it’s not just going from zero to one, but it’s a gradient and getting us closer to one to where we can fully trust these agents is is the goal.

[08:49] >> And I’ll also just share that you know, again, anecdotally, this is what we’re all experiencing at WorkOS. We’ve got an applied AI team that’s building a ton of different stuff for other teams and for ourselves. And it is just a night and day experience when you are iterating on a code base that has, you know, the foundational eval in place, a baseline that can be run and trusted. You know, we’ll get into some of the tips and tricks, but the ability to actually see that it did or did not do something correctly in the same way that we would as human developers, right? So we’re, you know, of we’ve the the metaphor of us all

[09:20] becoming agent harness managers is is, you know, well trod. This is how we ensure that each one of them is actually doing correct work and we’re not burning money and time essentially. >> Yeah, this is the equivalent of saying like make no mistakes, right? Yeah, if you want to have some verification in there, you can’t just like guess at what it needs to be. You need to give it clear, defined goals to get to and give it a way to observe and check those goals. If not, the agent’s going to do something and it’s going to spend some tokens and it might get to the end that you expect it

[09:52] to, but there’s no guarantee of that. Every for every detail that you don’t fill in in terms of an outcome and what you actually want to get to, it’s just going to infer that or make something up and that assumption that it makes may not be the assumptions that you make or that you were expecting because you’re a rational logical human and you were just not aligned on that yet. And so um you need to have these systems in place to allow for it to observe, understand what you want, observe that, repair that

[10:25] and then recheck that. >> Yeah, and I think just again, anecdotally like we’re all finding that you know, the tired way to do it is to have a giant massive PR and have one agent session that’s running for three or four days and say fix this, fix this, fix this, make it better. And what is working, you know, essentially perfectly for folks is decomposing tasks really cleanly, giving the each task an agent in the prompt exactly what it needs to do to know that it is actually done and to verify the state of done. And those will just rip. I mean, we have people on our team that are 900 PR’s a

[10:55] month and and no incidents and like improving KPIs for the software. So just anecdotally it is um something that we all kind of have to take a step back and think about. I’m not approaching this code base anymore in the traditional way. I’m almost gardening multiple code bases and letting them self evolve. Yeah. >> And this is something that we build and we hold our own tools too as well. This is how Zach and I stay productive at Work OS and how we get our own work done. We’ve each built kind of our own examples of this and our own ways of

[11:27] approaching this. And we really think that that’s like a good thing right now. It’s too early to really classify on anything, so experimentation is key, finding what sticks and then running with that. And uh one thing that we’re both running with is the verification piece or like driving everything from that verification loop. Uh because uh as as it says in this quote here for for mine, uh status comes from records, not model pros. Um so it’s it’s, you know, show me the receipts. Show me the actual tangible proof that it actually did it uh what I

[11:58] expect. Don’t just tell me, “Yeah, it passes, it looks good.” Um because there’s nothing to back that up. I need actual screenshots, videos, test results, smoke tests, um any all of the above to prove to me without me having to look at the code that it’s actually doing what I want. Because at the end of the day, I don’t care about the code as much. I care about the result and what it’s doing and what value it’s delivering. And it can have bad code, honestly, and deliver that result pretty well. Uh or it could have really good code that doesn’t uh give me that result at all. And I need

[12:28] to find the right balance in there, which is giving me the result that I want, not the code. >> Yeah, indeed. Uh so I’ve been doing this as well. I I built a tool that I call context or CTX. It started out as a cross-agent harness memory layer cuz I’m rapidly experimenting, as all of us are, with like ChatGPT, Cloud Code, uh Pi, etc. And I wanted them to all be able to write and read from memories, and that started working. And then the more that I was running more more multiple agents and, you know, average day is like 18 or 30 terminal tabs, the more that I realized uh it might be an interesting experiment to try to centralize

[12:59] authority for verification in a web service. So the CTX is a simple web app that runs on Cloudflare. It was vibe coded initially. It works. Uh it started as memory. It was able to hand out secrets to agents without them ever seeing it or getting the credential. And that worked, too. And then now as an additional experiment, I’m creating verifiers. And the way that that works is the agents are assigned work, as we’re all doing with prompts. They go off and do that work. They come back through the MCP connection to CTX and say, “This is what I’ve completed. Uh am I done? Please verify it. So, let’s say in the example of um

[13:32] uh one of the workflows needs to verify that a PR was created correctly. And so, that is going to run an evaluator on a known verifier. That could just be a simple CLI to start with as it is in my repo, and then that becomes a hardened piece that you can reuse again and again. It’s going to the GitHub API and verifying that that PR truly does exist and is healthy and that all the merge checks pass. And only then will it mark that node satisfied in the workflow. Otherwise, it will redirect to it will redirect the agent and say, “These are the things that are still failing.” Right? And so, again, an

[14:02] experiment, but this is kind of how we’ve been trying to play around with this and see which patterns are are going to stick and and what works and what not. Um but it’s also just kind of a fun time to do that five coding because uh I require uh weird pixel art across all of my apps. So, uh you can see in this case there was a simple workflow. And one of the verification gate is that requires that all pull requests were merged. And so, that work is done by the centralized authority. It goes out and uses its verifier, checks the API or whatever the artifact is, and then finally delivers the status over here on the right sidebar if you go to even

[14:33] down, and references the actual repository checked and the PR, right? So, simple example, but you could imagine having standardized verifiers in a library or in skills or in tooling that you share amongst your your org, and this could be one of the ways that you start to build toward accelerating, you know, PRs and and less and less human oversight. >> Mhm. >> Uh and then a similar tool uh that I built is called Ryker. This is more like a engineering-focused Grokbot or Muse uh that’s trying to be extremely flexible in how you hand work to it, but then

[15:03] once you hand work to it, its job is to babysit it. And so, I don’t want to have to babysit all of the PRs that I’m I’m bringing to fruition. At some point there’s a like this level of diminishing returns for me and my focus on on the work that I’m doing because I end up just like babysitting the PR, you know, fixing the tests, fixing the the reviews uh that are coming in, the the review comments and things like that. So, I want to be able to get the idea down of like what we should be doing and how we can verify that that work is done uh and

[15:33] then I can hand it off to Riker. It can go do the work of, you know, making sure that the the reviews are done, uh that when it fixes code uh from PR reviews that it’s still matching our overall goal of working software uh in some way, and then uh can just verify that and and alert me back when it needs me instead of me having to baby sit it. Um and so, with that it’s just um you know, it builds a check, it figures out what tools it needs to run, it will run them, uh verify that they all pass, it’ll keep

[16:06] that evidence and show it to me in different ways, uh and then decide when to stop. So, if it can verify yes, it was working, we’ve now fixed this bug, for example, um we put them together and it works. Uh so, it’s really just keeping me out of having to be in the minutia of shipping the the like final 10% uh and just focusing on where I’m valuable as a human, which is why we’re doing the work and how we’re and uh to an extent how we’re doing it.

[16:36] >> Okay, so maybe just as a mental experiment or a thought experiment, if you will, let’s just kind of show of hands like or feel free to shout out like how would we start to think as a human developer of verifying a web app like maybe in the before times before an LLM. >> Yeah, what are things that you would do to verify? >> And we’ll we’ll throw some easy ones up here to get it started. So, like refresh the page, is the application still visible, right? What’s that? Absolutely, yep. Open a new tab, see if it’s healthy, right? What are the response codes I’m getting back from the

[17:06] API? Are they expected based on what I sent it? Absolutely. >> Local host or local storage, checking persistence in some way, console logs, um things like that. Network, uh, like you said. And, um, like reading what’s actually on the page. Do the contents of the page actually >> Interacting with it, right? And the reason we’re we’re saying this is like this is really to set up the the transition from we were the human developers doing this all the time. This was part of our core responsibility when we’re hand chiseling code, if you will. And then, what is the delta between

[17:37] doing this and then in the the early stages of LLM time saying, “Here’s three paragraphs of text. Go execute these instructions.” The delta between those two things is the agent’s ability to verify that it actually did what you asked it to do in a real application and that its changes did not break anything. Right? Otherwise, you’re just getting the confabulations that LLMs are designed to give you cuz they’re they’re trying to process the text. They’re trying to make you happy.

[18:08] >> Uh, your agent can’t do any of this just in a terminal alone. Uh, it needs tools to do that. Uh, fortunately, tools are very easy to add to >> agents now. >> Um, and we just have to tell them how to use it. We’ll tell them specifically what we’re trying to to prove. Um, when you do that, you don’t want it to be just a paragraph of like, “Hey, do this very always verify the change in a browser.” Whatever that means, that’s pretty vague. Uh, “Remember to reload and check.” That’s a little bit more specific. Uh, “Check that the data persists.” Look at the console for errors. Uh, getting a little more

[18:39] specific, but like that’s a lot, um, to put in there and you can certainly do that. That’s what a lot of skills do. That’s what what a lot of just like saved prompts do. Um, but if you forget anything or things change, that can leave it up to a lot of interpretation. Um, one thing that might be better is to have a script that can prove it out in different ways, um, so that you can just run that over and over and it’s doing more of a deterministic check across a number of things and then it can feed that output back into the agent and it knows exactly what was wrong

[19:10] uh, and how to fix it quickly. And it just closes that loop so that it’s a much faster uh and the agent can just spin that, run it again, check, verify, run again, and just do that over and over until there’s no more errors. >> It’s also uniform if you think about it, right? Um we know that LLMs are non-deterministic, so even giving 30 agents the exact same prompt and you have a potential for variance in your outcomes. And pinning it down to a single command that is backed by actual bash commands and bash calls, right? Like that’s that’s significantly more deterministic. And anecdotally, the folks uh like Lauren Tan and others that

[19:41] are achieving thousands of PRs ostensibly a month and uh building ambitious products that were not possible to build in that time before have mentioned that this is the first thing that they they concentrated on that actually unlocked the velocity, right? So, if your specific web app, for example, does not already have a bespoke CLI that allows any agent to fully flex the functionality that you care about verifying, then you’re going to have a much rougher time and an unpaved path if you’re using prompts, you know, alone uh compared to actually, again, giving each

[20:12] agent the ability to say, “Yes, I actually built that feature. It is actually performant. It didn’t cause any errors, and the application looks correct.” >> So, for this workshop, uh we made a little tool. Uh we’ve been running it a couple of times, but it’s called snack. Uh and you can just run it with PNPM snack in that repo. Uh it’s not meant to be like a reusable tool, but just kind of like a template for how you could set up this uh specific for the applications that you’re working on, and then use that as a way to tie into the LLMs that are actually working on that application with you. And so, snack can do a couple

[20:43] of things. It can uh manage the health of the application. It can bring it up, it can take it down. It can run a doctor command to see is it actually, you know, is the database running? Does it have network connection? Et cetera. Um that quick drive or that quick check that it can do. Uh then it has uh drive, so you can tell it to join. Remember, this is our our uh midnight snack waitlist. Uh so, it can join the waitlist. It can reload the page, it can reset all of the data so it can’t find it. You can have it look up things, so take a snapshot, uh, look at the network storage, look at console

[21:15] logs, um, look at local storage, uh, screenshot it, run evals, all of all of the above. Uh, and then finally it can prove it in two ways. It can actually run a prove command where it’s checking for deterministic output of that. And a judge, which is using a system one model to, uh, in like, get an idea of whether we’re going in the right direction without it necessarily matching one to one. >> Just to, like, fully develop this idea, when you do something like this in a repo that you haven’t already had something like this before,

[21:45] the velocity gains that you unlock are not solely for you, right? It’s for everyone else on your team that then comes along and is also able to issue significantly more PRs significantly faster and significantly safer, right? More safely, so that, um, you know, everybody on the team actually benefits. And again, that’s like where we we keep harping on this being like a foundational concept now. >> Yeah. Uh, and if you think about it, like, that’s a really big piece of it it might even be more important than your software, uh, than the actual application is the way that you verify

[22:15] it, the way that you test it, uh, the way that you prove that it works because that is what you could use potentially, like, a lot of people are doing and converting to Rust. Um, you could take your app, uh, like the Bun team did, convert it to Rust, uh, Go, TypeScript, convert it to Go, uh, not necessarily with the same level of LLM help, but, um, they did use LLMs to help with that. Um, and then I think Theo just last week converted it to Rust again, so. >> Yep. >> Uh, when you want that, if you have all of those verifiers in place, then your

[22:46] source code doesn’t matter as much. You can write it again and prove that it works. Keep going. >> Absolutely. >> And so, um, these tools give your agents their eyes. Or you if you think about it, like, the tools that your agent use, that gives it the body. The LLM is the brain and then the way that it reaches out and interacts physically, uh virtually on your computer is through these tools. And so, things like uh join is it like actually having it run and do things and then it can check and see,

[23:17] you know, did I did I that actually succeed in some way? Uh check storage, run reload, uh snapshot, etc. And so, let’s just run a couple of these uh and see. P snack up. That brought up our um browser. And then I’ll open up another browser or another terminal. I have too many terminals. And run um P snack snapshot.

[23:47] And that give us a snapshot of the page in as JSON that we can see. If I put um Zack at zack.zack uh and add that to the page. Hopefully, we’ll see some Zacks in there. There we go. So, that’s a way that we can verify. Uh we can also do screenshot to make it a little easier. That should pop up a screenshot. And yeah.

[24:18] So, that gave us the ability to, for example, not just like pass this to the LLM and have it do interpretation on it, but like proving back to us. That’s the end goal, right? Is proving back to the human. Being able to take screenshots, record videos, put those on the pull request. You can do that with the the GH CLI now. >> Um Chrome debug debugging tools. >> Chrome debugging tools, yeah. >> Where is the actual bottleneck? Don’t guess and, you know, spin your wheels for 3 hours. Like actually figure out which part was causing the render to be slow. >> Yeah. So, the real key here is that there’s no

[24:48] um it’s it’s not just code that you can look at to interpret whether this this application is running correctly, but you can build tools that will help you prove to you that it’s working correctly without you having to read the code at all. Uh because this is all we care about. Is this what a user sees? Is it correctly rendering in this browser at this width with dark mode, with light mode, etc. And you can run infinite tests on that and run them over and over and over in a loop, uh which as Zach said unlocks your whole team to move faster because it you’ve given the agent the ability to

[25:20] run those checks itself as well. So, [clears throat] if we run this uh if we ran it just like this where we ran the doctor uh and then we add uh ada@example.test and then we check the storage, it’s there. We run uh if we check the storage, it’s not there. Um we would see local storage is empty. And if we rerun reload and then snapshot, we would verify that it is in fact empty. So, this is a way that the tool itself could run in a loop, could

[25:51] check all of these things, and yes, confirm with before it even gets back to us. Oh, I see that we’re not actually persisting this. I forgot to do that part. And the agent can just move on from there. Um real quick, we wanted to stop and take a a few questions if there are any. >> Yes, sir. >> Yeah. Uh so, the question is uh are we uh using models to write JSON uh to to then like help us to make our code deterministic, to bring that back. Um the answer for me is yes.

[26:23] Uh I’m I’m using that and I’m running it and then I use uh like I’ll I’ll use unit tests around that to verify in different ways, catch edge cases, uh and then verify that the code that that is like a real interpretation or real representation of what I’m expecting to get back from like a system one model, uh and use that to prove that that I’m on the right track. But, then have keep those as well to kind of like have a another check uh to make sure that it doesn’t drift over time or things change.

[26:54] >> The the the general process that we’re talking about? Yeah, so when what I’m talking about, uh, at least on our team, we we build a ton of applications that are internal tooling. We have some customer-facing applications as well. They tend to be uh, TypeScript and they tend to be deployed to Cloudflare. So, they’re you know, they’re full-stack applications. It works perfectly. You can even have evals that are focused on the back end or database operations. All right, you could get as granular as you want with it. Um, but it’s absolutely yeah, it works full-stack and and I expect that the way that we’re all going to continue interfacing with software in the future is just going to be kind of like the gardeners making sure that

[27:25] they’re evolving correctly on our own. Yeah. >> That’s why uh, we’re not like giving out a tool because we couldn’t give you a a tool at this time that works generically for every single application that everyone in this room is working on. You kind of have to build up the tools that fit the app that you’re working on and then give that to the models and just make sure that they know how to run them well. Um, as a >> I was so I was I was also going to say like your evals, what you actually need or care about as a team or company or business or going to wildly differ from, you know, if you’re in like the interior design space versus some other place

[27:56] where like speed is the only thing that matters. Um, I I think you’re going to have like wildly different evals and there’s a value to building those up with your team. >> Yeah. And there’s there’s lots of different ways to get the data to the like to the model in different ways for so that it can interpret it and it can keep up. And that’s like a a huge piece of like keeping the model in the loop as to what’s going on. Uh, the AMP team has a really great post on it. I think it’s called I can’t remember the the post, but I’ll get it out there. I think it’s called loop-driven develop I don’t know. I

[28:27] can’t remember. But uh, what they in in the example, they show like a canvas with a circle and a ball bouncing inside of this circle uh, and then like there’s a little slit where the ball if it hits just right, it can fall out of the circle and then the game the game is over. And uh, the whole idea of that is making things feedback loopable. That’s what it is. Um, where you know, the model can’t actually see the running canvas and where things are going, but if you, as a very contrived example, if you just print out the coordinates of that ball at every point, and you see a bug where, you know, once it gets to this specific

[28:58] point, it jumps to the other side of the screen. Well, if it’s moving more than one pixel at a time, like per loop, something is wrong, potentially. And so, there’s a bug in there. If you can surface that to the model, then it can help you debug it, where it doesn’t actually have eyes to see the canvas and see the ball not behaving well, like with physics. So, >> And also, once you do that, you can you’re also then free to spin up 30 different variants of software that are, you know, speaking to that eval, and then pick the one that you want. >> Yeah. >> Um, so, that’s the other thing that it

[29:28] unlocks, right? It’s really like foundational for just going, and especially if we expect agents to models to improve, you know, tokens to get cheaper, potentially, um, then, you know, you can imagine that we’re all going to be like coming in on Monday and saying like I would like to see 35 versions of this new feature or application here. >> Yep. >> And pick one. >> And so, how do we actually run or create that? Well, in this case, like we said, we can’t really prove it, uh, for everything, like universally. It really has to be something that’s unique to your application. And so, for our midnight

[30:00] snack page, this is what the proof, uh, the proof command might look like, where it’s basically using, uh, a tool like Playwright, um, to check that a, uh, an email was actually saved when it gets on the waitlist. So, uh, we can check that it doesn’t have any on the waitlist, any emails, then we can fill in an email on the next line, and then we can get the button and click it, uh, the join waitlist button, and then we can expect that the status, uh, element on the page has a waitlisted in

[30:32] there, uh, and then check the inner text of that to see if our email address is in there. Um, and so, that’s one simple way to do it, very easy if you’ve ever written, uh, an end-to-end test with like playwright or react testing library, any of those, you’ve definitely used tools like this. You can just give them back to the model to your agent and they can run them. Give it to them as a tool and they can prove it out themselves and you’ve made this reproducible bit of evidence that then you can use in this one next time

[31:03] you use it next time that page changes it can run it again and verify that nothing broke. It acts as a regression and keeps everyone on the team moving forward. >> [clears throat] >> One caution word of caution though, like a successful screenshot isn’t proof. Make sure that it’s actually showing, you know, the state that you expect it to be in, that it actually like ran the commands to get to that state to actually be in there because otherwise it might just be like another lie, but you’re seeing a screenshot on the

[31:35] the PR and thinking, oh yeah, this is this is correct, but it might have be causing different side effects. It might have taken a different path that’s not actually possible within the UI. So you want to make sure that it actually like runs start to finish to check that. >> Yeah, and so once you build these loops that are, you know, durable, reliable, repeatable, uniform, the value of what you get or the benefit the main benefit is that a a failure starts to drive future work, right? So if in one loop the agent fails,

[32:06] you’re busy talking to somebody at work or you’re starting yet another task, that agent can determine on its own, this is not quite correct. Let me go take another stab at it. Let me now run the command verify again. Okay, now we’re good. If you think about what that means at scale that a single PR or an agent a single lane of work, if you will, and an agent, you know, self heals, self corrects, figures it out on its own, you’re not coming back to that particular PR at the end of the day and and then being like, oh, I still have to get this all the way through. And if you just multiply that out, right? That that’s that’s really where

[32:38] again, we just say this is foundational for speed and velocity. Yep. >> And how many of you write good error messages? Show of hands. >> Yeah, nobody knows. We already know. >> [laughter] >> Sir, what’s your message? >> I got small hands. >> There you go. Yeah. >> Solid. >> Um well, you should. Uh I think they’re more important than ever because uh when your your uh app throws an error, guess what can interpret and run with that error really well? An agent. So, um if you make it so that your failure is

[33:09] explicit about why it failed and give as much detail as possible about how it got into that state, then uh your agent can just like self-heal from that. So, it’s um very easy, very worthwhile to to do that. >> Uh yeah, and so this is a concept that you know, Nick and I talk about, right? And it sounds like we’re being uh in some ways we’re trying to wrap determinism around LLMs, uh but we actually don’t want to do that. And it’s also something to the spirit of what the amp team is talking about. Uh the agents

[33:39] are in in intelligent. They’re they’re capable. We want them to be creative, actually. Because oftentimes if they have the right constraints, and then oftentimes constraints can be can equal freedom, right? In a way. Uh then they will come up with creative solutions and actually solve what you said. That’s why you give them the outcome. That’s why, you know, Nick’s project he’s experimenting with is outcome-driven development. Um and so, it’s not about over being overly prescriptive in how the agent achieves things. Um that can actually lead to lower performance in some cases. It’s

[34:11] more about giving it the map and saying you must get here. You’ll know you’re here when this command returns this. >> Yeah. You don’t necessarily have to prescribe how it gets there, though. And this is true more and more true every single day with like the frontier models. Fable, Astra, Saul 6.1, uh Opus 5.5. They’re all really good at being like you being creative is like the way I I describe that. But, if you give them This is where I want to get to and don’t necessarily tell them the path that they need to take, they might wander and make

[34:42] sure that they catch more edge cases. They might figure something out or ask you a question that unlocks something. But, if you’re just like you have to get here and then here and then here, they may not sway from that. And you want them to sway a little bit, but get to the right right end goal. And like I said, this is something that we we’ve only come around to really appreciating in the latest batch of Frontier models. Uh where it’s really becoming possible. So, going forward, it’s going to just get better. >> Yep. >> [clears throat and cough] >> So, when it’s going, um you want to get into like, you know, the

[35:13] typical TDD like red, green, refactor loop with your agent. Um we’ve talked You’ve heard about loops, you know, at every one of these AIE events, and um it’s no different here, but you can use that within the verification piece itself. Verify this, reproduce it, show me uh fix it, and then show me the proof of that. And how are you going to show me the proof? That’s just as important as the fix that’s going to go in, because that’s what’s going to leave leave you alone and allow you to trust the model to actually do the work. And And then when it says, “Hey, I’m done,”

[35:43] you know that it’s done because it’s proved it to you in some way. >> Absolutely. >> So, in this example, uh you can run Snack Doctor. Let’s just go ahead and run that real quick. P Snack Doctor. And so, this uh this ran, and it’s showing us um you know, a bunch of checks that it did. So, it’s checking that we have Node, that Chromium’s installed, uh that our session exists, uh that it’s actually

[36:15] running, and that it successfully built. So, that’s like what we’re running as a quick doctor check, just a bunch of different things. So, then we run the next command, Snack Join Ada at example.test. >> Sorry, we don’t type anymore. >> [laughter] >> Okay. Gave us the result back. Snack storage. Storage is empty. It didn’t actually put

[36:47] Ada in there. >> So, this is the point at which in the real world your agent you’ve just gotten the value out of this entire system cuz at this moment your agent realizes I am not done and I’m not going to drop this work on the floor. >> Yep. And if you reload it, do the same thing one more time. Boom. We have now given our app eyes. It can see this. It can run these. It can make it can make sense and change the world of the application, the Midnight Snack application, and see

[37:18] the results of that and then be able to interpret what happened from there. >> [clears throat] >> So, you can try that. You can If we like apply the persistence fix to it and add honest copy to it, then we can um run the proof. Let’s run that. And that kicked off a browser and it failed. I didn’t actually run the test, but if we had run the fix. If we had run the fix, it would show that.

[37:52] >> [clears throat and cough] >> Okay, one of the things that we’re we’re thinking about a lot lately and talking about and starting to roll out into more applications is this like concept of receipts. Um you know, you can you can take like a ticket like a a help ticket system where it’s there’s a certain performance the way that a human would answer a ticket and consider it done well as an excellent, you know, customer response or service. And then what does the um like preserving that in some way, for example, right? Uh why do we want to do that? There’s a ton of reasons and we’ll get into some of them, but again, if you think about

[38:23] if it if we all or if it seems that in some way many many folks are heading towards, you know, running RSI harnesses and self-evolving code bases, everything that we do today, everything that your agent does today, every run all day long, that is very valuable data. It’s very valuable data right now because you can feed it into LLMs and and get fixes that you need. It’s incredibly valuable data in the future as tooling improves and it gets easier and easier to set up RSI loops because then you’ve got a data set of exactly how your system performed that

[38:53] you can create, you know, very comprehensive evals for and have agents hill climb on, which means loop and see their performance and then continue going until they get better and better and better, right? >> Yep. And at that point they’re able to pass on their own using that evidence from the previous runs. >> [clears throat] >> So now, if we fix that code, it now persists, but it can also lie. So after we reload the page, it could say wait listed, but what the screenshot might actually

[39:24] say is you’re in, your seat is confirmed. Those don’t exactly match up, and so that might be like a failure right there because they don’t exactly match. So this is kind of getting away from the static testing piece of it. Like how do we prove that it worked without having to be like very tightly coupled to the actual text on the screen for a very contrived example. And so if we just run like, you know, P snack, judge,

[39:56] should run that and it failed because even though it worked and it says that we’re in, Jev did not the the model did not see that. And it’s because the the confirmation text breaks the contract. It’s not exactly one-to-one. So how do we fix that without adding a lot of tight coupling to everything that we’re doing. The answer is those system one models, which we’ll get into here. >> Yeah, absolutely. So, just to introduce it for anyone that

[40:27] hasn’t heard of it before, the you know, concept of system one, system two comes from psychology actually. It’s like a useful model to think about how the human brain works and how he thinks. So, system one is super fast decisions. It’s It’s, you know, autonomous. Like, someone swerved at me while I’m driving and I just corrected without even thinking about it kind of thing, right? Some I was about to lose my balance and I I corrected it. And then system two is like I need to figure out what I’m going to do with my life. So, I’m going to go book an Airbnb and like think about it for 3 days. >> [laughter] >> And so, you know, applied to the world

[40:57] of LLMs now we’ve got Jev and then immediately after we’ve got Cleft from Cloudflare, you know, 2 days later. That’s even faster. And so, there’s It’s It’s a really exciting time to think about all the ways that we can combine these tools together to make the new primitives that we’re going to continue to see in evolving AI architectures. >> Yeah. To get Put it another way, that light right over there, if I said, “What color is that projecting?” Quickly you would say yellow. That’s like system one thinking, right? You just You know the color. If I said, “Why is it projecting yellow?” Well, because we’re thinking. Now we’re thinking, you know, we could

[41:28] go down like a physics of why the light emits yellow. >> Why are we here? >> [laughter] >> That’s how we got to really what we want to talk to you about today. >> [laughter] >> So, in this we’ve got another game that we can play within within this. It’s a quick game with the snack. We have saboteur and a detective. And so, in this the the saboteur will pick a snack. It’ll put a secret bug in there, randomly putting a bug in there.

[42:00] We don’t know which. It’ll just be random. And then you, the detective, find it with with snack alone. And then prove what that is. Name the bug and give give proof that you found it. So, this is something that you can do if you’ve pulled down the website or pulled down the repo, um you can just run pnpm snack up –bug random and uh give it uh let it run and see if you can find it. So, let’s try that. We’ll just give it some time to go. Uh what was it?

[42:31] –bug >> bug random >> Oh, it’s already running. Let me kill that. Kill the right one. Okay. So, [clears throat] in this uh it ran

[43:02] uh it’s got the app URL, it’s running, it’s not headless, so we can see it. The bug uh says hidden until you stop up. Yeah, right. Um leave this running in another terminal, run pnpm snack doctor. So, let’s run that. All right, so that ran the whole thing and we can see node’s there, chrome’s there, it’s got a session. The proof here, uh the last receipt says fail, but the source is now

[43:33] uh that proof is for code that no longer exists, so it wasn’t able to prove that. That was a previous run. Let’s run it again. Same thing. Uh can anyone tell me what the bug is? Any ideas? Wrong email? Yep, exactly. Port’s wrong.

[44:06] Uh I think it was running at 62174. No, that was right. Let me try it one more time. We got less than a minute.

[44:39] Uh, for that one, yeah, you do. >> The tools make it optional though, so you can run through all the exercises if you don’t have it and it’ll just go, but um, it’s also good opportunity to experiment with one if you do. >> Yeah. >> They’re they’re pretty cheap calls. >> Uh, they give you $5 for free when you sign up and I think that’ll last you like 3 years. >> Yeah. >> All right. >> So, [clears throat] um, yeah, go ahead. Next one. Yeah.

[45:11] >> Um, so, yeah, we ran it a couple times. I think there was some problem with my output. I’ll debug that. Uh, it’s funny, I need some verification tests around my verification my contrived verification examples. Um, but the, you know, the the outcomes that could come up are uh, that it named the bug uh, with output, uh, said it works but it didn’t, uh, said it works but it did, uh, blamed a bug that wasn’t there, um, and then had no, it was the right

[45:42] bug or no evidence. >> Right. And this is just getting back to that point of uh, a contrived example, of course, but your team might score differently or have different criteria that you’re looking at. This is super flexible. The most important thing to do is to start and to create one, create an eval baseline and to use it consistently and to evolve it together as a team, and then get to the point where your changes and your PRs automatically flex that eval so that you can get to the point where you know if changes are safe to land or if they’re improving things or if they’re making things worse or if they’re not changing things at all. >> Yep.

[46:13] Uh and every time it runs and it misses, um that’s a new line that can go in the map. So, it can give us ideas of like the steps that we’re getting there, why we’re getting there, and kind of like you know, every time it fails, it’s getting us one step closer cuz we can fix that. So, the first time uh is memory only, um like it’s not storing anywhere but in memory. Uh we’re putting in a wrong email address. Uh we’ve lost our confirmation. Every time we can prove that we’ve caught that and then we don’t run into that again. Um but then the over promised one, uh

[46:45] the screenshot or the judge running uh can tell us that it um it actually did pass when it didn’t. Same thing with console error. Uh there might not be anything in the console, um but it’s in the receipt or it might not be it might be getting caught um before it gets to the console. Um yeah, anything like that. Or it could just be none. There’s nothing to find. Everything works. Um and that’s a real answer as well.

[47:18] Um yeah, if you run the doctor, kind of like what we were doing, it was showing this where it was showing the previous uh examples. Um it’s showing proof that no longer exists. Uh that’s because your code might have changed quite a bit between yesterday and today. Um it might be different circumstances, like a a famous date bug, um for example. It might be a number of different things. So, uh we want to build the tools in such a way that they’re flexible enough to uh not get caught by um

[47:48] issues like this. Uh this is all kind of like going back to you know, basic unit testing examples, uh but bringing that kind of like deterministic check to the models in a way that they can self-heal and self-improve from there. >> Absolutely. >> [clears throat and cough] >> Okay, so this again to tie it back to what we used to do as human developers, right? What we used to be able to see, how we would flex the application, how we would check everything. Uh, that’s really what we’ve been talking about and moving it into code.

[48:19] So, by moving it into code and making it available in a deterministic CLI, then we can get to the same path and the same experience that we would flex as, you know, developers when in Chrome trying to fix something late at night. And that’s really what unlocks the the speed and the evolution and the ability to scale up the amount of code that you’re delivering and to do that in a more safe way. Uh, again, you know, if you uh, the recommendation is if you have a web app uh, and you’re not already you don’t already have a custom verifier CLI,

[48:49] that’s one of the the highest leverage things you could start with for your uh, code base, the foundational eval as well that shows what good looks like in your application. And then also giving your agents the ability to see all aspects of performance and uh, networking and and traffic and and rendering, et cetera. And so, giving it Chrome dev tools if you’re in um, if you’re in the web app land. If you’re shipping native clients if shipping iOS, you know, or OSX apps, then there’s an alternative uh, projects and more coming out every day that you’re then going to attach to there.

[49:20] But the the the common, you know, foundation here across all of them is that you need to give your agent the ability to see absolutely everything that you would normally see as a developer. >> Yeah, the more that you can give it, the more arms or eyes that you can give it, the more it’s going to be able to take over from you. Uh, and then you just have to give it the intuition about when to use those, how to use those. Think about the way that you decide, okay, if I this bug came in, how would I reproduce this? Think about that and if you can break it down and this is dependent on your application and the type of of code that

[49:51] you’re writing, um, you can you might be able to do that in a way where it can like think, “Oh, you know, for us it’s a lot of sign-on things. Like, is it properly setting a cookie? Is it setting an expiration in that like all of that?” >> the in the job, right? You can go again like the this is applicable to every, you know, field and industry that you’ve got software for. Um but it’s it’s really just all about like, “Hey, that world where it made sense for us all to hand-chisel code all the time is at least evolving or at least changing rapidly. What are the foundational like what’s the what are the same system

[50:21] fundamentals that we bring to this now so that we can accelerate software development?” >> Yep. Uh so, yeah. Doing expensive call stacks. Uh but the the important thing is that uh getting that output, making sure that it’s giving you detailed output about what happened, uh the state of it, uh all of that so that it can be audited by the application uh by the model, and then you can run it again, it can fix it, run it again, and verify that those changes actually took hold, and that there’s no longer an issue.

[50:53] >> Uh and yeah, and again uh can’t overemphasize the value of keeping receipts. So, if you have runs, uh you know, it can be the entire user journey. Let’s say it’s an e-commerce app. It’s like when they log in, they hit the page, what happened, what was their flow? Did they see an error at all? Did they see 7 seconds of time to see your catalog, you know, come into view? Uh were they able to put something in their cart? Was there cart abandonment? Um and so, tr- save that all now because every single one of those runs and receipts can be fed to LLMs, or you can even set up a system that’s running all night long and is looking for uh the latest

[51:26] receipts being produced, and is aggregating them, and saying, “Well, today we saw eight failures in the caching module. So, I’m obviously going to, you know, issue a PR tonight to fix that properly.” And then, “Oh, I have the tools I need to prove in this PR that the issue I was trying to solve has been fixed.” Uh and then the recommendations that we’re seeing from from folks, too, that are achieving like super high scale PR uh shipping without errors. They’re they’re also able to, you know, add uh the stuff that is for us as humans in our oversight still. So,

[51:56] not just screenshots of the feature, but like a recording of I walked through the app this way. This was my flow. This is what I experienced. These were the states and I got to the goal. So, that if I’m waking up and trying to rip through, you know, 15 important PRs in the the first thing in the morning, I can first start watching that and make sure okay, it actually got to the end and worked. Then I can, you know, start looking at code uh if it’s something that I’m actually going to like human review. And uh again, all of that I think is going to be immensely valuable as we continue to see uh evolve self-evolving tooling, really.

[52:29] And you know, think about what that means though because when we get to the point where there’s self-evolving tooling is just like the default and people are using it, uh there will be a specific advantage for folks that have preserved uh clean data sets of things that they can say this is what we are trying to get to in this application and want you to get all the way there and rapidly improve it, right? If you’re not sitting on a mountain of that and your competitors are and they have similar apps, they’re going to be able to go significantly faster in their development cycle. >> Yep. And this is just building up that trust so that we can continue to improve

[52:59] upon our app as we go, uh but we have these checks for everything that came before it. So, we’ve got unit tests, we’ve got evals, we’ve got smoke tests, we’ve got whatever our application needs and we’ve got a way for the model to be able to interpret and run those and improve them uh in such a way that if we add new features in, we can run all of the previous ones and make sure that we didn’t actually break anything, uh no regressions, and we can just mount and climb that evidence ladder, building evidence as we go, uh and ensure that our app is working uh exactly as

[53:31] expected. And that really becomes the the spec that shows what our app does. Okay, cool. So, we’ve got uh just over 5 minutes. I’m going to pause and see if there’s additional questions. Yes, sir. >> So, does the scale I I would personally I’m curious with how you think about it. I would I would personally almost lean away from skills cuz in my experience it’s it’s you know up [clears throat] to the model whether or not it’s going to actually follow that path and use it

[54:02] versus like having the CI actually enforce that these these commands get run as well. Yeah, that’s what >> Like the answer or the question is how do you run these these checks normally, right? Effectively. >> [clears throat]

[54:37] >> Yeah, it can you can run those you can run these regularly. You can have them be like part of CI for example. You can have them be various hooks that could be like a get hook although that’s probably the last one I would reach for. We could have it be like a cloud code hook. It depends on what your team is using and how they’re they’re doing it. I might build like a full pi extension to keep things running in the background and just kind of like feed in information as it’s going. There’s a number of different ways that you can do that but the easiest way by far to get everyone across the board and

[55:08] I can say this now just put an agents.md not a cloud.md in your in your app and then have it say like you know on change verify things by running this or like every time you change significant things or before you open a PR do this. Like whatever wording that you want to put in there and then that’s an easy way to get everyone across the board and they really kind of have to go out of their way to ignore that or avoid it. >> Hooks are also relevant too if you’re doing the local development, right? For the whole team cuz you can share hooks across the board.

[55:46] Yeah, absolutely. Yeah. >> Well, CI is a is a I think a feature of it, but it’s not like the the actual tool is like the rapid development that you get locally. So, I give my agent a task to do and I can just quickly run uh like let the agent go. You know, I basically tell it this is where I want to end up. I want the waitlist to be I want to be able to add an email to the waitlist and then it gets persisted uh and saved and I can verify that. Uh so, this is how you verify it. It goes into this table, blah blah blah. Like whatever it might be. Um

[56:17] Yeah. No, good question. Sure. Yeah. Yeah, what’s the benefit of running it in CI versus like a local Sure. Uh the benefits are definitely like a

[56:47] faster feedback loop, which allows us to run faster and allows me to uh parallelize myself because I’m no longer working on just one thing at a time. I’m working on at least right now I have three agents running. Uh that’s a very low day for me, but I’m at a conference. Um >> [laughter] >> Normally, it’s like 10 to 15. >> He’s really taking it easy today. >> Um and and the the whole idea is like I’m going to set it off and I want I don’t want it to be waiting on me and saying, “Yep, I did it.” and then I go running and it’s like, “No, that’s not actually correct.” and then I have to like set it off again and I go get

[57:18] distracted by another agent again and I just continue that loop. I’m just like constantly moving between projects. So, I want to give it the tools to where it can prove to itself that it did it and then prove to me that like show me the evidence in a way that I can trust uh so that when I come back to it it might be in 5 minutes it might be in an hour or a couple of hours I want to know that it has done the best possible job that it can to get done to a state of done so that I’m not just like re-prompting it and starting that whole loop again because I don’t want to

[57:48] be that’s that’s not the fun part of my job. >> Yeah, I would I would say another way to to put it is that and we haven’t everyday achieved this perfectly but I want to have all of the different lanes that I started that day for stuff that I felt was important to ship that day. I want to come back to them at the end and see them basic like correctly done. What I don’t want to do is have a whole long day and have them running in the background be doing other stuff and going to meetings and then come back and then actually have to turn by turn nudge any of them because that is like a significant slow down and it it prevents me from going faster.

[58:19] >> And another way to put this is I’m like I rely on CI and the tests that are running in CI and the code reviews like we how many people do automated code reviews with like Reptile, Code Rabbit, Codo, any of those? Yeah. I rely on those. We use Reptile. Reptile gives me a X out of five score and if it gives me a five out of five and all of my CI is passing I feel extremely confident that I’m not going to break production when this gets shipped. We’ve gotten to that level of trust with Reptile. The more important thing for this is that I get to that state faster and that

[58:52] um >> with less turns >> With less turns, yes. And that you know, I I might add a whole like I could add 10,000 lines of absolutely nothing and it does nothing and great it passed. Reptile gave it a five out of five for some terrible reason and then it goes into production and it doesn’t do anything it doesn’t break anything. Now it’s just an extra 10,000 lines of nothing. Um and so this is also to help me make sure that like I’m I’m telling the agent like exactly what I want and it gets there without going through a bunch of um

[59:22] additional code to or additional like like it stays on track uh but it also knows how to fix itself to keep itself on track while I’m off doing something else. >> Okay, we might have time for one more quick question, but I think we’re Yes, yes, sir. >> Yes. Yes.

[59:53] Yeah. You could also You could also do depending on your stack like there’s it’s also you know there’s various providers that you could easily also go to preview first and make and then verify it there in a different way. So we’ll then go to prod and then also immediately monitor. It’s another pattern we’re starting to see emerge is that when folks have a deployment that was mostly agentically implemented, there’s also at least one agent specifically concerned with that production rollout looking for watching all the metrics, watching DataDog, watching feature flags, right? Being

[1:00:23] able to say this is this is actually bad and we’re we’re reverting it. Um so I I think that like I I truly understand and get the like queasiness around it like we all have or dealing with that, but I I I do see a path for that um because it just seems like it seems inevitable. Yeah. Yep. >> That’s all the time we have, but if you have more questions we’d be happy to chat. We’ll be in the expo hall booth six right to the right when you come in. Come find us. We’d be happy to chat to chat, show you what we’re working on and talk to you about anything you’d like. >> Yeah. Thank you so much for coming and

[1:00:54] your attention and everything. Thank you so much. >> [applause]