Como auditar a análise do REA: a evidência e as limitações por trás de cada conclusão antes de escrever código

Fala aí, beleza? Análise de engenharia reversa feita por agente só vale alguma coisa se você consegue conferir de onde saiu cada afirmação 🙂

O REA (Reverse Engineer Anything) é um MCP server e CLI open source que deixa um agente de código (Claude Code, Codex ou Cursor) analisar software sem ter o código-fonte

E aí vem a parte que mais importa: cada conclusão volta junto com a evidência e as limitações por trás dela

Neste post a ideia é aprender a LER isso de forma crítica, antes de transformar a análise em código, beleza?

REA em vídeo

Também gravei um vídeo sobre o REA no canal Hora de Codar. Dê o play abaixo ou assista no YouTube.

Por que o formato de evidência importa quando o próximo passo é escrever código

O princípio central do REA é simples: a análise roda localmente e cada resultado traz a evidência e as limitações que sustentam a conclusão

Parece detalhe, mas não é

Pensa comigo: depois da análise, o normal é pedir pro agente implementar algo em cima dela (um cliente, uma integração, um port e por aí vai)

Se um palpite entra nesse fluxo como se fosse fato, ele vira bug lá na frente, e bug chato de rastrear, porque a origem nem está no seu código haha

Análise estática tem limite, e o REA assume isso

Um executável pode ter símbolos removidos, instruções otimizadas, dependências faltando ou comportamento que a análise estática sozinha não recupera

O REA ajuda a investigar, mas não garante que todo detalhe interno será reconstruído

Por isso a evidência do REA não é enfeite: é ela que te diz até onde dá pra confiar em cada afirmação

A v6.3.0 deixou isso ainda mais explícito

Na v6.3.0, lançada em 9/10/2026, veio uma mudança incompatível: os providers passaram a ser obrigados a fornecer explicitamente metadados que antes eram preenchidos com valores padrão

E facetas não suportadas devem vir como null

Na prática: menos valor bonitinho preenchido por padrão e MUITO mais transparência sobre o que o provider realmente sabe 😀

O que você precisa antes de auditar uma análise

• Node.js e npm instalados
• Um agente compatível: Claude Code, Codex ou Cursor
• O REA configurado nesse agente

A configuração sai com um comando só:

npx rea-agents setup

Tu escolhe os agentes e revisa as mudanças propostas

O comando adiciona o MCP server do REA e as instruções de workflow correspondentes, fazendo backup da configuração existente (então nada de medo de perder o setup atual)

Cuidado com cópias do repositório

Segundo o próprio repositório do projeto, o repositório oficial é o github.com/morluto/rea, mantido por morluto

E o mesmo repositório aponta que repos como shijianzhong/rea, rea-tools/rea, danm-gh/morluto-rea e DhruvKikan/morluto-rea são cópias ou forks de terceiros, não a fonte oficial

Tome cuidado! Ferramenta que mexe com binário é exatamente o tipo de coisa que tu quer pegar da fonte certa

Versão e segurança

Na data desta publicação, a versão mais recente é a rea-agents v6.4.0, lançada em 11/10/2026

Só que o projeto lança versões quase todo dia, então confira o repositório antes de seguir qualquer tutorial (inclusive este xD)

E agora um aviso sério: o REA não é sandbox

Ele não protege contra processos maliciosos que já rodam com o mesmo usuário do sistema

E abrir um binário não confiável repassa o parsing e a análise ao provider local com as permissões desse usuário

Ou seja: binário suspeito pede um ambiente isolado montado por você, não confie que a ferramenta faz isso sozinha

Passo a passo para auditar cada conclusão do REA

Bora ver na prática?

A ideia aqui é um checklist pra rodar em cima de cada conclusão, antes de pedir qualquer linha de código pro agente

1. Identifique o provider e o nível de confiança

Cada resultado bem-sucedido é guardado como um registro estruturado Evidence v2, com o provider, a confiança e as limitações conhecidas

Comece por aí: quem gerou essa conclusão e com qual confiança ela veio

Erro comum: tratar confiança como certeza. Confiança é o quanto o provider aposta naquilo, não uma prova

2. Rastreie a procedência

A procedência inclui digests de arquivo, faixas de bytes e JSON pointers dentro da captura

Que JSON pointer? É um jeito de apontar um caminho exato dentro de um documento JSON, tipo um endereço pro dado que sustenta a conclusão

Com isso tu consegue voltar no arquivo e no trecho de onde a afirmação saiu

Erro comum: aceitar a conclusão sem localizar a origem. Se tu não acha de onde ela veio, ela ainda não serve de base pra código

3. Separe inferência estática de observação em runtime

O REA marca separadamente o que foi inferência estática e o que foi observação em runtime

São coisas diferentes: uma é dedução lendo o software parado, a outra é algo que de fato aconteceu com ele rodando

Erro comum: misturar as duas ao escrever a lógica, como se uma inferência estática tivesse o mesmo peso de um comportamento observado

4. Leia o que a análise NÃO conseguiu estabelecer

O registro traz uma lista explícita do que a análise não conseguiu estabelecer

E, desde a v6.3.0, facetas não suportadas pelo provider vêm como null

Dados que ficaram incompletos são informados como incompletos, o REA não apresenta palpite como fato

Erro comum: interpretar null ou ausência como não existe. Null quer dizer que aquela faceta não é suportada, não que a coisa está ausente no app

5. Trate a visão de API como inventário inferido

A visão de API não afirma conhecer o schema nem os handlers do servidor

É um inventário inferido, não uma spec

Erro comum: gerar um cliente como se aquilo fosse a especificação oficial. Já vi muito código zoado nascer exatamente desse atalho 😛

6. Em JavaScript, confira se houve corte por recurso

A análise de JavaScript roda em processo isolado, com limites configuráveis de heap e timeout

Se os recursos acabam, ela mantém os fatos já concluídos e deixa os unknowns explícitos

Erro comum: achar que o resultado está completo. Unknown explícito é lacuna real e precisa entrar na sua lista do que validar

Com esses seis passos tu sai da análise com duas listas: o que tem evidência e pode virar código, e o que é hipótese e precisa de validação

Como a auditoria muda conforme o tipo de software analisado

O REA inspeciona binários nativos, apps JavaScript e Electron, assemblies .NET e sites

O checklist é o mesmo, mas o ponto de atenção muda bastante de um alvo pro outro

Binários nativos

Aqui o REA devolve pseudocódigo, assembly, strings, símbolos, chamadas e referências

Pseudocódigo ajuda muiiito na leitura, mas lembra: se o binário teve símbolos removidos ou foi otimizado, parte do que tu está lendo é reconstrução, não o código original

Apps JavaScript e Electron

O ponto crítico são os limites de heap e timeout

Se a análise bateu no teto, o resultado tem fatos concluídos e unknowns explícitos, e tu precisa tratar os dois de forma diferente

Assemblies .NET e sites

São dois alvos diferentes, cada um com a sua análise, mas a regra do passo 5 vale pros dois: quando a análise gera visão de API, é inventário inferido

Nada de assumir schema ou handlers do servidor só porque o endpoint apareceu ali

De onde vem o provider?

O REA conecta o agente a ferramentas de engenharia reversa como Ghidra, IDA Pro e Hopper

Por isso olhar o provider no passo 1 importa tanto: ele te diz qual motor gerou aquela conclusão

Conclusão: trate a análise como hipótese documentada

O valor do REA está em mostrar o que sabe e o que não sabe, lado a lado

Código deve ser escrito só sobre o que tem evidência, e as lacunas (null, unknowns, inferências sem observação em runtime) viram pontos a validar, não suposições escondidas no meio da implementação

E lembra: a licença MIT cobre o REA, não o software que você analisa com ele

Próximo passo? Instala pelo repositório oficial, roda uma análise num app próprio e aplica esse checklist antes de pedir ao agente qualquer implementação

É o tipo de hábito que separa vibe coding de código que tu consegue defender depois =)

Até o próximo post!