Qué es el vibe coding: qué puedes crear hablando con una IA y dónde falla

Vibe coding: una expresión nacida en un post y adoptada por los diccionarios

Mucha gente busca qué es el vibe coding porque la expresión llegó deprisa y desde un único lugar. El 2 de febrero de 2025, Andrej Karpathy, cofundador de OpenAI y antiguo responsable de IA en Tesla, escribió en X sobre una forma de programar en la que te dejas llevar por las vibraciones y olvidas que el código existe. La Wikipedia en inglés toma esa publicación como origen. Según ella, Merriam-Webster registró la expresión como jerga en tendencia en marzo de 2025.

Collins fue más lejos. En noviembre de 2025 eligió vibe coding como palabra del año y la definió como el uso de inteligencia artificial, guiada con lenguaje natural, para escribir código. Su anuncio lo dice también de forma cotidiana: decirle a una máquina lo que quieres en lugar de programarlo tú con esfuerzo. Añade que los expertos aún discuten si la práctica es revolucionaria o temeraria.

Aceptar código sin leerlo separa el vibe coding de la ayuda de la IA

La publicación de Karpathy describe el método con detalle. Habla con la herramienta en vez de teclear, pulsa siempre Accept All y ya no lee los diffs, la lista de cambios que propone el modelo. Si aparece un error, pega el mensaje sin comentarios y casi siempre se arregla. Reconoce que el código crece más allá de lo que entiende y que algunos fallos prefiere esquivarlos. Lo consideró aceptable para proyectos de fin de semana desechables.

Ese matiz marca la frontera. La Wikipedia describe la práctica como desarrollo asistido por IA que puede implicar aceptar el código generado sin una revisión a fondo. Quien pide una función al modelo, la lee, la prueba y la entiende está usando un asistente, y el código sigue siendo suyo. En el vibe coding se entrega al modelo también la comprensión. Las herramientas son las mismas; lo que cambia es si alguien ha leído el resultado.

Lo que alguien sin formación técnica puede crear describiéndolo a una IA

La Wikipedia recoge un ejemplo temprano y modesto. En febrero de 2025, el periodista del New York Times Kevin Roose, que no es desarrollador profesional, creó así pequeñas aplicaciones que llamó software para uno, y vio que los resultados solían ser limitados y propensos a errores. Ese es el terreno real del método: herramientas para una persona o un equipo pequeño. Ahí un fallo cuesta una tarde, no los datos personales de nadie.

Replit es uno de los productos construidos alrededor de esta idea. Según su documentación, su Agent convierte tus ideas en aplicaciones a partir de lenguaje sencillo: prepara el proyecto, configura bases de datos, revisa su trabajo y corrige problemas. Así puedes obtener un prototipo navegable para un socio o un inversor, o una página que mide el interés por una oferta nueva. También encajan herramientas internas pequeñas: una calculadora de precios, una tabla de reservas, un formulario que ordena solicitudes.

Estos proyectos comparten una vida corta o pocos usuarios. Un prototipo existe para verlo, comentarlo y tirarlo. Una herramienta interna la usan compañeros que avisarán en cuanto falle. Por ellas no pasa ningún número de tarjeta, y si una se para un lunes por la mañana, alguien abre una hoja de cálculo y sigue.

Dónde fallan primero las apps hechas con vibe coding: accesos y datos

El OWASP Top 10, que sus autores llaman documento estándar de concienciación sobre seguridad de aplicaciones web, pone el control de acceso roto en primer lugar en su edición de 2025. Según OWASP, el control de acceso impide que los usuarios actúen fuera de sus permisos. Entre los fallos típicos están ver o editar la cuenta de otra persona indicando su identificador, y una API que no comprueba quién modifica o borra datos. OWASP informa de que todas las aplicaciones que probó tenían alguna forma de esta debilidad.

Ese fallo no lo ve quien nunca lee el código. En una demostración la app parece correcta: entras y ves tus pedidos. Si cambiar un número en la barra de direcciones muestra los pedidos de otro, nadie lo sabe hasta que alguien lo prueba a propósito. La Wikipedia registra que en mayo de 2025, 170 de 1645 aplicaciones web creadas con una conocida app de vibe coding tenían un fallo que permitía a cualquiera acceder a datos personales.

La lección no es que el código generado sea siempre peor. Las reglas sobre quién puede ver qué no aparecen en una demostración, y nadie nota que faltan. Un prototipo con tres clientes inventados vive sin ellas. Una app con clientes reales no, y revisarlas exige a alguien que lea código y sepa qué puertas probar.

Pagos, mantenimiento y un código que nadie del equipo entiende

El dinero trae sus propias reglas. El PCI Security Standards Council indica que su norma PCI DSS se aplica a las entidades que almacenan, procesan o transmiten datos de titulares de tarjetas. Un pago casero con números de tarjeta mete al negocio en ese terreno sin que nadie lo decida. Lo habitual es enviar los datos de la tarjeta a la página de un proveedor de pagos y que la app reciba solo el resultado. Si eso basta en tu caso, consúltalo con el proveedor y con un especialista.

Luego está el mantenimiento, porque el software casi nunca se termina. La Wikipedia cita al ingeniero Simon Willison: llegar a un código de producción a base de vibe coding es claramente arriesgado, porque casi todo el trabajo real es cambiar sistemas existentes, donde la calidad y la claridad del código pesan más. El propio Karpathy admitió que su código había superado su comprensión. En una app que recibe pedidos, eso significa que cada petición nueva al modelo puede romper en silencio algo que ayer funcionaba.

Y queda el lado humano. Cuando quien escribió las instrucciones se va u olvida cómo se montó todo, nadie conserva el conocimiento. Normalmente no hay pruebas, ni documentación, ni registro de qué instrucción produjo cada parte. Quien hereda el proyecto debe leerlo entero antes de tocar una línea, y esa lectura es la parte lenta y cara de cualquier rescate.

Cómo hacer un prototipo con IA sin datos reales ni claves expuestas

Empieza por el alcance. Escribe en tres frases qué debe mostrar el prototipo, quién lo verá y cuándo se retirará. Llénalo de datos inventados: nombres ficticios, correos de prueba, pedidos de ejemplo. No pegues nunca una lista real de clientes para ver cómo queda. Con datos personales reales dentro, el prototipo pasa a ser un sistema que hay que proteger y puede aplicarse la ley de protección de datos, así que revisa tu caso con un especialista.

Las claves piden el mismo cuidado. La documentación de Replit advierte que los secretos, como claves de API y tokens, escritos en el propio código pueden filtrarse si este se comparte públicamente, se sube a un repositorio público o aparece al compartir pantalla; su herramienta Secrets los cifra y los entrega a la app como variables de entorno. La documentación de GitHub explica que su escaneo de secretos revisa todo el historial de Git en todas las ramas, un recordatorio de que una clave borrada sigue en versiones anteriores. Si una clave real llega al código, cámbiala en el servicio que la emitió.

Guarda una vía de vuelta y prueba el prototipo como un extraño

La documentación de Replit describe los puntos de control: instantáneas completas que su Agent crea en los hitos clave, base de datos incluida. La misma página aclara que, por defecto, una reversión no modifica la base de datos, y que la base de producción se restaura con un proceso aparte a un momento concreto. Deshacer el código no equivale a deshacer los datos. La Wikipedia recoge además un caso de julio de 2025 en el que el agente de IA de Replit borró una base de datos pese a la instrucción explícita de no cambiar nada. Uses la herramienta que uses, guarda tu copia del código en un repositorio y una exportación de los datos.

Después prueba el prototipo como lo haría un extraño curioso. Entra con dos usuarios de prueba y comprueba que ninguno ve los registros del otro. Cambia números en la barra de direcciones, envía formularios vacíos y absurdamente largos, cierra la pestaña a mitad de un guardado. Lleva una lista de lo que debe hacer cada pantalla y repásala a mano tras cada cambio grande: el modelo que arregla una pantalla puede reescribir otra.

Cuándo un prototipo de vibe coding necesita un desarrollador para ser producto

La señal es fácil de recordar: personas reales, datos reales o dinero real. Una herramienta interna, para pocos compañeros y sin datos personales, puede seguir en tus manos. Si va a guardar cuentas de clientes, cobrar, conectarse a tu contabilidad o usarse a diario durante meses, necesita a alguien que lea código. A veces el prototipo se puede limpiar y conservar; otras es más sensato tratarlo como una especificación detallada y reconstruirlo. Solo un desarrollador que mire dentro puede decir cuál es tu caso.

Antes de esa conversación, reúne lo que ya tienes. Eso incluye el acceso al prototipo y a su código, lo que debe hacer cada pantalla, quién lo usará, qué datos guarda y de dónde vienen, los pagos e integraciones previstos y tus instrucciones o notas. Con eso sobre la mesa, un estudio como VITON13 puede estimar el trabajo en lugar de adivinar. Y la pregunta de qué es el vibe coding se convierte en otra más práctica: qué parte de tu prototipo merece la pena conservar.