La mayoría de los debates sobre la IA en ingeniería se centran en las herramientas: qué asistente de código adoptar, cómo automatizar la generación de tests o cómo es en la práctica el soporte a la documentación. Las decisiones de producto suelen acaparar la atención, mientras que las estructurales quedan de lado.
Eso genera un problema de negocio. Muchas organizaciones están invirtiendo en IA pero dejan el modelo operativo sin cambios: los desarrolladores pueden avanzar más rápido a nivel individual, pero el negocio sigue pagando los mismos traspasos, los mismos bucles de coordinación, los mismos retrasos de aprobación y la misma falta de claridad en la propiedad. McKinsey descubrió que el uso habitual de la IA ya está muy extendido, con el 88 % de las organizaciones usa IA en al menos una función de negocio, pero solo el 39 % declara impacto en el EBIT a nivel de toda la empresa. Esto es útil porque muestra la brecha entre adopción y valor.
Entonces, ¿qué está causando esta brecha? El cambio real no tiene que ver con las herramientas, sino con cómo se organiza el trabajo. A medida que la IA pasa de la asistencia a la ejecución, el tamaño del equipo, los límites de propiedad, las estructuras de coste y el ritmo de entrega evolucionan juntos.
Añadir IA a una estructura de equipo sin cambios produce una mejora incremental. Cambiar la estructura es lo que genera un caso de negocio diferente.
Para los equipos de ingeniería, la pregunta suele ser si la IA puede aumentar la productividad de los desarrolladores. Para los líderes de negocio, la mejor pregunta es si la IA puede reducir el coste y el tiempo necesarios para convertir las decisiones de producto en software funcional.
Esa distinción importa. Una mejora del 20 % en la productividad individual de un desarrollador no se convierte automáticamente en una mejora del 20 % en la entrega de producto. Si el trabajo sigue esperando traspasos funcionales, dependencias de sprint, colas de revisión o una propiedad poco clara, el sistema absorbe la ganancia.
El coste de ese sistema ya es considerable. La investigación de Atlassian sobre la experiencia del desarrollador descubrió que el 69 % de los desarrolladores pierde ocho horas o más cada semana por ineficiencias. Es aproximadamente una jornada laboral, o una quinta parte de su tiempo, dedicada a la fricción en lugar del avance del producto.
Aquí es donde empieza el caso de negocio. El valor de la ingeniería agéntica no es simplemente que los ingenieros escriban código más rápido. Es que las organizaciones pueden reducir el retraso entre identificar una oportunidad de producto y validarla en producción.
Eso afecta a varias métricas de negocio:
Salida al mercado más rápida para nuevas funcionalidades y productos digitales.
Menor costo de retraso cuando cambian las necesidades del mercado, de los clientes o las normativas.
Mejor aprovechamiento de los ingenieros sénior, que dedican más tiempo a dirigir y validar el trabajo en lugar de producir manualmente cada detalle de implementación.
Mayor capacidad sin un crecimiento proporcional de la plantilla.
Mayor claridad en la responsabilidad sobre los resultados, porque la propiedad se acerca más al flujo de valor completo.
El objetivo no es sustituir el criterio de ingeniería. El objetivo es dejar de usar capacidad humana costosa para trabajo que una capa de agentes puede ejecutar, verificar y repetir bajo supervisión humana.
Jeff Bezos introdujo la regla de las dos pizzas en Amazon mientras la empresa buscaba cómo preservar la velocidad y la responsabilidad a medida que crecía. El principio era simple: los equipos debían mantenerse lo bastante pequeños como para evitar los costes de comunicación y toma de decisiones que aumentan con la plantilla. En la práctica, esto solía significar grupos autónomos de entre cinco y diez personas, es decir, el número de personas que puedes alimentar con dos pizzas.
El tamaño del equipo era solo parte de la idea. Los equipos de dos pizzas recibían la responsabilidad de un producto o servicio definido, con las habilidades necesarias para construirlo, operarlo y mejorarlo integradas dentro del grupo. En lugar de pasar el trabajo entre departamentos separados de desarrollo, testing y operaciones, el equipo podía asumir una carga de trabajo de principio a fin. Esto encajaba con la dirección más amplia de la transformación ágil y DevOps: equipos más pequeños, ciclos de feedback más cortos y una responsabilidad situada más cerca del cliente.
Esto supuso una mejora significativa respecto a las estructuras de proyecto tradicionales. Integrar la ingeniería frontend y backend, QA, operaciones y la dirección de producto en un solo equipo redujo las dependencias de funciones centrales. Las decisiones podían tomarse más cerca del trabajo, y los equipos podían lanzar y aprender sin coordinar cada cambio en toda una organización grande.
Sin embargo, el modelo seguía dependiendo de que varios especialistas colaboraran para hacer avanzar un área de producto. El trabajo pasaba entre roles dentro del equipo, aunque ya no pasara entre departamentos. El desarrollo frontend, el desarrollo backend, el testing, la infraestructura y la gestión de producto seguían siendo áreas de responsabilidad distintas.
Esa división interna del trabajo limitaba cuánto podía reducirse y agilizarse el equipo. Cada especialidad adicional introducía una nueva dependencia, mientras que la responsabilidad del resultado final seguía repartida entre todo el grupo. Cuando la entrega se ralentizaba, la causa podía estar en cualquier punto de una cadena de decisiones, revisiones y traspasos.
Durante aproximadamente dos décadas de transformación ágil, el equipo de dos pizzas ofreció una respuesta práctica a los problemas de coordinación que generaban las organizaciones grandes y separadas por funciones. La ingeniería agéntica cambia ahora la economía subyacente de esa respuesta. Cuando la IA puede realizar más trabajo de ejecución en código, testing, documentación e infraestructura, un producto ya no necesita el mismo número de especialistas para avanzar.
El siguiente paso, por tanto, no es simplemente un equipo de dos pizzas más productivo, sino un equipo más pequeño construido en torno a una propiedad de producto más amplia.
El modelo de dos pizzas se apoyaba en una premisa: la ejecución requería múltiples roles especializados. Un solo ingeniero no podía ser dueño de todo el stack, escribir los tests, gestionar la infraestructura y mantener la documentación al día al mismo tiempo, así que la especialización existía porque la amplitud resultaba costosa.
La IA cambia esa premisa. El código, los tests, la documentación, el refactoring y el andamiaje de workflows pueden generarse en paralelo. El trabajo de ingeniería repetitivo que antes requería plantilla dedicada puede automatizarse. El coste de cambiar de contexto entre dominios se reduce para un ingeniero que dirige en lugar de escribir cada línea manualmente.
Esto cambia la restricción de una forma concreta. El cuello de botella ya no es la capacidad de ejecución, sino la calidad de la dirección: la capacidad de definir qué construir con suficiente precisión para que los agentes puedan ejecutarlo, validar que el resultado es correcto y decidir qué se lanza.
Por eso el caso de negocio depende del cambio del modelo operativo. Si la IA se usa solo dentro de la estructura existente, la organización obtiene tareas completadas más rápido. Si la IA cambia la propiedad y el flujo de entrega, la organización obtiene un avance de producto más rápido.
Cuando la ejecución deja de ser la restricción, cambia la lógica detrás del tamaño del equipo. Lo que surge no es una versión más pequeña del equipo de dos pizzas, sino un modelo diferente con un nombre diferente: el equipo de una pizza.
De dos a tres creadores de producto sustituyen a un equipo funcional de entre seis y ocho personas. Cada creador de producto es dueño de un flujo de valor completo en lugar de una porción funcional, y una capa de agentes se encarga de la ejecución: generación de código, creación de tests, refactoring, documentación y andamiaje de workflows.
Los creadores de producto nativos de IA no solo usan agentes. Los orquestan.
La diferencia estructural se ve en cómo se entrega el valor. En el modelo de dos pizzas, la entrega de valor es colectiva y difusa, con la responsabilidad repartida entre funciones. En el modelo de una pizza, la entrega de valor es individual y rastreable, y cada creador de producto responde por la entrega en lugar de por completar una tarea dentro de una cadena.
Para el negocio, esto crea una unidad de medida diferente. En lugar de preguntar cuántos desarrolladores están asignados a un área de producto, los líderes pueden preguntar cuánto avance de producto validado puede generar cada creador de producto con el apoyo de una capa de agentes. Es una medida de retorno más útil porque conecta la capacidad de ingeniería con el rendimiento del negocio.
El retorno de la ingeniería agéntica proviene de varias ganancias que se combinan cuando cambia el modelo operativo:
Este es el caso de negocio que importa. La ingeniería agéntica debería medirse por si la misma inversión produce más avance de producto validado, no solo por el uso de herramientas.
A medida que los agentes asumen más trabajo de ejecución, el reto pasa de producir código a controlar cómo se realiza ese trabajo. Las organizaciones necesitan saber qué se les permite hacer a los agentes, a qué sistemas y datos pueden acceder, cómo se revisan sus resultados y quién sigue siendo responsable del resultado final.
Esto requiere un modelo de gobernanza diseñado específicamente para la ingeniería agéntica. Como mínimo, las organizaciones necesitan controles claros para los permisos de los agentes, el acceso a datos, la selección de modelos, el testing, la aprobación humana, la monitorización y la auditabilidad. Estos controles deben integrarse en el proceso de entrega, no añadirse después de que los agentes ya estén desplegados.
Sin esta base, los agentes pueden aumentar el volumen y la velocidad de producción, pero también los riesgos de seguridad, calidad y cumplimiento normativo. Se puede generar más código, pero los defectos, los estándares inconsistentes y los errores de lógica de negocio también pueden avanzar más rápido por el sistema de entrega.
Una plataforma de ingeniería agéntica ayuda a abordar esto al ofrecer un entorno gobernado en el que los agentes pueden configurarse, monitorizarse y mejorarse. Da a los líderes de ingeniería una forma coherente de gestionar el acceso, aplicar políticas de seguridad, evaluar la calidad de los resultados y mantener visibilidad sobre workflows de agentes en paralelo.
Aquí es también donde cambia el rol del ingeniero. Los ingenieros pasan de completar ellos mismos cada tarea de implementación a definir el alcance, supervisar la ejecución, revisar los resultados críticos y decidir qué está listo para lanzarse. Cuanto más fuerte se vuelve la capa de agentes, más importantes son estos controles y responsabilidades.
El objetivo no es simplemente dejar que los agentes hagan más. Es crear un sistema de entrega en el que puedan operar a gran velocidad sin debilitar la seguridad, la calidad o la responsabilidad.
El atractivo de las primeras etapas está claro. En un estudio controlado de Microsoft/GitHub, los desarrolladores que usaban GitHub Copilot completaron una tarea de programación un 55,8 % más rápido que quienes no lo usaban. Para la ejecución de tareas individuales, la ganancia puede ser considerable.
Pero la velocidad en las tareas no es lo mismo que la velocidad de entrega. Un desarrollador más rápido sigue trabajando dentro del mismo sistema de producto. Si después el trabajo espera revisión, QA, soporte de infraestructura, aclaraciones de producto o coordinación de lanzamiento, gran parte de la ganancia individual se diluye antes de llegar al cliente.
Por eso la adopción de la IA debe entenderse como una curva de madurez, no como el despliegue de una herramienta. No todas las organizaciones que adoptan IA llegan a este modelo, y los resultados dependen de hasta dónde llega la adopción y de si el modelo operativo cambia junto con ella. Existe una progresión clara que se divide en dos categorías fundamentalmente distintas.
El salto de lo basado en chat a lo basado en agentes es donde cambia el modelo. La adopción basada en chat mejora la productividad individual dentro de la estructura existente. La adopción basada en agentes cambia la estructura.
La mayoría de las organizaciones chocan con un límite de eficiencia porque se quedan en las etapas basadas en chat. Las herramientas mejoran, pero el modelo operativo sigue igual. El negocio ve entonces ganancias parciales, mientras que el caso de inversión más amplio queda sin materializarse.
El patrón en las organizaciones que ven ganancias limitadas es constante: se añade IA a los workflows existentes, mientras que las estructuras de equipo, los roles y los silos funcionales permanecen sin cambios.
Los ingenieros individuales pueden completar tareas más rápido, y el rendimiento general del equipo puede mejorar. Pero la misma sobrecarga de coordinación permanece. El trabajo sigue pasando por traspasos, colas de revisión y áreas de propiedad separadas antes de llegar a producción.
Por eso a muchos programas de IA les cuesta demostrar un retorno de negocio claro. Las organizaciones miden la adopción de herramientas o la productividad individual, pero no cambian el modelo de entrega que determina la rapidez con la que el trabajo pasa de la idea a la producción.
Desbloquear las mayores ganancias de eficiencia de la ingeniería agéntica requiere más que dar a los ingenieros mejores herramientas. Significa rediseñar los equipos en torno a creadores de producto con una propiedad más amplia, integrar agentes en el proceso de entrega y adaptar los workflows, controles y medidas de éxito que los rodean.
Sin esos cambios estructurales, la IA puede acelerar tareas individuales sin cambiar de forma significativa el coste o la velocidad de la entrega de producto.
Superar ese límite requiere decisiones deliberadas sobre la estructura, no más inversión en tecnología.
Esto es coherente con lo que hacen de forma diferente las organizaciones de alto rendimiento en IA. La encuesta de McKinsey sobre IA de 2025 descubrió que estas organizaciones tienen casi el triple de probabilidades que las demás de rediseñar sus workflows de forma fundamental. Dicho de otro modo, las organizaciones que obtienen valor no se limitan a añadir IA a los procesos existentes. Están cambiando los propios procesos.
La propiedad tiene que pasar de tareas basadas en roles a la responsabilidad sobre el flujo de valor. Un ingeniero backend responsable de sus tickets no es lo mismo que un creador de producto responsable de que una funcionalidad se lance y funcione correctamente. El alcance es distinto, la medición es distinta y los incentivos son distintos.
La estructura del equipo tiene que reducir las dependencias funcionales, no solo el tamaño del equipo. Reducir un equipo de ocho a cinco personas manteniendo los mismos roles funcionales conserva la sobrecarga de coordinación que limitaba el modelo original. Fusionar esos roles en una propiedad más amplia es el cambio que realmente importa.
La capa de agentes tiene que ser una parte central de la entrega, no una herramienta opcional a discreción de cada ingeniero. Las organizaciones que tratan la orquestación como una preferencia del desarrollador, en lugar de como una capacidad de entrega, no verán el beneficio estructural.
La medición tiene que seguir el mismo camino. La velocidad de entrega por creador de producto, el tiempo de ciclo de iteración, el coste por funcionalidad lanzada, la tasa de retrabajo, los defectos que llegan a producción y el tiempo desde la idea hasta la producción son señales más relevantes que los story points o las líneas de código. Las métricas de ingeniería tradicionales asumen una relación lineal entre plantilla y producción. La entrega agéntica no.
Cuando el modelo operativo cambia junto con la tecnología, los resultados deberían ser medibles. El tamaño del equipo por área de producto puede reducirse. La velocidad de entrega por creador de producto puede aumentar. Los ciclos de iteración pueden acortarse a medida que se eliminan las dependencias funcionales. La responsabilidad se vuelve más clara porque la propiedad es directa.
Ya hay evidencia de que las mayores ganancias provienen de organizaciones que cambian el modelo de desarrollo, no solo las herramientas. El análisis de McKinsey sobre casi 300 empresas cotizadas descubrió que las organizaciones líderes están logrando mejoras del 16-30 % en productividad, time to market y experiencia de cliente, junto con ganancias del 31-45 % en calidad del software. El patrón común no es la simple adopción de herramientas. Es una integración más profunda de la IA en todo el ciclo de vida del desarrollo de software, respaldada por cambios en los roles, los workflows y la medición.
La afirmación más fuerte no es que todas las organizaciones vayan a lograr la misma ganancia porcentual. El argumento de negocio más sólido es que cambia la economía de la entrega. La productividad ya no es lineal respecto al tamaño del equipo. La capacidad ya no es solo una cuestión de contratación. La inversión en IA ya no se justifica por la adopción individual de los desarrolladores, sino por si el sistema de entrega puede convertir la ejecución de los agentes en un avance de producto más rápido y seguro.
Esa es la diferencia práctica entre la IA como herramienta y la IA como parte de la estructura de entrega.
Este cambio no ocurre por adoptar las herramientas adecuadas. Requiere decisiones organizativas deliberadas que están por encima del stack tecnológico.
Los líderes tienen que redefinir qué es un equipo. El modelo de dos pizzas fue una heurística útil durante dos décadas de transformación ágil, cuando entregar software todavía dependía de que varios especialistas trabajaran juntos dentro de un equipo autónomo. La ingeniería agéntica cambia esa ecuación al permitir que los creadores de producto dirijan la ejecución en código, testing, documentación e infraestructura con el apoyo de una capa de agentes.
El perfil de contratación de un creador de producto que orquesta workflows de agentes y es dueño de un flujo de valor completo es, por tanto, distinto del de un especialista dueño de un dominio funcional. Ambos siguen siendo valiosos, pero responden a modelos de entrega diferentes y no son intercambiables.
Los líderes también tienen que tratar la capacidad de orquestación como infraestructura, no como desarrollo profesional. Esto significa invertir en una plataforma de ingeniería agéntica que ofrezca una forma coherente de definir el alcance de los agentes, controlar el acceso a sistemas y datos, aplicar políticas de seguridad, monitorizar la actividad y revisar los resultados antes de que lleguen a producción.
Sin esa base compartida, la orquestación sigue dependiendo de las prácticas individuales de trabajo y se vuelve difícil de gobernar a escala. Con ella, las organizaciones pueden aplicar los mismos estándares de seguridad, calidad y responsabilidad en todos los equipos, a la vez que dan a los creadores de producto la libertad de dirigir los workflows de agentes de forma eficaz.
El objetivo no es usar más IA. Es construir un sistema de entrega en el que los agentes puedan ejecutar de forma eficaz y los creadores de producto puedan dirigir esa ejecución con precisión. Las organizaciones que hacen ese cambio pueden reducir los costes de coordinación, acortar los ciclos de producto y aprovechar mejor una capacidad de ingeniería escasa.
Las organizaciones que tratan la ingeniería agéntica como una decisión de herramientas obtendrán una ejecución más rápida. Las que rediseñan el modelo de entrega en torno a ella cambiarán la economía del desarrollo de software.