El 1 de octubre de 2026, David Pralong, socio sénior de McKinsey, escribió en Fortune que los éxitos más citados de la IA engañan a los consejeros delegados. Entre sus ejemplos estaban los equipos de software, y el motivo es incómodo: esos equipos ya tenían algo antes de que llegaran los modelos.
Lo que tenían, según Pralong, eran «prácticas de testing, integración continua y revisión de código» que hacían posible aprovechar la IA. Y añade que esos casos son «un punto de partida, no una plantilla» que se pueda trasladar a cualquier empresa.
De ahí sale la tesis de esta pieza: para implantar IA en un equipo de desarrollo, el primer paso no es elegir el agente, sino revisar la red que detecta los errores. Si el equipo no puede comprobar lo que entra, un agente produce más código del que nadie puede verificar.
Por qué la herramienta no es la primera pregunta
DORA, el programa de investigación de Google sobre equipos de software, lo resume en su informe de 2025 sobre desarrollo asistido por IA: el papel principal de la IA es el de un amplificador, que magnifica las fortalezas y las debilidades que la organización ya tiene. Un equipo que integra a diario y revierte sin drama gana velocidad. Un equipo que despliega con miedo despliega más rápido con el mismo miedo.
En septiembre de 2025, DORA publicó un modelo con siete capacidades que, según su análisis, amplifican o desbloquean los beneficios de la IA. Tres son de datos y plataforma, una es de foco en el usuario y otra es tener una postura clara sobre la IA. Las otras dos son exactamente la red de la que habla Pralong:
Sobre la primera, DORA escribe que, a medida que la IA aumenta la velocidad de los cambios, el control de versiones se convierte en una red de seguridad crítica, y recomienda que los equipos dominen las funciones de revertir. Sobre la segunda, que trabajar en lotes pequeños es «especialmente potente» en un entorno asistido por IA.
Un agente no trae calidad: trae volumen. La calidad la pone la red que el equipo ya tiene para comprobar cada cambio.
La red, pieza a pieza
Estas son las piezas que conviene mirar antes de dar un agente a un equipo. Ninguna es nueva; lo que cambia es cuánto pesan cuando el ritmo de cambios sube.
| Pieza de la red | Qué detecta o evita | Pregunta para tu equipo |
|---|---|---|
| Tests en los que el equipo confía | Que un cambio rompa algo que ya funcionaba | ¿Cuando un test falla, alguien lo investiga o se reintenta hasta que pasa? |
| Integración continua | Que el cambio solo funcione en la máquina de quien lo hizo | ¿Cada cambio pasa por la misma batería antes de mezclarse? |
| Cambios pequeños | Que una revisión sea imposible porque el cambio es enorme | ¿Cuánto tarda en revisarse un cambio típico, y cuántas líneas tiene? |
| Control de versiones y revertir | Que un error cueste horas en vez de minutos | ¿Cuándo fue la última vez que revertisteis algo, y cuánto tardasteis? |
| Revisión con criterio | Que entre código que nadie entiende | ¿La revisión comprueba qué hace el cambio y por qué, o solo el estilo? |
| Criterios de aceptación escritos | Que el código cumpla lo pedido pero no lo que se necesitaba | ¿Antes de empezar, está escrito cómo se sabrá que el trabajo está bien? |
Las cinco primeras piezas salen de Pralong (McKinsey) y del modelo de DORA; la sexta y las preguntas son lectura propia de onext
La revisión es la pieza que más cambia: cuando el autor es un agente, la revisión ya no puede dar por hecho que hay alguien que sabe por qué se escribió cada línea. Lo contamos en revisar código generado por IA. Y los criterios de aceptación pueden convertirse en la condición para integrar el cambio, como explicamos en tu spec ya es un eval; es la base del desarrollo guiado por especificaciones (Spec-Driven Development, SDD), que resumimos en qué es SDD y cómo mantiene el código controlado.
Lo que dice el dato de productividad, y lo que no
El estudio más citado sobre asistentes de código en empresas reales es el de Cui, Demirer, Jaffe, Musolff, Peng y Salz (Microsoft Research, junio de 2025). Combina tres experimentos aleatorizados en Microsoft, Accenture y una empresa anónima de la lista Fortune 100, con 4.867 desarrolladores: los que tenían acceso al asistente completaron un 26,08 % más de tareas, con un error estándar del 10,3 %. Los desarrolladores con menos experiencia lo adoptaron más y ganaron más.
Límite Es una media de tres grandes empresas, con un margen de error amplio, y el estudio no describe cómo era la red de cada equipo. No demuestra que sin tests ni integración continua no haya ganancia. Lo que no se puede hacer es tomar ese 26 % como promesa para tu equipo: la única cifra que vale es la que midas tú, antes y después.
Lo que sí es razonable leer junto a Pralong y DORA: las ganancias que cita Pralong aparecen en equipos que ya sabían comprobar y deshacer sus cambios. Y sin esa red, aunque el equipo vaya más rápido, nadie puede saber si va mejor.
El orden que proponemos
Implantar IA no exige parar el equipo ni reescribir su forma de trabajar de golpe. Exige un orden:
- Revisa la red con un equipo piloto. Las seis preguntas de la tabla, con datos del propio equipo, no con opiniones.
- Arregla el agujero más grande. Si los tests no son fiables o los cambios son enormes, eso va antes que cualquier licencia.
- Mide la línea base. Cuánto tarda hoy un cambio en llegar a producción y cuántos se revierten. Sin ese dato, después no sabrás qué ha cambiado.
- Introduce el agente sobre trabajo ya planificado. En paralelo al sprint del equipo, con permisos acotados y la revisión de siempre.
- Compara y decide si se amplía. Con tus datos, no con los de un estudio.
Este orden no niega que la adopción también es organizativa, como contamos en el éxito de la IA en equipos de desarrollo es organizativo, ni que hay que mirar personas, procesos, herramientas e indicadores a la vez, como en las cuatro perspectivas de un equipo de desarrollo con IA. Esta pieza responde a una pregunta más estrecha: qué va primero. Y cuando el agente ya está dentro, las reglas que tiene que cumplir no van en un texto que el modelo puede ignorar, sino en controles que se aplican solos, como explicamos en Claude Code para equipos: contexto no es control.
Dónde encaja onext
Si estás pensando en cómo implantar IA en tu equipo de desarrollo, el primer paso de AI-Accelerated Development es un diagnóstico gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Cuando hay Quick-start, no hace falta parar las entregas: trabaja con un equipo piloto, sobre trabajo real ya planificado y en paralelo a su sprint. Y en el proceso, una persona decide donde hay riesgo.
Si prefieres empezar por tu cuenta, el autodiagnóstico de 16 preguntas te da una primera foto de dónde está tu equipo.
Elige un cambio pequeño que saliera mal en los últimos meses. Pregunta en qué punto lo detectaría hoy tu equipo y cuánto tardaría en deshacerlo. Si la respuesta es «en producción» y «no lo sabemos», ya sabes por dónde empezar, y no es por el agente.
Preguntas frecuentes
¿Qué es «la red» de un equipo de desarrollo?
Es el conjunto de prácticas que detectan un error antes de que llegue a producción o permiten deshacerlo rápido: tests en los que el equipo confía, integración continua, cambios pequeños, control de versiones con la costumbre de revertir y una revisión del código con criterio. No es una herramienta: es cómo trabaja el equipo.
¿Por qué revisar la red antes de comprar licencias o agentes?
Porque la IA acelera lo que ya hay. El informe de DORA de 2025 la describe como un amplificador de las fortalezas y las debilidades de cada organización. Si el equipo no tiene cómo comprobar lo que entra, un agente produce más código del que nadie puede verificar.
¿Sin tests ni integración continua la IA no sirve de nada?
No hay datos para afirmar eso. Lo que sí dice McKinsey, en la pieza de David Pralong en Fortune, es que los equipos de software que lograron ganancias ya tenían prácticas de testing, integración continua y revisión de código. La ganancia observada venía con red; sin ella, nadie sabe si un cambio rápido es también un cambio bueno.
¿Cuánto mejora la productividad un asistente de código?
Un estudio con 4.867 desarrolladores de Microsoft, Accenture y una empresa de la lista Fortune 100 midió un 26,08 % más de tareas completadas, con un error estándar del 10,3 %. Es una media de tres grandes empresas, no una promesa para la tuya: la forma de saberlo es medirlo en tu equipo, antes y después.
¿Hay que parar las entregas para preparar la red?
No. Lo razonable es empezar con un equipo piloto, sobre trabajo que ya estaba planificado y en paralelo a su sprint, arreglar primero el agujero más grande de la red y medir antes de ampliar.
¿Cómo sé si mi equipo tiene la red preparada?
Con una prueba sencilla: elige un cambio pequeño que haya salido mal en los últimos meses y pregunta en qué punto se habría detectado hoy (un test, la integración continua o la revisión) y cuánto se tardaría en deshacerlo. Si la respuesta es «en producción» y «no lo sabemos», ese es el primer trabajo, antes del agente.
Fuentes
- David Pralong (McKinsey), «McKinsey senior partner: Why AI's easiest wins are misleading CEOs», Fortune, 1 de octubre de 2026.
- Kevin M. Storer y Derek DeBellis (Google Cloud), «Introducing the DORA AI Capabilities Model: 7 keys to succeeding in AI-assisted software development», 23 de septiembre de 2025.
- DORA, «State of AI-assisted Software Development 2025» (consultado el 13 de octubre de 2026).
- Zheyuan (Kevin) Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng y Tobias Salz, «The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers», Microsoft Research, junio de 2025.
- Las citas de fuentes en inglés están traducidas por onext. La tabla de preguntas, el orden propuesto y la prueba final son lectura propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →