Hay momentos en los que una tecnolog\u00eda no solo cambia lo que hacemos, sino c\u00f3mo pensamos sobre lo que hacemos. La inteligencia artificial parece haber entrado precisamente en esa categor\u00eda: no sustituye procesos, sino que obliga a replantear d\u00f3nde est\u00e1 el valor real.<\/p>\n\n\n\n
En esta nueva entrega de \u201cPerspectiva CTO\u201d hablamos con Antonio Francisco Herrera Tabasco,<\/a> responsable de tecnolog\u00eda en atmira<\/a>, asesor tecnol\u00f3gico y Fractional CTO, adem\u00e1s de fundador y CTO de Pensend<\/a>, una plataforma de creaci\u00f3n de contenido impulsada por IA.<\/p>\n\n\n\n Su trayectoria combina consultor\u00eda en grandes organizaciones y construcci\u00f3n de producto desde cero, una dualidad que le permite observar la tecnolog\u00eda tanto desde la escala del sistema como desde la presi\u00f3n del d\u00eda a d\u00eda del producto real.<\/p>\n\n\n\n Esa mezcla es lo que d efine c\u00f3mo entiende y aplica la tecnolog\u00eda hoy.<\/p>\n\n\n\n Para Antonio, la figura del CTO no desaparece, pero s\u00ed cambia de lugar en el sistema.<\/p>\n\n\n\n \u201cLa figura del CTO va a evolucionar, pero no va a desaparecer ni a vaciarse de contenido\u201d, explica. \u201cLo que cambia profundamente es d\u00f3nde se juega la partida\u201d.<\/strong><\/p>\n\n\n\n En un contexto donde la inteligencia artificial automatiza parte de la decisi\u00f3n t\u00e9cnica, el valor del CTO ya no est\u00e1 en el dominio absoluto del c\u00f3digo, sino en lo que no se automatiza.<\/p>\n\n\n\n \u201cQueda lo m\u00e1s dif\u00edcil: leer el contexto de negocio, gestionar la incertidumbre, construir equipos bajo presi\u00f3n y tomar decisiones con informaci\u00f3n incompleta. <\/strong>Eso no se delega en un modelo\u201d.<\/p>\n\n\n\n Desde su visi\u00f3n, el CTO del futuro ser\u00e1 menos un experto t\u00e9cnico aislado y m\u00e1s un \u201carquitecto de sistemas y de personas al mismo tiempo\u201d, alguien que conecta tecnolog\u00eda con prop\u00f3sito.<\/p>\n\n\n\n C\u00f3mo se construye un CTO: criterio antes que t\u00edtulo<\/strong><\/p>\n\n\n\n Cuando se le pregunta c\u00f3mo llegar a ese rol, Antonio es claro: el error es empezar por el t\u00edtulo.<\/p>\n\n\n\n \u201cEl CTO no es un destino, es una consecuencia de haber resuelto cosas dif\u00edciles con criterio\u201d.<\/strong><\/p>\n\n\n\n Su recomendaci\u00f3n se apoya en tres ideas muy concretas. La primera, salir de la propia capa t\u00e9cnica y aprender a hablar otros idiomas dentro de la organizaci\u00f3n. La segunda, liderar antes de tener equipo. Y la tercera, construir cosas reales.<\/p>\n\n\n\n \u201cLa influencia no empieza cuando gestionas personas, empieza cuando consigues que otros conf\u00eden en tu criterio\u201d.<\/p>\n\n\n\n Y a\u00f1ade una reflexi\u00f3n que atraviesa toda su forma de ver la profesi\u00f3n:<\/p>\n\n\n\n \u201cAprender a gestionar la incertidumbre sin bloquearte es probablemente la habilidad m\u00e1s importante del rol\u201d.<\/strong><\/p>\n\n\n\n Entre sus experiencias m\u00e1s formativas, recuerda su primer proyecto como Arquitecto DevOps en el sector defensa.<\/p>\n\n\n\n Un equipo incompleto, cambios de \u00faltima hora y una responsabilidad inesperada lo llevaron a asumir simult\u00e1neamente roles de arquitectura, gesti\u00f3n y ejecuci\u00f3n.<\/p>\n\n\n\n \u201cCuando no hay red, desarrollas un instinto para priorizar que no te ense\u00f1a ning\u00fan curso\u201d.<\/p>\n\n\n\n El proyecto termin\u00f3 en tiempo y forma, pero el aprendizaje va m\u00e1s all\u00e1 del resultado:<\/p>\n\n\n\n \u201cA veces los proyectos salen adelante precisamente porque no tienes a nadie m\u00e1s en quien delegar\u201d.<\/p>\n\n\n\n Deuda t\u00e9cnica: el coste invisible de decidir r\u00e1pido<\/strong><\/p>\n\n\n\n En su visi\u00f3n, la deuda t\u00e9cnica no es un problema puntual del c\u00f3digo, sino el resultado acumulado de c\u00f3mo las organizaciones toman decisiones bajo presi\u00f3n.<\/p>\n\n\n\n \u201cVivimos un doble paradigma que lo complica todo\u201d, explica. \u201cPor un lado, organizaciones arrastrando parques de legacy que llevan a\u00f1os acumulando deuda. Por el otro, la presi\u00f3n de la IA irrumpiendo en el ciclo de desarrollo antes de que esa deuda est\u00e9 controlada\u201d.<\/p>\n\n\n\n Ese choque, seg\u00fan Antonio, no solo no reduce el problema, sino que lo amplifica.<\/p>\n\n\n\n \u201cAh\u00ed es donde los riesgos se multiplican\u201d.<\/p>\n\n\n\n El primero es el m\u00e1s evidente: el coste de la inacci\u00f3n.<\/strong><\/p>\n\n\n\n \u201cCada sprint que pasa sin abordar la deuda es deuda con intereses. Lo que hoy cuesta refactorizar, ma\u00f1ana cuesta reescribir. Y lo que ma\u00f1ana cuesta reescribir, pasado puede costar directamente el negocio\u201d.<\/p>\n\n\n\n Pero hay un segundo riesgo, <\/strong>menos visible y m\u00e1s estructural: confundir modernizaci\u00f3n con transformaci\u00f3n.<\/p>\n\n\n\n \u201cMuchos clientes quieren migrar a cloud o a\u00f1adir un copiloto sobre su legacy sin entender que est\u00e1n poniendo pintura nueva sobre una estructura que cruje. La IA no salva una arquitectura rota, la hace m\u00e1s cara de mantener\u201d.<\/p>\n\n\n\n El tercer riesgo es el m\u00e1s silencioso: la p\u00e9rdida de conocimiento funcional.<\/strong><\/p>\n\n\n\n \u201cNos encontramos con aplicaciones cr\u00edticas donde el c\u00f3digo lleva m\u00e1s a\u00f1os que las personas que lo mantienen. Y ah\u00ed el problema ya no es solo t\u00e9cnico: nadie sabe exactamente qu\u00e9 hace ni por qu\u00e9\u201d.<\/p>\n\n\n\n Frente a este escenario, Antonio se\u00f1ala que empiezan a emerger enfoques m\u00e1s estructurales, como el Spec-Driven Development, donde la especificaci\u00f3n se convierte en el eje del sistema antes de escribir c\u00f3digo.<\/p>\n\n\n\n \u201cLa especificaci\u00f3n pasa a ser la fuente de verdad. Eso cambia radicalmente c\u00f3mo se previene la deuda desde el origen\u201d.<\/p>\n\n\n\n Sobre las m\u00e9tricas, su diagn\u00f3stico es directo:<\/p>\n\n\n\n \u201cLa mayor\u00eda de organizaciones no mide la deuda t\u00e9cnica, la sufre. Y cuando la mide, es porque ya duele\u201d.<\/p>\n\n\n\n Aun as\u00ed, distingue tres niveles de observaci\u00f3n.<\/strong><\/p>\n\n\n\n A nivel t\u00e9cnico, destaca el tiempo de ciclo de cambio<\/strong>: cu\u00e1nto tarda un equipo en llevar una modificaci\u00f3n a producci\u00f3n.<\/p>\n\n\n\n \u201cSi ese tiempo crece sprint a sprint sin que el equipo crezca, la deuda est\u00e1 frenando el sistema\u201d.<\/p>\n\n\n\n A nivel de equipo, el indicador clave es el tiempo invertido<\/strong> en entender c\u00f3digo frente a construir funcionalidad.<\/p>\n\n\n\n \u201cEn entornos con deuda severa, el equipo pasa m\u00e1s tiempo descifrando que creando\u201d.<\/p>\n\n\n\n Y a nivel de negocio<\/strong>, la m\u00e9trica m\u00e1s potente es el coste de oportunidad.<\/p>\n\n\n\n \u201cQu\u00e9 iniciativas no se han lanzado, cu\u00e1nto se ha retrasado una funcionalidad que deber\u00eda haber tardado la mitad o cu\u00e1ntos incidentes vienen de sistemas que llevan a\u00f1os sin tocarse\u201d.<\/p>\n\n\n\n Pero m\u00e1s all\u00e1 de cualquier m\u00e9trica, deja una se\u00f1al sencilla:<\/p>\n\n\n\n \u201cCuando preguntas cu\u00e1nto cuesta a\u00f1adir una funcionalidad y la respuesta empieza con \u2018depende\u2026\u2019, ah\u00ed tienes deuda t\u00e9cnica sin medir pero muy presente\u201d.<\/p>\n\n\n\n En su experiencia, los errores m\u00e1s comunes no son t\u00e9cnicos, sino organizativos.<\/p>\n\n\n\n El primero es priorizar entrega sobre solidez.<\/strong><\/p>\n\n\n\n \u201cNo es un error del equipo t\u00e9cnico, es una consecuencia de c\u00f3mo se gestiona la presi\u00f3n. Los atajos se normalizan y se acumulan hasta que bloquean el sistema\u201d.<\/p>\n\n\n\n El segundo es no documentar las decisiones de arquitectura<\/strong>.<\/p>\n\n\n\n \u201cNo el c\u00f3digo, las decisiones. Por qu\u00e9 se eligi\u00f3 algo, qu\u00e9 se descart\u00f3 y qu\u00e9 trade-offs se aceptaron. Sin eso, cada cambio de equipo reinicia el conocimiento\u201d.<\/p>\n\n\n\n El tercero es crecer sin especificaci\u00f3n.<\/strong><\/p>\n\n\n\n \u201cDesarrollar funcionalidad sobre funcionalidad sin una fuente de verdad compartida genera inconsistencias que se multiplican con el tiempo\u201d.<\/p>\n\n\n\n Y el cuarto, quiz\u00e1 el m\u00e1s importante:<\/p>\n\n\n\n \u201cTratar la deuda t\u00e9cnica como un problema exclusivamente t\u00e9cnico, cuando en realidad casi siempre es organizativo o de producto\u201d.<\/strong><\/p>\n\n\n\n La irrupci\u00f3n de la inteligencia artificial ha cambiado completamente la ecuaci\u00f3n.<\/p>\n\n\n\n \u201cLa IA ha democratizado la capacidad de generar c\u00f3digo a una velocidad que antes era impensable. El problema es que tambi\u00e9n ha democratizado la capacidad de generar deuda a esa misma velocidad\u201d.<\/p>\n\n\n\n En ese contexto, aparece un fen\u00f3meno que describe sin suavizar:<\/p>\n\n\n\n \u201cVibe coding masivo: c\u00f3digo sin arquitectura, sin tests y sin criterio. Una bomba de relojer\u00eda en muchas organizaciones\u201d.<\/p>\n\n\n\n Frente a esto, su organizaci\u00f3n apuesta por un enfoque distinto.<\/p>\n\n\n\n \u201cEstamos adoptando IA bajo el paraguas de Spec-Driven Development. La especificaci\u00f3n es la fuente de verdad antes de generar una sola l\u00ednea de c\u00f3digo\u201d.<\/strong><\/p>\n\n\n\n Eso permite mantener control sobre lo que se genera, independientemente de si lo produce un humano o un modelo.<\/p>\n\n\n\n \u201cLa IA bien gobernada reduce deuda. La IA sin criterio la acelera\u201d.<\/p>\n\n\n\n La inteligencia artificial ya no es una herramienta perif\u00e9rica dentro de la organizaci\u00f3n, sino un componente que atraviesa pr\u00e1cticamente todas las decisiones t\u00e9cnicas.<\/p>\n\n\n\n Permite analizar contextos de cliente, detectar oportunidades y acelerar la construcci\u00f3n de propuestas de valor.<\/p>\n\n\n\n En arquitectura act\u00faa como un \u201csparring t\u00e9cnico\u201d, capaz de contrastar opciones y anticipar riesgos sin sustituir el criterio humano.<\/p>\n\n\n\n En producto, su impacto es estructural: en plataformas como Pensend, la IA no es una funcionalidad, sino la base del sistema.<\/p>\n\n\n\n \u201cLa IA no modifica el objetivo de las decisiones, pero s\u00ed cambia la velocidad de exploraci\u00f3n y el coste del error\u201d.<\/p>\n\n\n\n El CTO no desaparece, pero cambia de naturaleza.<\/p>\n\n\n\n \u201cEl CTO del futuro ser\u00e1 menos un experto t\u00e9cnico absoluto en la sala y m\u00e1s un traductor entre tecnolog\u00eda y prop\u00f3sito\u201d.<\/p>\n\n\n\n El reto no es solo construir, sino asegurar c\u00f3mo se valida lo que se construye en entornos donde la IA acelera todo.<\/p>\n\n\n\n Eso introduce nuevas fricciones: confianza, governance y riesgo de ilusi\u00f3n de calidad.<\/p>\n\n\n\n\u201cEl CTO del futuro no ser\u00e1 el que m\u00e1s sepa de tecnolog\u00eda, sino el que mejor conecte tecnolog\u00eda con prop\u00f3sito\u201d<\/strong><\/h2>\n\n\n\n
De tres personas a una. A un d\u00eda del kickoff. Solo ante el peligro<\/strong><\/h2>\n\n\n\n
C\u00f3mo se mide algo que normalmente solo se sufre<\/strong><\/h2>\n\n\n\n
Por qu\u00e9 se genera la deuda: velocidad sin estructura<\/strong><\/h2>\n\n\n\n
IA y low-code: aceleraci\u00f3n de la deuda o su contenci\u00f3n<\/strong><\/h2>\n\n\n\n
La IA en la toma de decisiones t\u00e9cnicas<\/strong><\/h2>\n\n\n\n
El rol del CTO en la era de la IA<\/strong><\/h1>\n\n\n\n