Inside REA: from binary to an operable product

REA makes visible a stage that was long restricted to specialists: observing a software artifact, organizing technical evidence, and using agents to support a new implementation. This matters. It is also very different from receiving the original Uber, Airbnb, Booking, or iFood code and installing a ready-made copy.

Estado: artigo especial aprovado para publicação. Série editorial: REA and the new boundaries of software creation. 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.

What REA does — and what it does not promise

The official repository describes REA as an AI-assisted reverse-engineering orchestrator. It can analyze native binaries, .NET, JavaScript or Electron applications, and web pages; extract structure, pseudocode, assembly, modules, and relationships; and pass that evidence to an agent that writes and tests a new implementation.

The important verb is infer. Compiling a system removes names, comments, decision history, tests, production data, operational secrets, and part of the authors’ intent. A public interface also reveals only the behavior exposed in that journey. REA expands the observable field, but it does not go back in time to recover the original repository.

A prudent sequence separates six things:

1. observe behavior and artifacts;
2. infer an implementation hypothesis;
3. reimplement a bounded capability;
4. integrate that capability into a product;
5. operate the product with security, data, support, and sound economics;
6. build the business, network, and trust that make the product relevant.

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

“Can I copy the Uber app now?”

Not as an automatic consequence of REA. An app seen by a user is one surface of a larger system. Uber Engineering itself describes routing engines, a payments platform operating across many markets, and risk and fraud mechanisms. Maps, drivers, riders, liquidity, support, contracts, historical data, local rules, and real-time operations are not embedded in a screen that can be taken apart.

REA can help an authorized team understand a legacy client, document a protocol, or reimplement a bounded function. Building “another Uber” still requires product, infrastructure, operations, and a market network. The interface is a fraction of the problem.

“Is REA already the Booking or Airbnb code? Can I just install it?”

No. REA is the analysis and orchestration tool. It does not distribute those companies’ repositories. Airbnb publishes examples of what remains invisible in an interface copy: local payments and an identity graph used to connect entities and reduce risk. Booking, Airbnb, and other products at scale combine internal systems, data, contracts, observability, and teams that change continuously.

Even when a new implementation reproduces observed behavior, it starts without the history, data, integrations, controls, and rights required to operate the original product.

“Can I copy iFood by myself without being a developer?”

Someone without software-development training can now produce far more ambitious prototypes. They can build a catalog, cart, order flow, and tracking screens. This is a real change in how the ability to create is distributed.

iFood, however, reports an operation involving hundreds of thousands of establishments and millions of consumers. Its logistics engineering describes forecasting, dispatch, and optimization under dynamic conditions. When money, food, location, availability, and people enter the flow, the question shifts from “does the screen work?” to “who is accountable when an exception occurs?”

Alone, someone can validate a niche hypothesis. Turning it into an operable product requires domain knowledge, engineering, security, data, support, legal, and operations proportional to the risk. AI reduces work in some stages; it does not concentrate all those responsibilities in one person.

The productivity gain exists, but depends on scope

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.

METR also tracks the growth of the task horizon agents can complete under defined conditions. A longer horizon is not business autonomy: a task with clear tests and success criteria differs from finding the right product, negotiating rights, serving customers, and sustaining years of change.

The cost moves elsewhere

Tokens have a price, but they are not the total cost. Context must be collected and reviewed; agents need environments, tools, and permissions; runs fail; models and dependencies change; tests and observability must cover consequences. The 2025 DORA report describes AI as an amplifier of organizational strengths and weaknesses.

An organization with clear contracts, reliable tests, and ownership is more likely to convert the new speed into value. An organization that does not know who accepts the result merely generates more changes to review. There is also a confidence risk: in a study of security tasks, participants using an AI assistant produced less secure code and were more confident in the result.

A minimum technical contract for responsible REA use

1. Authorization: record ownership or permission to analyze the artifact and the legitimate purpose.
2. Scope: define the capability to be understood or reimplemented, without promising to “copy the company.”
3. Provenance: preserve hashes, version, tools, prompts, outputs, and human decisions.
4. Isolated environment: limit network access, credentials, data, and agent side effects.
5. Clean implementation: separate observed evidence from new code and document dependencies.
6. Evals: test behavior, security, performance, regression, and known limits.
7. Ownership: name who accepts, operates, fixes, funds, and can stop the system.

Isolation, least privilege, and software-supply-chain provenance are complementary controls; none replaces the others in an agentic system. [R2-C3]

In Brazil, the Software Law protects computer programs and treats similarities arising from functional characteristics, standards, or technical limitations differently from unauthorized reproduction. That distinction is not a general license to copy: purpose, contracts, secrets, trademarks, data, competition, and other rights remain case-specific. REA itself frames its use around authorized research, education, interoperability, and preservation. Specific legal review remains necessary.

What this new capability actually changes

REA is most relevant when it lowers the cost of understanding and modernizing systems an organization has the right to analyze: undocumented dependencies, legacy applications, interoperability, preservation, and migration. It can also accelerate competitive research based on public behavior, provided learning is not confused with appropriation.

For FORGE, the rule is simple: reverse engineering can produce evidence for a decision; it does not automatically produce rights, a ready product, or a business outcome. Value emerges when evidence enters an engineering process with boundaries, tests, authorship, and operational accountability.

Direct sources

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 and fraud challenges. Componentes operacionais além da interface.
8. Airbnb Tech — payments and identity graph. Infraestrutura interna e risco.
9. iFood — números da operação and engenharia de logística. Escala e complexidade operacional declaradas.
10. Lei nº 9.609/1998 and INPI — programas de computador. Marco brasileiro e orientação pública.

Editorial and responsibility note

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.

Research cutoff: October 14, 2026. Editorial status: special article authorized for October 14, 2026 at 9:00 AM BRT.