La Retro para la Resaca del Vibe-Coding

En algún lugar de tu código hay un módulo que nadie quiere tocar. Se lanzó en marzo, rápido, con un asistente de IA haciendo la mayor parte de la escritura. Funcionó en la demo. Ha sido reescrito dos veces desde entonces, aparece en las líneas de tiempo de incidentes, y el ingeniero que lo "escribió" no puede explicarlo completamente.

Ese módulo ahora tiene un nombre. La industria pasó 2025 discutiendo si las herramientas de codificación con IA hacen a los equipos más rápidos. En 2026 la discusión terminó y llegó la factura — no en dólares, sino en rotación, colas de revisión y canales de incidentes. Autonoma lo llama el "ajuste de cuentas de 90 días": el punto donde la velocidad del mes uno se convierte en la deuda del mes tres. Gizmodo reportó el septiembre pasado que las empresas están contratando ingenieros específicamente para arreglar los desastres del vibe-coding. Toda una economía de limpieza se está formando alrededor de un problema que la mayoría de los equipos podrían detectar ellos mismos, cuatro sprints antes, en una ceremonia que ya tienen en el calendario.

Este post trata sobre ejecutar esa ceremonia correctamente.

La Resaca Es Medible

El latigazo no es un sentimiento. El Reporte de Ingeniería con IA 2026 de Faros AI — dos años de telemetría de 22,000 desarrolladores en más de 4,000 equipos — puso números en ambas mitades: la aceleración que todos celebraron, y el deterioro que la siguió aguas abajo.

Fuente: Faros AI, "AI Engineering Report 2026," abril 2026.

Lee las dos primeras filas y la IA está funcionando. Lee las últimas cinco y puedes ver la resaca formándose en tiempo real: el código se descarta casi nueve veces más seguido, los incidentes por PR se han más que triplicado, y casi un tercio más de cambios están llegando a producción sin que un solo humano los lea.

El reporte DORA 2025, ahora retitulado "Estado del Desarrollo de Software Asistido por IA," encontró la misma forma a escala de encuesta: 90% de los desarrolladores usan IA en el trabajo, arriba del 76% del año anterior, y la adopción de IA ahora está vinculada positivamente con el rendimiento. Pero "continúa teniendo una relación negativa con la estabilidad de entrega de software." Más rápido y más inestable, al mismo tiempo, en toda la industria.

Esta Es una Falla de Proceso, No una Falla de Herramienta

La IA hizo exactamente lo que se le pidió. Produjo código plausible a una velocidad para la que ningún proceso de revisión fue diseñado. Lo que falló fue todo alrededor: nadie decidió cuánta verificación merece un diff escrito por máquina, qué tamaño de lote mantiene honesta la revisión, o quién es responsable del código que ningún humano escribió.

Esos son acuerdos de trabajo. Los acuerdos de trabajo son proceso. Y la evidencia dice que el proceso es precisamente donde está el apalancamiento. El Modelo de Capacidades de IA de DORA identifica siete condiciones que determinan si la IA amplifica a un equipo o amplifica su disfunción — y todas son organizacionales: una postura de IA clara y comunicada, prácticas sólidas de control de versiones, trabajar en lotes pequeños, ecosistemas de datos saludables. Ni una sola de ellas es "compra un mejor modelo."

El reporte de ROI 2026 de DORA agregó el lado de costos. Los equipos que adoptan IA enfrentan una curva en J (la productividad cae antes de subir), y un impulsor importante es lo que el reporte llama el impuesto de verificación: las horas humanas gastadas verificando la salida de la máquina. La encuesta 2025 de Stack Overflow de más de 49,000 desarrolladores explica por qué ese impuesto es tan alto. La confianza en la precisión de la IA cayó de 40% a 29% en un año, y la frustración número uno, citada por 45% de los encuestados, es "soluciones de IA que están casi bien, pero no del todo." El código casi-correcto es el tipo más caro. El código incorrecto falla rápido; el código casi-correcto pasa la revisión y falla en producción.

Un problema de herramienta tendría una solución de herramienta. Un problema de acuerdos de trabajo tiene exactamente un lugar donde los equipos renegocian cómo trabajan.

¿Qué Es una Retro de Resaca del Vibe-Coding?

Una retro de resaca del vibe-coding es una retrospectiva que examina cómo tu equipo produce código con IA, no solo qué lanzó. Reemplaza opiniones con los propios datos de entrega del equipo — rotación de código, latencia de revisión, enlaces de incidentes, fusiones sin revisar — y su resultado es un conjunto pequeño de acuerdos de trabajo para cambios escritos por máquina, cada uno medible en el siguiente sprint.

Difiere de tu retro regular en alcance, no en formato. Una retro normal pregunta "¿cómo estuvo el sprint?" Esta pregunta es más precisa: "¿cuál es nuestra relación real con el código que no escribimos?" Mismas plantillas, misma votación, mismo timebox. Diferente evidencia sobre la mesa.

Y debería suceder pronto, no eventualmente. Los datos de Faros dicen que el deterioro se acumula: la rotación alimenta incidentes, los incidentes alimentan la carga de revisión, la carga de revisión alimenta la tentación de fusionar sin revisar. Cada sprint sin una corrección de curso hace la corrección más grande.

Ejecútalo con datos, no con vibras

Hay una ironía real en hacer una retrospectiva sobre codificación por vibras y ejecutarla con vibras. Si el modo de falla fue "confiamos en resultados plausibles sin verificación", la ceremonia que lo arregla no puede ejecutarse con impresiones plausibles. Tus integraciones ya tienen la evidencia — tus repos conocen la rotación, tu tracker conoce el retrabajo, tu canal de incidentes conoce el rastro.

Pon cinco preguntas en el tablero, cada una anclada a un número que puedes obtener antes de la reunión:

1. ¿Qué PRs de los últimos 90 días ya hemos reescrito? La rotación es la medida honesta de velocidad. Una funcionalidad que enviaste dos veces no se envió rápido.
2. ¿A dónde va realmente la revisión? Si el tiempo hasta la primera revisión está aumentando mientras las fusiones sin revisión aumentan con él, tu proceso de revisión se está racionando silenciosamente. Decide el racionamiento a propósito.
3. ¿Qué incidentes se remontan a cambios que nadie leyó completamente? No para culpar: para dimensionar el impuesto de verificación que ya estás pagando en el peor momento posible, en producción.
4. ¿Cuál es nuestro acuerdo de trabajo para diffs escritos por máquina? Si el equipo no puede expresarlo en una oración, no tienes uno. Tienes una vibra.
5. ¿Los últimos elementos de acción se mantuvieron? Dos tercios de los elementos de acción de retro mueren. Si los tuyos murieron, ese es el primer arreglo. Nada más que decidas hoy importa si se evapora para el jueves.

Haz que los arreglos sobrevivan el contacto con el siguiente sprint

El resultado de esta retro no es un resumen de sentimientos. Son dos o tres acuerdos de trabajo, cada uno redactado para que los datos del siguiente sprint puedan confirmarlo o negarlo. El patrón que funciona: una regla concreta, un número que se mueve si se sigue, y una revisión nombrada.

• "Los PRs generados por agente de más de 400 líneas se dividen antes de revisión." Verificación: distribución de tamaño de PR, siguiente retro.
• "Nada se fusiona sin una aprobación humana, CI verde o no." Verificación: conteo de fusiones sin revisión, semanal.
• "Cada revisión de incidente pregunta si el cambio desencadenante fue escrito por IA, y rastreamos la proporción." Verificación: plantilla de postmortem de incidente, esta semana.

Lotes pequeños, revisión obligatoria, trazabilidad de incidentes — notarás que estas son las capacidades de IA de DORA, traducidas a oraciones con las que un equipo puede realmente estar de acuerdo un martes. Ese es el punto. La investigación nombra las capacidades; la retro es donde un equipo las instala.

Luego el ciclo se cierra de la manera en que siempre hemos argumentado que debería: la siguiente retro abre verificando si los acuerdos se mantuvieron y si los números se movieron. ¿Bajó la rotación? ¿Se recuperó la latencia de revisión? ¿Se mantuvo? La mejora que no puedes verificar es solo otra vibra.

La conclusión

La resaca nunca fue el precio de usar IA. Es el precio de adoptar una nueva forma de construir software sin sentarse nunca como equipo a renegociar cómo construyes software. Los equipos que avanzan en 2026 no son los que usan más IA o menos. Son los que notaron el latigazo en sus propios datos, convocaron la reunión y escribieron las reglas — mientras todos los demás seguían discutiendo sobre qué vibra era correcta.

No necesitas un especialista en limpieza. Necesitas noventa minutos y tus propios números.

No menos IA. Más reflexión.

Fuentes

• Faros AI — "Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash" (abril 2026)
• DORA — State of AI-assisted Software Development 2025 y anuncio de Google Cloud (septiembre 2025)
• DORA AI Capabilities Model (2025)
• InfoQ — "New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment" (mayo 2026)
• Stack Overflow — resultados de la encuesta de desarrolladores 2025 (diciembre 2025)
• Gizmodo — "After AI Led to Layoffs, Coders Are Being Hired to Fix 'Vibe-Coded' Screwups" (septiembre 2025)
• Autonoma — "Vibe Coding Technical Debt: The 90-Day Reckoning" (abril 2026)

Lectura adicional

• Por qué 2/3 de los elementos de acción de retrospectiva mueren (y cómo arreglarlo) — el problema de seguimiento del que depende esta retro para resolverse.
• Medir lo que la IA realmente le hace a tu equipo — cómo ver el impacto real de la IA en tu equipo sin vigilancia.
• Enviar y mantener: cómo medir si la IA realmente está funcionando — el marco de resultados detrás de "¿se mantuvo?"
• Más allá de los sprints: mejora continua para equipos nativos de IA — por qué la cadencia de reflexión importa más cuando el despliegue es continuo.