Después de un año escribiendo sobre lo que se rompe cuando la IA entra en organizaciones de ingeniería, puedo nombrar el hilo conductor que conecta cada fracaso y cada éxito: si la organización preservó el juicio mientras cambiaba la forma en que se realiza el trabajo.

Modelado de amenazas, gobernanza, desarrollo basado en especificaciones, revisiones de arquitectura, problemas de medición, el papel en evolución del CTO. Cada publicación abordaba un modo de fallo específico o una práctica concreta. Pero la estructura que hay debajo es un solo modelo, y nunca le había dado nombre explícitamente hasta ahora.

Una organización de ingeniería impulsada por IA tiene cuatro capas. Cada fallo que he documentado se relaciona con una ruptura en una de estas capas. Cada éxito que he visto implica que al menos tres de ellos sean correctos simultáneamente.

Por qué se rompen los modelos tradicionales

La mayoría de las organizaciones de ingeniería se diseñaron bajo una única suposición: los humanos escriben código, los humanos revisan código, los humanos despliegan código, los humanos arreglan código. Cada proceso, cada puesto, cada métrica, cada trayectoria profesional se construyó sobre esa suposición.

La IA no añadió simplemente una herramienta a este sistema. Cambió la restricción fundamental: la generación de código ya no es el cuello de botella, sino la definición de intención, la validación y el juicio arquitectónico.

Ese único cambio explica los fallos en la gobernanza, la brecha en la revisión de arquitectura, la disrupción del talento y la crisis de medición. Cada uno de esos problemas se remonta a que las organizaciones optimizan para un cuello de botella que ya no existe.

La investigación de McKinsey sobre organizaciones agentes (mayo de 2026) nombra la tensión con precisión: «La mayoría de los modelos operativos empresariales asumen que los humanos permanecen firmemente en el centro mientras inician, deciden y escalan. La IA agente trastoca esa premisa.» El Foro Económico Mundial lo expresa de forma más directa: «A diferencia de los humanos, los agentes autónomos carecen de restricciones operativas implícitas, lo que requiere que las organizaciones suministren gobernanza y límites externamente.»

El resultado es lo que veo en cada interacción: organizaciones que superponen IA sobre estructuras diseñadas para la ejecución solo humana, y luego se preguntan por qué los resultados son caóticos.

El modelo de cuatro capas es como se ve esa reimaginación.

Capa 1: Realidad tecnológica

Este es el entorno en el que opera tu organización, lo hayas elegido o no.

Los agentes de codificación con IA reducen la deuda técnica a nivel de código pero generan lo que Gartner denomina un «enorme aumento de la deuda técnica arquitectónica.» Para 2027, Gartner predice que el 65% de los equipos de ingeniería que usan codificación agentica tratarán los IDE como opcionales, trasladando el control a plataformas automatizadas. Los ataques a la cadena de suministro ahora se dirigen a las propias herramientas de IA: cinco vectores de ataque distintos en tres meses, desde dependencias hasta infraestructuras y el propio tiempo de ejecución del agente de codificación.

La capa de realidad tecnológica consiste en entender qué cambian las herramientas en tu superficie de riesgo, tu estructura de costes y tu posición competitiva. Las organizaciones que tratan esta capa como «adoptamos Copilot» operan con un mapa parcial.

Qué se ve bien: Un cliente de servicios financieros con el que trabajo mantiene un registro activo de cada herramienta de IA en su entorno, no solo el nombre y el proveedor, sino también los datos a los que accede cada herramienta, qué permisos posee, qué ocurre con su código tras la entrega y qué cambia si el proveedor modifica precios o condiciones. Cuando GitHub anunció el cambio a la facturación basada en el uso en junio, tenían una proyección de costes lista en 48 horas porque la dependencia ya estaba mapeada. El hallazgo de Gartner de que una gobernanza uniforme entre agentes de IA conduce al fracaso significa que esta capa requiere ese tipo de evaluación diferenciada, no políticas generales.

El anti-patrón aquí es el delegador pasivo de The CTO’s Real Job When AI Changes How Software Gets Build: el CTO que permite que la dependencia de los proveedores crezca sin control, que no gobierna las herramientas que ahora median el 75% de la generación de código en empresas como Google.

Capa 2: Ciclo de vida del desarrollo impulsado por IA

Así es como cambia la creación de software cuando la IA se encarga de la generación y los humanos del juicio.

El informe DORA 2025, que encuestó a casi 5.000 profesionales de la tecnología, concluyó que «el papel principal de la IA en el desarrollo de software es el de amplificador. Magnifica las fortalezas de las organizaciones de alto rendimiento y las disfunciones de las que están en dificultades.» Los mayores retornos de la inversión en IA no provienen de las herramientas en sí, sino del sistema organizativo que hay por dentro.

Thoughtworks ha puesto el desarrollo basado en especificaciones en su Technology Radar este año, nombrando OpenSpec y GitHub SpecKit como frameworks. Su análisis de macrotendencias (abril de 2026) lo describe como «una extensión o evolución del desarrollo basado en especificaciones; barreras de seguridad y flujos de trabajo estructurados.» La comunidad llegó a la misma conclusión de forma independiente: necesitas una capa de especificación entre la intención humana y la generación de IA.

La cifra del 75% de Google es instructiva no por la cifra, sino por lo que la hace funcionar. Sundar Pichai reveló en Cloud Next 2026 que el 75% de todo el código nuevo en Google es generado por IA y revisado por ingenieros. La cifra pasó del 25% en octubre de 2024 al 50% a finales de 2025 y al 75% a principios de 2026. Funciona porque Google tiene décadas de cultura de revisión de código, infraestructura de pruebas y prácticas de desarrollo estructuradas debajo. El 75% es la salida de un sistema, no del sistema en sí — y demuestra exactamente cómo la Capa 2 depende de la Capa 3. La metodología funciona porque la infraestructura operativa la respalda.

Solo el 35% de los líderes de ingeniería de software reportan un ROI significativo de la IA en el SDLC, según Gartner. El otro 65% tiene las herramientas pero no la metodología.

Qué se ve bien: Intención antes de generación, validación antes que avance, gobernanza en todo momento. Un ciclo de vida estructurado donde el contexto de generación de la IA incluye modelos de dominio, decisiones arquitectónicas, líneas de seguridad y restricciones de cumplimiento, no solo un prompt y buenas intenciones. Las organizaciones están convergiendo en esto de forma independiente, ya sea a través de marcos de desarrollo impulsados por especificaciones como OpenSpec y SpecKit, flujos de trabajo internos estructurados o enfoques como los DLC de IA que formalizan todo el ciclo de vida. La evidencia del taller de los equipos con los que he trabajado muestra el principio de forma consistente: 9,7/10 de satisfacción, 41% eligiendo el ritual humano colaborativo como el más valioso por encima de la generación de código con IA (24%). El cuello de botella nunca fue la generación de código. Era la definición de la intención.

El anti-patrón aquí es el programador de vibra: el CTO que usa herramientas de IA personalmente pero nunca construye el marco organizativo para que los demás las utilicen bien.

Capa 3: Modelo operativo y organizativo

Así es como las organizaciones de ingeniería deben operar de forma diferente cuando la IA participa en la ejecución, no solo un asistente.

El libro de McKinsey «Seis cambios para construir la organización agente del futuro» (febrero de 2026) describe el alcance: reconfigurar flujos de trabajo, remodelar roles, habilidades, estructuras y sistemas. La investigación de Harvard Data Science Review (invierno de 2026) es más específica: «Para alcanzar el potencial de productividad del 2 al 10× de la IA basada en agentes, las empresas deben rediseñar los flujos de trabajo con agentes como actores principales, no solo como asistentes digitales.»

Los datos de DORA cuentan la historia operativa. La adopción de la IA ahora muestra una relación positiva con el rendimiento, pero sigue mostrando una relación negativa con la estabilidad. Los equipos lanzan más rápido y rompen más cosas. El Índice de Referencia de Ingeniería 2026 de Cortex cuantificó la brecha: las PRs por autor subieron un 20%, pero las tasas de fallo del cambio subieron un 30% y los incidentes por solicitud de consulta subieron un 23,5%. El modelo operativo debe absorber esta tensión, no ignorarla.

Gregor Hohpe escribió en The Software Architect Elevator que la automatización se trata «principalmente de repetibilidad y resiliencia», no solo de eficiencia. Ese principio se aplica directamente: el modelo operativo para organizaciones impulsadas por IA debe priorizar la repetibilidad (procesos estructurados que generan calidad constante) y la resiliencia (la capacidad de recuperación cuando la producción generada por IA falla en producción).

El libro Intelligent Continuous Security (2025) de Hornbeek mapea cinco topologías de equipo para IA y seguridad, y nombra el modo de fallo de cada una. Los equipos de plataforma para seguridad e IA se convierten en cuellos de botella cuando se centralizan demasiado. La experiencia en IA integrada en los equipos de entrega fragmenta la gobernanza. Los Centros de Excelencia pierden el contacto con los flujos de trabajo diarios. La topología híbrida funciona en teoría pero colapsa en confusión de roles sin un mapeo explícito de responsabilidades. En la práctica, los equipos que he visto triunfar utilizan una versión de ese híbrido: un equipo de plataforma delgada que se encarga de las barreras y herramientas, con profesionales integrados en cada equipo de entrega que los aplican. El equipo de plataforma gobierna, los profesionales integrados ejecutan, y ninguno funciona sin el otro.

Qué se ve bien: Revisiones de arquitectura que se ejecutan de forma continua en lugar de como eventos de cumplimiento puntuales. Puertas de calidad integradas en el proceso de generación en lugar de añadidas como revisión posterior. Gobernanza de costes que trata el consumo de tokens de IA como una métrica operativa de primera clase. Respuesta a incidentes que explica código generado por IA que nadie entiende del todo.

El anti-patrón aquí es el emisor del mandato: el CTO que establece objetivos de uso del 80% de la IA con tablas de clasificación, produciendo tokenmaxxing en lugar de resultados. El modelo operativo debe medir lo que produce el trabajo asistido por IA, no cuánto se consumió IA.

Capa 4: Modelo de liderazgo y talento

Así es como evoluciona el liderazgo y cómo se desarrolla el talento cuando la IA cambia lo que significa «experiencia».

La orientación de Gartner para los líderes de ingeniería de software es directa: «reestructurar su organización, proteger las habilidades fundamentales, cambiar hacia métricas de creatividad e implementar la gobernanza para controlar la IA en la sombra y la deuda técnica.» La investigación de McKinsey sobre la fuerza laboral (abril de 2026) reveló que dos tercios de las empresas con mejor rendimiento tienen líderes tecnológicos «muy implicados» en la elaboración de la estrategia empresarial, en comparación con el 52% de otras organizaciones.

La ironía de la automatización, descrita por primera vez por Lisanne Bainbridge en 1983, se está desarrollando ahora en la ingeniería de software. Su observación: «Cuanto más fiable sea la planta, menos oportunidades habrá para el operador de practicar la intervención directa, y más difíciles serán las exigencias de las tareas restantes que requieren intervención del operador.» Cuando la IA se encarga del trabajo rutinario que convierte a los ingenieros junior en ingenieros senior, el bucle de aprendizaje se rompe. Los fundamentos dejan de practicarse. Y cuando el sistema falla de una forma que la IA no puede manejar, puede que las habilidades para solucionarlo ya no existan en el equipo.

Architecting Enterprise AI Strategies (Harjika, 2026) describe la erosión del juicio desde el lado empresarial: «Los analistas junior aceptaron los resultados del modelo sin cuestionar, los equipos de diseño perdieron la confianza en su propia creatividad y las reuniones de decisión se convirtieron en recitaciones de resúmenes de IA en lugar de espacios de debate.» El libro presenta la solución como un mapeo del continuo de autonomía: «La empresa sabia identifica dónde la automatización mejora el juicio y dónde lo erosiona.»

La cuestión de la cadena de talento es urgente. Varios hilos de profesionales este mes convergen en la misma preocupación: ¿quiénes serán tus ingenieros senior dentro de cinco años si la IA corta el aprendizaje que los produce? Este es un problema de planificación de la plantilla, y solo la dirección puede solucionarlo.

Qué se ve bien: Trayectorias profesionales que premian la calidad del juicio, el pensamiento sistémico y la integración entre dominios en lugar del volumen de salida de código. Práctica deliberada integrada en el proceso de desarrollo de IA: rotaciones de depuración sin IA, repasos de revisión de arquitectura, explicaciones estructuradas posteriores a la revisión. Nuevos roles que no existían hace dos años: facilitadores de metodologías de IA, arquitectos de especificaciones, ingenieros de gobernanza. Métricas de la tabla que miden la calidad de pensamiento, no la velocidad de escritura.

Los anti-patrones aquí son el evitador de métricas y el optimizador de plantillas: el CTO, que no puede explicar el ROI de la IA al consejo, y el CTO, que trata la adopción de la IA como un ejercicio de reducción de plantilla sin proteger el conocimiento institucional que hace útil la producción de la IA.

Donde las capas entran en conflicto

Las capas crean tensiones reales. Están destinados a hacerlo. El error que cometen la mayoría de las organizaciones es asumir que todas estas capas pueden optimizarse simultáneamente. No pueden. El liderazgo en IA es cada vez más la disciplina de gestionar tensiones irreducibles.

Capa 1 vs Capa 2: Las herramientas cambian más rápido de lo que la metodología puede formalizar. Los equipos construyen flujos de trabajo estructurados alrededor de una generación de capacidades de IA, y luego la siguiente versión del modelo invalida las suposiciones. La metodología debe ser lo suficientemente independiente de las herramientas para sobrevivir a los cambios de proveedores y lo bastante específica para ser útil el lunes por la mañana.

Capa 1 vs Capa 3: La tecnología cambia más rápido de lo que el modelo operativo puede absorber. Cuando has reestructurado tu proceso de revisión para una generación de herramientas de IA, la siguiente generación ha cambiado de nuevo las limitaciones. El modelo operativo debe diseñarse para una adaptación continua, no para un estado final estable.

Capa 2 vs Capa 4: La metodología estructurada requiere que profesionales experimentados validen la producción de la IA. Pero el modelo de talento está bajo presión para reducir el número de empleados. No puedes ejecutar Mob Elaboration sin personas que entiendan el dominio lo suficiente como para desafiar las suposiciones de la IA. Cortar a esas personas para financiar herramientas de IA destruye la base de la metodología.

Capa 3 vs Capa 4: Las métricas de eficiencia operativa (tiempo de ciclo, frecuencia de despliegue) pueden entrar en conflicto con los objetivos de desarrollo del talento (práctica deliberada, aprendizaje). Si optimizas solo para la velocidad, eliminas la holgura que permite aprender. Si optimizas solo para el desarrollo, pierdes velocidad competitiva. El equilibrio es una decisión de liderazgo, no de proceso.

Estas tensiones no se resuelven, se gestionan. El modelo de cuatro capas hace visibles los compromisos para que los líderes puedan hacerlos deliberadamente en lugar de descubrirlos en producción.

La tesis, expresada de forma clara

Cada publicación que he escrito durante el último año corresponde a una de estas cuatro capas. Los lectores que han seguido la serie reconocerán dónde encaja cada pieza. Los puestos de gobernanza alimentan a las Capas 1 y 3, los puestos de metodología alimentan a la Capa 2, los puestos de liderazgo alimentan a la Capa 4, los puestos operativos alimentan a la Capa 3. Individualmente diagnosticaron problemas. Juntos describen un sistema.

El éxito con la IA requiere alinear las cuatro capas alrededor de un único principio: preservar el juicio humano mientras cambia la forma en que se realiza el trabajo.

El informe DORA 2025 valida esto a gran escala: la IA amplifica lo que ya tienes. Si tus cuatro capas están alineadas, la IA te acelera. Si están desalineados, la IA acelera la disfunción.

Los últimos datos de Gartner son la señal de puntuación: el 84% del gasto en IA empresarial se destina a casos de uso individuales de productividad, mientras que solo el 16% se destina a casos de uso que cambian sustancialmente los resultados empresariales. La productividad individual reside en la Capa 2. Los resultados empresariales requieren que las cuatro capas trabajen juntas.

Lo que esto significa para ti

Un equipo con el que trabajé el trimestre pasado tenía las cuatro capas desalineadas simultáneamente sin darse cuenta. Habían adoptado de forma agresiva herramientas de codificación por IA (conciencia de Capa 1: parcial), pero sin una metodología estructurada (Capa 2: ausente). Su proceso de revisión no había cambiado desde antes de la adopción de la IA (Capa 3: obsoleto). Y sus ingenieros senior estaban agotados revisando PRs generados por IA por desarrolladores junior que no podían explicar su propio código (Capa 4: erosión). El diagnóstico del CTO fue «necesitamos mejores herramientas de IA.» El diagnóstico real fue que tres capas fallaban y la cuarta lo enmascaraba.

Si eres CTO o líder de ingeniería, la pregunta de diagnóstico es: ¿cuál capa es tu más débil?

Si tu equipo tiene grandes herramientas pero ninguna metodología, la Capa 2 es tu carencia. Si tu equipo tiene metodología pero la estructura organizativa la resiste, la Capa 3 es tu vacío. Si tu equipo tiene todo pero el talento se está erosionando, la Capa 4 es tu vacío. Si ni siquiera sabes qué está cambiando la tecnología en tu superficie de riesgo, la Capa 1 es tu hueco.

El modelo de cuatro capas es una lente diagnóstica, no una evaluación de madurez ni un marco de certificación. Úsalo para encontrar dónde está fallando tu organización, luego corrige esa capa antes de añadir más IA al sistema.

Ninguna capa te salva. Las organizaciones con las que trabajo que están teniendo éxito no empezaron comprando mejores herramientas, contratando un CAIO ni imponiendo objetivos de adopción de IA. Empezaron preguntando: «¿Cómo debe ser nuestra organización para que la IA nos haga mejores en lugar de ser más rápidos para romperse?»

Esa pregunta vive en la intersección de las cuatro capas. Y la respuesta es un sistema, no un héroe.

Ricardo