Agentic Engineering: Do Loop à Fábrica Autônoma

Prepare-se para uma conversa direta sobre a disciplina que está silenciosamente substituindo a engenharia de dados como a gente conhece, e que ainda não tem nome no mercado brasileiro.

Neste episódio, Lucas Tancredi e Luan Moreno discutem, sem rodeios, por que Engenharia Agêntica não é prompt engineering glorificado, o que mudou de verdade no workflow de quem já está construindo sistemas autônomos, e como o Data Engineer chegou ao centro dessa transformação.

O que você vai aprender neste episódio:

• Por que o medo não desaparece mesmo pra quem já constrói sistemas agênticos há dois anos, e o que isso diz sobre a velocidade do que está acontecendo.
• O que o Karpathy quis dizer com Software 3.0 e por que isso muda a forma como você pensa sobre o seu trabalho com dados hoje.
• As 5 camadas da Engenharia Agêntica (Prompt, Context, Harness, Loop e Eval Engineering) e por que a maioria das empresas ainda investe tudo na camada menos importante.
• O que é uma Dark Factory e como um sistema de 42 agentes fez em 6 meses o que um time de 7 pessoas levou 3 anos pra tentar, e ainda encontrou um bug de 137 mil dólares que ninguém havia visto.
• Por que você não vai ser substituído pela IA, mas pode ser substituído por alguém que a usa melhor do que você, e o que isso significa pra quem está no mercado agora.

Este não é um episódio sobre ferramentas. É uma conversa sobre por que esse momento não vai esperar você estar pronto.

Lucas Tancredi - Linkedin

 Luan Moreno - Linkedin

https://engenhariadadosacademy.com.br/

Engenharia de Dados Academy - Instagram

Transcript

SPEAKER_01 0:00

Bom, hoje a gente está aqui para mais um episódio do Engenharia de Dados Cast. Estou aqui com o Luan. E a gente quer fazer uma convergência de episódios anteriores, de coisas que aconteceram no meio desse caminho, né? De que poucos meses tudo mudou muito rápido. Então, eu até queria começar aqui com uma frase que eu não sou programador, mas eu nunca me assisti tão pra trás, até como pessoa, como pessoa, andava em Spark, by Spark, e SQL que seja. Não é porque ficou mais difficile. It's sort of because the chão parece que mudou, né? And tiraram ali o meu chão, basicamente. E aí eu fiquei pensando, né? Ontem, quando a gente started on a meetup, se isso é exaltante, isso é muito foda, se um chega perturbador. And I imagine até que seja um pouco entre os dois. E eu queria saber isso fora, Luan. Se teve algum momento specifico, algum projeto, algum treinamento que você deu, onde você percebeu que realmente seu workflow tinha mudado de uma forma irreversível. Not sort of mudou, but nothing pro modelo antigo. Foi essa session of exaltação, excitação, orgulhosa, flascou?

SPEAKER_00 1:24

Você usou two, a convergência, acho que é um ponto que eu quero tocar bastante aqui. Você falou sobre esse moment, né? Cara, I'm doing it. I think it was a very legal that's funday, because our base like a desenvolved, or engineer of dados, or enjoyed software, enfim, the area of technology that drives solutions. So this was 20-30 years at the time. It was the workflow during 30 years. A gente sort of tentando ter velocidade. Só que agora é totalmente diferente. Eu acho que eu ainda sinto medo. E por mais que eu esteja trabalhando com isso todos os dias, que eu já faço sistemas agênticos, que eu trabalho com o cloud desde o primeiro dia de incepção e literalmente drive todas essas soluções, a gente já fez vários workshops, bootcamps, treinamentos, formação sobre isso, eu ainda tenho medo. E custa muito pensar o que a gente vai trazer de conteúdo para o pessoal, porque eu quero ter certeza que esse conteúdo que eu vou entregar está completamente alinhado com o futuro próximo. So, por exemplo, antes da gente entrar aqui, eu não sei se você ficou sabendo, mas o Chat GPT 5.6 acabou de ser bloqueado pelo Donald Trump, porque é um modelo no mesmo nível do Fable, for example. Então a gente começa a viver uma era em que antigamente a gente tinha evoluções de modelos por meses, agora a gente tem por semanas, e agora a gente tem banimento de novos modelos. Então, é um mercado completamente incerto, mas tem uma coisa que é certa em cima disso. Se você não mudar seu workload, se você não mudar a forma como você trabalha, você não vai ser substituído por uma IA, mas com certeza você vai substituído por uma pessoa que utiliza a IA melhor do que você. E não somente isso, eu vou estender mais, que cria soluções agênticas em vez de soluções em nível software 2.0.

SPEAKER_01 3:33

Sim. Porque agora a pegada não é mais tecnológica, né? Tipo, a gente sai de Hadoop, vai pro Spark, pô, legal, isso deu mudança, documentação e tal, você aprende de novo, né? Agora você tem que mudar a sua cabeça, né? Tipo, é literalmente o mindset ali e tudo mais, buzzword muito boa, né? Mas assim, você tem que mudar o seu jeito de pensar e de aplicar as coisas, né? E mudar o modo de trabalho, e isso é o mais complicado no final das contas. No tanto que a frase que eu trouxe no início foi uma reflexão que eu peguei de um de um vídeo que eu estava assistindo do André Carpache, que ele fala isso, que ele também tá se sentindo mal. E assim, se o cara que criou o Tesla, que criou o modelo de divisão computacional da Tesla, o cara que ajudou a fundar o PNA ali, né? E agora tá no Cloud. E agora tá no Cloud, tá lá na Antropic. Se ele se sente mal, quem sou eu no meio de Brasília, né? Pra ficar de boa com isso, né? E aí, já falando sobre ele, né? Tem um podcast que ele fez na, uma troca de ideia, na realidade, na Sequoia, lá em, acho que se não me engano, foi em dezembro ou dois meses atrás, que ele fala que algumas coisas que pareciam simples, né? Mudaram, mas algumas coisas que pareciam simples mudaram tudo, que seria a parte de software 1.0, 2.0 e o 3.0. Onde no 1.0 a gente tinha ali regras explícitas, né? Então a gente fala de ser mais, que são coisas objetivas, são coisas que a gente coda explicitamente, cada passo que a gente faz. No 2.0 são passos e pesos aprendidos, então vem um comportamento mais emergente de treinamento de software. Aí a gente começa a ver a visão computacional, esse tipo de coisa, a LLM bem no comecinho, e o Software 3.0, que é literalmente a parte que ele fala, que é o context window ali, a parte de contexto realmente para o programa. Ele fala que você não escreve nem a lógica, você não treina pesos, mas você cuida do ambiente onde a LLM vai raciocinar, né? E você cuida do interpretador, no final das contas, né? Para a LLM fazer o trabalho dele. E a pergunta pra você, né? Se as pessoas que a gente conhece, ou quem tá escutando, as pessoas do The Plumbers, né, acordassem amanhã, realmente acreditando nessa mudança, né? Nesse ponto que o Carpache traz. O que você acha que muda no dia a dia de uma pessoa dessa, na prática?

SPEAKER_00 5:54

Eu acho que a pergunta é complexa. Deixa eu ver se eu consigo quebrar ela em partes. Eu acho que a primeira coisa do que você falou da BuzzWord, que é: não adianta você atacar LLMs ou software 3.0 somente pensando que é algo novo. Você precisa literalmente repensar em como você trabalha. Porque antigamente a preocupação era nós criarmos o código ou criar a forma para interpretar alguma coisa. Agora a ideia é a gente criar um sistema que faça isso. Então, o meu objetivo agora, como um engenheiro agêntico, ou como um AI Native Engineer, não é codar e não é literalmente escrever ou mesmo instruir. É ainda uma abstração acima. É pedir para que o sistema faça isso para você. Então, é exatamente isso que ele falou do ambiente. Você precisa prover um ambiente para que o LLM, que está dentro de um harness que a gente vai falar, você possa prover para ele o que ele precisa para fazer o trabalho dele. Vou dar um exemplo. Então vamos supor aqui no nosso mundo de engenharia de dados, pensando em construção de um pipeline. Vamos supor que a gente precisa construir um pipeline no Databricks, ou no Snowflake, ou no Fabric, e assim por diante. Daí, em vez de literalmente quebrar essas camadas e eu desenhar e codar, vamos tirar um passo para trás. A LLM pode escrever o código para você. Isso é uma fase. Uma outra fase é, ela pode executar múltiplos passos para você. Ela pode não só escrever esse código, mas ela pode escrever um teste local, por exemplo, para validar a escrita do código. Agora, a gente tem um outro nível. Eu posso dar uma ferramenta para o meu sistema agente pra falar, opa, calma aí. Você quer que eu traduza o código? Você quer que eu crie o código? Você quer que eu deploie esse código? Sim. Ah, eu tenho aqui na minha disponibilização uma CLI. Olha que legal, essa CLI faz acesso ao sistema. Posso usar essa CLI pra poder fazer o deployment? Sim, você pode. Tá vendo que a gente tá dando agora todo o processo para que o sistema agêntico faça cada vez mais de forma autônoma. Então é literalmente o que ele falou. É brilhante, você tá dando tudo pra ele, né? E aí, com isso, você vai dar ferramenta, contexto, regras, guardrails, você vai dar principalmente o rádio, né? Que ele vai conseguir andar, e você vai deixar a LLM fazer o trabalho como um todo. Então muda não só a forma de como você faz, mas muda a forma como você pensa pra fazer. Então a ideia é você ter um sistema que faça isso.

SPEAKER_01 8:25

Bom, de agora, dito tudo isso que você trouxe pra gente, né? De ferramentar, de trabalhar com a LLM, tem uma pergunta que eu queria deixar pro final, só que eu acho que convém agora trazer aqui. Agora a gente tem a gente pra tudo, ele tem liberação pra fazer coisas no nosso nome, no nosso e-mail, GitHub, tudo no nosso dia a dia, né? Muito massa. Isso é muito foda, por sinal. Agora, o que você acha que vai acontecer quando isso chegar para o público geral? Tipo, quando, sei lá, o Joãozinho da padaria conseguir fazer isso? O que você acha que muda para o mundo e para as pessoas não normais, mas as pessoas que têm um uso de cotidiano, né? Porque, por exemplo, minha irmã usou o ChatGPT pra tudo, tem 12 anos. Eu já tenho um uso diferente. Então, o que será que acontece com o mundo nesse. Pensando mais pra frente, cara?

SPEAKER_00 9:15

Eu gosto de pensar muito em coisas que já aconteceram na humanidade que impactaram e mudaram a trajetória da humanidade como um todo. Acho que uma das coisas que mudaram completamente a trajetória foi o celular, foi o smartphone, na verdade. Ele mudou completamente a forma como as pessoas se comunicam, como elas se comportam. Isso resolveu muitos problemas, mas trouxe outros problemas. A grande questão de uma coisa completamente nova e disruptiva é que você literalmente não sabe quais são os efeitos negativos até em que isso aconteça. Mas, na minha humilde opinião, quando a massa geral tiver acesso a isso, acho que a gente vai estar num nível, a gente vai pular pra um outro nível de humanidade como um todo. E isso traz muitos benefícios, mas isso traz muitos malefícios. E eu consigo olhar isso dando mainstream muito mais como um malefício do que um benefício. Por quê? Porque a capacidade que você vai ter, você já tinha uma capacidade gigantesca na sua mão aqui, que é o celular. Com sistemas que podem fazer milhões de coisas na palma da mão de todo mundo, isso se torna extremamente perigoso. E aí, se a gente olhar, isso tá tão verdade, esse é um tópico tão legal. Se você olhar, por exemplo, Anthropic, Anthropic hoje é obcecada por segurança. Ela é obcecada por não ter soltado mitos pra todo mundo. Por quê? Porque ela sabe que o nível de inteligência que um sistema desse tem hoje, ele pode ser completamente radioativo. Então, assim, eu acho que a gente vai depender muito da Anthropic, a gente vai depender muito da OpenAI, a gente vai depender muito dessas empresas grandes pra setar e pavimentar o local. But a gente vai passar por muitas mudanças, não só tecnológicas, mundiais mesmo. Isso vai impactar a forma como os negócios são criados, como as pessoas interagem, isso vai mudar como seres humanos se comunicam com máquina. Eventualmente, por exemplo, tem um artigo muito interessante de Dan Tropic, não sei se você já teve, já olhou para ele, mas eles estão trabalhando muito forte na parte de conseguir extrair sentimentos de palavras e conseguir dar pesos diferentes aos sentimentos dentro do contexto. E isso muda o comportamento da IA para que ela possa entender coisas positivas e negativas, não só palavras, sentimento, mas além disso, o que a expressão como um todo faz. Então acho que a gente já começa a ver também uma outra saída de mecanismos robóticos, de computação quântica, de visão. E se a gente juntar todos esses pedacinhos, a gente está falando literalmente de uma nova era. Daqui 10 anos a gente vai estar num completamente diferente patamar, e eu acredito que se a gente não tiver segurança como primeiro princípio, isso vai ser extremamente perigoso pra gente. Mas eu acredito muito na Ontropic, na OpenAI para liderar esse tipo de coisa, porque hoje, de fato, são as grandes e maiores empresas que lidam. Agora a gente pode falar também da SpaceX, que acabou de adquirir, o curso, 60 bilhões de dólares, eu acho. Então a gente vai ver uma corrida muito legal.

SPEAKER_01 12:05

Muito massa. Tem um, se não me engano, é a Gartner, agora eu não me lembro de onde que eu vi isso. Foi alguma coisa nesses devaneos que a gente tem lendo na internet, de que o próximo grande. A IA já está chegando num pico, né? Onde está tudo meio que, entre aspas, normalizando, né? E ela começa a decair não em desuso, mas em booms, né? E a gente começa a ver entrada de robotica. E aí, com a IA tão avançada, agentes tão avançados, e robótica junto, então acho que a gente vai ver realmente grandes mudanças, né? Assim como a gente já tem, né? A gente tem um termo aí Dark Factory pra gente, mas já existe, né? Já existe. Fábricas que operam no escuro, basicamente. É maluquice pensar nisso.

SPEAKER_00 12:46

E eu acho que é legal. Você quer trazer um pouquinho sobre isso, like, tipo, um minutinho, o que é a Dark Factory, para o pessoal que talvez está escutando isso. No nosso contexto ou no contexto externo? Não, no contexto externo, porque a gente vai trazer Dark Factory, né?

SPEAKER_01 12:57

Sim, o Dark Factory, pra quem não conhece, é uma fábrica que literalmente funciona no escuro e só com robôs, porque robôs não precisam enxergar, eles têm sensores, então é uma fábrica enorme, então você tem um custo energético menor dessa fábrica. É uma pena que não tenha seres humanos trabalhando, porque a gente pede realmente emprego, mas é literalmente um lugar todo escuro, com máquinas construindo carros, com máquinas mexendo em stocks, com máquinas, literalmente só máquinas. Because eles não precisam enxergar, como a gente. And tem menos gasto com energia, com logística, temperatura também, então por aí vai.

SPEAKER_00 13:35

E guardem isso porque a gente vai falar sobre isso como se isso se conecta ao nosso ecossistema de engenharia agêntica, tá? Então, guarda isso aí.

SPEAKER_01 13:43

E aí eu quero já começar a entrar nisso também que para ter uma Dark Factory, no nosso mundo normal, nós temos alguns pontos tecnológicos, e para o Dark Factory, voltado para IA, I agentes, e todo o nosso contexto, nós temos cinco camadas. Então eles são literalmente, aí tem uma metáfora, né? Que eu até coloquei aqui no meu script, que são como bonecas russas, né? Cada uma. Ah, legal. Elas são, como é que eu posso colocar? Elas são meio que codependentes, porque você precisa ter todas para você fazer o Dark Factory, né? Então você tem ali inicialmente pequenininho o Prompt Engineering, o Context Engineering, o Harness Engineering, o Loop Engineering e o Evol Engineering. Então eles meio que se complementam, né? Então são dependentes ali. Elas se complementam. A boneca russa muito mais. Sim, justamente. E até trouxe um dado aqui, cadê? A maioria das empresas investe 80% do esforço na camada 1, que seria só no prompt engineering, a gente vê muito isso, eu vejo isso no meu dia a dia. As pessoas focam muito na parte de prompt, prompt, prompt. Você tem que ter um prompt gigante, muito bem feito. Produtos de A em produção de empresas grandes que foram criados na mão, só com o prompt engineering de um ser humano. E hoje, isso tá meio que fora da caixinha mundial, para quem realmente bota isso em produção. E aí, Luan, eu queria que você comentasse sobre o Lerum, que seria o Prompt, né? A bonequinha menor ali da nossa boneca russa. Ele funciona. É meio que a fundação, né? Ele foi o que veio primeiro, né? E eu queria que você falasse um pouquinho sobre.

SPEAKER_00 15:25

Fala. Posso, se me permite, antes, só dar um passo pra trás e falar um pouco da boneca geral, né? Claro. Tudo isso que o Tancred falou se aplica muito ao contexto de tentar encaixar as coisas. A gente, como pessoa de tecnologia, a gente tenta colocar as coisas nos lugares, né? Arquitetura, padrão, framework e assim por diante. Então, se você pensar no que o Tancred falou, faz total sentido hoje. Talvez há dois anos atrás era completamente longe, mas a gente começa da boneca menor, né? Então eu gostei muito disso. Você começa do contexto, desculpa, do prompt, depois você vai pro contexto, depois você vai pro harness, depois você vai pro loop, depois você vai pro evol. Mas quando você pensa em tudo isso, a primeira pergunta que eu me perguntei, literalmente depois de conversar com a galera lá fora, foi, cara, qual é a disciplina que abraça tudo isso? E isso me deixou muito inquieto durante um tempo, porque a gente vê isso como pedaços separados. Mas como o Tancred falou, e da boneca russa de você abrir e ter, realmente um precisa do outro. Não tem como, literalmente, se você quiser ter todas as peças, você simplesmente começa só em uma, ou só na menor, ou só na maior. E isso mostra que existe uma nova disciplina hoje, e foca aqui importante, que é uma disciplina que a gente. que muitas, poucas pessoas sabem, inclusive, e é o motivo que a gente está aqui falando sobre tudo isso. É pra mostrar pra vocês que o mercado tá sendo engolido positivamente e as profissões estão sendo engolidas. E aí a gente quer trazer alguns dados importantes aqui, não sou eu falando, né? Nós temos até o momento mais de 93 mil demissões em tecnologia nos primeiros seis meses, mundialmente falando. De pessoas especificamente em tecnologia que saíram de áreas. Por quê? O que está acontecendo, pessoal, pra gente pegar só o gancho aqui? Nós estamos começando a colidir áreas, coisas que não aconteciam antes. Então, por exemplo, você pega uma pessoa engenheira de dados com analista de dados com analytics engineer, eles convergem. Você pega um cientista de dados com ML Engineer, eles convergem. Você pega um cara que é DevOps, você pega que é um cara de infra, que é um SRI, por exemplo, eles convergem. Só que, se a gente olhasse tudo isso, isso meio que saiu da costela da engenharia de software. A engenharia de software sempre foi a grande massa disso. Agora, e se eu falasse pra você que hoje a engenharia de software é embrulhada? Olha só que medo, né? E quem é essa disciplina que faz isso? Seja bem-vindo ao mundo moderno chamado engenharia agêntica. Então, a engenharia agêntica tem engenharia de software, ela tem dados completos, ela tem IA completa, ela tem infraestrutura completa. Então, talvez você esteja se perguntando, isso quer dizer que eu vou deixar de existir? Bem, não deixar de existir, mas a sua função como pessoa vai mudar completamente. E eu não digo isso de achismo. O Dancret que vive um pouquinho comigo sabe que eu vivo isso hoje já há mais de dois anos. Eu vivo isso. Então hoje eu não sou um engenheiro de dados, hoje eu sou um engenheiro agêntico. Construo soluções que os meus agentes constroem IA, constrói ML, constrói infraestrutura, constrói deployment, constrói reg, constrói sistemas agênticos, constrói todo o processo, camadas oncutológicas e assim por diante. Então, só para vocês entenderem que essa é a parte mais importante e é o centro que a gente vai estar aqui. Voltando para a sua pergunta sobre o prompt, o que a gente começou a discutir, o que a gente começou a entender fora do país? Bem, como a gente tem sistemas agênticos hoje, né? E só para a gente entender aqui, colocar todo na mesma página, o que é um sistema, o que é um multiagente, o que é um sistema agêntico, né? Um agente faz uma coisa específica, um multiagente, cada um faz uma coisa específica, eles têm alguma forma de controlar estado, inteligência, contexto e todo o ambiente, e a gente tem agêntico. Agêntico quer dizer que eles tomam decisões. Então, é literalmente como o Carpache falou: você dá o ambiente e eles estão livres para tomar decisões baseado que a gente chama de blast radius, né? Que é qual é o tamanho do impacto que ele pode. E quem vai fazer isso é o humano no loop, que é você. Então, o prompt, o que a gente já descobriu, por ser a boneca pequenininha, é que hoje, antigamente, a preocupação é que engraçado, né? Há três anos atrás, eu não sei se você lembra disso, mas a engenharia de prompt era uma profissão. Há um ano atrás, mais ou menos, a engenharia de prompt virou uma skill, e hoje a gente não faz mais prompt. Então, se você está promptando agente, a gente vai mostrar pra você que você não precisa mais fazer isso. Na verdade, você deve criar um loop que faz o prompt pra você, mas você não faz mais o prompt. Você tá até errado, né?

SPEAKER_01 19:58

Porque você não é tão inteligente assim. Vai ficar ruim.

SPEAKER_00 20:02

É importante. É isso. Exatamente. Então, assim, você não quer promptar, você quer passar pra um sistema que prompia os agentes pra você, porque eles vão ser extremamente melhores do que você, indiscutivelmente. Então, essa camada a gente já meio que tira da equação, ela vira um commodity, e aí, por virar um commodity, ela é automatizada. Então, assim, é um skill importante pra ter? Obviamente, é uma coisa muito legal pra ter. É importante você entender as bases e as abstrações e como que o processo funciona na camada fundamental, mas eu não gastaria ciclo em literalmente entrar em todos os detalhes do que é um CORT, um chain of thought, como funciona. Essas bases são legais. Mas daí você literalmente investir muito, muito, muito tempo nisso, eu acredito que seja legal ter a base.

SPEAKER_01 20:48

Então a gente pode dizer que ela é uma bonequinha, que é a última mesmo, lá do core, né? Da boneca russa.

SPEAKER_00 20:52

Eu concordo, ela é a menorzinha.

SPEAKER_01 20:54

É a que você não precisa abrir pra você entender, né? Você só deixa ela ali fora e ela é a menorzinha ali, é a que é menos. Não que menos importa, né? O texto é feio, mas é a que você não precisa se preocupar tanto em abrir. E agora, indo para o layer 2, né? Para a camada 2 ali, que seria a parte de contexto, né? Que a gente vê que realmente foi quando deu aquilo a diferença, né? Que é assim, o contexto é o mote, né? A parte competitiva, realmente, né? É onde o modelo com contexto melhor, ele vai ser sempre. Vai superar, né? O modelo pelado ali, sem nada. Só que na realidade, no final, não é só o modelo que ganha, né? Quem cuida melhor do contexto. Então, se você der um contexto certo, do jeito que você dá o seu contexto, e aí eu queria que você comentasse um pouco disso também.

SPEAKER_00 21:43

Nossa, aqui a gente pode ir por horas. O contexto é chave, como você falou, é o mote, né? É o motivo principal, é uma das cápsulas que a gente vai ver ali do Hornets, que é o próximo, mas o contexto, ele é difícil falar o que é mais importante. Muito importante porque todos têm a sua importância, mas o contexto ele tem uma base tão forte porque acontece, muita gente fala de alucinação, né? Então, quando você fala de LLM nos níveis primários hoje, a gente tá falando de alucinação. Ah, alucina, não escreveu certo, não entendeu o que eu falei. Tudo isso tá relacionado ao contexto. Mas quando a gente fala de contexto, as pessoas pensam no prompt. Sim. Né? Eu vou injetar um prompt no contexto e ele vai entender o que eu tô falando. Não necessariamente, existem outras camadas muito mais complexas do que só injetar o prompt. Porque o que muita gente deve entender é que o context window, ah, eu tenho uma janela de contexto de 256 mil, 512, 1 milhão, 2 milhões, enfim. Ela é um contexto que passa. E aí você tem um grande problema que é o lost in the middle. Que é, quando você tem muito contexto, achar certas coisas no meio daquela conversa muito grande se torna muito difícil. Então, o que você quer fazer? Você não quer só ter contexto. E aí que vem a sacada. Você quer dar o contexto certo, e aí vem uma palavra muito difícil. No momento certo. E isso é uma arte. Você precisa de ontologia, você precisa de reg, você precisa de uma inteligência de gerenciamento de contexto, você precisa saber temporalidade. For example, como que eu sei de dois fatos, qual o fato invalidado e qual o fato recente numa base de reg? Já parou pra pensar? Porque quando eu faço um retrieval do dado, quando eu recupero o dado, eu recupero o quê? Chunks. Mas como que eu sei que aquele chunk e aquela informação, ela é a última mais válida de alguma coisa específica? Não pelo timestamp. Nem sempre o timestamp vai ser de fato o dado mais atual. Parece logicamente, mas não. Então, existem técnicas para você recuperar. E ele passa a ser uma parte muito importante do contexto como um todo. Então, assim, se você começa a desenhar, e aqui o que a gente está tentando guiar vocês é cada pedacinho para que vocês entendam o sistema como um todo. Então, cada sistema desse, cada pedaço desse deve ser construído com muito carinho. A questão do prompt não é que ele é irrelevante, não. Mas é porque a gente vai ver que nas camadas de cima, você vai ter um mecanismo em que existe esse mecanismo fazendo o prompt para você. No contexto, não. Você precisa dar ao sistema esse contexto. Então, nós, como, eu nem vou falar de AI engineer, de engenheiro de dados, eu vou falar como um AI Native Engineer. Como um engenheiro nativo de A, é o seu trabalho construir um contexto inicial para gerar o seu sistema. E talvez você fale, mas o que você faz com isso? Cara, tudo que você, como ser humano, faz. Você recebeu um pipeline de dados que você vai converter arquivos, você vai dar o contexto pra gente fazer isso. Se eu quero criar um front-end, você vai dar o contexto pra gente construir o front-end com as características e com o design que você quer. Pô, eu quero construir um back-end. Você vai gerir o contexto do back-end baseado nas regras de negócio para que os seus sub-agentes construam isso. Ah, eu quero construir um sistema de reg, de armazenamento de dados. Você vai nutrir o seu sistema para que os agentes construam o seu sistema. Então não só você vai fazer com que o sistema construa o sistema, mas esse sistema vai entregar solução no final. Então é meio que você tá. O que a gente chama de dog fooding, você está se alimentando do próprio processo. Você está criando sistemas agênticos para criar os sistemas agênticos. Você está criando sistemas para construírem os sistemas. Por isso que a gente fala, o sistema constrói o sistema.

SPEAKER_01 25:34

Então são passos como é que eu posso colocar? É meio que uma escadinha, então, né?

SPEAKER_00 25:38

Cara, eu acho que você matou assim, muito legal, nunca tinha pensado nisso, foi genial. A boneca russa.

SPEAKER_01 25:43

Eu acho que eu vou usar isso aqui pra frente, porque faz muito sentido. Faz muito sentido. Boa. E aí, Luan, beleza, a gente fala de contexto, né? Então a gente tem um context rot ali, que é o que degrada o teu modelo, e a gente passa ali pela parte de progressive disclosure, né? Que é dar só o necessário e tudo mais. Só que aí a gente precisa chegar na parte de controlar. Como é que a gente controla isso tudo, né? E aí a gente chega na parte bonita de harness, né? Acho que isso é a palavra bonita. Eu acho linda. O harness, né? Que é literalmente a parte de controle, né? Então, quando eu penso em harness e pesquisa no Google, vem uma imagem de controle, né? Vem a tradução literal de controle. E eu imagino um cavalo com aquelas viseiras, né? Pra andar reto. E é literalmente o que a gente tenta fazer com o modelo, né? Então a gente traz o contexto certo e tenta trazer ferramentas e modos para que ele caminhe na linha, certo? E aí, como é que você usa no seu dia a dia, cara?

SPEAKER_00 26:41

Muito legal. Ontem a gente falou sobre isso, né? O MOT não é o modelo, mas sim o Hornets, né? E você trouxe um ponto muito legal que é. O que é o Hornets, enfim, né? Vou achar até que sim, desculpe te interpretar.

SPEAKER_01 26:56

Não, pode falar. Mas é porque o Hornets, até peguei aqui uma referência que eu li, saí juntando um monte de referência para o podcast de hoje, né? E ele fala que o Hornets é o bubble rap, né? Que é o que você. Como é que você pode colocar? Embrulho. Você lembra a palavra em português, né? Que é o que impede o agente de apagar um trabalho de produção, quando na real dia está mexendo e editando um CSV. Perfeito. E isso aí acontece bastante. Desculpa ter te cortado, mas eu queria trazer esse pensamento pra.

SPEAKER_00 27:26

Bem, o que a gente começou, né? Trabalhando lá na literalmente no Bleeding Edge, eu nem falo de cutting edge, né? E aí, uma nota pessoal, eu sempre existe, cara, qual a palavra mais linda em inglês que você acha? Pra mim sempre foi craving. Eu adoro essa palavra, acho linda essa palavra. Craving é desejar, é querer demais, quando você está desejando algo. Mas vou falar que Horness tá bem perto. Eu adoro essa palavra harness. É bonita de falar e o processo como um todo é muito legal. E tudo isso, gente, é pra vocês entenderem a evolução de sistemas agênticos nos últimos três anos. É louco falar disso. Acho que até menos, né? É, até menos. Então, assim, palavras, essas palavras que você está escutando no podcast é literalmente a gente trazendo tudo de mais recente pra que você entenda e coloque isso numa caixa que fique muito visual pra você, tá? Então, o Hornets é exatamente o que o Tancred falou, é o controle. E o que significa esse controle? Significa uma coisa muito mais linda hoje. Significa o seguinte: antigamente, antigamente, um ano, dois anos atrás, os modelos frontiers, os frontier models, como OpenAI, Cloud, que são literalmente os dois grandes, né? A diferença competitiva para os outros modelos, inclusive open source, eles eram gigantescos. Então, assim, você precisava, para outros modelos menores, instruir demais, promptar demais, falar demais para o modelo. Ah, eu quero isso dessa forma, assim, assim, assado, fazendo isso e isso. Então, por isso que o prompt engineering era algo extremamente vital para o processo. O que começou a acontecer é que os modelos começaram a ter o COT, o Chain of Thought. Eles começaram a pensar, né? E aí tem aquela brincadeira de quantos Rs tem Strawberry, por exemplo, né? Então eles começaram a pensar, e não só os modelos mais novos, mas os modelos open source, como GLM, Kimi, Deep C começaram a entrar nessa batalha. E hoje a gente está num momento muito legal. E eu digo isso por experiência própria, eu inclusive mostrei isso no Meetup, é que hoje, para muitas tarefas, independe qual o modelo. O que depende é o hardness. É exatamente o que você coloque de capacidade para um modelo. Porque se você pensar no modelo, o que o modelo é? O modelo é imputa token, sai token. É um preditor, ele vai prever a próxima palavra, se você parar sobre isso. Então, como que você faz com que o LLM, que é muito inteligente, né, mas ele não tenha a sabedoria. Então, como que você dá sabedoria para o modelo? Inteligente ele é, ele não é sábio. Como que você traz a sabedoria? Aplicando o Hornets em cima dele. Então você traz o contexto pra ele, você traz as seguranças pra ele, você traz as ferramentas pra ele, você traz a observabilidade do ambiente, você traz estado pra ele. Então você começa a munir ele, e aí a gente viu uma coisa muito legal. O Hornets é como se fosse uma armadura do Batman, por exemplo. Bem legal, mas é bem legal. Então você vai adicionando isso pra que ele fique extremamente robusto e ele possa fazer isso. Só que a armadura do Batman é tão boa que agora você pode colocar qualquer um lá dentro, por exemplo, e ele vai ser muito bom também. Obviamente que os modelos vão se diferenciar, famílias de modelos vão se diferenciar, mas a ideia é que o Hornets consiga alcançar algo extremamente interessante. Por isso que você vai ver muito na internet, muito no YouTube, muito sobre Hornets. Porque, na verdade, hoje você consegue ter modelos mais econômicos, você pode ter modelos e você pode escolher camadas e eu diria vestimentas para os seus LLMs então o Hornets vai fazer tudo isso pra você.

SPEAKER_01 30:51

Então ele é literalmente a. A gente só tá dando um caminho, né? Então a gente tem o prompt, tem o contexto, né? Que vai deixar ele mais inteligente, vai fazer ele entender o que ele realmente precisa fazer, e a gente vem junto com o Hornets pra guiar. E faz o bubble wrap. Bubble em tudo, né? Exatamente. E aí, pensando agora nesses três passos aí nesse encaixezinho bonitinho, aí a gente vem com mais um engineering, né? A gente tá cheio de engineering aqui hoje, porque no final ele se converge pra algo muito maior. E eu queria só que a gente falasse por cima de loop, porque a gente tem o loop engineering, né? Agora, tudo vem com o engineering agora no nome, eu tô ficando doido já com isso. Mas a gente tem o loop engineering, né? Que assim, o Harness é uma estrutura estática, o loop é meio que como se fosse o motor para fazer isso funcionar, né? E o loop mínimo viável é, enquanto não tá pronto, você meio que roda para o agente de novo até o estado mais recente, dá pra fazer funcionar, certo? E aí, alguma colocação sua?

SPEAKER_00 31:57

Sim, rapidinho, quando a gente olha para a loop, existe uma distinção muito importante para você entender que em alguns artigos você vai ler que o loop está dentro do Hornets, e em outros artigos você vai ler em que o loop está fora do Hornets. Se um foi um ou outro, os dois estão errados, porque na verdade o loop está nas duas camadas. Você tem um loop dentro do Hornets, que é a arquitetura da LLM como um todo. Quando um sistema agêntico é construído, o Hornets já é o sistema agêntico. E quando a gente falou tico, agêntico, quer dizer que ele já tem o quê? Ele já tem uma autonomia própria. Ele já é próprio, ele já tem autonomia de fazer as coisas. Ele tem ferramenta, contexto, inteligência, enfim. Então lá dentro ele tem um loop. E o loop dele é o React. Ele faz o reasoning e o act. Entende o ambiente e executa. Só que qual a diferença aqui? A diferença é que quando você vai a uma camada acima do bubble wrapping e do Hornets, e você fala do loop engineering, é exatamente a camada onde o prompt deixa de ser necessário. Porque o que você vai fazer? Você vai setar um objetivo. Olha só que legal. Você vai falar o seguinte: olha, eu quero construir, né? Esse é o contexto, tal, tal, tal. O que eu quero? Qual o gol? Qual o objetivo? Eu quero fazer a tradução desse script para esse script. Eu quero que você garanta com que eles tenham precisões perfeitas. Aqui está o output final para você testar o dado, enfim. E você não vai sair desse objetivo até que você valide que 100 é igual a 100 neste contexto aqui. E aí, o que ele vai fazer? Ele vai fazer um outro bubble wrapping no critério do objetivo. Então ele vai falar, opa, calma aí, eu preciso completar um objetivo. Legal. Então ele vai embrulhar o sistema inteiro, ele vai embrulhar o harness, que já está embrulhado, e ele vai falar: olha só, a gente não vai sair disso aqui até a conclusão desse objetivo. Isso se torna muito interessante, porque não só você está dando qual o objetivo, mas você tem que trazer outras características pra ele. Você tem que trazer o objetivo, você tem que trazer o estado, então ele tem que ter um state para saber, poxa, fiz isso, tô aqui, chamei isso e tal. E aí o próprio Loop Engineering vai fazer o quê? Vai fazer a ideia de um manager. Ele vai literalmente entender, pô, beleza, eu tenho esse objetivo. Para esse objetivo, eu preciso chamar a frota de agentes. Pô, então eu vou chamar um Python developer, eu vou chamar um documentor, eu vou chamar um Simplifier e eu vou chamar um tester. Beleza, então ele vai lá e ele prompteia a galera. Fala, olha, a gente precisa fazer isso aqui. E eles começam a trabalhar juntos de forma orquestada pra entregar. Então, isso começa a ser o que a gente vê como looping de new.

SPEAKER_01 34:29

Legal. Eu tenho um negócio meio. Como é que eu posso colocar que palavra usar? Meio. homem das cavernas, assim? Vou colocar.

SPEAKER_00 34:38

Caveman.

SPEAKER_01 34:39

Bem caveman, que é. Eu chego pro Claudio, peço por ele alguma coisa, falo, cara, só me retorna quando isso aqui tiver uma nota 9. Joga um subagente aí, manda ele te julgar. E ele faz isso. Ele posso chamar isso de looping? Sim, legal. Principalmente se você usar o barra gol.

SPEAKER_00 34:55

Faça isso. Eu não sabia que existia. É, ele tem um barra gol que aí ele te força a fazer isso. Muito bom. Aí ele cria o objetivo lá no cloud e fala: olha, você não vai sair desse looping. Provavelmente quando você promptou isso, ele vai chamar o gol internamente. Ele vai falar, pô, beleza, ele pediu pra eu não fazer até tanto, então ele vai criar o looping pra você. Massa.

SPEAKER_01 35:12

Que eu só boto lá no meu Whisper, eu falo com ele lá e vou fazer qualquer outra coisa. Cara, só me levar você aí quando tiver. Uma nota nove, por favor. E aí depois ele tá lá, depois de 20 minutos, quebrando cabeça com uma coisa muito idiota que eu pedi pra ele fazer, ele me retorna, é, cara, agora tá bom, 9 aqui, os outros um ponto aí é contigo, se vira lá pra você gravar seu podcast, basicamente. Então, cara, beleza. Looping é uma tarefa, entre aspas, repetitiva com objetivo. Isso. Certo? Vou. Bem sucinto, assim.

SPEAKER_00 35:44

Com vender de tarefas com um estado que tem um objetivo final, exatamente.

SPEAKER_01 35:49

Só pra deixar bem comprimido, assim, no final. E aí eu queria entrar numa parte, como é que a gente valida isso tudo, né? Porque parte de avaliação, hoje não é mais no Agente que Engineering, até onde eu li, né? A gente não precisa mais de QA aí, já não precisava, tem tempo, né? Sim. Porque os caras gostam de ferrar a vida de quem desenvolve.

SPEAKER_00 36:09

Não fique com raiva, mas é verdade.

SPEAKER_01 36:11

Outra parte que eu vi que o Kapati, acho que ele até disse, eu não lembro exatamente, que é que a diferença do software 2.0 e o 3.0 não é só onde, nem o que você escreve, né? Como você vai validar isso daí. Literalmente essa parte do Evol. E aí, tem um outro ponto também que eu trouxe aqui, que é que 60-80% do tempo de desenvolvimento tem que ser consumido fazendo esse tipo de validação, né? Que é onde a gente, no final, vai dizer se tá certo ou não o nosso trabalho. E tem até uma frasezinha, trouxe aqui, escrevi, que é o trust is a pass rate, not a feeling, right? So, so, ó. Você não revisa mais o código, você no final vai. Agora você vai revisar só o resultado do eval, né? E aí eu queria entender, e aí, assim, qual é a diferença de um looping para um eval? Porque me parece que o eval acontece dentro do looping, ou não.

SPEAKER_00 37:05

Ele pode acontecer dentro do looping, mas é melhor que ele aconteça fora do looping. E a questão disso é porque é o seguinte: setar um objetivo para LLM é literalmente confiar. E a gente tem que fazer o confiança, mas verificando, que é o trust but verify. Então a ideia do Evolve é o seguinte: quando a gente pensa em TDD, a gente pensa em escrever o teste primeiro e escrever depois a função que vai ter o resultado disso. O problema é que TDD não funciona com sistemas agênticos. E aí muita gente vai olhar pra mim e falar, meu Deus do céu, esse cara é doido, né? Ele pode mentir pra você, né? É, na verdade, vai fazer isso. O que ele vai fazer? Pode chegar uma hora que você quer que o sistema inteiro escreva o TDD, o que é muito bom, tá? Ele vai escrever. Só que quando o seu Code base é muito grande, dependendo do que você pede, o que a LLM pode fazer pra você, pra ela passar um código, ela pode alterar o seu teste. E eu já vi isso acontecer várias vezes, tá? Então, como que você faz com que um sistema, né? Porque a gente tá humano pra humano TDD, por quê? É determinístico. 2 mais 2 é 4, então escreve o código e vai chegar a 4. Quando você tem um LLM, é não determinístico. Então, como que você faz com que a LLM seja obrigada a fazer algo e validar o output dela? E vouls. O evolve é a forma do nosso TDD para a máquina. Então, é basicamente eu falar pra ela o seguinte, olha só, amigão, você falou que fez o deployment, que você fez o deployment lá no Databricks, né? Eu não confio em você. Eu não confio em você. Faz o seguinte: aqui pra você fechar esse bubble wrapping aqui no final de tudo, executa lá o Databricks LI e verifica se aquele objeto lá tá criado. E isso é um envolve. Ele vai ter que fazer algo, ele vai ter que acessar uma tooling, fazer uma chamada pra ver se o resultado do que ele disse que é, tá certo. Só que aí o Tancret falou, poxa, mas isso pode acontecer dentro ou fora? Pode acontecer dentro, mas eu gosto de fazer fora. Por quê? Você tem um outro contexto, você tem uma outra LLM, e talvez você tenha até um adversarial julgando aquele voo. Bem, deixa eu executar esse voo aqui, ou outro LLM que fez, porque, enfim, você fez, eu não vou acreditar que você fez. Eu não vou botar você que fez pra você executar a validação, porque você pode mentir pra minha validação. Mas se eu tiver um sistema em cima disso que encapsula esse processo, esse ring, então daí eu consigo garantir que essa execução vai ser muito mais bem feita do que literalmente quem escreveu. É o QA.

SPEAKER_01 39:38

Você vai validar. Só que é um sistema mais voltado pra gente. Com certeza. Só que o Way normal é. É, não, brincando, é só falar um cara.

SPEAKER_00 39:44

Alguém vai validar o trabalho do que vocês.

SPEAKER_01 39:46

É literalmente o QA de agentes. Exatamente. E aí, gente, agora pensando, passando por todos esses cinco pontos, né? Então, vamos retornar lá. Prompt engineering, começo de tudo. Context engineering, contexto, no final das contas é RAI, é o multi, né? Você tem que fazer o contexto bem feito. O harness é onde você vai guiar a LLM com contexto para fazer o seu trabalho. O looping é algo com um objetivo final, né? Você vai botar o objetivo, ele vai rodar até trazer o seu resultado final. E o eval é o que o Enay é quem vai validar e quem vai trazer ali a tua resposta final, né? O looping funcionou, o cara rodou o looping inteiro, vem o Eval, valida, rodou, ok, seguimos. Correto?

SPEAKER_00 40:30

Lindo pensar isso, e gente. Demorou muito pra gente chegar nessa conclusão. Parece simples, né? Sim. Mas muito estudo pra conseguir compilar tudo isso, porque tem tanta coisa na internet, cara, você fica louco, né? Como você vai encaixar as coisas e entender? Parece tão simples, né? É, se você não entender o fundamento, você não vai conseguir promptar certo, né? E daí você fecha a disciplina, engenharia agente.

SPEAKER_01 40:51

Então, é o tudo. Fazendo esse wrapping agora, né, de Agent King New, e eu queria agora voltar já no ponto que a gente falou no início do Dark Factory, né? E li em alguns lugares que é meio que uma, entre aspas, profissional. Voltado para 2030. I acho até estranho falar isso, porque olhar isso para 2030 será que não é mais rápido? Sim, eu acho que é muito mais rápido. Então agora a gente. Código abundante, gerar código ficou barato pra caramba. Eu pago ali 20 dólares por mês e eu gero coisas praticamente infinitas. O recurso escasso hoje não é só mais código, né? Eu nem sei mais o que seria essa parte escassa. Mint, say. Talvez atenção humana, né? Porque com IA isso IA ficou muito difícil ter isso. Ando faz como é que eu posso colocar? Dar essa virada, né? And so a habilidade que a gente tem mais valiosa não é só escrever código, é saber literalmente onde colocar atenção. E hoje a gente tem cara com IA, com colocar em rede social, esse atentip, né? Esse negócio ficou muito maluco e eu tava com um problema com isso também. Então, imagino que se eu tivesse que ler código de agente ou qualquer coisa que seja um pouquinho para trás, eu não ia conseguir fazer.

SPEAKER_00 42:17

Por favor, não é. Literalmente pela falta de atenção. Não leia o que o seu agente escreve. Cria um eval pra fazer isso. Não faz sentido você acordar. Algumas coisas, obviamente, né? Coisas novas, coisas que você ainda está trabalhando, você vai se tirando do loop. Mas se você tem um sistema já maduro que está fazendo isso há um bom tempo, a ideia é que você vá para um motivo de autônomos até um Dark Factory, para que você não precise ficar fazendo isso repetidas vezes. Fez mais que 4, 5, 6, 7 vezes e sai do loop.

SPEAKER_01 42:42

Aí Luan, assim, pra trazer um exemplo de Dark Factory, né? Aí eu escrevi aqui também pra não. pra lembrar, né? Uma fábrica onde o humano escreve e revisa código antes pra produção. E aí, onde nenhum humano, perdão, escreve código ou revisa, né? E aí, eu sei que a gente tem a Curvy, né? Curve Pay. Isso. A gente consegue falar um pouquinho? Posso, posso? Porque a gente falou no Meetup, né? Posso falar? Por cima, sim, que seria um processo de oito horas, a parte de 75 vezes mais rápido que você fez, né? Ali os dados que a gente tem. 42 agentes especializados e oito fases com o Gate. Se eu não me engano, aí eu posso estar enganado também, você me corrija, que o processo para você foi tão bizarro ali, o sistema de avaliação foi tão rigoroso, você encontrou bug legado, correto? Sim. E aí eu queria que você explicasse um pouquinho sobre o Dark Factory e como se aplica isso também no dia a dia. Se você puder falar um pouco sobre como o seu sistema achou esse bug legado, seria legal. Sim.

SPEAKER_00 43:44

Então vamos passar isso porque acho que esse é o momento da gente fechar essa conclusão inteira. Então, como que a gente traz isso para a prática? Pensa num projeto, esse projeto é um projeto financeiro, então a gente tem na precisão literalmente perfeita, do zero, do 1, enfim. E o objetivo era fazer uma migração de um ambiente. Mais clássico, com banco de dados relacional, integration services, SQL Server, colocando esses dados e processando arquivos financeiros. Então, eles tinham mais de 63 tipos de arquivos financeiros, sendo que 38 eram extremamente críticos. Então, qual era a grande ideia? Era ter uma empresa que pudesse fazer isso para refatorar para um ambiente moderno. Eles estão indo para a nuvem. Então, afinal das contas foi utilizar a AWS e Databricks pra isso. Estão explicando para vocês o caso e como que tudo aquilo que a gente falou de prompt, context, harness, loop e vol vai entrar tudo aqui no Dark Factory. E aí o grande desafio é, bem, quanto tempo a gente consegue traduzir esses 32 arquivos, né? A gente está falando de aproximadamente 1,7 milhões de linhas de store procedures no SQL 7. E daí, isso é impossível humanamente falando. Só para vocês terem ideia, um time com 7 pessoas lá dentro demoraram 3 anos para fazer isso. Então não tem como uma empresa de consultoria simplesmente fazer isso em um ano e meio. E a ideia, a proposta era fazer isso em um ano e meio, e acreditem ou não, nós fizemos isso em seis meses, tá? Todos os arquivos traduzidos com precisão 100% aprovada pelo cliente. Como isso aconteceu? Primeira coisa, quando a gente fala de um sistema autônomo rodando oito, nove horas, talvez você esteja escutando isso e falar, cara, eu não acredito. Obviamente eu também não acreditaria. Porque a gente tá olhando o quê? De fora pra dentro. Mas eu vou te explicar de dentro pra fora. Então vai fazer sentido. Então a primeira coisa é o seguinte, pô, eu tenho um spec, a especificação, que é o TSQL, e a documentação. Então, qual foi a primeira coisa? Qual foi o primeiro gate? Bem, eu preciso ter um agente, um sistema, que entende o que é TSQL e que entende o que é Python, porque eu quero traduzir. Então eu criei um agente que entende TSQL, um agente que entende Python, e eu crio uma base de conhecimento pra eles via MCP e via padronização agêntica. E eu falei, bem, traduz esse arquivo. Um arquivo o menor de todos, 300 linhas de store procedure. Beleza, traduz esse arquivo, essa entrada, testa, executa aqui, executou do outro lado. Legal. Como que eu valido isso? Traduziu ou traduzir? Commodity, não é como você falou. E aí a gente traz o ground truth. Qual é a verdade? A verdade é o output da SQL. Ei, me manda o output da tabela lá do SQL Server pra esse arquivo. Coloquei no LLM e falei, tá, olha só, esse é o resultado. Vê se funcionou. Beleza, funcionou. Porra, isso é groundbreaking. Caraca, eu não precisei abrir a store procedure pra traduzir no meu olho. Isso já foi uma explosão pra minha cabeça. E daí eu comecei a entender o seguinte bem, deixa eu fazer isso algumas vezes? Eu fiz dois, três, me senti confortável, falei, cara, a precisão tá muito boa, eu tenho um ground truth pra testar, então eu dei o resultado de entrada e saída, e aí a LLM vai ser muito boa nisso, eu dei a entrada, eu dei a saída, ela vai descobrir o pedaço no meio com toda a base de contexto. Beleza, segundo parte. Eu falei, bem, eu preciso agora não só fazer isso, eu preciso traduzir, eu preciso mandar para a AWS, eu preciso interagir com a AWS, eu preciso fazer o deployment no AWS, eu preciso cuspir o dado em parquê, eu preciso criar o processo no Databricks, o Lake Flow, para buscar esse dado, eu preciso validar esse dado como um todo, depois eu preciso criar o processo, persistir a tabela no Databricks e ter o resultado batendo. Então, para cada processo desse, a gente foi criando gates e se tirando do loop a cada vez que esse processo precisava rodar. Ao ponto de que chegou a um certo tempo em que todos os componentes que a gente falou aqui chegou na camada de loop. Então eu conseguia criar um loop que fazia todos esses processos passando pelos gates e aprendendo. Só que o grande problema que faltava pra mim é, quando eu tenho um problema, o que acontece? Eu parava o looping, porque esse seria o critério de exit. Se eu não conseguir fazer, eu vou parar e vou botar o mano no loop. E aí vem a grande sacada. Eu tenho que ter um sistema que aprende com isso. Então, a ideia de achar o bug no cliente foi, eu falei basicamente pro loop, o seguinte: olha só, quando você encontrar um erro, você vai parar, você vai logar e você vai investigar esse erro. Na hora que você achar a causa raiz desse erro testada por causa disso, disso, assim, assim, assim, você vai criar uma skill pra isso. E isso foi genial, porque ele criou uma skill de precisão de conversão de numérico pra Python na precisão. E o que a gente descobriu é que alguns centavos faltavam do lado esquerdo. Então, a precisão estava certa no Python, mas errada no sistema legado. Nossa. Pelo tipo numeric14/6 ou alguma coisa que tinha mudado no sistema deles, ele não estava pegando centavos. E isso gerou uma diferença de 137 mil dólares nos últimos três meses. Caraca. Agora imagina você conseguir entregar isso para o cliente. Não só a tradução, mas também o resultado de que existe um erro no próprio sistema do cliente. Então isso foi fantástico.

SPEAKER_01 48:45

Maluquice, né, cara? Muito massa. E eu acho que com o teu exemplo a gente consegue enxergar um pouquinho de cada coisa acontecendo ali.

SPEAKER_00 48:52

Sim.

SPEAKER_01 48:53

O que transforma ali, o que chega na Dark Factory, né? No Agente Kingering, né? No final das contas. E aí eu queria só fazer uma colocação aqui dos quatro papéis que ficam para o mano no final, né? Que é o taste e o intent, né? Que é você ter o gosto e a intenção de construir. Você vai definir o que construir e o porquê, você tem que ter isso também. Não adianta construir qualquer coisa por aí. Você vai ter a parte de evalu design também. Você vai definir mecanicamente o que o correto significa no final das contas. A parte de orquestração, que você vai ter que você ter que ter alguém também para arquitetar a fábrica. Os loops e o harness ali, no final das contas. E a parte de exception handling, que é, cara, deu erro, que foi o exemplo que você acabou de dar. Retorna pra mim, né? Ou então, sei lá, a Lemu, a gente deu um orçamento ali, talvez, e ele retorna pra você, certo? Que você vai colocar a mão. E você concorda com esses quatro patrões?

SPEAKER_00 49:53

Cara, eu concordo, e se vocês estiverem explicando isso ou vendo isso, não. Acho que esses quatro são objetivos muito importantes. Isso vai mudar a forma como você pensa como sistemas agentes. Você acredita? Tudo isso aqui que a gente está trazendo é baseado em casos reais. É a teoria aplicada para vocês verem. Então, esses quatro pontos aí, eu queria que você repetisse para ficar gravado aí para vocês entenderem qual é. Eu só adicionaria o spec. O spec como fonte da verdade. Então, você não faz mais vibecoding, você cria o spec para drivar tudo isso. Isso aí seria um. Saber fazer boas perguntas também. Exatamente.

SPEAKER_01 50:27

Você ter uma especificação muito boa também. Então, texture intention, né? Você ter gosto e ter. Agora fugiu o intention. A intenção. A gosto e a intenção e entendimento, né? Ter ali o objetivo. A parte de evalua design também, que é definir também o que o correto significa. O que no final das contas vai ser o correto. A parte de orquestrar, né? Como é que você vai montar, arquiteturar ali a fabric, né? A parte de loopings, o harness. E o exception handling, né? Que é lidar com erros. Como é que você vai. O que o seu LLM, o que o seu agente tem que fazer no final das contas, pra lidar com os erros, né?

SPEAKER_00 51:07

E aí o Spec, como first class citizen, eu diria.

SPEAKER_01 51:12

O Spec, né? Pra você escrever o Spec. Massa. E aí. Dá até pra colocar que o humano migra de executor pra pensador, né? Porque a gente deixa de fazer, a gente passa pra ser pensado.

SPEAKER_00 51:24

O que é o que vai mais valer dinheiro? Que esse pensamento vai fazer com que você possa se comunicar com o problema em vez do código. Que esse é o problema dos engenheiros. A gente pensa só no código e na solução técnica e não no problema real. Se a gente parasse tempo, ciclos no problema real, a gente evitaria muito problema que a gente precisa passar na engenharia.

SPEAKER_01 51:47

Massa. Então, a gente vai encerrando por quê? Exatamente, perfeito. E eu só queria deixar aqui uma frase final, né? Que a gente passou aí a última hora falando sobre teoria, as camadas, os papéis, Dark Factory, né? Porque é algo totalmente disruptivo. Mas aí eu queria deixar uma pergunta de final de podcast, não para vocês dessa vez, mas pra quem tá escutando a gente, que é se você realmente confiaria numa fábrica autônoma para rodar um pipeline crítico hoje. O que vocês acham disso? Espero que vocês pesquisem, que vão atrás também desse conhecimento. Estamos abertos, como sempre, né, para trocar ideias, LinkedIn, no YouTube, em todos os lugares, a gente está sempre aberto a tudo. Haja cabeça também para isso, mas sempre estamos aqui abertos à troca de ideias. E é isso, gente. Foi no final aí de mais um episódio. Muito obrigado. Muito obrigado, Luan, mais uma vez. E é isso, gente. Acabamos aqui. Até a próxima. Até a próxima. Obrigado.