Vibe coding en producción: el código que compila no es el código que estaba bien

En febrero de 2025, Andrej Karpathy publicó un tuit que le puso nombre a algo que ya estaba pasando: "vibe coding", describir una intención en lenguaje natural, aceptar lo que la IA genera y avanzar sin leer los diffs. Un año después, el mismo Karpathy escribió que el término ya estaba obsoleto para uso profesional. Su propuesta de reemplazo fue "agentic engineering": orquestar agentes con supervisión activa, no dejarse llevar por las vibes — que es, sin coincidencia, el tema de nuestro artículo anterior.

Esa retractación del propio autor del término es la mejor advertencia posible. Vibe coding nació para prototipos de fin de semana. El problema es lo que pasó después: la misma práctica que Karpathy pensó como un juego se está usando para construir software que toca datos reales, usuarios reales y, en algunos casos, información médica o financiera.

Este artículo no trata sobre si vibe coding "sirve". Sirve, y muy bien, para lo que fue diseñado. Trata sobre qué ocurre cuando una aplicación generada así cruza la línea entre demo y producción sin que nadie audite ese cruce — y sobre qué evidencia concreta existe hoy, no especulación, de lo que sale mal cuando eso pasa.

¿Por qué el código que funciona no es el código que está bien?

Porque "funciona" y "es correcto" se verifican de formas completamente distintas, y vibe coding solo optimiza la primera. Un modelo genera una función que compila, pasa la prueba manual del desarrollador y resuelve el caso feliz. Eso no dice nada sobre qué pasa cuando alguien manda un input malicioso, un endpoint recibe una URL controlada por un atacante, o una dependencia que el modelo importó nunca existió.

El riesgo real de seguridad en desarrollo asistido por IA no es solo una función vulnerable o una dependencia expuesta: es la falsa confianza que producen sistemas que parecen completos antes de haber sido probados, cuestionados y comprendidos de verdad. Ese es el núcleo del problema, y por eso el título de este artículo no habla de "riesgos" en abstracto: habla de la brecha entre compilar y estar bien.

La evidencia de 2026 confirma que esa brecha no se está cerrando con modelos mejores. Un análisis de Veracode de marzo de 2026 encontró que la tasa de aprobación en pruebas de seguridad se mantuvo plana en aproximadamente 55%, sin mejora, mientras los benchmarks de capacidad de codificación seguían subiendo en el mismo período — y los modelos más grandes no superaron a los más pequeños en seguridad. Traducido: la IA escribe código funcionalmente mejor cada mes. No escribe código más seguro.

¿Qué riesgos de seguridad aparecen con más frecuencia?

Cuatro categorías se repiten en la evidencia disponible, y ninguna es hipotética.

Fallos de control de acceso. Es la categoría número uno del propio OWASP Top 10, y vibe coding la agrava porque cada prompt puede generar una implementación ligeramente distinta del mismo control. Un estudio de Tenzai de diciembre de 2025 probó cinco agentes de codificación importantes en el mismo tipo de funcionalidad y los cinco introdujeron una vulnerabilidad SSRF — cinco de cinco, cien por ciento.

Secretos y credenciales expuestas. IBM documentó que el 64% de las credenciales expuestas en aplicaciones vibe-coded seguían activas y sin revocar a enero de 2026, con un caso —Football Australia— donde claves de AWS quedaron expuestas en el código fuente del sitio durante más de 700 días. No es un bug raro: es lo que pasa cuando nadie audita qué queda escrito en el repositorio.

Dependencias que no existen. Una nota de investigación de la Cloud Security Alliance de abril de 2026, sobre 2,23 millones de muestras de código generado por IA en 16 modelos, encontró que el 19,7% contenía al menos un nombre de paquete alucinado que no existe realmente. Esto abre la puerta al "slopsquatting": un atacante registra ese nombre de paquete inventado, y el siguiente desarrollador que genere código similar instala malware sin saberlo.

Vulnerabilidades de inyección clásicas, a mayor escala. Investigación de la Universidad de Nueva York encontró que el 45% del código generado por Copilot contenía al menos un problema del OWASP Top 10, concentrado en inyección, fallos de autenticación y errores de configuración de seguridad. Nada de esto es nuevo en la historia de la seguridad de software. Lo nuevo es la velocidad a la que se produce.

El propio OWASP ya lo reconoce como fenómeno, no como anécdota. La actualización 2025 del Top 10 señala explícitamente que las prácticas de desarrollo están cambiando hacia código escrito y confirmado casi sin supervisión humana —lo que suele llamarse vibe coding— y advierte que quien escribe código debe poder leer y entender por completo cualquier código que someta, sea de IA o no. Cuando el estándar de referencia de la industria dedica una sección a esto, es señal de que dejó de ser un debate de Twitter.

¿Qué le pasa a la arquitectura cuando nadie la diseñó, solo la generó?

Se acumula deuda técnica de un tipo distinto al habitual: no es "código feo que funciona", es decisiones de arquitectura que nadie tomó conscientemente. Un agente resuelve cada prompt de forma local y óptima para ese prompt. No tiene memoria del resto del sistema salvo lo que le pases explícitamente, así que el mismo problema de autorización puede resolverse de tres formas distintas en tres endpoints, porque cada uno se generó en una sesión distinta.

Ese patrón tiene un efecto medible en cómo se integra el código a un repositorio real. Los desarrolladores que trabajan con asistencia de IA producen más del triple de commits que sus pares sin IA, pero los agrupan en pull requests significativamente menos frecuentes y mucho más grandes. Es la combinación menos deseable posible para revisión humana: más cambios, empaquetados en bloques más difíciles de auditar uno por uno.

El resultado en producción, medido con herramientas de análisis reales, no es ambiguo. Apiiro desplegó su motor de análisis de código en decenas de miles de repositorios de empresas Fortune 50 entre diciembre de 2024 y junio de 2025: los desarrolladores con asistencia de IA confirmaban código a un ritmo de tres a cuatro veces mayor que sus pares, y los hallazgos de seguridad mensuales pasaron de aproximadamente 1.000 a más de 10.000 — una multiplicación por diez en seis meses. No es que la IA introduzca un tipo de vulnerabilidad nuevo. Es que multiplica el volumen de código sin multiplicar la capacidad de revisarlo.

¿Cómo se ve un pipeline que no deja pasar vibe coding sin filtro?

No hace falta prohibir vibe coding para gestionarlo. Hace falta que el pipeline de CI/CD asuma, por defecto, que cualquier cambio pudo haber sido generado sin que nadie lo leyera con atención — y que lo trate en consecuencia.

Un punto de partida razonable, en un flujo de GitHub Actions:

# .github/workflows/pr-gate.yml
name: Puerta de calidad para pull requests

on:
  pull_request:
    branches: [main]

jobs:
  puerta-de-calidad:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 1. Nadie mezcla secretos al repo, generados por humano o por IA.
      - name: Escaneo de secretos
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

      # 2. Si el nombre del paquete no existe, el build falla aquí,
      #    no en el servidor de producción de un atacante.
      - name: Verificación de dependencias
        run: |
          npm ci --strict-peer-deps
          npm audit --audit-level=high

      # 3. Tipado estricto como verificador barato de alucinaciones.
      - name: Chequeo de tipos
        run: npx tsc --noEmit

      # 4. Tests + cobertura mínima. Sin esto, no hay criterio de verdad.
      - name: Tests con cobertura
        run: npm run test -- --coverage --coverageThreshold='{"global":{"lines":70}}'

      # 5. SAST específico para patrones comunes de código generado por IA
      #    (auth solo en cliente, CORS permisivo, falta de rate limiting).
      - name: Análisis estático de seguridad
        uses: github/codeql-action/analyze@v3

  bloqueo-de-revision-humana:
    needs: puerta-de-calidad
    runs-on: ubuntu-latest
    steps:
      - name: Exigir al menos una aprobación humana
        run: echo "Configurado como branch protection rule, no como step: 1 review mínimo, sin auto-merge."

El detalle que importa no es la herramienta específica de cada paso —eso cambia según tu stack—, sino el orden: ningún paso de este pipeline confía en que el código "se ve bien". Cada uno verifica una afirmación concreta y falla ruidosamente si esa afirmación es falsa. Y el último paso, la aprobación humana, no es negociable ni automatizable: es la puerta que decide si algo entra a main, y por diseño no puede saltarse con un flag de configuración.

Vale la pena medir esto de forma explícita en lugar de asumir que "ya lo revisamos": cuánto tiempo se dedica a generar código frente a cuánto se dedica a releerlo, cuestionarlo y entenderlo antes de aprobarlo. Si esa proporción se inclina fuertemente hacia generación, la velocidad que ganaste escribiendo la estás perdiendo — o peor, la estás heredando en forma de incidentes — más adelante.

¿Quién es responsable del código cuando lo escribió un agente?

Legalmente y operativamente, la persona que lo aprobó y lo desplegó. Eso no cambia porque el autor material fuera un modelo. Pero en la práctica, la pregunta que causa más problemas no es "¿de quién es la culpa cuando algo falla?", sino una más aburrida y más frecuente: ¿quién mantiene esto dentro de seis meses?

Cuando la persona que generó una aplicación vibe-coded deja el equipo o cambia de rol, y no existe un proceso claro de traspaso de responsabilidad, el resultado es lo que en inglés se llama "zombie apps": aplicaciones que siguen corriendo, que nadie entiende del todo, y que se acumulan silenciosamente por la rotación natural de personal. En una clínica o una empresa mediana en Venezuela, donde los equipos técnicos suelen ser pequeños, ese riesgo no es hipotético: es exactamente el tipo de aplicación interna que alguien generó rápido para resolver un problema puntual y que dos años después nadie sabe cómo tocar.

La respuesta no es prohibir que la gente use estas herramientas para resolver problemas rápido. Es exigir, antes de que cualquier cosa generada así toque un sistema con datos reales, tres cosas que no dependen del modelo: un dueño humano identificado y documentado, un repositorio con historial real (no un export final de una sesión de chat), y una decisión explícita de que ese código pasa a mantenimiento formal, con los mismos estándares de revisión que el resto del sistema. Si nadie puede o quiere firmar esas tres condiciones, la conclusión correcta no es "lo arreglamos después". Es que esa aplicación no debería estar en producción todavía.

¿Qué debe hacer un equipo antes de llevar vibe coding a producción?

Tres decisiones, en orden de importancia.

Primero, trazar la línea entre prototipo y producción explícitamente, no dejar que ocurra sola. Un prototipo que "funciona bien en la demo" y se despliega porque nadie dijo que no, es la forma más común en que estos riesgos se materializan. La línea debe ser una decisión consciente, con una lista de verificación —seguridad, dependencias, ownership—, no una inercia.

Segundo, invertir el orden de gasto de tiempo. Si generar una función toma minutos y revisarla con criterio toma más que eso, esa proporción es correcta, no un desperdicio. La señal de alarma es la contraria: cuando el tiempo de generación supera ampliamente al de revisión, ahí es donde se acumulan los hallazgos de seguridad que después cuestan mucho más que el tiempo que se ahorró.

Tercero, tratar el pipeline de CI/CD como el verificador real, no como formalidad. Escaneo de secretos, verificación de dependencias, tipado estricto y aprobación humana obligatoria no son burocracia: son las únicas capas que catch lo que una demo exitosa no revela.

Vibe coding no es el problema. Tratar "compila y funciona" como sinónimo de "está listo para producción" sí lo es. La diferencia entre un equipo que se beneficia de esto y uno que acumula incidentes no está en qué modelo usan. Está en si construyeron el sistema de verificación antes de confiar en la velocidad.

Preguntas frecuentes

¿Qué diferencia hay entre vibe coding y desarrollo agéntico?

Vibe coding, tal como lo definió Andrej Karpathy en 2025, describe aceptar código generado por IA sin revisar los cambios línea por línea, pensado originalmente para proyectos desechables. El desarrollo agéntico —término que el propio Karpathy propuso después como reemplazo para uso profesional— implica orquestar agentes con supervisión activa: validación de salidas, presupuesto de pasos y revisión humana antes de que el cambio se integre. La distinción no es cosmética: es la diferencia entre confiar y verificar.

¿Es seguro llevar una aplicación vibe-coded a producción?

Puede serlo, pero no por defecto. La evidencia de 2026 muestra tasas de vulnerabilidad estables alrededor del 45-55% en código generado sin supervisión, y categorías de riesgo específicas —control de acceso, secretos expuestos, dependencias inexistentes— que aparecen con mucha más frecuencia que en código con revisión humana. Es seguro cuando pasa por los mismos controles de seguridad que cualquier otro código antes de tocar datos reales, no cuando "funcionó en la demo".

¿Qué controles mínimos necesita un pipeline de CI/CD para código generado por IA?

Como mínimo: escaneo de secretos antes de cada merge, verificación de que las dependencias declaradas existen realmente, tipado estricto, una suite de tests con cobertura mínima exigida, y una regla de protección de rama que impida el merge sin al menos una aprobación humana. Ninguno de estos controles es exclusivo de código generado por IA — son buenas prácticas de siempre — pero se vuelven no negociables cuando el volumen de cambios crece más rápido que la capacidad de revisarlos uno por uno.

¿Quién es responsable si una aplicación generada con IA falla en producción?

La persona o el equipo que la aprobó y la desplegó, no la herramienta. Por eso toda aplicación que pase de prototipo a producción necesita un dueño humano identificado, un repositorio con historial real de cambios, y una decisión explícita de que entra a mantenimiento formal con los mismos estándares que el resto del sistema. Sin esas tres condiciones, el riesgo no es solo técnico: es que en un año nadie sepa quién puede tocar ese código con seguridad.