¿Qué es el vibe coding y cómo afecta a tu empresa?

El término que Karpathy puso nombre a algo que ya estaba pasando

Andrej Karpathy publicó en febrero de 2025 una idea sencilla: hay una nueva forma de programar en la que el código en sí deja de importarte. Describes lo que quieres, la IA lo escribe, tú lo revisas a grandes rasgos y sigues adelante. Lo llamó vibe coding.

El nombre pegó porque describía una práctica que miles de equipos ya hacían sin haberle puesto etiqueta. Founders construyendo MVPs en un fin de semana. Diseñadores generando componentes funcionales sin tocar JavaScript. Product managers prototipando flujos completos antes de involucrar a ingeniería.

Lo que Karpathy formalizó no es solo una técnica. Es un cambio de mentalidad sobre quién puede construir software y a qué velocidad. Ese cambio tiene implicaciones directas para la productividad de los equipos y para la forma en que las empresas piensan su desarrollo de software a mediano plazo.

El impacto ya es medible. Plataformas como Lovable reportaron un crecimiento explosivo de usuarios en los primeros meses de 2025, con decenas de miles de proyectos iniciados por personas sin formación técnica previa. La tendencia no es experimental: ya está afectando decisiones de contratación, presupuesto y estructura de equipos en empresas de distintos tamaños.

Cómo funciona en la práctica

El flujo básico tiene 3 pasos. Escribes un prompt describiendo lo que necesitas (por ejemplo: “una pantalla de login con validación de email y un botón de Google OAuth”). La herramienta genera el código. Tú iteras con más instrucciones hasta que el resultado se acerca a lo que necesitas.

Lovable, Bolt y v0 son las herramientas que más tracción tienen para este flujo sin conocimientos técnicos previos. Lovable genera aplicaciones web completas desde una descripción en lenguaje natural, incluyendo lógica de backend básica y conexión a base de datos. Bolt, disponible en bolt.new, produce código React listo para producción con una interfaz que guía al usuario paso a paso. v0 se especializa en componentes de interfaz y lleva el respaldo de Vercel, la infraestructura donde corre buena parte de la web moderna.

Cursor apunta a un perfil distinto: desarrolladores que ya saben programar pero quieren acelerar su trabajo. En ese entorno, el 60-70% del código que los equipos producen ya sale de la IA, según datos publicados por la propia compañía entre 2024 y 2025. No es asistencia puntual; es generación masiva con supervisión humana.

Lo que hace diferente al vibe coding de los asistentes de código que existían antes es la intención. No se trata de autocompletar una función o corregir un error. Se trata de delegar la construcción completa de una funcionalidad, o incluso de un producto, a un sistema que interpreta instrucciones en lenguaje cotidiano.

Esto significa que el prompt se convierte en la habilidad central. Saber describir con precisión qué quieres, qué restricciones tiene el sistema, qué casos borde deben cubrirse: eso determina la calidad del output más que cualquier otro factor. La capacidad de hacer buenas preguntas y dar buenas instrucciones es ahora una competencia técnica real, aunque no requiera saber escribir código.

Qué cambia para un equipo no técnico

El cambio más concreto es que el prototipo deja de ser un bloqueador. Antes, una idea de producto pasaba semanas o meses esperando que alguien con tiempo y conocimientos técnicos la materializara. Ahora un PM con 2 horas y un prompt bien escrito puede tener algo funcional para mostrarle a un cliente o a un inversor.

Esto tiene consecuencias reales en cómo se priorizan las ideas. Si probar un concepto cuesta 3 horas en vez de 3 semanas, el umbral para experimentar baja de forma significativa. Los equipos que entienden esto están moviendo su ciclo de decisión mucho más rápido que los que siguen esperando que ingeniería tenga espacio en el sprint.

También cambia la conversación entre áreas. Cuando el equipo de operaciones puede construir una herramienta interna básica sin depender de ingeniería, la dinámica de quién espera a quién se invierte. Eso no significa que ingeniería desaparece. Significa que sus horas van a problemas más complejos, a arquitectura, a seguridad, a las decisiones que realmente requieren criterio técnico profundo.

Para equipos en América Latina y España que operan con recursos limitados, esta reconfiguración tiene un valor especial. La escasez de desarrolladores disponibles y asequibles ha sido históricamente un cuello de botella para empresas que quieren crecer con tecnología propia. El vibe coding no elimina esa limitación, pero la desplaza: ahora el cuello de botella no es quién puede construir, sino quién puede pensar con claridad qué construir y para qué.

La productividad del equipo también cambia cualitativamente, no solo en velocidad. Cuando las personas que conocen el problema de negocio pueden materializar sus ideas directamente, se eliminan capas de traducción entre lo que se necesita y lo que se construye. Ese ruido de comunicación ha sido durante décadas una fuente constante de retrasos y productos que no encajan con lo que el usuario necesitaba.

Los riesgos que nadie menciona en los tutoriales

El mayor problema del vibe coding no es técnico. Es de gobernanza. Cuando cualquier persona en la empresa puede generar código funcional, la pregunta de quién revisa ese código y bajo qué criterios se vuelve urgente. Esa pregunta no tiene una respuesta automática, y la mayoría de los equipos no la responden hasta que algo falla.

Hay tres riesgos concretos que los equipos deben considerar antes de adoptar este enfoque de forma generalizada.

Dependencia de herramientas de terceros

Si tu operación crítica corre sobre código generado por Lovable o Bolt, necesitas entender qué pasa si esa herramienta cambia su modelo de precios, limita sus capacidades, modifica sus condiciones de uso o simplemente desaparece. El ecosistema de herramientas de IA para desarrollo de software está en un estado de cambio permanente. Lo que hoy es la opción dominante puede ser irrelevante en 18 meses. Los equipos que construyen sobre estas plataformas sin una estrategia de salida están asumiendo un riesgo de continuidad que pocas veces se evalúa con seriedad.

Seguridad del código generado

Los modelos de IA generan código que funciona, pero no siempre generan código seguro. Autenticación mal implementada, exposición de variables de entorno, validaciones incompletas, gestión deficiente de sesiones: son errores que la IA reproduce porque los reproduce la web en la que se entrenó. Un prototipo funcional que maneja datos de usuarios o se conecta a sistemas externos puede tener vulnerabilidades reales que no son visibles sin una revisión específica. El hecho de que la IA lo haya generado no es una garantía de seguridad; es, en algunos contextos, una razón adicional para revisarlo con cuidado.

Mantenibilidad a largo plazo

El código que nadie entiende es código que nadie puede mantener. Si el resultado de un sprint de vibe coding es una aplicación funcional pero opaca, el costo de modificarla, extenderla o integrarla con otros sistemas puede ser mayor que haberla construido con criterio desde el principio. La deuda técnica no es abstracta: se materializa en horas de trabajo no planificadas, en bugs que aparecen en el peor momento y en la imposibilidad de incorporar nuevas funcionalidades sin romper lo que ya existe. Este es el riesgo que más subestiman los equipos que adoptan el vibe coding sin establecer ningún tipo de revisión del output.

Cómo incorporarlo sin crear problemas nuevos

El enfoque más sensato no es prohibirlo ni adoptarlo sin criterio. Es establecer en qué contextos tiene sentido y en cuáles el costo de los riesgos supera el beneficio de la velocidad.

Para prototipos y validación de ideas, el vibe coding es difícilmente superable. La velocidad de iteración justifica los tradeoffs. Ningún MVP necesita ser perfecto; necesita ser suficientemente bueno para aprender algo útil. En este contexto, la calidad del código es secundaria respecto a la velocidad de aprendizaje.

Para herramientas internas de bajo riesgo, también tiene sentido, siempre que alguien con criterio técnico básico revise el output antes de que toque datos sensibles o se integre con sistemas core. Una herramienta interna que automatiza un proceso administrativo puede construirse con vibe coding con bajo riesgo. Una herramienta interna que accede a datos financieros o de clientes requiere una capa adicional de revisión.

Para productos en producción con usuarios reales, el código generado por IA debe pasar por revisión técnica antes de desplegarse. No porque la IA sea mala, sino porque cualquier código en producción requiere esa capa de control, independientemente de quién lo escribió o cómo. Esa revisión no tiene que ser exhaustiva en todos los casos, pero sí tiene que existir como práctica sistemática.

La clave práctica es separar la fase de generación de la fase de revisión, y asignar responsabilidades claras a cada una. Un PM puede generar el 80% del trabajo con prompts bien construidos. Un desarrollador con 2 horas puede revisar, refactorizar los puntos críticos y solidificar el resultado para que sea mantenible. Esa división es más eficiente que cualquiera de los dos trabajando solos en todo el proceso.

Los equipos que están obteniendo mejores resultados con el vibe coding son los que han establecido criterios explícitos: qué tipos de proyectos pueden iniciarse con estas herramientas, qué revisión requiere el output según el nivel de riesgo, y quién tiene la responsabilidad final sobre lo que se despliega. Esa estructura no frena la velocidad; la hace sostenible.

Conclusión

El vibe coding no es una moda pasajera. Karpathy le puso nombre a una tendencia estructural que ya mueve el mercado de herramientas de desarrollo de software y que está redefiniendo qué significa la productividad en equipos técnicos y no técnicos por igual. Para equipos en América Latina y España que operan con recursos limitados, la posibilidad de prototipar rápido, reducir dependencias de ingeniería y acortar los ciclos de validación es una ventaja competitiva real y accesible hoy. El riesgo está en confundir velocidad con solidez: lo que la IA genera en minutos puede costar semanas arreglarlo si nadie lo revisa con criterio. La diferencia entre los equipos que aprovechan esta tendencia y los que crean problemas nuevos con ella no está en las herramientas que usan, sino en cómo gobiernan lo que producen.