REA por dentro: do binário ao produto operável

O REA torna visível uma etapa que por muito tempo ficou restrita a especialistas: observar um artefato de software, organizar evidências técnicas e usar agentes para apoiar uma nova implementação. Isso é relevante. Também é muito diferente de receber o código original de Uber, Airbnb, Booking ou iFood e instalar uma cópia pronta.

Estado: artigo especial aprovado para publicação. Série editorial: REA e os novos limites da criação de software. A análise parte do repositório público do REA e de evidências sobre produtividade, segurança, operação e sistemas digitais em escala. Não afirma que a Trustyu reproduziu todos os fluxos do projeto, nem que engenharia reversa autoriza copiar software de terceiros.

O que o REA faz — e o que ele não promete

No repositório oficial, o REA é descrito como um orquestrador de engenharia reversa assistida por IA. Ele pode analisar binários nativos, aplicações .NET, JavaScript ou Electron e páginas web; extrair estrutura, pseudocódigo, assembly, módulos e relações; e entregar essas evidências a um agente que escreve e testa uma implementação nova.

O verbo importante é inferir. Compilar um sistema remove nomes, comentários, histórico de decisões, testes, dados de produção, segredos operacionais e parte da intenção dos autores. Uma interface pública também mostra apenas o comportamento que foi exposto naquela jornada. O REA amplia o campo observável, mas não volta no tempo para recuperar o repositório original.

Uma sequência prudente separa seis coisas:

1. observar comportamento e artefatos;
2. inferir uma hipótese de implementação;
3. reimplementar uma capacidade delimitada;
4. integrar essa capacidade a um produto;
5. operar o produto com segurança, dados, suporte e economia;
6. construir o negócio, a rede e a confiança que tornam o produto relevante.

Confundir a primeira ou a terceira etapa com a sexta é o atalho conceitual por trás das perguntas mais comuns sobre o REA.

“Agora posso copiar o aplicativo do Uber?”

Não como consequência automática do REA. Um aplicativo visto pelo usuário é uma superfície de um sistema maior. A própria engenharia da Uber descreve motores de roteamento, uma plataforma de pagamentos que opera em muitos mercados e mecanismos de risco e fraude. Mapas, motoristas, passageiros, liquidez, suporte, contratos, dados históricos, regras locais e operação em tempo real não estão embutidos em uma tela que possa ser desmontada.

O REA pode ajudar uma equipe autorizada a compreender um cliente legado, documentar um protocolo ou reimplementar uma função delimitada. Construir “outro Uber” continua exigindo produto, infraestrutura, operações e uma rede de mercado. A interface é uma fração do problema.

“Esse REA já é o código do Booking ou Airbnb? Posso só instalar?”

Não. O REA é a ferramenta de análise e orquestração. Ele não distribui os repositórios dessas empresas. O Airbnb publica exemplos do que permanece invisível numa cópia de interface: pagamentos locais e um grafo de identidade usado para ligar entidades e reduzir risco. Booking, Airbnb e outros produtos em escala combinam sistemas internos, dados, contratos, observabilidade e equipes que mudam continuamente.

Mesmo quando uma nova implementação reproduz um comportamento observado, ela começa sem o histórico, os dados, as integrações, os controles e os direitos necessários para operar o produto de origem.

“Consigo copiar o iFood sozinho sem ser desenvolvedor?”

Uma pessoa sem formação em desenvolvimento consegue hoje produzir protótipos muito mais ambiciosos. Pode montar catálogo, carrinho, fluxo de pedido e telas de acompanhamento. Isso é uma mudança real na distribuição da capacidade de criar.

O iFood, porém, informa uma operação com centenas de milhares de estabelecimentos e milhões de consumidores. Sua engenharia de logística descreve previsão, despacho e otimização em condições dinâmicas. Quando dinheiro, comida, localização, disponibilidade e pessoas entram no fluxo, a questão deixa de ser “a tela funciona?” e passa a ser “quem responde quando uma exceção acontece?”.

Sozinho, alguém pode validar uma hipótese de nicho. Para transformar essa hipótese em produto operável, precisará reunir domínio, engenharia, segurança, dados, atendimento, jurídico e operação de acordo com o risco. A IA reduz trabalho em algumas etapas; ela não concentra todas essas responsabilidades numa única pessoa.

A produtividade existe, mas depende do recorte

Estudos públicos não sustentam nem a tese de que “nada mudou” nem a de que “software inteiro agora é instantâneo”. Em um experimento controlado com 96 engenheiros, um assistente generativo reduziu em cerca de 21% o tempo de uma tarefa empresarial específica, com grande incerteza entre grupos. Em outro estudo, 16 desenvolvedores experientes trabalhando em 246 tarefas de repositórios maduros ficaram 19% mais lentos com ferramentas do início de 2025; os próprios autores alertam que esse retrato envelhece à medida que ferramentas e hábitos mudam.

O METR também acompanha o crescimento do horizonte de tarefas que agentes conseguem completar sob condições definidas. Horizonte maior não equivale a autonomia empresarial: uma tarefa com teste e critério de sucesso claros é diferente de descobrir o produto certo, negociar direitos, atender clientes e sustentar anos de mudança.

O custo muda de lugar

Tokens têm preço, mas não são o custo total. Contexto precisa ser coletado e revisado; agentes precisam de ambientes, ferramentas e permissões; execuções falham; modelos e dependências mudam; testes e observabilidade precisam cobrir consequências. O relatório DORA de 2025 descreve a IA como um amplificador das forças e fragilidades do sistema organizacional.

Uma organização com contratos claros, testes confiáveis e ownership tende a converter melhor a nova velocidade. Uma organização que não sabe quem decide o aceite apenas gera mais mudanças para revisar. Há ainda um risco de confiança: em estudo com tarefas de segurança, participantes com assistente de IA produziram código menos seguro e demonstraram maior confiança no resultado.

Contrato técnico mínimo para usar REA com responsabilidade

1. Autorização: registrar propriedade ou permissão para analisar o artefato e a finalidade legítima.
2. Escopo: definir a capacidade que será compreendida ou reimplementada, sem prometer “copiar a empresa”.
3. Proveniência: preservar hashes, versão, ferramentas, prompts, saídas e decisões humanas.
4. Ambiente isolado: limitar rede, credenciais, dados e efeitos colaterais do agente.
5. Implementação limpa: separar evidência observada de código novo e documentar dependências.
6. Evals: testar comportamento, segurança, desempenho, regressão e limites conhecidos.
7. Ownership: nomear quem aceita, opera, corrige, financia e pode interromper o sistema.

Isolamento, menor privilégio e proveniência da cadeia de software são controles complementares; nenhum deles substitui os demais num sistema agêntico. [R2-C3]

No Brasil, a Lei do Software protege o programa e trata a semelhança decorrente de características funcionais, normas ou limitações técnicas de forma diferente da reprodução não autorizada. Essa distinção não é licença geral para copiar: finalidade, contrato, segredos, marcas, dados, concorrência e outros direitos continuam dependentes do caso. O próprio REA enquadra seu uso em pesquisa autorizada, educação, interoperabilidade e preservação. Avaliação jurídica específica permanece necessária.

O que esta nova capacidade muda de verdade

O REA é mais relevante quando reduz o custo de compreender e modernizar sistemas que uma organização tem direito de analisar: dependências sem documentação, aplicações legadas, interoperabilidade, preservação e migração. Também pode acelerar pesquisa competitiva baseada em comportamentos públicos, desde que não confunda aprendizagem com apropriação.

Para o FORGE, a regra é simples: engenharia reversa pode produzir evidência para uma decisão; não produz automaticamente direitos, produto pronto ou resultado de negócio. O valor surge quando a evidência entra num processo de engenharia com limites, testes, autoria e responsabilidade operacional.

Fontes diretas

1. REA — repositório oficial. Escopo declarado, alvos suportados, fluxo e uso responsável.
2. METR — Time horizons. Metodologia e atualização do horizonte de tarefas de agentes.
3. METR — Early-2025 AI experienced open-source developer study. Experimento, amostra, resultado e ressalva temporal.
4. The Effects of Generative AI on High-Skilled Work. Experimento empresarial controlado com 96 engenheiros.
5. DORA — State of AI-assisted Software Development 2025. Leitura sistêmica da adoção de IA.
6. Do Users Write More Insecure Code with AI Assistants?. Estudo de segurança e confiança dos participantes.
7. Uber Engineering — routing engine, payments platform e fraud challenges. Componentes operacionais além da interface.
8. Airbnb Tech — payments e identity graph. Infraestrutura interna e risco.
9. iFood — números da operação e engenharia de logística. Escala e complexidade operacional declaradas.
10. Lei nº 9.609/1998 e INPI — programas de computador. Marco brasileiro e orientação pública.

Nota editorial e de responsabilidade

Este artigo combina fatos atribuídos às fontes com análise e proposta técnica do autor. Não constitui aconselhamento jurídico, de segurança, investimento ou autorização para analisar software de terceiros. Marcas pertencem aos respectivos titulares; não há patrocínio ou endosso. Pesquisa e redação tiveram assistência de IA; Fernando Parreiras aprovou a pauta e a publicação, sem revisão humana independente adicional.

Corte da pesquisa: 14/10/2026. Estado editorial: artigo especial autorizado para 14/10/2026 às 09h BRT.