El *vibe coding* —describir lo que quieres y aceptar el código que un modelo genera sin revisarlo en profundidad— produce prototipos en horas y sistemas frágiles en meses. No es una técnica ilegítima: es una técnica excelente para explorar una idea y una técnica peligrosa para construir algo de lo que dependa una empresa.
La confusión entre ambas cosas es el problema. Lo que sale de una sesión de generación asistida se parece mucho a un producto: tiene interfaz, responde, hace lo que se le pidió delante de quien lo pidió. La diferencia con un producto real no está en lo que hace, sino en todo lo que no se ha decidido: qué pasa cuando falla, quién puede ver qué, cómo se cambia dentro de un año y quién entiende por qué está escrito así.
|
Dimensión |
Prototipo generado |
Sistema en producción |
|---|---|---|
|
Objetivo |
Demostrar que la idea es posible |
Operar de forma fiable durante años |
|
Errores |
Se corrigen regenerando |
Se corrigen sin romper lo demás |
|
بيانات |
De prueba, limpios |
Reales, incompletos, contradictorios |
|
حماية |
Fuera de alcance |
Permisos, cifrado, auditoría |
|
صيانة |
No aplica |
El 60-70% del coste total |
|
Propiedad del criterio |
El modelo decidió la estructura |
Alguien la decidió y sabe por qué |
La última fila es la que más pesa a medio plazo. Cuando nadie ha decidido la estructura, nadie puede defenderla ni evolucionarla. Se convierte en un texto que hay que interpretar cada vez que se toca, y esa interpretación cuesta tiempo en cada cambio futuro.
No es una intuición de gremio. GitClear, analizando 211 millones de líneas de código entre 2020 y 2024, encontró que el trabajo de refactorización —reorganizar lo existente para que siga siendo comprensible— cayó de alrededor del 25% del cambio total en 2021 a menos del 10% en 2024, mientras el copiar y pegar subía del 8,3% al 12,3% y los bloques duplicados se multiplicaban por ocho.
El informe DORA de 2024 de Google Cloud, sobre unos 39.000 profesionales, midió el efecto en la entrega: un aumento del 25% en la adopción de IA correlacionaba con una caída del 1,5% en throughput y del 7,2% en estabilidad. En el mismo estudio, el 39,2% de los desarrolladores declaraba poca o ninguna confianza en el código generado.
El patrón que describen ambos es coherente: se produce más, se revisa igual y se reorganiza menos. La consecuencia no aparece en la semana uno; aparece cuando hay que cambiar algo.
Sería una tontería renunciar a una herramienta que multiplica la velocidad de exploración. Estos son los usos donde el vibe coding es claramente la decisión correcta:
En los cuatro casos hay un rasgo común: el resultado no tiene que sobrevivir. En el momento en que alguien dice «esto ya casi funciona, pongámoslo en producción», el uso ha cambiado de categoría y el criterio debería cambiar con él.
Antes de promover a producción algo generado así, conviene responder a esto:
Un prototipo que responde a las cinco ya no es un prototipo: es un sistema que se construyó rápido, que es exactamente lo que se busca. El problema nunca fue la velocidad.
El patrón que vemos en auditoría es siempre el mismo. Un equipo pequeño construye en tres semanas lo que habría costado tres meses. La dirección concluye, razonablemente, que el desarrollo se ha abaratado. Se aprueban más iniciativas con el mismo criterio.
Seis meses después, cada cambio tarda más que el anterior, nadie quiere tocar dos módulos concretos y las estimaciones dejan de ser fiables. Es el cuadro clínico de la deuda técnica, y lo hemos desarrollado en detalle en el cuello de botella vuelve a ser la arquitectura.
Lo llamativo es que el diagnóstico rara vez señala el origen, porque la velocidad inicial fue real y todo el mundo la recuerda como un éxito.
El patrón que vemos en auditoría es siempre el mismo. Un equipo pequeño construye en tres semanas lo que habría costado tres meses. La dirección concluye, razonablemente, que el desarrollo se ha abaratado. Se aprueban más iniciativas con el mismo criterio.
Seis meses después, cada cambio tarda más que el anterior, nadie quiere tocar dos módulos concretos y las estimaciones dejan de ser fiables. Es el cuadro clínico de la deuda técnica, y lo hemos desarrollado en detalle en el cuello de botella vuelve a ser la arquitectura.
Lo llamativo es que el diagnóstico rara vez señala el origen, porque la velocidad inicial fue real y todo el mundo la recuerda como un éxito.
No hay que elegir entre generar rápido y construir bien. Hay que separar las dos fases y ser explícito sobre en cuál se está:
Fase de exploración. Genera todo lo que quieras, sin revisión profunda, con datos falsos y sin pensar en mantenimiento. El objetivo es aprender.
Punto de decisión. Alguien declara que la idea es válida. Aquí es donde se toma la decisión que casi nadie toma: lo explorado se tira. Lo que se conserva es el conocimiento, no el código.
Fase de construcción. Se define la arquitectura, se decide el modelo de datos, se establecen los contratos, y entonces sí se usa generación asistida, ahora dentro de una estructura decidida por una persona.
Tirar el prototipo parece un desperdicio y no lo es: el prototipo ya cumplió su función, que era responder a una pregunta. Conservarlo es lo que convierte una herramienta de exploración en el cimiento de un edificio.
Esta separación es la razón por la que en TCG-SAF™ la arquitectura precede a la construcción. No por ceremonia: porque es lo único que permite usar la velocidad de generación sin heredar el desorden.
Es la práctica de generar software describiendo lo que se quiere y aceptando el código producido por un modelo sin revisarlo en profundidad. Es muy eficaz para explorar ideas y construir prototipos, y problemática cuando el resultado se promueve a producción sin rediseñarlo.
Solo si responde a cinco preguntas: alguien puede explicar por qué está estructurado así, existen pruebas que detecten regresiones, está definido qué datos toca y quién puede verlos, hay registro y mecanismo de reversión ante fallos, y hay alguien que pueda mantenerlo dentro de un año.
Los datos apuntan a un cambio de patrón más que a un empeoramiento directo. GitClear documentó que la refactorización cayó de ~25% del cambio total en 2021 a menos del 10% en 2024 y que la duplicación se multiplicó por ocho. DORA midió en 2024 caídas de throughput y estabilidad al aumentar la adopción de IA.
Para validar una idea antes de invertir, explorar alternativas de interfaz, crear herramientas internas desechables o aprender un dominio nuevo. El rasgo común es que el resultado no necesita sobrevivir.
Separar las fases: conservar el conocimiento y descartar el código. Después definir arquitectura, modelo de datos y contratos, y volver a usar generación asistida dentro de esa estructura decidida por una persona.
Porque la velocidad inicial es real y se recuerda como un éxito, mientras que el coste se manifiesta cuando hay que cambiar algo: los cambios tardan cada vez más, hay módulos que nadie quiere tocar y las estimaciones dejan de ser fiables.
¿Tienes en producción algo que nació como prototipo? Nuestra auditoría técnica te dice en 10 días hábiles, con precio cerrado, qué se puede conservar, qué hay que reestructurar y qué está costando dinero cada mes. Pide la auditoría →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
