Vibe coding: ¿sirve para el software de tu empresa?

¿Qué es el vibe coding?

Es programar describiendo lo que quieres y aceptando lo que la IA escribe, sin leer el código.

El vibe coding es una forma de crear software en la que describes en lenguaje natural lo que quieres, una IA genera el código y tú juzgas el resultado por cómo se ve y cómo funciona, no por cómo está escrito. Si algo falla, pegas el error en el chat y pides que lo arregle. El código existe, pero casi nadie lo lee.

El término lo acuñó Andrej Karpathy, cofundador de OpenAI y exdirector de IA de Tesla, en una publicación del 2 de febrero de 2025. Lo describió como entregarse por completo a las vibras y olvidar que el código existe: aceptar todos los cambios sin leer las diferencias y pedir cambios al azar hasta que un error desaparezca. Él mismo aclaró que no estaba tan mal para proyectos desechables de fin de semana. En marzo de 2025 Merriam-Webster lo registró como expresión de tendencia, y el diccionario Collins la eligió palabra del año 2025.

Conviene separar dos cosas que hoy se mezclan. Una es el vibe coding en sentido estricto: aceptar sin revisar. Otra es programar con IA, que es lo que hace cualquier equipo de desarrollo serio en 2026: usar asistentes para escribir más rápido, pero leyendo, probando y respondiendo por cada línea que llega a producción. La herramienta puede ser la misma; la diferencia es quién entiende el resultado.

¿Para qué sí sirve: prototipos y validación?

Para probar una idea con usuarios reales antes de invertir en construirla bien, el vibe coding es difícil de superar.

El vibe coding brilla cuando el objetivo es aprender, no operar. Un prototipo navegable para mostrar a inversionistas, una página para medir si alguien deja su correo, una demo para validar con cinco clientes si el flujo tiene sentido: en todos esos casos, tener algo funcionando en días en lugar de meses vale más que un código impecable.

También funciona bien para herramientas internas pequeñas y de bajo riesgo: un tablero que lee una hoja de cálculo, un formulario que ordena solicitudes, un script que renombra archivos. Si se cae, nadie pierde dinero ni datos personales, y quien lo usa es la misma persona que lo hizo.

Para un fundador, además, es una forma excelente de llegar a una conversación con un equipo de desarrollo con mucho más claro lo que quiere. Un prototipo hecho con IA comunica mejor que veinte páginas de requisitos. Lo que no debe pasar es que ese prototipo se convierta, sin que nadie lo decida, en el sistema donde viven los clientes, los pagos y los datos de la empresa.

¿Dónde se rompe: seguridad, datos y mantenimiento?

Se rompe donde los errores no se ven en pantalla: permisos, datos de otros usuarios, secretos y cambios futuros.

El problema del vibe coding no es que el código no funcione, es que funciona en la demo y falla donde no se ve. La autenticación parece correcta porque el formulario de inicio de sesión aparece, pero la API responde a cualquiera que conozca la dirección. Los datos de un cliente se pueden leer cambiando un número en la URL. La llave de la pasarela de pagos quedó escrita en el código del navegador.

No es un riesgo teórico. En las pruebas del 2025 GenAI Code Security Report de Veracode, el código generado por IA introdujo fallas de seguridad riesgosas en el 45 % de los casos, y los modelos más grandes no lo hicieron mejor. En mayo de 2025 se registró la vulnerabilidad CVE-2025-48757: políticas de seguridad a nivel de fila (RLS) insuficientes en sitios generados con Lovable permitían a atacantes sin autenticar leer o escribir tablas de la base de datos. Lovable la disputó, argumentando que cada cliente es responsable de proteger los datos de su aplicación, y ese argumento es justamente el punto: la plataforma genera, pero quien publica responde.

El tercer frente es el mantenimiento. Un código que nadie entiende es caro de cambiar. Cada nueva función pedida a la IA puede romper otra, no hay pruebas automáticas que lo detecten y, cuando el proyecto crece, ni la propia IA logra mantener la coherencia. Lo que fue rápido el primer mes se vuelve lento en el sexto.

¿Cómo saber si tu app hecha con IA está lista para clientes reales?

Si no puedes responder sí a cada punto de esta lista, la app todavía es un prototipo, aunque ya tenga usuarios.

Antes de abrir la app a clientes, de cobrar o de cargar datos personales, revisa estos puntos. No hace falta saber programar para hacer las preguntas; sí hace falta que alguien con criterio técnico verifique las respuestas en el código y no solo en la pantalla:

• Autenticación: el inicio de sesión lo maneja un proveedor probado y cada ruta de la API verifica quién hace la petición, no solo la pantalla.
• Permisos y RLS: un usuario no puede ver ni modificar datos de otro cambiando un identificador; en bases como Supabase, cada tabla tiene políticas de seguridad a nivel de fila activas y probadas.
• Secretos: ninguna llave de API, contraseña o token está en el código del navegador ni en el repositorio; viven en variables de entorno del servidor.
• Datos personales: sabes qué datos guardas, dónde y por qué, y puedes atender una solicitud de eliminación como exige la Ley 1581 de 2012 en Colombia.
• Copias de seguridad: hay respaldos automáticos de la base de datos y ya probaste restaurar uno al menos una vez.
• Pruebas: los flujos críticos (registro, pago, permisos) tienen pruebas automáticas que corren antes de cada cambio.
• Pagos: la confirmación de pago llega por webhook verificado desde la pasarela, no porque el navegador diga que se pagó.
• Monitoreo: te enteras de un error en producción por una alerta, no porque un cliente te escriba por WhatsApp.
• Dependencias: las librerías están actualizadas y no hay paquetes inventados por la IA ni abandonados.

¿Rescatar o reconstruir: cómo decidir?

Se rescata lo que tiene buena estructura y fallas puntuales; se reconstruye cuando el problema está en la base de datos o en los permisos.

No todo prototipo hecho con IA hay que tirarlo. Muchas veces la interfaz, los flujos y buena parte del código sirven, y el trabajo es cerrar huecos: mover secretos al servidor, activar políticas de acceso, añadir pruebas y ordenar el despliegue. Otras veces el modelo de datos está tan mal planteado que cada arreglo es un parche sobre otro.

La decisión se toma después de una auditoría corta del código, no antes. Estas son las señales que miramos para recomendar una u otra opción:

¿Cómo usamos la IA los desarrolladores profesionales?

Usamos IA todos los días; la diferencia es que cada línea que llega a producción la revisa, la prueba y la entiende una persona.

En Beleaf usamos asistentes de IA para escribir código, generar pruebas, revisar cambios y documentar. Nos hacen más rápidos, y negarlo sería tan poco honesto como decir que reemplazan el criterio técnico. Lo que cambia frente al vibe coding es el proceso alrededor: la arquitectura y el modelo de datos los decide una persona antes de pedirle nada a la IA, cada cambio pasa por revisión, las pruebas automáticas corren antes de desplegar y los permisos se verifican en el servidor.

Ese proceso importa más cuanto más se complica el sistema. En plataformas multiempresa, como la que construimos para Kreatup, la separación de datos entre empresas, la sincronización con la tienda online y los roles de cada usuario son exactamente las partes donde un error silencioso cuesta clientes. Ninguna de esas decisiones se puede dejar a las vibras.

Si ya tienes un prototipo hecho con IA y estás pensando en lanzarlo, la mejor inversión no es reescribirlo a ciegas, sino pedir una revisión con la lista de arriba. Y si todavía estás validando la idea, sigue con el vibe coding: es la herramienta correcta para esa etapa. Lo importante es saber en qué momento cambiar de herramienta.