App do zero com IA: harness, subagents, spec-driven, novas skills e workflows

Autoria: Waldemar Neto - Dev Lab · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: português

Vídeo original: App do Zero com IA: Harness, Sub Agents, Spec-Driven, Novas Skills e Workflows · Canal: Waldemar Neto - Dev Lab · 1:11:13 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA

Resumo

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.

Pontos-chave

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.

Capítulos

Início	Capítulo	Resumo
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.

Citações

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

Conceitos e entidades

Harness (conceito): Conjunto de ferramentas, instruções, estrutura de código e mecanismos de validação que orientam e dão feedback ao agent.
plan mode (conceito): Modo de trabalho em que o agent prepara um plano para revisão antes de implementar uma mudança.
subagent (conceito): Agent auxiliar que recebe uma tarefa específica, como explorar uma parte do repositório ou revisar uma implementação.
Spec-driven development (conceito): Abordagem que usa especificações e, em algumas variantes, decisões de design e tarefas para orientar a implementação e sua validação.
Cursor (ferramenta): Ferramenta de desenvolvimento com IA usada no vídeo para interagir com agents, modelos e o repositório.
Playwright (ferramenta): Ferramenta de automação de navegador usada para testar interfaces e percorrer fluxos de uma aplicação.
MCP (conceito): Protocolo usado para conectar o agent a ferramentas, como a automação de navegador demonstrada no vídeo.
Agent Skills (repo): Repositório open source apresentado como catálogo de skills, incluindo uma implementação de spec-driven.
TLC Spec Driven (ferramenta): Skill de spec-driven development apresentada como um fluxo estruturado que inclui especificação, design, tarefas e verificação.
TLC Spec (ferramenta): Fluxo apresentado como uma alternativa mais enxuta que combina spec e design em um plano e usa um checklist para verificar a implementação.
Harness e Val (ferramenta): Skill apresentada para avaliar se as instruções e estruturas do harness continuam válidas ou se podem estar redundantes para um modelo.
Harness Score (ferramenta): Ferramenta mencionada para avaliar a estrutura de harness de um projeto.
Grok (modelo): Modelo usado durante a demonstração para planejar e implementar funcionalidades.
Waldemar Neto (pessoa): Apresentador do vídeo e autor das práticas e skills demonstradas.

Tradução completa (pt-BR)

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

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

01:07 aqui, bem, bem simples. Acabei de começar, tá? Então, tem só um app, uma API, que é o backend. Tem um service, item service, e uma aplicação web feita com React, bem simples, para vocês acompanharem o que estou fazendo, tá? Muita gente pediu nos outros vídeos: “Ah, eu quero que vocês façam do zero.” Então, a gente vai fazendo do zero e entendendo as coisas juntos. Beleza? Então, vou começar pelo seguinte: o último lugar onde trabalhei era uma empresa de ERP nos

01:38 Estados Unidos. ERP é um domínio complexo, né? Tinha controle de estoque e um monte de coisas. A gente vai trabalhar mais ou menos nisso. A primeira coisa que vou fazer aqui é dar um prompt. E aqui estou usando o Cursor, tá? Na verdade, estou usando a janela de agents; uso mais essa janela aqui. Vocês veem que o codebase fica em segundo plano e o código fica em primeiro plano. Aqui estou na minha janela de agente, usando o Grok, e vou usar o 4.6 Fast. Como é um workshop, quero que as coisas andem rápido, tá? Então, vou usar o Fast

02:11 aqui. Mesmo assim, o Fast é mais barato que um Opus. Então, vale muito a pena. A primeira coisa que vou dizer aqui é: “Pesquise quais módulos são necessários para termos um ERP completo e funcional, com controle de estoque, warehouses, obras, alocação de staff, administrador e operador.” Isso não é algo que vocês vão fazer no dia a dia, tá, gente? Só que estou fazendo isso para termos um arquivo de roadmap, que é o que vamos trabalhar. E aí, em cada ciclo do roadmap, vamos usar alguma técnica diferente. Adam, olha, se tu precisar falar alguma coisa, não vou ver o chat por um tempo, tá? Tu pode me interromper. Não tem nada de

02:43 especial, tá, gente? Enfim, é só um começo mesmo, só para vocês acompanharem comigo o que está acontecendo. Então, ele vai fazer uma busca na internet sobre coisas similares, e a gente vai criar um roadmap. Enquanto isso, o que tenho neste repositório, tá? Tenho um agents.md. O que é o agents.md? É uma coisa que a gente chama de rules: coisas que sempre carregam na context window. Se eu descer aqui na context window, olha o que está nela. Lembra que a gente paga por tokens nos loops da context window. Cada vez que mando algo para o modelo e recebo a resposta, estou pagando por isso. Então, aqui tenho meu system prompt, o

03:16 system prompt do Cursor, as tools, que são coisas como “ler arquivo” e chamar o MCP, esse tipo de coisa. E aqui ponho as rules e as skills. Então, aqui ele me deu os módulos necessários: identidade, autorização, identificação, catálogo, warehouse, inventário, tarefas, equipe, atribuição, procurement. OK. Crie um roadmap.md. Ah, então vou criar isso aqui. Estava explicando o agents.md. A gente fez uma live sobre isso. Quem não assistiu àquela live e tem dúvidas sobre o que é um agents.md e como criar um .md,

03:50 bom, assista à live. Mas, resumindo, o que ele é? São rules, coisas que quero que o agente sempre carregue. Aqui vou colocar o mínimo possível, tá? Só coisas que o modelo não vai entender sozinho. Como falei, os modelos evoluíram bastante. Esta última geração de modelos, além de ser muito inteligente, é muito boa em usar tools. Ou seja, é muito boa em buscar uma skill para usar e em saber chamar o MCP. É muito inteligente. Então, não preciso colocar tanta coisa no agents.md. O que coloquei aqui? Principalmente coisas que ele não saberia, como é feita a

04:21 injeção de dependência neste repositório. Depois que eu tiver bastante código feito sempre do mesmo jeito, posso remover isso, porque o código é o melhor exemplo, tá? E a minha estratégia de teste: digo que service tem que sempre ter testes unitários, porque tem lógica de domínio. Rota e banco, tu testa indiretamente com testes de integração. O repositório, sozinho, não prova nada; ele só é testado com teste end-to-end, tá? E a aplicação web não tem testes; vou explicar depois o motivo. Então, esse é o básico de que preciso para começar a trabalhar neste repositório. Agora vou colocar mais uma coisa,

04:53 tá, gente? Mais uma coisa importante. Quero que, sempre que eu implementar algo que toque no frontend, o próprio agente teste aquilo para ver se deu certo, tá? Então, vou dizer o seguinte: “Coloque uma regra no agents.md para sempre validar uma implementação no final, usando Playwright quando ela tocar nas telas.” O que estou dizendo aqui? Estou dizendo para ele usar o meu Playwright. Quem não sabe o

05:26 que é o Playwright, vou mostrar para vocês. Aqui, em Customize, tenho meus MCPs. Um deles é o Playwright. Playwright é bem famoso, como o Cypress. É bem famoso para automação de testes end-to-end no frontend, tá? A pessoa entra, navega e clica em tudo. O MCP basicamente me permite fazer essas coisas e permite que o agente também as faça. Ele tem várias tools que pode usar para encontrar um navegador, abrir o navegador, clicar nas coisas e tal. Então, basicamente, dou isso ao agente para ele fazer e digo: “Olha, cara,

05:57 tu vai ter que provar o teu trabalho fazendo isso, tá?” Olha, está aqui, e assim por diante. E aí ele colocou uma regra. Isso quer dizer que todo agente que eu abrir, toda janela de agente que eu abrir, vai saber disso e vai fazer. Espero que faça, tá? Então, o que temos agora? Temos um roadmap que vamos seguir. Fiz isso, de novo, só para não precisar ficar pensando na próxima coisa. Temos o roadmap, e vou colocar mais uma coisa aqui, que é o seguinte: para vocês irem entendendo como a coisa funciona com IA, tá?

06:27 Tem muita coisa que vocês vão ter que ir dizendo, basicamente. Então, mantenho H pressionado aqui. “Every time a roadmap item is completed. Mark it as done in the roadmap.” Então, só coloquei isso aqui: sempre que eu implementar alguma coisa do roadmap, ele vai lá e marca aquele item do roadmap como concluído, tá? Só para a gente saber como estamos progredindo. Então, vamos começar. Primeira coisa: qual é o próximo item? O item do roadmap. Vamos ver qual

07:00 que é o próximo item do meu roadmap aqui. Ah, que é o estoque do warehouse, eu acho, porque eu só tenho um item no momento. Estoque do warehouse. Beleza? Então, vamos lá. Qual é a maneira mais fácil de implementar? É, OK, implemente isso. Implo. Vou fazer do jeito mais básico, para entendermos quais são as limitações disso. Por quê? Porque estamos num momento em que as pessoas têm muitas dúvidas, né? Principalmente: “Ah, spec-driven é waterfall”, “não sei o quê”. Todas essas coisas a gente precisa entender em nível fundamental, e vamos entendê-las aqui para vocês conseguirem compreender e ter respostas para essas questões. Ah, o que

07:32 é loop engineer? O que é graphic engineer? Todo esse tipo de coisa. A gente vai chegar lá quando surgir a necessidade. Então, eu dei um prompt para construir, tá? Ou vamos buscar os arquivos, que eu vou explicando. Estou usando reasoning no nível high aqui, estão vendo? E high. O que isso quer dizer? Quer dizer que ele vai pensar mais. Se eu clicar aqui e olhar, ele me mostra os arquivos que leu e tudo em que está pensando. Então, ele fica num loop de pensamento, gasta mais tokens, mas isso é importante quando precisa pensar bastante, principalmente na fase de planejamento, a que vamos chegar depois, tá? É bem importante. Gosto de usar bastante reasoning high nas fases de planejamento. Eu uso

08:05 reasoning high. Para implementar, normalmente uso medium. [limpando a garganta] Mas hoje em dia, com o Grok que estou usando aqui, ó, antes eu usava um modelo bom para planejar e um modelo mais ou menos para implementar, tipo Opus para planejar e Sonnet para implementar. Hoje em dia, o Grok faz tudo. É barato, barato comparado com os outros, rápido, bom. Cara, manda ver, faz o que quiser. Mas às vezes eu uso, tá? Às vezes uso Opus quando preciso pensar muito em algumas coisas. Acho que o reasoning do Opus é melhor, as conclusões dele são melhores, mas realmente

08:37 ele é bem mais caro. E no Cursor também tenho o Grok no meu plano, o que me ajuda bastante. Então, ó, ele pesquisou os arquivos e está começando a alterá-los, tá? Foi lá: vai alterar tudo o que precisa alterar. Também vai colocar isso no meu CONTEXT.md, que não mostrei para vocês, mas é um arquivo que gosto bastante de ter, tá, gente? Inclusive, tem uma skill que vou deixar para vocês depois, que é a de context map. Basicamente, os itens do domínio, cada coisa nova que coloco no meu domínio, ele coloca nesse arquivo. Ah, o que é um item? O que é um catálogo? O que é uma

09:07 unidade? O que é um warehouse? O que é um estoque? Porque, assim, a gente não precisa pensar de novo no que é essa coisa, sabe? Ah, o que é um warehouse? É onde os itens e as quantidades ficam, tá? E o que ele não é aqui? O que eu não quero ter? Não quero ter estoque num catálogo, por exemplo. O estoque tem que ficar no warehouse. Então, são regras da minha arquitetura que também é bem importante ter. Gosto bastante disso. Então, ele vai implementar essa parte aqui, ó. Já está implementando um teste e tal, e vai atualizar o roadmap. Vamos ver. Cadê? Ele vai atualizar aqui agora, ó. Dentro do catálogo. Deve chegar nesse cara aqui

09:39 depois. Aí, vocês viram o que eu fiz para isso acontecer. Basicamente, escrevi aqui. Então, qual é a ideia que vocês tiram disso? A primeira coisa: os modelos estão cada vez melhores e mais confiáveis. Eles vão seguir muitas das instruções. E a ideia é a seguinte: provavelmente, no nosso workshop do início do ano que vem, vou dizer para vocês: “Cara, quase não usem skills”, porque vamos ter técnicas para fazer o modelo seguir as instruções. Muito bem. Hoje em dia a gente ainda precisa usar. Vou explicar para vocês depois, mas só de eu colocar isso aqui, as telas e o roadmap, ele já

10:12 atualizou o roadmap para mim aqui, ó: o warehouse está concluído e tal. Então, não preciso me preocupar muito com essas coisas. Vou colocando essas regras naquele arquivo ali. Ah, agora ele vai fazer um teste e tal. É isso. Beleza. Outra coisa que vou conferir aqui, deixa eu ver. Vou atualizar. Ó, agora ele vai iniciar a API web. Quero deixar aberta aqui para vocês verem, ó. Abriu a web. E meu site ainda está bem feio, gente. Está bem feio. Vamos arrumar tudo isso aqui juntos, tá? Mas olha ali: entrou e testou. Então, outra coisa muito importante, principalmente para quem trabalha com frontend, tá? A

10:46 IA, sem ver a coisa, quase não tem como fazer um bom trabalho nem validar se ficou bom. Os modelos são muito bons com imagens, muito bons com imagens, mas são muito ruins em interpretar algo visual sem ter a imagem. Se você está criando um componente de frontend, quem é de frontend deve saber disso. Manda no chat. Você manda uma coisa do Figma, uma parada assim, e acha: “Ah, vai ficar pixel perfect”. Não fica, tá ligado? Aí você manda uma imagem, e ele consegue chegar perto daquilo. Então, Playwright é, pô, para quem trabalha com frontend. Mas agora vem outro problema: “Pô, mas aí eu crio

11:20 testes com Playwright e faço commit desses testes, cara?”. Aí é outra conversa. Sugiro ter testes para alguns wrappers, mas manter testes end-to-end é caro, lento e desafiador. Então, sugiro tomar cuidado com essa parte, mas usar para validar é bem importante, tá? Porque eu venho aqui, ele entrou e testou tudo o que fez. Depois ele vai me dizer que deu certo. Então, uso bastante isso, tá? Gasta tokens, gasta um pouco mais de tokens, obviamente, mas evita retrabalho, né? Se eu tivesse que entrar e, como humano, testar tudo e deixar as coisas passarem, também gastaria o meu tempo

11:54 também. Aí depende de quando vocês estão disponíveis para gastar esse tempo. Então, ó, ele vai terminar de testar aqui. >> Acho que, se puder, faz uma recapitulação rápida do que você fez até agora, porque está basicamente focando em testar a capacidade do modelo usando poucas coisas como guia, né? Porque tem gente perguntando quais skills está usando e tal. Se puder repassar isso. >> Boa, gente. Não estou usando skill nenhuma aqui, tá? Estou usando o básico do básico. Começamos pelo básico do básico. Dei um prompt para criar o estoque do warehouse, tá? E a única coisa a mais que dei foram instruções no meu AGENTS.md, nas regras. Dizer: “Olha, sempre que você mexer numa tela, tem que testar com Playwright, abrir e fazer isso aqui que mostrei. Vai lá, testa as telas com Playwright. E temos o roadmap do que vamos fazer, que está atualizado.” Beleza? Dei um prompt aqui, dizendo: “Ó, constrói”. Agora construí isso daqui, tá? Dei um prompt e construí. Qual é o problema agora? Qual é o problema que tenho agora nas mãos? Vamos ver aqui. Vou abrir o chat, mano. E qual é o problema dessas coisas que

12:26 eu fiz? Code review, arquitetura, regressões de vibe coding. Exato. Gente, eu não sei, não sabia o que ia ser feito. E agora, para validar a resposta, como faço? Como valido se isso aqui ficou bom? Vou ter que olhar mudança por mudança. E como sei se ele testou o que tinha que testar? Como sei se todas as regras de negócio foram implementadas? Cara, eu não sei. Sabe? Como não é uma mudança grande, imagino que praticamente tudo tenha sido feito. Mas vocês não vão fazer isso em produção, tá? Vou comentar isso daqui. Ah, só um minuto. Então, pô, em

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

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

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

14:33 ele fez aqui? Abriu subagents para explorar. O que são subagents, gente? Só para relembrar: pensem nos subagents como se fossem threads. Isso é muito importante para não poluir a context window. Aqui ele abriu dois, que exploraram duas coisas. Quais são os padrões da API? Ah, quais são os padrões? Como funciona a web? Exploraram as duas coisas e trouxeram só uma resposta para o agente principal, tá? Assim, o agente principal consegue tomar uma decisão. Eu não precisei fazer nada para isso, tá? As ferramentas

15:05 novas, Cursor, Claude Code e tal, e os modelos inclusive são inteligentes e sabem: “Olha, isso aqui, eu tenho que fazer uma varredura no codebase. Não vou fazer isso na minha context window principal porque ela é limitada”. O Grok nem tem uma context window de 1 milhão. A janela máxima dele é de 250.000 tokens. Então não vou encher esta janela aqui. Vamos ver. Fase dois é user role. Blá-blá-blá. O que entra nesse slide? A role fica como campo de user, não como uma tabela própria. Só cadastro. Cadastro mais login. Vamos colocar aqui: cadastro, cadastro mais login. Legal. É isso aí. É isso que ele vai fazer. Essa

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

16:08 Cursor e Claude Code já abrem o navegador. Por que usar o Playwright? Porque o Playwright não depende da ferramenta que você vai usar, né? Está em um time em que todo mundo usa o Cursor, por exemplo, e você testou o navegador e funcionou bem? Pode usar, mas eu tenho uma experiência muito boa com o Playwright e ele basicamente tem o MCP, funciona em qualquer lugar. Então, deixo aqui minha dica: o Playwright ainda é muito útil para mim. Então, tá, agora a gente tem um plano. Pô, o plano já me permite revisar o que vai ser feito. O plano identificou a linguagem, explicou aqui o domínio, o que vai ser feito, e

16:41 mostrou também as rotas que vão entrar e o que vai ser alterado. O formato da API, os testes que vão ser feitos. Então, ter um plano, uma spec, não é waterfall, como o pessoal está dizendo, porque basicamente é pegar um bloco de trabalho e usar o agente para planejar esse bloco antes de escrever código. Lembra da primeira implementação que a gente fez? Corrigir aquilo lá é muito mais difícil, porque você não sabe exatamente o que ia ser feito nem exatamente o que pediu.

17:12 Então, você vai ter que ficar fazendo loop com a gente até corrigir e gastando tokens. É muito melhor fazer loop com o agente numa especificação, porque basicamente é como se você estivesse implementando a coisa sem implementá-la, do que fazer loop com um agente em cima de um código já feito, tá? Então, o plan mode ajuda nisso. Todas as ferramentas têm plan mode por padrão, tá? E aqui, ó, beleza? Tem algumas coisas que vou revisar, então não vou revisar em detalhe aqui, até porque é um código de teste, mas, na vida real, faço uma boa revisão. Mas vocês vão ver quando eu fizer o nosso código de verdade, de produção, um código que já está bem estruturado e que já tem um bom harness, que eu vou

17:44 explicar. Normalmente, com um bom modelo, as coisas saem muito bem em uma situação, em um nível de detalhe bem bom. Mas, claro, se for um código legado em que você ainda está adotando IA, toda vez que planejar vai ter que ver o que ficou pendente, o que ele errou, corrigir e também ajustar seu MD ou skill para ele não errar mais. É um processo de longo prazo, tá? Mas aqui temos a primeira coisa, beleza? Pô, fiz isso aqui. Aqui, olha, pensem no seguinte: esse agente aqui — outra coisa que vamos ver agora — pensou em um monte de coisas para poder planejar isso. E aqui tem um

18:16 resumo do que tem que ser feito. Na vida real, provavelmente essa context window já estaria em 60%, 70%. Não tem por que construir nessa janela e fazer com que ela seja compactada. Vou explicar isso. É muito mais fácil pegar esse plano aqui, ó. Vou pegar esse plano e dizer o seguinte: “Pô, constrói isso aqui em outro agente com uma context window zerada”. Então, basicamente, em um agente eu fiz uma busca e, no outro, vou construir a coisa com uma context window zerada. E por que isso é importante, gente? Enquanto ele constrói agora, vou voltar aqui. Por que

18:48 isso é importante? Porque hoje temos context windows ainda maiores, tá? Temos context windows de 300.000 tokens para quem usa Opus, dois níveis, né? Normalmente, há um que é o seguro: a Anthropic e a OpenAI dizem que é seguro trabalhar dentro dessa janela. Quando chega a 1 milhão, a responsabilidade é sua. E há dados comprovados de que, quanto maior a context window, mais a qualidade cai, tá? Então, tenho que cuidar da context window para manter a qualidade do output boa. E a gente gosta de dizer que, pô, cara, até uns 40% da janela é seguro. Com 60%, cara, dá para seguir tranquilo. Acima de 60%, você vai começar a pagar um pouco em qualidade. Ah, mas é extremamente preocupante. Depende do contexto, né? Depende do contexto em dois sentidos, né? Depende do contexto, amor. É, se você tem, por exemplo, um plano, um plano e depois tem uma maneira de verificar

19:19 científico. Quanto maior a context window, tá vendo? Cada 100.000 tokens a mais, basicamente, mais a qualidade cai. Então vocês têm que cuidar da context window para manter a qualidade do output boa. E a gente gosta de dizer que, pô, cara, em torno de 40% da janela é seguro. Com 60%, cara, dá para ir tranquilo. Acima de 60%, tu vai começar a pagar um pouco em qualidade. Ah, mas é extremamente preocupante. Depende do contexto, né? Depende do contexto em dois sentidos, né? Depende 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 o teu único contexto é a context window, aí a qualidade começa a cair. E, se ele compacta, aí piora, porque compactar faz o quê? Resume tudo que está na context window e reinjeta as regras de volta. Então, tu perde tudo que conversou. Então, quando é tranquilo deixar a context window encher ou compactar? Quando eu sei que minhas regras estão em uma spec ou em um plano e também tenho uma maneira

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

20:57 sabem o que é o codebase, não sabem nada. A cada prompt — ou, na verdade, a cada loop que o agente faz aqui, a cada chamada de modelo —, ele manda tudo que está nessa janela para o modelo. O modelo faz uma análise: “Ó, qual é a próxima coisa aqui?”, e 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 eu uso uma janela de 1 milhão de tokens? Quando estou fazendo uma fase de pesquisa, ó. Então, pensem assim: qual vai ser o loop de trabalho de vocês? Pesquisar algo, usar o agente para

21:30 ajudar vocês a chegarem a alguma definição. Nessa fase aqui, tu vai abrir o máximo possível a busca e também vai usar subagents, tá? Então, aqui, por exemplo, ó, aqui, nesse plano que eu criei, tá vendo que ele usou um subagent? Cadê? Hum, agora não lembro onde, mas ele tinha usado dois subagents. Não lembro qual foi o chat. E tudo bem, tá, gente? Deixar o modelo usar subagents para fazer pesquisa é bom: ele mantém a context window menor e consegue separar os contextos. Vocês viram que, quando ele usou um subagent lá, um subagent buscou coisas do backend, outro, do frontend.

22:02 Então, cada um sai com uma missão. Isso é bom; a própria ferramenta faz isso, tá? E, nessa fase, tu pode mandar links, conectar um monte de coisas. A gente vai ver depois, no exemplo de construção da feature no Techlads Clube, que usamos muitas métricas e posts, conectamos um monte de coisas. Beleza? Só que aqui vai ter um monte de ruído. Depois, quando tu vai para a implementação de verdade, não quer ter esse ruído. Aí tu pega isso e joga em um plano, em uma spec, no que for, tá? Ó, terminou, terminou de implementar, tá? Terminou de implementar esse aqui. Eu só vou terminar de

22:35 explicar. Joga em um plano; depois tu vai para uma fase de implementação e verifica essa implementação. Então, voltando aqui: pô, meu plano terminou de implementar, implementou tudo que a gente tinha falado. Aí rodou o Playwright, deixa eu ver. Tá, tá aqui. Beleza, testou as coisas. É, o que falta agora nesse aqui? O que falta nessa abordagem com plan mode? Vamos lá. O que falta? Eu já vou colocar 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, deixar ele rodando enquanto falo alguma coisa. O que faltou? Code review. Revisar agora. Tá. Mas como a gente revisa? Eu, humano, sei que tinha um plano; consigo comparar, consigo revisar, tipo, pegar o plano e revisar o output um por um. Cara, isso não é sustentável, né? Pô, por exemplo, se eu vier aqui, olhar para aquele plano que ele fez e revisar cada uma das coisas, cara, não dá. Então, qual é a coisa mais fácil que a gente pode fazer? Usar outra LLM para validar. Ah, bom. O Playwright não validou; ele validou a navegação das

23:37 coisas, mas, pô, todas as regras de domínio foram aplicadas? Tudo que a gente falou que ia fazer foi feito? Cara, não sei. Então, qual é a coisa mais simples que a gente pode fazer, tá? Vou mostrar para vocês agora. Vamos lá. Vamos colocar aqui. E aí eu volto com aquela explicação do contexto, tá? Não se preocupem. Pum, fit indent. Ah, show. Qual é a coisa mais simples que eu posso fazer? Vou criar uma skill. “Crie uma skill que planeja, faz perguntas, tira dúvidas sobre o trabalho com o usuário e cria

24:08 um plano de spec com dado, quando e então, com todas as regras de domínio. Também marca as decisões técnicas e tem uma fase de implementação que, depois de implementar, inicia um subagent que valida se tudo foi feito conforme a spec.” Ó, beleza? Então, o que vou fazer aqui? Eu

24:39 estou criando uma skill. Por quê? Porque as pessoas também têm muitas dúvidas. “Ah, como crio uma skill? O que vai na skill e tal?” Então, já vou aproveitar para fazer duas coisas ao mesmo tempo. Primeiro, mostrar para vocês o mais fundamental que vocês têm que entender; depois, construir as coisas com base nisso, tá? Depois, vamos entrar em spec-driven, nos limites atuais do spec-driven por causa dos modelos, e no que vem depois do spec-driven. Mas temos que alinhar muito bem essas coisas fundamentais aqui: o que eu consigo fazer hoje. Lembra que falei que a gente estava construindo uma ferramenta? O Felipe está aqui. O Spectror era uma

25:12 ferramenta que fazia um pouco dessas coisas. Hoje tu consegue instruir um modelo, e os modelos bons seguem a maioria das instruções, tá? Ele inicia um subagent, inicia um Playwright, 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 no seguinte: skills são reutilizáveis. Tu pode iniciar um subagent genérico e dizer para ele usar três ou quatro skills. Um agente, quando tu cria um agente personalizado, é só um papel; não é flexível.

25:43 As skills basicamente tornaram os agentes quase obsoletos. Há casos em que tu quer usar agentes, mas basicamente faz tudo com skills, tá? Então, ele vai criar essa skill para nós e a gente vai ver, ó, essa skill, cursor, skill. O que é uma skill? É como 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 skills tu tiver, mais isso aqui vai pesar no teu contexto. É com isso que o agente decide se usa ou não uma skill. Ele lê isso aqui e pensa: “Ah, essa pessoa quer planejar; eu tenho o spec and build ali, vou carregar aquela skill.” É isso que ele faz.

26:13 Aqui tem o que ele colocou: fase um, fase dois, escrever a spec, fase três, implementar. Fase quatro, verificar. Claro que tu vai revisar e ver se fez sentido, mas normalmente é assim que eu crio uma skill. O que eu faço para criar uma skill? Eu mesmo resolvo um problema e digo ao agente para criar uma skill; depois reviso o que ele fez, porque não vou escrever um monte de Markdown, mas também não posso deixar ele sem controle, criando um monte de coisas inúteis, tá? Então, aqui a gente tem

26:44 uma skill já para implementar. E eu vou dizer: beleza, use, planeje o próximo item do mapa usando spec. Como é o nome dessa skill? Spec and Build. Vamos lá, deixar ele planejar agora. E, se a minha skill é boa, ela vai me perguntar para tirar as ambiguidades, tá? Porque eu disse que tinha que ter isso na skill. Vamos ver. Ah, pararã. Cadê? Spec and Build. Fase um: descobrir. Lê os arquivos. Então, pergunte uma coisa de cada vez.

27:17 Uma pergunta de cada vez. Isso aqui é muito bom, tá? Porque tem muita skill, até de spec-driven, que manda todas as perguntas juntas, só que às vezes uma pergunta depende da outra. 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 ela normalmente recomenda, tá? A própria IA já vai recomendar uma coisa que acha ideal. Ah, faça o recomendado. O que é? 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 pense no seguinte: é muito bom usar a IA para fazer bastante perguntas para você, tá? Ah, faça todos os recomendados. Tem uma skill que a galera usa bastante, de um YouTuber, Matthew Pocock, que é Grill Me. É uma skill muito boa. Se puderem mandar no chat aí para a galera, ela basicamente faz um monte de perguntas. Você quer começar um projeto? Ela faz um monte de perguntas. Vou mostrar uma para vocês depois: uma skill nossa que uso bastante, um pouco parecida, mas diferente, né? Mas é bom, nessa fase de pesquisa, fazer a IA

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

28:56 crie uma lista que contenha o job criado. Colocou: “Dado um usuário conectado, quando ele envia uma solicitação para jobs, recebe um erro.” Então, agora tenho o quê? Todas as regras que consigo verificar no final, porque antes eu não tinha. Preciso ter as regras para poder verificar no final. Também estão aqui as decisões técnicas que a gente tomou. Então, só com isso aqui, gente, vocês já estão muito bem. E aí, a mesma coisa: vou lá, não preciso pegar aquela janela poluída. Vou dizer: “Spec and Build: construa o job. Markdown.” Então, ele vai

29:30 construir aquilo ali. Eu precisava ter chamado “/spec-and-build job construa”? Talvez não, tá? Talvez o próprio agente fosse inteligente o suficiente para usar a skill, porque a descrição da skill mostra isso aqui. Mas eu gosto de chamar, porque quero ter certeza de que a coisa vai rodar do jeito que eu quero. Bom, ele vai começar a implementar. A gente vai voltar para a nossa explicação. Então, a gente viu a pesquisa, planejou; agora vamos entrar na fase de implementação. Implementa a coisa com base na spec e verifica a coisa em relação àquela spec. Esse é o fundamento que você tem que

30:02 ter em mente. “Ah, mas como se verifica?” A gente vai fazer essa verificação e falar das limitações de verificação com a IA, tá? Mas, enquanto isso, vamos passar para esta parte aqui, ó. Já está na etapa de verificar, tá? Tá. R. Pô, o Grok é genial, gente. Pô, tenho meus questionamentos sobre Elon Musk, mas eles fizeram um belo trabalho no Grok, muito rápido. A gente vai sempre tentar trabalhar com uma estrutura de divulgação progressiva, ou seja, deixar o agente descobrir as coisas de que precisa. E as skills permitem isso. A própria estrutura da codebase permite

30:37 isso. Então, quando é que eu uso uma skill? Quando quero ter, basicamente, uma instrução que carrego sob demanda, quando o modelo precisar, porque a skill é um arquivo Markdown. Quando você traz aquele Markdown para o contexto, ele ocupa espaço no seu contexto. Então, skills são coisas sob demanda; as rules, você coloca só o que precisa no agents.md, tá? Isso é bem importante. E a estrutura de pesquisar, planejar e implementar ajuda nisso, porque você abre uma pesquisa, usa um monte de skills, um monte de coisas, depois salva tudo num plano e não carrega aquelas coisas de novo. Aí a gente entra nessa questão, tá? Mas

31:08 pesquisar, planejar e implementar não é spec-driven? Gente, spec-driven virou um grande guarda-chuva de coisas que ninguém mais entende o que são, porque cada um adaptou à própria realidade. A gente vai falar um pouco sobre isso; meio que perdeu a identidade. Então, eu sempre volto à ideia de que, não importa como estou trabalhando, sempre tenho uma fase de pesquisa, uma fase de planejamento, uma fase de implementação e, agora, uma fase de verificação, tá? Então, quando a gente entrar mais em spec-driven, vamos entender um pouco melhor esse momento da coisa. Tá? Está verificando com Playwright. Beleza? E aí a gente entra em outro termo bem importante, que é harness. É…

31:41 Você deve ter ouvido falar bastante de harness; talvez seja uma coisa de que se falou mais nos últimos tempos. E harness tem dois sentidos. Tem o sentido estrito de harness, que é a ferramenta que a gente usa, tá? Então, seja Cursor ou Claude Code: esse é o harness sobre o qual a gente não tem muito controle. A gente confia que a empresa fez um bom trabalho. Inclusive, uma dica que dou para vocês é: tomem muito cuidado com ferramentas de terceiros, porque a ferramenta que você usa interfere muito no resultado que vai obter. Então, se você baixar uma ferramenta e pensar: “Ah, não quero pagar, quero usar modelos open source, vou pegar qualquer harness na internet”, cara, pode

32:14 ser que a pessoa desenvolvedora tenha feito um trabalho muito ruim para gastar mais tokens usando aquele harness. Então, sugiro usar, quem sabe, um OpenCode, algo conhecido, em vez de usar qualquer coisa. Aí, por cima disso, vem a parte que a gente consegue controlar ou adicionar para ter uma resposta melhor: o agents.md, as skills e o próprio código. A estrutura do código é um dos melhores harness que existem. Se você conseguir fazer com que o agente entenda o código sem ter que explicar para ele o que é, melhor ainda. Isso a gente chama de guias: coisas que guiam o agente para chegar a algum lugar. E

32:45 depois temos as coisas que validam e dão feedback para o agente. É muito importante que um agente tenha feedback. Vocês viram: por que uso Playwright para validar o frontend? Porque, se ele não recebe feedback sobre se o que fez está certo, vai assumir que está. E não dá para deixar o mesmo agente cuja missão é implementar a coisa dizer se ela está pronta, porque ele vai dizer que está: a missão dele é terminar aquilo. Aí, quando você abre outro subagent, cuja missão é provar que aquilo está funcionando, ele vai fazer de tudo para tentar validar aquilo. E o que são essas validações? A gente chama de

33:18 sensores: testes, linters, CI, observabilidade, hooks, sobre os quais o Felipe também vai falar. Tudo isso dá feedback para o agente, de forma determinística, sem depender do julgamento dele. Esse é o fundamento que você tem que ter em mente. Então, voltando ao desenvolvimento de software: testes são extremamente importantes, lint é extremamente importante, CI é extremamente importante, todo esse tipo de coisa, porque dão feedback para a gente, tá? Ó, ele está rodando aqui; deve estar rodando o Playwright agora. Deixa eu ver, talvez seja isso, tá? Deixa eu voltar aqui. Beleza. Então, nada mudou. Desenvolvimento de

33:49 software. Uma boa arquitetura vai ajudar; é uma boa estrutura para o agent entender. Isso a gente vai ver amanhã. É extremamente importante porque tu gasta menos tokens, ele acha as coisas mais rápido e a qualidade é boa. É extremamente importante porque ele vai ter feedback do que está fazendo. Vocês veem que aqui no meu codebase eu tenho dois tipos de teste, tá? Tenho testes no nível da API, tenho testes de integração, porque quero validar de ponta a ponta. E, no nível interno, nos services, tenho testes unitários, porque tenho bastante lógica de negócio. Ó, terminou a

34:19 validação. Ele diz que a spec passou; verificou todas as regras de negócio que estavam na spec, lembra? Então, vamos 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 tenho para vocês é: o que faltou aqui? A gente fez essa validação, mas o que faltou para ficar melhor? Hum, checklist. Code review. Review,

34:51 cenários, gates. Não, os gates rodaram, tá? Os gates rodaram. Ó, 106 testes passaram. Então, ele rodou tudo aqui. Passou pelos gates; ele rodou tudo. Faz parte da minha coisa aqui, ó. Ele não só validou, como também 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 agent consiga implementar coisas e se autovalidar, pensa o seguinte: pensando em review, a primeira coisa sobre review é que, se eu estou dando uma lista de coisas e validei que essa lista contém

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

35:58 driven. Beleza, a gente já fez um mini spec-driven aqui, já funcionou para nós, mas estamos construindo software Enterprise e precisamos ter mais estrutura na spec. Estamos construindo algo cuja arquitetura preciso validar. Spec-driven ajuda bastante nisso. Terceiro: spec-driven. Planeje o próximo item, o próximo item do roadmap. Vamos lá. Agora vamos fazer o seguinte aqui. Enquanto ele planeja, a gente vai dar uma olhada em uma skill. O 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. O Felipe já deve ter mandado. Manda no chat para a galera. Então, essa aqui é a nossa lista de skills open source. Todas as skills que vou mostrar estão aqui. Vocês foram ao GitHub; inclusive, deem uma estrelinha para nós, quem ainda não deu, já que a gente está vendo isso aqui. Vou passar todo esse material para vocês, não se preocupem. Foquem em entender as coisas. A gente está com 5.000 stars e, aqui dentro de package skills, estão as skills no catálogo de skills. E tem esse frontend aqui que o William Fernandes, que está aqui, fez. Sensacional. O Felipe Rodrigues, que também está aqui e vai falar com

37:00 vocês mais tarde, também fez. E aqui estão todas as nossas skills. A gente tem uma verificação de segurança. Temos uma baita auditoria para não deixar entrar skill lixo. Cuidado com skill lixo, tá, gente? Skill é um prompt que vocês estão colocando dentro do sistema de vocês, e tem muito problema com isso. E aí eu instalei a TLC Spec-Driven daqui. É a nossa skill de desenvolvimento spec-driven. Ah, mas por que vocês fizeram uma skill de desenvolvimento spec-driven? Porque a gente começou a ver que a maioria das skills era só uma instrução de prompt, e não era um prompt muito efetivo. E por quê? Porque ninguém fazia… Vamos

37:31 colocar isso daqui, colocar um monte de coisa. Porque ninguém fazia o quê? Ninguém fazia um benchmark de verdade dessas skills. Só diziam: “Ah, essa skill aqui é boa”. Aí tu pega Spec Kit, Superpowers, OpenSpec. Era muito baseado no sentimento da pessoa, mas eu pensava: “Pô, cara, se a gente está gastando tokens com uma 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. A gente viu que as skills de spec-driven ficaram para trás, principalmente porque vocês já viram uma coisa aqui que praticamente nenhuma skill de spec-driven tem: ela não valida o próprio trabalho. Então, comecei a ver,

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

38:34 normalmente, o spec-driven tem estas fases aqui. Estou usando o TLC Spec-Driven como padrão, mas normalmente os frameworks Spec Kit e Superpowers são famosos. Esta é uma fase em que tu especifica; aquela especificação cria algo bem similar ao Given-When, que a gente viu lá, como em BDD, em Gherkin. Tem uma fase de design, que é um documento que tu aprova, dizendo o que tem que fazer. A fase de design é o teu design técnico, as decisões técnicas, a arquitetura, o diagrama. E depois tu passa para a fase de testes, que é a fase de

39:06 implementação, a fase que define o que vai ser usado para implementar. Por que a indústria fez isso? Por que o spec-driven veio com essa ideia de que, pô, spec-driven é a spec como fonte da verdade e tal? Spec-driven é a grande coisa. Porque a gente trabalhava com modelos bem… Não, não digo ruins, porque vou comparar com o quê? Mas tinha muito retrabalho. Ou seja, tu planejava algo, tinha que olhar a especificação, depois olhar o design e 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 codebase bom, uma estrutura boa e trabalha com bons modelos praticamente não revisa mais a spec. Quem trabalha aqui com spec-driven? Comentem aqui. Vocês ainda revisam a spec em detalhes? Pelo que tenho visto, a maioria das pessoas já não revisa mais. E o que a gente começou a ver na indústria, principalmente entre as pessoas que usavam o TLC Spec-Driven, é que elas usam muito o TLC Spec-Driven porque gostam muito da garantia de execução e implementação que ele dá, mas já não revisam mais. Aí comecei a pensar: pô,

40:11 mas a indústria está se movendo para outra fase, em que talvez a gente não precise de tanta coisa assim. Vou explicar um pouco sobre isso, tá? Mas ele está criando os arquivos, vai criar o design e depois vai deixar implementar. Então, gente, o que acontece? A gente também fez bastante benchmark, tá? Está aqui, ó. A gente fez benchmark. Como é feito esse benchmark? Temos uma feature complexa: integração com Stripe. É uma feature que levaria de duas semanas a um ano, e a gente fica reimplementando várias vezes com os frameworks, até validar. E aí, na versão dois, a

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

41:13 tenho que usar o TLC Pack Driven? Não. Muita gente na própria empresa fez o próprio framework da empresa baseado nos fundamentos do nosso. Então, pensa assim, cara: eu não estou vendendo para vocês o TLC Pack Driven; estou dizendo que essa é uma maneira confiável de fazer e são boas práticas. Tu pode pegar essa skill e dizer: “Cláudio, me explica como funciona essa skill, como eu faço isso no meu time”. Pode fazer isso também, tá? Beleza? Cadê? Vamos lá, então. O que tem no Spec Driven que a gente precisa ver? A spec, que é bem similar àquela spec que tinha lá antes. O que ela tem? O que está fora de

41:44 escopo, questões abertas que foram confirmadas. Isso aqui é muito bom para registrar. As histórias de usuário, a mesma coisa. Given, when, then. Eu já vou mandar construir porque não quero perder muito tempo. TLC Spec Driven, build. Qual é o nome da feature? A mesma coisa. Abrir outro inventário de features. Tá, vou deixar ele construir. Enquanto isso, vou voltar para a explicação que eu estava dando sobre o TLC Spec Driven. Cadê? Specs, features. Ó, então a gente tem uma spec, tá? O que essa spec tem? Open questions, esse tipo de coisa. O given ali. Por que isso aqui é importante, gente? As pessoas pensam: “Pá, mas por

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

42:48 entrar nela aqui, em /TLC Pack Driven, ela usa um pouco de determinismo e um pouco de não determinismo para fazer as coisas. O Felipe fez várias alterações para que ela valide os arquivos e extraia informações 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 essas informações. Então, para quem está construindo skills, tentem misturar coisas determinísticas com não determinísticas, porque isso dá mais segurança. Então, voltando ao TLC

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á mais segurança, obviamente, né? Redundante. Então, spec é isso. Ah, o que tem que ser feito? Aí a gente passa para a parte do design. Aqui normalmente é onde a gente gasta mais tempo, se está numa arquitetura que precisa de ajustes, porque aqui tu tem uma visão de como a coisa vai ser no futuro. Aí tu vai lá e valida: “Pô, vai ser feito assim”. Tem um job service, data model, que é importante, error handling, riscos e preocupações. Então, tu tem um snapshot de como a

43:52 coisa vai ser feita, tá? Aí depois tu tem as tasks. As tasks são estas aqui, ó, tá vendo? Task um. As tasks são pequenas e atômicas, para a gente ir implementando uma a uma. E por que isso é importante? Até a geração anterior de modelos, gente, a gente não só tinha que dar um input bom para o 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 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 tu dá uma coisa muito aberta para ele, ele faz metade da coisa. Então, quanto mais estruturada for a coisa, melhor: tu dizer “Olha, tu tem que implementar isso, você tem que rodar um teste para provar isso”. Tá vendo? Uma task tem o quê? A task tem o que precisa ser feito e como ele valida. Então, aquela coisa só está 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 para a gente lidar com esses modelos antigos. E outra coisa também é que isso dá uma estrutura de

44:58 implementação, mas tem um trade-off, né? Pô, quando o modelo vai fazendo task por task, é mais lento, tá? Vocês estão vendo aqui: ele está fazendo uma, está provando que está funcionando, vai fazer a outra e assim vai ficar rodando até implementar todas as tasks. Cara, isso tem um efeito, né? Tem um efeito na velocidade; basicamente, é mais lento, gasta mais tokens porque ele roda um teste, para e tal. Mas isso era necessário até então para os modelos com que a gente estava 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 Superpowers, que é o framework, faz, é dar o código pronto para uma fase. Por exemplo, uma fase de planejamento já inclui no próprio plano o código de como vai ser, e o outro modelo só implementa. Isso também não é uma coisa boa, porque, com os modelos evoluindo, o modelo que vai implementar deveria saber implementar. O que tu tem que dar para ele é uma direção e depois validar. A gente vai ver isso. Então, o que o Spec Driven fazia? Para recapitular: uma spec,

46:02 revisar o design e depois tasks para o modelo seguir uma a uma, rodando testes e tal. Isso aqui é muito bom, gente. Então, para quem está trabalhando hoje e ainda não tem acesso — “Pô, eu não consigo usar sempre um Sonnet para implementar, não consigo usar um Grok para implementar” —, vocês ainda vão se beneficiar bastante desse modelo de Spec Driven por um bom tempo. “Ah, mas eu já estou como tu, pô. Eu consigo usar um Grok, consigo fazer como o William, que usava Opus para planejar e implementar.” Se está nesse nível, essa estrutura está te atrapalhando, porque esses modelos são

46:34 muito mais inteligentes para implementar. Eles conseguem fazer bem, conseguem implementar muito mais rápido. Isso aqui basicamente é cuidar desses modelos o tempo todo. E eu vou explicar como a gente passa por isso, tá? Outra coisa interessante e importante que tem no TLC Pack Driven é um log de decisões, tá? Então, ele registra o que foi decidido, e por isso isso é muito bom para ver tudo que aconteceu. Então, para quem está nessa situação de fazer aquela composição de modelos, em que tu usa um modelo bom para planejar e o modelo mais barato, tipo o Composer, para implementar: usa o Composer?

47:05 Composer? Cara, eu testei o Composer; a minha meta era fazer o Composer entregar muita qualidade. E, na última versão dele, com Spec Driven, eu consegui fazer ele superar todos os outros frameworks usando o Composer. Por quê? Porque a gente colocou bastante estrutura para ele. Então dá para usar tranquilamente, tá? E vou voltar aqui. Aí ele está implementando, vai implementar task por task. Vou deixar ele implementando e vou voltar aqui. E outra coisa também que está se tornando bastante difícil com o Spec Driven é o seguinte: a gente tem um fluxo de desenvolvimento em que a gente

47:38 Tem um PRD, um documento de requisitos do produto. Normalmente, a gente tem um documento de design, que é onde ficam — vou mostrar depois — as decisões de design que você compartilha com a empresa, com outras pessoas. Depois, isso vira um projeto e, para cada tarefa, um design, uma tarefa. Aí vem a primeira coisa que as pessoas perguntam: “Tá, mas a spec é para as pessoas validarem?” Não, a spec é para o agente. O design é para as pessoas validarem. Até dá para usar a spec para isso, mas ela também é para o agente, tá? E a tarefa da abordagem orientada por especificações vira tarefa no board? Não. Aquela tarefa pequenininha é uma tarefa para o

48:11 agente. Aí, o que vai no board? Cada pessoa faz de um jeito. Quem é mais avançado aqui, tenho quase certeza de que, se usa a abordagem orientada por especificações, fez alguma coisa para juntar essa abordagem com o resto do fluxo. Quem quiser, pode mandar no chat o que fez. Então, uma ideia inicial em que eu também acreditei em parte — eu não acreditava que a spec fosse a fonte da verdade, mas acreditava que o task tracking, o Jira e o Linear iam morrer. Então, a abordagem inicial se estruturou assim: “Não, tudo fica no repo, esquece o resto”. Só que, na verdade, a indústria está indo para o lado oposto. Cada vez mais, a

48:43 gente quer conseguir instrumentar agentes em qualquer parte. E a melhor maneira de fazer isso é a partir de um task tracking, de um board, porque você pode ter um fluxo totalmente automatizado que começa com um ticket de suporte, cai numa triagem, um agente faz a triagem e encaminha para outro agente, que implementa, e nem chega ao seu computador. E aí isso dificulta bastante o uso da abordagem orientada por especificações. Outra coisa: a ideia de a spec ser a fonte da verdade não se consolidou. Por quê? E, assim, se alguém usa a spec como fonte da verdade e funciona, continue usando. Mas a realidade é que, se você não está num time onde consegue controlar

49:14 que toda operação seja feita com a abordagem orientada por especificações, já existe drift. O código é diferente da spec. O que acontece? A gente tem modelos extremamente inteligentes. Aí você diz para ele: “Olha, esta aqui é a spec”. Ele olha e vê que o código é diferente. Então, começa a entrar num loop de reasoning, pensando no que está certo. Você está atrapalhando o modelo. Cara, não faça isso. O que a gente está fazendo — e vou mostrar no segundo bloco, depois do almoço — é usar mais os boards como fonte da verdade, deixando no repo apenas as decisões, os ADRs e coisas do tipo, tá? Esse é o caminho que a gente está seguindo, e vejo que a indústria

49:46 está indo bastante nessa direção. “Ah, mas eu quero deixar o impact comitado.” Pode deixar, tranquilo, sabe? Mas pensem que existem essas limitações, e a gente vai continuar trabalhando nisso aqui, tá? Então, entendemos a abordagem orientada por especificações e o momento em que ela está. Como quero garantir que a gente não fique sem tempo, já vou começar a próxima parte aqui. Vou fazer o seguinte. Vamos lá. Agora, vou dizer o seguinte: abra uma worktree, crie uma. Pode falar, Dom. Teve uma coisa que gerou bastante dúvida, mas acho que é melhor esclarecer para acabar com as dúvidas por enquanto. Ah, foi

50:18 quando você falou ali para não usar a abordagem orientada por especificações com modelos melhores. Você vai explicar isso com mais detalhes depois? >> Vou chegar lá. Não, não vou, gente. Vou explicar; vocês vão sair daqui com todas as respostas, tá? De novo, a TLC Spec Driven, tenho certeza de que, entre os frameworks que conheço, é disparada a melhor. A gente realmente… gastei uns R$ 30.000, R$ 1.000 testando isso. Então confio no benchmark. >> Gastou um quilo usado. >> Mas, no geral, vejo que o modelo da abordagem orientada por especificações chegou ao limite, principalmente com os modelos atuais e com a

50:50 estrutura para a qual a gente está indo. E vou dar duas opções para vocês, tá? Uma opção é não fazer uma grande breaking change para quem usa a abordagem orientada por especificações; a outra é o meu fluxo, que é o que estamos começando a implementar na TLC e que acho que talvez faça mais sentido. Aí vocês vão evoluindo como acharem melhor, tá? >> Boa. >> Uma coisa que vou fazer é mandar para o pessoal ali. Teve bastante gente questionando a metodologia usada na avaliação da Telec Driven e tal. Vou deixar o post do blog

51:21 aqui, que o Valdemar fez lá na comunidade. E, de novo, gente, a gente não está querendo vender nada para vocês. É open source, aberto; a gente não está tentando convencer ninguém a usar isso. Mas é um bom trabalho feito pela comunidade, open source e gratuito. Nesse arquivo estão todos os benchmarks que fizemos, mostrando por que é melhor e tal. Então, testem por conta própria e vejam se funciona para vocês. É open source, não custa nada para usar. [risadas] >> Sim, sim. Acho engraçado. As pessoas questionam, cara,

51:52 “É, tem todos os resultados abertos.” As pessoas da comunidade, inclusive, já rodaram esse benchmark. E, gente, muita gente nas empresas faz esse tipo de avaliação: adapta a abordagem orientada por especificações ao próprio fluxo. Então, pegam a Telec Spec Driven, pegam outras de que gostam, mandam para o agente e dizem: “Olha, compare estas e me diga qual é melhor usando os fundamentos de LLM como juiz”. Sempre vai ser a TLC Spec Driven, porque a gente implementa vários fundamentos. Então, você pode pegar todas essas coisas, mandar para um LLM e perguntar. Às vezes parece que a gente está vendendo a skill. A gente não ganha nada com isso; só compartilha com vocês o que usa, tá? Mas

52:25 beleza. Então, falei que o modelo da abordagem orientada por especificações está chegando aos limites por causa do caminho que os modelos estão seguindo. E a primeira coisa que vou deixar para vocês é esta aqui. Cadê a TLC? Vou instalar aqui, ó. Em vez da TLC Spec Driven, a gente vai usar a TLC Spec. Opa, cadê o Spec Link? Em vez de fazer uma breaking change na TLC Spec Driven, porque esta nova versão é mais voltada para esses modelos ainda melhores — talvez daqui a uns três meses a gente faça uma breaking change —, esta é a nova versão que imagino para a Telec Spec Driven, tá? Que é a TLC Spec. Ah, vamos lá.

52:57 TLC Spec Plan: planeje o próximo item do roadmap. Por que abri uma worktree, gente? Uma worktree basicamente não é só uma branch, tá vendo? “Fit inventário.” Ela não é só uma branch: é uma branch com uma cópia do código, ou seja, consigo trabalhar em duas coisas ao mesmo tempo sem que uma interfira na outra. E, como uso SQLite, não tenho nada que interfira entre uma e outra. Então posso deixar esta branch implementando o que estava implementando. Ó, já está na verificação, tá vendo? E abro outra para a gente não gastar muito tempo e já começar a fazer outra coisa, tá? Depois, que o merge se vire. Mas

53:29 não vou entrar muito no merge aqui, porque a minha ideia é mais mostrar o fluxo para vocês. Então, vocês vão ver que a TLC Spec é bem mais leve. O que mudou da TLC Spec Driven para a TLC Spec é que spec e design viram uma coisa só e não temos mais a etapa final de tarefas. Ou seja, deixamos o modelo, que é bom em fazer o trabalho dele, implementar, fazer a implementação do jeito que acha ideal, e depois validamos bem. Então, isso é uma grande diferença, uma grande diferença,

53:59 tá? Vou mostrar para vocês. A TLC Spec Driven implementou todas as coisas e agora está executando um verificador aqui. É um verificador muito mais rigoroso do que aquela skill que fizemos internamente. Ele verifica todos os critérios, verifica os testes e marca linha por linha o que foi feito. Então, não deixa nada passar; é bem, bem, bem seguro e muito bom, tá? Por isso que digo: se vocês usam modelos mais baratos para implementar, isso aqui é extremamente necessário. E agora vou voltar para este aqui. Ele está explorando o código-base, tá? Então, quando aquilo ali estiver acontecendo, vamos

54:31 Seguir um pouco mais para a frente, tá? Depois é code review, tá? Beleza? Beleza. Deixa eu ver se está tudo alinhado. Hum, eu vou… Vamos lá, tá? Ele vai criar o plano aqui. Aqui a gente também, gente, enquanto ele está trabalhando, falou bastante dessa parte de implementação, né? Aqui, aqui dentro. Basicamente, ainda não entrei nessa parte do projeto e tal; vou entrar nisso depois, tá? É uma coisa sobre a qual 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 também vai entrar nisso. Estou tentando seguir uma linha que seja bem

55:03 fácil para vocês entenderem como as coisas vão acontecendo e como as necessidades vão surgindo, tá? Então, a gente entendeu que existe a necessidade de montar esse harness em volta, tá? Ele é uma combinação de coisas não determinísticas com coisas determinísticas, além dos sensores do nosso código base, que testa todo esse tipo de coisa. E a gente também entendeu que o spec driven atual ainda faz sentido, tá? Em muitos casos, mas já estamos caminhando para deixar de usá-lo. Só que simplesmente não usar nada não dá, porque os modelos ainda são não determinísticos e, por melhores que sejam, vão deixar alguma coisa

55:35 passar. Por que eles deixam coisas passar? Porque, quando você dá uma missão para o modelo, pense que o LLM é uma máquina de probabilidade, que está sempre calculando a próxima coisa. Se a missão dele é implementar, ele vai se otimizar para implementar. Não vai tentar testar tanto. Vai tentar, obviamente, mas vai deixar alguma coisa passar. Vai esquecer de executar algumas coisas. Então, quando você abre outro para validar, a missão dele é aquela ali, pô. Ele vai encontrar. E o code review é bem parecido; a gente também vai entrar nisso, tá? Está ficando pronto. E, ah, outra coisa que o TC Spec Driven tem é teste de mutação, tá vendo? Ele está fazendo isso aqui agora; eu tinha esquecido. Teste de mutação, o quê? Ele

56:08 pega alguns casos. Ah, uma função recebe um, recebe dois números e soma esses números. Ele vai tentar colocar número negativo, fazer um monte de coisas, tá? Isso já vem embutido; você não precisa se preocupar com isso. Olha, está fazendo o teste de mutação ali. Dizem que é uma das coisas mais efetivas para testes com IA. Ah, beleza, gente. Então, aqui a gente criou um plano, lembram? Telec que estou usando aqui. Qual é a grande diferença em relação ao spec driven normal? Ah, ele criou dentro da outra branch. Putz, ele pegou a branch. Tá, vou fazer o seguinte: não use a pasta inventory; crie como já estava ali

56:43 a pasta; ele criou na mesma. Mas o plano é uma fusão da spec com o design. Por quê? Porque outra coisa que eu via como bem difícil era que as pessoas não sabiam o que colocar na task do board, no Jira, sei lá o quê. Aí colocavam qualquer coisa, só um título, qualquer descrição. E, quando iam planejar, começavam a planejar tudo de novo, pegando o contexto de um design doc e tal, e o board não servia para nada. Só que tenho visto que cada vez mais as pessoas usam o board. Então, a primeira coisa que fizemos nessa alteração é que você tem um plano, que pode… Esse plano pode virar

57:16 uma task, e aí você pode pegar de lá. Por exemplo, olha, você pode vir planejar sua coisa aqui, criar uma task; essa task vai para cá e aqui você não vai mais fazer isso, basicamente. Vai só fazer a implementação aqui, só implementar. Então, a primeira coisa que mudamos aqui foi isso. Ainda dá para fazer commit dessa estrutura. Se quiser comentar seus specs, pode comentar, mas ela também foi feita para se integrar melhor com o board, seja o Linear ou o que vocês usarem, tá? Então, aqui só tem um plano. Depois vou deixar ele mover para um

57:46 diretório novo para vocês verem qual é a diferença. Não, putz. Ah, tá. Ele continua com o próximo item. Vamos lá. Vamos ver. Ele vai criar um plano agora direitinho. A gente vai ver ali, ó. Verificação. Está terminando. Ele escreve um validation. Esse aqui é o outro que está rodando. Beleza. Então, deixa eu ver esse plano que ele vai criar agora para mim. Nada como uma worktree, galera. A worktree resolve o problema de vocês: paralelizar as coisas. Enquanto o TC Spec Driven está verificando o trabalho dele, eu estou aqui, ó. TC Speclink criou o plano. Crie o checklist. É, ó, agora a gente vai

58:19 conseguir ver aqui, ó. O próximo item do roadmap é procurement, que são compras e vendas. Explica o problema, explica o que está fora do escopo, explica as coisas que foram presumidas e não confirmadas. Então, seria bom confirmá-las. As histórias. E aqui tem todo o contexto das decisões que foram tomadas, o fluxo da arquitetura. Então, ah, entra por aquela tela, tem uma API, chega no post service. Bom para um humano revisar, o data model também para revisar. Então agora tenho uma coisa que pode virar uma task; isso já ajuda bastante. Tem uma coisa que pode virar uma task; não preciso depender só daquilo que está no repositório, tá? Essa

58:52 foi a primeira mudança que fizemos. A grande mudança foi muito baseada no uso que as pessoas fazem. Agora ele vai criar os checks. A Telec Spec Driven está rodando e vamos ver duas coisas para finalizar este bloco antes de entrar no… Não, vou fazer uma coisa principal para a gente finalizar este bloco e vou compartilhar mais algumas libs. Vou deixar esse aqui terminar. Está escrevendo os checks. Deixa eu ver. Legal. Ah, olha que legal. O verifier falhou. Estão vendo? Viram ao vivo, gente? Mesmo numa coisa simples,

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

59:53 deixar ele criar o checklist. Criou, olha. Olha a diferença em relação ao que tínhamos antes. Antes, tínhamos uma spec com tasks, design, spec, um monte de coisas. Agora temos basicamente um plano, que é uma task, e os checks, que são as implementações extraídas desse plano, para fazer uma correspondência para cada uma. Olha: get API suppliers. Com uma tabela vazia, tem que responder 200 com um array vazio. Como você prova isso? Executando o teste. Então, são vários checklists que ele vai ter que executar no final. Ou seja, quanto mais spec, a

1:00:24 gente deixa o modelo implementar do jeito que achar melhor, paralelizar as coisas, fazer o que quiser, e depois executamos um checklist rigoroso e fazemos o modelo provar tudo. Basicamente isso. Então, é muito mais econômico, muito mais rápido e usa o modelo da melhor forma possível, tá? Então, essa é a grande aposta que eu vejo. Então, vamos colocar aqui TC Spec. Vamos deixar ela implementando também. Vamos lá. TC SPC. Ah, não, tem que voltar àquela. Vou colocar nesse aqui mesmo. Qual é o erro da branch inventory? Vamos lá. Hum, aqui: spec TLC pack. Cadê? Vamos lá. Quero deixar ele implementando. Olha, agora

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

1:01:33 Essa aqui é TL6 Pack Driven. Ele verificou que está tudo feito. Pô, o que falta agora? Antes de chegar até mim, vou revisar. Mas, antes disso, vou adicionar mais uma camada de revisão de código. O que entra nessa camada de revisão de código? Entra a revisão da arquitetura: se ela mudou, se entrou algo novo na arquitetura, algum padrão novo, se há alguma regressão, se o agente mexeu em algo que não tinha relação com essa feature. Tudo isso faz parte da revisão final, que não tem muita relação com a skill em si, tá? Então, como a gente faz isso? A gente também tem uma skill de revisão de código. Vamos usar TLC. Vou instalá-la

1:02:06 aqui. Tem duas skills, tá? Tem uma; vou usar esta daqui, que é mais rápida de executar. Mas tem… opa, vamos usar esta do Felipe, que é nova aqui. Então, esta é uma skill de revisão de código. Vamos colocar aqui: “Ah, use a skill de dud para validar as alterações feitas aqui. Não faça nenhuma integração com Git.” Essa skill é algo que vocês vão plugar no pipeline de vocês, algo assim, para fazer a revisão do PR, tá? Então, como funciona uma revisão com IA? Pensem no seguinte: a gente viu um pouco sobre sub agents,

1:02:41 mas qual é a ideia? A gente sabe que cada sub agent é bom em uma coisa. Então, para começar a revisão de código, a primeira coisa é iniciar um sub agent para cada coisa que é importante para o seu codebase. Normalmente, o que a gente usa nos nossos é um para segurança, um para requisitos, um para garantir que tudo foi testado ou que há testes, um para arquitetura, para garantir que os padrões de arquitetura foram seguidos. O que eu também gosto de validar é se não foi adicionado nada à arquitetura que não seja conhecido. Se foi, quero que me avisem, porque a IA tem muito essa tendência de querer abstrair demais e, às

1:03:11 vezes, traz design patterns que eu nem sei o que são, cara. Não coloquem sem me avisar. Regressão e alucinação. Essa é extremamente importante. O que acontece? Principalmente com modelos de versões anteriores: às vezes, eles passavam por um arquivo que não tinha relação nenhuma com as mudanças e alteravam algo. Já vi, pô, deletarem fila, mexerem na estrutura do banco de dados. Então, essa parte de regressão e alucinação olha para essas coisas e aponta: “Olha, acho que isto aqui não tem relação com o que você está fazendo.” E performance. Esses são os que a gente faz, tá? Eu confesso para vocês: essa skill do

1:03:42 Felipe é nova. Estou usando K jude. A gente tinha uma que era o pior review, que é a que também usamos no time. Vou deixar ela para vocês; depois dou uma olhada. Mas esta daqui é baseada nessa skill de revisão de PR que vou deixar para vocês. A do Felipe é nova, estamos testando. Ela tem um harness melhor, porque você consegue executá-la várias vezes e ela não fica apontando coisas infinitamente. Ela aponta uma vez, valida aquelas coisas e tal. Então, provavelmente vamos migrar para essa dedude. Mas o slide que estou mostrando é da outra, que também vou deixar para vocês. Vocês podem juntar as duas. O que ela faz? Essa

1:04:15 Deud precisa apresentar evidências. Vamos ver. Ela classifica os itens como blocker, should fix e nich. Isso também é importante, porque às vezes o modelo fica colocando um monte de coisa. Ah, ela tem integração com Git e várias camadas determinísticas também para garantir as coisas. Então vocês podem pegar essa skill e olhar depois como ela funciona. São bons padrões para vocês incluírem na revisão de código de vocês, tá? Olha, aqui ele está escrevendo um finds. Depois vamos ver o que ele encontrou. Então, essa é a camada final. Aí, onde entra o humano? Pô, passei por todas essas camadas de revisão aqui.

1:04:49 Ou a gente encontrou… encontrou coisas. Vou aplicar o que ela encontrou. Aí vou dar uma olhada no que faço normalmente: olho as partes que sei que são críticas, que têm lógica de negócio e decisões críticas de arquitetura. Mas vocês vão ver amanhã, no final da tarde, que as coisas no nosso codebase… Pô, meu review hoje em dia é muito rápido. Um PR de mais de 50 linhas, em 10, 15 minutos eu já revisei, porque a gente tem uma grande automação, tá? Então, olha, ele fez uma revisão e disse que está safe para aprovar.

1:05:19 Neste caso, há duas coisas pequenas, olha: a quantidade no input permite zero, mas a API não permite. Ah, “o alerta de erro fica abaixo dos três formulários”. Não sei o que é isso, mas é uma coisa simples de frontend que ele encontrou aqui, tá? Então, neste caso, estamos safe aqui. Duas skills que vou deixar para vocês, porque não vou ter tempo de mostrar uma skill de projeto: é esta daqui. Outra coisa: por que vou deixar essas skills para vocês testarem? Pensem no seguinte: a gente falou um monte de harness, pmmd e skills, mas o 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 falei, os modelos novos são muito inteligentes, mas não precisam de um monte de skills que a gente tem, nem de um monte de agents. Ponmd, mas precisam de alguns. Como a gente sabe quais são esses? 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 há vários JZ com atenção dispersa por três minutos aqui, uma geração TikTok. Disseram no chat que precisam de uma recapitulação rápida antes do almoço sobre tudo o que foi feito. Não sei se já estava planejado, mas, se puder fazer essa recapitulação para J, o pessoal agradece. >> Boa, boa. Vou dar uma repassada. É, então vou deixar para vocês esta skill aqui, nossa, para vocês validarem aqui. Harness e val. Essa skill vai ficar para vocês validarem a utilidade das coisas que têm. Ah, meu de espant, as coisas estão todas ali e fazem sentido; algumas podem ser deletadas. Tipo, ele tem três níveis, tá? O nível A valida se as estruturas ainda existem. Os comandos que ele indica aqui,

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

1:07:00 por exemplo, os comandos que estão aqui nesse agents.md são válidos quando há comandos. Ah, se ele aponta para um arquivo, aquele arquivo ainda existe. Então esse é o nível seguro. Depois, ele tem outros dois níveis de validação, B e C. Aí ele usa um sub agent, analisa as skills e verifica se, para aquele modelo que está fazendo a validação, aquela instrução é redundante ou não. Então, esse nível é sensível ao modelo, tá? Então, se vocês forem executar isso, além de gastar tokens, executem com os modelos que usam no dia a dia, para verem o que nas skills e nos agm de vocês está começando a ficar redundante. Mas vão

1:07:34 tirando devagarzinho, tá? É só para dar uma ajuda para vocês. Outra coisa que vou deixar para vocês é este aqui: Harness Score, do Fernando Paladini, da comunidade. Vou deixar o link aqui; já vou até mandar o link para vocês. Ele valida se a estrutura do seu harness está boa. Você tem skills, guides e tal; ele percorre repositórios. Então comecem pelo Harness Score, depois passem para o harness e avaliem a estrutura de vocês. Beleza? Então, para a gente finalizar esse bloco, uma recapitulação rápida. Vou

1:08:05 deixar esse pack para vocês também. Está tudo aqui no nosso… estão todas aqui, gente. Depois ficam todos os links. Vamos lá. Eu uso o Cursor aqui, tá, galera? Recapitulação. O que a gente fez? A gente começou com esse sistema, que era um RPzinho simples, tá? No roadmap aqui. Como ele está, na verdade? Deixa eu ver. Vamos pegar aqui o usuário e a senha do admin. A gente fez um roadmap 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 alguma abordagem. A gente começou sem nada, tá? A gente começou sem nada. O que foi? Cadê? Vamos ver. É, criou o roadmap. Aí, nesse item aqui, a gente implementou sem nada, só disse 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, em que 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 cria uma spec e 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 Spec-Driven. A gente instalou a skill de Spec-Driven. Cadê? É, tá aqui, ó. Isso aí. A gente foi para Spec-Driven. A gente entendeu que, pô, Spec-Driven nos dá toda essa estrutura. A gente tem uma spec, a gente tem um design que consegue revisar, consegue ajustar as coisas, consegue mandar

1:09:38 implementar. A gente tem um harness muito forte pra seguir passo a passo, tá? Pra seguir passo a passo com testes. Só que a gente viu também que isso aqui tá chegando no limite pros modelos atuais. E aí, qual é o passo depois disso? É parar de fazer babysitting nos modelos e tirar o melhor deles, deixar eles implementarem mais e validarem. 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 no que mudou aqui. Em vez de a gente ter uma spec, um design e as tarefas, agora a gente tem um plano que envolve a spec e o design direto ao ponto. E depois a gente tem um checklist que um subagent vai lá e roda contra a implementação. Ó, tá vendo? Ele tá fazendo isso aqui agora. Essa é a questão. Então, se vocês — tem muita gente que tá aqui que já é mais avançada, tem a própria skill da empresa e tal —, o 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 vocês, melhorar as skills de vocês, usar os fundamentos que a TLC Packlin implementa para melhorar a estrutura de vocês. E quando vocês vão usar essa skill? Só se vocês têm acesso a modelos bons, tá? Porque, se você botar num modelo, tipo, botar num Composer, que é um modelo que não segue bem as regras, ele não vai rodar os checks depois. Aí tu tem um problema: vai implementar de qualquer jeito, não vai rodar os checks. Tu não quer fazer isso, tá? Então tu tem que saber com quais modelos isso funciona. Então é muito mais começar a pensar já no futuro, pra onde as coisas estão indo, e ajustar as skills de vocês. Então, pra resumir, Spec-Driven ainda é útil rodando com os modelos mais baratos, mas precisa de muito

1:10:38 vocês melhorarem as skills de vocês, usarem os fundamentos que a TLC Packlin implementa para melhorar a estrutura de vocês. E quando vocês vão usar essa skill? Só se vocês tiverem acesso a modelos bons, tá? Porque, se você colocar num modelo, tipo, num composer, que é um modelo que não segue bem as regras, ele não vai rodar os checks depois. Aí tu tem um problema: vai implementar de qualquer jeito, não vai rodar os checks, e tu não quer fazer isso, tá? Então tu tem que saber por quais modelos optar. Então é muito mais começar a pensar já no futuro, para 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. TLC Packlin é o caminho para rodar com modelos melhores. E aí a gente finaliza esse bloco.

Transcrição original

[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.