Como Criar Agentes IA Personalizados na IDE
BMAD nao e magia — e um conjunto de system prompts bem escritos que dao personalidade e responsabilidade para cada agente. Aprenda a criar PO, Arquiteto, Dev e
Carregando
BMAD nao e magia — e um conjunto de system prompts bem escritos que dao personalidade e responsabilidade para cada agente. Aprenda a criar PO, Arquiteto, Dev e
Um agente IA sem persona e como contratar um estagiario sem dar nenhuma instrucao. Ele vai fazer algo, provavelmente. Mas vai fazer do jeito dele, com as suposicoes dele, e voce vai passar mais tempo corrigindo do que se tivesse feito sozinho.
O BMAD resolve exatamente esse problema. Em vez de lancar um prompt generico e torcer, voce cria agentes com identidade, responsabilidades e restricoes bem definidas. O resultado e um time virtual que funciona com coerencia. Se voce quer entender a metodologia por completo antes de entrar nos detalhes tecnicos, comece pelo <a href='/2025/agile-coding-is-here-90-ai-cod'>artigo sobre agile coding com IA</a> que explica a filosofia do BMAD do zero.
Todo agente BMAD e composto por tres camadas: a persona (quem ele e), as responsabilidades (o que ele faz), e as restricoes (o que ele nao faz). Sem as tres camadas, o agente fica generico e inutil.
A persona define a voz e o ponto de vista do agente. Um Product Owner pensa em usuario e valor de negocio, nao em codigo. Um Arquiteto pensa em escalabilidade e manutencao, nao em features rapidas. Essa diferenca de perspectiva e o que faz o BMAD funcionar — cada agente ve o problema pelo angulo certo.
Como Criar Agentes IA Personalizados na IDE. BMAD nao e magia — e um conjunto de system prompts bem escritos que dao personalidade e responsabilidade para cada agente. Aprenda a criar PO, Arquiteto, Dev e QA do zero dentro da sua IDE.
Cada agente precisa de acesso diferente ao repositorio. O agente PO precisa ler documentos de contexto, mas nao deve mexer em codigo. O agente Dev precisa ler e escrever arquivos de codigo, mas nao deve modificar documentos de arquitetura. Essa separacao de acesso evita que um agente bagunce o trabalho de outro.
Na pratica, voce implementa isso criando diretorios especificos por agente e colocando instrucoes no system prompt sobre onde cada um pode ler e escrever. Em ferramentas como Claude Code, voce tambem pode usar o CLAUDE.md para definir essas permissoes de forma declarativa.
O PO e o primeiro agente do workflow. Ele transforma ideias vagas em requisitos concretos. O segredo do prompt do PO e forcar ele a sempre questionar o 'por que' antes de escrever qualquer user story.
Com esse prompt, quando voce descreve uma ideia de produto, o agente PO nao vai direto para uma lista de features. Ele vai primeiro fazer perguntas de clarificacao: quem e o usuario principal, qual e o problema que ele tem hoje, o que ele faz atualmente para resolver esse problema. So depois ele transforma em stories.
Esse comportamento de questionamento e o que diferencia um bom agente PO de um ruim. Um agente sem persona aceita qualquer coisa. Um agente bem configurado empurra de volta quando a instrucao nao tem informacao suficiente para gerar algo util.
O Arquiteto recebe o PRD do PO e transforma em decisoes tecnicas. Ele nao precisa ser prescritivo em cada linha de codigo, mas precisa ser muito claro sobre estrutura de pastas, padroes de codigo, escolhas de stack e fronteiras entre modulos.
O pulo do gato no agente Arquiteto e a instrucao de justificar cada decisao. Quando o agente precisa argumentar por que escolheu PostgreSQL em vez de MongoDB, ou por que usou um monolito em vez de microservicos, ele tende a fazer escolhas mais maduras e menos influenciadas por hype.
O agente Dev e onde a maioria das pessoas passa mais tempo ajustando. Ele precisa de um contexto rico para gerar codigo de qualidade. A sacada e que ele deve sempre ler o Tech Spec antes de comecar a codar — isso e uma instrucao explicita no prompt.
O QA e o agente que a maioria dos devs pula. Erro crasso. Um agente QA bem configurado encontra problemas que voce nunca encontraria porque testa de um angulo diferente — o do usuario, nao do dev.
O mindset de testes no final do prompt faz uma diferenca enorme. O agente passa a testar casos que normalmente so aparecem em producao.
O workflow correto do BMAD tem uma sequencia clara. Quebrar essa sequencia e o erro mais comum de quem esta comecando.
A chave e que voce — o dev humano — faz a revisao entre cada sessao. BMAD nao e AI 100% autonoma, e AI supervisionada. Voce nao escreve o codigo, mas voce aprova cada etapa antes de avancar. Isso evita que um erro no PRD se propague para o codigo.
Abaixo tem um template de arquivo CLAUDE.md que voce pode colocar na raiz do seu projeto para ativar os 4 agentes no Claude Code com um unico arquivo de configuracao.
Depois de criar o CLAUDE.md, crie um arquivo para cada agente em /agents/po.md, /agents/arch.md, /agents/dev.md, /agents/qa.md com os prompts completos que mostramos acima. O Claude Code vai referenciar esses arquivos quando voce ativar cada agente.
Criar pasta /docs no repositorio
Criar pasta /agents no repositorio com os 4 arquivos de prompt
Criar CLAUDE.md na raiz com as instrucoes de uso
Testar o agente PO com uma ideia simples primeiro
Revisar o output do PO antes de passar para o Arquiteto
So comecar a codar depois que Tech Spec estiver aprovado
Bugs que custaram bilhões
Para ver o BMAD em acao com um exemplo real usando Claude Code no terminal, leia o <a href='/2026/bmad-claude-code-tutorial-completo'>tutorial completo de BMAD com Claude Code</a>.