Deep Dive
Do zero com IA: entendendo o fluxo fundamental
Waldemar começa mostrando um app full stack simples — backend em Node, frontend em React — para construir do zero usando IA, iterando por ciclos que cobrem plan mode, sub agents, verificação, harness, spec driven e workflows otimizados. A ideia é entender onde cada conceito se encaixa antes de aprofundar. Ele já começa preparando o repositório com um agents.md que carrega regras que só precisam estar no contexto uma vez: padrões de dependency injection, estratégia de testes (services com unit tests porque têm lógica de domínio, rotas testadas com integração, banco testado end-to-end, web sem testes por enquanto). Isso tudo vai minimizar o que precisa ser repetido a cada prompt. A primeira coisa que o agente faz é pesquisar na internet quais módulos são necessários para um ERP funcional completo com controle de estoque, warehouses, obras, alocamento de staff, admin e operador — criando um roadmap que vai guiar todo o workshop. Waldemar deixa claro: modelos evoluíram muito e agora são muito bons em usar tools e buscar skills, então não precisa botar tanta coisa no agents.md quanto antes.
Agents.md, skills e contexto: a arte de instruir sem poluir
A janela de contexto é um recurso caro que degrada com tamanho. Waldemar mostra um gráfico científico onde a qualidade do GPT cai consistentemente a cada 100k tokens adicionais na janela — por isso a regra de ouro é ficar em torno de 40-60% de ocupação máxima para não pagar em output quality. Agents.md deve ter o mínimo: só regras que o modelo não entenderia sozinho. Skills são instruções reusáveis que o modelo carrega sob demanda quando vê que faz sentido, baseado na descrição. Quando o agente começa a trabalhar num warehouse stock, Waldemar adiciona uma rule dizendo que sempre que implementação tocar no frontend, o próprio agente tem que validar com Playwright — abrindo o browser, navegando, clicando — para provar que funcionou. Sub agents são críticos aqui: quando precisa pesquisar código base completo, em vez de encher a janela principal, ele abre dois sub agents separados — um explora padrões do backend, outro padrões do frontend — cada um volta com um resumo, agente principal toma decisão com janela limpa. Isso é automático com ferramentas modernas, o modelo reconhece quando precisa e faz.
Plan mode e a morte do retrabalho: especificar antes de implementar
Waldemar usa plan mode para o próximo item do roadmap — descobrir User Role, decidir como vai ficar a arquitetura. Plan mode é como se fosse uma skill nativa, instruções de como o agente deve planejar. O agente abre dois sub agents, explora código base, volta com um plano estruturado: fases de implementação, quais rotas vão entrar, shape da API, testes que vão ser feitos. Isso muda tudo porque antes, quando você apenas pedia para implementar, o agente ia direto e você só descobria problemas depois, quando código já tava feito — aí revisar é muito mais difícil. Com plan mode, você revisa a especificação antes do código existir, e cada loop com o agente custa menos tokens porque ele não tá tentar corrigir implementação, tá refinando decisões. A janela de contexto fica em torno de 60-70% depois de planejar — é o momento certo de pegar aquele plano e botar em um agente novo com janela zerada para implementar, porque compactar janela (quando fica cheia) faz o agente perder conversas e qualidade cai. Waldemar enfatiza que estar acima de 60% historicamente era desconfortável, mas hoje com planejamento claro é aceitável porque agente sempre tem para onde voltar.
Spec Driven: validação rígida com verificadores separados
Spec Driven tem o propósito claro: você não deixa o mesmo agente que implementa também validar seu próprio trabalho — ele vai dizer que tá pronto porque a missão dele é terminar. Waldemar cria uma skill chamada Spec and Build que tem quatro fases: discover (ler arquivos), questionar uma pergunta por vez (nunca todas juntas, porque uma pode depender da outra), write spec com Given When Then e todas as regras de domínio, depois implement e validate com sub agent rígido. A skill extrai cenários como lista vazia, criar lista, lista contém o job criado — tudo testável. O agente implementa, roda testes e Playwright, depois um verificador separado valida contra aquela spec linha por linha. O próprio verificador falha 1 de 389 acceptance criteria? Ele manda de volta para o agente arrumando, roda novamente — isso tudo automático, sem você ter que tocar. Waldemar mostra que TLC Spec Driven v3 bate todos os frameworks de spec driven do mercado em benchmark (gastou uns R$1000 testando), principalmente porque ela tem essa parte de autoverificação forte. Se você usa modelos mais baratos tipo Composer 2.5, essa estrutura é absolutamente necessária — ele tem attention span pequeno, sem tesques estruturadas pula metade das coisas.
TLC Spec Link: a próxima geração para modelos melhores
Com modelos evoluindo rapidamente, Spec Driven tradicional começou a ficar pesado — muita estrutura para modelos que já conseguem implementar bem. Waldemar apresenta TLC Spec Link como a resposta: em vez de spec, design e tesques separadas, agora tem um plano que funde spec e design, sem tesques granulares. O modelo implementa do jeito que acha melhor (não é babysitting tesque por tesque), e depois roda um verificador muito mais rígido que extrai de forma determinística cada acceptance criteria e faz modelo provar cada uma. Isso é muito mais econômico — menos loops, menos tokens gastos — e usa modelos bons da melhor forma: deixa implementar livremente, depois valida forte. O plano que sai daqui pode vira uma tesque no seu board (Jira, Linear, o que for), porque cada vez mais a indústria tá usando task tracking como fonte de verdade em vez de repositório. Waldemar mostra ao vivo: o verificador de TLC Spec Link falha uma criteria? Automaticamente manda de volta, arruma, roda novamente. Você humano não toca, loop é determinístico e pode rodar em CI, não depende de você estar na máquina.
Harness: a arquitetura invisível que guia agentes
Harness tem dois níveis: ferramentas que você não controla (Cursor, Cloud Code) e tudo que você consegue controlar ou adicionar (agents.md, skills, código, testes, CI, lints, observabilidade, hooks). Estrutura de código é um dos melhores harness porque se o modelo entender o código sem precisar de explicação, economiza enormemente em tokens. Sensores são tudo que valida: testes unitários, testes de integração, lints, CI pipelines, observabilidade. LLM é máquina de probabilidade otimizando para sua missão — se a missão é implementar, ela tira atalhos em teste e valida. Por isso precisa de outro agente com missão de provar que tá funcionando. Quando Waldemar roda Playwright para validar frontend, é porque modelos são muito bons com imagens mas péssimos em interpretar visual sem screenshot real — uma screenshot muda tudo. Tudo isso junto forma o harness que permite agentes irem de research para plan para implement para verify de forma confiável. Sem harness — sem testes, sem lints, sem verificadores — é impossível confiar output, você fica manualmente revisando tudo.
Workflows adaptativos: pesquisa larga, planejamento focado, implementação liberada
O workflow que Waldemar mostra é: research (use janela grande, 1 milhão de tokens, abra sub agents à vontade, traga links e contexto de indústria); plan (resuma numa spec ou design doc conciso, agora a janela tá 60-70%, é hora de limpar); implement (passa esse plano para agente novo com janela zerada, deixa implementar, sem micromanaging). Isso é bem diferente de Spec Driven tradicional que tenta fazer tudo num agente só ou com tesques granulares. Na fase de research, LLM pode fazer muita exploração e trazer ruído — é OK, depois disso você compacta em algo limpo. Na fase de implementação, você não quer spec driven micromanaging tesque-por-tesque com modelos bons — quer deixar implementar e depois validar forte. Waldemar mostra git worktree para paralelizar: enquanto um agente tá verificando implementação anterior, você já abre outro contexto para planejar e implementar o próximo item do roadmap. Isso quebra uma grande frustração da IA — esperar testes finalizarem é lento. Code review é camada final: a arquitetura mudou? Entrou algo novo na arquitetura? Teve regressão? Agente tocou em coisa não relacionada? Isso vem depois de automatizado passar.