Dónde falla
Sé honesto sobre los límites, porque aquí es donde el vibe coding sin supervisión le quema a la gente:
- Lógica profunda y novedosa. Algoritmos sutiles, concurrencia, cualquier cosa donde estar 95% en lo correcto significa estar roto. El modelo está seguro de sí mismo incluso cuando se equivoca.
- Cambios extendidos entre muchos archivos. Pierde el hilo en una base de código grande y rompe silenciosamente cosas que no puede ver.
- Seguridad y dinero. Autenticación, pagos, permisos, cualquier cosa donde un error que se ve plausible tiene consecuencias reales. Revisa esto como si tu trabajo dependiera de ello, porque podría ser así.
- Problemas subespecificados. Si tú no sabes cómo se ve "correcto", la IA no puede leerte la mente. Especificación basura entra, código basura sale.
El modo de falla es casi siempre el mismo: código que parece correcto, corre en el camino feliz y está mal de una forma que habrías detectado si lo hubieras leído. La solución es el paso de revisión. No hay forma de saltárselo.
Dos preguntas ubican cualquier tarea en este mapa: ¿el patrón es común? y ¿el resultado es barato de verificar?
EASY TO VERIFY HARD TO VERIFY
┌──────────────────┬──────────────────┐
COMMON │ PURE UPSIDE │ go slower, │
PATTERN │ (scaffold, │ demand tests │
│ boilerplate) │ │
├──────────────────┼──────────────────┤
RARE / │ read it, but │ DANGER ZONE │
NOVEL │ doable │ (novel logic, │
│ │ auth, money) │
└──────────────────┴──────────────────┘
Fíjate en el inverso de la regla anterior: estos son los casos que son raros, sutiles o costosos de verificar. El patrón es poco común, así que el modelo está adivinando; o el bug es invisible en el camino feliz, así que una revisión rápida no lo detectará. Eso no significa que evites la IA aquí; significa que vayas más despacio, reduzcas los pasos, exijas pruebas y leas cada línea como si fuera hostil.