REA (Reverse Engineer Anything) y ArtCraft: ingeniería inversa con IA y el futuro del SaaS
Los agentes de IA facilitan reconstruir software y ArtCraft apunta a las herramientas de Adobe. Qué cambia para los SaaS y cómo defender su valor con especialización, datos e innovación.
Los agentes de IA facilitan reconstruir software y ArtCraft apunta a las herramientas de Adobe. Qué cambia para los SaaS y cómo defender su valor con especialización, datos e innovación.
Si un cliente pudiera recrear con IA las tres funciones que más utiliza de tu producto, ¿seguiría pagando la suscripción?
REA, el proyecto de ingeniería inversa de Morluto, permite que un agente investigue software existente. ArtCraft está desarrollando alternativas a aplicaciones como Photoshop y Premiere. Son dos señales de un cambio que afecta al negocio del software: las funciones resultan más accesibles de reproducir y el valor debe sostenerse también en la especialización, los datos y la calidad del servicio.
Para entender la amenaza conviene ver cómo funciona esta reconstrucción y qué cambia cuando el producto es un SaaS.
Qué es REA y cómo funciona la ingeniería inversa con IA
REA, abreviatura de *Reverse Engineer Anything*, conecta agentes de programación con herramientas de ingeniería inversa. Lo hace mediante comandos y MCP, el protocolo que permite a un agente utilizar herramientas externas.
Imaginemos una función escrita por un desarrollador. Este es un ejemplo didáctico en C:
Al compilarla para ejecutarse directamente en un procesador, se transforma en instrucciones de máquina. Quien analiza el ejecutable no recibe ese código fuente legible: parte de bytes, representados por unos y ceros. Para el cuerpo de esta función, una posible secuencia en x86-64 con la convención de llamadas System V es:
Son dos representaciones de los mismos cuatro bytes. Un ejecutable completo contiene muchas más instrucciones, además de datos y otras estructuras. El resultado concreto depende de la arquitectura, el compilador y sus opciones.
Los ingenieros llevan décadas estudiando estos archivos. Un desensamblador traduce las instrucciones a una forma textual denominada ensamblador. Para esos bytes, la lectura sería:
Aquí se suma el argumento consigo mismo y se devuelve el resultado. Un descompilador puede reconstruir una representación parecida a C:
Hemos recuperado una lógica equivalente, aunque no los nombres originales ni la intención que escribió su autor. En aplicaciones grandes, las optimizaciones, los saltos entre funciones y las estructuras de datos complican enormemente esa interpretación.
Los binarios ya podían analizarse antes de la IA: herramientas como Ghidra incluyen desensamblado y descompilación. REA permite que el agente utilice esos instrumentos, siga referencias, formule hipótesis y programe una reconstrucción. La IA aporta valor al conectar las pistas y convertirlas en una implementación que después hay que comprobar.
Reconstruir una función de un programa compilado: el caso DX-Ball
DX-Ball es un juego de romper ladrillos: una pelota rebota en una paleta controlada por el jugador y destruye los bloques de la pantalla. Cuando golpea un ladrillo, se reproduce un sonido. El caso publicado por REA reconstruye cómo ese sonido se desplaza entre los altavoces izquierdo y derecho según la posición del ladrillo golpeado.
La primera descompilación omite parte del cálculo. El agente examina las instrucciones y las constantes del ejecutable. Entre las operaciones aparecen:
Esas direcciones contienen los valores 1.5625 y 500.0. Una versión simplificada del cálculo reconstruido, pasando la escala como argumento para facilitar la lectura, sería:
Aquí, x es la coordenada horizontal en píxeles. Con escala 1, x = 0 sitúa el sonido a la izquierda (-500), x = 320 en el centro (0) y x = 640 a la derecha (500).
El proyecto publica 3.205 comparaciones con la función original y coincidencia de sus 63 bytes compilados. Son resultados de esa función; la reconstrucción del juego seguía en desarrollo.
¿Puede REA ayudar a replicar un SaaS o una webapp?
Sí. REA también incorpora análisis de páginas y scripts en el navegador, así como análisis de capturas de tráfico de red. Sus aplicaciones van más allá de los ejecutables de escritorio, aunque cambia la información disponible.
En muchas webapps, el navegador recibe JavaScript que puede inspeccionarse, incluso cuando está empaquetado o minificado. También permite observar pantallas, interacciones y las peticiones que intercambia con el servidor. Esa información ayuda a entender cómo funciona la parte accesible del producto.
El backend permanece en otra máquina. Observar una petición y su respuesta no revela automáticamente el código que la procesa, la base de datos privada o todas las reglas de negocio. El desarrollador tiene que construir esa parte con una implementación propia y validar su comportamiento.
Pensemos en un gestor de tareas, como ejemplo hipotético. Es posible estudiar cómo se crean tarjetas, qué campos utilizan y cómo cambian de columna. Reconstruir ese flujo puede ser relativamente asequible. Reproducir además sus permisos de equipo, sincronización, historial e integraciones añade trabajo que la interfaz no explica por completo.
Por tanto, ser una webapp no impide utilizar REA; la barrera está en lo que ocurre fuera de la parte observable. Cuanto más valor dependa de datos privados, procesos internos e integraciones complejas, más queda por resolver.
Una alternativa tampoco necesita reproducir todo el servicio para competir. En su vídeo sobre REA, Nate Herk describe un prototipo inspirado en Loom que graba con cámara y guarda archivos localmente. Puede cubrir una necesidad concreta sin ofrecer toda la plataforma de colaboración y alojamiento.
Esa misma lógica permite entender la amenaza de ArtCraft para Adobe: reconstruir suficientes funciones de una herramienta conocida como para que ciertos usuarios puedan prescindir de su suscripción.
Qué es ArtCraft y por qué amenaza el modelo de Adobe
Las Crafting Apps se presentan como reimplementaciones independientes de aplicaciones conocidas, como explica el repositorio de PhotoCraft. Ese trabajo encaja en el objetivo de la ingeniería inversa: estudiar cómo funciona una solución y reconstruir capacidades equivalentes. No hay pruebas de que hayan utilizado REA ni de que hayan descompilado los programas de Adobe. La conexión está en el resultado que persiguen.
ArtCraft reúne dos propuestas. Su estudio de creación visual permite trabajar con imágenes y vídeo generados con IA. Las Crafting Apps son los editores que plantean esa competencia directa:
Aplicación | Ámbito | Referencia | Estado consultado |
|---|---|---|---|
PhotoCraft | Edición de imágenes | Photoshop | Alpha temprana |
FilmCraft | Edición de vídeo | Premiere Pro | En desarrollo |
VectorCraft | Ilustración vectorial | Illustrator | En desarrollo |
Su creador, Brandon Thomas, sitúa estas reimplementaciones en el contexto del desarrollo con agentes de IA.
PhotoCraft y FilmCraft publican su código con licencias MIT/Apache-2.0. El estudio de generación también ofrece planes con créditos: disponer del software no elimina necesariamente el coste de los modelos o el cómputo.
Hay otra característica relevante para los agentes. El MCP de PhotoCraft permite descubrir y ejecutar comandos e inspeccionar documentos. La propuesta incorpora automatización del trabajo creativo, además de nuevas herramientas para realizarlo manualmente.
La madurez sigue siendo una cuestión abierta. PhotoCraft documenta carencias en fidelidad PSD, rendimiento y plugins. En su prueba de FilmCraft, Fireship describe problemas de fluidez y considera que todavía no responde a sus necesidades profesionales.
Adobe combina aplicaciones de escritorio con servicios en la nube bajo un modelo de suscripción. La amenaza comercial para ese modelo puede llegar antes de la equivalencia completa. Una empresa que recorta clips o prepara imágenes sencillas puede necesitar menos funciones que un estudio profesional. Si una alternativa resuelve esas tareas con fiabilidad y menor coste total, la suscripción empieza a resultar más difícil de justificar para ese segmento.
Para cualquier SaaS, la pregunta es similar: ¿qué parte de nuestro producto necesita recrear un competidor para resolver el trabajo principal del cliente?
Tres palancas para construir un SaaS más defendible
1. Verticalización: resolver un trabajo con profundidad
Un SaaS especializado incorpora las decisiones, excepciones e integraciones de un sector. Eso amplía el trabajo que debe resolver quien intenta competir con él.
Pensemos en un producto de facturas para logística. Extraer campos es una función delimitada. Asociarlos a envíos, comprobar tarifas pactadas, detectar recargos y gestionar discrepancias exige entender la operación del cliente. La defensibilidad crece cuando ese conocimiento reduce incidencias y revisión manual de forma medible.
2. Datos: calidad, protección y contexto
Un agente con acceso autorizado a tarifas vigentes, acuerdos y resoluciones de incidencias puede tomar decisiones mejor fundamentadas que otro que solo ve una factura.
El valor está en obtener, relacionar y mantener información fiable, con trazabilidad y permisos adecuados. Las integraciones y los procesos de validación pueden ser difíciles de reproducir. La protección de esos datos y la confianza del cliente sostienen esa ventaja; retenerlos como barrera de salida la deteriora.
3. Innovación: mejorar el resultado con IA
La IA permite revisar cómo se completa un proceso. Un agente podría preparar una conciliación, explicar discrepancias y solicitar autorización para las excepciones, reduciendo el trabajo manual.
Esa evolución requiere decidir qué automatizar, cómo detectar errores y cuándo debe intervenir una persona. La innovación aporta defensibilidad cuando el cliente obtiene mejores resultados con una calidad comprobable. En agentes de IA en producción para SaaS desarrollamos las implicaciones de permisos, observabilidad y recuperación.
El valor de un SaaS también está en que siga funcionando
Construir una alternativa propia puede tener sentido. Quien la adopta asume también el mantenimiento: integraciones que cambian, formatos inesperados, actualizaciones, permisos, incidencias y recuperación de datos.
La IA ayuda a programar correcciones, pero alguien debe comprobar que funcionan y responder cuando el servicio falla. Ese trabajo continuado puede convertir un ahorro inicial en una carga de fragilidad y mantenimiento para el cliente.
Un SaaS que opera excelentemente evita que cada empresa tenga que organizar esa responsabilidad por su cuenta. Al comparar construir o contratar, el coste incluye implementación, infraestructura, revisión, soporte y fallos.
REA y ArtCraft hacen visible la presión sobre las funciones que pueden recrearse. Nuestra lectura es que los SaaS deben profundizar en su sector, trabajar con datos fiables y protegidos, e innovar sobre las necesidades del cliente. Las tres palancas ganan fuerza cuando se acompañan de una operación excelente, mantenida a lo largo del tiempo.
En Devic trabajamos en la incorporación de agentes de IA a productos SaaS: elegir qué automatizar y sostener su calidad en producción forman parte de la misma decisión de producto.
Fuentes y estados de desarrollo consultados el 14 de octubre de 2026. El primer ejemplo de compilación es didáctico; el código de DX-Ball se presenta adaptado y simplificado. Los resultados y pruebas publicados se atribuyen a sus autores.
Convierte tu SaaS en AI-Native
Obten una prueba gratis solo con registrarte
Últimos blogs
