Engenharia com agentes de IA não é escrever prompts melhores, é antecipar o seu esforço. O agente é um executor fenomenal e um analista de requisitos medíocre. Por isso passo toda feature não trivial por cinco skills, em ordem, e cada uma existe agora mesmo como uma pasta real no meu diretório ~/.claude/skills. Instalei o conjunto a partir da coleção de skills de Matt Pocock. Aqui está o pipeline, com as partes de cada arquivo de skill que fazem o trabalho de verdade.
O modelo mental: a ambiguidade é a parte cara
Toda sessão de agente que deu errado para mim tem a mesma causa raiz: ambiguidade que sobreviveu até a geração de código. Um desenvolvedor júnior humano esbarra numa ambiguidade e pergunta. Um agente esbarra numa ambiguidade e escolhe, em silêncio, na velocidade da máquina, e depois constrói cinquenta decisões consistentes em cima da escolha errada.
Então o pipeline é organizado por um único princípio: eliminar a ambiguidade na fase mais barata possível. Uma suposição errada custa uma frase para corrigir durante uma entrevista, um parágrafo num PRD, uma issue num tracker e uma branch inteira depois da implementação.
Skill 1: grill-me — entreviste a ideia antes de qualquer código
grill-me instrui o agente a me entrevistar sem trégua sobre um plano, uma pergunta de cada vez, resolvendo cada ramo da árvore de decisão com uma resposta recomendada anexada a cada pergunta. A instrução no meu SKILL.md que realmente se paga:
Se uma pergunta puder ser respondida explorando o codebase, explore o codebase no lugar disso.
Na prática, isso significa que o agente me faz cinco perguntas em vez de vinte, porque as outras quinze podiam ser respondidas a partir do repositório. As cinco que ele faz são exatamente as que eu estava evitando.
Skill 2: to-prd — congele o entendimento enquanto ainda está quente
No momento em que o interrogatório termina, o entendimento compartilhado existe apenas na janela de contexto de uma sessão, o armazenamento mais perecível do planeta. to-prd o converte num documento durável, e o arquivo da skill diz explicitamente: NÃO entreviste o usuário, apenas sintetize o que você já sabe. O interrogatório já aconteceu; um segundo interrogatório seria cerimônia.
Dois detalhes da skill importam. Primeiro, a skill puxa para módulos profundos, muita funcionalidade atrás de uma interface pequena e estável, e faz o agente conferir comigo as fronteiras de módulo propostas antes de escrever. Segundo, ela publica o PRD finalizado diretamente no issue tracker do projeto com o label ready-for-agent. Esse label é o contrato de passagem de bastão: qualquer sessão, em qualquer máquina, inclusive um agente paralelo que nunca viu a conversa, pode pegar o trabalho do zero. Essa propriedade é o que torna rodar vários agentes em paralelo viável, para começo de conversa.
Skill 3: to-issues — fatias verticais, não camadas horizontais
to-issues divide o PRD em issues, e a única regra que importa é a direção do fatiamento. Fatias horizontais ("construir a migration", "construir a camada de serviço", "construir a UI") são como os agentes se desviam, porque cada camada força o agente a inventar o contrato da camada acima dela. Fatias verticais ("um usuário consegue arquivar um post e vê-lo sumir do índice") prendem cada camada a um comportamento observável.
A primeira fatia é sempre um tracer bullet: o caminho mais fino possível por todas as camadas da feature. Ela expõe surpresas de integração enquanto o diff ainda é pequeno o bastante para ser lido de uma só vez.
Skill 4: tdd — red, green e o refactor que ninguém quer fazer
A minha skill tdd começa com filosofia, não com mecânica, e a filosofia é a parte de que os agentes mais precisam: testes verificam comportamento por meio de interfaces públicas, não detalhes de implementação. Se um refactor quebra um teste mas o comportamento não mudou, o teste estava errado.
A seção mais importante da skill é um alerta de antipadrão em negrito: não escreva todos os testes primeiro e depois toda a implementação. Isso é fatiamento horizontal de novo, contrabandeado pela suíte de testes, e é o comportamento padrão de todos os modelos que já usei, porque emitir trinta testes numa resposta parece progresso. O red-green-refactor de verdade é um teste falhando, o mínimo de código para ficar verde, refactor, repetir. É mais lento por minuto e dramaticamente mais rápido por feature.
O passo de refactor é onde os agentes são mais fracos. Deixado por conta própria, um modelo trata testes verdes como trabalho concluído. O meu só refatora de forma confiável porque a skill exige isso como uma fase nomeada, e porque o loop inteiro ecoa a disciplina de planejar primeiro que descrevi em a estratégia do Claude Code que a maioria dos desenvolvedores não percebe.
Skill 5: improve-codebase-architecture — quando o pipeline volta ao início
Depois que três ou quatro features chegam à mesma área, a entropia vence localmente: módulos rasos se acumulam, aparecem helpers quase duplicados, uma interface que fazia sentido para a fatia um está errada para a fatia nove. improve-codebase-architecture é a skill que rodo nesse momento. Ela examina a área, identifica módulos rasos e propõe consolidá-los em módulos mais profundos, com os testes da skill quatro atuando como a rede de segurança que torna barato aceitar a proposta. Escrevi um relato de campo completo sobre essa skill em Deep Modules: a skill que está salvando o meu codebase.
Essa também é a resposta honesta para "por que os agentes nunca refatoram o próprio código?". Eles refatoram, mas só quando a refatoração é um mandato explícito e nomeado, e não uma virtude implícita.
Onde o pipeline desmorona
Três modos de falha honestos. Primeiro, mudanças minúsculas: rodar cinco skills para renomear uma chave de configuração é cerimônia, e o meu próprio CLAUDE.md mantém uma lista explícita de exceções para trabalho trivial. Segundo, trabalho genuinamente exploratório: quando não sei o que quero, me interrogar produz respostas confiantes para perguntas que eu ainda não deveria estar respondendo; primeiro o protótipo, depois o pipeline. Terceiro, PRDs desatualizados: se a implementação diverge do documento e ninguém o atualiza, o tracker vira ficção. A disciplina de registrar decisões por escrito precisa ir além do kickoff, e é o mesmo músculo por trás do fluxo de nove skills que uso diariamente.
O que isso faz com a descrição do cargo
Rode esse pipeline por um mês e você percebe que o seu dia se inverteu. A maior parte do seu tempo de teclado vai para entrevistas, revisão e decisões de fatiamento. O agente fica com a digitação. O seu julgamento fica com a alavancagem. Não é um trabalho menor, é a metade sênior do trabalho, aplicada mais cedo e com mais frequência.
Se você está olhando para um backlog e se perguntando se isso se sustentaria no seu stack, essa é uma conversa que tenho tido muito ultimamente, com mais de 8 anos e mais de 1.500 projetos de cicatrizes nas costas. Me conte o que você está construindo e eu direi honestamente se um pipeline de agentes se encaixa nisso, e onde ele vai morder você primeiro.
