Meetup #23 - Monad Bugfinder: Construindo agentes de segurança com IA - Antonio Viggiano

Transcript

Vocês estão ouvindo? >> Fala galera, tão ouvindo? Acho que você tem que baixar ele falou que vai esperar uns 5 minutos lá para >> a gente vai esperar uns 5 minutinhos. >> Tá vendo? Aham. >> Grande falar para você assim, cara, a certo dele, é verdade. Qual é o nosso era minha vida e for para zero bosta, né? Sea for para 10k. Já tô tá tô

amarrado com isso ainda. [risadas] da é completamente Vou ficar aqui para admitir

está sendo gravado. Isso >> beleza pode começar. Pode. Beleza. Então, boa noite, galera. Bem-vindos aí Meetup 13. Ã 23, né? 23. S 55. Eh, eu, bom, para quem, para quem não me conhece, eu sou o Antônio. Eu eu tô trabalhando com segurança em cripto faz uns 4 anos, mais ou menos.

eh mais recentemente focado assim na área de fuzing, que é uma metodologia de de testes, eh, e basicamente de tentar encontrar bugs em smart contracts. E faz uns três meses eu entrei na Monad Foundation, que é a foundation por trás da blockchain Monad. A Monad é um é uma out layer one, né? Então, é EVM compatible, só que é focada em auto putut, por 10.000 transações por segundo, eh, mas com 100 100% EVM compatible, então você pode usar Solid e tudo mais.

E aí lá na Monet Foundation tem um time de segurança onde eu trabalho na área eh de protocol security. Então eu eu tô tentando proativamente evitar bugs na blockchain, né, na na no nos nós da blockchain, nos nós de execução e consenso e também trabalhando junto com os com os projetos do ecossistema, então os times de DeFi que vão deploar na MONAD, ajudando eles na parte de segurança também, a tipo como ter eh contratos mais seguros, né? e também como eu posso fazer ferramentas que ajudam a todo mundo que tá deployando na blockchain, como como conseguir escalar essa parte

de segurança. Então esse talk vai ser sobre eh eu até coloquei aqui, né, como a gente tenta construir workflows eh genéricos o suficiente que eles não se perdem quando você tem um modelo novo. Então existe uma um acho que uma questão bem relevante, né, que é tipo assim, nossa, mas quando surge o o modelo N, o modelo N + 1, parece que, tipo assim, tudo aquilo que você fez pro modelo atual, você pode jogar fora e começar do zero, porque o próximo modelo ele ele sempre é muito melhor do que o anterior. E então é muito fácil aquilo que você tá fazendo se tornar eh eh

obsoleto assim, com com uma velocidade cada vez mais rápida. Eh, mas tem algumas coisas que elas aparentemente não se tornam obsoletas tão rápido, que é o que eu queria focar hoje, né? tipo, eh, enfim, quais são as competências que você constrói para AI, que elas eh se carregam mesmo quando o modelo avança, que eu acho que é a parte mais útil, né? Então, tipo, enfim, você não tá jogando fora o seu trabalho.

>> Eh, deixa eu ver. >> Beleza. Então, eh, >> po compartilhar a tela um pouco? >> Ah, compartilhar a tela. Beleza. >> Esse meme ótimo. Eu eu eu sou esse meme que é tipo o o meme é os AI engineers. Fala o meme é tipo assim, ah não, você tá você só tem um rapper em cima do chat de PT. Não, não é um rapper, é um harness. E aí, o que que é um harness? O harness, eu tô usando a definição de um de um de um artigo que tem a referência aqui mais

para frente, onde eh ele define como o conjunto de cinco verticais e todas essas cinco elas podem mudar. E dependendo de como você muda essas cinco verticais, o o output do seu modelo ele é mais ou menos eh eh enfim, tem maior ou menor sucesso na tarefa que você tá tentando fazer, né? Então, tipo assim, obviamente o mais importante de todos seria o agente que você tá colocando. Eh, é o Cludo, Codex, eh, Kim, né, sei lá, tipo, o Rio de Janeiro fez um recentemente. Enfim, é qual agente você tá usando. Aí tem ali também a topologia da sua dos da sua

da da sua arquitetura entre esses agentes. É, então, por exemplo, quando você quando você tá simplesmente falando com Codex ou com Cloud, a sua topologia é simplesmente um nó. Então, imagina que você tem um grafo onde cada agente é um nó e as setas são eh a forma como esses agentes falam um com o outro, né? Tipo, e então, enfim, você pode ter um grafo de um nó só, mas você pode ter também dois. Se você tem, por exemplo, um agente que, eh, por exemplo, faz o desenvolve, você tem outro agente que revisa o full request, por exemplo, então você tem dois agentes e você pode ter infinitos,

tipo assim, muitos agentes. Essa seria sua topologia. Aí você teria eh uma outra definição que é eh como como você passa mensagem eh entre esses entre esses agentes. Então, o jeito mais fácil é tipo através de arquivos, né? os os agentes, eu acho que eles eles até têm essa tendência sem que você instrua eles a fazer isso sempre. A e também acho que até como uma forma de bypassar ou de superar os limites de contexto e de eh memória, né? Eles têm uma tendência muito forte em escrever aquilo que eles estão fazendo em arquivos de texto, tipo Markdown Jon.

Então, por exemplo, então imagina que você tem vários agentes e você tá você manda mensagem de um pro outro através de Jon, através de Mark Files. Seria uma maneira de você passar passar passar a mensagem. Outra outra vertical seria as ferramentas que seu agente tem. Então, tipo, eh, por padrão, os agentes eles já vêm carregados de algumas ferramentas, né? Então, tipo assim, quando você tá falando com o seu cloud, ele consegue ler arquivos, ele consegue escrever arquivos, ele consegue pesquisar dentro de um arquivo, ele consegue pesquisar na internet, tem algumas ferramentas, mas você consegue dar ferramentas adicionais. Eh, e isso é é uma coisa que acho que assim, as pessoas fazem pouco porque as ferramentas padrão elas já

conseguem resolver tudo que você precisa praticamente, mas entregar ferramentas adicionais pros agentes também ajuda muito a que essa a que a tarefa seja executada de forma mais precisa. Então, imagina, por exemplo, que você tá eh fazendo um sei lá, uma uma eh tipo, você precisa, vamos supor, classificar imagens, né? Tipo, ah, essa imagem aqui ela, a, qual é a cor dessa imagem? Sei lá. Você pode fazer uma ferramenta que é um script e esse script ele processa a imagem e ele entrega a cor. Então, quando você eh executa o seu agente e passa essa ferramenta pro agente, o agente ele vai executar essa tarefa de forma determinística. Então, isso faz

com que o resultado da tarefa seja primeiro, seja sempre o mesmo, né? que é muito importante, dependendo do que você tá fazendo, e também eh exige menos do agente em termos de contexto, ou seja, eh eh o o agente se perde menos na que na na tarefa que ele tá tentando fazer quando ele tem uma ferramenta especializada. Então isso seria aqui um um outro um outro uma outra vertical que você tá dando pro pro seu harvest. E aí seria a a a última que seria mais mais ou menos tipo assim como como você tá colocando isso tudo junto, né? Tipo como você tá coordenando os diferentes agentes na sua topologia, no seu nas nas mensagens quais

ferramentas. Então isso aqui é é o seu hardness. Eh, e aí, eh, acho que a primeira parte interessante, né, tipo assim, é, é você conseguir, eh, acho que assim, identificar primeiro que quanto quanto mais acho que assim, primeiro o harness ele, dependendo da tarefa que você vai executar, ele vai ser diferente. Então, tipo, ah, eu preciso no meu exemplo, né, bugs em segurança, eu quero achar bugs, eu vou ter agentes específicos com prompt que vão tentar achar bug. Eu vou tentar às vezes ter uma topologia que vai ter enumerar vários tipos de bug, depois rodar vários testes, enfim. Eh,

dependendo se você tiver fazendo um harness que vai tá classificando fraude, vai ser tudo, todos esses aqui vão, todos esses verticais vão ser diferentes. Então, entender como, como fazer o seu harness, né, como fazer essa orquestração, ela varia de de acordo com o seu use case. E aí, bom, beleza, na prática, né? Eh, esse aqui seria um exemplo de um harness que que que eu construí na na para achar bugs especificamente da blockchain moned. Eh, esse aqui foi baseado em dois artigos, duas referências. Eh, um que é focado, se não mudei

um que é focado em encontrar bugs, seria esse finder aqui, e o outro que é esse triager, que é focado em validar os bugs. Eh, e, e, e, e aí, basicamente, né, tipo assim, fazendo um paralelo com aquela com aquelas definições anteriores, né? Então aqui eu tenho, em resumo, eu tenho seis caixinhas, tipo cada caixinha dessa é um agente. Eh, e a forma como a mensagem tá sendo passada de um pro outro é através de um banco de dados.

Então, nesse caso, eu escolhi não usar arquivos de texto porque eu queria maior eh maior eh observabilidade, né? Tipo, é, é mais fácil você identificar se os seus arquivos no, se o se as informações que estão sendo colocadas no banco de dados estão corretas. Além disso, o banco de dados também te permite ter informações estruturadas mais fáceis, né? Tipo, porque a validação já é feita na no próprio momento da escrita do banco de dados. Mas basicamente, então, eu tenho as caixinhas são agentes, eu escrevo mensagens no banco de dados, então é tipo um posstres.

Eh, as tools não tem nenhuma tool especializada. o que é um grande problema, porque isso faz com que os agentes percam muito tempo para eh executar tarefas bem simples. Então, tipo assim, por exemplo, um exemplo prático, né? Você precisa rodar um teste, aí que que o a gente faz? Ele vai lá, ele lê o projeto, aí ele escreve o teste, aí ele roda o teste, aí ele vê o output do teste. Aí, tipo, isso são tokens e tokens e tokens que simplesmente para rodar um teste, ele gastou centenas de milhares de tokens. Se eu tivesse uma ferramenta específica para rodar testes, ele gastaria tipo 10 vezes menos tokens e economizaria tanto dinheiro, né,

custo, quanto, eh, que nem eu falei, deixaria a tarefa mais assertiva e também consumiria menos contexto do agente. Mas, enfim, essa versão inicial não tem nenhuma ferramenta especializada. Eh, e aí, e aí qual qual que se então tem a questão da mensagem, as ferramentas, a topologia e e quais são os agentes que estão sendo usados. No caso, eu tô usando tanto o Cloud quanto o Codex. Todas essas etapas são executadas duas vezes, né, uma em cada modelo. E aí no final tem tipo uma uma eh um tipo um veredito determinístico, que é os dois modelos concordam? Sim.

Então essa é o resultado final. Qual? O Cloud concordou com o Codex. Se eles não concordam, aí é triagem manual e acontecem muitos casos onde eles não concordam. Então, tipo, o esforço de triagem manual, ele é bem alto nesse nesse exemplo, porque às vezes o cloud não concorda com o Codex. Então, tipo, isso também é um é um hã eu acho que é um é uma questão que, enfim, tem um espaço para melhoria grande deixar a deixar a a etapa de análise mais determinística, né, de eh enfim, menos onerosa pro pro revisor final. E aí aqui eu coloquei tipo as as duas referências, né, que deram esse

deram esse sistema. Não sei se vocês viram, mas o Antropic, assim que eles lançaram a o anúncio sobre o mitos, que é o o modelo mais eh eh mais poderoso que que eles construíram, eles fizeram um post explicando como que eles usaram mitos para para tentar identificar vulnerabilidades em alguns softwares open source, por exemplo, no Firefox, né, e outros softwares. E aí eles mostraram que o modelo deles era muito simples, tipo, basicamente assim, é muito simples até de um lado negativo, tipo assim, é assim, na verdade assim, a a lógica deles de procurar bugs era

muito simples, ou seja, tem muito espaço para melhorar, mas o modelo era tão bom que mesmo sendo simples, ele achava os bugs. E aí é mais ou menos isso. Então, tipo assim, ele ia no projeto, listava todos os arquivos, né? via todos os arquivos eh identificar e para cada arquivo ele eh identificava, ah, dá um score e o prompt, né? O prompt era assim, ranquei esse arquivo de um a cinco sobre a probabilidade de encontrar bugs. Mais ou menos isso aí. Ele vai lá e dá ah, nota um, nota dois, nota três, nota aí para cada um dessas notas você pode priorizar, né? Vou focar nos nota 5 primeiro. Aí ele eh nessa etapa de hunting, ele tinha um outro prompt que

basicamente falava: "Baseado nesse arquivo, encontre uma vulnerabilidade e classifique eh eh quão interessante ela é. Então, tipo assim, assim, algo nada eh tipo científico assim, né? Ah, qual que é qual interessante essa funilidade?" E depois e pronto. E aí depois ele então faça uma proof of concept para essa vulnerabilidade. E ele dessa forma eles acharam centenas de bugs, na verdade dezenas de milhares de bugs que depois foram se afunilando, né, nos bugs relevantes mesmo e foram algumas centenas de bugs relevantes, porque eh e aí isso é isso é uma um um dos problemas

desse exemp desse desse prompt muito simples, né, desse harness que ao criar um um prompt muito simples, e com poucas validações, muitos bugs pouco relevantes são levantados. Então, no na própria análise, né, que eles que que a Antropic soltou depois desse post inicial, tipo assim, desses 10.000 bugs, na verdade só 100 eram críticos, mas existiam 10.000 bugs, mas tem vários bugs que não são críticos. E isso é e isso eu acho que em parte é explicado pela pelo prompt muito simples, tipo assim, ah, quão interessante é esse bug.

Enfim, eh, então, basicamente é esse essa o artigo que que gerou a origem desse finder que tenta achar bugs. Só que aí a gente tem um outro sistema que tenta validar o bug para eliminar falsos positivos e e tipo assim, putz, eu não vou ler 10.000 bugs. Eh, eu quero ler só os mais importantes. Então, existe aqui um outro paper também chamado TXray. Na verdade, esse TXray ele é eh ele o objetivo dele é eh eh fazer root cause analises, então entender qual que é a causa raiz de um hack a partir de uma transaction hash na blockchain.

Então, dado um link do er scan, por exemplo, né, sei lá, você identifica qual que é a vulnerabilidade que aconteceu no smart contract, faz uma proof of const, faz uma po em foundaryry e essa po tem que ser eh genérica, então generalizável para que você possa tipo eh enfim, né, para que assim consiga demonstrar que qualquer pessoa poderia ter executado o mesmo hack. Basicamente isso. Então, basicamente a gente, eu, eu peguei esse paper, era era um dos primeiros na época que explicava como fazer esses eh esses eh eh essas orquestrações de agentes para detecção de vulnerabilidade. E aí, basicamente

isso. Então, tipo, então, eh, da mesma maneira, né, tem vários agentes, cada um é especializado em uma etapa e, e, eh, e essas etapas elas elas são elas são basicamente uma triagem, né? Então, o na a primeira etapa é ah, você falou que tem esse bug, né? Então, a acho que acho que a primeira primeira parte importante é é ver que os LLMs eles eles eh acho que assim pela pela própria arquitetura, né, onde eh cada mensagem ela ela é reanalisada como como fio da conversa por inteiro. Se você começa a mensagem de uma forma

muito assertiva falando que o bug existe, a tendência da conversa é continuar achando que aquele bug existe. Então, então logo de começo você já tem que, se você tá querendo fazer uma triagem, você tem que ir do lado contrário e tentar refutar todas as hipóteses, né, todas as claims, todos os argumentos que estão sendo colocados pelo aquele pelo aquele report inicial. Então, basicamente, esse verifier ele tenta, ah, beleza, eu vou eu vou enumerar todas as hipóteses que estão sendo colocadas, eu vou de forma independente rodar os testes, eh, que eu acho que na verdade acontece aqui, eh, eu vou rodar os testes de forma independente e eu vou eh criar testes

adicionais seguindo uma lógica cada vez mais complexa, né? Então, tipo, eu vou começar fazendo teste unitário. Ah, o teste unitário realmente confirma o bug. Beleza, eu vou pro próximo teste. O próximo teste seria um teste de integração, onde eu tenho tenho dois módulos, né, duas bibliotecas e eu vou ver se confirma que essa biblioteca realmente vai deixar o bug passar, porque às vezes existe um cenário onde uma biblioteca tem o bug, a outra valida do bug. Então, na verdade, esse bug não não tem como chegar em produção. Aí teria uma terceira etapa, então vou fazer uma po end to end. Então, eu vou subir o sistema inteiro, eh, fazer uma mensagem através do RPC, por exemplo, para tentar verificar o bug. Eh, e aí

por final eu teria uma uma etapa de de julgamento assim, né? Que tipo, ah, dado todas essas evidências que eu tenho, qual que é é falso, positivo ou é falso, negativo? é falso, positivo ou é verdadeiro positivo. E se for verdadeiro positivo, qual que é a severidade desse bug, né? Um bug crítico, não é crítico, tal. Eh, e aí ele dá um um report aqui no final e, enfim, eh, então, tipo, que que que que isso que que isso resultou, né? eh resultou que o sistema ele foi muito bem

suucedido, principalmente na parte de triagem. Então esse esse aqui seria um um exemplo da eh da plataforma, né, onde o operador, né, que no caso sou eu, vê o sistema rodando. E aí aqui seriam as etapas, que é como se fosse um funil. Então, tipo assim, eu tô chegando bug em cima, eh, validando eles, onde no final eu tenho muito menos bugs do que chegaram no início, porque no início eu tenho hipóteses que são muito eh eh pouco validadas, né? Porque se você lembrar bem, o Finder que tá tentando achar o bug, ele tá ele tá seguindo uma

metodologia parecida com a do mitos, onde ele lê o o arquivo e fala, encontre um bug, qual que é a prova? Tipo, quão interessante é esse bug. Eh, e assim, é, é tão eh eh tão simples, né? E apesar de ser simples, ainda funciona. Isso é o mais incrível, né? E eu acho que, na verdade, isso isso liga muito naquela slide inicial que é os agentes hoje eles são muito inteligentes, né? São muito mais capazes do que há seis meses atrás. E quanto mais eh inteligente o agente, eu acho que mais essa abstração ela tá eh eh a a abstração, né, de tipo assim, putz, o bug é interess que de forma que a capacidade dele de

encontrar o bug seja muito maior do que em, pô, sei lá, no GPT3, né? Tipo o GPT5, se você dar um prompt para ele muito simples, ele vai encontrar o bug, mas se você rodar no GPT3, ele não vai encontrar o bug. Enfim. Então, mas voltando aqui, né? Então, tipo, basicamente é um funil onde as estatísticas são mais ou menos que a cada 100 hipóteses que o Finder acha, o triager confirma 10 delas. Então, é tipo como se fosse 10 para um, ou seja, tem muito mais hipótese que é falsa do que a hipótese que é verdadeira. Só que mesmo assim, mesmo tendo 10 bugs, eh,

muitos deles não são tão relevantes assim, tipo, é, às vezes é um bug minor que não causa nenhum problema em produção e a carga de eh, tipo, a carga humana, né, de review, ela é muito alta, porque os LLMs são cada vez mais incrivelmente bons em fazer um texto que te convence de qualquer coisa, tipo, eh, e então assim, para você revisar tá em detalhe e vê que é verdade, que não é verdade, você gasta tipo horas. Então a gente também tenta reduzir muito a carga do ser humano que tá revisando. Então assim, na prática existem 100 hipóteses, 10 são verdadeiramente bugs, mas só uma a gente

manda pro time de desenvolvimento, porque todas as outras nove elas eh são minor, né? Então, tipo, a gente prefere agregar. Então, ah, em vez de mandar uma, tipo, em vez de mandar 10 mensagens, eu mando uma mensagem só, tipo, ah, tá aqui esses, sei lá, 10 bugs minor para vocês olharem quando tiver tempo, mas eles não são tão relevantes assim. E aí, em termos de custo, né, tipo, eh, esse $ seria essa esse número do meio, né? Então, tipo, eh eh assim, é é praticamente linear o custo, tipo, para cada, sei lá, um bug que eu reporto, é como se eu tivesse gastado $. 1.000 em crédito. E para cada 10 bugs válidos, é como se eu tivesse

gastado $ em crédito, né? Porque, enfim, eu tô multiplicando por 10 aqui cada uma dessas etapas. E para cada um desses eu é como se eu tivesse gastado $ para cada hipótese. E isso sem nenhuma otimização, né? Tipo, daria para otimizar em cada um dos cinco, das cinco verticais. Eu posso otimizar escolhendo agentes mais baratos, posso otimizar fazendo uma topologia mais simples ou menos simples, eu posso otimizar colocando mais etapas eh determinísticas que aí eu não vou gastar uma chamada de API para um modelo caro e tal. Eh, mas apesar de não ter nenhuma otimização e tipo assim, depende do use case, né?

Mas $000 por bug é muito barato porque para uma para uma blockchain, né? Porque eh um bug crítico dependendo depende da blockchain, mas tipo na média é 1 milhão de dólares. Então se eu gastei 1000 para achar um de 1 milhão, foi 1000 vezes de de ROY, né? tipo, eh, mas enfim, não que esse sistema tenha achado nenhum bug crítico, mas mesmo dependendo das outras severidades, em 100% dos casos é um ROI positivo no sentido de se algum white hat encontrar esse bug, né, tipo a pel através do programa de bug bounty, a a

você pagaria para ele o equivalente do do bounty, não? Então, então, tipo assim eh isso isso é interessante pensar que isso torna a a a o a racionalização sobre a detecção de vulnerabilidades muito mais financeira até, né? Tipo, porque você consegue precificar quais tipos de bug você tá encontrando e quanto você tá eh pagando at pro pros white heads de uma forma que antes era muito mais difícil sem AI, porque sem AI eh o que você fazia era você pagava um custo fixo por auditoria, né? Então,

tipo, por exemplo, eh, eu não eu não sei valores exatos, né? Mas tipo assim, sei lá, $1.000 000. Não é um absurdo você pensar numa auditoria $.000. Você paga $.000, mas você não sabe quantos bugs você vai achar. Aqui eu tenho certeza que eu vou pagar 1.000 e vou achar um bug né? certeza estatisticamente. Eh, e e o outra coisa muito interessante é que, tipo, o custo de encontrar o bug, ele não é relacionado à severidade necessariamente por causa da da e eu acho que é muito por causa da questão probabilística ligada a esse sistema, né? Então, tipo assim, eu eu posso pagar 1.000 e economizar 100.000

1000 ou não, eu posso pagar 1.000 e achar um monte de bug inútil. Eh, teve recentemente um um bug do Zicash, não sei se vocês acompanharam, mas o ZCash um eh eh foi encontrado um bug eh crítico em um dos Eu não sei em detalhes como funciona ZCAS, mas basicamente encontrar um bug crítico que permitia eh mintar infinitos tokens de Z cash de forma praticamente 100 100% não rastreável, já que a esse minting

ele seria eh em uma em uma pool encriptada. Enfim, eu posso estar falando algum detalhe, não 100% tecnicamente correto, mas mas basicamente você mintava tokens de forma totalmente eh eh invisível e aí isso fez o token cair incrivelmente. Eh, e o mais incrível dessa história é que esse bug foi encontrado com o cloud 4.8, com prompt super simples. Eh, e enfim, como era um bug live, né? Tipo eles, a a ZCash Foundation, enfim, eh comunicou esse bug pros usuários e

tiveram que fazer, enfim, vai ter um upgrade, sei lá o quê. Eh, mas enfim, foi um bug muito impactante através de um prompt super simples feito por um um auditor. Eh, então, enfim, acho que o core o core aqui né takeaway é sobre como isso se torna uma questão mais financeira e mais precificável, né? Tipo, como você consegue precificar os bugs que você tá encontrando. Ó, tem um comentário, ó. Ah, um comentário do do LAN tá perguntando, tá comentando sobre

que era um bug na prova blockchain, não no código. Pô vou ó só vou repetir a pergunta. Eh, outro exemplo parecido foi um eh Ah, não é, na verdade teve uma um comentário anterior, semana passada eu tava debugando um bug, não tinha que ajudasse, o bug era no kernel do macOS, parecido com esse. Outro exemplo foi o Reverge numa transação que não deveria reverter, mas eh uma semana debugando descobriu que o bug era na prova blockchain, não no código. Maior parte do tempo gastou caçando, era um bug de ferramenta de terceiros. Tem alguma ferramenta que ajude com isso? Olha, essa é uma ótima pergunta. Eu eu não sei dizer explicitamente ou especificamente, mas eu acho que ajustando o seu harness

consiga resultados melhores do que simplesmente com eh simplesmente usando a CLI do Codex ou do Cloud ou eh ou perguntando diretamente para eles, porque eh e isso isso também tem muitas pesquisas e eu deixei referência só no final, mas eu vou passar por isso. que mostram que quando você usa, mesmo usando modelos mais simples, você consegue resultados muito bons, às vezes até equivalentes ao modelo superior, se você tiver um harnesso.

Então, nesse nesse exemplo, né, tipo, eh muitas vezes você tem que instruir o seu modelo a e um nível mais a fundo na camada de dependências. Por exemplo, eh, ah, verifique a as minhas libraries se tem bugs na library. Aí, se não tem, tipo assim, em última instância, verifique o kernel se não tem um bug nesse kernel. Só que é complicado porque cada cada camada mais afunda que você vai entrando, você tá gastando mais, né? Tipo, eh, nos seus tokens do seu agente para poder investigar cada vez mais a fundo. Isso também isso também é uma dúvida, uma dúvida muito grande na parte inclusive desse sistema do eh que chama

buger, de encontrar bugs na monedag. Quando eu comecei, eu simplesmente apontei o modelo para os bugs nos no na nos módulos core que eram desenvolvidos pelos desenvolvedores, né? Só que aí chegou um bug no bug bounty de eh esse bug já foi corrigido, que era um bug numa biblioteca ou ou seja, tipo assim, o meu sistema deixou esse bug passar porque eu não tava escaneando as bibliotecas, mas alguém, sei lá, um um white head escaneou e achou o bug. Então isso acontece.

Eh, beleza. Aí, outro sistema aqui também, esse aqui é o mais alfa, porque isso aqui ainda não é público, vai ter um outro blog post sobre esse que é relacionado a fuzing. Eh eh eh, ô, eu não mudei ainda, eh que é relacionado a fuzing para solidity. Então, eh, essa aqui é uma ferramenta chama ter fuz. Não sei se vocês já usaram o cloud tem um um bagulho chama ultra code. Aí eu copiei o a nomenclatura, que ele cria ele cria um workflow para fuz tests em

Solidity. Eh, e aí essa essa ferramenta mais recente, né, isso aqui foi criado a partir de um de um suporte que a gente deu para um time que iria deploiar na Mon. Então, tinha um time que ia deploar seus contratos na Mon, eles não tinham nada de fuzing. E aí falei: "Nossa, putz, esse os contratos deles tinha muita otimização". Opa. Eh, enfim, os contratos dele tinham muita otimização, muito assemble. E eu falei: "Nossa, isso é o us case perfeito para vocês fazerem fuzing". E e eles não sabiam como fazer, não tinham tempo suficiente. E aí isso, essa ferramenta começou através de eh de

um esforço de guiar o AI para construir os testes, né? Então, tipo, basicamente eu falei, "Ah, crie eh sei lá". Bom, em primeiro primeiro lugar, né? usavam hard hat. Então, ah, então vamos fazer foundarry, crie foundary testes do zero. Ah, faça, eh, identifique quais são os atores do sistema, identifique quais são os workflows do sistema, identifique quais são as propriedades do sistema, enfim. Então, basicamente, eu fui ao longo de uma semana, mais ou menos, criando todo esse workflow para eventualmente ter fuzing e também ter eh invariants, então, tipo stateful fuzing, para conseguir testar os projetos dele, testar o projeto deles do início ao fim.

E beleza. E aí no final disso eu percebi que isso dava para ser automatizado. Eh eh eh que daria para construir um harness em cima dessa dessa dessa de tudo isso que foi feito manualmente, né? tipo, manalmente, no sentido de eu escrevendo prompt o o GPT, eh, eu poderia criar uma ferramenta que faz esses prompts pré pré-organizados e a e a comunicação entre esses nós pré-organizados. Então, beleza. Então, disso tudo surgiu essa essa tool que chama ter fuz, que ainda não é open source, mas vai ser open source

em em breve, eventualmente em breve. preciso só, enfim, dar uma polida no código, mas basicamente cada uma dessas caixas é um agente. Então, tipo, tem um monte de agente. Eh, e eles, se você lembrar da definição lá do início, eh, então aqui tem tanto o cloud quanto o o Codex, que são os os modelos por trás. Eh, a forma que eles mandam mensagem entre de um pro outro é através de Jason e Markdown Files, porque tudo isso roda na máquina do desenvolvedor.

Eh, as tools, por enquanto, são todas as tools padrão que já vem by default no no no Codex e no cloud. Mas eu também quero, na verdade, tem tem algumas tools adicionais que é para visualização de coverage, eh, ou que é que é a medida de quanto do seu código tá sendo testado através desse de de stateful fuzing, só que é uma medida de coverage modificada que ela desconsidera view functions, porque a gente tá primariamente interessado nas funções que modificam o estado. Enfim, então, basicamente, tipo assim, é uma ferramenta que tem um workflow eh pré definido, onde esse workflow

pré-definido, ele foi o resultado do meu processo manual de implementar fuzing para aquele time. Eh, e o legal é que, tipo, isso tudo é extensível. Então, todo toda essa o que eu chamo de o que eu chamo, não, não é, o que chamam de topologia. Eh, ou seja, esse grafo, os nós desse grafo, eles são eh eh documentados em um arquivo de configuração, tipo em amo o file, que você escreve qual nó depende de qual nó. E aí eh os prompts todos são markdown files, então é muito fácil você estender, né? Então, tipo, ah, eu quero colocar um nó a mais. Você coloca o

Markon File ou você usa UI também. Então, tipo, ele é tanto agent friendly quanto human friendly. Eh, e aí você consegue também paralisar as etapas que são independentes umas das outras para que seja mais rápido. Eh, e aí, o legal também é que, tipo, bom, então alguns resultados, né? Eh, pô, tudo assim, foram várias iterações e melhorias de um um lado pro outro, até que no final do tudo o report que foi feito gerou tipo 20, quase 30, 27 eh bugs nesse projeto, onde foi o dobro de todos os outros benchmarks que a gente

tinha feito no mesmo projeto, que foram outras ferramentas também de AI, né, tipo de audit Mutoria de AI. Eh, aí demora para rodar essa essa todo toda essa essa essa arquitetura demora uns uns umas 4 a 6 horas, depende de como você configura, porque alguns dos parâmetros podem ser configurados. Então, tipo, ah, eu quero eh eu quero gerar mais testes, né? tipo, enfim, você configurar alguns parâmetros e aí custa mais ou menos uns 200, que tipo, enfim, depende de com que você tá comparando, mas se você tiver comparando com o tempo do ser humano, é ridiculamente barato.

Tipo, eh, para você fazer esse tipo de esforço pré AI é facilmente uns $50.000, 1.000, tipo, porque leva-se semanas para desenvolver tudo isso. Então, óbvio, né, tipo, provavelmente não está tão bem feito quanto se alguém parar e gastar tempo e pensar e melhorar e tudo mais, mas o esforço do desenvolvedor é muito menor. O desenvolvedor ele aperta um botão, é tipo uma uma CLI, um rust, ele aperta o botão e recebe o report depois de 4 horas. Eh, e se ele tem a subscription do Codex, né, de sei lá, do cloud de ó, ele gasta a própria subscription dele

e aí, beleza, semana que vem ele pode continuar usando de novo. Então, uma ferramenta muito poderosa em nessa questão de democratização, né, de fuzing, que eu acho que é o principal eh benefício. Tipo, se você pensar no funil de projetos cripto que tão eh quais investimentos em segurança que eles fazem, né, muitas vezes o investimento, assim, muitos projetos nem auditam seu código, mas quando o projeto tem mais financiamento, eles fazem uma auditoria.

Aí dos que fazem auditoria, os que fazem fuzing é menos ainda, talvez tipo sei lá, não sei, quinto, não sei, um décimo. Aí dos que fazem fuzing, talvez mais um d um desses fazem formal verification. Então, tipo, existe um um funil de investimento em segurança onde esse tipo de ferramenta consegue eh eh assim, de certa forma democratizar, né, e e trazer para mais projetos um baseline. E, e também acho que outra parte muito interessante é que assim, isso começa com fuzing, porque a assim, tipo, a a geração de valor é muito rápida. Você consegue ali ter o

seu report em uma semana, tipo, enfim, manualmente o report ele veio em uma semana, mas agora qualquer desenvolvedor consegue ter report em algumas horas. Eh, só que eventualmente isso também pode se estender para forma verification. Então, eh, através dos testes que foram gerados, você consegue tanto transcrever eles para alguma linguagem de verificação formal, tipo, por exemplo, usando TOR, no caso de Solid, né, ou, enfim, sei lá, K Control, tem várias eh e e também reutilizar algumas etapas desse workflow, porque aqui não dá para ver, mas, eh, tá escrito mais ou menos aqui, mas

basicamente, tipo, essa essa essa essas primeiras caixas, eles eles criam os testes, eles criam eh configuram o foundarry, né, para poder executar fuz tests no projeto. Aí em paralelo também fazem tipo uma uma recon do do do projeto, né? Identificam quais são os atores, lê o white paper, lê o readm, identifica o projeto, gera vários arquivos de suporte. Depois essa etapa amarela aqui seria as etapas de enumeração das propriedades do sistema, onde você tenta identificar, tipo assim, ah, por exemplo, né, no caso de RC20, quais são os as propriedades que sempre são verdade no RC20? A soma da balance de todos os usuários é igual ao total

supply, né? Enfim, isso seria um invariante. Ah, eh, toda vez que você deposita no no na Volt, o seu shares aumenta, seria uma propriedade de volt, enfim, e aí você vai fazendo as propriedades. E e aí o legal também é que, tipo, você consegue também paralelizar o que eu chamei de estratégias, eh, que são maneiras diferentes de, eh, de, de resolver o mesmo problema. Então, tipo assim, cada uma dessas taxas é uma estratégia diferente de enumeração de propriedade. Eh, algumas delas vê do da própria Certora, que é uma empresa de

formal verification. Outra vem da Runtime Verification, que é uma outra empresa que também trabalha muito com Forma Verification. Aí tem uma que é da Tree of Beats, que é uma auditoria, etc, etc, etc. Então, basicamente, eu juntei seis repositórios open source, cada um deles que tá eh trabalhando com enumeração de propriedades. Aí tem aqui uma etapa de deduplicação. Então, tipo assim, imagina que cada um deles vai lá e enumera usando diferentes estratégias, né? Tipo, acertor tem um jeito, ah, o run tem outro jeito, sei lá. Eh, você poderia adicionar sua própria maneira aqui, inclusive tem uma dessa maneira que é a maneira do Antônio. Aí você vai lá, você bota várias maneiras, depois você deduplica aqui e isso tudo é o que é o que, tipo, alimenta a sua geração de

testes. Então, cada uma dessas caixas consegue ler o output das caixas anteriores. Então, esses agentes aqui, né? Então, tipo assim, teria um agente aqui que seria, por exemplo, esse agente aqui que é stateful fuzing, né? Ele tenta executar transações mantendo o estado para quebrar alguma das propriedades. E quais são as propriedades? As propriedades que o sertor aí numerou, Runtime Verification númerou, Tur of Beats numerou, tipo sei lá quem é númerou. E aí que foram deduplicados. Aí tem um tem uma outra caixa aqui, essa caixa que é interessante, que é uma das mais complexas, que é differential fuzing, que é tipo se você tem uma se você tem uma uma implementação otimizada e uma não otimizada, ela sempre tem que ser igual, né? tipo o resultado das

operações. E aí essa aqui é complicada porque eh essa aqui tenta recriar uma implementação alternativa baseada nas especificações. E isso é muito também muito interessante que é com AI você consegue, tipo assim, o custo de desenvolvimento ele é muito baixo, então você pode fazer coisas que você nunca faria sem AI. Então, tipo assim, imagina o seguinte, você tá fazendo um projeto de DeFi, aí eu falo assim: "Ah, eu vou fazer tudo do zero, porque é muito barato fazer do zero." Aí você faz tudo do zero, aí depois você compara os dois e várias vezes você acha bug porque você vai comparar e não vai dar igual, porque quando você tá refazendo o zero, a sua implementação pode ser diferente, ela vai ser minimamente diferente.

Eh, e isso acontece, né? Então, tipo assim, existem casos, então você vai lá, você faz tudo do zero, lendo white paper, lendo as specs, eh, seria assim, a a analogia seria tipo, ah, você que nem no Etherum, você tem vários clientes, às vezes tem um cliente que faz a coisa de um jeito, tem um cliente que faz a coisa do outro jeito e isso é um problema. Eh, então nesse caso é isso aqui que essa estratégia tá fazendo. Então, tipo assim, no final do dia tem 20 estratégias. Isso tudo aqui gera vários bugs. Aí tem uma etapa de deduplicação de bug, tem uma etapa blá blá blá, tem uma etapa de geração de report e aí isso gera o report.

Eh, próxima. >> E aí, beleza? Aí, tipo, eh, cada uma dessas interações aqui foi melhorias incrementais no na Tool. Essa interação zero foi a minha o meu a minha execução manual, né? Então, tipo assim, eu fui lá e eu falei: "Codex, faça não sei o quê, tal, tal, tal". Aí eu achei 11 bugs. Aí eu falei: "Ah, vou fazer uma C." Aí essa aí ela não foi muito boa, tipo assim, na verdade ela achou só do só dois bugs. Eu falei: "Nossa, deu tudo errado". Só que os bugs eram diferentes das que eu tinha achado. Então, na verdade, tipo assim, pô, ótimo. Aí, que que eu fiz? Da dois para três, da um

para dois, eu perguntei pro agente como, tipo assim, baseado nesses logs, baseado na nas issues que eu deveria ter encontrado, quais estratégias estão faltando, porque inicialmente eu tinha criado só cinco estratégias baseado no que eu pensei com a minha cabeça, né? Aí ele falou: "Não, você pode criar mais tais estratégias". Aí pulou absurdamente, tipo, de dois para 17, enfim, únicos, né? E aí o a a contagem total foi 24. Aí eu fiz a mesma coisa, né? Então, tipo, ah, baseado nos bugs, quais estratégias eu posso aumentar?

Quais podem ser generalizadas? Foi para 27. E tipo assim, eu nem sei se pararia em 27, porque eu eu não tenho um eu eu não sei quais são todos os bugs possíveis. Pode ser que na iteração quatro acharia mais bug ainda, mas enfim, parou por aqui. Eh, e enfim, então, então tipo assim, eh, eu acho que esse também é um é um takeaway muito interessante, que é eh essa ideia meio quase do robô que melhora sozinho, né? Tipo, você pode perguntar pro robô como que ele pode melhorar e aí o robô edita o código dele mesmo, porque é ele quem tá programando. Aí ele testa e no final ele realmente melhorou. Então foi

isso que aconteceu aqui mais ou menos, né? Porque no no caso eu quem tô gerando os promps de melhoria, mas a próxima iteração que eu que eu quero desenvolver é um ciclo onde a melhoria ela o output ele gera um input, né? Tipo, então o output do modelo analisa todos os logs e a execução, identifica potenciais de melhoria, lança experimentos. Então, tipo assim, ah, você pode, por exemplo, lançar cinco agentes, onde um agente é o Cloud, sei lá o quê, um agente Codex, o Kim, não sei quem. gera cinco experimentos, olha os resultados todos em paralelo, todos de forma eh independentes. E aí você olha o que que

qual foram os melhores e e você eh faz isso, tipo, basicamente com um limite que você define, né? Ah, eu quero fazer isso, sei lá, cinco vezes, 10 vezes, ou então por durante 24 horas, ou então ah, eu quero gastar no máximo, sei lá, 500 $ 500 com essa, com esse ciclo de melhoria enfim. Então eu acho que assim, o próximo, qual que é o next step principal? É ter esse ciclo de melhoria que ele é automatizado. E os benchmarks eles também são eh eh como é que fala, né? Tipo automatizados e também autoreenciáveis.

Tipo você você termina um loop, já já dá o output pro próximo loop, já faz em paralelo e já consolida. Eh, aí beleza. Mais mais benchmark, eh, esse aqui foi da ferramenta de fã contra outras ferramentas de AI, né? tipo, enfim, não não eh esse projeto ainda não teve nenhum auditoria humana, mas eh basicamente, enfim, achou mais bugs que os outros e também com maior precisão, porque a etapa, que nem eu falei, a etapa de triagem, ela você também consegue, tipo, eh, criar agentes para paralelizados no seu no seu harness.

Então, eh, na etapa de triagem, eu gero cinco eh cinco juízes, né? E eu só classifico o bug como válido se quatro desses cinco concordam. Isso faz com que a precisão seja altíssima. Eh, porque cada um desses desses juízes, desses agentes, tá sendo instanciado com contexto diferente, o que faz com que eles tenham muito pouco env enviezamento, eh, versando num prompt só. E, e é interessante que uma delas não achou nenhum bug.

Eh, e aí, beleza? Aí, tipo, esse aqui também é uma coisa aí. Agora, beleza, falando de outro tema que esse eu também acho muito interessante, não tem a ver exatamente com a com a com as ferramentas de segurança, mas eu acho que é mais com o que eu enxergo como novo modelo de desenvolvimento de software. Não sei se depo todo tipo de software, mas eu acho que mais software relacionado à pesquisa, né, que é tipo eh é uma é uma uma coisa que eu tenho pensado muito recentemente, que é o o gap entre a pesquisa de alta ponta e a materialização dessa pesquisa tem diminuído muito com AI, tipo, eh, você consegue literalmente pegar qualquer

paper e fazer esse paper, sendo que, tipo assim, sei lá, um ano atrás Para você entender o que que o paper tá falando, você precisava ser um especialista naquele domínio. Assim, não era realista você, ah, vou ler qualquer paper aqui e sair implementando. Porque muitas vezes, na verdade, os pesquisadores eles nem explicam direito como eles fizeram aquele sistema. Ou as explicações são vagas ou às vezes mesmo quando tem pseudocódigo, na maioria dos papers o pseudocódigo tem bugs. Tipo, em vários casos tem vários papers que mostram que o paper anterior teve bug. Enfim, hoje não, hoje você consegue falar você, Codex, faça esse paper.

Então, uma coisa que eu tenho feito cada vez mais é ler papers, porque os papers eles te entregam de mão beijada a melhor coisa possível sobre aquele assunto. Então, tipo assim, por que que eu vou, tipo assim, reinventar a roda, sendo que a minha, sendo que eu posso pegar a melhor roda possível? Tipo, eu vou pegar a roda da Ferraris, né, sei lá. Eh, então, tipo assim, aqui foram alguns dos papers que inspiraram vários desses modelos então tipo eh eh desses sistemas, né? Então, e esse aqui, por exemplo, é um super ótimo paper de alta qualidade sobre multi agent, onde ele explica como então, então esse foi um

dos um dos eh esse pesquisador ele e e foi o que foi o que fez aquela definição do meme lá do início, né, que é tipo que é tipo assim, eh, essa categorização foi daquele paper. Então, o que ele mostrou é que em todos os outros papers que eles analisaram, a maioria da da dos harness, né, deixa a topologia fixa. Foi o principal insight dele, sendo que a topologia ela também deveria ser modificável. Então imagina aqui no meu sistema de desse aqui de fuzing, né, onde dinamicamente eu tô colocando novos nós, novas caixinhas e eu tô colocando novas

setas, que são as dependências dessas caixinhas. E eu também poderia dinamicamente eh identificar novas ferramentas que podem beneficiar esses agentes através dos logs e tipo fazer um um um um negócio que literalmente melhora sozinho, porque você tem um orquestrador que identifica todas as falhas e todos os gaps nos agentes de baixo, né? e e você vai melhorando constantemente. E foi exatamente isso que esse que esse cara fez, que esse cara não, não é que esse time é um time bem grande, que eles eh foram procurar vulnerabilidades no Google Chrome e acharam tipo dezenas de vulnerabilidades, várias críticas, eh ficaram em primeiro num benchmark lá,

eh, fazendo exatamente isso. Então, tipo, eles têm um sistema que faz orquestração, esse sistema identifica os logs dos agentes menores. E aí o, por exemplo, a gente fala assim: "Ah, sei lá, preciso, sei lá, tipo assim, eh, preciso testar, não sei o quê". Aí o orquestrador vai lá, lê o log e fala: "Hum, talvez eu deveria eu deveria criar um nó novo só só de testes". Aí ele vai lá e ele cria e na próxima rodada ele vê se isso melhorou. o output e é assim que ele se desenvolve e que ele acha os bugs. Então aqui tem um exemplo, tá meio pequeno, deixa eu ver se eu se eu consigo ler. Eh, mas b basicamente tipo assim, tinha duas

caixinhas, aí vai lá o orquestrador, viu o o log, falou: "Não, vou preciso de uma caixinha mais". Botou uma caixinha mais, aí viu de novo o log, botou outra caixinha, aí foi lá e achou o bug. Então, tipo, eh, com essa, com essa ideia de o orquestrador tá identificando as falhas na sua topologia, nos seus agentes e nas suas tools e às vezes nas mensagens, né? Tipo assim, essa questão de mensagem também é uma coisa muito chata, tipo, às vezes você bota o output em markdown, aí o agente gasta um tempão parcelando no markdown, sendo que se você fizesse o output em Jason, ele não teria esse problema. Enfim, também tem alguns detalhes relacionados a a o as mensagens que você cobra. Então esse é esse é um paper também, é tipo state of

the art de harness e você pode literalmente faz fazer ele. Só manda o codex ir lá, implementa isso aqui. Outro paper muito interessante sobre eh sobre a parte mais de otimização de custo, que inclusive tem a ver com o que você estava falando, tipo eh o Carpati, que é o não sei como pronunci, mas é um um dos cofounders da Open AI, que agora foi para Antropic, ele publicou faz alguns, sei lá, semanas, meses, um projeto que chama Auto Research, que é a ideia de você otimizar os a sua skill. E como você otimiza, basicamente você tem um looping Python lá que ele fez que ele

roda a skill, aí ele roda o agente e fala e aí ele tem uma métrica, né? Então, tipo assim, ah, sei lá, 15, aí ele roda de novo, aí foi para 16, na verdade ele ele pergunta pro agente editar skill, aí foi para 16, aí ele salva, aí na próxima interação piorou, ele descarta. Então, é é como se fosse um algoritmo de auto de autootimização, eh, onde quem tá otimizando a skill, né, que é o próprio prompt, é um outro agente.

Eu tentei rodar, não deu muito certo porque por outros problemas que vão estar no blog post, mas mas basicamente tem esse paper aqui também que é super recente da Microsoft, onde eles fizeram um eles fizeram um workflow para otimização de skill e também, tipo, foi 100% em todos os benchmarks. Então, tipo assim também, cara, se você quiser otimizar sua skill, usa esse paper e você vai ter a melhor state of the art, igual a Microsoft tá fazendo, literalmente para otimizar sua skill. Eh, e como e aí quais são os insightes desse paper, né? Tipo, o primeiro insight é que eh eles rodam essa skill em vários modelos

diferentes para ver como essa skill se eh com quão quão ela é transferível de modelo para modelo. Então, por exemplo, você rodou a você otimizou a skill no cloud, será que se você rodar ela no GPT vai ter um ganho de performance? A resposta é sim. Será que se você rodar no GP, aí você otimizou ela no 5.5? Se você rodar ela no 5.1, você vai ter um ganho de performance? A resposta é sim. E muitas vezes o ganho de performance ele é quase tão grande quanto o modelo original, só que o custo ele é muito menor. Então para empresas ou aplicações que estão focadas em otimização de custo, o a receita do bolo é basicamente você otimiza a skill no

modelo caro, que aí você vai lá, gasta sei lá quanto, uma vez, aí você usa a mesma skill no modelo barato e o modelo barato vai performar muito melhor, entendeu? vai vai proar muitas vezes melhor que o modelo caro sem skill. E aí tem aqui vários ventarks eles fazendo isso. Não, assim, existem eh algumas alguns tipos de problema que onde o impacto é maior ou ele é menor. Eh, mas para todos os tipos de problema, essa isso que eu falei é verdade, né? Então, tipo assim, tem, sei lá, tratamento de texto, tratamento de imagem, manipulação de Excel, código, sei lá o quê, né? Cada uma dessas colunas é um tipo diferente de benchmark. Esse aqui seria o GPT 5.5,

esse aquele ser o 5.2. E aí, basicamente, se você faz essa otimização de skill, você sempre melhora. E se você pega o que foi otimizado pro 5.5, joga pro 5.2, você também melhora. E a melhoria ela é significativa, tipo, versus o baseline, que é não usar nenhuma skill ou que é não usar a skill otimizada. Eh, enfim. Então, isso aqui também é um ótimo. Esse aqui são os mais antigos que eu coloquei só porque inspiraram a versão inicial, mas eh enfim, esse aqui é legal, mas o takeaway é muito simples.

É que basicamente se você usa o modelo diferente tem um impacto também diferente. Tipo, e nesse caso eles fizeram, sei lá, o son o Sonet 4 contra o GPT5 e o Thinking sempre é melhor. Tipo, tipo assim, parece óbvio, mas esse paper era bem antigo. na época não era óbvio, eh, e, e, e também não era óbvio quão grande a diferença é, dependendo do modelo, né? No caso aqui o GPT ele tem um salto muito grande entre o thinking e o não thinking. Eh enfim então acho que a minha minha dica é assim a a facilidade de implementar a pesquisa de ponta tá tá muito muito

muito muito muito mais alta do que antigamente. É, e aí que eu coloquei uma parte de workflow aqui para para irritar a galera que não programa ainda com AI, que é tipo como que eu como que eu faço e como que eu vejo essa essa parte de desenvolvimento, né? Tipo que que na verdade todo, enfim, óbvio ou não óbvio, mas todas as os exemplos anteriores foram feitos 100% com AI. Tipo, eu não escrevi uma linha de código e e aí como que isso foi feito? Eh, esse aqui foi o meu diagrama.

Então, tipo assim, ah, eu tenho uma ideia, eu quero fazer tal produto, tal coisa. Eh, acho, acho que a primeira coisa, tipo assim, os modelos eles ainda funcionam, eu não sei, eu não sei se vai ser sempre assim, mas eu acho que vai, que é tipo, se você não sabe exatamente precisamente o que você quer fazer, eles fazem uma coisa muito ruim. Eh, ou seja, acho que a primeira etapa de todas é você ter uma especificação do seu produto muito clara, né? você ter uma uma PRD, você ter um design document, você alguma coisa que vai dizer exatamente o que você quer fazer, porque se você não sabe exatamente o que você quer fazer, o modelo ele vai te entregar algo, mas não vai ser

exatamente o que você imaginou que você queria, porque eh se você porque às vezes o que o modelo vai fazer é aquilo que ele acha, né, tipo entre aspas, o que é o certo, baseado em como foi treinado. pouco e muitas vezes como foi treinado, é o que tá na internet e você não necessariamente quer uma média do que tá na internet, você quer algo específico para sua aplicação. Então, primeira etapa, você, tipo, tem que ter certeza que a sua specta tá muito clara. E eu acho que um um dos jeitos, lógico, né, brainstorm com seres humanos é muito eficiente até para clarificar a spec, mas também brainstormar com AI.

Conversar de forma interativa com AI durante boa parte do tempo para clarificar spec faz com que você tenha specs muito melhores e disso se traduz em construir produtos com muito menos eh erros, né, idas e vindas, porque através da spec clara o modelo faz a spec. Você pode ter um outro modelo que verifica se o modelo fez esse pack, né, que é tipo assim, imagina lá no seu workflow lá atrás, tipo, eh, só que imagina que em vez dessas caixinhas serem o fuz do não do não sei do quê, não, isso aqui é o dev que faz a spec, aí você tem o dev que verifica se a spec tá não sei o quê, aí você tem o dev que faz sei lá o quê, aí você tem o cara que faz o o code

review, aí você tem outro que faz a review de segurança. Pô, e essa ideia eh eh de de pensar em workflows, né? Eh, eu acho que ela se aplica também a desenvolvimento de software e e bom, mas eu acho que sem você saber exatamente o que você quer desenvolver, não funciona bem, porque e acho também porque, tipo, cada vez que você vai pra próxima caixinha, o erro se acumula, né? Então tipo é como se fosse um telefone sem fio.

Você começa falando uma coisa, aí o que o que o agente faz é uma coisa nada a ver. Então você tem que ter muito claro o que que você quer fazer. Então, enfim, tem um loop aqui. Aí, beleza. Ah, eu não sei o que eu quero fazer. Tipo, ah, eu quero fazer um sistema antifraude. Ah, beleza. Vai pesquisar quais são os melhores papers do mundo sobre antifraude. Você pode literalmente fazer os melhores papers do mundo. Beleza? Aí, tá, eu sei o que que eu quero fazer. Eu vou fazer um vou botar pro meu devi e fazer o que eu quero fazer. O por request review você também pode fazer para AI.

Eh, eu testei alguns já. Eu testei o GitHub Copilot. Eu achei que a qualidade do review deles era meio fraca. Muitas vezes ele recomendava coisas que eram muito simples e eu acho que isso deve ser relacionado ao custo, porque ele é bem mais barato que os outros e talvez eles usem modelos mais simples ou sei lá. Tem esse grap que eu já usei também, eu achei bom, mas tipo, sei lá, nada demais também. O que eu tô usando hoje muito é vários codex, então tipo, você pode usar vários clouds também, mas tipo, basicamente eu peço para faça cinco revisões em série, onde cada uma deles começa com um eh um como é que fala? Um contexto novo, né?

Ah, você também pode fazer até que convirja mas eu eu já tive mais experiências, tipo assim, onde ele fica num loop infinito fazendo micro otimizações irrelevantes. Eu acho melhor botar um Não, faça cinco, um loop de cinco otimizações, cinco revisões e depois é isso. Beleza? Aí você tem isso, eh, tal, tal, tal. E aí, beleza? Aí, basicamente esse é é o seu sistema. Então, tipo assim, você consegue sair da sua ideia pra produção sem tocar no código, só que existe muito eh assim, muita margem ainda para problemas de keyway, né, de produção, onde aí você consegue também ter o loop loop auto referencial de fixes, né?

Porque, tipo, se você consegue logar os problemas que você tem em algum banco de dados, sei lá o quê, você tem o AI que lê o seu banco de dados e entra na mesma caixinha. Então, tipo, eh, isso eu fiz no caso do do sistema de de achar bugs na blockchain. Tipo, eu tinha os bugs que eram enviados para um banco de dados. Aí depois eu tinha um job que rodava diariamente e diariamente ele me enviava por requests. Nesse caso eu não aprovava automaticamente porque um problema também que eu que eu que eu acho que eu acho que eventualmente vai ser, sei lá, pode talvez ser melhorado com promps melhores, mas muitas vezes o AI ele corrige bugs locais sem pensar em como resolver a o problema na raiz, né?

Então tipo assim, às vezes ele vai lá, ele corrige o bug, mas você tem certeza que esse bug vai voltar depois? Então, às vezes eu simplesmente descartava o PR, tipo, ah, não, péssima solução, eu mandava ele fazer outra coisa de novo. E e tudo bem também, porque, tipo, o custo de desenvolvimento é baixo. Tipo, se você tem o AI que tá fazendo para você vários PRs, você revisa o PR, você achou que não vale a pena, você fecha e faz de novo. Eh, enfim, então esse é esse é esse é basicamente o meu workflow. E aí, tipo assim, o seu humano, tem gente que gosta de revisar os PRs e tal, tipo, eu acho que depende depende da sua aplicação, né?

Tipo, se a sua aplicação ela eh é crítica, né? Tipo, tem eh eh ali, sei lá, tipo, enfim, valor monetário e tudo mais, mas eu acho que esse não é o caso de 90 100 sem, tipo, 90% do que a gente faz, talvez, não sei se 90, talvez mais que 50, com certeza. não são aplicações críticas e eu acho que para essas não é necessário revisar o código, pelo menos não é o que eu faço, porque se você orquestra bem a parte de revisão, a revisão do AI também vai ser boa. Então, tipo assim, eh, então, beleza. Aí, bom, outra parte mais de ferramenta, né?

Tipo, eu eu tava fazendo tudo isso até duas semanas atrás com um monte de best script. um monte decks, um monte de screen assim rodando tudo na mão. E aí eu resolvi usar ferramentas que foram criadas para isso. Tem a Open Ai, lançou Open Source faz, sei lá, um mês. Esse Syfony aqui, que é um orquestrador que eles eh conectam com o Linear, que é uma ferramenta de eh gestão de tarefas, né? Tipo um gira, um sei lá, um trelo da vida. E tem outros conectores também, mas basicamente, tipo, é um camban onde cada etapa do camban é um agente e esse agente você configura o prompt

dele, você configura como que ele roda e você deixa ele rodando na nuvem. Então isso é legal também porque tipo uma coisa que eu assim uma é uma microotimização que eu acho que na verdade ela muito importante, que é quando você tá mandando o o cloud, o codex fazer alguma coisa, você precisa ficar esperando ele codar. Então, tipo assim, eh e você também precisa ficar com o seu computador aberto, que é muito chato, às vezes ele demora, aí você perde a internet, você precisa, sei lá, entrar no Uber. Tipo, se você roda tudo isso na nuvem, os seus agentes que estão codando, eles estão rodando de forma síncrona e eles estão usando como banco de dados a sua ferramenta de gestão de

tarefas. Então, tipo assim, hoje, como eu faço? Eu vou no Codex, então eu não crio essas tesque, né? Eu vou no Codex e falo, cria uma tesque para fazer tal coisa. Aí ele vai lá e ele cria uma tesque no Liner. Imediatamente isso é executado por um agente que tá rodando na máquina virtual, que pega essa tesque e faz o loop que eu pré-programei, que eu acho que é bom, né? que é, por exemplo, que eu falei de revisão, n revisões de contextos independentes. Então, tipo, eh, ele vai lá, ele pega uma tesque todas as e aí, tipo, na verdade, se a tesquec ela não tá bem eh especificada, né, que é eh aquela questão tipo ele vai fazer um negócio que eu não quero, eu não deixo ela em tudo, eu deixo ela em backlog, aí eu vou

lá e manualmente falo, não, faça tal coisa. Ou então, às vezes você não sabe exatamente o que você quer. Então você precisa conversar com a saber o que você quer. Quando a tesquec tá bem, tá bem escopo bem garantido, você move ela para tudo e automaticamente você sabe que ela vai ser mergeada na produção, né? Tipo, é, então ela vai passando de tudo, tal, tal, tal. E e o legal também é que, tipo assim, é muito mais fácil você paralelizar o seu trabalho, porque antigamente, né, tipo, eu abri um monte de terminal e pá b pá, tipo, eh, assim, tipo, desse jeito você não precisa, tudo aquilo que você coloca aqui automaticamente vai pra frente. E aí, ó, lógico, né? Pode ser que você tenha vários conflitos e tudo mais, mas tipo, eh, eh, assim, e acontece muito pouco de

acontece muito pouco de quem tá fazendo merge, que também é um agente, não fazer um merge bem feito, porque muitas vezes o merge eh ele é uma união das duas tarefas, né? Tipo, dificilmente você tá, tipo assim, você não tá mandando ele adicionar um negócio e tirar um negócio na mesma interação aqui. Tipo, o que acontece geralmente é que você pede para ele fazer duas features. Talvez essas duas features tocam no mesmo código, mas ele faz o merge sem problema, quase sempre. Então esse gráfico aqui vem de um post da Openi também falando que, pô, antes desse sistema, eles usavam o Codex iterativo para todas as tarefas que eram de alta complexidade e alta eh alta complexidade e alta ambiguidade.

Então, tipo, você ia lá, mandava o Codex fazer as coisas. Agora eles só falam de forma interativa com aquilo que é alta complexidade e alta alta eh alta ambiguidade, né? Enfim, para coisas que não tão bem com escopo bem definido. Eh, mas para tudo aquilo que o escopo é bem definido, você pode delegar para um agente assíncrono. Então, essa seria a minha minha dica que é o último slide, não é verdade? Aí o, na verdade, esse é o último slide.

Então, tipo assim, acho que para para concluir, né, tipo, falei de três coisas meio assim, mais mais ou menos relacionadas, mas eu eu acho que o meu o meu resumo é que, tipo, eu acho que trabalhar com workflows é meio você primeiro entender o workflow que você quer, construir ele com os seus agentes e depois usar os agentes para melhorar o próprio workflow, porque muitas vezes, assim, 100% das vezes, o workflow inicial ele não é o melhor. possível, né? Você ainda assim pode executar um loop de análise para expandir esse workflow. Então, da mesma forma que, tipo, eh, sei lá, no caso da de detecção de bugs na blockchain,

eu comecei com com as caixinhas rígidas e tudo mais. Para V2, o meu plano é jogar tudo fora, recomeçar do zero, com workflow totalmente eh aberto, parecido com o paper lá do que eu comentei, né? Então, tipo assim, eu vou literalmente pegar a arquitetura deles, eh, e, e só que generalizar, enfim, aplicar pro meu caso específico. Para essa história de fuzing, a mesma coisa. Tipo, eu comecei com cinco estratégias de fuzing, não teve uma performance boa, o próprio agente expandiu para 20. Então agora são 20 estratégias e eu acho que tipo, sei lá, né, na V2 vai ter, sei lá, 50, 100, não sei, tipo, e aí o seu o seu a sua o

seu racional, assim, a o seu gargalo fica muito mais em custo em tempo, mas que também deveria tá tendo um impacto importante em quantos bugs você tá encontrando, né? E e aqui, tipo, enfim, essa parte mais de desenvolvimento que eu acho que eh enfim, acho que o meu meu meu takeway é que vale repensar o fluxo de desenvolvimento para eh o máximo possível retirar tarefas manuais de pouco risco.

Eh, por exemplo, por exemplo, pedir para o agente fazer alguma coisa, né? Eh, e é isso aí. Comentários dúvidas. Comentários >> tá no link. >> Vamos ver, ó.

Vamos ver. Pera aí. Ah tem eh beleza. Acho que começou ali com ah, o Lohan respondeu a o meu a minha ideia sobre tentar tentar. Eh, ele tinha, só para repetir a pergunta, ele tinha perguntado sobre eh tipo assim, como você pode ter os agentes que ajudam a descobrir bugs que não estão no seu código, né? Eu comentei que eu não sei, mas eu acho que uma maneira é com uma orquestração que ela vai um nível mais a fundo, né? Tipo, para você tentar ir nas bibliotecas que

estão sendo usadas em último caso até no sistema operacional e tal. Eh, enfim, aí ele falou: "Acho impossível fazer um programa sem bug. as próprias core libraries compiladores são tem bugs. Inclusive teve recentemente o o Bantag que é um an posta muito sobre Viper, tem um post dele sobre bugs no compilador do Vip, bugs, tipo relacionados a não não determinismo no compilador de Viper. Então, é nos próprios compiladores. Eh, aí beleza, o Papai falou: "Como o modelo não encoda os bugs como propriedades esperadas do sistema?"

Eu vou responder depois, vou ler as próximas mensagens. É isso. Isso, tipo assim, é uma coisa que eu ainda preciso fazer mais benchmarks, mas isso tudo é tá pré-determinado no prompt. Então o prompt é a única coisa que tá tentando não envzar o o agente, mas eu acho que daria para ser mais rigoroso, né? Então, por exemplo, né, o meu prompt, enfim, uma das caixinhas é a caixinha do Antônio. E a caixinha do Antônio, uma coisa que eu sempre falo é: "Não leia o código para gerar as propriedades do sistema, porque a implementação ela ela escreve como o sistema está funcionando, não necessariamente como o sistema deveria funcionar.

Eh, então tente identificar as propriedades do sistema através da documentação, através do white paper, através de referências eh eh tipo teóricas, né, sobre enfim, sobre a especificação do sistema, mas nada garante que o Codex não vai lá e vai ler o código, porque às vezes os agentes fazem isso. Então, tipo, enfim, né, tipo, mas enfim, é o promp de quem tá determinando isso. Aí o Loran falou: "Eu pessoalmente não acho que fuz eficiente como teste ele prova a existência de bugs, mas não a ausência de bugs. Recentemente comecei a tentar uma abordagem diferente tentando usar ferramenta que comprova de bugs. Aí tem esse VST a Pringston". Eh, eu, cara, eu acho assim, eu sou super

super otimista com formal verification mais AI, principalmente porque eu acho que a grande justificativa da dos times de fugir de forma verification é o tempo necessário para implementar. Eh, e aí assim, eu acho que a o seu argumento de que isso não deveria ser uma justificativa válida é razoável, né? Tipo assim, pô, você deveria gastar esse tempo, você tá lidando com milhões de dólares e com dinheiro das outras pessoas e tal e tal, tal. E que, tipo, putz, a NASA botou foguete no espaço há, sei lá, 30 anos atrás, com muito menos recurso que a gente tem hoje. Tipo, recurso em termos de de eh sei lá, tipo, recurso de desenvolvimento.

Mas não é isso que não é isso que os times fazem. Os times eles vão lá e eles fazem o mínimo possível. Então, tipo, em termos de custo, eu acho que fuzing tem um custo menor eh para implementar. E eu acho que AI vai deixar esse custo muito parecido de forma que formal verification seja tipo tão custoso quanto fuz, mas muito melhor. Então eu acho que isso deve aumentar a adoção. E eu acho que deveria aumentar a adoção, né? Tipo assim, eu acho que a gente deveria encorajar mais a adoção e principalmente a adoção eh através de de da geração automática de dessa desses

harness e tudo mais. Eh, inclusive hoje na block threats, não sei se vocês acompanham essa newsletter, saiu uma ferramenta de alguém lá, um que fez um auto certora com AI. Eu não testei, não sei se funciona bem, mas eu acho que, tipo, isso é, eu acho que isso é o caminho, eh, tal, tal, tal. Aí o papai falou do do entende e tudo mais. Eh, beleza.

Vários casos pode ter um bug d verificação. Fal. Eu acho que a mais antiga de tipo joga tempo nisso e se surgir muito pouco bangel nenhum você entende que a tá seguro. Eu acho que ainda é válido. >> É, eu eu acho que ela é uma métrica importante, mas eu acho que ela ela começa a ser cada vez mais questionada na medida que, tipo assim, você tem vários contraargumentos, né? Por exemplo, o hack do balancer, que era um código de 5 anos que foi hackeado.

Você tem casos de, sei lá, AI encontrando bug no kern, sei lá do qu anos. Tipo, eh, não sei. Eu eu acho que ainda é um é um proxy de segurança muito forte, né? Tipo, quanto tempo esses essa essa foi investido em Mas não sei se não sei, mas também não é uma bala de prata não só o tempo em produção, né? Mas acho que o tempo investidos também. Cada etapa dessas eu acho que é importante. Auditoria, fãs e tudo. Eu acho que é perigoso achar que a verificação formal é uma bala de prata, sabe? Porque já vi gente fazendo isso, cara. Falou: "Não, eu verifiquei isso

aqui formalmente, então não preciso fazer mais nada. Provei que não tem pan, né? >> Sim. >> Mas você verificou formalmente a sua verificação formal? Sim, sim. >> Porque é não. E o mais legal também, eu acompanho, entre aspas, muito a cena de AI para eh matemática, né? E como eles estão eh resolvendo os Airds Problem e tudo mais. Eu vi uma estatística muito legal que é tipo assim, tipo 90% 99% das provas eram erradas. Tipo assim, ou seja, o GPT realmente achou vários várias teoremas foram provados, mas muitas provas dessa estavam erradas. E eu acho que eu eu acho assim, um problema real que eu que eu acho é que as pessoas que têm capacidade de achar o

problema na prova continuam sendo as mesmas que são capazes de provar. Então, no momento onde você democratiza essas ferramentas, também tem o risco de passar um falso senso de segurança, onde quem tá quem tá rodando o alto, sei lá o quê, não sabe ver, não sabe, tipo, ver se tá certo ou se tá errado, entendeu? Eh eh e aí beleza, aí a pessoa vai achar que tá tudo certo, mas pode ser que haja um problema na prova que a pessoa não vai conseguir não vai conseguir identificar. eventualmente será que alguém vai ser inteligente suficiente para provar e para criticar o

trabalho dos modelos, né? Peg daqui 10, 20 anos. >> É bom. É isso aí. Valeu, galera. Depois vou mandar os slides aí. Valeu, >> valeu. Tchau. Tchau, pessoal. Boa noite. Bom descanso, viu? >> Já já uso.

>> Tipo, uma pessoa que é analfabeta falar assim: "Não, GPT, me escreve um poema". E aí manda outro GPT fala assim, ó. Certifica-se que esse poema tá com as irmãs todas séas. >> [risadas] >> É assim, >> mas você não sabe escrever cois consegue