App do Zero com IA: Harness, Sub Agents, Spec-Driven, Novas Skills e Workflows

Author: Waldemar Neto - Dev Lab · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: Portuguese

Original video: App do Zero com IA: Harness, Sub Agents, Spec-Driven, Novas Skills e Workflows · Channel: Waldemar Neto - Dev Lab · 1:11:13 · Watch on YouTube

Topics: AI agents, Task and workflow automation, Software engineering with AI

Summary

Waldemar Neto demonstra como desenvolver do zero uma aplicação full stack com IA, começando por um prompt simples e avançando para plan mode, skills e abordagens spec-driven. Ele explica como organizar o contexto, usar subagents e validar as implementações com testes, Playwright e revisão por IA. O vídeo compara o spec-driven tradicional com um fluxo mais enxuto, baseado em plano e checklist de verificação, pensado para modelos mais capazes. Também apresenta práticas e ferramentas para avaliar e aprimorar o harness de um projeto.

Key points

Um roadmap ajuda a dividir o trabalho em etapas e acompanhar o progresso da implementação.
As regras do projeto devem ser concisas e registrar principalmente o que o modelo não consegue inferir pelo código.
Playwright pode ser usado para o agente testar interfaces e validar visualmente o que implementou.
Plan mode e subagents ajudam a explorar o repositório e revisar o plano antes de escrever código.
Separar pesquisa, planejamento, implementação e verificação reduz ruído e facilita o controle do contexto.
Um harness combina instruções, skills, estrutura do código e mecanismos de feedback, como testes e lint.
No spec-driven tradicional, a implementação segue tarefas menores e verificações determinísticas, o que pode aumentar a segurança, mas também o tempo e o uso de tokens.
O fluxo apresentado como TLC Spec combina spec e design em um plano e verifica a implementação com um checklist.
A revisão por IA pode usar subagents para examinar segurança, requisitos, testes, arquitetura, regressões e performance.
Skills como Harness e Val e Harness Score podem ajudar a identificar instruções redundantes e avaliar a estrutura do harness.

Chapters

Start	Chapter	Summary
00:00	Apresentação do workshop e da aplicação	O apresentador apresenta o objetivo do vídeo e mostra a aplicação full stack que será desenvolvida do zero.
03:16	Regras do projeto, roadmap e validação de interface	Ele explica o papel das regras do repositório, cria um roadmap e configura a validação de mudanças no frontend com Playwright.
07:00	Primeira implementação e limites do prompt simples	A aplicação recebe uma primeira funcionalidade a partir de um prompt direto, e o apresentador discute como verificar o resultado.
13:29	Plan mode, subagents e revisão do plano	O fluxo passa a usar plan mode e subagents para explorar o código e preparar uma implementação revisável antes de alterar arquivos.
18:16	Janela de contexto e etapas de trabalho	O apresentador explica os efeitos do tamanho e da compactação do contexto e recomenda separar pesquisa, planejamento, implementação e verificação.
23:05	Criando uma skill para planejar e verificar	Ele cria uma skill que esclarece dúvidas, registra regras de domínio e prevê uma etapa de validação por subagent.
30:02	Skills, feedback e fundamentos do harness	A demonstração relaciona progressive disclosure, skills e regras do projeto aos mecanismos de feedback que orientam o agent.
35:58	Spec-driven development e benchmarks	O apresentador mostra o repositório Agent Skills e introduz o fluxo TLC Spec Driven, incluindo especificação, design, tarefas e validação.
42:17	Especificações, tarefas e trade-offs	Ele detalha como regras de negócio e tarefas verificáveis orientam a implementação, discutindo o custo de um fluxo mais estruturado.
48:11	Limites do spec-driven e integração com boards	O vídeo discute dificuldades de manter a spec como fonte da verdade e a importância crescente de integrar o trabalho com task tracking.
52:25	TLC Spec: plano e checklist de verificação	É apresentado um fluxo que combina spec e design em um plano e deixa a implementação mais livre, verificando-a depois com um checklist.
1:01:33	Code review por IA e harness de projeto	O apresentador demonstra uma revisão com subagents para segurança, requisitos, testes, arquitetura, regressões e performance, além de ferramentas para avaliar o harness.
1:08:05	Recapitulação dos fluxos e recomendações	A recapitulação compara o prompt simples, o plan mode, as skills e o spec-driven, e resume quando usar cada abordagem conforme a capacidade do modelo.

Quotes

Eu não estou usando skill nenhuma aqui; estou usando o básico do básico. — 12:26

Quanto maior a janela de contexto, a qualidade tende a cair. — 19:19

É muito importante um agent ter feedback. — 32:45

Se alguém usa spec como fonte da verdade e funciona, siga usando. — 49:14

Em vez de ter spec, design e tarefas, agora temos um plano e um checklist. — 1:10:08

Concepts and entities

Harness, plan mode, subagent, Spec-driven development, Cursor, Playwright, MCP, Agent Skills, TLC Spec Driven, TLC Spec, Harness e Val, Harness Score, Grok, Waldemar Neto

Full transcript (original language)

00:00 Não importa se tu já desenvolve com IA ou se tu é iniciante com IA. Na era da IA a gente tem que estar sempre atualizado. As coisas mudam rápido. A cada 3 meses tudo muda. E é por isso que eu tô disponibilizando uma hora de vídeo, que é uma parte do workshop meu de início ao fim, que a gente vai criar uma app do zero usando o IA e colocando os conceitos para ver onde eles se encaixam. Se a gente começa do zero, a gente vê plan mode, a gente vê sub agents, a gente vê verificação, a gente vê harness, a gente chega em spec driven, a gente fala dos limites do spec driven pros modelos atuais e a gente termina com o workflow mais efetivo possível pros modelos atuais e os

00:35 modelos da próxima geração. Ou seja, em uma hora tu vai te atualizar em tudo e vai mudar a maneira como que tu desenvolve software. E também eu vou te deixar um monte de skills, as minhas skills mais novas, toda a minha pesquisa, tudo para ti melhorar o teu desenvolvimento com IA. Então, a gente vai ver hardness, Speck Driven, o que que vem depois do Spect Driven, várias skills minhas, tudo disponibilizado para te melhorar o teu workflow. E a única coisa que eu te peço é dá like, comenta, compartilha esse vídeo porque me ajuda bastante, me ajuda bastante a trazer mais conteúdo de qualidade e também ajudar toda a comunidade do Brasil. Então, eh, eu tenho uma app full stack

01:07 aqui bem bem simples, acabei de começar ela, tá? Então, é, tem só um app, um API, que é o back end, backend ban. Ó, tem um service, item service e um web, que é uma aplicação web white com React, bem simples pra gente vocês irem acompanhando o que eu tô fazendo, tá? Muita gente pediu nos outros: “Ah, eu quero que vão fazendo do zero.” Então, a gente vai fazendo do zero, a gente vai entendendo aqui as coisas juntos. Eh, beleza? Então, eu vou começar aqui que é o seguinte, essa app, o que que última empresa que eu trabalhei era um RP nos

01:38 Estados Unidos. RP é um domínio complexo, né? Então, era e tem controle de estoque, esse monte de coisa. A gente vai trabalhar mais ou menos nisso. Primeira coisa que eu vou fazer aqui é ã vou dar um prompt que é o seguinte. E aqui eu tô eu tô usando, eu tô usando o cursor, tá? Na ver eu tô usando o agents window, uso mais essa janela aqui. Vocês vem que inverteu code base fica em segundo plano, o código fica em primeiro plano. Aqui eu tô na minha janela de agente, eu tô usando o Grock e eu vou usar o 4.6 Fast por como é um como é um um workshop, eu quero que a coisa vá rápido, tá? Então eu vou usar o Fest

02:11 aqui. Ele ainda assim no Fest ele é mais barato que um Opus. Então vale muito a pena. Primeira coisa que eu vou dizer aqui é pesquisa quais módulos são necessários para termos um RP completo funcional com controle de estoque eh warehouses, obras, alocamento de STF, administrador e operador. Isso aqui não é uma coisa que vocês vão fazer no dia a dia, tá gente? Só que eu tô fazendo isso para quê? pra gente ter um arquivo de roadmap, que é o que a gente vai trabalhar nele. E aí cada ciclo do roadmap a gente vai usar alguma técnica diferente. Eh, Adam, olha, se tu precisar falar alguma coisa, eu não vou ver o chat por um tempo, tá? Tu pode me interromper. Aqui não tem nada de

02:43 especial, tá gente? Cunhar, é só um start mesmo, só para vocês ir acompanhando comigo o que que tá acontecendo. Então ele vai fazer uma busca na internet sobre e coisas similares e a gente vai criar um roadmap. Enquanto isso, o que que eu tenho nesse repositório, tá? Eu tenho agents.m. Que que é o agents.m? É uma, a gente chama de rules, são coisas que sempre carregam na janela de contexto. Se eu descer aqui na janela de contexto, ó, tá o que tá na minha janela de contexto aqui. Lembra que a gente paga tokens por é loops na janela de contexto. Cada vez que manda pro modelo e volta, eu tô pagando por isso. Então aqui eu tenho meu system prompt, o

03:16 system prompt que é do cursor, as tos que é tipo ah, read file, é chamar o MCP a um ato MCP, esse tipo de coisa. rules e ponm aqui as skills. É, então aqui me deu, ó, módulos necessários identity, autorização, identificação, catalogue, warehouse, inventory, job, staff, assignment, procuramente. OK. OK. Crie ummap oldmap.md. Ah, então vou criar aqui. Então, tava explicando agents.md. É, a gente fez uma live sobre isso. Quem não assistiu aquela live e tem dúvida sobre o que que é um agentesm, como como criar um.Md,

03:50 bom, assista a live. Mas em resumo, o que que ele é? Eles são regras, coisas que eu quero que sempre o agente carregue. Aqui eu vou botar, gente, o mínimo de coisa possível, tá? Só coisas que o modelo não vai entender sozinho. Como eu falei, os modelos evoluíram bastante. Essa última versão de modelos, além de ser muito inteligente, eles são muito bons em usar tools. Ou seja, eles são muito bons em tipo buscar skill para usar, é saber chamar o MCP. Eles são muito inteligentes. Então eu não preciso botar tanta coisa no agent.md. Que que eu botei só aqui? Principalmente coisas que ele não saberia. como que é feito o

04:21 dependência injection nesse repositório. Isso depois de eu ter bastante código feito sempre do mesmo jeito, eu posso remover porque o código é o melhor exemplo, tá? E a minha estratégia de teste, ah, eu digo que service tem que ser, tem que sempre ter unidade porque tem lógica de domínio. Rota e banco, tu testa indiretamente com teste de integração. Só o repositório não não prova nada, ele só testa com o teste end to end, tá? e web eu não tenho testes, eu vou explicar depois sobre isso. Então essa é a o básico que eu preciso para começar a trabalhar nesse repositório aqui. Agora eu vou botar mais uma coisa,

04:53 tá gente? Mais uma coisa que é importante. Eu quero que sempre que eu implemente algo que toque no front end, ã, eu quero que o próprio agente teste aquela coisa para ver se deu certo, tá? Então vou dizer o seguinte. Hã, coloque uma regra no agents.m para sempre validar uma implementação. Validar no final da implementação usando playw quando toca em telas. Que que eu tô dizendo aqui? Eu tô dizendo para ele usar o meu playght. É, quem não sabe o

05:26 que que é o playght, eu vou mostrar para você. Aqui em e customize, eu tenho meus MCPs. Um deles que eu tenho é o Playwright. Playwright é bem famoso, tipo Cypress. Ele é bem famoso com automação de teste no front end, end to end, tá? A pessoa entra, navega e clica em tudo. O MCP, ele me, basicamente me permite fazer essas, permite o agente fazer essas coisas. Ele tem várias tools que ele pode usar encontrar um browser, cadê abrir o browser, clicar nas coisas e tal. Então eu basicamente dou pro agente isso fazer e digo: “Olha, cara,

05:57 tu vai ter que provar o teu trabalho fazendo isso, tá?” Ó, tá aqui, tal, tarará. E aí ele botou uma regra aqui. Então quer dizer que todo o agente que eu abrir, toda a janela de agente que eu abrir, vai saber disso aqui e vai fazer. Espero que ele faça, tá? Então a gente tem o que agora? A gente tem um roadmap que a gente vai seguir. Isso aqui eu só de novo, eu só fiz isso para eu não precisar estar pensando na próxima coisa. Tem o roadmap e eu vou botar mais uma coisa aqui, ã, que é seguinte, para [limpando a garganta] ver ver se para vocês, eu quero que vocês vão entendendo como que a coisa funciona com IA, tá?

06:27 Tem muita coisa que vocês vão ter que ir dizendo basicamente. Então, hold em H aqui. Every time a road map item is completed. Mark it as done in the road map. Então, só botei isso aqui que é o seguinte, sempre que eu implementar alguma coisa no roadmap, ele vai lá e marca aquele road map como dano, tá? Só pra gente saber onde a gente tá progredindo. Então vamos começar. Primeira coisa, qual é? Qual o próximo item? Item do roadmap. Vamos ver qual

07:00 que é o meu próximo item do meu roadmap aqui. Ah, que é o warehouse stock, eu acho, porque eu só tenho tenho só um item no momento. Warehouse stock. Beleza? Então, vamos lá. A maneira mais fácil de implementar é qual? É, OK, implemente isso. Implo. Eu vou fazer do jeito mais básico que a gente vai entender o quais são as limitações disso. Por quê? Porque a gente tá com momento que as pessoas têm muita dúvida, né? Principalmente, ah, spec driven é waterfall, eh, não sei quê. Tipo, todas essas coisas a gente tem que entender a nível fundamental e a gente vai entendendo a nível fundamental aqui para vocês conseguirem entender e ter as respostas para essas coisas. Ah, o que

07:32 que é loop engener? O que que é graphic engineer? Todo esse tipo de coisa. A gente vai chegar lá quando a necessidade aparecer. Então, eh, eu dei um prompt para construir, tá? Ou a gente vai buscar os arquivos que eu vou explicando. Eu tô usando um reason em high aqui, tá vendo? E high. Que que isso quer dizer? Quer dizer que ele vai pensar mais. Se eu clicar aqui e olhar, ele me mostra os arquivos que ele leu e tudo que ele tá pensando. Então ele fica num loop de pensamento, gasta mais tokens, mas é importante quando ele tem que pensar bastante, principalmente fase de planejamento que a gente vai entrar depois, tá? É bem importante. Eu gosto de usar eh nas fases de planejar, eu uso

08:05 bastante reasoning high. para implementar, normalmente eu uso medium, [limpando a garganta] mas hoje em dia com o Grock que eu tô usando aqui, ó, antes eu usava um modelo bom para planejar, o modelo mais ou menos para implementar, tipo, ah, opos para planejar, eh, son para implementar. Hoje em dia o groque tudo, tipo, é barato, barato comparado com os outros, é rápido, é bom, cara, toca aí, faz o que tu quiser. Mas às vezes eu uso tá às vezes eu uso opos quando eu preciso de pensar muito em coisas. Acho o reasoning é do Opus melhor, as as conclusões dele melhor, mas realmente

08:37 ele é bem mais caro. E no cursor eu tenho o Grock dentro do meu plano também que me ajuda bastante. Então, ó, ele fez uma pesquisa dos arquivos e tá começando a alterar, tá? Foi lá, vou alterar tudo que ele tem para alterar. Ele também vai botar aqui no no meu context. MD que eu não mostrei para vocês, mas é um arquivo, eu gosto bastante de ter isso, tá gente? Inclusive, tem uma skill que eu vou deixar para vocês depois que é do context context map. Basicamente os itens de domínio, cada coisa nova que eu boto no meu domínio, ele bota nesse arquivo. Ah, o que que é um item? Que que é um catálogo? Que que é um uma

09:07 unit? Que que é uma warehouse? Que que é um estoque? Porque assim, eh, o a gente não precisa pensar de novo o que que é essa coisa, sabe? Ah, o que que é um que que é uma warehouse? É onde os itens, as quantidades vivem, tá? E o que que ela não é aqui? Ela não, o que que eu não quero ter? Eu não quero ter estoque num catálogo, por exemplo. Stock tem que estar na warehouse. Então, são regras da minha arquitetura que são bem importantes ter também. Eu gosto bastante disso. Então ele vai implementar essa parte aqui, ó. Já tá implementando um teste e tal e vai atualizar o roadmap. Vamos ver. Cadê? Ele vai atualizar aqui agora, ó. Dane catálogo. Deve chegar nesse cara aqui

09:39 depois. Aí assim vocês viram que que que eu que eu fiz para isso aqui acontecer. Eu basicamente escrevi aqui. Então qual que é a ideia de vocês? Primeira coisa que vocês tiram daqui. Os modelos estão cada vez melhores e mais confiáveis. muitas das coisas eles vão seguir. E a ideia é assim, provavelmente no nosso workshop do início do ano que vem eu vou est dizendo para vocês, cara, quase não usem skills, porque vai ter técnicas que a gente vai usar pro modelo seguir as coisas. Eh, muito bem. Hoje em dia a gente tem que usar, ainda vou explicar para vocês depois, mas eh só de eu botar isso aqui, screens e o roadmap, ele já

10:12 atualizou o roadmap aqui para mim, ó, a warehouse tá done, tal. Então eu não preciso me preocupar muito em nessas coisas. Eu vou botando essas regras naquele arquivo ali. Ah, agora ele vai ah fazer um teste e tal. E isso. Beleza. Outra coisa que eu vou dar uma olhada aqui, deixa eu ver. Vou atualizar. Ó, agora ele vai subir a API web. Quero deixar ele abrir aqui para vocês verem, ó. Abriu o web. E assim tá feião meu site ainda, gente. Tá feião. A gente vai arrumar isso aqui tudo junto, tá? Mas olha ali, entrou, testou. Então, outra coisa muito importante, principalmente para quem trabalha com front end, tá? O

10:46 IA, sem ela ver a coisa, é quase impossível ficar bom ou tu conseguir validar que fica bom. Eh, modelos são muito bons com imagens, muito bons com imagens, mas muito ruins em interpretar algo visual sem ter aquela imagem. Eh, se tuud um componente frontend, quem é frontange deve saber disso aí, manda no chat. Tu manda um, sei lá, uma coisa do Figma, uma parada assim, tu acha, ah, vai ficar pixel perfect, não fica, tá ligado? Aí tu manda uma imagem, ele consegue chegar próximo daquilo ali. Então é playw, pô, para quem trabalha com front end. Mas agora vem outro, vem um problema assim, pô, mas aí eu crio

11:20 testes com playw, comito esses testes, cara. Aí é outra conversa. Eu sugiro daqui a pouco ter testes para os raps, alguns deles, mas manter teste end to end caro, é lento, é desafiador. Então é, eu sugiro tomar cuidado com essa parte, mas usar para validar é bem importante, tá? Porque eu venho aqui, ele entrou e testou tudo que ele fez, ele vai me dizer lá depois que beleza, deu certo. Então isso eu uso bastante, tá? Ah, gasta tokens, gasta um pouco mais de token, obviamente, mas evita retrabalho, né? Se eu tivesse que entrar eu, humano, testar tudo e deixar as coisas passar, é, ia gastar o meu tempo

11:54 também. Aí vai de quando vocês estão disponíveis, é, a para gastar. Então, ó, ele vai terminar de testar aqui. >> Acho se puder fazer um recap rápido assim de o que que tu fez até agora, que tu tá focando basicamente em estressar a capacidade do modelo usando poucas coisas como guia ali, né? Porque tem gente perguntando quais skills tá usando e tal, tudo mais. Se puder dar uma repassada sobre isso. >> Boa, gente. Eu não tô usando skill nenhuma aqui, tá? Eu tô usando o básico do básico. Eu dei, é, a gente começou pelo básico do básico. Eu dei um promptir

12:26 warehouses stock, tá? E a única coisa que eu dei a mais foi instruções do meu agents. MD nas regras. Dizer: “Olha, tudo que tu tudo sempre que tu tocar uma um screen, tu tem que testar com playw, abrir, fazer isso aqui que eu mostrei. Vai lá, testa as telas com playrht e a gente tem o roadmap do que a gente vai fazer que tá atualizado. Beleza? Eu dei um prompt aqui, digo, ó, disse constrói. Agora eu construí isso daqui, tá? Pode dei um prompt e construí. Qual que é o problema agora? Qual que é o problema que eu tenho agora na minha mão? Tipo, vamos ver aqui. Vou abrir o chat, mano. E qual que é o problema desse desses que

12:56 eu fiz? Code review, arquitetura, vibe code regressão. Exato. Gente, eu não sei, eu não sabia o que ia ser feito. E eu agora para para validar a resposta, tá? Eh, pô, como que eu valido que isso aqui ficou bom? Eu vou ter que ir mudança por mudança olhando. E como que eu sei que ele testou que tinha que testar? Como que eu sei que todas as regras de negócio eh foram implementadas? Cara, eu não sei. Sabe? Aqui, como não é uma mudança grande, eu imagino que foi feito praticamente tudo. Mas vocês não vão fazer isso em produção, tá? Eu vou comentar isso daqui. Ah, só um minuto. Então, pô, em

13:29 produção vocês não vão fazer isso aqui, né, gente? Ah, então o que que é a primeira coisa que a gente vai fazer, pô? Então, eh, o que que a gente pode fazer aqui? A gente pode usar um plano mode, por exemplo, beleza? Eh, planeje o próximo, que é esse daqui, ó, próximo item do roadmap. Qual que que que a gente vai ter agora de diferente? Pô, a gente e assim, eu tô falando aqui, gente, para quem escreve código em produção, tu vai ter que saber o código que vai entrar e tu vai ter que ler o código no final para ver se ele foi na direção certa. a gente vai ver como a gente vai minimizar isso ao máximo, mas

13:59 tu vai ter que fazer isso por um bom tempo ainda. Quem diz: “Ah, não lei”, não leio o código comprovadamente não é possível com código em produção de verdade. Vou deixar referências para vocês, mas tem um cara que, cara, o cara que cunhou com o o termo context engineering e tal, ele eh tentou fazer isso por 4 meses, chegou um ponto que ele não conseguiu nem refaturar o código mais. Ele teve teve que refazer toda a aplicação porque ele não leu o código, tá? Então ele ele é um cara que fala que sim, a gente vai ter que ler por um bom tempo. Mas pô, agora eu fiz diferente, né? Eu dig eu disse: “Olha, planejo usando plan mode”. Eu vou explicar o próximo item do roadmap. Então que que

14:33 que ele fez aqui? Ele abriu é sub agents para explorar. Que que são sub agents, gente? Só para relembrar, subagents é pensa que como se fosse uma trader é muito importante isso. Para não poluir a janela de contexto. Daqui ele abriu, ele explorou as duas coisas. Quais são os padrões da API? Ah, os padrões, quais [limpando a garganta] são como que funciona o web? Explorou os dois, trouxe só uma resposta pro agente principal, tá? E assim o agente principal consegue tomar uma decisão. Eu não precisei fazer nada para isso, tá? As ferramentas

15:05 novas, cursor, cloud code e tal e e os modelos inclusive são inteligentes e saber, olha, isso aqui é, eu tenho que fazer uma varredura no code base. Eu não vou fazer isso na minha janela de contexto principal porque ela é limitada. O Grock ele nem tem janela de 1 milhão. A janela máxima dele é 250.000 tokens. Então não vou encher essa janela aqui. Vamos ver. Ã, fase dois é user roll. Blá blá. O que entra nesse slide? A roll fica como campo user, não como uma tabela própria. Só cadastro. Cadastro mais login. Vamos botar aqui cadastro, cadastro mais login. Show. Isso aí. Isso que ele vai fazer. Essa

15:37 pergunta que veio também é o próprio modelo usando uma tool de pergunta porque não ficou bem claro. Então o plan mode vem da própria ferramenta. Dentro dele ele é como se fosse uma skill, tá? Tem algumas instruções de como fazer as coisas. E aí ele me manda isso aqui para deixar mais claro como as coisas têm que ser feitas, tá? Então essa essa aqui é basicamente a ideia do plan mode. E o que que vai acontecer agora? Agora eu vou conseguir ter uma das primeiras coisas que são úteis que eu conseguir ver o que vai acontecer. Ó, você fechou o escopo, ele vai passar pelas coisas e vai escrever um plano pra gente. O

16:08 cursor e o cloud code já abrem o browser. Por que usar o playwite? Porque o playwite não depende da ferramenta que tu vai usar, né? Tá num time onde todo mundo usa o cursor, por exemplo, e tu testou o browser e funcionou bem. Eh, pô, pode usar ele, mas eu tenho uma experiência muito boa com o Playght e ele basicamente tem o MCP, funciona em qualquer lugar. Então eu eu deixo ali minha dica de playeroid para mim ainda é muito útil. Então, tá, agora a gente tem um plano. Pô, o plano já me permite revisar o que que vai ser feito. O plano pegou a linguagem, ele me explicou aqui o domínio, o que que vai ser feito, ele

16:41 mostrou as rotas que vão entrar também e o que que vai ser alterado. Ah, [limpando a garganta] o shape da API, os testes que vão ser feitos. Então, eh, ter um plano, uma spec, não é, não é, eh, waterfall, né, a galera tá falando, porque é basicamente tu pegar um bloco de trabalho e tu usar o agente paraar nesse bloco antes de tu escrever código. Assim, lembra da primeira implementação que a gente fez? Tu corrigir aquilo lá é muito mais difícil, porque tu não sabe exatamente o que que ia ser feito e tu não sabe exatamente o que que tu pediu.

17:12 Então, tu vai ter que ficar lupando com a gente até corrigir e gastando tokens. Então é muito melhor tu lupar com o agente numa especificação, porque basicamente é como se tivesse implementando a coisa sem implementar do que tu lupar um agente num código já feito, tá? Então o plan mode ajuda isso aí. Todas as ferramentas têm plan mode por padrão, tá? E aqui, ó, beleza? Tem algumas coisas que eu vou revisar, então eu não vou revisar no detalhe aqui, até por isso que é um código de teste, mas na vida real eu dou uma boa passada. Mas assim, vocês vão ver quando eu fizer o nosso código de verdade de produção, um código que já tá bem estruturado, que já tem eh um bom harness que eu vou

17:44 explicar. Normalmente as coisas saem com modelo bom num numa situação, num detalhe bem bom, mas claro, se é um código legado que tu ainda tá adotando IA nele, tu vai ter que a cada vez que tu planeja ver o que que ficou pendente, o que que ele errou, arrumar e também arrumar no teu MD ou skill para ele não errar mais. É um processo de longo prazo, tá? Mas aqui a gente tem a primeira coisa, beleza? Pô, fiz isso aqui. Aqui, olha, eh, pensa o seguinte, esse agente aqui, primeira outra coisa que a gente vai ver agora, esse agente aqui pensou em um monte de coisa para poder planejar isso. E aqui tem um

18:16 resumo do que do que que tem ser feito. Na vida real, provavelmente essa janela de contexto ia est lá pelos 60, 70% já. Não tem por eu construir nessa janela e fazer ela ser compactada. Eu vou explicar sobre isso. É muito mais fácil eu pegar esse plano aqui, ó. Vou pegar esse plano aqui e vou dizer o seguinte: pô, constrói isso aqui em outro agente com uma janela de contexto zerada. Então, basicamente, em um agente eu fiz uma busca e no outro eu vou construir a coisa ali com uma janela de contexto zerada. E por que que isso é importante, gente? Deixa eu, enquanto ele constrói agora, eu vou voltar aqui. Por que que

18:48 isso é importante? Por a gente tem hoje janela de contexto até maiores, tá? A gente tem janela de contexto de 300.000 tokens para quem usa é Opos, duas, dois níveis, né? Normalmente é um que é o safe, que é assim, olha, dentro dessa janela, nós antropic, open AI dizemos que é seguro tu trabalhar. Quando vai para 1 milhão é tua responsabilidade. E tem dados comprovados que quanto maior a janela de contexto, mais a qualidade cai, tá? Então eu tenho, não sei se, deixa eu ver se eu acho, é aqui a comparação do GPT em um em um paper

19:19 científico. Quanto maior a janela de contexto, tá vendo? Cada, basicamente cada 100.000 tokens a mais, mais a qualidade cai. Então vocês têm que cuidar a janela de contexto para manter a qualidade do output boa. E a gente gosta de falar que, pô, cara, em torno de 40% tá safe da janela. Tá 60%, cara, dá para ir tranquilo. Acima de 60% tu vai começar a pagar um pouco com a qualidade. Ah, mas é extremamente preocupante. Depende do contexto, né? Depende do contexto em dois sentidos, né? defe do contexto, amor. É, se tu tem, por exemplo, um plano, um plano e depois tu tem uma maneira de checar

19:52 aquele plano, pode ser que perder informação no meio, não importe, porque o agente sempre tem para onde voltar. Mas se tu dá um prompt frio para um agente e tu, o teu único contexto é a janela de contexto, aí a qualidade começa a cair. E se ele compacta, aí piora, porque compactar faz o quê? Resume tudo que tá na janela de contexto e reinjeta as as regras de volta. Então, tu perde tudo que tu conversou. Então, quando que deixar jela de contexto encher é tranquilo ou quando que compactar é tranquilo? Quando eu sei que as minhas regras tão em uma spec ou num plano ou e também eu tenho uma maneira

20:25 de checar, tá? E assim, tranquilo até ali, porque o agente vai tomar decisões daqui a pouco que ele já tomou ou decisões diferentes porque ele compactou a janela e perdeu aquele resumo. Tem um paper que eu vou deixar para vocês que mostra assim que ele joga tudo fora, tá? Ele não ele não escolhe. Tá, isso aqui é uma coisa importante, isso aqui não é uma coisa importante, não. Ele compacta tudo e só reinjeta as coisas de volta, tipo pmmd e as skills. Então é bem perigoso. Eu tento manter mais ou menos nesse tamanho ali de uns 60%. E outra coisa importante para para lembrar é que LLMs elas são stateless, tá? Elas não

20:57 sabem ter o code base, elas não sabem nada. A cada prompt, ou na verdade, a cada loop que o agente dá aqui, cada chamada de modelo, ele manda tudo que tá nessa janela aqui para para pro modelo. O modelo faz eh uma análise, ó, qual que é a próxima coisa aqui, manda de volta. Então é, gente, é por isso que a janela vai enchendo, tá? Ah, tá. Mas se usar uma janela de 1 milhão de tokens, como a gente falou, vai perdendo a qualidade. Quando que eu uso uma janela de 1 milhão de tokens? Quando eu tô fazendo uma fase de research, ó. Então, pensa assim, o loop de trabalho de vocês vai ser o quê? pesquisar algo, usar o agente para

21:30 ajudar vocês a chegarem em alguma definição. Nessa fase aqui, tu vai abrir o máximo a busca e tu vai usar também sub agents, tá? Então aqui, por exemplo, ó, ã, aqui nesse aqui que eu criei o plano, tá vendo que ele usou um sub agent? Cadê? Hum, aqui, lembro cadê agora, mas ele tinha usado dois subagents, eu não lembro qual foi o o chat. E é OK, tá, gente? Deixar o modelo usar sub agents para fazer pesquisa é bom, ele mantém a janela de contexto menor, ele consegue separar os contextos. Vocês viram que quando ele usar subent lá, um sub angent buscou coisa do back end, outro do back do do

22:02 front end. Então cada um sai com uma missão. Isso é bom, isso a própria ferramenta faz, tá? E nessa fase tu pode mandar link de coisa, conectar um monte de coisa. A gente vai ver depois é quando for o exemplo de construir a feature na na Techlads Clube, é, a gente usa muitas métricas, post, conecta um monte de coisa. Beleza? Só que aqui vai ter um monte de ruído. Depois quando tu vai paraa implementação de verdade, tu não quer ter esse ruído. Aí tu pega isso e joga em um plano, uma spec, o que for, tá? Ó, terminou, terminou de implementar, tá? Terminou de implementar esse cara aqui. Eu só vou terminar de

22:35 explicar. joga num plano, depois tu vai para uma fase de implementação e verificar aquela implementação. Então, voltando aqui, pô, meu meu plano terminou de implementar, implementou tudo aqui que a gente tinha falado. Eh, tã, aí rodou o playgrid, deixa eu ver. Tá, tá aqui, tal. Beleza, testou as coisas. É, o que que falta agora nesse daqui? O que que falta nesse approach com plan mode? Vamos lá. Que é o que que falta? Eu já vou botar a imagem do funil de volta. A gente vai voltar. Não se preocupem, gente. A gente vai voltar lá.

23:05 Só quero, como a gente tem um agente rodando, eu quero deixar ele rodando enquanto eu falo alguma coisa. Que que faltou? Code review. Revisar agora. Tá. Mas como que a gente revisa? Eu humano, eu sei que tinha um plano, eu consigo bater, eu consigo eu revisar, tipo, pegar o plano e revisar o output um por um. Cara, isso não é sustentável, não é? Pô, por exemplo, se eu vier aqui e eu olhar pro plano aquele que ele fez e revisar cada uma das coisas, cara, não dá. Então, o que que é a coisa mais fácil que a gente pode fazer? Usar outra LLM para validar. Ah, bom. Playwright não validou, ele validou a navegação das

23:37 coisas, mas, pô, todas as regras de domínio tão tão aplicadas, tudo que a gente falou que ia fazer foi feito, cara, não sei. Então, qual que é a coisa mais simples que a gente pode fazer, tá? Que eu vou mostrar para vocês agora. Vamos lá. Vamos botar aqui. E aí eu volto com aquela explicação do contexto, tá? Não se preocupem. Pum, fit idente. Ah, show. Qual que é a coisa mais simples que eu posso fazer? Eu vou criar uma skill. Der, crie uma skill que é planeja, pergunta. Eh, tira dúvidas, dúvidas do trabalho com o usuário, cria

24:08 um plano spec com given, when, then e todas toda todas regras de domínio também também marca as decisões técnicas e tem uma fase de implemente de implementação que após implementar inicia um sub agent. que valida se tudo foi feito como na spec, ó. Beleza? Então, o que que eu vou fazer aqui? Eu

24:39 tô criando uma skill. Por quê? Eh, porque as pessoas também tm muita dúvida. Ah, como que eu crio uma skill? É, que que vai na skill e tal? Então, já vou aproveitar para fazer duas coisas ao mesmo tempo. Primeiro é mostrar para vocês é o o mais fundamental que vocês tem que entendiar e depois em cima a gente constrói as coisas, tá? Depois a gente vai entrar, a gente vai entrar em spec driven, a gente vai entrar nos limites de spe driven atuais por causa dos modelos, a gente vaientrar o que que vem depois de spe driven, mas a gente tem que alinhar muito nessas coisas fundamental fundamentais aqui, que é o que que eu consigo fazer hoje. Lembra que eu falei que a gente tava construindo uma ferramenta, né, o o Felipe tá aqui, o Spectror, que era uma

25:12 ferramenta que fazia um pouco dessas coisas. Hoje tu consegue instruir um modelo e os modelos bons eles seguem a maioria das instruções, tá? Ele inicia um sabi agent, ele inicia um um playw e e eu chuto que até o final do ano isso vai ser muito muito muito mais confiável, tá? Ã, por que uma skill e não um agente? Eu raramente crio agentes, porque pensem o seguinte, skills são reusáveis. Tu pode iniciar um sub agent genérico e dizer usa três, quatro skills. Um sub, um agente, quando cria um agente custom, ele é um papel

25:43 só, ele não é flexível. A skills basicamente tornaram agentes quase obsoletos. Tem casos que tu quer usar, mas basicamente tu faz tudo com skills, tá? Então ele vai criar essa skill para nós e a gente vai ver, ó, que tá skill, cursor, skill. Que que é uma skill? É como se fosse uma instrução que eu não quero ter que digitar toda hora, tá? Ó, ela tem um nome e uma descrição. Isso aqui é sempre carregado no contexto. Quanto mais skill tu tiver, mais isso aqui vai pesar no teu contexto. Isso que o agente decide, usa para decidir se ele usa ou não uma skill. Ele lê isso aqui e pensa: “Ah, essa pessoa quer planejar,

26:13 eu tenho spe and build lá, eu vou carregar aquela skill”. É isso que ele faz. Aqui tem eh o que ele colocou, fase um, fase dois, write the spec, fase três, implementa. Fase quatro, verifica. Claro que tu vai revisar, ver se se fez sentido, mas normalmente é assim que eu crio uma skill. O que que eu faço para criar uma skill? Eu resolvo um problema eu mesmo digo pro agente controlar, criar skill, depois eu reviso o que ele fez, porque eu não vou escrever um monte de markd, mas eu também não posso deixar ele desenfriado, criar um monte de coisa, que ele vai botar um monte de coisa inútil, tá? Então aqui a gente tem

26:44 uma uma skill já para implementar. E eu vou dizer, beleza, use eh planeje o próximo item do map usando spec, como é que é o nome dessa skill? Speck unbuild. Vamos lá, deixar ele planejar agora. E a se a minha skill é boa, ela vai me perguntar para tirar a ambiguidade, tá? Porque eu disse que tinha que ter isso na skill. Vamos ver. Ah, pararã. Cadê? Speck and build. Fase um discover. Lê os arquivos. Tã, pergunte uma vez, uma vez one one

27:17 question at the time. Isso aqui é muito bom, tá? Porque tem muita skill até de spec driven que ela manda as perguntas todas juntas, só que às vezes uma pergunta depende da outra. Só então é bom vir uma pergunta de cada vez. Ó, quem cria o job e o que muda no mundo? o que muda no mundo é profundo, não sei. Ah, faça o recomendado. E é, e ela normalmente recomenda, tá? Isso aqui o próprio eh o o própria IA já vai fazer recomendar uma coisa que ela acha ideal. Ah, faça o recomendado, que é o quê? qualquer usuário autenticado, administrador ou operador registra um job com um nome. Beleza? É isso. Então,

27:47 faça o recomendado. Não vou ficar é pensando muito, mas pensa o seguinte, é muito bom tu usar a Ll para te perguntar bastante coisas, tá? Ah, faça todos o recomendado. Tem uma skill que a galera usa bastante que é de um youtuber Mat Pecock, que é Grillmi. É uma skill muito boa. Se puderem mandar no chat aí pra galera, ela basicamente te pergunta um monte de coisa. Tu quer fazer começar um projeto, ela te pergunta um monte de coisa. Eu vou te mostrar uma, eu vou mostrar para vocês depois uma skill nossa que eu uso bastante, que é um pouco similar, mas diferente, né? Mas é, é bom nessa fase de pesquisa fazer a IA

28:22 te abrir os olhos, te ajudar bastante, porque ela tem um contexto code base, ela tem contexto da indústria, ela pode ir lá na indústria e buscar coisas e tal, eh, buscar referências da indústria. Então, isso é bem importante. Ó, vamos ver. Cadê? Ah, criou um job. Docs specs job. Bom, tenho um plano basicamente agora, né? Então é da minha skill. Vocês estão vendo isso? Eu quero fazer para vocês entenderem também que quando a gente fala de spec driven, não tem mágica ali, sabe? Um monte de gente fez um monte de skill e foram ajustando elas. Ó, que que tem aqui? Domain rules. Ele colocou cenários. Ah, lista empty,

28:56 create list contains the created job. Botou, ó, given, um usuário signed. Quando ele posta para jobs, ele recebe um erro. Então agora eu tenho o quê? todas as regras que eu consigo verificar no final, porque antes eu não tinha, eu preciso ter as regras para poder verificar no final. Decisões técnicas que o a gente tomou também. Então, só isso aqui, gente, vocês já estão muito bem. E aí, mesma coisa. Vou lá, não preciso pegar aquela janela poluída, vou dizer spec and build e construa o job. Markdown. Então, ele vai

29:30 construir aquilo ali. Eu precisava ter chamado barra speec and build job construa. Talvez não, tá? Talvez o próprio agente ia ser inteligente de usar skill, porque na descrição da skill mostra isso aqui. Mas eh eu eu gosto de chamar que eu não quero ter certeza que a coisa vai rodar do jeito que eu quero. Bom, ele vai começar a implementar. A gente vai voltar pra nossa pra nossa eh pra nossa explicação. Então, a gente viu research planejou, agora a gente vai entrar na fase de implementação. Implementa a coisa baseada na spec e verifica a coisa contra aquela spec ali. Esse é o fundamento que você tem que

30:02 pensar. Ai, mas como que verifica? A gente vai, a gente vai fazer essa verificação e vai falar das limitações de verificação com o Ll, tá? Mas enquanto isso a gente vai passar para essa parte aqui, ó. Já tá no verify aqui, tá? Tá. R. Pô, o Grock é genial, gente. Pô, eu tenho meu meus meus questionamentos do El Musk, mas é um belo trabalho que eles fizeram no Grockp muito rápido. É, a gente vai sempre tentar trabalhar numa estrutura de progressive disclosure, ou seja, de aia, o agente, ele ir descobrindo as coisas que ele precisa. E skills permitem isso. A própria estrutura do Code base permite

30:37 isso. Então, ah, quando que eu uso uma skill? Quando eu quero ter uma, basicamente, uma instrução que eu carregue sob demanda, quando o modelo precisar, porque a skill ela tem, ela é um markd. Quando tu traz aquele markd para dentro do contexto, ele enche teu contexto. Então, eh, skills são coisas sobre demanda, rules, tu bota só o que tu precisa no agents.m, tá? Isso é bem importante. E a estrutura de research plan implement ela ajuda nisso porque tu abre um research, um monte de skill, um monte de coisa, depois tu salva num plano e tu não carrega aquelas coisas de novo. Aí a gente entra na coisa, tá? Mas

31:08 research plan implement não é spec driven? Gente, esse pack driven virou um grande guarda-chuva de coisas que ninguém mais entende o que que é, porque cada um adaptou paraa sua realidade. A gente vai falar um pouco sobre isso, e meio que perdeu a identidade. Então eu sempre volto pra coisa de não importa como que eu tô trabalhando, eu sempre tenho uma fase de research, uma fase de planejar, uma fase de implementar e agora uma fase de verificar, tá? Então aí quando a gente entrar mais em spec drift, a gente vai entender um pouco mais dessa desse momento da coisa. Ã, tá? Tá verificando com com playw. Beleza? E aí a gente entra em outro termo bem importante que é harness. Eh,

31:41 você deve ter ouvido bastante falar sobre harness, talvez foi, talvez seja coisa que foi mais falada nos últimos tempos. E harness tem dois sentidos. Tem o harness estrito que a gente fala, que é a ferramenta que a gente usa, tá? né? Então, seja cursor, cloud code, esse é o Harness que a gente não tem muito controle sobre ele. A gente confia que a empresa fez um bom trabalho. Inclusive, uma dica que eu dou para vocês é: tomem muito cuidado com ferramentas de terceiros, porque a ferramenta que tu usa interfere muito no output que tu vai ter. Então, se tu baixar uma ferramenta, ah, não quero pagar, eu quero usar modelos open source, vou pegar aqui qualquer harness na internet, cara, pode

32:14 ser que a pessoa, o desenvolvedor fez um trabalho muito ruim para gastar mais token usando aquele harness ali. Então, sugiro usar daqui a pouco um open code, algo que é conhecido do que usar qualquer coisa. Aí, em cima disso vem a parte que a gente consegue controlar ou a gente consegue adicionar para ter uma melhor resposta, que é o agents.m, é as skills, o próprio código, a estrutura do código é um dos melhores hardness que tem. Se tu conseguir que a gente entenda o código sem tu ter que dizer para ele o que que é muito melhor. Isso eh, a gente chama de guias, a coisa que guia o agente para chegar em algum lugar. E

32:45 depois a gente tem a coisa que valida, que dá o feedback pro agente. É muito importante um agente ter feedback. Vocês viram que, pô, por que que eu uso Playwght para validar o Fronte? Porque se ele não tem um feedback que o que ele fez tá certo, ele vai assumir que tá certo. E assim, não dá para deixar o mesmo agente que a missão dele é implementar a coisa, dizer se a coisa tá pronta, porque ele vai dizer que tá, porque a missão dele é terminar aquela coisa ali. Aí quando tu abre outro sub agent, que a missão do sub agent é provar que aquela coisa tá funcionando, ele vai fazer de tudo para tentar validar aquela coisa ali. E o que que são essas validações? A gente chama de

33:18 sensores, testes, lints, CI, observabilidade, hooks, que o Felipe vai falar também. Isso tudo dá feedback pro agente e é determinístico e não depende do julgamento dele. Então esse é o fundamento que você tem que pensar. Então voltando ao desenvolvimento de software, testes são extremamente importantes, Lint é extremamente importante, C é extremamente importante, todo esse tipo de coisa, porque eles dão feedback pra gente, tá? Ó, ele tá rodando aqui, deve tá rodando playw agora. Deixa eu ver, talvez seja isso, tá? Deixa eu voltar aqui. Beleza. Então, eh, nada mudou. Desenvolvimento de

33:49 software. Uma boa arquitetura vai ajudar, é uma boa estrutura que o agente entenda. Isso a gente vai ver amanhã. É extremamente importante porque tu gasta menos tokens, é, ele acha as coisas mais rápido, é uma boa qualidade, é extremamente importante porque ele vai ter feedback do que ele tá fazendo. Vocês veem que aqui no meu code base, eu tenho dois tipos de teste, tá? Eu tenho a nível de API, eu tenho teste de integração, por quero validade ponta a ponta. E a nível interno, nos services, eu tenho teste, eh, opa, eu tenho teste eh unitário, porque eu tenho bastante lógica de negócio. Ó, terminou a

34:19 validação, ele diz que a spec passou, ele verificou todas as regras de negócio que tinha no spec, lembra? Então, voltar aqui. Cadê apps, Doc, Job? Ele validou tudo isso contra aquela spec ali. Isso aqui já é bom, gente, sinceramente, isso daqui já é melhor que vários frameworks de spec driven que vocês vão usar por aí. E agora a pergunta que eu vou falar é a pergunta que eu tenho para vocês é o que que faltou aqui? A gente fez essa validação, mas o que que o que que faltou para ser pô para ser melhor? Hum, checklist. Code review. Review,

34:51 sensores, gates. Não, os gates rodaram, tá? Os gates rodaram. Ó, 106 testes passaram. Então, ele rodou tudo aqui. Os gates ele passou, ele ele rodou tudo. Faz parte da minha coisa aqui, ó. Ele não só validou, como ele rodou tudo e garantiu que tudo funcionou. Teste de mutação, segurança e tal. Revisar. Sim, review é óbvio, gente. Review vai ter, a gente vai chegar no code review depois, mas pensando que tu quer que o agente consiga implementar coisa e se autovalidar, pensa o seguinte, pensando em review, primeira coisa sobre review. Se eu tô dando uma lista de coisas e essa lista de coisas eu validei que tem

35:22 as regras de negócio que eu espero e o agente foi lá e revisou e provou que tudo tá funcionando, eu já tenho uma baita segurança. O que que falta aqui? Falta basicamente a gente ter mais validações que nos nos garantam que, pô, a arquitetura tá certa. os testes estão certos, esse tipo de coisa. Aí a gente entra numa estrutura um pouco maior, pô, eu tenho que pensar um pouco mais na arquitetura e esse tipo de coisa. Daí vem a ideia de spec driven. Deixa eu comentar aqui. Essa aqui é fit, qual que era fit? Jobs. Agora vou fazer o seguinte. É agent skills install TLC pack D. Agora a gente vai ir para spec

35:58 driven que é beleza, a gente já fez um mini spec driven aqui, já funcionou para nós, mas a gente tá construindo eh software Enterprise, a gente precisa eh ter mais estrutura na spec, a gente tá construindo algo que eu preciso validar arquitetura. Speck driven ajuda bastante nisso. Eh terceiro Speck Driven. Planeje a o próximo item. O próximo item do road map. Vamos lá. Agora vamos fazer o seguinte aqui. Quanto ele planeja, a gente vai dar uma olhada em uma skill. Que que eu fiz aqui também para instalar? A gente tem um projeto, gente,

36:28 que é o Agent Skills. Esqueço que tem gente nova aqui. Então, vamos lá. Agent Skills. Vou mandar aqui para vocês. Felipe já deve ter mandado. Manda no chat pra galera. Então, esse aqui é a nossa lista de skills open source. Todas as skills que eu vou mostrar estão aqui. Vocês foram no GitHub, inclusive dei uma estrelinha lá para nós que não deu ainda que a gente tá vendo aqui. Eu vou passar todo esse material para vocês, não se preocupem. Foquem em entender as coisas. A gente tá com 5.000 stars e aqui dentro de packag skills estão as skills no skill do catálog. É, e tem esse front end aqui que o William Fernandes tá aqui que fez. Sensacional. O Felipe Rodrigues também que tá aqui que vai falar com

37:00 vocês mais tarde, fez. E aqui tá todas as nossas skills. A gente tem scan de segurança. A gente tem uma baita auditoria para não entrar skill lixo. Cuidado com skill lixo, tá gente? Skill é um prompt que vocês estão botando é dentro do sistema de vocês e tem muito problema com isso. E aí eu instalei a TLC Speck Driven daqui. É a nossa skill de spe driven development. Ah, mas por que que vocês fizeram uma skill de spe driven development? Porque a gente começou a ver que a maioria das skills elas eram só é uma instrução de prompt e não era nenhum prompt muito efetivo. E por quê? Porque ninguém fazia, vamos

37:31 botar isso daqui, botar um monte de coisa. Porque ninguém fazia o quê? Ninguém fazia um benchmark de verdade dessas skills. El só dizer: “Ah, essa skill aqui é boa”. Aí tu pega spec kit, é super powers, open spec. Era muito sentimento da pessoa, mas eu pensava: “Pô, cara, se a gente tá gastando token numa coisa, eu não vou saber se ela é realmente efetiva ou não”. E aí a gente fez muito benchmark e ao mesmo tempo a indústria começou a mudar e a gente viu que as skills de spec driven elas ficaram para trás, principalmente por vocês já viram uma coisa aqui que praticamente nenhuma skill do spec driven tem, ela não valida o próprio trabalho. Então tipo, eu comecei a ver,

38:04 cara, a indústria tá focando só em criar um monte de spec sem validar. Se quanto mais spe, quanto mais input eu tiver e menos output de qualidade eu tiver, pior é. Então, a gente começou a criar por causa disso e a gente vai ver a funcionalidade dela aqui. Ah, isso aí [limpando a garganta] pode fazer, pode, pode criar pack, o design e as testes, mas agora eu vou vou explicar um pouco para você sobre isso, tá? Vamos lá. Eh, enquanto ele cria esse pack, eu vou voltar aqui. Depois eu vou explicar spec driven ali assim que ele terminar. Mas

38:34 normalmente o spec driven tem essas fases aqui. Eu tô usando a spec a TLC spec driven como como padrão, mas é normalmente os frameworks pega spec power são famosos. Esse é uma fase que tu especifica, aquela especificação, ela cria aquele bem similar ao give when lá que a gente viu, que é como um em BB, em BDD, em Gking. Tem uma fase de design que é podado que tu concordou no que que tu tem que fazer. A fase de design é o teu design técnico, decisões técnicas, arquitetura, diagrama. E tu passa paraa fase depois as tesques, que é a fase de

39:06 implementação, é a fase de o que que vai ser usado para implementar. Por que que a gente como indústria fez isso? Por que que spec driven veio com uma ideia de, pô, Speck Driven é a spec fonte da verdade e tal? Speck driven é a grande coisa. Porque a gente trabalhava com modelos bem, não, não digo ruins porque eu vou comparar com quê, mas tinha muito retrabalho, ou seja, tu planejava algo, tu tinha que olhar a especificação, depois olhar o design, ajustar um monte de coisa no design. Isso ainda é realidade, obviamente, para quem trabalha com código mais complexo, código legado, mas não é realidade para

39:38 muita gente, tá? Muita gente que já tem um code base que já tá bom, uma estrutura boa e trabalha com modelos bons, praticamente não revisa mais spec. Quem, se alguém trabalha aqui com eh spec driven, comentem aqui. Vocês ainda revisam no detalhe a spec? Eu que tenho visto assim, a maioria das pessoas já não revisa mais. E o que que a gente começou a ver na indústria e principalmente as as pessoas que usavam o TLC Speck Driven, elas usavam, elas usam muito TC Speck Driven porque elas gostam muito da garantia de execução e de implementação que dá, mas elas já não revisam mais. Aí eu comecei a ver, pô,

40:11 mas esa aí a indústria tá movendo para outro outra fase que talvez a gente não precise de tanta coisa assim. Eu vou explicar um pouco sobre isso, tá? Mas ã ele tá criando os arquivos, vai criar o design e depois vai deixar implementar. Então gente, o que que acontece? A gente também fez bastante benchmark, tá? Tá aqui, ó. A gente fez benchmark. O como que é feito esse benchmark? A gente tem uma feature que é uma feature complexa, é integração com stripe. Uma feature é que levaria uns duas semanas para um ano e a gente fica reimplementando ela várias vezes, é, com os frameworks até até validar. E aí na versão dois, a

40:42 Telec Spec Driven, foi quando a gente começou o o benchmark, ela batia muito pouco os outros frameworks, principalmente na parte de qualidade. E aí a gente fez bastante alteração para ela na versão três ela ser bem melhor, principalmente que ela se autifica e esse tipo de coisa. Então eu garanto para vocês hoje que se vocês testarem qualquer framewor spec driven, testarem terceira spec driven, ela vai ser melhor. Não só porque a gente bastou bast bastante esforço, mas porque ela tem essa parte de autverificação. Tudo que ela faz, toda a estrutura dela é feita para se autovalidar. Ah, mas eu

41:13 tenho que usar a TLC Pack Driven? Não. Muita gente na própria empresa fez o próprio próprio framework da empresa baseado no nosso uso fundamentos. Então penso assim, cara, eu não tô vendendo para vocês até se pack dribl tô dizendo que essa é uma maneira confiável de fazer e são markds. Tu pode pegar, pegar essa skill e dizer, Cláudio, me explica como que funciona essa skill, como que eu faço isso no meu time pode fazer isso também, tá? Beleza? Cadê? Vamos lá, então. O que que tem no spec driven que a gente tem que ver? A spec que é bem similar aquela spec que tinha lá antes. Que que ela tem? O que tá fora de

41:44 escopo, questões abertas que foram confirmadas. Isso aqui é muito bom para logar. As histórias de usuários, mesma coisa. Given when then. Eu já vou botar a construir porque eu não quero perder muito tempo. Tot spec driven build. Hã, qual que é o nome da da feature? Mesma coisa. Abrir outro features inventory. Tá, vou deixar ele construir. Enquanto isso, eu vou voltar pra explicação que eu tava dando da TC specd. Cadê specs, features? Ó, então a gente tem uma spec, tá? Que que essa spec tem? Open questions, esse tipo de coisa. O given ali. Por que que isso aqui é importante, gente? As pessoas pensam, pá, mas por

42:17 que que tem que ter essa esse texto ali? Porque pensem o seguinte, é muito difícil tu representar lógicas de domínio de alguma forma, tá? Ó, ele me perguntou se eu quero usar sub agents. Por quê? Porque se eu for em tesqus, provavelmente tem várias fases, são 18 eh 18 fases. Eu vou explicar sobre isso depois. Vou dizer: “Ah, usa fazem line”. Tá? Eu vou voltar para não atrapalhar minha a minha explicação. Isso aqui é importante por quê? Toda a regra de negócio tá aqui. Isso aqui é parciável, tá? A skill, inclusive, se a gente

42:48 entrar nela aqui, barra TLC Packdriven, ela usa um pouco de determinismo e um pouco de não determinismo para fazer as coisas. O Felipe fez vári várias alterações onde ela valida os arquivos e ela extrai coisas usando Python em vez de deixar a IA extrair. Então tu consegue validar que tudo isso aqui foi implementado e validado porque tem uma parte determinística que extrai isso. Então para quem tá construindo skills, tentem misturar coisas determinísticas com não determinísticas porque te dão mais segurança. Então voltando até LC

43:19 spec driven, tu pode ter scripts dentro de uma skill. Aqui tem vários exemplos. Copia isso, gasta menos token, é mais seguro e te dá eh mais segurança, obviamente, né? Redundante. Então, spec é isso. Ah, o que que tem que ser feito? Aí a gente passa pra parte do design. Aqui normalmente é que a gente gasta mais tempo se tá numa arquitetura que precisa ajustar coisa, porque aqui tu tem uma visão do futuro de como a coisa vai ser. Aí tu vai lá e tal, é, valida, pô, que vai ser feito assim. tem um o job service, data model é importante, ah, error handling, risco e concerns. Então, tu tem um um snapshot de como a

43:52 coisa vai ser feita, tá? Aí depois tu tem as tasqus. As tes são uma aqui, ó, tá vendo? Tesk um. As tes são pequenas e atômicas pro a gente ir implementando uma a uma. E por que que isso é importante? Até a geraça, geração anterior de modelos, gente, a gente não só tinha que dar um input bom pro modelo, mas também tentar dar instruções claras de implementação para ele não pular as coisas. Eu usei muito o Composer, o modelo Composer 2.5 da do cursor. Ele é um modelo totalmente maluco assim, pô. Eu digo que ele é tipo

44:25 JNY assim, tipo, é o attention span dele é muito pequeno, então se dá uma coisa muito aberta para ele, ele faz metade da coisa. Então, quanto mais estruturada for a coisa, tu dizer: “Olha, tu tem que implementar isso, você tem que rodar um teste para provar isso”. Tá vendo? Uma tes que tem o quê? A tes que tem o que que tem que ser feito e como que ele valida. Então, aquela coisa só tá completa quando ele roda um gate determinístico, que é um teste, tá? Isso aqui a skill faz normalmente. E então isso aqui é muito útil pra gente lidar com esses modelos antigos. E outra coisa também é que isso dá uma estrutura de

44:58 implementação, mas tem um tradeoff, né? Pô, quando o modelo vai fazendo tesque por tesque, é mais lento, tá? Vocês estão vendo aqui, ele tá fazendo uma, ele tá provando que tá funcionando, vai fazer a outra e assim ele vai ficar rodando até implementar todas as tesqus. Cara, isso tem um efeito, né? Tem um efeito na na velocidade, basicamente é mais lento, gasta mais tokens porque ele roda um teste, ele para e tal, mas é necessário, era necessário até então pros modelos que a gente tava lidando, tá? Porque sem isso tu não tinha

45:29 segurança de que ia ser tudo feito e tal. Então são coisas necessárias. Outra coisa que a gente não faz aqui, mas o superpers que é o framework faz, é ele dá o código pronto pro tipo, uma fase de uma fase planeja e no próprio plano ele já bota o código de como vai ser e o outro modelo só implementa. Isso não é uma coisa boa também, tipo com os modelos evoluindo, o modelo que vai implementar, ele deveria saber implementar. O que que tu tem que dar para ele é um uma direção e depois validar. A gente vai vai ver sobre isso. Então, o que que o spec driven fazia? Então, pra gente recapitular uma spec,

46:02 revisar o design e depois tesques pro modelo seguir uma a uma e rodando teste e tal. Isso aqui, gente, muito bom. Então, para quem tá hoje trabalhando, ainda não tem acesso, pô, eu não consigo usar sempre um sonet para implementar, eh, eu não consigo usar um Grock para implementar, vocês ainda vão se beneficiar bastante desse modelo aqui de spec driven por um bom tempo. Ah, mas não, eu já tô que nem tu, pô. Eu consigo usar um Grock, consigo que nem o William, que o William usava Opos para planejar e implementar. Se tá nesse nível, essa estrutura que tá te tá te atrapalhando, porque esses modelos são

46:34 muito mais inteligentes para implementar. Eles conseguem fazer bet, eles conseguem implementar muito mais rápido. Isso aqui basicamente é fazer babysitting desses modelos. Eh, e eu vou explicar como a gente passa por isso, tá? Outra coisa interessante aqui que tem no TC6 pack driven que é importante é um log de decisões, tá? Então ele eh o que que o que que foi decidido e por isso aqui é muito bom para te ver tudo que aconteceu. Então para quem tá nessa situação de da tu tá fazendo aquele composição de modelo, tu usa um modelo bom para planejar, o modelo mais barato, tipo composer para implementar, usa o

47:05 composer? Cara, eu testei o composer, o meu a minha meta era fazer o composer entregar muita qualidade. E a última versão dele Spec Driven, eu consegui ele bater todos todos e os outros frameworks com o composer. Por quê? porque a gente botou bastante estrutura para ele. Então dá para te usar tranquilo, tá? E vou voltar aqui. Aí ele tá implementando, vai implementar tesca por tesc. Vou deixar ele implementando e eu vou voltar aqui. E outra coisa também que a gente tá chegando, que tá dificultando bastante é a coisa do spec driven, é o seguinte. A gente tem um fluxo de desenvolvimento a gente, onde a gente

47:38 tem um um PRD, um product require document, normalmente a gente tem um design doc, que é onde tá, eu vou mostrar depois, que é onde tá as decisões de design que tu compartilha com a empresa, com outras pessoas. Depois isso vira um projeto e para cada tesque, um design, um tesques. Aí vem a primeira coisa que as pessoas falam que é: “Tá, mas a spec é para as pessoas validarem?” Não, spec é pro agente. O design é para as pessoas validarem. Até dá, mas também é pro agente, tá? E a tesque do spec driven vira tesque no board? Não. Aquela tesque pequeninha é uma tesque pro

48:11 agente. Aí o que que vai no board? Aí cada pessoa faz de um jeito. Quem é mais avançado aqui, eu tenho quase certeza que se usa spec driven fez alguma maneira de juntar o spec driven com o resto do fluxo. Quiser mandar no chat o que que fez. Então, se teve uma ideia inicial, eh, parte disso eu também acreditei, eu não acreditava na parte de spec ser a fonte da verdade, mas eu acreditava que o task tracking gira e linear ia morrer. Então, o spec driven inicial se estruturou assim, não, tudo fica no repo, esquece o resto. Só que na verdade a indústria tá indo para um lado onde é o oposto. É, cada vez mais a

48:43 gente quer conseguir instrumentar agentes de qualquer parte. E a melhor maneira de fazer isso é a partir de um task tracking, um board, porque tu pode ter um fluxo totalmente automatizado que vem lá de um suporte ticket, cai num numa triagem, um agente faz triagem, ele joga para outro agente que implementa e nem chega no teu local. E aí isso dificulta bastante com o spec driven. Outra coisa foi eh spec fonte da verdade, cara, não se consolidou. Por quê? E assim, se alguém usa spec como fonte da verdade, funciona, sigam usando. Mas a realidade é que se tu não tá num time onde tu consegue controlar

49:14 que toda operação vai ser feita com spe driven, um que já tem o drift. O código é diferente da spec. O que acontece? A gente tem modelos extremamente inteligentes. E aí tu diz para ele, olha, essa aqui é spec. Aí ele olha o código é diferente. Aí ele começa a lupar num reasoning pensando sobre o que que é o certo. Tu tá atrapalhando o modelo. Cara, não faz isso. O que a gente tá fazendo, que eu vou mostrar no segundo bloco depois do almoço, é usando mais os os boards como fonte da verdade, deixando só decisões no repositório, ADRs e tal, tá? Isso é o caminho que a gente tá indo e eu vejo que a indústria

49:46 tá indo bastante. Ah, mas eu quero deixar e pack comitado. Pode deixar, tranquilo, sabe? Mas pensem que tem esses esses essas limitações e a gente vai seguir trabalhando aqui, tá? Então, a gente entendeu spec driven, o momento que tá spec driven. Eh, como eu quero garantir que a gente não fique sem tempo, eu vou já começar a próxima parte aqui. Vou fazer o seguinte. Vamos lá. Agora a gente, eu vou dizer o seguinte, abra uma work, crie uma. Pode falar, Dom. Teve uma coisa que gerou bastante dúvida, mas acho que só para parar as dúvidas por por hora. Ah, foi

50:18 quando tu falou ali de para modelos melhores não usar TC Spec Driven. Eh, tu vai explicar isso com mais detalhe depois. >> Vou chegar. Não, não vou, gente, eu vou dar, a gente vai, vocês vão sair daqui com todas as respostas, tá? De novo, eh, a TLC Speck Driven, eu tenho certeza, dos frameworks que eu conheço, ela é disparada melhor, a gente realmente, eu gastei uns R$ 30.000 R$ 1000 testando isso. Então eu confio no benemark. >> Gastou um quid usado. >> Mas o modelo de spec driven no geral eu vejo que ele chegou no limite principalmente pros modelos atuais e pra

50:50 estrutura que a gente tá indo. E eu vou dar duas opções para vocês, tá? Uma opção é para não ter uma grande breaking change para quem usa spec driven e outra é o meu fluxo, que é o que a gente tá começando a implementar na TLC, que eu acho que vai ser o talvez o que faça sentido. Aí vocês vão evoluindo como vocês acham que é melhor, tá >> boa? coisa vou dar uma po fal >> mandar pro pro pessoal ali. Ã, teve bastante gente questionando a metodologia ali usada para avaliação da Telec Driven e tal. Vou deixar o blog

51:21 post aqui que o Valdemar fez lá na comunidade. E de novo, gente, a gente não tá querendo vender para vocês, tipo, é open source aberto assim, tipo, não é, a gente não tá tentando convencer ninguém, usem isso e tal, mas tipo, é um bom trabalho feito pela comunidade, open source, é gratuito. E nesse arquivo tem todos os benchmarks ali que a gente fez mostrando o por que é melhor e tal. Então, tipo, testem por conta própria, veja se funciona para vocês, mas é open source assim, não custa nada para usar. [risadas] >> Sim, sim. Eu acho, eu acho isso engraçado. As pessoas questionam, cara,

51:52 o, é, tem todos os resultados abertos. As pessoas da comunidade, inclusive, já rodaram esse benchmark. E, gente, é um monte de MarkD que a maioria das pessoas fazem nas empresas é elas adaptam spec driven pro fluxo delas. Então, elas pegam a Telec Speck Driven, elas pegam outras que elas gostam, elas mandam pra agente e diz: “Olha, compara essas e me diz qual que é melhor usando fundamentos de LL Mejude sempre vai ser TLC spec driven, porque a gente implementa vários fundamentos”. Então tu pode pegar todas essas coisas, mandar para LM e perguntar, que às vezes parece, ah, tá vendendo a a skill, a gente não ganha nada com isso, a gente só compartilha com vocês o que a gente usa, tá? Mas

52:25 beleza. Então, eu falei que o modelo de spec driven ali tá chegando em limites por causa de da do caminho que a gente tá indo dos modelos. E aí, a primeira coisa que eu vou deixar para vocês é esse daqui. Cadê TLC? Que eu vou instalar aqui, ó. Em vez de TLC spec driven, a gente vai usar TLC spec. Opa, cadê spec link? Essa em vez de fazer uma Breaking Change na TC Speck Driven, porque ela, essa versão nova é mais para esses modelos melhores ainda, talvez daqui uns três meses a gente faça uma breaking change, essa é a versão nova que eu imagino para Telec Pack Driven, tá? Que é a TLC Spec. Ah, que vamos lá.

52:57 TC6 Packlin. Planeje o próximo item do Holdmap. Por que que eu abri uma work tree, gente? Uma work tree é basicamente não é só uma brand, tá vendo? Fit inventário. Ela não é só uma brint, ela é uma brand com uma cópia do código, ou seja, eu consigo trabalhar em duas coisas ao mesmo tempo sem elas se baterem. E como eu uso SK Lite, eu não tenho nada que interfira um no outro. Então eu posso deixar essa branch implementando o que tava implementando, ó, já tá no na verificação, tá vendo? E eu abro outra pra gente não gastar muito tempo e já começar a fazer outra coisa, tá? Aí depois o merge que se vire. Mas

53:29 eu não vou eu não vou entrar muito no merge aqui porque minha a minha ideia é mais mostrar para vocês o fluxo. Então a TLC Specan vocês vão ver que ela é bem mais le que a gente mudou na TLC Spec driven para TLC Spec é spec design virar uma coisa só e a gente não tem mais tesquagem final, ou seja, a gente deixa um modelo que é bom em fazer o trabalho dele de implementar, fazer a implementação do jeito que ele acha que é ideal e depois a gente valida bem. Então isso tem uma grande diferença, uma grande diferença,

53:59 tá? Eu vou mostrar para vocês. A TLC Speck Driven implementou as coisas todas e agora ele tá rodando um verifier aqui. Então é um verifier muito mais rígido do que aquela skill que a gente fez em house. Ele bate todos os critérios, ele bate os testes, ele marca linha por linha do que foi feito. Então ele não deixa escapar nada, ele é bem bem bem seguro e bem bom, tá? Por isso que eu digo, pô, se vocês usam modelos mais baratos para implementar, isso aqui é extremamente necessário. E agora eu vou voltar para esse cara aqui. Ele tá explorando o Code Base, tá? Então, quando tá acontecendo aquilo ali, vamos

54:31 seguir um pouco mais pra frente, tá? Depois é code review, tá? Beleza? Beleza. Deixa eu tá tá tudo alinhado. Hum, eu vou, vamos lá, tá? Ele vai criar o plano aqui. Aqui a gente também, gente, enquanto ele tá trabalhando, eh, a gente falou bastante dessa parte aqui de implementação, né? aqui, aqui dentro. Basicamente eu não entrei nessa parte ainda do projeto e tal, eu vou entrar nisso depois, tá? Que é uma coisa que as pessoas têm bastante dúvida, tá? Mas como tu estrutura o fluxo, de onde vem o projeto, como é que ele vira uma spec? A gente vai entrar nisso aí também. Eu tô tentando ir numa linha que seja bem

55:03 fácil vocês entenderem como as coisas vão indo e como a necessidade vai vindo, tá? Então a gente entendeu que tem a necessidade da gente montar esse harness em volta, tá? Que ele é uma combinação de coisas não determinísticas com coisas determinísticas e mais os sensores do nosso COD base que teste, todo esse tipo de coisa. E a gente também entendeu que o spec driven atual ainda é uma coisa que faz sentido, tá? E para muitos casos, mas a gente tá movendo já para não fazer. Mas simplesmente não usar nada não dá, porque os modelos ainda são não determinísticos e por mais que eles sejam bons, eles vão deixar alguma coisa

55:35 passar. Por que que eles deixam coisas passar? Porque quando dá uma missão pro modelo, pensa que a LM ela é uma máquina de probabilidade, tá calculando sempre a próxima coisa. E se a missão dela implementar, ela vai otimizar para implementar. Ela não vai tentar testar tanto. Ela vai tentar obviamente, mas vai deixar a coisa passar. Ela vai esquecer de rodar coisas. Então, quando tu abre outro para validar, a missão dele é aquela ali, pô. Ele vai achar. E o code review é bem similar, a gente vai entrar nisso também, tá? Tá ficando. E ah, outra coisa que a TC Spec Driven tem, ela tem teste de mutação, tá vendo? Ela tá fazendo isso aqui agora, tinha esquecido. Teste de mutação, o quê? Ela

56:08 pega alguns casos, ah, uma função, recebe um, recebe dois números e soma esses números. Ele vai tentar botar número negativo, fazer um monte de coisa, tá? Isso é bem, já vem bulin, você não tem que se preocupar com isso. Ó, tá fazendo ali teste de mutação. Dizem que é uma das coisas mais efetivas pr para testes com IAS. Ah, beleza, gente. Então, aqui a gente criou um plano, lembra? Telec que eu tô usando aqui. Qual que é a grande diferença do spec driven normal? Ah, ele criou dentro da outra fit. Putz, que ele pegou da brand. Tá, fazer o seguinte, não use a pasta inventor, crie o como já tava ali

56:43 a pasta, ele criou na mesma. Mas o plan ele é uma fusão da spec e do design. Por quê? Porque outra coisa que era bem difícil que eu via é que as pessoas não sabiam o que que que o que botar na tesque do board, no gira, sei lá o que for. E aí botava qualquer coisa, só um título, qualquer descrição. E aí quando ia planejar, elas começavam a planejar tudo de novo, pegando o contexto de um design doc e tal. e o board não se não servia para nada. Só que eu tenho visto que cada vez mais as pessoas usam o board. Então, a primeira coisa aqui que a gente fez nessa alteração é tu tem um plano que tu pode, esse plano pode virar

57:16 uma tesque e aí tu pode pegar de lá, por exemplo, ó, tu pode vir planejar tua coisa aqui, tu pode planejar tua coisa, ã, criar uma tesque, essa tesque vai para cá e aqui tu não vai mais fazer isso aqui, basicamente. Tu vai só fazer a implementação aqui, só implementa ela. Então, a primeira coisa que a gente mudou aqui foi isso. Ainda dá, essa estrutura ainda dá para comitar. Eh, se quiser comentar seus specs, pode comentar, mas ela também é feita para integrar melhor com o board, seja o liner, seja o que for que vocês usarem, tá? Então aqui só tem um plano. Depois eu vou deixar ele mover para um

57:46 diretório novo para vocês verem qual que é a diferença. Não, putz. Ah, tá. Ele continua o próximo item. Vamos lá. Vamos ver. Ele vai criar um plano agora direitinho. A gente vai most vai ver ali, ó. Verificação. Tá terminando. Ele escreve um validation. Esse aqui é o outro que tá rodando. Beleza. Então, deixa eu ver esse plano que ele vai criar agora para mim. Nada como a work tre, galera. Word resolve o problema de vocês. É paralelizar a coisa. A gente tá tá enquanto a TLC Spec Driven tá verificando o trabalho dela, eu tô aqui, ó. TC Speclink criou o plano. Crie o o checklist. É, ó, agora a gente vai

58:19 conseguir ver aqui, ó. Tem uma, a próxima item do roadmap é procurament, que é compras e vendas. Explica o explica o explica o problema, explica o que tá fora de escopo, explica as coisas que foram assumidas e não foram confirmadas. Então, era bom confirmar elas, eh, as histórias. E aqui tem todo o contexto de decisões que foram tomadas, o fluxo da arquitetura. Então, ah, entra por aquele screen, tem uma API, chega no post service, bom para humano revisar, data model para revisar também. Então agora eu tenho uma coisa que pode virar uma tesque, isso aqui já ajuda bastante. Tem uma coisa que pode virar uma tesque, não preciso depender só do da coisa no repositório, tá? Essa

58:52 foi a primeira mudança que a gente fez. Mudança grande foi baseado muito nos usos das pessoas. Agora ele vai criar os checks. Eh, a Telec Spect Driven tá rodando e a gente vai ver duas coisas paraa gente finalizar esse bloco antes da gente entrar no Não, eu vou uma coisa principal pra gente finalizar esse bloco e eu vou compartilhar mais algumas libs deixar esse cara aqui terminar. Tá escrevendo check. Deixa eu ver. Show. Ah, olha aqui que legal. O verifier falhou. Tá vendo, ó? Viu? Vocês viram ao vivo, gente? Mesmo numa coisa simples,

59:22 ele de 389 acceptas criterias. 38 deram certo e um falhou. E aí ele mandou de volta, olha, falhou um. Aí ele vai lá, arruma e manda rodar de novo. Então isso aí vocês não precisam se preocupar. Tipo, o próprio Harness tá fazendo isso. Hardness da skill. Então o que vocês fazerem é importante pensar nessas coisas. Quanto menos eu, humano, me envolver nesse loop de implementação, melhor, porque daí eu consigo fazer esse loop em qualquer lugar, não precisa ser na minha máquina. Essa é a coisa mais importante que vocês tm que entender. A coisa verificando a coisa. Aí esse outro aqui tá criando o checklist. Vamos

59:53 deixar ele criar o checklist. Criou, ó. Olha a diferença que a gente tinha antes. Antes a gente tinha uma spec que tinha tesques, design, spec, um monte de coisa. Agora a gente tem um plano basicamente que é uma tesque e os checks que são extrair desse plano as implementações e fazer um bater com cada um. Olha, get get API suppliers. Numa tabela vazia tem que responder 200 com arrei vazio. Como que tu prova isso? Rodando o teste. Então são vários checklists que ele vai ter que rodar no final. Ou seja, quanto ele ser spec, a

1:00:24 gente deixa o modelo implementado do jeito que ele achar melhor, paralelizar a coisa, fazer o que ele quiser e depois a gente roda um checklist forte nele e faz ele provar tudo. Basicamente isso. Então é extremamente mais econômico, é muito mais rápido e usa o modelo da melhor forma possível, tá? Então esse é o é é a grande aposta que eu vejo. Então vamos botar aqui TLC Spec. Vamos deixar ela implementando também. Vamos lá. TC SPC. Ah, não, tem que voltar naquela. Eu vou botar nesse cara aqui mesmo. Qual que é o erre fit inventory? Vamos lá. Hã, aqui spec TLC pack. Cadê? Vamos lá. Quero deixar ele implementando. Ó agora

1:01:02 que ele tá terminando de rodar. Deixa eu só ver. Vamos. Ah, ele tá fumado. Vou fazer aqui nesse daqui, depois eu volto nisso. Vai TC pack. Implemento, esse plano aqui. Então, vou deixar ela implementando esse cara aqui. Eh, mais uma coisa que eu quero mostrar para vocês nesse bloco antes da gente finalizar que é o seguinte. Ah, aqui a gente terminou, tá? Esse cara, ó, tá escrevendo validation report. Então, o que que eu faço? Terminei uma feature, tá? Pô, ela ela rodou o meu pipeline, seja TL6 Pack Driven, seja TL6 Pack LAN.

1:01:33 Essa aqui é TL6 Pack Driven. Ele verificou que tá tudo feito. Pô, o que que falta agora? Antes de chegar em mim, eu vou andar revisar. Mas antes disso, eu boto mais uma camada de code review. O que que entra nessa camada de code review? Entra revisão de, pô, eh, a arquitetura mudou, entrou algo novo na arquitetura, algum padrão novo, tem alguma regressão, o agente tocou em algo que não era relacionado a essa feature, tudo isso faz parte do review final, que não tem muita relação com a skill em si, tá? Então, como que a gente faz isso? A gente tem uma skill também de de code review. Vamos TLC. Eu vou instalar ela

1:02:06 aqui. Tem duas skills, tá? Tem uma, eu vou usar essa daqui que ela é mais rápida de rodar, mas tem, opa, vamos usar essa do essa do Felipe que é nova aqui. Então essa skin uma skill de code review. Vamos botar aqui. Ah, use a skill de dud para validar as alterações feitas aqui. Não faça nenhuma integração com Git. Eh, essa skill aqui é uma skill que vocês vão plugar pipeline de vocês, algo assim. para fazer revisão do P request, tá? Então, como que funciona uma revisão com IA? Pensa o seguinte, a gente viu um pouco ali sobre sub agents,

1:02:41 mas qual que é a ideia? A gente sabe que cada sub agent é bom em uma coisa. Então tu inicia, primeira coisa de de code review com, tu inicia um sub agent para cada coisa que é importante paraa tua pro teu code base. No normalmente o que a gente usa nos nossos é um para segurança, um para requirements, um para garantir que tudo foi testado ou que tem testes, um para arquitetura, garantir que os padrões de arquitetura foram seguidos. O que eu gosto de validar também é que não foi adicionado nada na arquitetura que não seja conhecido, se foi me avisar, porque a IA tem muita uma coisa de querer abstrair demais e às

1:03:11 vezes elas trazem design patterns que eu nem sei que é, cara. Não bota sem me avisar. Regressão e alucinação. Essa daqui extremamente importante. Porque que acontece? Principalmente modelos eh versões anteriores, às vezes eles estavam passando por um arquivo que não tinha relação nenhuma. Com a mudança deles, eles alteravam algo. Já vi, pô, deletar fila, mexer em estrutura de banco de dados. Então esse é da regressão e alucinação. Ela olha para essas coisas e aponta: “Olha, isso aqui não tem, eu acho que não tem relação com essa, com essa que tu tá fazendo. E performance, esses são os que a gente faz, tá? Eh, essa skill eu vou, eu confesso para vocês, essa skill do

1:03:42 Felipe, ela é nova, que eu tô usando K jude. A gente tinha uma que era o pior review, que é o que a gente usa no time também. Eu vou deixar ela para vocês, eh, depois eu dou uma olhada, mas essa daqui é baseada nessa skill de PR review que eu vou deixar para vocês. Essa do Felipe é uma nova que a gente tá testando, que ela tem mais, ela tem um harness melhor, porque tu consegue rodar elas várias vezes e ela não fica apontando coisas infinitamente. Ela aponta uma vez, valida aquelas coisas e tal. Então a gente vai provavelmente mover para essa dedude. Ã, mas o slide que eu tô mostrando da outra que eu vou deixar para vocês também. Vocês podem juntar as duas, ó. Que que ela faz? Essa

1:04:15 Deud tem que provar evidência. Vamos ver. Ela marca as coisas como blocker, should fix, nich. Isso é importante também porque às vezes o modelo fica botando um monte de coisa. Ah, ela tem integração com git e aí tem várias e camadas determinísticas também para garantir as coisas. Então vocês podem pegar essa skill, eh, e olhar ela depois como ela funciona. E são bons padrões para vocês botarem no code redw de vocês, tá? Ó, aqui ele tá escrevendo um finds. Depois a gente vai ver o que que ele achou. Então, essa é a camada final. Aí, onde entra o humano? Pô, eu passei por todas essas camadas de review aqui.

1:04:49 Ou a gente achou o o aí achou coisas. Eu vou aplicar essas coisas que ela achou. E aí eu vou dar uma olhada o que que eu faço normalmente eu olho as partes que eu sei que são críticas, tem lógica de negócio, decisões críticas de arquitetura, mas vocês vão ver na amanhã, no final da tarde que as coisas no nosso code base, pô, o meu review hoje em dia é muito rápido. Eh, piar de 50, mais de 50 linhas, 10, 15 minutos eu já revisei ele, porque a gente tem uma grande automação, tá? Então, ó, ele fez uma revisão e disse que tá safe pr

1:05:19 provar. Nesse caso aqui tem duas coisas que são pequenas, ó. Quantidade input allow zero, mas a API não não permite. Ah, error alert sits below the three forms. Não sei o que que é isso, mas coisa simples de front end que ele achou aqui, tá? Então, nesse caso, a gente tá safe aqui nesse nesse caso aqui. Ah, duas skills que eu vou vou deixar para vocês que eu não vou ter tempo de mostrar uma skill em projeto que é essa daqui. Outra coisa, por que que eu vou deixar essas skills para vocês, para vocês testarem? Pensa o seguinte, a gente falou um monte de harness, pmmd, skills, mas o que que a gente faz quando

1:05:52 essas coisas ficam velhas? Como a gente sabe que não são mais necessárias? Como eu falei, os os o vou terminar aqui essa essa linha de pensamento, os modelos novos, eles são muito inteligentes, mas eles não precisam de um monte de skills que a gente tem mais, um monte de agentes. Ponmd, mas eles precisam de alguns. Como que a gente sabe quais são esses? Aí vou deixar uma skill para vocês darem uma olhada nisso, mas pode falar da M. >> Atendendo aos pedidos aí, não sei, não precisa ser agora, mas o pessoal pediu, falaram que tem vários JZ com attention spam de 3 minutos aqui, geração TikTok que falaram no chat que eles precisam de um recap rápido antes da gente do para

1:06:26 almoço de tudo que foi feito. Sei se já tava planejado, mas se puder fazer esse recap pro para J, o pessoal agradece. >> Boa, boa. Vou d uma repassada. É, então vou deixar pr vocês essa skill aqui, nossa, para vocês validarem aqui. Harness e val. Essa skill vai ficar para vocês validarem a utilidade das coisas que vocês têm. Ah, meu de espant, as coisas estão ali todas fazem sentido, algumas podem ser deletadas. Tipo, ele tem três níveis, tá? O nível A, ele valida que ah, as estruturas ainda existem. Os comandos que ele diz aqui,

1:07:00 por exemplo, os comandos que estão aqui nesse agents.md, eles são válidos quando tem comandos. Ah, se ele linka um arquivo, aquele arquivo ainda existe. Então esse é o seguro. Aí depois ele tem outro, dois níveis de validação mais B e C. Aí ele usa um sub agent, ele analisa as skills, ele vê se para aquele modelo que tá validando aquilo ali, aquela instrução é redundante ou não. Então esse é sensível ao modelo, tá? Então peguem, se vocês vão rodar esse, além de gastar tokens, rodem com os modelos que vocês usam no dia a dia para vocês verem o que que nas skills e agm de vocês tá começando a ficar redundante, mas vão

1:07:34 tirando devagarzinho, tá? É só para dar uma uma ajuda para vocês. Outro que eu vou deixar para vocês é esse cara aqui, Harness Score, que é do Fernando Paladini da comunidade. Vou deixar o link aqui, já vou até mandar o link para vocês. Esse daqui ele valida, ele valida se a tua estrutura de harness está boa. Tu tem skills, tem guides e tal, ele desce em repositórios. Então comecem pro hardness score, depois vão pro hardness e para avaliar a estrutura de vocês. Beleza? Então pra gente finalizar esse bloco, recapitulação rápida. Eu vou

1:08:05 deixar esse pack para vocês também. Tá tudos aqui no nosso aqui. Tá todas aqui, gente. Ã, depois ficar vai todos os links. Vamos lá. Eh, eu uso o cursor aqui, tá, galera? Recapitulação. O que que a gente fez? A gente começou esse sistema que era um RPzinho simples, tá? No roadmap aqui. Como é que ele tá, na verdade? Deixa eu ver. Vamos pegar aqui qual usuário e senha do admin. Eh, a gente pegou, fez um roadmap aqui simples e para cada item desse roadmap de um RP, fazer um house, fazer autenticação, autorização, job, inventário, a gente

1:08:36 foi implementando seguindo algum approach. A gente começou sem nada, tá? A gente começou sem nada que foi, cadê? Vamos ver. É, criou o roadmap. Aí nesse item aqui, a gente implementou sem nada, só dis pra gente implementar. A gente entendeu que a limitação aqui é que a gente não sabe o que vai ser feito, a gente não consegue validar. Depois a gente foi pro próximo nível, aonde a gente implementou usando o plan mode, que já nos dá uma previsão de como as coisas vão ser. Depois a gente fez uma skill que ela cria uma spec e ela valida a coisa. A gente viu que, pô, agora a gente consegue prever o que vai

1:09:08 acontecer e consegue validar o que vai ser feito, mas a estrutura dela era muito simples. Então, cadê? Se a gente for em spec, em docs, ó, a estrutura dela era simples, não cobria bastante coisa. E aí a gente foi para uma estrutura mais robusta, que é qual? Pô, vamos instalar Speck Driven. A gente instalou a skill de Speck Driven. Cadê? É, tá aqui, ó. Isso aí. A gente foi para spec Driven. A gente entendeu que, pô, Speck Driven dá nos dá toda essa estrutura. A gente tem uma uma spec, a gente tem um design que a gente consegue revisar, a gente consegue ajustar as coisas, a gente consegue mandar

1:09:38 implementar. A gente tem um harness muito forte pra gente seguir passo a passo, tá? Pra gente seguir passo a passo com tescs. Só que a gente viu também que isso aqui tá chegando no limite pros modelos atuais. E aí, qual que é o passo depois disso? É a gente parar de fazer babysitting nos modelos e tirar o melhor deles, deixar eles implementar mais validar. Aí a gente entrou na TLC Specan que vai ser a nossa nova versão da skill de spec driven, tá? E por mais que eu esteja falando da skill, o que importa aqui é o fundamento

1:10:08 que mudou. Pensa o que que mudou aqui. Em vez da gente ter uma spec, um design e as tesques, agora a gente tem um plano que envolve eh a spec e o design direto ao ponto. E depois a gente tem um checklist que um subente vai lá e roda contra a implementação. Ó, tá vendo? Ele tá fazendo isso aqui agora. Isso que é a coisa. Então se vocês t muita gente que tá aqui já é mais avançado, tem a própria skill da empresa e tal, que que vocês vão fazer com essas coisas que eu trouxe para vocês? Vocês vão usar isso como base para melhorar a estrutura de

1:10:38 vocês, melhorar as skills de vocês, usar os fundamentos que até que a TLC Packlin implementa para melhorar a estrutura de vocês. E quando que vocês vão usar essa skill? Só se vocês têm acesso a modelos bons, tá? Porque você botar num modelo, tipo, bota num composer, que é um modelo que não segue bem regra, ele não vai rodar os cheques depois. Aí tu tem um problema, vai implementar de qualquer jeito, não vai rodar os cheques, tu não quer fazer isso, tá? Então tu tem que saber por quais modelos antió. Então é muito mais começar a pensar já no futuro pr onde as coisas estão indo e ajustar as skills de vocês. Então para resumir, spec driven ainda é útil, rodando com os modelos mais baratos, precisa de muito

1:11:13 ajuste. TC Pack Lin é é o caminho para rodar com modelos melhores. E aí a gente finaliza esse bloco.