Un CTO que conozco, aprobó el despliegue de una herramienta de codificación de IA que no entendía. La tecnología estaba a su alcance, no había tocado una en nueve meses, así que ya no sabía qué preguntas hacer. Se sentó a ver la demo del vendedor, asintió a la diapositiva de arquitectura, hizo una pregunta sobre precios y firmó. Tres meses después, su equipo afrontaba consecuencias que no había previsto, y aún no podía explicar qué preguntas no había planteado el proceso de implantación.

Cuando le pregunté qué preguntas le gustaría haber hecho, se detuvo durante un largo rato. «No sabía lo que no sabía. No lo había usado lo suficiente recientemente como para saber dónde están los modos de fallo.»

No es inusual. El CTO que se desvía de la práctica no pierde capacidad de la noche a la mañana. Sucede en trimestres, una decisión delegada a la vez, hasta que la distancia entre su juicio y la tecnología que su equipo usa cada día se convierte en un vacío que alguien más tiene que cubrir.

En el Estudio de CEO de IBM de 2026, el setenta y seis por ciento de los CEOs afirmó que sus organizaciones ahora cuentan con un Director de IA, frente al veintiséis por ciento del año anterior. El estudio encuestó a más de dos mil directores generales. El puesto es real, está creciendo, y en las organizaciones de ingeniería a menudo llena el vacío de juicio creado cuando el CTO se aleja de las herramientas.

Lo que escasea cuando la producción es abundante

Los últimos meses de datos han hecho visible algo. La IA hizo abundante la producción de software: la generación de código es más rápida, barata y accesible para más personas que en cualquier otro momento de la historia de la profesión. Escritos recientes aquí han rastreado esa abundancia a través de la paradoja de la productividad, el mito 5x, la deuda de comprensión y la economía de construir frente a poseer.

¿Qué se vuelve estratégicamente escaso una vez que la producción es abundante? La capacidad organizativa para mantener, gobernar y evolucionar lo que se construye. Juicio sobre qué construir, si hacerlo o no, cómo mantenerlo vivo después de que la emoción inicial se desvanezca y cuándo parar antes de que los costes de mantenimiento superen el valor producido. Ese juicio no proviene de la lectura de informes trimestrales. Proviene de la proximidad a la obra.

El trabajo del CTO cambió. Cuando la producción era la limitación, el trabajo era acelerarla. Ahora que la producción es abundante, el trabajo es gobernar lo que queda escaso: el juicio sobre qué conservar, qué matar y qué no construir en primer lugar. El CAIO suele entrar en la conversación de ingeniería cuando el CTO ha dejado de emitir ese juicio, independientemente de si el puesto tiene o no un mandato legítimo a nivel empresarial.

El foso de credibilidad

Escribo código todos los días. Construyo mis propias herramientas, mantengo mis propios servidores MCP, gestiono mis propias pipelines de automatización. El propósito es la credibilidad, no la productividad. Un CTO que construye a diario es más difícil de engañar con una demo porque la práctica sostenida le plantea preguntas que la demo no puede responder. Saben lo que significa «funciona en la puesta en escena» frente a lo que significa «sobrevive a tres meses de tráfico de producción». Saben qué atajos arquitectónicos oculta una demo de proveedor porque ellos mismos crearon esos atajos la semana pasada.

La deriva ocurre gradualmente. El trabajo técnico práctico pasa de ser una parte significativa de la semana laboral en el primer año a casi nada en el cuarto año, ya que las reuniones, la estrategia y la gestión organizativa ocupan el calendario. El Informe de Liderazgo en Ingeniería 2026 de LeadDev ofrece una señal más actual: el cuarenta y cuatro por ciento de los CTO o equivalentes informaron haber realizado más programación práctica y revisión de código que el año anterior. Esa cifra sugiere que algunos líderes están volviendo a la obra, quizás porque la distancia les ha costado algo que no pueden recuperar leyendo un resumen.

La due diligence de capital riesgo ha exigido esto durante décadas. La Diligencia Debida de Capital Riesgo de Camp menciona la capacidad del CTO «para contribuir personalmente a la investigación, desarrollo y/o ingeniería debido a un conocimiento actualizado y profundo de las tecnologías en las que participa la empresa» como criterio de selección. Los inversores formalizaron lo que los profesionales sienten intuitivamente: un CTO que no puede evaluar personalmente el trabajo está gestionando mediante narrativas, no con juicio.

Gupta deja explícita la excepción en su guía de liderazgo en ingeniería: evita delegar «tareas que requieran tu perspectiva única». El trabajo de alta criticidad «debería ser gestionado por gestores de gestión y líderes.» La ortodoxia de la delegación nunca dijo delegar todo. Decía delegar lo mecánico para poder centrarte en lo insustituible. El problema es que cuando la IA hace invisible la mecánica, el CTO olvida cuál era la parte insustituible.

¿Qué llena el vacío?

Una empresa automovilística europea nombró un CAIO cuya primera decisión fue exigir que todos los agentes de IA estuvieran registrados antes del despliegue y bloquear los servidores MCP a menos que estuvieran completamente documentados. La aprobación se volvió lo suficientemente lenta como para que los equipos dejaran de usar la palabra. «Solo indicaciones, habilidades, llamadas API, cualquier cosa menos agente», dijo un ingeniero dentro. «Decir eso en voz alta nos costaría el trabajo. Así que simplemente ya no llamamos agentes a las cosas a menos que sea necesario.»

El CAIO está haciendo lo que el puesto les da actualmente: crear puertas. En esta organización, el CAIO podía evaluar, clasificar y aprobar, pero no podía redirigir recursos de ingeniería ni anular decisiones arquitectónicas. Eso dejó a las puertas como el instrumento de autoridad más visible, y cuando esas puertas ralentizaron la entrega, los equipos crearon soluciones para cambiar nombres que dejaron a la organización con menos visibilidad que antes de que existiera el puesto.

No estoy argumentando que el CAIO sea ilegítimo. La investigación de IBM reveló que las empresas con un Director de IA obtuvieron un retorno del cinco por ciento superior de sus inversiones en IA. El mandato a nivel empresarial (legal, de personal, de datos, operaciones con clientes) es real y está en crecimiento. Pero la parte de ingeniería-gobernanza, la parte que determina si el código generado por IA se distribuye de forma segura, si las arquitecturas de agentes se mantienen bajo carga, si las herramientas que tu equipo usa a diario valen su coste: esa parte no puede delegarse a alguien que no construye.

La práctica que lo mantiene tuyo

El comunicado del Laboratorio de Economía Digital de Stanford publicado en julio da a esa elección un marco útil: «guía la IA para complementar a los humanos en lugar de simplemente imitarlos.» El CTO que sigue construyendo aporta el juicio, el contexto y la práctica que la IA no puede proporcionar. Un CTO que delega cada decisión técnica se convierte gradualmente en coordinador, y la coordinación es exactamente la capa que las organizaciones pueden pedir a la IA que absorba. Que Acemoglu co-firme esa declaración significa que el encuadre trasciende el optimismo frente al pesimismo. La elección es si el CTO mantiene suficiente contacto con el trabajo como para cuestionar la salida del modelo, o si se convierte en la persona que aprueba un proceso diseñado por otra persona.

La versión operativa es lo suficientemente sencilla para empezar esta semana: antes de firmar una orden de compra para una herramienta de IA, úsala tú mismo durante dos semanas en una tarea real. No es una demo, no es un sandbox, no es un resumen de tu equipo. Conoce los modos de fallo de tus propias manos. Sabe lo que no puede hacer, dónde alucina, cómo maneja los casos límite que tu equipo enfrentará en el tercer mes. Si requiere credenciales, entiende el alcance de lo que concedes. Si genera código, lee el código que genera para tu base de código, no la base de código del vídeo de marketing del proveedor.

Un compromiso limitado, repetido con cada decisión de herramienta que se te cruza por la mesa, mantiene el músculo que se atrofia en el momento en que empiezas a aprobar cosas que no has tocado.

El debate sobre el CAIO es una prueba de un problema industrial, no una solución a él. Un nuevo título no restaura la sentencia que abandonó la sala cuando el CTO dejó de construir. Solo le da un nombre y una línea de reporte a la aspiradora.

Estoy escribiendo más sobre cómo es esa práctica diaria y sobre saber cuándo no construirla yo mismo. Esa es una pregunta más limitada que qué software debería poseer una empresa, y la respuesta es menos obvia.

Ricardo