Meu Workflow com IA: Skills, Agentes e um Segundo Cérebro

Deixa eu adivinhar como é o teu uso de IA no dia a dia. Você abre um chat, cola um pedaço de código, pede uma função e copia o resultado. Funciona, né? Destrava o momento e segue o jogo.

Só que isso não é um workflow. É um truque. E eu fiquei preso nesse truque por um bom tempo até cair a ficha de uma coisa: o ganho de verdade não tá no prompt esperto. Tá na estrutura em volta dele.

Esse é o workflow que montei na TryTech depois de mais de um ano apanhando, e não inventei nada do zero aqui. Fui juntando ideia de workflow que vi colega usando, pegando o que funcionava pra mim e descartando o resto, até virar esse setup. São três peças: um contrato escrito, skills que viram um pipeline, e uma memória externa que não morre quando a sessão fecha.

O contrato: CLAUDE.md

Começa com um arquivo de texto, simples assim. O Claude Code lê um CLAUDE.md global toda vez que abre, e o meu é basicamente um contrato de engenharia. Minimalismo implacável (a melhor linha de código é a que você não escreve), commit pequeno e em imperativo, validação só na borda do sistema, e a regra de ouro do TDD científico, que eu já chego nela.

Sabe o que isso resolve? Eu paro de repetir instrução. A IA já chega sabendo que eu prefiro deletar a adicionar, que duplicação eu tolero até a terceira vez, e que pergunta se faz tudo de uma vez, não de gota em gota.

Pensa comigo: se você usa IA todo dia e ainda digita “não põe comentário óbvio” toda santa semana, você tá pagando um pedágio à toa. Escreve isso uma vez, num arquivo que a ferramenta sempre lê, e acabou.

Skills: workflow com nome

O coração do setup são as skills. No Claude Code elas funcionam como comandos que carregam um workflow inteiro. Em vez de explicar o processo de novo a cada vez, eu chamo o processo pelo nome. As que eu mais uso formam um ciclo fechado de desenvolvimento:

• /po veste o chapéu de Product Owner: explora o codebase, faz as perguntas certas e escreve um PRD focado em requisito de produto, não em solução técnica.
• /dev pega esse PRD (ou uma issue, ou um prompt solto) e implementa em TDD estrito, em três modos: par de agentes (um dirige, o outro navega e fiscaliza), solo, ou pareando comigo no teclado.
• /review solta revisores em paralelo pra segurança, performance e qualidade, e por cima ainda joga um auditor red team que revisa os revisores, atrás de falso positivo e severidade inflada.
• /qa age como um segundo dev: sobe o app, testa no navegador o que foi construído e valida comportamento de verdade, não só teste verde.
• /commit fecha tudo com commits pequenos, convencionais, escritos como gente escreve.

E olha, não tem mágica nenhuma nisso. É a velha disciplina de processo, só que executável. Cada skill é um markdown que descreve como eu trabalharia se eu tivesse tempo infinito. A diferença é que agora a IA tem esse tempo.

TDD científico, ou: como não cair no conto da própria IA

Sim, eu sei o que você tá pensando: IA escrevendo o teste e a implementação ao mesmo tempo é a raposa tomando conta do galinheiro. Concordo contigo. É exatamente por isso que existem as regras.

O maior perigo de codar com IA não é ela errar. É ela errar com confiança, te entregando algo bonito e quebrado com a maior cara de pau. Minha defesa é um TDD que cheira a método científico: o teste que falha é a hipótese, a implementação é o experimento, e tem um passo que quase ninguém faz, que é reverter a correção depois do verde só pra confirmar que o teste volta a falhar. Se ele não fica vermelho de novo, ele nunca provou nada. Nunca.

Duas regras fecham o jogo. Cada passo muda o teste ou o código de produção, nunca os dois ao mesmo tempo, porque assim um dos lados continua honesto. E se não dá pra reproduzir o bug, a sessão para e eu assumo. Aqui não se chuta.

Quer um exemplo concreto? Numa sessão recente do nosso servidor web em C, isso virou até uma receita: stub que retorna -1 pra ter um RED comportamental de verdade. Por quê? Porque teste que nem compila por falta de header é um RED fraco demais pra você confiar nele.

O segundo cérebro: vault no Obsidian

A IA tem memória de peixe entre uma sessão e outra, e fingir que não tem sai caro. Minha saída foi grudar o workflow num vault Obsidian, com três skills cuidando dele. O /note captura uma ideia ou um TIL na hora em que aparece, o /recap fecha cada sessão gravando o que aprendi, o que decidi e o que ficou em aberto, e o /vault traz tudo isso de volta quando eu preciso.

O recap é o herói silencioso da história. Toda sessão que importa termina num arquivo estruturado: contexto, o que aprendemos com os detalhes técnicos no capricho, o que foi decidido e por quê, e as pontas soltas. Aí passa duas semanas, eu volto pro mesmo assunto, e a IA não começa do zero. Ela lê o recap e continua a conversa de onde a gente parou.

Quer saber? Foi assim que esse post aqui nasceu. Eu pedi ideia, e a primeira coisa que a IA fez foi fuçar os recaps recentes do vault.

O que muda no fim das contas

Vamos ser honestos: nada disso aposenta o engenheiro, e eu desconfio de quem te promete o contrário. O que muda é pra onde o meu tempo vai. Escrever PRD, montar suite de teste, revisar PR em três frentes, documentar sessão, tudo isso virou processo executável. E o que sobra pra mim é o que sempre foi o trabalho de verdade: decidir o que construir, pesar trade-off e dizer não pra complexidade que ninguém pediu.

Se você se vê usando IA todo dia com aquela sensação de que tá sempre recomeçando, o conselho é um só. Para de colecionar prompt e começa a escrever os teus workflows. Um arquivo de cada vez.

Love to you all.