Engenharia com agentes de IA: o pipeline de 5 habilidades que eu uso
Perdi um domingo inteiro com uma funcionalidade do Laravel que deveria ter levado quatro horas.
Não porque o código fosse difícil. O código era fácil. Perdi o domingo porque deixei o Claude Code começar a escrever antes de ter respondido às perguntas que teriam dado forma ao design. No meio do segundo prompt, percebi que o agente havia assumido um relacionamento um-para-muitos que precisava ser muitos-para-muitos, gerado trinta testes contra o contrato errado, e agora refatorava com total confiança, afundando cada vez mais na abstração incorreta. Na hora do jantar, eu havia revertido a branch para o primeiro commit e aberto um arquivo em branco.
Esse é o modo de falha da engenharia com agentes de IA que ninguém coloca na página de marketing. O agente vai escrever alegremente o que você pedir. Ele não vai te impedir de pedir a coisa errada. E como cada novo chat começa sem memória do anterior, o mesmo erro estará lá te esperando na segunda-feira de manhã, a menos que algo no seu fluxo de trabalho force as decisões a acontecerem antes que o código seja escrito.
Algumas semanas depois daquele domingo perdido, assisti a um engenheiro chamado John Lindquist percorrer o pipeline exato que ele usa para evitar isso, construído em torno de cinco habilidades com escopo definido que rodam em uma ordem fixa. Fez sentido. Reconstruí meu próprio fluxo de trabalho com as mesmas cinco habilidades, executei em três projetos em abril, e a diferença foi do tipo que eu teria rido se alguém me descrevesse há seis meses. Menos código reescrito. Mais funcionalidades entregues. Menos domingos perdidos.
Este é o pipeline. Cinco habilidades, a ordem em que são executadas, o que cada uma realmente faz por baixo dos panos, e as partes que não aparecem nas demos.
O modelo mental que muda como você usa agentes
Antes das habilidades, o modelo mental. Pule isso e o resto do artigo serão apenas comandos.
O agente não é um engenheiro júnior que vai melhorar no próximo sprint. O agente é um especialista sem memória — um engenheiro sênior sem lembranças do dia anterior, sem conhecimento da sua base de código que não tenha sido colado na janela de contexto atual, e sem capacidade de fazer uma pergunta de acompanhamento daqui a três dias. Cada sessão é o primeiro dia de trabalho.
Isso soa como uma desvantagem. Na verdade, é a restrição que faz o pipeline funcionar. Porque o agente não tem memória, cada decisão precisa ser explícita. Cada suposição precisa ser exposta. Cada requisito precisa ser escrito em algum lugar durável, em um arquivo que a próxima sessão consiga ler. O pipeline que vou descrever é, por baixo, apenas um sistema para produzir esses artefatos duráveis na ordem correta.
Há uma ideia mais profunda por trás que vem de The Design of Design de Frederick P. Brooks. Brooks descreve a engenharia como a exploração de uma árvore de design — cada decisão se ramifica em mais decisões, e você realmente não entende o design até ter percorrido os galhos o suficiente para ver quais se fecham e quais se abrem. A maioria do software que falha vem de cortar a árvore cedo demais. Você se comprometeu com uma folha antes de entender o tronco.
Um agente sem memória vai cortar a árvore no primeiro galho, a menos que algo o force a ir mais longe. Esse algo é a primeira habilidade do pipeline.
Habilidade 1: Grill Me — Entreviste a ideia antes de programar
A habilidade Grill Me é a coisa mais contra-intuitiva da lista. Você pensaria que o primeiro passo com um agente de IA é dar um prompt e vê-lo escrever código. Grill Me faz o oposto. Você entrega ao agente uma ideia aproximada — três frases, um parágrafo, uma solicitação de funcionalidade pela metade — e ele entrevista você.
A entrevista é estruturada em torno da árvore de design de Brooks. O agente identifica cada ponto de decisão que sua ideia implica mas não resolve, e te conduz por eles um a um. Para uma funcionalidade curta, pode fazer dezesseis perguntas. Para algo complexo — um sistema de faturamento multi-tenant, um pipeline de conteúdo com fluxos de trabalho ramificados, uma nova superfície de autenticação — já vi gerar de trinta a cinquenta perguntas antes de ficar satisfeito. A maioria dessas perguntas são as que eu deveria estar me fazendo e não estava.
Veja como foi uma sessão de Grill Me em um projeto real no mês passado. Eu disse que queria adicionar "espaços de trabalho em equipe" a um painel SaaS. Ele voltou com:
- O espaço de trabalho pertence a um único usuário ou a uma equipe?
- Se for uma equipe, um usuário pode pertencer a múltiplas equipes simultaneamente?
- Os espaços de trabalho herdam permissões da organização pai ou definem as suas próprias?
- O que acontece com os recursos de um espaço de trabalho quando seu proprietário sai da organização?
- A cobrança do espaço de trabalho é incluída na fatura da organização ou cobrada separadamente?
Eu estava prestes a escrever para o Claude "adicione espaços de trabalho em equipe ao painel". Se tivesse feito isso, o agente teria tomado cinco decisões ocultas por mim, escrito código baseado nessas suposições, e eu teria descoberto a discrepância por volta da pergunta 4, em produção, quando alguém saísse de uma equipe. A entrevista tornou as suposições visíveis antes de existir uma única linha de código.
O padrão é sempre o mesmo. A maioria das perguntas parece óbvia em retrospecto, que é exatamente por que vale a pena expô-las — perguntas óbvias em retrospecto são as que pulamos porque nosso cérebro nos diz que já sabemos a resposta. O agente não tem esse viés. Ele simplesmente percorre a árvore.
Você pode pensar na saída como uma transcrição, mas a transcrição não é o entregável. O entregável é o entendimento compartilhado — um estado em que você e o agente concordam sobre cada decisão consequente que a funcionalidade implica. Uma vez que você tem isso, a próxima habilidade assume.
Habilidade 2: Escreva um PRD — Fixe o entendimento compartilhado em forma durável
A saída da entrevista morre no momento em que a janela do chat fecha. Esse é o imposto do agente sem memória que mencionei antes. A habilidade Write a PRD existe para resolver esse problema de uma só vez: ela converte a transcrição do Grill Me em um Documento de Requisitos de Produto, formatado para um leitor de IA, e o envia como uma issue para o rastreador do seu projeto — geralmente uma issue do GitHub.
Há três coisas a notar sobre como essa habilidade é estruturada.
Primeiro, é escrita para o próximo agente, não para você. Um PRD tradicional se lê como um documento de vendas. Este se lê como uma assinatura de função com prosa. Cada requisito é testável. Cada restrição é explícita. Cada decisão de design da entrevista é capturada com o raciocínio por trás dela. A próxima sessão não terá acesso à sua memória de por que você escolheu muitos-para-muitos em vez de um-para-muitos — mas terá acesso ao PRD, e o PRD vai informá-la.
Segundo, vive no rastreador de issues. Não em uma pasta docs/, não no Notion, não colado em um chat. A razão importa: o rastreador de issues é o lugar onde cada outra ferramenta — humanos, agentes, CI, habilidades posteriores — vai procurar a fonte da verdade sobre essa funcionalidade. Colocar o PRD em qualquer outro lugar cria uma bifurcação na história do design que vai te assombrar em seis semanas.
Terceiro, te compromete. Uma vez que o PRD está no GitHub, você transformou uma conversa em um artefato. Seu eu futuro pode relê-lo. O futuro Claude pode relê-lo. Um colega de equipe que se junte ao projeto na semana que vem pode relê-lo. A conversa, com suas tangentes ramificadas e pensamentos pela metade, se foi. O que sobrevive é o design resolvido.
Eu costumava descartar PRDs como algo que product managers escreviam para justificar seus salários. Ver um agente sem memória avançar rapidamente por uma funcionalidade complexa usando um PRD conciso de uma página como sua única entrada de contexto mudou essa opinião completamente. O PRD não é burocracia. É a memória de trabalho do agente entre sessões.
Habilidade 3: PRD para Issues — Cortes verticais, não camadas horizontais
Aqui é onde a maioria dos fluxos de trabalho com IA desmorona. Você tem um PRD. Entrega ao agente. O agente decide "implementar a funcionalidade". Quarenta e cinco minutos depois você tem trezentas linhas de abstração pela metade e nenhum software funcionando.
A solução é a habilidade PRD to Issues, e ela empresta diretamente de um padrão que Andy Hunt e Dave Thomas chamaram de balas traçantes em The Pragmatic Programmer. Uma bala traçante é um corte vertical — uma implementação fina de ponta a ponta que toca cada camada do sistema da UI ao banco de dados, faz uma coisa pequena do início ao fim, e prova que o design funciona de ponta a ponta antes que qualquer camada seja construída completamente.
PRD to Issues pega o PRD e o decompõe em cortes verticais, cada um com o escopo de uma única bala traçante. Para a funcionalidade de espaços de trabalho em equipe que mencionei antes, a habilidade dividiu o PRD em quatro issues:
- Issue 1 (sem bloqueios): Criar o modelo
workspace, a migração e um único endpoint que permita a um usuário autenticado criar um espaço de trabalho para si mesmo. UI: um botão. Testes: criação do modelo, endpoint retorna 201, botão envia o payload correto. - Issue 2 (bloqueado pela Issue 1): Adicionar multi-associação — permitir que um usuário pertença a múltiplos espaços de trabalho, com uma tabela de junção
workspace_usere um seletor de espaços de trabalho na barra de navegação. - Issue 3 (bloqueado pela Issue 1, em paralelo com Issue 2): Adicionar as regras de herança de permissões do PRD. Lógica de domínio pura com sua própria suíte de testes.
- Issue 4 (bloqueado pelas Issues 2 e 3): Adicionar a lógica de consolidação de faturamento e a geração de linhas de fatura.
Duas coisas a notar sobre essa decomposição. Primeiro, a Issue 1 é uma funcionalidade completa e funcionando por si só — se você parasse depois da Issue 1, teria software entregável. Essa é a promessa da bala traçante: cada corte é utilizável de ponta a ponta. Segundo, o grafo de bloqueio é explícito. As Issues 2 e 3 podem rodar em paralelo, o que significa que posso criar dois agentes, um para cada issue, e eles vão trabalhar simultaneamente sem se atrapalharem.
Esse paralelismo é o diferencial que a maioria das equipes ainda não internalizou. Quando você para de pensar nos agentes como um único trabalhador e começa a pensá-los como um pool de trabalhadores com dependências explícitas, o throughput de uma sessão de engenharia muda de forma. Escrevi o modelo mental mais amplo para isso na arquitetura agent-swarm para Claude Code — PRD to Issues é o artefato concreto que torna o trabalho estilo enxame seguro em vez de caótico.
A outra coisa que PRD to Issues previne é o pior modo de falha da engenharia com IA: a armadilha do corte horizontal. Sem cortes verticais, um agente tenderá a construir primeiro todos os models, depois todos os controllers, depois todas as views, depois todos os testes. No meio do caminho, sua branch tem uma camada de dados completa que nada usa, uma UI mockada contra o contrato errado, e zero software funcionando. Com cortes verticais, você sempre tem um sistema funcionando; apenas um sistema funcionando menor que a funcionalidade final.
Habilidade 4: TDD — Vermelho, verde, refatorar (e por que o refatorar dói)
Agora você tem o PRD, tem as issues e está pronto para escrever código. É aqui que a habilidade TDD assume, e onde o pipeline começa a revelar como os agentes de IA realmente se comportam sob pressão.
A habilidade TDD executa o clássico ciclo vermelho/verde/refatorar, mas adaptado para agentes:
- Vermelho: O agente escreve um teste que falha para o próximo comportamento da issue atual. Executa o teste. Confirma que falha pelo motivo correto. (Esse sub-passo importa — agentes às vezes escrevem um teste que falha pelo motivo errado, e você vai descobrir duas horas depois quando "passar" não significa o que você pensava.)
- Verde: O agente escreve o código mínimo necessário para o teste passar. Executa o teste. Confirma que passa.
- Refatorar: O agente melhora o código sem mudar o comportamento. Executa o teste. Confirma que continua passando.
Os passos 1 e 2 funcionam lindamente com agentes. Claude é excelente escrevendo testes focados, igualmente excelente escrevendo implementações mínimas para que esses testes passem. A primeira vez que vi ele arrasar com uma classe de serviço do Laravel em vinte minutos, com cada método coberto por um teste que foi escrito antes do método existir, genuinamente senti que estava fazendo meu trabalho errado por uma década.
O passo 3 é onde mora o problema.
Aqui vai a parte honesta de todo este artigo. Agentes de IA são profundamente relutantes em refatorar seu próprio código dentro do mesmo contexto. O padrão é assim: você escreve um teste verde, o agente escreve o código mínimo, você diz para refatorar, e ele retorna o mesmo código com um comentário dizendo "isso já está bem estruturado". Ele não está mentindo. Do seu próprio contexto, o código parece bom. O problema é que o agente esteve olhando para sua própria lógica por uma hora e perdeu a perspectiva necessária para ver o mau cheiro.
A solução que está funcionando para mim — e que a habilidade TDD incorpora — é separar o passo de refatoração em uma nova sessão de agente. Nova janela de contexto. Sem histórico de ter escrito o código original. Você entrega à nova sessão o teste que falhava e depois passava junto com a implementação verde, e pede para refatorar. Sem o viés do autor original, ele está disposto a destrinchar o código. O teste lhe dá um contrato contra o qual refatorar. A refatoração termina. Você faz commit.
Este é o momento que muita gente perde quando diz "a IA realmente não consegue fazer TDD". Consegue — mas só se você tratar cada fase do ciclo vermelho/verde/refatorar como uma sessão de agente com escopo separado, não como uma única conversa. A habilidade impõe esse escopo. O princípio é o mesmo que cobri em por que precisão nos prompts supera criatividade — o agente é tão bom quanto o contexto que você dá, e isso inclui o contexto que você não dá.
Há uma segunda sutileza que a habilidade TDD lida. Ela se recusa a deixar o agente pular o passo vermelho. Se você deixar um agente escrever um teste contra código existente, ele vai escrever um teste que passa na primeira execução — e você não vai ter ideia se o teste está realmente exercitando o comportamento que te importa. A habilidade bloqueia isso impondo o estado de falha primeiro. Você não avança até o teste falhar por uma razão que consiga articular.
Habilidade 5: Melhorar a arquitetura da base de código — Quando o pipeline volta ao início
As quatro habilidades anteriores vão te dar uma funcionalidade funcionando. Elas não vão, por si só, prevenir sua base de código de apodrecer. Ao longo de cinco ou dez funcionalidades, você acumulará o tipo de dívida estrutural que não aparece em nenhum PR individual mas lentamente torna cada funcionalidade futura mais difícil de construir. A quinta habilidade é o que captura essa deriva.
Improve Codebase Architecture é diferente das outras. Ela não roda dentro do pipeline linear — roda periodicamente, entre ciclos de funcionalidades, como um passe de limpeza. Seu trabalho é olhar para a base de código atual e propor refatorações deliberadas, depois transformar as melhores em novas issues que reentram no pipeline pelo topo.
A forma como funciona não se parece com nada no resto do fluxo de trabalho. A habilidade gera três ou mais sub-agentes em paralelo, cada um com o prompt de propor um design de interface radicalmente diferente para a área da base de código sendo refatorada. Três sub-agentes porque um só confirmaria o status quo e dois cairiam em uma dicotomia — três é o menor número que força alternativas genuínas a surgirem.
Rodei isso no mês passado em um módulo de pipeline de conteúdo que havia ficado bagunçado. Os três sub-agentes voltaram com:
- Proposta A: Um pipeline funcional puro de passos combináveis, cada um uma função pura sobre um payload tipado.
- Proposta B: Um design orientado a eventos com uma fila e um conjunto de consumidores independentes.
- Proposta C: Uma hierarquia tradicional de classes de serviço com uma classe base e três estratégias concretas.
O agente pai avaliou as três contra as restrições reais da base de código — cobertura de testes, forma de deploy, o modelo de dados existente — e recomendou um híbrido de A e B: passos funcionais puros por dentro, despachados sobre a infraestrutura de filas existente. Nenhuma das três propostas puras era a resposta certa. O híbrido era. E eu nunca teria chegado ao híbrido por conta própria, porque meu cérebro estava ancorado na forma existente de classes de serviço por meses.
A saída da habilidade é um RFC, também arquivado como uma issue do GitHub. O RFC descreve a refatoração proposta, as alternativas que foram consideradas e rejeitadas, o raciocínio por trás da recomendação, e o caminho de migração incremental sugerido. Uma vez que o RFC é aprovado, ele reentra no pipeline no passo 1 — você faz Grill Me na proposta de refatoração, escreve um PRD para ela, decompõe em issues, desenvolve com TDD.
Esse ciclo é a parte mais difícil de comunicar sem ver funcionando. O pipeline não é realmente linear. É um loop. Funcionalidades passam por 1→2→3→4. Refinamentos periódicos de arquitetura passam por 5→1→2→3→4. Ao longo de um trimestre, a base de código se compõe em uma direção que você escolheu em vez de derivar em uma direção que ela encontrou sozinha.
A linha do tempo — Como uma funcionalidade real se move pelo pipeline
Deixe-me percorrer como isso realmente se parece no tempo, para a funcionalidade de espaços de trabalho em equipe que sigo referenciando, para que a abstração ganhe forma.
Segunda-feira de manhã, 45 minutos. Rodo Grill Me sobre a ideia aproximada. Vinte e duas perguntas. Respondo todas. No final da sessão, a árvore de design foi percorrida o suficiente para que eu consiga descrever a funcionalidade em um único parágrafo sem ambiguidades.
Segunda-feira de manhã, 20 minutos. Rodo Write a PRD. A habilidade gera o documento a partir da transcrição da entrevista, reviso, edito duas frases e envio como uma issue do GitHub. Issue #341.
Segunda-feira de manhã, 15 minutos. Rodo PRD to Issues. Decompõe a #341 nas quatro sub-issues que descrevi acima, com o grafo de bloqueio anexado. Issues #342, #343, #344, #345.
Segunda-feira à tarde até terça-feira. Rodo TDD na issue #342 (o corte fundamental). Cerca de quatro horas no total. Vermelho, verde, refatorar em cada comportamento. Mantenho o passo de refatoração em uma janela de contexto separada. Issue fechada.
Quarta-feira. Crio duas sessões paralelas de TDD, uma na #343 e outra na #344. São issues independentes por design. Cerca de três horas cada, rodando em janelas paralelas. Ambas fecham.
Quinta-feira de manhã. Rodo TDD na #345, a consolidação de faturamento. Cerca de cinco horas, porque a superfície de testes é mais ampla. Fecha no final do dia.
Sexta-feira. Rodo Improve Codebase Architecture contra o módulo de espaços de trabalho. Os três sub-agentes propõem três estruturas. O pai recomenda uma pequena refatoração para extrair a lógica de verificação de permissões em um módulo puro. RFC arquivado como issue #346. Decido que vale a pena, rodo o loop novamente e entrego a refatoração na sexta à tarde.
Total transcorrido: cerca de trinta horas de trabalho focado ao longo de cinco dias, para uma funcionalidade que eu teria estimado em duas semanas antes de começar a rodar esse pipeline. A razão pela qual comprimiu não é que os agentes são mais rápidos que eu digitando. São — mas digitar nunca foi o gargalo. A razão é que o pipeline eliminou quase todos os ciclos de retrabalho que costumavam devorar os três dias do meio da semana.
A parte honesta — Onde esse pipeline falha
Estive te contando o que funciona. O artigo não ganha sua confiança a menos que eu também diga onde ele quebra.
O pipeline assume que você consegue escrever boas respostas durante o Grill Me. Se você não consegue articular o que realmente quer, as perguntas apenas expõem a lacuna. A habilidade não é um substituto para pensar — é uma função forçadora do pensamento. Vi desenvolvedores tentarem usar Grill Me como uma forma de "descobrir o que querem" no meio da sessão, e o resultado é uma transcrição cheia de "não sei, o que você acha?" o que produz um PRD que é efetivamente as preferências do agente, disfarçadas como as do usuário. Esse PRD será então o contrato que cada agente posterior cumprirá, e você descobrirá na issue #4 que as preferências do agente não eram as suas.
O problema de refatoração do TDD não se resolve completamente, mesmo com uma sessão nova. Às vezes o novo agente vai olhar o código e produzir uma limpeza marginal que perde o problema estrutural mais profundo. O padrão ao qual cheguei: rodo a refatoração duas vezes, em duas sessões frescas separadas, e olho ambas. Se concordam, faço commit. Se discordam, a discordância geralmente é onde vive a refatoração real, e vou escolher a melhor das duas ou entregar ambas a um terceiro agente para reconciliar. Isso é mais lento do que eu gostaria.
Issues paralelas não são realmente grátis. Quando rodo duas sessões TDD em paralelo sobre issues independentes, estou dividindo minha própria atenção — e esse é o custo real, não o compute do agente. O grafo de bloqueio em PRD to Issues previne os agentes de interferirem um com o outro no código, mas não pode prevenir que eu faça mal a troca de contexto. Me limito a duas sessões paralelas por essa razão. Três me quebram.
A habilidade de arquitetura pode refatorar demais. A primeira vez que rodei Improve Codebase Architecture contra um módulo saudável, ela gerou três propostas sérias de refatoração para código que não precisava ser refatorado. A habilidade tem viés para encontrar trabalho. Você é o freio. Se nenhuma das três propostas melhora materialmente a base de código, a resposta certa é pular a refatoração e re-rodar a habilidade em dois meses. Disciplina importa mais aqui do que em qualquer outro passo.
O tamanho da habilidade não é qualidade da habilidade. As duas melhores habilidades desse pipeline — Grill Me e PRD to Issues — são curtas. Talvez cem linhas cada. Os escritores de habilidades que vi produzir os piores resultados são os que tratam o tamanho da habilidade como indicador de rigorosidade. A precisão em quando uma habilidade dispara e o que ela produz importa muito mais do que quanto texto de instrução ela contém. Cobri esse padrão em como as habilidades do Claude realmente executam um fluxo de trabalho — o mesmo princípio se aplica aqui, em dobro.
Como isso transforma o que um engenheiro faz o dia todo
Afaste-se das cinco habilidades por um momento. A forma de trabalho que o pipeline produz é genuinamente diferente do que eu fazia em 2024, e vale a pena dizer em voz alta o que mudou.
Escrevo menos código. Escrevo mais contratos. O PRD é um contrato. As issues são contratos. Os testes são contratos. Os RFCs são contratos. A implementação real é cada vez mais algo que um agente produz contra um contrato que eu redigi, e meu tempo investido por funcionalidade se deslocou fortemente para o lado da escrita de contratos.
Penso mais em árvores de decisão, menos em sintaxe. As três primeiras habilidades do pipeline são sobre resolver a árvore de design antes que qualquer código exista. As duas seguintes são sobre executar de forma limpa contra a árvore resolvida. Uma vez que notei esse padrão, meus hábitos de engenharia fora do pipeline também começaram a mudar — me pego, no meio de uma conversa sobre uma funcionalidade, fazendo o tipo de perguntas que Grill Me faz, antes que qualquer ferramenta rode.
Confio no paralelismo de uma forma que nunca fiz antes. Duas sessões TDD simultâneas em issues independentes soa como um truque de produtividade. Na verdade é um modo diferente de engenharia. A habilidade mental que exige é a capacidade de projetar o grafo de bloqueio corretamente a montante — se você decompõe mal as issues, sessões paralelas colidem. Se decompõe bem, paralelismo é quase grátis. O pipeline pune má decomposição e recompensa boa decomposição, o que é um loop de feedback que eu nunca tive antes.
Trato memória como um artefato, não como uma suposição. Cada decisão importante vive em um lugar que o futuro Claude pode ler. O PRD, as issues, os nomes dos testes, as mensagens de commit, os RFCs — tudo é estruturado como se um engenheiro sênior sem memória pudesse pousar no repositório amanhã sem contexto, porque na prática, é exatamente isso que acontece toda vez que abro uma nova sessão de agente.
Se você quer um olhar mais profundo sobre como o sistema de habilidades subjacente permite esse tipo de composição, o guia de arquitetura de habilidades de agente é o post para o qual eu te direcionaria em seguida. O pipeline que descrevo aqui é como habilidades se parecem quando você as conecta com intenção.
O curso que estou realmente assistindo
Seria desonesto se não mencionasse de onde a maioria desses padrões surgiram para mim. Matt Pocock — o engenheiro por trás de grande parte da educação sobre TypeScript na qual silenciosamente me apoiei por anos — conduziu uma coorte de duas semanas chamada Claude Code for Real Engineers de 30 de março a 13 de abril de 2026, e o currículo se mapeia quase exatamente ao pipeline que acabei de descrever. Protocolo Plan/Execute/Clear. Implementação de balas traçantes. Escrita de PRDs para leitores de IA. O padrão de loop autônomo no final da segunda semana.
O curso custa $795 no AI Hero. Não sou afiliado, não recebo comissão, e não me inscrevi na coorte ao vivo — a versão sob demanda é o que está disponível agora, e estou avaliando se a estrutura justifica o custo dado que a maioria dos padrões são públicos e reproduzíveis se você estiver disposto a montá-los. A opinião honesta: se você quer comprimir a curva de aprendizado de meses para semanas e prefere não montar o pipeline de cinco habilidades a partir de posts de blog como este, a coorte é uma aposta razoável. Se você é paciente e o pipeline acima te dá o suficiente para começar, provavelmente consegue chegar lá por conta própria.
O que eu direi é que a categoria que esse curso ocupa — prática estruturada de engenharia em torno de agentes de IA, em oposição a conteúdo de "dicas e truques" — é a que mais vai importar nos próximos dois anos. O mercado vai se bifurcar em engenheiros que tratam a IA como um acelerador de digitação e engenheiros que a tratam como um colaborador sem memória que precisa de um pipeline real. O segundo grupo vai dar voltas ao redor do primeiro.
Além das cinco habilidades — Para onde estou avançando
O pipeline como está é sólido. Não é onde quero que ele termine.
O que estou experimentando agora é a integração autônoma de agentes nas bordas. Especificamente: um agente agendado que re-roda Improve Codebase Architecture contra o repositório a cada duas semanas, arquiva RFCs como issues e me marca para revisão. Não preciso lembrar de rodar a habilidade. A habilidade roda sozinha. Os RFCs chegam na minha fila. Eu aprovo e reentro no pipeline, ou fecho como wontfix. O problema da deriva arquitetural se torna um checkbox passivo em vez de um hábito ativo.
A outra peça é a disciplina da janela de contexto ao longo do pipeline. Cada passo produz um artefato que se torna o contexto de entrada para o próximo passo. Se o artefato é muito verboso, o contexto do próximo passo enche e o agente fica menos inteligente. A arte está em fazer cada artefato o mais conciso possível enquanto ainda seja um contrato completo. Tenho aparado meu template de PRD durante o último mês, e a qualidade do código downstream melhorou mensuravelmente cada vez que cortei um parágrafo que não estava contribuindo. Esse princípio — a ideia de que menos contexto escolhido com precisão supera mais contexto curado vagamente — é a maior alavanca na engenharia com agentes de IA da qual ninguém fala nos tutoriais.
A terceira peça é a aplicação agnóstica a linguagem. Tenho rodado esse pipeline contra Laravel, contra Next.js, contra um pipeline de dados em Python, e contra um repositório de infraestrutura pesado em Bash. Funciona nos quatro. As habilidades não sabem em que linguagem estão operando; elas operam sobre a árvore de design, o PRD, as issues, os testes e os padrões arquiteturais. Esse agnosticismo em relação à linguagem é a propriedade que me faz pensar que esse pipeline é o certo para investir nos próximos dois anos, independentemente do stack em que eu acabe trabalhando.
O que fazer antes da segunda-feira de manhã
Se você leu até aqui e está convencido da ideia, esta é a ordem em que sugiro que tente. Não instale as cinco habilidades de uma vez. O pipeline é sequencial por uma razão, e tentar adotá-lo como um Big Bang vai sobrecarregar qualquer fluxo de trabalho que você tenha atualmente.
- Esta semana: Instale Grill Me. Use na próxima funcionalidade que de outra forma simplesmente pediria ao Claude para escrever. Observe as perguntas que faz. Observe quais você não conseguiria responder sem ele. Esse é o valor.
- Próxima semana: Adicione Write a PRD. Passe a saída do Grill Me por ela. Arquive o PRD como uma issue do GitHub. Acostume-se com o artefato vivendo em um lugar durável.
- Na semana seguinte: Adicione PRD to Issues. Observe suas funcionalidades se decomporem em balas traçantes. Aprenda a distinguir bons cortes verticais de ruins — os ruins voltam como uma única issue que não fecha.
- Semana quatro: Adicione TDD. Prepare-se para a fricção do passo de refatoração. Resolva rodando a refatoração em uma sessão separada.
- Semana seis: Adicione Improve Codebase Architecture. Rode uma vez. Veja se confia na saída o suficiente para agir com base nela.
Na oitava semana você terá um pipeline funcionando. Na décima segunda semana estará projetando suas próprias variações. No sexto mês o fluxo de trabalho vai parecer tão natural quanto o que você tinha antes dos agentes existirem, exceto mais rápido, mais deliberado e mais difícil de quebrar.
O domingo que perdi no Laravel foi o que eu precisava perder. Foi o custo de aprender, nos meus ossos, que a engenharia com agentes de IA não é sobre escrever prompts e ver código aparecer. É sobre produzir os artefatos certos na ordem certa para que um especialista sem memória possa pegar o trabalho em qualquer ponto e continuá-lo sem perder o design. O pipeline é como você torna isso possível.
Não perdi um domingo assim desde então.
Perguntas frequentes
O que "engenharia com agentes de IA" realmente significa na prática?
Engenharia com agentes de IA significa tratar o agente como um engenheiro sênior sem memória que precisa de cada decisão, requisito e restrição capturados como um artefato durável antes que o código seja escrito. Na prática é um pipeline fixo — Grill Me, PRD, Issues, TDD, Refatoração de Arquitetura — onde cada passo produz o contexto do qual o próximo passo depende. Para o percurso completo, consulte as seções do pipeline acima.
Essas habilidades só funcionam no Claude Code?
As cinco habilidades são agnósticas em relação a linguagem e conceito — os padrões subjacentes (árvore de design, cortes verticais, vermelho/verde/refatorar, sub-agentes em paralelo) funcionam com qualquer runtime de agentes que suporte habilidades ou instruções equivalentes com escopo definido. Claude Code é onde as rodo porque o sistema de habilidades lá é o mais maduro, mas o mesmo pipeline pode ser reproduzido em outros ambientes com comandos slash personalizados ou system prompts.
Por que os agentes de IA se recusam a refatorar seu próprio código?
Agentes têm dificuldade em refatorar dentro do mesmo contexto porque estiveram raciocinando sobre o código durante toda a sessão e perderam a perspectiva necessária para detectar o mau cheiro. A solução é abrir uma nova sessão de agente sem contexto prévio, entregar apenas o teste que falhava e depois passava junto com a implementação verde, e pedir para refatorar contra o contrato do teste. O princípio é coberto na seção de TDD acima.
O que é um "corte vertical" ou "bala traçante" neste contexto?
Um corte vertical é uma implementação de ponta a ponta que toca cada camada do sistema — UI, API, lógica de domínio, banco de dados — mas faz apenas uma coisa pequena do início ao fim. Originou-se como o padrão de "bala traçante" em The Pragmatic Programmer e é a unidade de trabalho em que PRD to Issues decompõe uma funcionalidade. O resultado é que cada issue que você fecha entrega software funcionando, não uma camada pela metade.
Os $795 do curso Claude Code for Real Engineers valem a pena?
A coorte cobre os mesmos padrões descritos neste artigo — Plan/Execute/Clear, escrita de PRDs para leitores de IA, implementação de balas traçantes, loops autônomos — em um formato estruturado de duas semanas. Vale o custo se você quer comprimir a curva de aprendizado e prefere instrução guiada em vez de montar o pipeline a partir de fontes públicas. A versão sob demanda é o que está disponível atualmente; coortes ao vivo são re-rodadas periodicamente.
Vamos trabalhar juntos
Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.
- Fiverr (construções personalizadas e integrações): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e branding): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
