Vibe coding en producción: los 5 errores que ocurren cuando no hay un senior en el equipo

Lo veo todas las semanas en proyectos. Un equipo sube código generado por IA a producción, las funcionalidades salen rápido, los bugs llegan despacio. Hasta que un día un secreto de API aparece en un repositorio público, un endpoint crítico no tiene autenticación, o una migración destruye la base de datos en staging. El vibe coding (programar "a la intuición" dejando que la IA genere el código) produjo 74 CVEs confirmadas entre enero y marzo de 2026, según el proyecto Vibe Security Radar de Georgia Tech. El problema no es la IA. El problema es que no hay nadie que verifique lo que produce.

Error 1: el código IA va a producción sin auditoría de seguridad

El primer reflejo del vibe coding es la velocidad. La IA genera una funcionalidad en diez minutos, el desarrollador la prueba visualmente, funciona, la sube. El problema: lo que funciona visualmente puede estar lleno de vulnerabilidades que nadie lee.

Según Veracode, el 45 % del código generado por IA contiene al menos una vulnerabilidad explotable. CodeRabbit mide un factor 2,74x en los problemas de seguridad del código asistido por IA frente al código escrito manualmente. El informe METR 2025 confirma que los desarrolladores asistidos por IA introducen más bugs de los que corrigen en cuanto la complejidad supera el boilerplate.

¿Cuáles son los riesgos concretos del vibe coding en producción?

El proyecto Vibe Security Radar de Georgia Tech rastreó cada CVE hasta el commit de origen para determinar si una herramienta de coding IA había introducido la vulnerabilidad. Resultado: 6 CVEs en enero de 2026, 15 en febrero, 35 en marzo. Es decir, 74 vulnerabilidades confirmadas en tres meses, según el blog de Pradeo. Los investigadores estiman que la cifra real es entre 5 y 10 veces superior, ya que la mayoría de los commits IA no llevan una firma identificable.

Las vulnerabilidades no son exóticas. Son los clásicos del Top 10 de OWASP: inyecciones SQL, XSS, secretos hardcodeados, criptografía débil, autenticación insuficiente. Un dev senior los detecta con solo leer el código. Sin esa lectura, llegan a producción a la velocidad de la IA.

He participado en proyectos donde la primera auditoría de seguridad tras tres meses de vibe coding reveló más de 40 vulnerabilidades críticas en un solo proyecto Next.js. El coste de la corrección superó el coste del desarrollo inicial. Es el patrón clásico: la velocidad inicial se paga en deuda de seguridad.

Error 2: la arquitectura se desvía sin que nadie la controle

La IA nunca dice "atención, esta decisión arquitectónica es incoherente con lo que hice ayer". Resuelve el problema del prompt, no el problema del proyecto. Spencer Keglovitz, CTO fraccional con 25 años de experiencia, lo resume bien en su análisis: "la IA no avisa cuando produce una arquitectura inconsistente. Avanza. Eres tú quien debe vigilar el structural drift."

¿Por qué la IA no puede decidir la arquitectura en tu lugar?

Un LLM es un reconocedor de patrones. Reproduce lo que ha visto en sus datos de entrenamiento. Cuando le pides que diseñe un sistema, produce algo que parece un diseño. Incluso lo defiende. Pero no ha sopesado los trade-offs como lo haría un ingeniero con contexto de negocio.

En un proyecto reciente, retomé un desarrollo donde la IA había migrado silenciosamente de un esquema REST a llamadas RPC personalizadas a mitad del desarrollo. Nadie se había dado cuenta porque cada prompt producía código que funcionaba. Solo cuando un nuevo desarrollador se incorporó al equipo descubrimos dos patrones incompatibles en la misma codebase.

El desarrollador aumentado no es quien deja que la IA decida el stack. Es quien fija la arquitectura de antemano (ARCHITECTURE.md, CONVENTIONS.md, DECISIONS.md) y verifica que cada commit IA respete esas decisiones. La IA ejecuta rápido. El senior garantiza que ejecute en la dirección correcta.

Error 3: los datos sensibles quedan expuestos

Red Access analizó más de 380.000 activos web en plataformas de vibe coding (Lovable, Replit, Base44) e identificó 5.000 aplicaciones construidas con fines empresariales. Entre ellas, el 40 % contenía datos sensibles desplegados sin controles de seguridad básicos, según el informe publicado en junio de 2026 y recogido por LeMagIT.

Ya no es shadow IT. Es shadow development. Empleados construyen apps completas, las conectan a sistemas de producción y las despliegan públicamente mientras el departamento de sistemas ni siquiera sabe que existen. 2.000 de esas 5.000 aplicaciones no tenían autenticación, ni control de acceso, ni pista de auditoría.

¿Cómo terminan las apps de vibe coding con accesos de administrador abiertos?

El caso documentado por Red Access incluye un panel financiero en tiempo real de un banco de América Latina, accesible para cualquiera que tuviera la URL. La IA genera código que funciona, pero no configura la seguridad por defecto. Las cabeceras HTTP, la protección CSRF, el rate limiting, el cifrado de secretos: nada de esto aparece "gratis" en el código generado.

Un senior sabe que cada endpoint expuesto debe estar autenticado. Sabe que las claves API no van en el código fuente. Sabe que un .env.example nunca contiene valores reales. No es gatekeeping, es disciplina básica, la que separa un prototipo de un servicio en producción. Cuando contratas a un dev senior a 180 €/día para esta revisión, estás comprando exactamente ese filtro.

Error 4: nadie distingue "funciona" de "está listo para producción"

Un código que pasa las pruebas visuales en local no es un código listo para producción. La producción implica monitoreo, logs estructurados, backups, gestión de errores, migraciones reversibles, health checks y graceful shutdown. La IA no implementa ninguno de estos elementos de forma espontánea. Los añade si se los pides, pero primero hay que saber qué pedir.

El vibe coding crea una ilusión de velocidad. Amazon generalizó la asistencia IA en sus equipos de ingeniería y en 90 días registró 471 incidentes de producción, incluyendo una interrupción de 6 horas que afectó a 6,3 millones de pedidos, según Spencer Keglovitz. Amazon cuenta con miles de ingenieros para vigilar esos sistemas. Una startup con tres desarrolladores junior no tiene esa red de seguridad.

¿Cómo revisa un dev senior el código IA?

El senior comprueba primero la coherencia arquitectónica (¿sigue este código las convenciones del proyecto?). Busca los patrones de seguridad ausentes (validación de entrada, sanitización, autenticación). Prueba los casos límite que la IA no imaginó (timeout de red, base de datos no disponible, payload malformado).

Para gestionar esta revisión en remoto, basta con un ritual de 30 minutos al día. El senior lee los PRs por la mañana, comenta los puntos bloqueantes y valida los merges. No es un cuello de botella, es un punto de control.

Mi enfoque: cada bloque entregado por el agente IA pasa por un ciclo de lectura, prueba en navegador y validación manual. El agente lee el contexto (CLAUDE.md, ARCHITECTURE.md), ejecuta, prueba y documenta. Luego el senior valida.

Error 5: el junior armado con IA acumula deuda técnica sin saberlo

Stanford registra una caída del 20 % en la contratación de desarrolladores junior entre 2024 y 2026. Las empresas creen que la IA cubre ese hueco. La realidad: un junior que usa la IA sin un senior en el equipo no produce código de senior. Produce código de LLM que nadie vuelve a leer.

La distancia entre "saber usar la IA" y "saber verificar lo que produce" es una brecha de experiencia, no de inteligencia. La confianza de los devs experimentados en el código IA pasó del 40 % al 29 % en un año, según la encuesta citada por Spencer Keglovitz. Los seniors dudan porque saben qué es lo que falla.

¿Un junior armado con IA sin un senior es realmente un riesgo?

Un desarrollador que no comprende las race conditions, el control de acceso o la gestión de sesiones no detectará cuándo la IA se equivoca en esos temas. La IA entrega código vulnerable con la misma confianza que el código correcto. No hay señal de alerta, no hay cambio de tono, no hay advertencia.

El mercado está reestructurándose en torno a esta realidad. Los juniors intercambiables pierden terreno. Los seniors que orquestan la IA, establecen las salvaguardas y garantizan la calidad del entregable ven crecer su valor. Por eso todos los perfiles de Extra Dev tienen un mínimo de 8 años de experiencia: un agente IA en manos de un senior con contexto de negocio entrega rápido y limpio. El mismo agente en manos de un junior solo produce código que pasa los tests unitarios y explota en producción.

"El senior no está para frenar. Está para que el código aguante."

Vincent Roye, junio de 2026

El vibe coding no es un callejón sin salida. Es una herramienta poderosa cuando el coste del fallo es bajo y alguien comprende el resultado. Para un prototipo interno, un script de automatización o una herramienta de uso único, es extraordinariamente eficaz. Para producción de cliente, con datos sensibles, usuarios reales y obligación de disponibilidad, el filtro de un dev senior con al menos 8 años de experiencia no es opcional. Es la única barrera entre un código que funciona y un código que resiste.