Contexto Técnico
Revisé la discusión sobre Rork y la tesis de que "Manus crea una app Expo desde un solo prompt, la despliega y entrega un código QR". Como arquitecto, no verifico impresiones, sino la reproducibilidad: documentos públicos, repositorios de ejemplo, limitaciones documentadas, contratos de API e integraciones con EAS/Expo.
Para Manus, el panorama actual se centra en la web: una plataforma de agentes con planificación/ejecución/verificación en la nube, y acceso a herramientas del proyecto. Las descripciones mencionan previsualizaciones y despliegues web (incluso en Netlify), además de APIs para tareas/archivos/webhooks. Sin embargo, no encuentro casos confirmados específicamente para React Native/Expo, y mucho menos "un código QR como resultado del despliegue".
Esto no significa que sea "imposible", significa que hoy no veo una base técnica pública para incluir esta funcionalidad en la ruta crítica de un proyecto. La cadena móvil requiere pasos concretos: generar un proyecto RN/Expo, compilar (local o por CI), publicar a través de EAS (u otro pipeline), lanzar una compilación de vista previa y generar un código QR. Si la herramienta no lo demuestra en su documentación, considero la afirmación puro marketing hasta que se verifique.
En cuanto a Rork, hay una promoción inicial (99% de descuento en el plan de $50, código REVENUECAT2026), pero faltan detalles técnicos: qué SDKs/frameworks se usan, cómo funciona la compilación, si hay integración con Expo CLI/EAS, o cómo se manejan firmas, secretos y requisitos de Apple/Google. En su estado actual, es "interesante para probar", pero no "para planificar un proceso de arquitectura".
Evalúo a Claude como generador de código para Expo de forma pragmática: un LLM puede generar la estructura del proyecto, componentes, navegación, estado, e incluso sugerir configuraciones de EAS. Sin embargo, "saber hacer apps en Expo" no equivale a "hacer un despliegue en producción". Sin el entorno, claves, perfiles de firma y CI, sigue siendo un asistente poderoso, no una fábrica de lanzamientos.
Impacto en Negocios y Automatización
En los negocios, la diferencia entre "generar código" y "cubrir el ciclo completo" se mide en semanas y presupuesto. Si prometo a un cliente un despliegue zero-shot y luego resulta que el flujo móvil no es compatible, el proyecto pasa a DevOps manual, incrementando tiempos y costos.
Veo dos tipos de ganadores. Primero, los equipos que usan LLMs como aceleradores de ingeniería: bosquejan UI/lógica rápidamente, pero mantienen la compilación/firma/lanzamientos en un flujo controlado. Segundo, productos realmente integrados con EAS/CI, gestión de secretos y observabilidad; allí, la "automatización con IA" se convierte en una operación repetible, no solo en una demo.
Los perdedores son quienes compran herramientas por su apariencia sin realizar una validación técnica en los primeros 1 o 2 días. En nuestros proyectos en Nahornyi AI Lab, siempre inicio la implementación de IA con una prueba de capacidad breve: una pantalla, una solicitud de API, una compilación de vista previa, un despliegue. Si esto no funciona en la práctica, las herramientas aún no cumplen lo prometido.
Si necesita un efecto "2 a 3 veces más rápido", suelo elegir un híbrido: Cursor/Copilot/Claude para generación y refactorización + una arquitectura de IA estrictamente definida para el pipeline (repositorio, pruebas/lint, EAS, entornos, métricas). Esta es la verdadera integración de IA en el desarrollo sin perder el control.
Visión Estratégica y Análisis Profundo
Mi pronóstico para 2026 es simple: el mercado se dividirá en "chat de código" y "agente responsable del artefacto". El segundo tipo solo ganará donde haya un contrato de resultado verificable: enlace de compilación, ID de lanzamiento, registros de compilación reproducibles, política de secretos y capacidad de reversión.
También veo un patrón recurrente en la automatización con IA: cuanto más cerca se esté de producción (firmas, tiendas, cumplimiento, analíticas, informes de fallos), menos espacio hay para la magia y mayor es el valor de la disciplina arquitectónica. Una herramienta puede escribir el 80% del código, pero el 20% de las integraciones consumen el 80% del tiempo si no se gestionan adecuadamente.
Por lo tanto, evaluaría Rork y cualquier promesa "prompt→QR" con una lista de verificación: (1) ¿crea un proyecto de Expo válido?, (2) ¿compila una vista previa de EAS?, (3) ¿cómo almacena los tokens?, (4) ¿dónde están los registros y artefactos?, (5) ¿quién es el dueño del repositorio?, (6) ¿se puede repetir la compilación fuera del servicio? Esto convierte el entusiasmo en una decisión de ingeniería y protege su ROI.
Este análisis fue preparado por Vadym Nahornyi, Experto Principal en Nahornyi AI Lab sobre arquitectura de IA y automatización de IA en el sector real. Lo invito a discutir su caso: verificaré las afirmaciones de las herramientas sobre su reproducibilidad, diseñaré la integración de IA en su SDLC y ayudaré a crear soluciones de IA para negocios de manera que los lanzamientos sean predecibles, no basados en la "inspiración de una demo".