Como transformar o resultado do REA em código no seu projeto, da investigação à feature

O REA não te entrega o código do app que você investigou, ele te entrega uma explicação com evidências

A feature que vai parar no seu projeto é implementação SUA, e entender isso muda tudo no jeito de usar a ferramenta

Fala aí, beleza? O REA (Reverse Engineer Anything) é um servidor MCP e uma CLI open source, com licença MIT, que conecta agentes de programação a ferramentas de inspeção de binários nativos, apps JavaScript/Electron, assemblies .NET e sites

O repositório oficial é o morluto/rea no GitHub, criado em abril de 2026 e que viralizou no começo de outubro de 2026 depois de meses quietinho

O fluxo prometido pelo projeto é: o agente inspeciona o app sem o código-fonte, explica como a feature funciona, mostra as evidências e constrói uma versão para o seu projeto

O pulo do gato está entre o "mostra as evidências" e o "constrói"… e é exatamente aí que este post foca 🙂

O que você precisa antes de começar:

A lista é curta, mas cada item importa:

• Node.js em uma destas versões: 22.x (>=22.19), 24.x (>=24.11) ou 26+, mais o npm
• Um agente compatível: o setup suporta Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros
• Um alvo que você pode examinar: app que você possui ou tem autorização para analisar, dentro dos usos que o projeto declara (pesquisa legal, educação, interoperabilidade, preservação de software e análise autorizada)
• Um projeto seu, onde a feature vai entrar

Sobre o alvo, o REA trabalha com binários nativos, apps JavaScript/Electron, assemblies .NET e sites

Se o agente for o Claude Code, vale ter claro o que o Claude Code faz e o que continua sendo trabalho seu, porque essa divisão aparece de novo lá no passo 4

Passo a passo: da investigação do REA ao código no seu projeto

A lógica geral é simples: primeiro tu entende, depois tu especifica, só então tu pede código

Bora ver cada etapa?

1. Instale o REA com o setup:

Com Node e npm no lugar, roda o setup pelo npx:

npx rea-agents@latest setup

O README também mostra a forma sem o @latest:

npx rea-agents setup

O que esse comando faz? Ele registra o servidor MCP do REA e as instruções de workflow correspondentes no seu agente, e faz backup da configuração que já existia antes de mexer

Ou seja, se algo sair estranho, a config antiga não se perdeu =)

Checagem: confirme que a configuração do seu agente passou a incluir o servidor MCP do REA

Se preferir registrar o MCP na mão, a documentação de instalação do repositório traz o registro manual

Erro comum deste passo: Node fora das versões exigidas. Uma 22 antiga, abaixo da 22.19, não atende ao requisito, então confira a versão instalada antes de culpar o setup

2. Escreva o prompt da investigação:

O README traz este prompt de exemplo no quick start:

Understand how search works in the Notes app, show me the evidence, and build a similar feature for my project

A ideia é trocar o app (Notes) pelo seu alvo e a feature (search) pela que você quer entender

Uma decisão didática que deixa o processo mais controlável: quebrar esse pedido em duas etapas

Primeiro, só entender e mostrar evidências:

Entenda como a FEATURE funciona no APP_ALVO e me mostre as evidências. Não escreva código ainda

Depois, numa segunda mensagem, pedir a construção (isso fica pro passo 5)

Por que separar? Porque assim você lê o relatório com calma e decide o que entra na feature, em vez de receber evidência e código misturados de uma vez só

Isso é uma sugestão de organização, não um resultado medido

Erro comum deste passo: pedir pro agente "clonar" o app. O README é explícito: o REA não promete restaurar o código-fonte original nem clonar aplicações automaticamente

3. Leia o relatório pelas categorias certas:

Aqui mora o valor da engenharia reversa com o REA

Na hora de reportar, o REA separa cada conclusão nestas categorias:

• Observado: o que apareceu de fato na inspeção
• Derivado: o que sai diretamente das observações
• Inferido: a hipótese do agente a partir do que viu
• Desconhecido: o que a análise não conseguiu responder

E a proveniência das evidências é preservada, ou seja, dá pra saber de onde veio cada conclusão

Segundo o projeto, a análise roda localmente e cada conclusão vem acompanhada das evidências e das limitações que a sustentam

No caso de apps Electron, o exemplo de resultado documentado no README cita módulos, imports, fronteiras do Electron e as respectivas evidências

Erro comum deste passo: tratar inferência como fato. Inferência é palpite bem fundamentado, não comportamento comprovado… Tome cuidado!

4. Transforme o relatório numa especificação sua:

Esse é o passo que quase todo mundo pula, e é o mais importante

Pega o relatório e monta uma lista de requisitos seguindo esta regra:

• Comportamento observado vira requisito da sua feature
• Inferências e incógnitas viram escolhas de design suas, anotadas como tal ("decidi fazer assim porque…")
• Limitações reduzem o que dá pra reproduzir com fidelidade: onde a evidência é fraca, você não está reproduzindo, está projetando

Se você conhece a diferença entre ler a documentação de uma API e adivinhar como ela funciona por dentro, é bem semelhante: uma coisa é contrato, a outra é hipótese

Erro comum deste passo: tentar reproduzir detalhes que só aparecem como incógnita. Se nem a análise sabe como aquilo funciona, copiar o "jeito" é inventar e chamar de engenharia reversa

5. Peça a implementação a partir da especificação:

Agora sim, código

Você entrega ao agente a sua especificação (não o relatório cru) e pede a implementação no seu projeto, deixando claro que nada de código, marca ou conteúdo do app alvo deve ser copiado

Esse é o uso pretendido pelo projeto: entender a feature e construir uma versão original sua

Depois que o código existir, vale também conferir se ele respeita as convenções do seu projeto, e não só se roda

Checagem final: cada parte da feature precisa apontar pra uma evidência observada no relatório OU pra uma decisão sua declarada na especificação

Se tem um pedaço que não aponta pra nenhum dos dois, ele veio do nada, e vale revisar antes de seguir

Quando faz sentido usar o REA para criar uma feature?

Os casos que encaixam são os mesmos usos que o projeto declara como permitidos:

• App que você possui: entender como ele implementa algo pra construir a sua versão
• Interoperabilidade: fazer o seu projeto conversar com uma ferramenta que você usa
• Estudo: aprender como uma feature funciona por dentro, com fins educacionais
• Preservação de software: documentar o comportamento de algo que pode deixar de existir

E o limite é claro: sem autorização, ou com a intenção de copiar o produto de outra pessoa, não é o uso pretendido pelo REA

Não é questão de "jeitinho" no prompt, é a regra do projeto

Vídeo complementar do canal:

O Grok Build está na lista de agentes suportados pelo setup, e se o ecossistema do Grok te interessa, no canal tem um vídeo testando o modelo Grok 4.7 criando projetos reais

Próximo passo:

Escolhe UMA feature pequena de um app que você pode examinar (uma busca, um filtro, um atalho), roda a investigação só com o pedido de entender e mostrar evidências

Antes de pedir qualquer linha de código, monta a lista de requisitos marcando cada item como "observado" ou "decisão minha"

Se a lista ficar mais cheia de decisões suas do que de observações, ótimo: você descobriu o tamanho real do que dá pra reproduzir

E um detalhe que evita dor de cabeça: a fonte é o repositório oficial morluto/rea. Repositórios com outros nomes, como NabilRFG12/Reverse-Engineer-anything e DhruvKikan/morluto-rea, são cópias e não o oficial

Até o próximo post! 😀

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.