Si llevas meses pagando licencias premium de Copilot, Cursor o Windsurf para todo tu equipo de desarrollo y la conversación interna sigue siendo «no estamos viendo el retorno que esperábamos», es muy probable que estés atacando el 30% del problema. El otro 70% — el que ningún vendor te va a vender porque no se compra en una factura — es organizativo. Esta pieza explica qué hay en ese 70%, por qué lo confundes con problema técnico cada trimestre, y las cuatro preguntas concretas que tu próximo comité de tecnología puede usar para distinguir ambas cosas.
El malentendido más caro del trimestre
Llevo varios meses viendo el mismo patrón en CTOs y VPs de Engineering de empresas medianas. La conversación con su equipo de dirección se reproduce con un guion casi idéntico: «hemos invertido equis miles de euros en licencias de Copilot para los developers; la encuesta interna dice que el equipo está contento con la herramienta; pero la velocidad de release no ha cambiado, los bugs en producción siguen subiendo, y el ratio de PR review no mejora».
Cuando la conversación llega al CFO o al consejo, la pregunta que aparece encima de la mesa es esta: «¿qué hacemos? ¿Compramos otra herramienta más potente? ¿Subimos a Cursor Enterprise? ¿Contratamos Copilot Workspace?». La intuición natural es escalar la inversión técnica: si una herramienta no devuelve, otra mejor sí lo hará.
Esa intuición es lo que en onext llamamos el malentendido del 70%. Y es la razón por la que más del 40% de los proyectos basados en agentes serán cancelados antes de finales de 2027, según Gartner.
La cifra que pocos vendors te van a contar
Tras trabajar con doce equipos de desarrollo que han completado nuestro programa de transformación con IA — equipos de entre veinte y doscientos developers — la pauta que vemos consistentemente es esta: aproximadamente el 70% del éxito de la IA en un equipo no es técnico. Es organizativo.
El 30% restante sí es técnico: la herramienta que se contrata, el modelo, el stack, la integración con el IDE. Es importante. Pero está acotado, es relativamente fácil de comprar, y todos los vendors del mercado compiten por ese 30%. El otro 70% — el que de verdad separa equipos productivos de equipos atascados — vive en cinco dimensiones organizativas que ninguna herramienta resuelve por sí sola.
Las cinco se diseñan con método. No se compran. Y eso explica por qué el CTO que sólo compra herramientas mejores, ciclo tras ciclo, sigue viendo el mismo resultado: la herramienta funciona, el problema persiste.
El estudio METR como evidencia del gap
El estudio del Model Evaluation & Threat Research Institute documentó algo que conviene tener encima de cualquier mesa de comité técnico: en su experimento sobre developers experimentados, los participantes que usaban IA reportaron +20% de productividad subjetiva mientras eran −19% menos productivos medidos en commits útiles, ciclo de PR review y defectos en producción.
La paradoja no es defecto de la tecnología — la tecnología en ese experimento era de primera clase. La paradoja es la consecuencia directa del gap organizativo: developers acelerados por la herramienta sin método pierden tiempo en revisar PRs que el agente firmó mal, en reescribir tests que el agente no entendió, en debugging de bugs latentes que el código generado no exhibe inmediatamente. La aceleración del input no se traduce en aceleración del output útil. El equipo siente que va más rápido. El equipo va más lento.
Esa es la firma operativa del 70% que falta.
Las cuatro preguntas para tu próximo comité
Si llevas el tema de adopción IA en el siguiente comité técnico de tu organización, éstas son las cuatro preguntas que distinguen un problema técnico de un problema organizativo.
Pregunta 1: ¿Tenemos definidos por escrito los carriles humano-agente en cada workflow crítico, o cada developer los improvisa con su criterio? Si la respuesta es «los improvisa», el problema no es la herramienta — es la ausencia de gobierno operativo. Comprar herramienta mejor no lo resuelve.
Pregunta 2: ¿Medimos productividad real (commits útiles, ciclo PR, defectos producción, tiempo onboarding) o productividad percibida (cuánto rápido nos sentimos)? Si la respuesta es «percibida», probablemente estamos en la paradoja METR. Comprar herramienta mejor amplifica la paradoja, no la resuelve.
Pregunta 3: ¿Tenemos personas con criterio en el equipo para definir y actualizar los quality gates, o el equipo está esperando que el vendor lo haga por ellos? Si la respuesta es «lo hace el vendor», la organización ha cedido la gobernanza al proveedor. Eso no es transformación — es dependencia.
Pregunta 4: ¿La organización tiene un plan de sostenimiento a seis meses, o estamos asumiendo que la herramienta se actualiza sola y los procesos también? Si la respuesta es «asumimos que se actualiza sola», el sostenimiento no existe. La curva se va a aplanar a los seis-nueve meses y volverás a estar en la conversación de hoy.
El benchmark interno que sostiene la tesis
Cuando decimos «el 70% del éxito de la IA es organizativo» no es una intuición. Es la pauta acumulada de doce equipos de desarrollo a los que hemos acompañado en transformación con IA — programa de entre doce y dieciséis semanas, con cuatro fases solapadas (diagnóstico, rediseño, despliegue, transferencia). El resultado consistente cuando el programa se ejecuta bien:
- ×7 velocidad de delivery (caso particular de cada equipo, dependiendo del baseline previo).
- 0 sprints perdidos durante el rediseño organizativo.
- −50% time-to-production: la mitad del tiempo entre que el ticket sale de Discovery y aterriza en producción.
- +40% consistencia de código medida en linting, cobertura de tests y rework post-merge.
- 1-2 FTE senior/año liberados por equipo en tareas ahora absorbibles por agentes supervisados.
Las cinco cifras vienen del rediseño organizativo. La herramienta es la misma — Claude, principalmente, con Cursor o Copilot en el IDE. Lo que cambia es cómo el equipo se relaciona con la herramienta.
La cita honesta que cierra la conversación
«Los agentes aún no son suficientemente fiables para ingeniería compleja.»
— Andrej Karpathy
Quien lo dice no es un escéptico anti-IA. Es uno de los ingenieros de IA más respetados del mundo. La conclusión operativa no es «no uses IA». Es: úsala con método.
Y el método no se compra. Se diseña, se instala en el equipo, se mantiene. Las cinco dimensiones organizativas que describí arriba — carriles, métricas, gobernanza de gates, formación dual, sostenimiento — son ese método. Y son lo que el 30% del problema técnico resuelto por Copilot, Cursor o el modelo del trimestre nunca va a cubrir.
Si en tu próximo comité técnico la conversación es «no vemos retorno con la IA, ¿qué herramienta compramos ahora?», tienes el diagnóstico equivocado. El retorno no va a venir de la herramienta — va a venir del método con el que tu organización opera con ella.
Hemos preparado cuatro preguntas para tu próximo comité que distinguen problema técnico de problema organizativo en menos de diez minutos. Una página A4, sin email obligatorio:
→ Descarga las 4 preguntas para tu próximo comité
Si las cuatro respuestas te dejan incómodo, hablemos: info@onext.es — asunto «auditoría organizativa IA». Conversación de 30 minutos sin compromiso.
Fuentes: estudio METR sobre productividad de developers con herramientas IA (paradoja +20%/−19%); Gartner sobre cancelación de proyectos basados en agentes antes de 2027; declaraciones públicas de Andrej Karpathy sobre fiabilidad de agentes en ingeniería compleja.
Lectura complementaria: El mes 6: el sistema de sostenimiento que lo previene · Los 3 claims canónicos del AI Engine