Vibe coding sin control: lo que se ahorra en horas se paga en meses

1Creían ir más rápido

A comienzos de 2025, la organización de investigación METR hizo un experimento poco común: tomó a 16 desarrolladores experimentados, les asignó tareas reales en repositorios de código abierto que conocían bien y sorteó en cuáles podían usar herramientas de IA y en cuáles no. Antes de empezar, los desarrolladores estimaron que la IA los haría un 24 % más rápidos. Al terminar, creían que lo había hecho: calcularon que habían ganado un 20 % de velocidad. El cronómetro dijo otra cosa. Con IA, las tareas tomaron un 19 % más de tiempo.¹

El resultado no se puede generalizar, y la propia METR publicó en 2026 datos preliminares que sugieren que las herramientas más nuevas sí aceleran el trabajo, aunque con limitaciones metodológicas importantes.² Pero el experimento dejó al descubierto algo que va más allá de la velocidad: la distancia entre lo que sentimos que la IA hace por nosotros y lo que efectivamente hace. Esa distancia es el terreno donde prospera el vibe coding.

No es el único dato en esa dirección. En 2023, investigadores de Stanford encontraron que quienes programaban con un asistente de IA escribían código menos seguro que quienes no lo usaban y, al mismo tiempo, estaban más convencidos de que su código era seguro.³ Y en la encuesta 2025 de Stack Overflow, con más de 49.000 desarrolladores, el 84 % dice usar o planear usar IA, pero solo el 33 % confía en la exactitud de lo que produce; dos de cada tres señalan como su mayor frustración las respuestas «casi correctas».⁴

El término lo acuñó Andrej Karpathy en febrero de 2025 para describir una forma de programar en la que uno describe lo que quiere, deja que la IA escriba el código, lo prueba y pide ajustes, sin necesariamente leer lo que se generó.⁵ Lo que antes tomaba semanas hoy puede convertirse en un prototipo funcional en una tarde. Es un avance extraordinario, y sería un error minimizarlo. Pero viene con una ilusión peligrosa: creer que producir software que funciona equivale a construir una solución robusta.

Una aplicación puede funcionar perfecto en una demostración y, al mismo tiempo, tener una arquitectura que no soporta crecer, dependencias difíciles de mantener, vulnerabilidades que nadie ve, cero manejo de errores, problemas de concurrencia o de integridad de datos, y ningún mecanismo para recuperarse cuando algo falla. Nada de eso aparece en la primera ejecución. Por eso el riesgo no es que la IA escriba código malo; los humanos también lo hacen. El riesgo es que la facilidad para obtener resultados visibles reemplace la disciplina para validar los invisibles.

2Lo que revela la evidencia sobre el código generado por IA

La preocupación no es solo teórica. En marzo de 2026, Veracode publicó su evaluación más reciente del código que generan los modelos de lenguaje: 80 tareas de programación en cuatro lenguajes, diseñadas para tentar a los modelos con vulnerabilidades conocidas. Más del 95 % del código generado era sintácticamente correcto. Solo el 55 % era seguro. En las tareas expuestas a ataques de tipo cross-site scripting, apenas el 15 % de las respuestas lo era; en Java, el 29 %. Ni siquiera los modelos más avanzados, con razonamiento extendido, superaron el 72 %.⁶ Es decir, el problema no se resuelve solo esperando el próximo modelo. Tampoco es nuevo: en 2021, un estudio de la Universidad de Nueva York encontró que cerca del 40 % de los programas que generaba GitHub Copilot en escenarios de riesgo tenían vulnerabilidades.⁷

La mantenibilidad muestra una tendencia parecida. GitClear analizó 623 millones de cambios de código entre 2023 y 2026. La duplicación de bloques de código creció 81 % desde 2023, y la proporción de código refactorizado (reorganizado para reutilizarlo en vez de copiarlo) cayó de 21 % de las líneas modificadas en 2022 a menos de 4 % en 2026. Hoy los desarrolladores copian cinco veces más de lo que refactorizan.⁸ GitClear es cuidadoso en no atribuirle toda la causa a la IA, pero la dirección coincide con lo que cualquier equipo de ingeniería observa: se escribe más código, y se ordena menos.

Google llega a una conclusión parecida desde otro ángulo. Su informe DORA 2024, el estudio de referencia sobre el desempeño de los equipos de ingeniería, encontró que en los equipos que adoptaron IA la velocidad de entrega bajó 1,5 % y la estabilidad de lo entregado, 7,2 %.⁹ Escribir código más rápido no se tradujo en entregar mejor software.

Ninguno de estos estudios mide el universo completo del software construido con IA, y sus cifras no deben leerse así. Lo que muestran, juntos, es un principio: la velocidad percibida no es productividad efectiva, y el código que compila no es código seguro ni mantenible.

3El costo no desaparece. Se desplaza.

La productividad del desarrollo asistido por IA se suele medir con el tiempo para tener un prototipo o la cantidad de funcionalidades entregadas. Son métricas legítimas, pero miran solo la primera línea de la cuenta. El costo de un sistema incluye también validarlo, operarlo, mantenerlo, protegerlo y, a veces, reconstruirlo. La IA reduce drásticamente la primera partida. Si al mismo tiempo se reducen la revisión y la comprensión, las demás crecen. El costo se mueve hacia adelante, justo donde corregir es más caro.

Un caso ilustrativo lo hace visible. Los números son supuestos redondeados, no la medición de una empresa real.

El área comercial de una empresa necesita una aplicación que consolide información de ventas de varias fuentes y sugiera a qué clientes contactar. Hay tres caminos.

Camino A: desarrollo tradicional. Un equipo pequeño la construye en seis semanas, con arquitectura, pruebas y revisión de seguridad. Desarrollo y validación cuestan USD 110.000, y operarla y mantenerla durante dos años, otros USD 80.000.

Camino B: vibe coding sin control. Una persona del área la construye en tres días con IA, por USD 20.000. Funciona tan bien que en pocas semanas la usa toda la fuerza de ventas y empieza a cargar datos de clientes. En el sexto mes, una revisión de seguridad encuentra credenciales expuestas y datos de distintos clientes sin separar: corregirlo cuesta USD 35.000. En el décimo mes, cuando ya la usan 200 personas, hay que reconstruirla para que soporte usuarios simultáneos y cambios en las fuentes: USD 110.000. Y como nadie conoce bien su lógica, operarla y mantenerla cuesta USD 125.000 en dos años, casi el doble que en el camino A.

Camino C: vibe coding con controles desde el inicio. La misma persona la construye con IA en una semana, pero con un ingeniero que define desde el comienzo los controles mínimos: dónde viven las credenciales, cómo se separan los datos, qué pruebas automáticas corren y quién responde si falla. Cuesta USD 45.000 al inicio, más USD 40.000 en el sexto mes para prepararla antes de abrirla a toda el área, y USD 80.000 de operación y mantenimiento.

El camino B es el más barato durante los primeros nueve meses, y es el que cualquier comité aprobaría mirando solo el presupuesto inicial. A los dos años es el más caro, por lejos. El camino C, en cambio, captura casi toda la velocidad de la IA y termina siendo el más barato de los tres. Además, B y C empiezan a entregar valor desde la primera semana, mientras A tarda un mes y medio.

La conclusión no es que el vibe coding sea caro. Es que el vibe coding sin control es caro, y el problema se esconde justamente en el período en que todos están celebrando lo rápido que salió.

4La deuda de comprensión

Hay un costo menos visible que las vulnerabilidades o la reconstrucción: la pérdida de comprensión del sistema.

Escribir código a mano nunca garantizó entenderlo, pero obligaba a tomar decisiones explícitas: cómo estructurar los componentes, qué hacer con los errores, cómo se comunican los servicios. Con el vibe coding, muchas de esas decisiones las toma el modelo y quedan implícitas. El resultado son sistemas que funcionan, pero cuya lógica interna nadie del equipo ha revisado de verdad.

Lo he visto de cerca en proyectos de agentes de IA para minería, en sistemas de procesamiento de imágenes y en aplicaciones del área comercial. El prototipo aparece rapidísimo y funciona en la demostración. Meses después, una parte deja de funcionar, o empieza a fallar sin aviso, y nadie del equipo puede explicar por qué. Tampoco nadie sabe bien qué riesgos traen sus integraciones con los sistemas de la operación. No es un problema del modelo ni de las personas: es que las decisiones que tomó el modelo nunca las tomó, ni las documentó, nadie del equipo.

Addy Osmani, ingeniero de Google, le puso nombre en abril de 2026: deuda de comprensión, la brecha entre cuánto código existe en un sistema y cuánto de ese código entiende realmente alguien.¹⁰ Es distinta de la deuda técnica. La deuda técnica, la metáfora que Ward Cunningham propuso en 1992, describe decisiones de implementación que encarecen los cambios futuros.¹¹ La deuda de comprensión aparece cuando el conocimiento para explicar, modificar, validar o reconstruir un sistema simplemente no está en el equipo que lo opera. Una aplicación puede tener una arquitectura razonable y una deuda de comprensión enorme, si nadie conoce sus supuestos, sus dependencias ni sus límites. El fenómeno tiene además respaldo experimental: en 2025, el MIT Media Lab encontró que quienes escribían con ayuda de ChatGPT recordaban menos de lo que habían producido y mostraban menor conectividad cerebral que quienes escribían sin ayuda, un efecto que sus autores llamaron deuda cognitiva.¹²

Lo que me interesa agregar es su dimensión económica. La deuda de comprensión no es un problema de los ingenieros: es un costo diferido que no aparece en ningún presupuesto y que se cobra en el peor momento, cuando algo falla y nadie sabe por qué, cuando un cambio en una fuente rompe todo, o cuando hay que demostrarle a un regulador cómo el sistema toma sus decisiones. En el camino B del caso, buena parte de los USD 125.000 de operación es exactamente eso: pagar, una y otra vez, por no entender lo que se construyó.

La pregunta deja de ser técnica: ¿quién entiende realmente las decisiones que llevaron a construir la solución de esa manera?

La respuesta no pasa por revisar a mano cada línea; eso eliminaría buena parte de la ganancia. En Expert Validation Loop propuse que la supervisión humana no se limite a aprobar lo que la IA entrega, sino a validar el razonamiento, los supuestos y el método antes de que un resultado se use. Aplicado al vibe coding, significa que alguien con criterio de ingeniería define qué es correcto, seguro y suficientemente robusto, y que la automatización (análisis estático, pruebas, revisión de dependencias) verifica el resto. El humano no necesita escribir el código. Necesita conservar el control sobre los criterios que deciden si ese código es aceptable.

5Prototipo no es producto

Esto ya no es hipotético. En 2025, un investigador revisó aplicaciones construidas con Lovable, una de las plataformas de vibe coding más populares, y encontró al menos 170 que exponían datos de sus usuarios (correos, teléfonos, estado de pago y claves de acceso a otros servicios) porque nadie había configurado bien quién podía leer qué en la base de datos. El problema quedó registrado como una vulnerabilidad oficial, la CVE-2025-48757.¹³ Ese mismo año, el inversionista Jason Lemkin contó en público cómo el agente de IA de Replit borró la base de datos de un proyecto que estaba construyendo, en medio de un congelamiento de código que él mismo había pedido. El CEO de Replit lo calificó de inaceptable y anunció que separaría automáticamente los ambientes de desarrollo y de producción, algo que cualquier equipo de ingeniería da por sentado.¹⁴

Vuelvo al área comercial del caso. El prototipo estuvo listo en tres días. La interfaz era atractiva, los resultados parecían correctos y la demostración ante la gerencia salió impecable. La organización concluyó lo obvio: el producto está prácticamente terminado.

Nadie hizo las preguntas que separan una demostración de una capacidad operacional. ¿Qué pasa si una fuente cambia su estructura? ¿Dónde están guardadas las credenciales? ¿Qué ocurre cuando cien personas consultan al mismo tiempo? ¿Cómo se recupera si falla? ¿Quién controla las versiones? ¿Cómo se audita por qué recomendó contactar a un cliente y no a otro? ¿Qué garantiza que los datos de un cliente no se mezclen con los de otro? No son exigencias de una gran plataforma corporativa. Son lo mínimo para pasar de una idea validada a algo de lo que la empresa depende.

El costo oculto aparece el día en que la organización descubre que lo que trataba como producto terminado era, en realidad, una prueba de concepto. Fred Brooks lo advirtió hace medio siglo en The Mythical Man-Month: el primer sistema que se construye casi siempre termina desechándose, y lo único que se puede decidir es si eso se planifica o se descubre tarde.¹⁵ Y eso no es un fracaso del vibe coding. Es un fracaso de liderazgo al fijar expectativas, presupuestos y criterios de madurez.

En The P&L Can Be Right describí la Deuda de Liderazgo en IA: el costo futuro que se acumula cuando las decisiones de liderazgo sobre IA avanzan más rápido que la capacidad de la organización para sostenerlas. Una de sus seis formas es la deuda de arquitectura, y el vibe coding la acelera como ninguna otra cosa. Se puede incurrir en ella de dos maneras opuestas: usar una arquitectura experimental para algo que después necesita escalar, ser seguro y estar siempre disponible; o exigir desde el primer día una arquitectura sobredimensionada para una idea que todavía nadie ha validado. Las dos destruyen valor. La primera difiere costos de reconstrucción; la segunda gasta capital antes de saber si hay una necesidad real.

¿Por qué el vibe coding la acelera? Porque la velocidad con que aparece una solución funcional comprime la percepción de complejidad. El liderazgo ve el resultado, pero no el trabajo que falta para convertirlo en una capacidad sostenible. La facilidad para desarrollar termina amplificando el costo de no saber qué se está desarrollando.

6Desarrollar rápido sin hipotecar el futuro

La respuesta no es abandonar estas herramientas ni volver a procesos rígidos e innecesariamente lentos. Sería renunciar a una de las transformaciones más importantes de la ingeniería de software. La alternativa es aprovechar la velocidad e introducir, desde el comienzo, los controles mínimos para que lo construido pueda evolucionar. Lo llamo vibe coding listo para evolucionar (Evolution-Ready Vibe Coding): no se trata de que cada prototipo esté preparado para operar a escala corporativa, sino de distinguir qué decisiones pueden quedar en modo experimental y cuáles hay que evaluar antes de comprometer el futuro del sistema.

Siete preguntas ordenan esa distinción: qué problema resuelve y cómo sabremos que lo resolvió; cómo va a evolucionar; qué podría comprometer; cómo sabemos que funciona correctamente, incluidos los casos límite; quién entiende el sistema; quién responde cuando falla; y cuánto costará mantenerlo y escalarlo. Algunos de esos controles se pueden automatizar dentro del mismo proceso de generación. Otros son decisiones explícitas que no deberían delegarse a un modelo.

La clave es la proporcionalidad. Una herramienta interna de uso temporal justifica controles sencillos. Una aplicación que procesa datos personales, apoya operaciones financieras o interviene en decisiones clínicas necesita estándares mucho más exigentes. En Chile, además, la Ley 21.719 exigirá poder explicar las decisiones automatizadas que afectan significativamente a las personas y responder en 30 días a quien pida acceso a sus datos, algo muy difícil de cumplir con un sistema que nadie entiende.¹⁶ El rigor debe responder al riesgo y al impacto del sistema, no a la herramienta con que se construyó.

7Cuando la velocidad se convierte en una decisión de liderazgo

Hay una paradoja detrás de todo esto. A medida que la IA automatiza la escritura de código, saber escribir instrucciones sintácticamente correctas vale menos. Pero otras capacidades valen más: arquitectura, pensamiento sistémico, evaluación de riesgos, comprensión de requisitos, diseño de pruebas y, sobre todo, la capacidad de reconocer una mala decisión técnica cuando se ve bien. Un desarrollador experimentado y una persona sin formación pueden construir aplicaciones que parecen equivalentes. La diferencia aparece cuando algo falla, cuando cambian los requisitos, cuando crecen los usuarios o cuando hay que demostrar que el sistema cumple con algo. Ahí, entender el software deja de ser una ventaja y se convierte en la condición para controlarlo.

Por eso, capacitar a las personas para usar asistentes de programación no basta. Las organizaciones necesitan la capacidad de especificar, evaluar, gobernar y mantener software que en gran parte no escribió ningún humano. La alfabetización en IA no reemplaza la ingeniería, y la facilidad de generación no reemplaza la responsabilidad técnica.

Desde la perspectiva de AI Value Realization Theory (AVRT), el marco con que analizo cómo la IA se convierte en valor, la cadena no termina cuando la IA produce código. Ese código tiene que validarse, integrarse a un proceso, convertirse en una capacidad y producir resultados medibles. Cada paso puede fallar, y una solución que parte con resultados positivos puede terminar destruyendo valor si su mantenimiento, su riesgo y su reconstrucción cuestan más de lo que entrega.

Para un directorio, la pregunta no debería ser cuánto más rápido puede construir software la empresa con IA. Debería ser esta: ¿qué parte de esa velocidad se está convirtiendo en sistemas confiables, mantenibles y capaces de generar valor en el tiempo, y qué parte en costos que todavía no vemos?

Acelerar la producción de software se nota en minutos. Acelerar la creación de valor solo se demuestra cuando el sistema se usa, se mantiene, se adapta y se evalúa en condiciones reales. Ahí es donde el costo oculto deja de serlo.

La IA puede hacer que desarrollar software parezca cada vez más simple. Pero la simplicidad para crear no es simplicidad de ingeniería.

Referencias

1. METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. metr.org
2. METR (2026). Uplift update, 24 de febrero de 2026. metr.org
3. Perry, N., Srivastava, M., Kumar, D. y Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? Stanford University. arxiv.org/abs/2211.03622
4. Stack Overflow (2025). 2025 Developer Survey.
5. Karpathy, A. (2025). Publicación en X que acuñó el término vibe coding, febrero de 2025.
6. Veracode (2026). Spring 2026 GenAI Code Security Update, 24 de marzo de 2026. veracode.com
7. Pearce, H. y otros (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. IEEE Symposium on Security and Privacy.
8. GitClear (2026). The AI Code Quality Maintainability Gap. gitclear.com
9. Google Cloud (2024). DORA: Accelerate State of DevOps Report 2024.
10. Osmani, A. (2026). Comprehension debt: the hidden cost of AI-generated code. O’Reilly Radar, 13 de abril de 2026.
11. Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA ’92.
12. Kosmyna, N. y otros (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. MIT Media Lab.
13. CVE-2025-48757 (2025). Falta de controles de acceso en proyectos generados con Lovable. Reportado por Matt Palmer.
14. The Stack (2025). Vibe coding CEO deletes production database, 21 de julio de 2025.
15. Brooks, F. (1975). The Mythical Man-Month. Addison-Wesley.
16. Ley N° 21.719 sobre protección y tratamiento de datos personales. Biblioteca del Congreso Nacional.

El caso del área comercial es ilustrativo. El concepto de vibe coding listo para evolucionar es una propuesta del autor, todavía no validada empíricamente.