Uma nova forma de criar software começa com outra pergunta. Em vez de pedir à IA que crie tudo do zero, podemos pedir que ela veja como um recurso já funciona. O REA, sigla de Reverse Engineer Anything, foi feito para esse tipo de tarefa. Ele ajuda agentes de programação a investigar apps, sites e outros programas.
O REA não é um botão que gera um app pronto. É uma ponte entre um agente de programação e ferramentas que leem um programa. O agente usa as pistas que encontra para explicar um recurso. Depois, se a equipe pedir, pode ajudar a criar uma versão nova, com outro código e regras claras.
O que é REA e como funciona?
REA é um projeto aberto que conecta agentes a ferramentas de engenharia reversa por meio de MCP. Em termos simples, engenharia reversa é estudar um software existente para entender seu comportamento. De acordo com o repositório oficial do REA, o agente inspeciona o alvo, recebe achados com evidências e limitações e usa essas informações para explicar o comportamento, responder a perguntas ou implementar e testar uma funcionalidade semelhante.
- Inspecionar: o agente aciona as ferramentas do REA para analisar um alvo autorizado.
- Reunir evidências: o REA devolve achados, evidências e limitações da análise.
- Aplicar: o agente usa os resultados para explicar o comportamento e apoiar a implementação e os testes de uma funcionalidade.
O tipo de leitura depende do app. Em apps JavaScript e Electron, o REA pode mapear arquivos, rotas e ligações entre partes do programa. Em apps nativos, pode usar ferramentas de análise como Hopper ou Ghidra. A análise roda no computador, mas o modelo de IA pode ter regras próprias sobre os dados que recebe.
Como o REA muda a criação de apps?
Sem esse tipo de leitura, a IA parte do que a pessoa escreveu no prompt. Se faltam detalhes, ela pode supor uma regra e criar algo que parece certo, mas age de outro modo. Com o REA, o agente pode olhar um caso que já existe, mostrar as pistas e então ajudar a fazer uma nova versão.
Isso pode ser útil em mais de um tipo de trabalho:
- Modernizar: mapear um app antigo antes de trocar uma parte dele.
- Integrar: entender como um dado entra e sai de um sistema que tem pouca documentação.
- Aprender: estudar uma função real e ver quais regras o código aplica.
- Prototipar: criar uma versão própria de uma ideia e testar se ela serve ao produto.
Exemplo prático hipotético: uma equipe quer pôr um cálculo de porcentagem em seu próprio app. Ela pede ao agente para estudar uma calculadora que tem direito de analisar. Na demonstração do REA, o agente investiga por que 200 mais 10% resulta em 220. A regra depende da operação; não basta copiar o símbolo de porcentagem da tela. O código aberto da Calculadora da Microsoft permite conferir parte dessa lógica.
O ganho não é copiar uma tela. É usar pistas do programa para fazer perguntas melhores, criar testes e construir uma função nova para outro contexto. A equipe ainda decide o que deve ser feito e confirma que o resultado atende às suas regras.
REA não é um clone automático
A documentação do projeto faz uma distinção clara:
Os resultados incluem evidências e limitações da análise.
Resumo do repositório oficial do REA.
Essa distinção importa. Inspecionar o comportamento de um app sem seu código-fonte não significa recuperar o projeto original. A análise pode deixar lacunas ou apresentar pistas incompletas; por isso, qualquer implementação derivada precisa ser revisada e testada pela equipe.
Limites e uso responsável
Antes de analisar um app, a empresa deve confirmar que tem direito para isso. Licenças e contratos podem limitar o que pode ser lido ou refeito. A análise não deve expor dados de clientes, quebrar controles de acesso ou copiar código protegido.
REA diz que a análise ocorre no próprio computador, sem enviar o app para um serviço de análise hospedado. Mas isso não define como cada agente ou modelo lida com o contexto que recebe. A empresa deve checar a regra de dados do provedor de IA e evitar incluir segredos ou dados pessoais sem aprovação.
Também há limites por sistema e ferramenta. A página oficial do REA lista o que é aceito e aponta que a análise nativa pode exigir ferramentas à parte. O suporte a Ghidra no Windows tem limites descritos pelo projeto. Logo, é preciso checar a plataforma antes de montar um fluxo de trabalho.
Para uma empresa, o melhor uso inicial é pequeno e controlado: estudar um app autorizado, escolher uma função, pedir ao agente que mostre as pistas e testar a nova versão. A IA ajuda a ler e a criar; a equipe segue responsável pelo produto. Veja também as soluções de IA da CAV para outros usos da tecnologia nos negócios.
O REA cria apps sozinho?
Não. Ele dá ferramentas de leitura a um agente de programação. O agente pode ajudar a escrever código, mas a equipe ainda precisa definir o que quer, rever o resultado e testar o app.
O REA recupera o código original?
Não há essa garantia. O REA pode mostrar código lido, código aproximado, chamadas e outros sinais. Isso ajuda a entender uma função, mas não recompõe todo o projeto original.
Quando vale usar o REA?
Ele pode ajudar a estudar um app autorizado, planejar uma troca de sistema, entender uma função ou criar uma versão própria. Antes, confira os direitos de uso, a proteção dos dados e o suporte à sua plataforma.
