La escena es tentadora: describes en lenguaje natural lo que quieres construir y la IA te devuelve código que “funciona”. Lo integras, lo despliegas, y en la demo todo luce impecable. El problema es que la demo no es producción. Y cuando confundes velocidad de adopción con evidencia de efectividad, el costo llega en forma de vulnerabilidades, deuda técnica y decisiones que nadie puede auditar.
El “Vibe Coding” (término acuñado por Andrej Karpathy en febrero de 2025, con un post de 4.5 millones de vistas) se volvió masivo porque baja la fricción: “yo pido, la IA escribe”. Pero el documento es claro: adopción no es madurez. Que el uso diario esté entre 72% y 92% y que herramientas como GitHub Copilot superen 20 millones de usuarios no prueba seguridad ni calidad. Solo prueba dependencia funcional.
En este artículo vas a llevarte tres cosas concretas:
- qué está fallando de forma documentada en seguridad y productividad,
- cómo aparece la deuda técnica (el “Spaghetti Point”),
- qué pasos prácticos puedes aplicar sin caer en “compliance theater” ni en fe ciega en SAST/DAST.
Fundamentos: qué es Vibe Coding y por qué seduce
Vibe Coding, en el documento, es simple: describes en lenguaje natural lo que quieres construir y una herramienta de IA genera el código. Esa simplicidad explica por qué se expandió tan rápido. También explica por qué es fácil que un equipo lo use sin red.
El indicador que mejor resume el fenómeno no es “usuarios” ni “ARR”, sino la tensión entre confianza y dependencia. La confianza del desarrollador en herramientas IA cae de 43% a 29% en 18 meses, pero el uso sube a 84%. Eso no suena a “amor por el producto”: suena a que la herramienta se volvió parte del flujo aunque la fe en su calidad baje.
Aquí hay un error mental típico: “si compila, está bien”. El documento insiste en lo contrario: los modelos han mejorado en generar código que compila, pero no han mejorado de forma significativa en generar código seguro. Eso cambia completamente cómo deberías evaluar el resultado.
Seguridad: el gap entre “funciona” y “es seguro” es real
El documento reúne evidencias en una dirección consistente: el código generado por IA presenta problemas de seguridad significativos, con tasas reportadas entre 15% y 45% de vulnerabilidades según diferentes documentos. Pero también advierte algo clave: no puedes citar una sola cifra como “la tasa real” sin contexto metodológico, porque no miden lo mismo.
Un ejemplo fuerte: Veracode probó más de 100 Modelos de Lenguaje Grande (LLM) en 80 tareas y encontró que 45% del código generado contenía vulnerabilidades del OWASP Top-10. En Java, la tasa de fallo llegó a 70%. Además, reporta fallos altos en Cross-Site Scripting (XSS) (86%) y log injection (88%).
Y aquí viene el golpe a la narrativa “los modelos se arreglan solos con el tiempo”: el documento afirma que dos años de mejoras no han reducido la tasa de vulnerabilidades de forma significativa. Mejoran para generar código que compila; no para generar código seguro.
Incluso cuando intentas “entrenar” el resultado con prompts de seguridad, el documento marca límites: Claude Opus 4.5 solo genera código seguro el 56.1% del tiempo sin prompting específico de seguridad, y técnicas como prompting enfocado, auto-identificación de Common Weakness Enumeration (CWE) o pistas directas no cierran confiablemente la brecha entre “funcional” y “seguro”.
El sesgo que te rompe cualquier métrica: Dunning-Kruger asistido
Stanford documenta el efecto “Dunning-Kruger asistido”: desarrolladores usando asistentes de IA escriben código menos seguro pero están más convencidos de que es seguro. Si tu organización mide calidad por autopercepción (“me siento más rápido”, “me parece seguro”), estás midiendo el sesgo, no el resultado.
Cloud Security Alliance reporta que 62% del código IA presenta fallas de seguridad y que 69% de organizaciones han descubierto vulnerabilidades introducidas por código generado por IA. Ojo: el documento también advierte que estas cifras no son comparables entre sí sin metodología, pero sí refuerzan la dirección del problema.
De riesgos “teóricos” a CVEs: cuando el ecosistema se vuelve superficie de ataque
La discusión deja de ser filosófica cuando aparecen CVEs. El documento menciona que en enero de 2026 se registraron tres Vulnerabilidades y Exposiciones Comunes (CVE) que afectan herramientas centrales del ecosistema:
- CVE-2025-54135: ejecución de comandos vía Model Context Protocol (MCP) de Cursor.
- CVE-2025-53109: servidor MCP de Anthropic permitía lectura/escritura sin restricción.
- CVE-2025-55284: exfiltración vía DNS en Claude Code.
Esto no significa “todo es inseguro”. Significa algo más útil: la superficie de ataque existe y está catalogada. Si tu estrategia de seguridad para IA era “ya veremos”, aquí tienes la razón para no improvisar.
Productividad: percepción contra realidad (y por qué importa)
El documento cita un único estudio experimental con metodología de ensayo controlado aleatorizado: METR, con 16 desarrolladores. Resultado: quienes usaron IA creían ser 20% más rápidos, pero en realidad fueron 19% más lentos.
El propio documento pone el freno metodológico: con 16 participantes no puedes extrapolar a toda la industria. Pero sí puedes quedarte con algo accionable: la percepción del desarrollador es poco confiable como métrica cuando hay asistentes de IA de por medio.
Si tu empresa está justificando la adopción con “sensación de velocidad” o con métricas autoinformadas, te estás construyendo una narrativa, no un caso. Y las narrativas no pagan incidentes.
Deuda técnica: el “Spaghetti Point” y el mes tres maldito
El documento describe un patrón recurrente: el Spaghetti Point. Alrededor del mes tres, agregar funcionalidades rompe las existentes y la velocidad cae cerca de cero. La razón práctica: el código generado rápido tiende a crecer sin estructura consistente si no hay diseño, revisión y pruebas.
Hay un dato adicional con sabor a “métrica dura”: Google DevOps Research and Assessment (DORA) encontró que un incremento de 25% en uso de IA genera una disminución de 7.2% en estabilidad de entregas.
Forrester predice que 75% de decisores tecnológicos enfrentarán deuda técnica moderada a severa para 2026. Y la cifra de 1.5 billones de dólares en deuda técnica para 2027 aparece como estimación, no hecho. El documento te pide no venderla como certeza.
Aquí aparece un incentivo perverso: 54% de líderes de ingeniería planean contratar menos junior por eficiencias de IA, mientras la deuda técnica por código IA requiere juicio humano para resolverse. Cortas cantera y subes complejidad: el costo llega después, pero llega.
Implementación práctica: cómo usar IA sin jugar a la ruleta
Si te quedas solo con “no uses Vibe Coding”, pierdes. El documento no pide prohibición; pide gobernanza y verificación real.
Paso 1: vuelve “objetivo” lo que hoy es intuición
Define métricas que no dependan de autopercepción: estabilidad de entregas, defectos en producción, tiempo real de ciclo, vulnerabilidades confirmadas, retrabajo. El documento es explícito: la percepción del desarrollador contamina métricas.
Paso 2: exige cimientos antes de marcos
Los marcos normativos son referencia útil solo si ya tienes base: Integración Continua y Despliegue Continuo (CI/CD), revisión de código y pruebas automatizadas. Sin eso, el marco se vuelve burocracia vacía.
Paso 3: usa marcos con reservas (y sin vender humo)
El documento menciona ISO/IEC 42001:2023 (Sistema de Gestión de IA, AIMS) y NIST AI Risk Management Framework (RMF) con cuatro funciones: Gobernar, Mapear, Medir y Gestionar. También menciona el Reglamento (UE) 2024/1689 (EU AI Act), aplicable desde el 2 de agosto de 2026 para sistemas de alto riesgo con sanciones de hasta 35 millones de euros o 7% de facturación mundial.
Pero ojo con el matiz: usar un agente para programar no convierte automáticamente tu producto en sistema de IA de alto riesgo. El documento dice que afirmar aplicabilidad “directa” sin matices simplifica un marco legal complejo.
Paso 4: no asumas que SAST/DAST “ya cubren”
SAST (Análisis Estático de Seguridad de Aplicaciones) y DAST (Análisis Dinámico de Seguridad de Aplicaciones) integrados en CI/CD se presentan como mitigación, pero el documento recalca que no fueron validados específicamente contra patrones de vulnerabilidad de código generado por IA. Su efectividad aquí es asumida, no demostrada.
Paso 5: si documentas prompts, que no sea teatro
Registrar prompts por “trazabilidad” sirve solo si hay un proceso que haga algo con esos registros. Si nadie revisa, es simulacro. El documento llama a esto “compliance theater”.
Errores comunes que te van a pasar si no los nombras
Error 1: confundir adopción con maduración.
72–92% de uso mide uso, no competencia. Y la confianza cae mientras el uso sube: eso es dependencia funcional.
Error 2: creer que multi-agentes arregla calidad por sí solo.
El documento menciona propuestas de arquitectura multi-agente (Arquitecto, Programador, Auditor, Seguridad), pero afirma que no hay evidencia de que “agentes auditando agentes” reduzcan vulnerabilidades documentadas.
Error 3: adoptar taxonomías sin operación.
El marco Intención–Restricciones–Verificación (I-R-V) es razonable como estructura conceptual, pero el documento dice que no tiene validación empírica en organizaciones reales. Si no defines qué significa “verificación” y cómo se mide, es nomenclatura sin sustancia.
Conclusión: no se trata de correr más, sino de chocar menos
El mensaje central del documento es incómodo pero útil: el Vibe Coding no es una revolución madura; es dependencia funcional con riesgos documentados, gobernanza improvisada y métricas que confunden adopción con resultado.
Tres ideas para cerrar y llevarte a acción:
- mide resultados reales (no autopercepción), porque el sesgo está documentado,
- construye cimientos (CI/CD, revisión, pruebas) antes de marcos,
- no asumas cobertura: valida seguridad y calidad específicamente para tu uso de IA.
Si tu plan era “adoptar más rápido”, cámbialo por “gobernar mejor”. Ahí está la diferencia entre experimentar y operar.
Si esto te ayudó, considera apoyar el canal en
ko-fi.com/luisospina21292
O si necesitas ayuda específica con ciberseguridad para tu empresa,
ofrezco consultas express de 30 minutos.
info@vvc-consultor.com
#Ciberseguridad #DevSecOps #VibeCoding #AIcoding #TechDebt #SeguridadAplicaciones #CIcd #vvcconsultor