Claude Opus ayudó a un analista de negocios a lanzar dos apps en dos semanas sin equipo

Un experimento con desarrollo de IA demostró que una persona sin experiencia en programación ya puede llevar un producto móvil al mercado. En dos semanas, un analista de negocios construyó dos aplicaciones Flutter para RuStore y gastó aproximadamente 80 horas en ello.

Cómo fue el experimento

El autor abordó la tarea como una prueba de hipótesis: si un analista de negocios sabe cómo descomponer requisitos, escribir historias de usuario y criterios de aceptación, esto puede ser suficiente para trabajar con un asistente de IA en lugar de un equipo común. Para la prueba, eligió dos productos diferentes — un rastreador de tiempo "168 Horas" y F1 Tycoon, un juego sobre dirigir un equipo de Fórmula-1. También seleccionó el stack a través del modelo: Flutter y Dart para desarrollo multiplataforma, Supabase como backend gratuito para el MVP.

El cronograma resultó casi como un sprint completo. Los primeros dos días se dedicaron a configurar Flutter y Android Studio, luego comenzó un montaje en cadena de pantallas para "168 Horas". Después llegó la primera etapa pesada — integración con Supabase, donde la autorización y las llamadas de red rápidamente se convirtieron en una serie de correcciones cíclicas.

Después de eso, el autor abordó F1 Tycoon, pero el proyecto de juego en sí reveló la principal limitación de los modelos actuales: cuantos más archivos y dependencias, peor mantienen la arquitectura general. En el día 14, ambas aplicaciones pasaron la moderación en RuStore, y los gastos directos se mantuvieron en cero.

Dónde la IA aceleró el trabajo

Según el autor, los mejores resultados vinieron no de herramientas gratuitas, sino de modelos comerciales más potentes. Las opciones gratuitas a menudo producían código que no compilaba e interfaces en el estilo de proyectos académicos antiguos. GPT-5.2 resultó ser notablemente más estable, pero fue Claude Opus el que entregó el código más limpio, interfaz moderna y mejor preservó el contexto del diálogo. Pero hay algo más importante: las habilidades del analista de negocios se alinearon inesperadamente con lo que requiere un buen prompting.

"La IA es como un desarrollador junior: cuanto más preciso el

requisito, más preciso el resultado."

En la práctica, esto no parecía magia, sino como un ciclo muy rápido de planteamiento de tareas y verificación de resultados. El autor describía una pantalla, recibía código, lo insertaba en el proyecto, lo ejecutaba en el teléfono y devolvía errores específicos al modelo. Este modo era como trabajar con un junior remoto muy rápido: la respuesta llega en minutos y las correcciones se pueden verificar inmediatamente en un dispositivo real. En este esquema, la IA resultó ser particularmente útil para varias tareas típicas:

• generar componentes UI y pantallas en minutos
• elegir un stack inicial para un principiante sin equipo
• explicar errores y terminología en lenguaje simple
• escribir código boilerplate y lógica de negocio básica
• prepararse para publicación: firma de compilación, claves, configuración build.gradle

Dónde comenzaron los problemas

El área más dolorosa fueron las integraciones. Conectar Supabase parecía simple en el papel, pero en la realidad, una corrección fácilmente generó el siguiente error. El autor describe un escenario típico: el modelo corrige un error de autorización por correo, después la pantalla de registro se rompe, luego el siguiente parche toca otro archivo.

En tareas cortas esto es tolerable, pero en un proyecto grande se convierte en un juego agotador donde corregir un problema local no garantiza que la aplicación siquiera se compile como un todo. El segundo problema era la memoria del modelo. Cuando F1 Tycoon creció a 50+ archivos, la IA dejó de recordar con confianza clases clave, estructura del proyecto y decisiones arquitectónicas anteriores.

Para reducir la pérdida de contexto, el autor creó un "archivo de memoria" separado que describía la estructura y se lo proporcionaba al modelo al inicio de cada sesión. Esto ayudó, pero no resolvió completamente el problema. Un riesgo adicional eran los límites de solicitudes: en un momento crítico, el acceso al mejor modelo podría cortarse durante varias horas, y todo el desarrollo simplemente se detenía.

Al final del experimento, ambos lanzamientos llegaron a la tienda, pero juntos recibieron solo 14 descargas.

Qué significa esto

La historia no prueba que la IA ya haya reemplazado a los desarrolladores, pero sí muestra bien otra cosa: el umbral para crear un MVP ha caído drásticamente. Si una persona sabe cómo formular requisitos, desglosar tareas y depurar pacientemente, ya puede llegar a un lanzamiento funcional. Pero las integraciones complejas, la arquitectura de proyectos grandes y el control de calidad siguen siendo áreas donde sin un ingeniero experimentado, la velocidad rápidamente alcanza un techo incluso en experimentos en solitario.