Vibe Coding: qué es y cómo crear una aplicación con IA paso a paso

El Vibe Coding consiste en describir una aplicación en lenguaje natural y utilizar un agente de IA para generar y modificar su código. Para que entiendas como funciona hemos construido «ReservaLab» desde cero explicándote paso a paso como lo hemos hecho ¡Sigue leyendo!

Qué es realmente el Vibe Coding

Andrej Karpathy popularizó la expresión vibe coding en en X el 3 febrero de 2025 al describir una forma de programar basada en explicar a un modelo qué quería construir, aceptar cambios, ejecutar el resultado y devolver los errores a la IA para continuar iterando. Su formulación original era deliberadamente informal y estaba vinculada a proyectos experimentales.

En 2026 el término aparece también en la documentación de herramientas de desarrollo. Replit, por ejemplo, describe un flujo que parte de una intención expresada en lenguaje natural, genera software, permite probarlo y continúa mediante nuevas instrucciones y correcciones.

Forma de desarrollo	Qué hace la IA	Qué hace la persona
Autocompletado	Sugiere líneas o fragmentos de código mientras escribimos.	Escribe y estructura el programa.
Copiloto	Genera funciones, explica código y ayuda a depurar.	Mantiene control directo sobre los cambios.
No-Code / Low-Code	Puede generar lógica o ayudar a configurar componentes.	Trabaja principalmente con las abstracciones de la plataforma.
Vibe Coding	Convierte instrucciones en lenguaje natural en cambios sobre una aplicación completa.	Describe, prueba, corrige y dirige el desarrollo.
Desarrollo agéntico	Lee repositorios, modifica archivos, ejecuta comandos y comprueba resultados.	Define objetivos, restricciones y criterios de aceptación.

Construimos una aplicación de reservas con IA

Para escribir este artículo hemos desarrollado ReservaLab, una app que gestiona plazas para pequeñas clases o actividades por lo que vas a ver es un ejemplo real (vibe_coding_demo y sesion log). Un administrador crea una clase, fija fecha y aforo y los usuarios pueden consultar disponibilidad, reservar y cancelar.

El proyecto necesita actividades, usuarios, reservas, persistencia de datos y dos niveles de permisos. El código, los errores y los tests que aparecen a continuación proceden de la ejecución real de la aplicación.

Herramientas utilizadas en la prueba: construimos ReservaLab con un agente de programación (Codex, Cursor Agent o Replit Agent) trabajando sobre un proyecto local. El agente generó y modificó el código; ejecutamos el backend con Python, utilizamos SQLite para almacenar usuarios, clases y reservas y probamos la interfaz en el navegador. Los tests automáticos se ejecutaron sobre el propio proyecto para comprobar duplicados, aforo y permisos.

Paso 1. Explicar qué queremos construir

Empezamos con un prompt corto, sin especificar framework, base de datos ni estructura de archivos:

Quiero crear una aplicación web sencilla para gestionar reservas de clases. Un administrador crea las clases y define plazas disponibles. Los usuarios pueden consultar horarios, reservar una plaza y cancelar su reserva.

Dejamos decisiones pendientes a propósito: cómo identificar a cada usuario, dónde guardar las reservas, qué operaciones correspondían al administrador, qué ocurría cuando se agotaban las plazas y cómo impedir que una misma persona reservase dos veces.

Antes de generar más código utilizamos un segundo prompt:

Antes de escribir código, hazme las preguntas necesarias para definir usuarios, datos, permisos y funciones principales. No implementes todavía nada.

Ese segundo prompt hizo que el agente enumerase decisiones sobre usuarios, datos, permisos y funciones antes de generar más código.

Paso 2. El primer prototipo

La primera versión ya mostraba clases disponibles, botones para reservar y una identificación básica de usuarios. Detrás de esa pantalla había cinco piezas distintas:

Capa	Qué hace en ReservaLab
Frontend	Muestra clases, formularios, botones y disponibilidad.
Backend	Recibe las peticiones y aplica las reglas de reserva.
Base de datos	Guarda usuarios, clases y reservas.
Sesión	Identifica al usuario conectado.
Autorización	Determina qué operaciones puede ejecutar cada rol.

El recorrido básico permitía reservar. Todavía faltaba comprobar qué ocurría con reservas duplicadas, aforo, persistencia y peticiones enviadas directamente al backend.

Paso 3. Rompemos el backend

Al crear una clase como administrador apareció un error real en el backend:

AttributeError: 'sqlite3.Cursor' object has no attribute 'lastrow'.
Did you mean: 'lastrowid'?

El código intentaba recuperar el identificador de una nueva fila mediante un atributo inexistente de SQLite. La modificación necesaria era:

lastrow → lastrowid

Utilizamos este prompt:

Reproduce el error, identifica la causa y explícame qué prueba demostraría que está corregido. No modifiques otras funciones.

El agente sustituyó lastrow por lastrowid. Ejecutamos de nuevo la prueba de creación de clases y la operación terminó correctamente.

Paso 4. Guardamos usuarios, clases y reservas

ReservaLab utiliza SQLite para conservar la información después de recargar la aplicación. La estructura se redujo a tres tablas:

• users: usuarios y roles;
• classes: actividad, fecha y aforo;
• bookings: relación entre un usuario y una clase.

La tabla bookings incluye una restricción para impedir que la misma persona reserve dos veces la misma clase. La interfaz puede desactivar un botón, pero la base de datos sigue rechazando el duplicado si la petición llega por otra vía.

El aforo también se comprueba al procesar la reserva. La disponibilidad que aparece en pantalla procede de esa misma información almacenada.

Paso 5. Añadimos login y permisos

ReservaLab utiliza dos roles. Un usuario puede consultar, reservar y cancelar; un administrador puede además crear clases.

La interfaz oculta las operaciones administrativas cuando entra un usuario normal. Probamos después la misma operación directamente contra el backend y el servidor volvió a comprobar el rol antes de aceptar la petición.

403 Forbidden

Ese fue el resultado al intentar crear una clase con una cuenta sin permisos de administrador. La documentación de seguridad de Lovable recoge la misma separación entre interfaz y servidor: el código que se ejecuta en el navegador puede inspeccionarse o manipularse y las decisiones de autorización deben aplicarse también en backend.

Paso 6. Revisamos seguridad

La aplicación ya permitía entrar, crear clases y reservar. Al revisar el código encontramos contraseñas almacenadas en texto plano, de modo que cualquier acceso a la base de datos habría permitido leerlas directamente.

Las sustituimos por hashes derivados mediante PBKDF2 y un salt independiente para cada contraseña. La revisión encontró además un segundo fallo en el frontend: los títulos de las clases se insertaban mediante innerHTML sin escapar previamente su contenido.

Utilizamos este prompt antes de hacer nuevas modificaciones:

Revisa el proyecto buscando problemas de autenticación, permisos, validación de datos, secretos expuestos y datos que puedan ejecutarse en el navegador. Primero enumera los riesgos y explica cómo comprobarlos. No modifiques todavía el código.

La versión revisada quedó con estos controles:

• contraseñas derivadas mediante PBKDF2;
• salt independiente;
• consultas SQL parametrizadas;
• roles comprobados en servidor;
• restricción contra reservas duplicadas;
• comprobación del aforo durante la reserva;
• cookie de sesión HttpOnly;
• SameSite=Lax;
• escape de contenido antes de renderizarlo.

Antes de utilizar ReservaLab con usuarios reales siguen pendientes:

• recuperación de contraseña;
• rate limiting;
• protección CSRF completa;
• monitorización;
• auditoría de actividad;
• infraestructura de producción.

Paso 7. Añadimos tests

Terminamos la prueba con cuatro tests automáticos sobre operaciones que ya formaban parte del comportamiento esperado de ReservaLab:

• una persona no puede reservar dos veces la misma clase;
• una clase no puede superar su aforo;
• un usuario normal no puede crear clases;
• un administrador sí puede crearlas.

La ejecución real devolvió:

test_admin_can_create_class ... ok
test_capacity_cannot_be_exceeded ... ok
test_duplicate_booking_is_blocked ... ok
test_regular_user_cannot_create_class ... ok

Ran 4 tests
OK

Para preparar las pruebas utilizamos:

Genera tests para los casos normales y para los límites que podrían romper esta función. Antes de escribir cada prueba, explica qué comportamiento intenta demostrar.

Qué le falta a ReservaLab antes de publicarla para usuarios reales

Fase	Qué queremos comprobar	Qué necesita
Idea	La necesidad y el flujo tienen sentido.	Usuario, necesidad y funciones esenciales.
Prototipo	La interacción puede probarse.	Interfaz, recorrido y feedback.
Aplicación	Una persona puede utilizarla realmente.	Datos persistentes, autenticación, permisos, errores e integraciones.
Producto	Puede mantenerse con usuarios reales.	Seguridad, tests, monitorización, backups, despliegue, costes, soporte y mantenimiento.

ReservaLab ya dispone de frontend, backend, persistencia, usuarios, permisos y pruebas automáticas. Faltan recuperación de acceso, monitorización, copias de seguridad operativas, protección adicional, infraestructura de despliegue y procedimientos para mantener el servicio.

Una secuencia de prompts como «añade filtros», «crea favoritos», «permite repetir reservas» o «añade otra vista de administración» puede dejar componentes muy grandes, código duplicado, nombres inconsistentes y dependencias innecesarias. La deuda técnica es el coste que dejan esas decisiones rápidas cuando dificultan modificar o mantener el software después.

Revisa la arquitectura actual de este proyecto antes de añadir nuevas funciones. Identifica duplicación, componentes demasiado grandes, dependencias innecesarias y riesgos de mantenimiento. No modifiques todavía el código.

Construir ReservaLab deprisa abarata la prueba técnica. La demanda necesita otra prueba: que alguien utilice el producto, vuelva a utilizarlo y, cuando corresponda, esté dispuesto a pagar. En nuestra guía de ideas de negocio rentables trabajamos esa parte mediante entrevistas, prototipos, preventas y primeras ventas.

Qué herramientas de Vibe Coding existen en 2026

Herramienta	Encaja especialmente bien en	Cómo trabajas
Lovable	Aplicaciones y prototipos web.	Conversación, interfaz visual y servicios de backend.
Replit	Pasar de una idea a una aplicación y publicarla dentro del mismo entorno.	Agente, código, Preview y despliegue.
Bolt	Prototipos, webs y aplicaciones creadas desde navegador.	Conversación, editor, base de datos y entorno de ejecución.
Codex	Construcción y mantenimiento de software, funcionalidades, refactors y migraciones.	Agente disponible en ChatGPT, editor y terminal que puede trabajar sobre proyectos completos.
Cursor	Desarrollo sobre repositorios manteniendo contacto directo con el código.	IDE, agentes, revisión de cambios y terminal.
Claude Code	Trabajo agéntico sobre proyectos desde terminal y otros entornos de Claude Code.	Explora el proyecto, modifica archivos y ejecuta herramientas.
GitHub Copilot	Desarrollo integrado en repositorios, IDE y flujos de GitHub.	Planificación, cambios de código, tests y trabajo sobre ramas y pull requests.

Lovable, Replit y Bolt permiten partir de una descripción y llegar a una primera aplicación visible sin disponer previamente de un repositorio. Replit reúne agente, ejecución y despliegue, mientras que Bolt incorpora entorno de ejecución, base de datos y publicación desde la propia plataforma. Bolt documenta aquí su entorno de construcción y despliegue.

Codex, Cursor, Claude Code y GitHub Copilot pueden trabajar directamente sobre proyectos existentes. Codex aborda funcionalidades, refactorizaciones y migraciones y está disponible desde ChatGPT, editor y terminal. GitHub Copilot puede trabajar sobre un repositorio, preparar cambios y presentarlos mediante pull request para revisión. Cursor y Claude Code ofrecen flujos similares desde el editor o la terminal.

¿Se puede hacer Vibe Coding sin saber programar?

Sí, para determinados prototipos, herramientas personales, pequeñas aplicaciones, automatizaciones y MVP sencillos.

Con datos reales, integraciones, distintos tipos de usuario o acciones que pueden tener consecuencias, aparecen decisiones que ya no podemos resolver mirando únicamente si la pantalla funciona: arquitectura, bases de datos, APIs, autenticación, permisos, seguridad, tests, despliegue, monitorización y mantenimiento.

En IEBS trabajamos la construcción de aplicaciones con IA y herramientas No-Code en nuestro Postgrado en Desarrollo Inteligente de Apps con IA.

Qué facilita para quien ya sabe programar

Un desarrollador puede delegar una funcionalidad, una migración, una refactorización o la generación inicial de tests y revisar después el diff, la arquitectura, las dependencias y la salida de las pruebas. Codex, Cursor, Claude Code y GitHub Copilot están diseñados para trabajar sobre ese tipo de tareas y repositorios existentes.

Anthropic analizó en 2026 alrededor de 400.000 sesiones de Claude Code. En una sesión típica, las personas tomaban la mayor parte de las decisiones de planificación —qué hacer— y Claude asumía una mayor parte de las decisiones de ejecución —cómo hacerlo—; los usuarios con mayor experiencia en el dominio también obtenían mejores tasas de éxito. El estudio completo está publicado por Anthropic.

Un agente puede encargarse de estructuras iniciales, CRUD sencillos, primeras versiones de tests, documentación, búsquedas dentro del repositorio, depuración frecuente y refactorizaciones delimitadas. Arquitectura, modelado de datos, seguridad, dependencias y migraciones siguen necesitando revisión antes de incorporar los cambios al sistema.

8 prompts más útiles que «hazme una app»

1. Antes de escribir código

Antes de escribir código, hazme las preguntas necesarias para definir usuarios, datos, permisos, funciones principales y situaciones de error.

2. Para entender la arquitectura

Explícame la arquitectura actual del proyecto para una persona con conocimientos técnicos básicos. Indica frontend, backend, base de datos, autenticación, servicios externos y cómo fluye la información.

3. Antes de modificar varias partes

Analiza qué archivos, componentes y datos afectará este cambio. Propón primero el plan y los riesgos. No modifiques todavía el proyecto.

4. Para depurar un fallo

Reproduce el error, identifica la causa probable y dime qué prueba demostraría que está solucionado. Evita modificar funciones que no estén relacionadas.

5. Para revisar permisos

Crea una tabla con cada rol y las operaciones que puede leer, crear, modificar, eliminar o ejecutar. Comprueba que las restricciones se verifican en el servidor y no únicamente en la interfaz.

6. Para revisar seguridad

Busca problemas de autenticación, autorización, validación de datos, secretos expuestos, dependencias inseguras y entradas que puedan ejecutarse en el navegador. Enumera primero los hallazgos y cómo comprobarlos.

7. Para generar tests

Genera tests para los casos normales, errores y límites de esta función. Antes de escribir cada test, explica qué comportamiento intenta demostrar.

8. Para revisar deuda técnica

Revisa la arquitectura actual de este proyecto antes de añadir nuevas funciones. Identifica duplicación, componentes demasiado grandes, dependencias innecesarias y riesgos de mantenimiento. No modifiques todavía el código.

Checklist IEBS antes de publicar una aplicación hecha con IA

Área	Pregunta
Arquitectura	¿Entiendo qué componentes ha generado y cómo se comunican?
Datos	¿Sé dónde se almacenan, quién puede acceder y cómo recuperarlos?
Autenticación	¿La aplicación identifica correctamente a cada usuario?
Permisos	¿Se comprueban en backend o base de datos y no únicamente en la interfaz?
Secretos	¿Hay claves API, tokens o contraseñas expuestos en frontend o repositorio?
Casos límite	¿Hemos probado datos incorrectos, duplicados, concurrencia y situaciones de borde?
Tests	¿Existen pruebas que detecten si un cambio rompe funciones relevantes?
Dependencias	¿Sabemos qué librerías necesita el proyecto y cómo se mantienen?
Servicios externos	¿Sabemos qué APIs, modelos y proveedores utiliza?
Backup	¿Podemos recuperar los datos si falla la aplicación o la infraestructura?
Costes	¿Sabemos cómo crecerá el gasto cuando aumenten usuarios, almacenamiento o llamadas a servicios externos?
Portabilidad	¿Conservamos código y datos si cambiamos de plataforma?
Mantenimiento	¿Otra persona puede comprender y continuar el proyecto?

ReservaLab empezó con una descripción en lenguaje natural y terminó con frontend, backend, base de datos, roles, controles de seguridad y tests. La aplicación no está terminada porque dejamos algunas cosas por hacer pero aunque no lo creas la construí en solo cinco minutos. Sin gastar un euro en cursos básicos que además son muy caros y que te prometen enseñarte a hacer esto que yo te enseño gratis.