Hay momentos en los que una tecnología no solo cambia lo que hacemos, sino cómo pensamos sobre lo que hacemos. La inteligencia artificial parece haber entrado precisamente en esa categoría: no sustituye procesos, sino que obliga a replantear dónde está el valor real.

En esta nueva entrega de “Perspectiva CTO” hablamos con Antonio Francisco Herrera Tabasco, responsable de tecnología en atmira, asesor tecnológico y Fractional CTO, además de fundador y CTO de Pensend, una plataforma de creación de contenido impulsada por IA.

Su trayectoria combina consultoría en grandes organizaciones y construcción de producto desde cero, una dualidad que le permite observar la tecnología tanto desde la escala del sistema como desde la presión del día a día del producto real.

Esa mezcla es lo que d efine cómo entiende y aplica la tecnología hoy.

“El CTO del futuro no será el que más sepa de tecnología, sino el que mejor conecte tecnología con propósito”

Para Antonio, la figura del CTO no desaparece, pero sí cambia de lugar en el sistema.

“La figura del CTO va a evolucionar, pero no va a desaparecer ni a vaciarse de contenido”, explica. “Lo que cambia profundamente es dónde se juega la partida”.

En un contexto donde la inteligencia artificial automatiza parte de la decisión técnica, el valor del CTO ya no está en el dominio absoluto del código, sino en lo que no se automatiza.

“Queda lo más difícil: leer el contexto de negocio, gestionar la incertidumbre, construir equipos bajo presión y tomar decisiones con información incompleta. Eso no se delega en un modelo”.

Desde su visión, el CTO del futuro será menos un experto técnico aislado y más un “arquitecto de sistemas y de personas al mismo tiempo”, alguien que conecta tecnología con propósito.

Cómo se construye un CTO: criterio antes que título

Cuando se le pregunta cómo llegar a ese rol, Antonio es claro: el error es empezar por el título.

“El CTO no es un destino, es una consecuencia de haber resuelto cosas difíciles con criterio”.

Su recomendación se apoya en tres ideas muy concretas. La primera, salir de la propia capa técnica y aprender a hablar otros idiomas dentro de la organización. La segunda, liderar antes de tener equipo. Y la tercera, construir cosas reales.

“La influencia no empieza cuando gestionas personas, empieza cuando consigues que otros confíen en tu criterio”.

Y añade una reflexión que atraviesa toda su forma de ver la profesión:

“Aprender a gestionar la incertidumbre sin bloquearte es probablemente la habilidad más importante del rol”.

De tres personas a una. A un día del kickoff. Solo ante el peligro

Entre sus experiencias más formativas, recuerda su primer proyecto como Arquitecto DevOps en el sector defensa.

Un equipo incompleto, cambios de última hora y una responsabilidad inesperada lo llevaron a asumir simultáneamente roles de arquitectura, gestión y ejecución.

“Cuando no hay red, desarrollas un instinto para priorizar que no te enseña ningún curso”.

El proyecto terminó en tiempo y forma, pero el aprendizaje va más allá del resultado:

“A veces los proyectos salen adelante precisamente porque no tienes a nadie más en quien delegar”.

Deuda técnica: el coste invisible de decidir rápido

En su visión, la deuda técnica no es un problema puntual del código, sino el resultado acumulado de cómo las organizaciones toman decisiones bajo presión.

“Vivimos un doble paradigma que lo complica todo”, explica. “Por un lado, organizaciones arrastrando parques de legacy que llevan años acumulando deuda. Por el otro, la presión de la IA irrumpiendo en el ciclo de desarrollo antes de que esa deuda esté controlada”.

Ese choque, según Antonio, no solo no reduce el problema, sino que lo amplifica.

“Ahí es donde los riesgos se multiplican”.

El primero es el más evidente: el coste de la inacción.

“Cada sprint que pasa sin abordar la deuda es deuda con intereses. Lo que hoy cuesta refactorizar, mañana cuesta reescribir. Y lo que mañana cuesta reescribir, pasado puede costar directamente el negocio”.

Pero hay un segundo riesgo, menos visible y más estructural: confundir modernización con transformación.

“Muchos clientes quieren migrar a cloud o añadir un copiloto sobre su legacy sin entender que están poniendo pintura nueva sobre una estructura que cruje. La IA no salva una arquitectura rota, la hace más cara de mantener”.

El tercer riesgo es el más silencioso: la pérdida de conocimiento funcional.

“Nos encontramos con aplicaciones críticas donde el código lleva más años que las personas que lo mantienen. Y ahí el problema ya no es solo técnico: nadie sabe exactamente qué hace ni por qué”.

Frente a este escenario, Antonio señala que empiezan a emerger enfoques más estructurales, como el Spec-Driven Development, donde la especificación se convierte en el eje del sistema antes de escribir código.

“La especificación pasa a ser la fuente de verdad. Eso cambia radicalmente cómo se previene la deuda desde el origen”.

Cómo se mide algo que normalmente solo se sufre

Sobre las métricas, su diagnóstico es directo:

“La mayoría de organizaciones no mide la deuda técnica, la sufre. Y cuando la mide, es porque ya duele”.

Aun así, distingue tres niveles de observación.

A nivel técnico, destaca el tiempo de ciclo de cambio: cuánto tarda un equipo en llevar una modificación a producción.

“Si ese tiempo crece sprint a sprint sin que el equipo crezca, la deuda está frenando el sistema”.

A nivel de equipo, el indicador clave es el tiempo invertido en entender código frente a construir funcionalidad.

“En entornos con deuda severa, el equipo pasa más tiempo descifrando que creando”.

Y a nivel de negocio, la métrica más potente es el coste de oportunidad.

“Qué iniciativas no se han lanzado, cuánto se ha retrasado una funcionalidad que debería haber tardado la mitad o cuántos incidentes vienen de sistemas que llevan años sin tocarse”.

Pero más allá de cualquier métrica, deja una señal sencilla:

“Cuando preguntas cuánto cuesta añadir una funcionalidad y la respuesta empieza con ‘depende…’, ahí tienes deuda técnica sin medir pero muy presente”.

Por qué se genera la deuda: velocidad sin estructura

En su experiencia, los errores más comunes no son técnicos, sino organizativos.

El primero es priorizar entrega sobre solidez.

“No es un error del equipo técnico, es una consecuencia de cómo se gestiona la presión. Los atajos se normalizan y se acumulan hasta que bloquean el sistema”.

El segundo es no documentar las decisiones de arquitectura.

“No el código, las decisiones. Por qué se eligió algo, qué se descartó y qué trade-offs se aceptaron. Sin eso, cada cambio de equipo reinicia el conocimiento”.

El tercero es crecer sin especificación.

“Desarrollar funcionalidad sobre funcionalidad sin una fuente de verdad compartida genera inconsistencias que se multiplican con el tiempo”.

Y el cuarto, quizá el más importante:

“Tratar la deuda técnica como un problema exclusivamente técnico, cuando en realidad casi siempre es organizativo o de producto”.

IA y low-code: aceleración de la deuda o su contención

La irrupción de la inteligencia artificial ha cambiado completamente la ecuación.

“La IA ha democratizado la capacidad de generar código a una velocidad que antes era impensable. El problema es que también ha democratizado la capacidad de generar deuda a esa misma velocidad”.

En ese contexto, aparece un fenómeno que describe sin suavizar:

“Vibe coding masivo: código sin arquitectura, sin tests y sin criterio. Una bomba de relojería en muchas organizaciones”.

Frente a esto, su organización apuesta por un enfoque distinto.

“Estamos adoptando IA bajo el paraguas de Spec-Driven Development. La especificación es la fuente de verdad antes de generar una sola línea de código”.

Eso permite mantener control sobre lo que se genera, independientemente de si lo produce un humano o un modelo.

“La IA bien gobernada reduce deuda. La IA sin criterio la acelera”.

La IA en la toma de decisiones técnicas

La inteligencia artificial ya no es una herramienta periférica dentro de la organización, sino un componente que atraviesa prácticamente todas las decisiones técnicas.

Permite analizar contextos de cliente, detectar oportunidades y acelerar la construcción de propuestas de valor.

En arquitectura actúa como un “sparring técnico”, capaz de contrastar opciones y anticipar riesgos sin sustituir el criterio humano.

En producto, su impacto es estructural: en plataformas como Pensend, la IA no es una funcionalidad, sino la base del sistema.

“La IA no modifica el objetivo de las decisiones, pero sí cambia la velocidad de exploración y el coste del error”.

El rol del CTO en la era de la IA

El CTO no desaparece, pero cambia de naturaleza.

“El CTO del futuro será menos un experto técnico absoluto en la sala y más un traductor entre tecnología y propósito”.

El reto no es solo construir, sino asegurar cómo se valida lo que se construye en entornos donde la IA acelera todo.

Eso introduce nuevas fricciones: confianza, governance y riesgo de ilusión de calidad.

Decidir sin perder dirección

Para Antonio, el riesgo principal no es ir demasiado rápido o demasiado lento, sino moverse sin dirección.

El papel del CTO es necesariamente activo en la estrategia de IA, pero con una línea clara:

la IA no debe sustituir el juicio humano en decisiones críticas.

El valor del criterio en la era de la IA

La adopción de la IA no está cambiando únicamente las herramientas con las que trabajamos, sino la forma en la que pensamos, decidimos y construimos tecnología.

Lo interesante no es la velocidad a la que evoluciona la tecnología, sino la velocidad a la que las organizaciones son capaces —o no— de adaptarse sin perder criterio en el camino. Ahí es donde aparecen las verdaderas diferencias: no entre quienes usan IA y quienes no, sino entre quienes la gobiernan y quienes simplemente la consumen.

En ese contexto, el rol técnico se vuelve menos una cuestión de ejecución y más una cuestión de dirección. La capacidad de entender qué automatizar, qué preservar y qué no delegar se convierte en una competencia central.

“La IA no reduce la necesidad de criterio humano, la hace más visible que nunca”.

Y probablemente, más decisiva.

Queremos agradecer a Antonio por su participación en Perspectiva CTO, por su tiempo y por compartir una visión tan honesta y profunda sobre el impacto real de la inteligencia artificial en la tecnología y el liderazgo.