Vibecoding para quienes no programan: crea una app (casi) sin código

Hace unos años, la idea de que una persona sin perfil técnico pudiera sentarse una tarde y construir una aplicación que funcione sonaba a promesa de marketing. Hoy es real, solo que no como sugieren los titulares. El vibecoding, es decir, construir software hablando con un modelo de IA en lugar de escribir el código a mano, permite de verdad que una persona sin experiencia llegue a algo que funciona. Este texto trata de dónde acaba el hype y empieza el trabajo real, y de cómo recorrer ese camino sin frustrarte.

Qué es realista y qué es hype

Empecemos por la honestidad, porque es lo que más disgustos te va a ahorrar. Es realista construir en una sola tarde un prototipo navegable, con aspecto de producto real, unas cuantas pantallas y una lógica básica. Es realista crear una herramienta interna que calcule algo para tu equipo, o una página sencilla con un formulario de registro. También es realista aprender muchísimo sobre cómo funciona el software, simplemente observando lo que genera la IA.

El hype empieza cuando alguien insinúa que “ya no necesitas desarrolladores”. No es verdad. El vibecoding resuelve de maravilla el primer 80% de una aplicación sencilla y fatal el último 20%, y es justo ese 20% (seguridad, pagos, datos de usuarios reales, escala) el que decide si tienes un producto o una demo. Cuanto antes lo aceptes, menos decepciones tendrás por el camino.

Qué es realmente el vibecoding

En la práctica, el vibecoding es un diálogo. Describes con palabras lo que quieres (“quiero una página donde la gente se registre en una lista de espera, con un campo de email y un botón”) y el modelo genera el código, el diseño y los estilos. Miras el resultado, dices qué cambiar e iteras. No necesitas saber sintaxis. Necesitas saber describir, pensar con claridad en lo que quieres y darte cuenta de cuándo algo no cuadra.

Se parece más a trabajar con un contratista rapidísimo pero muy literal que a la magia. Ese contratista hará exactamente lo que dijiste, incluidas las partes que no especificaste y que luego interpretó a su manera. Por eso todo el oficio está en cómo describes las cosas.

El panorama de herramientas para quienes no programan

Cada mes aparecen herramientas nuevas, pero vale la pena conocer unas cuantas por su nombre, porque salen en todas partes. Se diferencian en lo cerca que te llevan de una “aplicación terminada”.

• Lovable: pensada para personas no técnicas; describes la aplicación en lenguaje llano y construye un proyecto de varias pantallas con base de datos e inicio de sesión “incluidos”. Buena opción cuando quieres llegar a algo completo, no solo a una pantalla.
• Bolt: una filosofía similar; genera el proyecto completo con vista previa en vivo y te permite ejecutarlo y hacer el deploy en un mismo lugar. Práctica para pasar rápido “de la idea a un enlace que funciona”.
• v0: fuerte generando la interfaz y componentes atractivos. Genial cuando te importan el aspecto y las pantallas sueltas; menos cuando necesitas conectar toda una aplicación con datos.
• Replit: un entorno completo en el navegador con un asistente de IA. Es la que más control y alcance te da, pero también la que antes deja ver que debajo hay código real. Buena opción si quieres aprender y no te da miedo mirar más a fondo.

No hay una única “mejor”. Para un primer proyecto, elige la que más te lleve de la mano, normalmente Lovable o Bolt. Los precios cambian rápido; la mayoría tiene un nivel gratuito para probar y una suscripción de algunas decenas de dólares al mes si quieres construir algo más en serio. Toma estas cifras como orientativas y consulta las actuales en la web de cada herramienta.

Cómo describir lo que quieres

Esta es la habilidad que separa a la gente frustrada de la gente contenta. El modelo no te lee la mente: te da lo que describes. Algunas reglas que funcionan de verdad:

• Empieza con una frase sobre el objetivo. “Estoy creando una app que ayuda a pequeñas cafeterías a recoger opiniones de clientes mediante un código QR”. Eso fija el contexto para todo lo que viene después.
• Describe una pantalla cada vez. En lugar de “hazme la app entera”, pide la pantalla de inicio, luego el formulario y después la vista de resumen. Pasos pequeños = menos sitios donde algo puede fallar.
• Habla de comportamiento, no de tecnología. “Después del clic, muestra un agradecimiento y vacía el formulario” es mejor que intentar nombrar bibliotecas que, de todos modos, no conoces.
• Da ejemplos. “Debe verse limpia y moderna, como la web de Stripe” le da al modelo un punto de referencia concreto.
• Revisa el resultado después de cada cambio. No acumules diez peticiones a la vez. Un cambio, una comprobación: así detectas el momento en que algo se rompió.

Cuando algo no funcione, describe el síntoma, no la causa que supones. “Después de enviar el formulario no pasa nada, y esperaba un mensaje” ayuda más al modelo que “creo que tu estado está mal”.

El momento en que sí necesitas un desarrollador de verdad

Hay límites que, siendo honestos, no deberías cruzar por tu cuenta. No porque no estés a la altura, sino porque un error en estas áreas cuesta dinero real, datos reales o confianza real.

• Inicio de sesión y cuentas de usuario. La IA crea un formulario de inicio de sesión en un minuto, pero el almacenamiento seguro de contraseñas, las sesiones y la recuperación de acceso son un terreno donde un error silencioso significa una filtración. Aquí conviene usar un proveedor de autenticación ya hecho y probado, o pedir ayuda a alguien con experiencia.
• Pagos. Cobrar dinero conlleva regulaciones y responsabilidad. Usa integraciones ya hechas (como Stripe), pero pide a alguien con experiencia que lo revise antes de conectar tarjetas reales.
• Datos de personas reales. En cuanto guardas emails de otras personas, datos personales o cualquier cosa sensible, entran en juego normas y obligaciones de protección de datos que un prototipo ignora.
• Escala. Una app para 10 amigos y una app para 10 mil personas son dos mundos distintos. Si tu tráfico empieza a crecer, es buena señal, y un buen momento para un ingeniero de verdad.

La buena noticia: llegar a un prototipo funcional con vibecoding hace que la conversación con un desarrollador sea mucho más barata y concreta. Te presentas con algo que funciona, no con una idea vaga.

Cómo no meterte en un callejón sin salida

El error de principiante más común es construir de una forma que luego no permite crecer. Algunos hábitos que mantienen la puerta abierta:

• Mantén el alcance pequeño. Una app = una tarea principal. “Hace de todo” suele significar “no hace nada bien” y es imposible de mantener.
• No dejes secretos fijos en el código. Las claves de servicios y las contraseñas no deberían terminar directamente en el código. Si la herramienta ofrece “variables de entorno”, úsalas.
• Exporta y guarda el código. Elige herramientas que te permitan descargar el código o conectarlo a un repositorio (por ejemplo, GitHub). Es tu seguro para cuando quieras llevarte el proyecto a otra parte.
• No te ates a un único proveedor sin salida. Si todo vive solo dentro de una herramienta sin forma de exportarlo, dependes de sus precios y de sus decisiones.
• Guarda las versiones que funcionan. Antes de pedir un cambio grande, ten un punto al que puedas volver si algo se viene abajo.

Una idea realista para tu primer proyecto

El mejor primer proyecto es aburrido, pequeño y tuyo. No construyas “el nuevo Instagram”. Construye algo que necesites tú mismo y que quepa en una o dos pantallas.

Un ejemplo concreto: una página de inscripción a una lista de espera para una idea que te ronda por la cabeza. Una pantalla con una descripción, un campo de email, un botón y un mensaje de “gracias”. Guarda las direcciones, al menos al principio, en una hoja de cálculo sencilla o en un servicio ya hecho de recogida de emails, sin construir tu propia base de datos. Es un proyecto de una tarde que te enseña el ciclo completo: describir, generar, corregir, hacer el deploy. Y al final tienes algo real que puedes compartir.

Otros buenos candidatos: una calculadora sencilla para tu sector, un portfolio de una sola página, una lista de verificación interna para tu equipo. El denominador común: alcance pequeño, nada de datos sensibles, satisfacción rápida.

TL;DR

El vibecoding permite de verdad que una persona no técnica construya un prototipo funcional hablando con una IA, y eso es genial. El primer 80% de una aplicación sencilla es realista; el último 20% (inicio de sesión, pagos, datos, escala) es el momento de recurrir a un desarrollador de verdad. Elige una herramienta que te lleve de la mano (Lovable, Bolt; v0 para la interfaz, Replit para aprender), describe el comportamiento pantalla a pantalla, mantén el alcance pequeño, no dejes secretos fijos en el código y guarda una exportación del código. Empieza por algo aburrido y tuyo, aunque sea una página de inscripción a una lista de espera. Tu primer proyecto que funcione te enseñará más que diez tutoriales.