El problema del vibe coding no tiene nada que ver con la IA

Una demo funcional es el artefacto más peligroso del software. Pasa la prueba visual del stakeholder, corre en el navegador, y si se armó con un par de prompts y un asistente de IA, hasta se ve profesional. El costo está debajo de la superficie — y aparece recién cuando llegan los usuarios reales con escrituras concurrentes, tráfico de producción y patrones de uso que ninguna demo anticipó. El verdadero problema del vibe coding no es la IA que genera el código. Es la ausencia de criterio de ingeniería revisando, moldeando y haciéndose cargo de lo que sale a producción.

El vibe coding disfraza fragilidad como producto terminado

El término nació a principios de 2025 para describir un flujo de trabajo concreto: darle un prompt a un asistente de IA, aceptar lo que devuelve con revisión mínima y repetir hasta que la aplicación parezca funcionar. En pocos meses se volvió tan mainstream que Collins Dictionary lo eligió como palabra del año. La velocidad es real. La ilusión de completitud que genera es todavía más real.

Para alguien no técnico, una aplicación vibe-coded luce idéntica a una construida por un equipo senior de ingeniería. Tiene rutas, base de datos, pantalla de login y una URL de deploy. Pero lo que hay debajo suele contar otra historia: un esquema de base de datos que colapsa pasados unos cientos de registros, lógica de autenticación sin validación de inputs, llamadas a APIs que se rompen con tráfico concurrente, y cero logging, tests o pipeline de deployment.

La percepción es el bug más difícil de corregir. La distancia entre "funciona en mi máquina" y "funciona para mil usuarios un sábado a la noche" es donde mueren la mayoría de los proyectos vibe-coded — en silencio, con un costo alto, y siempre en el peor momento posible.

Dónde fallan los sistemas vibe-coded en producción

Tres categorías de fallas explican casi todo postmortem de vibe coding: seguridad, escalabilidad y mantenibilidad. Cada una potencia a las otras, y juntas forman un patrón que se repite con una consistencia llamativa entre equipos, stacks e industrias.

Seguridad: las vulnerabilidades que nadie revisó

Entre el 45% y el 48% del código generado por IA contiene vulnerabilidades de seguridad — una cifra que se mantuvo estable a lo largo de auditorías independientes durante 2025 y 2026. El código co-escrito con IA introduce fallas de seguridad a una tasa aproximadamente 2.7 veces mayor que el código escrito por humanos. Los patrones son predecibles: API keys hardcodeadas enviadas al cliente, validación de JWT salteada o mal configurada, políticas de Row-Level Security que parecen correctas en la superficie pero otorgan acceso a todas las filas de la tabla.

El riesgo no es teórico. A principios de 2026, una aplicación vibe-coded construida sobre una plataforma de IA popular expuso más de 18,000 registros de usuarios, incluyendo cuentas de estudiantes con probables menores de edad entre ellos. La causa raíz fue una política de RLS mal configurada — una corrección de cinco líneas que cualquier ingeniero con experiencia habría detectado en un code review, pero que nadie revisó antes del deploy.

Cuando la seguridad se trata como algo que la IA va a resolver, la IA lo resuelve como resuelve todo lo demás: estadísticamente, sin contexto y sin accountability.

Escalabilidad: la arquitectura que nadie diseñó

Los asistentes de IA optimizan para el prompt inmediato, no para el futuro del sistema. Producen código que satisface el requerimiento actual sin conciencia de los límites de conexión, la planificación de queries, las estrategias de caché, ni la diferencia de comportamiento entre una tabla de 50 filas y una de 500,000.

Los esquemas de base de datos generados por prompts suelen carecer de índices compuestos, almacenan datos estructurados como blobs de JSON en columnas de texto y usan configuraciones por defecto que agotan el connection pool con tráfico moderado. La aplicación anda perfecto en el entorno de preview. Falla con el primer pico de tráfico real — no con un error claro, sino con una cascada de timeouts de 30 segundos que se propaga por cada servicio que comparte la misma conexión a la base de datos.

El context drift agrava el problema. La mayoría de los asistentes de IA pierden coherencia en codebases que superan unos pocos miles de líneas. Para el archivo siete u ocho, el modelo ya olvidó las decisiones de arquitectura que tomó en el archivo dos. Las nuevas sugerencias contradicen las anteriores, y el sistema resultante se comporta menos como software diseñado y más como un ensamblaje accidental de fragmentos independientes.

Mantenibilidad: el código sin ownership

Una aplicación vibe-coded tiene una propiedad inusual: la persona que la puso en producción no la escribió, y muchas veces no la entiende del todo. Esto genera una brecha entre intención e implementación que ninguna cantidad de re-prompting puede cerrar después.

Cuando un bug aparece tres meses más tarde, el ingeniero que tiene que arreglarlo se encuentra con convenciones de nombres auto-generadas, patrones de arquitectura inconsistentes y flujos de lógica que reflejan la distribución de entrenamiento del modelo en lugar de los requerimientos del dominio. El debugging se convierte en arqueología. Cada cambio introduce una regresión porque las suposiciones implícitas en el código nunca fueron explicitadas por un humano que las entendiera.

El ownership no es un concepto de gestión — es un concepto de ingeniería. Código sin dueño técnico es código que nadie puede modificar con confianza, y código que nadie puede modificar con confianza es código que se pudre.

La trampa de velocidad que genera el vibe coding

La velocidad es la cualidad más seductora del vibe coding. Un prototipo funcional en horas. Un feature por prompt. Un deploy antes del almuerzo. Pero la curva de aceleración es engañosa — parece exponencial al principio y choca contra una pared alrededor del tercer mes.

Los equipos que construyen agresivamente con vibe coding reportan un patrón consistente: para la semana doce, la mayor parte de la capacidad del sprint se consume no en features nuevos sino en regresiones. Arreglar un componente generado por IA rompe otro. El codebase creció más allá de la ventana de contexto del asistente, así que las nuevas sugerencias entran en conflicto con decisiones que el modelo tomó en archivos anteriores. El proyecto llega a lo que algunos practioners llaman el spaghetti point — el momento donde agregar cualquier cosa nueva cuesta más que empezar de cero.

La velocidad inicial nunca fue gratis. Se tomó prestada contra tiempo de ingeniería futuro, y la tasa de interés se acumula más rápido de lo que cualquiera espera. Un feature que tomó treinta minutos de prompts puede llevar una semana entera de debugging cuando interactúa mal con el resto del sistema. Los equipos que tomaron la velocidad del primer mes como la línea base descubren, dolorosamente, que era la anomalía.

La IA es la herramienta, no el problema

Nada de esto es un argumento en contra de usar IA en el desarrollo de software. La ingeniería asistida por IA — donde un desarrollador usa IA para acelerar trabajo que entiende, revisa y del que se hace cargo — es un multiplicador de productividad genuino. La distinción entre este enfoque y el vibe coding importa mucho más que las herramientas específicas que se usen.

Un desarrollador que genera una migración boilerplate con IA, después revisa el SQL, agrega el índice que falta y testea el rollback, está haciendo ingeniería con mejores herramientas. Un desarrollador que le pide al asistente "agregá autenticación de usuarios" y despliega el resultado sin leerlo está practicando esperanza con un teclado.

La IA produce borradores. La calidad del producto final depende enteramente del criterio que se aplica entre el borrador y el deployment. Ese criterio requiere entender cómo se comporta una base de datos bajo carga, reconocer patrones inseguros en la lógica de autenticación y saber cuándo una sugerencia está sutilmente mal — habilidades que se desarrollan a lo largo de años de construir, romper y reparar sistemas reales. La IA acelera las manos. No reemplaza la cabeza detrás de ellas.

Cómo se ve un desarrollo asistido por IA responsable

Pasar del vibe coding a la ingeniería asistida por IA con disciplina no significa abandonar la IA ni volver a escribir cada línea a mano. Significa restaurar el criterio de ingeniería que el vibe coding se saltea.

• Revisar cada sugerencia antes de aceptarla. No una ojeada — una revisión. Si no podés explicarle el código generado a un colega, no estás listo para ponerlo en producción.
• Tener ownership de la arquitectura. La IA debería implementar tus decisiones de diseño, no tomarlas por vos. Definí el esquema, los límites de los servicios, la estrategia de manejo de errores y el modelo de seguridad antes del primer prompt.
• Testear lo que importa. Los tests automatizados atrapan regresiones antes que los usuarios. Un proyecto vibe-coded sin tests es un proyecto que se rompe en silencio una y otra vez.
• Agregar logging y observabilidad desde el día uno. Si el comportamiento de la aplicación en producción es invisible, arreglarla cuando falla es pura adivinanza. Y va a fallar.
• Tratar la seguridad como prerrequisito, no como feature. Validación de inputs, autenticación correcta, almacenamiento seguro de credenciales y políticas de autorización bien configuradas son la base de la que depende todo lo demás. Nunca son una mejora para agregar después.

¿Qué preguntan los equipos técnicos sobre vibe coding?

La línea entre el vibe coding y la ingeniería asistida por IA genera preguntas prácticas que aparecen una y otra vez en equipos técnicos evaluando cómo incorporar IA a sus flujos de trabajo.

¿Es aceptable usar vibe coding para prototipos descartables?

Para una demo que nunca va a ver usuarios reales ni manejar datos reales, el vibe coding puede ser una herramienta de exploración útil. El riesgo empieza cuando el prototipo se gradúa silenciosamente a producción sin ser reconstruido con prácticas de ingeniería adecuadas. La postura más segura es tratar los prototipos vibe-coded como artefactos descartables — valiosos para validar ideas, nunca para entregar a usuarios reales.

¿Pueden los escáneres de seguridad compensar las vulnerabilidades del vibe coding?

Los escáneres automatizados detectan patrones conocidos: vulnerabilidades en dependencias, vectores de inyección comunes, headers faltantes. No detectan fallas arquitectónicas, políticas de autorización mal configuradas ni errores de lógica de negocio. Un escaneo limpio en una aplicación vibe-coded no significa que la aplicación sea segura. Significa que la cobertura del escáner tiene límites que el codebase todavía no superó.

¿El vibe coding erosiona el ownership del equipo con el tiempo?

La erosión es gradual pero medible. Cuando un equipo pone en producción código que ninguno de sus miembros entiende del todo de forma consistente, la capacidad colectiva de debuggear, refactorizar y extender el sistema se degrada mes a mes. Con el tiempo, el equipo pasa a depender de la herramienta de IA no solo para construir features nuevos sino para entender los existentes — una dependencia que se quiebra en el momento en que la ventana de contexto de la herramienta se excede o sus sugerencias divergen de las convenciones implícitas del codebase.

Una visión opuesta

Un argumento común corre en dirección contraria: la velocidad de llegada al mercado lo es todo, y el vibe coding la entrega. En entornos competitivos donde ser primero importa más que ser prolijo, enviar rápido y arreglar después es una estrategia racional. La deuda técnica es un trade-off aceptable cuando la supervivencia depende de llegar a los usuarios antes de que se acabe el runway.

El argumento se sostiene — hasta cierto punto. Para un founder solo validando una hipótesis con una landing page y una lista de espera, el trade-off puede tener sentido. Pero se desmorona en el momento en que datos reales de usuarios entran al sistema, en el momento en que un segundo ingeniero se suma al equipo, o en el momento en que la aplicación necesita manejar su sesión concurrente número 500. La velocidad que el vibe coding ofrece en la semana uno se convierte en la parálisis que bloquea al equipo en la semana doce. Sobrevivir exige enviar rápido, pero también exige enviar algo que siga funcionando cuando los usuarios realmente aparezcan.

Lo que importa recordar

• El vibe coding genera una brecha de percepción: las aplicaciones parecen completas pero carecen de las bases de ingeniería que las mantienen funcionando bajo condiciones reales.
• Entre el 45% y el 48% del código generado por IA sale a producción con vulnerabilidades de seguridad, incluyendo credenciales expuestas, autorización mal configurada y validación de inputs ausente.
• La ventaja de velocidad inicial colapsa en cuestión de meses cuando los loops de regresión y la deuda arquitectónica consumen más tiempo que el desarrollo de features nuevos.
• La IA es un multiplicador de ingeniería legítimo cuando se combina con revisión humana, ownership arquitectónico y testing disciplinado.
• Código sin un dueño humano — alguien que lo entienda y pueda modificarlo con seguridad — es código que eventualmente no se puede mantener.
• La seguridad, la escalabilidad y la observabilidad son prerrequisitos para producción, no features para agregar después del lanzamiento.

Conclusión

La conversación alrededor del vibe coding suele enmarcarse como un debate sobre IA, pero en el fondo es un debate sobre responsabilidad de ingeniería. Las herramientas de IA están mejorando a un ritmo que va a hacer que las limitaciones de hoy parezcan anecdóticas dentro de unos años. Lo que no va a cambiar es la necesidad de que alguien entienda lo que sale a producción, se haga cargo de las consecuencias cuando se rompa y tome las decisiones de arquitectura que determinan si un sistema sobrevive al primer encuentro real con usuarios. La pregunta que vale la pena hacerse no es si usar IA — ese barco ya zarpó. La pregunta es si la persona que aprieta deploy entiende lo que está desplegando, y si está dispuesta a bancársela cuando las cosas se pongan serias.