REA por dentro: del binario al producto operable

REA hace visible una etapa durante mucho tiempo reservada a especialistas: observar un artefacto de software, organizar evidencia técnica y usar agentes para apoyar una implementación nueva. Esto es relevante. También es muy distinto de recibir el código original de Uber, Airbnb, Booking o iFood e instalar una copia lista.

Estado: artigo especial aprovado para publicação. Série editorial: REA y los nuevos límites de la creación 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.

Qué hace REA y qué no promete

El repositorio oficial describe REA como un orquestador de ingeniería inversa asistida por IA. Puede analizar binarios nativos, aplicaciones .NET, JavaScript o Electron y páginas web; extraer estructura, pseudocódigo, assembly, módulos y relaciones; y entregar esa evidencia a un agente que escribe y prueba una implementación nueva.

El verbo importante es inferir. Compilar un sistema elimina nombres, comentarios, historial de decisiones, pruebas, datos de producción, secretos operativos y parte de la intención de sus autores. Una interfaz pública muestra solo el comportamiento expuesto en ese recorrido. REA amplía el campo observable, pero no recupera el repositorio original.

Una secuencia prudente separa seis cosas:

1. observar comportamientos y artefactos;
2. inferir una hipótesis de implementación;
3. reimplementar una capacidad acotada;
4. integrar esa capacidad en un producto;
5. operar el producto con seguridad, datos, soporte y economía sostenible;
6. construir el negocio, la red y la confianza que hacen relevante el producto.

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

«¿Ahora puedo copiar la aplicación de Uber?»

No como consecuencia automática de REA. Una aplicación vista por el usuario es una superficie de un sistema mayor. Uber Engineering describe motores de rutas, una plataforma de pagos que opera en muchos mercados y mecanismos de riesgo y fraude. Mapas, conductores, pasajeros, liquidez, soporte, contratos, datos históricos, reglas locales y operación en tiempo real no están contenidos en una pantalla que pueda desmontarse.

REA puede ayudar a un equipo autorizado a comprender un cliente legado, documentar un protocolo o reimplementar una función acotada. Construir «otro Uber» sigue exigiendo producto, infraestructura, operaciones y una red de mercado. La interfaz es una fracción del problema.

«¿REA ya es el código de Booking o Airbnb? ¿Solo tengo que instalarlo?»

No. REA es la herramienta de análisis y orquestación. No distribuye los repositorios de esas empresas. Airbnb publica ejemplos de lo que permanece invisible en una copia de interfaz: pagos locales y un grafo de identidad usado para conectar entidades y reducir riesgo. Booking, Airbnb y otros productos a escala combinan sistemas internos, datos, contratos, observabilidad y equipos que cambian continuamente.

Incluso cuando una implementación nueva reproduce un comportamiento observado, comienza sin el historial, los datos, las integraciones, los controles y los derechos necesarios para operar el producto original.

«¿Puedo copiar iFood yo solo sin ser desarrollador?»

Una persona sin formación en desarrollo puede producir hoy prototipos mucho más ambiciosos. Puede crear catálogo, carrito, flujo de pedido y pantallas de seguimiento. Es un cambio real en la distribución de la capacidad de crear.

iFood, sin embargo, declara una operación con cientos de miles de establecimientos y millones de consumidores. Su ingeniería logística describe previsión, despacho y optimización en condiciones dinámicas. Cuando dinero, comida, ubicación, disponibilidad y personas entran en el flujo, la pregunta deja de ser «¿funciona la pantalla?» y pasa a ser «¿quién responde cuando ocurre una excepción?».

Una persona sola puede validar una hipótesis de nicho. Para convertirla en un producto operable tendrá que reunir dominio, ingeniería, seguridad, datos, atención, jurídico y operaciones de acuerdo con el riesgo. La IA reduce trabajo en algunas etapas; no concentra todas esas responsabilidades en una sola persona.

La productividad existe, pero depende del alcance

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 también sigue el crecimiento del horizonte de tareas que los agentes completan bajo condiciones definidas. Un horizonte mayor no equivale a autonomía empresarial: una tarea con pruebas y criterios de éxito claros difiere de descubrir el producto correcto, negociar derechos, atender clientes y sostener años de cambios.

El costo cambia de lugar

Los tokens tienen precio, pero no son el costo total. El contexto debe recopilarse y revisarse; los agentes necesitan entornos, herramientas y permisos; las ejecuciones fallan; los modelos y dependencias cambian; las pruebas y la observabilidad deben cubrir consecuencias. El informe DORA 2025 describe la IA como amplificador de fortalezas y debilidades organizativas.

Una organización con contratos claros, pruebas confiables y ownership tiende a convertir mejor la nueva velocidad. Una organización que no sabe quién acepta el resultado solo genera más cambios para revisar. Existe además un riesgo de confianza: en un estudio de tareas de seguridad, participantes con asistente de IA produjeron código menos seguro y mostraron mayor confianza en el resultado.

Contrato técnico mínimo para usar REA con responsabilidad

1. Autorización: registrar la propiedad o el permiso para analizar el artefacto y la finalidad legítima.
2. Alcance: definir la capacidad que será comprendida o reimplementada, sin prometer «copiar la empresa».
3. Provenance: preservar hashes, versión, herramientas, prompts, salidas y decisiones humanas.
4. Entorno aislado: limitar la red, las credenciales, los datos y los efectos secundarios del agente.
5. Implementación limpia: separar la evidencia observada del código nuevo y documentar dependencias.
6. Evals: probar comportamiento, seguridad, rendimiento, regresión y límites conocidos.
7. Ownership: nombrar quién acepta, opera, corrige, financia y puede detener el sistema.

El aislamiento, el menor privilegio y la provenance de la cadena de software son controles complementarios; ninguno sustituye a los demás en un sistema de agentes. [R2-C3]

En Brasil, la Ley de Software protege el programa y trata de manera distinta las similitudes derivadas de características funcionales, normas o limitaciones técnicas y la reproducción no autorizada. Esa distinción no es una licencia general para copiar: finalidad, contratos, secretos, marcas, datos, competencia y otros derechos dependen del caso. REA enmarca su uso en investigación autorizada, educación, interoperabilidad y preservación. Sigue siendo necesaria una evaluación jurídica específica.

Qué cambia realmente esta nueva capacidad

REA es más relevante cuando reduce el costo de comprender y modernizar sistemas que una organización tiene derecho a analizar: dependencias sin documentación, aplicaciones heredadas, interoperabilidad, preservación y migración. También puede acelerar investigación competitiva basada en comportamientos públicos, siempre que no confunda aprendizaje con apropiación.

Para FORGE, la regla es simple: la ingeniería inversa puede producir evidencia para una decisión; no produce automáticamente derechos, un producto listo ni un resultado de negocio. El valor surge cuando la evidencia entra en un proceso de ingeniería con límites, pruebas, autoría y responsabilidad operativa.

Fuentes directas

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

Nota editorial y de responsabilidad

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 de investigación: 14 de octubre de 2026. Estado editorial: artículo especial autorizado para el 14 de octubre de 2026 a las 09:00 BRT.