Lo que encuentro cuando me llaman al mes 9
Cuando un CTO me escribe para pedirme que entre a revisar su setup de IA, la conversación casi siempre empieza igual: «lo implantamos hace unos meses, los developers están contentos con las herramientas, pero algo no está funcionando. No sabemos qué.»
Cuando entro al repo y a los workflows, sé exactamente qué voy a encontrar. No lo sé por deducción — lo sé porque lo he visto ya en doce equipos de desarrollo de distintas verticales, tamaños y niveles de madurez técnica.
El diagnóstico es casi siempre el mismo: los workflows de IA están desactualizados. Las reglas de validación bloquean cosas que ya no deberían bloquear. La constitución del proyecto sigue diciendo cosas que el código ya no respeta. Y nadie lo ha actualizado — no porque el equipo sea descuidado, sino porque nadie tenía el mandato de hacerlo.
Eso es el mes 6.
Cómo funciona la transformación IA en los primeros tres meses
Para entender por qué el mes 6 es donde se rompe todo, hay que ver qué pasa antes.
Los primeros dos o tres meses de una transformación IA bien hecha son entusiasmo con método. El equipo instala los carriles: quién decide qué, quién revisa qué, en qué punto del flujo el humano firma. Se define la constitución del proyecto — el documento que codifica las reglas inmutables que la IA debe respetar: arquitectura, convenciones de código, restricciones de seguridad. Se establecen los quality gates: qué valida el agente, qué valida el humano, qué se bloquea de oficio.
Si el proceso de instalación está bien acompañado, al mes tres el equipo ve resultados tangibles. Los ciclos de PR review bajan. Los defectos en producción caen. El tiempo de onboarding de developers nuevos se reduce. El equipo siente que va más rápido — y esta vez, lo está midiendo, así que sabe que no es sólo sensación.
La organización concluye que la transformación ha funcionado. Esa conclusión es el primer error.
Anatomía del mes 6: lo que se rompe y en qué orden
La transformación no ha terminado al mes 3. Ha arrancado. Y lo que pasa en los tres meses siguientes determina si la inversión de los primeros tres va a sostenerse o va a evaporarse.
En los doce equipos que he acompañado, el colapso del mes 6 sigue siempre el mismo orden:
Se desactualizan los workflows
La guía de estilo cambia, el stack pivota, se añaden dependencias nuevas. La constitución del proyecto sigue diciendo lo que decía al mes 1. El agente genera código conforme a reglas que ya no reflejan la realidad. Nadie lo ha actualizado porque «ya funcionaba».
Se disparan los falsos positivos en los quality gates
Las reglas de validación empiezan a bloquear cosas que ya no deberían. El equipo empieza a sortearlos en silencio para no romper el flujo de delivery. Primero un developer. Luego dos.
Desaparece la constitución como fuente de verdad
Los developers confían menos en el documento versionado y más en su criterio personal. La consistencia del código generado por IA decae. Los code reviews se alargan porque hay que reescribir partes que el agente firmó mal.
La organización vuelve al punto de partida
A los 8-9 meses la velocidad de delivery ha vuelto al baseline previo. Y en el comité técnico la conversación es: «con esto no estamos viendo retorno, ¿qué herramienta probamos ahora?» El bucle se cierra.
Por qué parece un problema técnico cuando no lo es
El colapso del mes 6 tiene una firma operativa muy específica: cuando ocurre, todos los síntomas apuntan a la herramienta. «Copilot firma cosas que después hay que reescribir.» «El agente no entiende nuestra arquitectura.» «Los tests que genera no cubren los casos que necesitamos.»
Son síntomas reales. Pero la causa no es la herramienta. La herramienta funciona exactamente igual que al mes 1 — probablemente mejor, porque el modelo subyacente ha mejorado. Lo que ha cambiado es el contexto en el que opera. La constitución del proyecto ya no refleja la realidad. Los carriles humano-agente están desactualizados. El agente tiene menos información fiable sobre qué puede y qué no puede hacer en este proyecto específico.
Actualizar la herramienta en ese momento es comprar más velocidad para un coche que no tiene carretera. El problema no es la velocidad. Es la carretera.
Esta es la misma tesis que articula el artículo del gap del 70%: el 70% del éxito de la IA en un equipo no es técnico, es organizativo. El colapso del mes 6 es ese 70% haciéndose visible de golpe, después de meses acumulándose en silencio.
El sistema de sostenimiento que previene el colapso
Tras ver el patrón suficientes veces, los elementos que distinguen a los equipos donde la transformación sigue funcionando al mes 9 y al mes 12 no son complicados. Pero tienen que existir de forma deliberada — no se instalan solos.
Cuánto cuesta no tener el sistema
El coste del colapso no es sólo la pérdida de productividad. Es el tiempo invertido en reconstruir la transformación cuando ya está rota.
En los dos casos donde he entrado a reparar una transformación colapsada, el tiempo necesario para reconstruir los workflows, actualizar la constitución del proyecto, recalibrar los quality gates y devolver la confianza del equipo en el método fue entre seis y ocho semanas. Seis a ocho semanas de trabajo del equipo, mientras seguía entregando en producción.
Comparado con eso, dos horas al sprint de un senior dev rotando como owner de sostenimiento es una inversión trivial.
La frase que mejor resume el problema
«Los agentes aún no son suficientemente fiables para ingeniería compleja.»
— Andrej Karpathy
La conclusión operativa no es «no uses IA». Es: úsala con contexto fiable y supervisión activa. Los workflows, la constitución del proyecto, los quality gates — eso es el contexto fiable. El owner rotativo y el ritual mensual — eso es la supervisión activa.
Sin ambas cosas, la herramienta no es menos capaz. Simplemente está operando con información degradada sobre el entorno en el que trabaja. Y el resultado es el mes 6.
El mes 6 no es inevitable. Es el resultado de asumir que la transformación termina el día que la instalas.
Si llevas un equipo de desarrollo y quieres diagnosticar si tu setup actual va a aguantar más allá del mes 6, el artículo de Bernat con las cinco dimensiones organizativas y las cuatro preguntas para el comité es el punto de partida: El gap del 70%.
Si quieres hablar de cómo hemos instalado el sistema de sostenimiento en los equipos que acompañamos: info@onext.es · asunto «sostenimiento IA mes 6».
Lectura complementaria: El gap del 70%: problema técnico vs organizativo · Los 3 claims canónicos del AI Engine · Spec-Driven Development