Vibe coding: qué es, cómo funciona — y el capítulo que las guías se saltan

Toda herramienta de vibe coding, diga lo que diga su marketing, ejecuta una versión del mismo ciclo: describir → generar → ejecutar → reaccionar. Escribes “una lista de tareas donde las tareas se ordenan por fecha límite”; el agente planifica el cambio, escribe el código en todos los archivos que hacen falta, compila el proyecto, ve los mismos errores que vería un programador, los corrige y te muestra un resultado que funciona. La siguiente frase — “las vencidas tienen que estar en rojo” — repite el ciclo sobre todo lo que ya está construido.

Tres cosas por dentro deciden si ese ciclo produce algo bueno, y conviene conocerlas porque explican cada diferencia de calidad entre herramientas:

Contexto. El agente solo puede respetar lo que ve — tus decisiones anteriores, el código existente, el sistema de diseño. Las herramientas difieren muchísimo en cuánto recuerdan y en cómo eligen qué mirar.

Estructura. Pide las funciones de una en una sin un plan y el agente improvisa una arquitectura en cada prompt — bien para una demo, mal de una forma que se acumula hasta la función veinte. Las herramientas que deciden la estructura antes (o te la hacen decidir) producen código que sigue siendo utilizable.

Verificación. Las mejores herramientas no te entregan código que debería funcionar: lo compilan, lo ejecutan, lo prueban y corrigen sus propios errores antes de que veas nada. La diferencia entre “genera código” y “entrega software” está casi toda aquí. Hasta Apple integró en Xcode agentes que iteran entre compilación y corrección.

Fíjate en lo que falta en esa lista: tu capacidad de programar. Lo que el ciclo consume de verdad es tu capacidad de describir con precisión y reaccionar con honestidad — y por eso la gente de producto le tomó la mano más rápido que nadie. Escribir qué tiene que existir, escenario por escenario, ya era el trabajo.

Bueno, hoy: pasar de la idea al software funcionando en una sesión; iterar barato (el “vuelve a intentarlo” que costaba la tarde de un desarrollador ahora cuesta una frase); las superficies estándar de producto — pantallas, formularios, listas, cuentas, pagos sobre backends gestionados; y dejar que la persona con criterio de producto construya directamente en vez de pasar el mensaje por capas.

Falla todavía, con honestidad: el trabajo sin una especificación describible (si no sabes decir cómo es “correcto”, el agente tampoco puede saberlo); los algoritmos realmente nuevos y la programación de sistemas poco común; rescatar una base de código grande y vieja que no construyó él; y compensar la falta de pensamiento de producto — un agente amplifica la calidad de las decisiones en las dos direcciones.

Y una forma de fallar es del usuario, no de las herramientas: confundir una demo con un producto. Cualquier herramienta de esta página te da una demo impresionante en una tarde. Un producto necesita, además, una estructura que sobreviva a la función veinte, cuentas que funcionan, datos que se quedan, actualizaciones que salen y código que es tuyo. Las herramientas difieren mucho más en esta segunda mitad que en la velocidad de la demo — y eso nos lleva al mapa.

La mayoría de las listas ordena por velocidad y acabado. Ordena en cambio por resultado — en qué se convierte de verdad lo que describes — y todo el mercado se divide en cinco grupos. (Sin precios aquí: cambian, y cada herramienta publica los suyos. La pregunta que hay que hacer es siempre la misma: ¿en qué plan puedo publicar y llevarme el código?)

Builders web — resultado: app web. Lovable es la referencia: apps en React, sincronización con GitHub, backend en Supabase; su propia documentación dice que “Lovable does not generate React Native projects”. v0 de Vercel y Bolt juegan el mismo partido. Para productos web son publicables de verdad; para prototipos de cualquier cosa son excelentes.

Herramientas de prototipado — resultado: demos interactivas desechables. Figma Make vive en el ecosistema de diseño y es honesta sobre lo que es: hecha para explorar, no para publicar.

Agentes de código, trae tu propia IA — resultado: lo que consigas dirigir. Claude Code, Cline, Aider: agentes que trabajan en una base de código real con tu suscripción o tu clave de API. Máxima libertad, ningún carril — excelentes para desarrolladores, y el camino en el que la gente de producto más necesita la estructura que incorpora el grupo siguiente.

Builders para teléfono — resultado: app para teléfono, con una bifurcación dentro del grupo que casi ninguna lista nombra. Vibecode, Newly y Bolt con Expo generan React Native/Expo — JavaScript multiplataforma que corre en el teléfono a través de un puente, con las mismas pantallas en los dos sistemas. FlutterFlow ensambla apps Flutter de forma visual. Rork cambió en 2026 a código nativo — Swift para iPhone, Kotlin para Android — como dos apps separadas dentro de un proyecto: según sus propios docs, “each app has its own code”. Y Modaal (la nuestra) genera código nativo de verdad de cada plataforma — Swift/SwiftUI para iPhone, Kotlin/Jetpack Compose para Android — desde un solo proyecto, con la lógica de cada función escrita una vez y una pantalla nativa por plataforma, con un plan que apruebas antes de cada función, el código en tu Mac y prompts ilimitados en el plan gratuito. Por qué importa esa bifurcación es el capítulo siguiente — porque es la parte del vibe coding que las guías siguen saltándose. (Los diez builders, ordenados por lo que producen, están en nuestra comparativa en inglés.)

Esta es la extraña laguna de todas las guías de vibe coding publicadas hasta ahora, en español igual que en inglés: explican el ciclo, enumeran las herramientas, enseñan una demo web — y se detienen en el teléfono. “Para teléfono” aparece, cuando aparece, como “tu app web también funciona en el navegador del teléfono”. Para quien tiene un producto que pertenece a la pantalla de inicio de un teléfono, esa frase esconde los tres hechos que más importan:

1. Un sitio web en el teléfono no es una app. Notificaciones push, uso sin conexión, cámara y sensores, widgets, reloj y los pagos dentro de las tiendas pertenecen a las apps de verdad. La prueba rápida: ¿tus usuarios llegan tocando un enlace o abriendo un icono? La comparación completa está en nuestra guía en inglés.

2. Empaquetar tu app web hecha con vibe coding no cruza la brecha. El atajo obvio — meter la app web en una cáscara con forma de app — choca con la revisión de Apple, que rechaza con regularidad las cáscaras delgadas alrededor de un sitio, y con todos los límites de arriba, porque la app sigue siendo un sitio disfrazado.

3. La brecha ahora se cruza con la misma habilidad. Esto es lo que cambió y lo que las guías todavía no recogen: el ciclo de describir e iterar ahora produce código nativo de verdad. En la versión de Modaal, el ciclo es a propósito más estructurado que el vibe coding web — un documento de producto cuando empieza el proyecto y, para cada función, el agente escribe primero un plan que puedes leer (escenarios, enfoque, riesgos, pruebas) y construye solo después de que lo apruebas; el resultado es Swift y Kotlin que un desarrollador de la plataforma reconoce, compilado y probado, en tu Mac. Vibe coding con la improvisación sustituida por especificaciones — exactamente la corrección que hace posible un resultado de producción.

La consecuencia práctica: el camino web y el camino del teléfono ahora empiezan igual — con una descripción — y ya no tienen que terminar con una reescritura. ¿Validaste algo en Lovable que resultó ser una app? El backend suele sobrevivir a la mudanza; la parte de delante se convierte en una app nativa de verdad, descrita en el mismo idioma que usaste para el prototipo. Y si el producto es para las dos tiendas, la lógica se escribe una vez y cada plataforma recibe su propia pantalla nativa — sin reconstruir nada para Android.

La rampa de entrada de una sesión, en el orden que evita los errores clásicos:

1. Elige algo real pero pequeño. No el producto estrella de tu empresa — una herramienta que quieras tú. El aprendizaje está en el ciclo, y las cosas pequeñas giran más rápido.

2. Escribe cinco frases antes de tocar ninguna herramienta. Qué hace; tres escenarios “el usuario hace X, ve Y”; qué deja fuera a propósito la primera versión. Es la diferencia entre dirigir e ir a la deriva — y es el hábito que después escala hasta producción.

3. Elige la herramienta por el resultado, no por la demo. Producto web → builder web. Producto para teléfono → herramienta con resultado móvil (y decide con conciencia entre nativo y multiplataforma). Solo estás explorando → cualquiera, sin remordimientos.

4. Reacciona con precisión. “Mal” no le enseña nada al agente; “el botón va abajo, donde llega el pulgar” lo arregla en un paso. Dale instrucciones al agente como se las darías a un desarrollador muy literal y muy rápido — una habilidad que la gente de producto ya tiene.

5. Itera pronto en un teléfono de verdad, si el producto es móvil — el simulador es educado, el pulgar es honesto.

Empezar no cuesta nada que importe: los builders web tienen planes gratuitos, y el plan gratuito de Modaal es un proyecto completo con prompts ilimitados; Pro cuesta 9 € al mes con pago anual — los detalles están en la página de precios. Cuánto cuesta de verdad crear una app por cada camino, con cada cifra verificable, está en cuánto cuesta crear una app. El recurso escaso es el de siempre — saber qué construir. Las herramientas solo dejaron de esconderlo.