Vibecoding
Construir software en iteración rápida con IA, sin spec formal
[[vibecoding|Vibecoding]] es el modo por defecto de casi todos: pides algo, ajustas, pides más, iteras. Funciona sorprendentemente bien para prototipos. Deja de funcionar cuando necesitas que lo construido sea reproducible, auditable o extensible por otra persona. Entender dónde termina el vibecoding evita seis meses de deuda técnica disfrazada de velocidad.
Construcción rápida de software con IA sin spec formal — útil para explorar, riesgoso para producción.
Cuándo el vibecoding gana
- Exploración: estás probando si algo se puede o no.
- Prototipos desechables: vas a tirar el código en una semana.
- One-shots: scripts de migración, limpieza de datos, utilidades personales.
En esos casos, escribir un spec es overhead. Vibecoding te lleva al resultado en 30 minutos.
Cuándo pierde
- Producción: cualquiera que tenga que pagar la cuenta cuando falle.
- Equipo: si otra persona (incluido tu yo-futuro) va a tocarlo, necesitas el contrato escrito.
- Features complejos: más de un endpoint o más de un estado = riesgo de loops infinitos.
Vibecoding no es malo per se — es inadecuado fuera de su dominio. La trampa es usarlo para lo que debería ser spec-driven-development.
De los últimos 5 features que pediste a un agente, ¿cuáles fueron vibecoding legítimo y cuáles debieron ser spec? El criterio: ¿vas a tocarlo de nuevo o entregárselo a alguien más?
- Vibecoding gana en exploración, prototipos y one-shots.
- Pierde en producción, equipo y features complejos.
- La trampa no es usarlo — es no saber cuándo dejar de usarlo.