Vibe Coding en Producción: Lo que funciona y lo que No

El CEO llega a la reunion con un artículo de Forbes bajo el brazo: "¿Por qué no estamos usando IA para escribir código?" El CTO conoce la respuesta real, pero no siempre puede decirla en voz alta.

En Initium llevamos más de 2 años usando IA en código de producción real — no en demos, no en hackathons, no en proyectos de laboratorio. Este artículo no es una guía de herramientas. Es el informe post-mortem que nos hubiera gustado leer antes de empezar. Incluye los errores que cometimos, las métricas que obtuvimos y el sistema que construimos para que vibe coding en producción no sea una apuesta al azar.

Qué es vibe coding y por qué tu CEO lo va a mencionar en la próxima reunión

El término lo acuñó Andrej Karpathy en febrero de 2025: desarrollar guiado por lenguaje natural, dejando que el modelo genere el código mientras el programador itera por conversación hasta que el resultado "se siente bien". La propia definición lleva incorporada la trampa. Karpathy situó explícitamente el vibe coding en proyectos de fin de semana descartables. No en sistemas que procesan pagos a las 3 de la mañana.

El problema no es que la IA genere código. El problema es la velocidad con la que esa capacidad llega a los C-levels sin el contexto técnico que la acompaña. Hoy, el 41% del código global tiene participación de herramientas de IA, y el 92% de los desarrolladores en EEUU usará asistentes IA diariamente en 2026 según datos de GitHub Octoverse 2026, recogidos por Hostinger. Esas cifras no distinguen entre un prototipo y un sistema de integración bancaria. Tu CEO tampoco.

No somos anti-IA. Somos anti-ingenuidad. Y la distinción importa porque la presión sobre el CTO es real: si dices que no al vibe coding sin un argumento estructurado, el framing que queda es que tu equipo es lento. Si dices que sí sin un sistema detrás, el riesgo lo absorbes tú.

Los tres errores que cometimos en los primeros seis meses

No aprendimos esto leyendo papers sobre vibe coding, lo aprendimos trabajando en proyectos reales.

Error 1: Código que pasaba los tests pero rompía la lógica de negocio

La IA genera código sintácticamente correcto con una eficiencia que desactiva el instinto de revisión. El primer fallo grave que sufrimos fue en un módulo de cálculo dentro de un sistema financiero: la lógica generada respetaba los tipos de datos, pasaba todos los tests unitarios y compilaba sin warnings. El error era semántico — una invariante de dominio que ningún test capturaba porque nadie la había especificado de forma ejecutable.

Lo detectamos tres semanas después, en una auditoría manual. En un sistema con 500.000 transacciones diarias, tres semanas de error silencioso no es un incidente menor. Es un problema de auditoría regulatoria. La raíz del fallo no estaba en el modelo de IA. Estaba en que habíamos pedido código sin haber escrito primero qué debía garantizar ese código.

Error 2: Deuda técnica invisible acumulada en sprints rápidos

Cuando un desarrollador escribe 400 líneas en 3 minutos, el code review deja de ser posible en los términos habituales. Nadie puede revisar con criterio real algo que el modelo ha generado más rápido de lo que se puede leer. Lo que ocurre en la práctica es que el review se convierte en una validación superficial: ¿compila? ¿los tests pasan? Aprobado.

Medimos la diferencia entre sprints con generación libre y sprints con revisión estructurada: el ratio de bugs introducidos en el primer grupo fue 2,3 veces mayor. La velocidad de generación no crea deuda técnica por sí sola. La crea cuando no va acompañada de un proceso de revisión que pueda seguirle el ritmo. Son dos velocidades distintas y si no las sincronizas, la segunda siempre pierde.

Error 3: Pérdida de propiedad intelectual del código crítico

Este es el error que menos se menciona en los artículos de adopción de IA y el que más daño hace a largo plazo. Cuando un equipo no entiende el código que ha "producido", el conocimiento sobre ese código vive en el modelo, no en el equipo. A efectos prácticos: si el desarrollador que gestionó la sesión de generación sale de la empresa, nadie sabe por qué ese módulo hace lo que hace.

Eso tiene consecuencias directas en tres frentes: escalabilidad (nadie puede extenderlo con confianza), auditoría (no puedes explicar una decisión de diseño que tomó un LLM) y continuidad (el coste de mantenimiento escala de forma no lineal). En sectores regulados como el financiero o el asegurador, la pregunta "¿quién puede explicar por qué este código hace esto?" tiene que tener una respuesta humana, no un prompt de Copilot.

Lo que sí funciona: el sistema que construimos después

Estos tres errores nos llevaron a diseñar un sistema. No es revolucionario. Es ordenado. Y la diferencia entre tenerlo y no tenerlo es medible.

Specs ejecutables antes de la primera línea de código generado

Una spec ejecutable es un documento estructurado que define, antes de cualquier generación, qué debe garantizar el código: entradas válidas, salidas esperadas, invariantes de dominio, casos límite y condiciones de error. No es un comentario en el ticket de Jira. Es un artefacto que el equipo puede usar para auditar el output del modelo.

El enfoque de Spec-Driven Development — consolidado como respuesta directa a los fallos del vibe coding — formaliza exactamente esto. Cuando el equipo escribe la spec antes de lanzar el primer prompt, dos cosas ocurren: el desarrollador tiene que pensar en el problema antes de delegarlo, y el output del modelo tiene un contrato contra el que verificarse. La ambigüedad no ralentiza solo el desarrollo — en IA, la ambigüedad activa genera riesgo. Aplicar esta disciplina es lo que diferencia vibe coding en produccion sostenible del que acumula deuda silenciosa.

Contract testing como red de seguridad no negociable

El contract testing verifica que los contratos entre servicios se cumplen independientemente de cómo se haya generado el código que los implementa. Herramientas como Pact/PactFlow o Specmatic permiten integrar esta verificación directamente en el pipeline de CI/CD. Con código generado por IA, esta capa no es opcional: es el mecanismo que detecta los errores silenciosos que los tests unitarios no ven.

Después de integrar contract testing sistemático en proyectos con generación IA, redujimos los errores silenciosos en integración en más de un 60%. No porque la IA generara mejor código — sino porque el pipeline dejó de aceptar código que violaba los contratos definidos, independientemente de lo limpio que pareciera el output.

Revisión humana de la lógica crítica: donde el humano no puede delegar

No todo el código tiene la misma criticidad. La clasificación que usamos es directa: lógica de negocio que afecta a transacciones económicas, módulos de seguridad y autenticación, e integraciones con sistemas financieros o regulados — estos tres bloques no se aprueban sin revisión humana real, no superficial.

El CTO no puede delegar la función de guardián del contrato de calidad en el modelo que generó el código. La herramienta de generación no tiene contexto regulatorio, no conoce los acuerdos de nivel de servicio y no asume responsabilidad cuando algo falla. El equipo humano, sí. La revisión crítica no es un paso que ralentiza el proceso — es el paso que hace que el proceso sea sostenible.

Cuánto cuesta no tener este sistema — y cuánto cuesta tenerlo

Los datos de mercado de 2026 son directos: el 45% del código generado por IA contiene vulnerabilidades de seguridad según el análisis de Veracode, y el 92% de los codebases con participación significativa de IA contienen al menos una vulnerabilidad crítica según el informe de Sherlock Forensics 2026. Los incidentes de produccion por pull request aumentaron un 23,5% entre diciembre de 2025 y el primer trimestre de 2026.

El coste de un bug silencioso en un sistema financiero no es solo técnico. Incluye tiempo de investigación forense, coste de comunicación a regulador, posible impacto en auditoría y coste reputacional con el cliente final. Ninguno de esos costes aparece en el sprint velocity cuando el equipo celebra que "están entregando el doble con IA".

El coste de implementar el sistema que describimos — specs ejecutables, contract testing en pipeline, revisión estructurada de código crítico — se recupera en el primer incidente que no ocurre. No es una estimación conservadora. Es lo que hemos medido en nuestros propios proyectos.

La pregunta clave sobre vibe coding en produccion antes de decir que sí

Una sola pregunta. No hace falta un framework de evaluación de 40 criterios. Solo esta: "Si este código falla en produccion a las 2 de la mañana, ¿quién sabe exactamente qué hace y por qué?"

Si la respuesta no es inmediata, el problema no es la herramienta de IA que estás usando. Es que tienes un déficit de arquitectura: no hay spec que defina el comportamiento esperado, no hay contrato verificable entre servicios y no hay un humano con propiedad real sobre esa lógica. La IA no crea ese problema. Lo amplifica.

El 48% de los desarrolladores no revisa siempre el código generado antes de hacer commit, según datos de Keyhole Software 2026. Si ese porcentaje vive en tu pipeline sin salvaguardas estructurales, el vibe coding en produccion no es una estrategia de aceleración — es una deuda que todavía no ha vencido.

Cómo trabaja Initium — sin dogma, con sistema

En Initium usamos IA en generación de código desde hace mas de 2 años. No en todos los proyectos de la misma manera, y no sin el sistema que describimos arriba.

El flujo que hemos estandarizado: spec ejecutable antes del primer prompt, contract testing integrado en el pipeline de CI/CD y revisión humana obligatoria en los módulos de lógica de negocio crítica.

No vendemos un enfoque anti-IA. Hacemos código que funciona en produccion. La diferencia entre los dos es exactamente el sistema que este artículo describe.

Si estás evaluando cómo introducir generación con IA en tu stack sin perder el control sobre la calidad y la propiedad del código crítico, podemos tener una conversación técnica de 20-30 minutos entre equipos. Sin presentación comercial, con el whiteboard y los casos reales sobre la mesa. Reserva aquí la reunión de descubrimiento.