Andrej Karpathy acuñó el término vibe coding en febrero de 2025 para describir un modo de desarrollo de software en el que se describe lo que se quiere, se acepta lo que genera la IA y no se lee el código. Su descripción era generosa: un modo de hobbyista de fin de semana para proyectos personales. Lo que vino después no lo fue. A mediados de 2025, una oleada de personas sin formación técnica había lanzado aplicaciones SaaS de producción construidas íntegramente en Cursor, Replit Agent, v0 y bolt.new, sin haber llegado a entender lo que habían creado. Las aplicaciones tenían buen aspecto en las demostraciones. Algunas están fallando en producción.
Qué es realmente el "vibe coding"
La descripción original de Karpathy es precisa: uno está en la zona, le dice a la IA lo que quiere, genera código, acepta casi todo y no llega a entender del todo lo que está ejecutándose. Él mismo lo reconoció explícitamente: "No leo el código, simplemente vibo con él". Para una herramienta personal o un prototipo desechable, esto es perfectamente válido. El practicante de vibe coding no pretende ser un ingeniero. El problema es que el ecosistema de herramientas, con el "lanza tu startup en un fin de semana" de Replit Agent, los despliegues con un clic de v0 y la generación instantánea de aplicaciones full-stack de bolt.new, ha presentado este modo como un camino legítimo hacia el software de producción.
La deuda técnica resultante es cualitativamente diferente del código deficiente habitual.
Por qué el código generado por "vibe coding" es peor que el código manual deficiente
Cuando un desarrollador junior escribe código deficiente, al menos entiende lo que intentaba hacer. Es posible sentarse con él, rastrear la lógica y corregirlo. Cuando una IA genera código deficiente que el operador nunca leyó, no hay modelo mental que recuperar. El desarrollador no puede explicar por qué la autenticación está estructurada como está, porque nunca leyó el código de autenticación. No puede decir qué librería de terceros gestiona los pagos, porque aceptó el archivo sin abrirlo. El código es una caja negra que posee pero sobre la que no puede razonar.
Los patrones de fallo que aparecen de forma recurrente en aplicaciones de producción generadas por IA:
- Vulnerabilidades de autenticación integradas en el andamiaje; secretos JWT presentes en ejemplos de variables de entorno confirmados en repositorios públicos. Son hallazgos comunes en revisiones de código de proyectos asistidos por IA sin supervisión de ingeniería. El código de autenticación generado por IA copia con frecuencia patrones de sus datos de entrenamiento sin comprender el modelo de seguridad. La seguridad a nivel de fila se desactiva "temporalmente" durante el desarrollo y se olvida en producción. Las comprobaciones de roles que comparan literales de texto fallan en cuanto se renombra un campo.
- Sin gestión de errores más allá del camino feliz. La IA escribió el caso de éxito. ¿Qué ocurre cuando el proveedor de pagos devuelve un 402? ¿Qué pasa cuando la conexión a la base de datos se interrumpe en medio de una transacción? En aplicaciones de vibe coding, la respuesta suele ser una promesa rechazada sin gestionar que se manifiesta como una pantalla en blanco.
- Dependencia del proveedor vinculada a patrones generados por IA. Cuando la IA eligió estructurar el modelo de datos de una manera determinada, el practicante de vibe coding lo aceptó. Toda la aplicación se construye en torno a esa estructura. Migrar a otra requiere entender código que el desarrollador nunca leyó.
- Sin pruebas. Las pruebas no existen porque el practicante de vibe coding nunca las pidió y la IA no las ofreció. Cuando algo falla en producción, no hay una suite de pruebas que detecte las regresiones en la corrección.
La brecha entre la demo y la producción
Las herramientas de IA son genuinamente buenas generando código que funciona con entradas limpias, una red cooperativa y un único usuario concurrente. Esas son exactamente las condiciones de una demo. La producción es lo contrario: entradas mal formadas, conexiones interrumpidas, escrituras concurrentes y casos extremos que nunca se especificaron en el prompt.
El patrón se desarrolla de forma predecible. Una aplicación de vibe coding se lanza, tiene buena apariencia y consigue usuarios tempranos. Después llegan los problemas: un usuario con un carácter no ASCII en su nombre rompe la consulta a la base de datos, un usuario de móvil con conexión lenta provoca una condición de carrera en la gestión del estado. He visto situaciones en las que los endpoints de la API filtran datos entre cuentas de usuario porque las comprobaciones de autorización estaban ausentes o incompletas, consecuencia directa de lanzar código que nunca se revisó para la aplicación del lado del servidor. Ninguno de estos fallos es exótico. Son la consecuencia básica de lanzar código que nunca se leyó.
La IA hace mejores a los buenos ingenieros, no prescindibles a los malos
Esta es la afirmación que el relato del vibe coding invierte. Las herramientas son reales y las ganancias de productividad también lo son. En webvise, utilizo Claude Code, Cursor y orquestación multiagente en cada proyecto que entrego. Los ingenieros sénior que usan Claude Code reportan ahorros de tiempo significativos en tareas que de otro modo llevarían días. Las mismas herramientas en manos de alguien sin fundamentos de ingeniería producen una demo que no sobrevive a su primer usuario real.
El ingeniero aporta la diferencia a la herramienta. Los fundamentos de ingeniería consisten en comprender los límites del sistema, los modos de fallo, los modelos de seguridad y la integridad de los datos. Un ingeniero que usa Claude Code lee el código de autenticación generado y reconoce cuándo es incorrecto. Un desarrollador sin experiencia acepta la sugerencia y la lanza.
| Capacidad | Ingeniero + herramientas de IA | Practicante de vibe coding + herramientas de IA |
|---|---|---|
| Velocidad de prototipado | Rápida | Rápida |
| Lee el código generado | Sí: detecta errores y problemas de seguridad | No: acepta y lanza |
| Gestiona casos extremos | Los especifica proactivamente en los prompts | Los descubre en producción |
| Revisión de seguridad | Integrada en el ciclo de revisión | Ausente |
| Puede depurar fallos en producción | Sí: conoce la base de código | No: caja negra que posee pero no comprende |
| Escala más allá de la demo | Sí | Raramente |
El riesgo específico del software empresarial
Las aplicaciones de consumo pueden absorber los modos de fallo del vibe coding. Si un rastreador de finanzas personales pierde algunos datos, es molesto. Cuando un B2B SaaS que gestiona registros de clientes, flujos de pago o flujos de trabajo internos se lanza con los problemas de autenticación y gestión de errores descritos, las consecuencias son legales, contractuales y reputacionales. La responsabilidad bajo el GDPR se aplica independientemente de cómo se generó el código; el código de gestión de datos requiere revisión.
Varios productos SaaS recientes asistidos por IA han seguido un patrón similar: impresionantes en una demo, captaron clientes tempranos por la promesa, y luego chocaron contra una pared cuando el primer cliente empresarial realizó una auditoría de seguridad o el primer día de alto tráfico expuso la gestión de errores inexistente. Los fundadores no son impostores: genuinamente no sabían lo que habían construido.
Qué buscar en un socio de desarrollo aumentado por IA
Si está evaluando un socio de desarrollo que afirma utilizar herramientas de IA, formule estas preguntas:
- ¿Ejecutan pruebas automatizadas sobre el código generado por IA? Si la respuesta es "confiamos en el resultado de la IA", mejor buscar otra opción. La cobertura de pruebas es la forma de detectar la gestión de errores que la IA omitió.
- ¿Realizan revisiones de seguridad sobre el código de autenticación y autorización generado? Las herramientas de IA copian patrones de autenticación de sus datos de entrenamiento, y esos patrones incluyen vulnerabilidades reales de bases de código reales.
- ¿Pueden explicar la arquitectura de lo que construyeron? Si un desarrollador no puede explicar el modelo de datos y justificar por qué está estructurado así, es que no lo arquitectó: lo aceptó.
- ¿Versionan sus prompts junto al código? La disciplina de ingeniería aplicada a las herramientas de IA implica tratar el prompt como parte de la base de código, no como una entrada desechable.
- ¿Tienen un proceso para gestionar las alucinaciones de la IA? Las herramientas de IA generan con confianza llamadas a API incorrectas, métodos obsoletos y funciones de librería inexistentes. Un equipo experimentado tiene un ciclo de revisión para esto. Un practicante de vibe coding lo descubre en tiempo de ejecución.
El enfoque correcto: la IA como multiplicador de fuerza, no como sustituto
El relato del vibe coding es seductor porque es parcialmente cierto. Las herramientas de IA han bajado genuinamente el umbral para construir software. Una persona motivada sin formación técnica puede lanzar un prototipo funcional en un fin de semana. Eso tiene valor para la validación, para los MVPs y para herramientas internas con bajo riesgo. El error es tratar el suelo como el techo: asumir que, porque algo funciona, puede funcionar de forma fiable a escala, de forma segura y mantenible.
Los ingenieros que más han sacado partido de las herramientas de codificación con IA son quienes las usan para eliminar las partes tediosas de la ingeniería, como el boilerplate, el andamiaje y las refactorizaciones repetitivas, mientras aplican su criterio a las partes que importan: arquitectura, seguridad, gestión de errores y preparación para producción. La IA acelera el trabajo. El ingeniero garantiza que es correcto.
webvise utiliza desarrollo aumentado por IA en cada proyecto: Claude Code, Cursor, pipelines multiagente. Todo con la disciplina de ingeniería que hace que el resultado sea apto para producción. Si está construyendo software que necesita sobrevivir a usuarios reales, casos extremos reales y requisitos de seguridad reales, póngase en contacto para ver cómo funciona el proceso.
Las prácticas de webvise están alineadas con las normas ISO 27001 e ISO 42001.