Entrevista a Javier Mallo, CIO en Carrefour España

El retail se encuentra en un momento de profunda transformación. La inteligencia artificial generativa, los agentes, el cloud, los datos y la automatización están abriendo nuevas posibilidades para mejorar tanto la experiencia de cliente como la eficiencia operativa.

Pero en un sector con millones de transacciones, cientos de tiendas y una enorme complejidad tecnológica, innovar no consiste únicamente en probar nuevas herramientas. El verdadero reto está en conseguir que la tecnología genere valor real y pueda escalar dentro del negocio.

La velocidad a la que aparecen nuevas tecnologías está obligando a los departamentos de IT a trabajar a dos velocidades.

Por un lado, necesitan explorar constantemente nuevas posibilidades y encontrar casos de uso que aporten valor. Por otro, tienen que mantener y modernizar infraestructuras, aplicaciones y sistemas que siguen siendo críticos para el funcionamiento del negocio.

Y en retail esta dualidad es especialmente evidente: la tecnología ya no está únicamente detrás del canal digital. Está presente en prácticamente cada interacción y cada proceso de una tienda física.

La tecnología ya no es un soporte: es parte de la estrategia

Durante años, la tecnología podía entenderse como una herramienta para dar soporte al negocio. Hoy esa separación resulta cada vez más difícil de mantener.

El comercio electrónico, las aplicaciones móviles, los programas de fidelización, la gestión del stock, el pricing, las promociones, la logística o la experiencia dentro de la tienda dependen directamente de sistemas tecnológicos.

Incluso el funcionamiento de una tienda física está cada vez más digitalizado. Por eso, la tecnología ha dejado de ser un medio aislado para convertirse en una pieza fundamental de la estrategia empresarial.

Esto cambia también el papel de los responsables de tecnología. El reto no consiste simplemente en conocer las últimas novedades, sino en entender la realidad concreta de la compañía y decidir qué tecnología aplicar, cuándo hacerlo y con qué objetivo.

No todas las empresas tienen la misma cultura, el mismo nivel de madurez ni las mismas necesidades. Una tecnología puede funcionar extraordinariamente bien en una organización y no aportar prácticamente nada en otra. El éxito depende de saber conectar la innovación tecnológica con los problemas reales del negocio.

El gran reto de la IA: conseguir adopción

La inteligencia artificial es probablemente el mejor ejemplo de esta nueva realidad. Las empresas pueden desplegar herramientas de IA generativa con una rapidez que hace unos años habría resultado difícil de imaginar. Pero poner una herramienta a disposición de miles de empleados/as no significa que vaya a ser utilizada de forma habitual.

Una experiencia real de despliegue demuestra precisamente esta dificultad. Tras poner una plataforma de IA a disposición de miles de empleados/as, la utilización inicial fue elevada, pero cayó considerablemente después de las primeras semanas. La tecnología estaba disponible, pero la adopción no se había trabajado suficientemente.

La solución pasa por entender que la adopción es un proyecto en sí mismo. No basta con proporcionar acceso a un modelo o a un copiloto. Es necesario formar a las personas, identificar casos de uso, crear referentes internos y conseguir que la tecnología se incorpore realmente a la forma de trabajar.

Los programas de AI Champions son una de las vías para conseguirlo. En lugar de plantear la adopción únicamente desde arriba, se crean comunidades de usuarios que experimentan, comparten conocimiento y ayudan a extender el uso de la IA dentro de las distintas áreas de negocio.

En el caso analizado, este enfoque permitió extender el uso de la IA a diferentes áreas y tiendas, acompañado de formación y sesiones periódicas.

Pero la adopción necesita también una dirección clara. Experimentar con IA en cientos de casos de uso diferentes puede acabar dispersando los recursos. Por eso resulta fundamental establecer prioridades estratégicas y concentrar los esfuerzos allí donde exista una oportunidad real de impacto.

De la IA genérica a los casos de uso que generan negocio

Una de las claves para que la inteligencia artificial tenga impacto en retail es dejar de pensar únicamente en la tecnología y empezar por los problemas que se quieren resolver.

Entre las áreas con mayor potencial aparecen cuestiones como la optimización del surtido, el pricing, las promociones, las operaciones en tienda y el conocimiento y relación con el cliente.

Aquí es donde los datos adquieren un papel fundamental. La IA puede ser extraordinariamente potente, pero necesita información de calidad y correctamente gobernada para generar resultados fiables.

Un ejemplo especialmente interesante es la evolución de los asistentes hacia experiencias mucho más personalizadas. Los nuevos agentes pueden ir más allá de responder preguntas y utilizar información contextual sobre cada cliente para ofrecer recomendaciones, promociones o información relevante para su situación concreta.

En este escenario, el valor de la IA no está únicamente en responder mejor, sino en utilizar el conocimiento disponible para ofrecer una experiencia más útil y personalizada.

Innovar rápido no significa escalar rápido

Una de las grandes ventajas actuales es que experimentar con nuevas tecnologías resulta mucho más rápido y barato que hace unos años.

Una prueba de concepto puede desarrollarse en cuestión de semanas o meses con una inversión relativamente contenida, lo que permite validar una idea antes de comprometer grandes cantidades de recursos. Pero existe una diferencia enorme entre demostrar que algo funciona y llevarlo a producción a gran escala.

Cuando una prueba de concepto se convierte en un producto utilizado por miles o millones de personas, aparecen nuevos desafíos. La experiencia de usuario, la estabilidad, la infraestructura, la seguridad y la calidad de los datos pasan a ser factores críticos. El verdadero cuello de botella de la innovación muchas veces no está en crear el prototipo, sino en tener una arquitectura preparada para soportarlo.

Por eso, los equipos de UX y UI adquieren una importancia creciente. Una aplicación o un agente puede funcionar técnicamente y, sin embargo, fracasar porque la experiencia de usuario no resulta suficientemente intuitiva o atractiva. La adopción depende también de cómo se presenta la tecnología al usuario.

El problema que sigue detrás de la IA: el legacy

Hay otro elemento menos visible, pero fundamental: los sistemas que existen detrás de las nuevas experiencias digitales. Una empresa puede desarrollar rápidamente un nuevo agente, una aplicación basada en IA o un nuevo canal digital.

Sin embargo, si ese producto depende de una aplicación crítica de hace quince años que continúa funcionando sobre una infraestructura antigua, la capacidad de escalar estará limitada. Es el problema de las dos velocidades de IT.

Mientras una parte de la organización trabaja en inteligencia artificial, agentes, innovación y transformación digital, otra tiene que ocuparse de infraestructuras, aplicaciones legacy, vulnerabilidades, obsolescencia y mantenimiento.

El reto consiste en conseguir que ambas velocidades avancen. No tiene sentido construir el futuro digital sobre una base tecnológica incapaz de soportarlo.

La modernización de estos sistemas, la migración al cloud, la creación de infraestructuras autoescalables y, sobre todo, una correcta gestión y gobierno del dato son condiciones necesarias para aprovechar realmente las nuevas tecnologías.

El dato como infraestructura invisible del retail

La IA está haciendo todavía más evidente un problema que ya existía: la calidad del dato. Los modelos y agentes necesitan acceder a información fiable, actualizada y correctamente gobernada.

De poco sirve disponer de una tecnología muy avanzada si los datos sobre clientes, productos, stock o procesos están fragmentados, desactualizados o almacenados en sistemas difíciles de integrar.

Por eso, una parte importante del trabajo tecnológico durante los próximos años seguirá siendo mucho menos visible que la IA: limpiar datos, modernizar sistemas, migrar plataformas, mejorar la gobernanza y eliminar deuda tecnológica.

Puede parecer menos espectacular que desplegar un agente autónomo, pero probablemente sea igual o más importante para determinar qué empresas estarán preparadas para aprovechar esa tecnología.

El futuro del retail será agéntico, pero seguirá siendo humano

Es difícil predecir exactamente cómo será el retail dentro de cinco años. La velocidad de evolución de la inteligencia artificial hace que muchas de las predicciones actuales puedan quedarse rápidamente obsoletas.

Lo que sí parece claro es que los agentes tendrán un papel cada vez mayor y estarán más interconectados con los sistemas de las compañías. También veremos una mayor presencia de tecnologías como IoT, edge computing o computación cuántica.

Pero existe una conclusión especialmente relevante para el retail: digitalizar no significa eliminar la dimensión humana de la experiencia de compra. La tienda física seguirá teniendo un peso enorme.

Aunque crezcan el ecommerce, el quick commerce, las aplicaciones y las nuevas interfaces basadas en IA, las personas continuarán visitando las tiendas. El objetivo de la tecnología será hacer esa experiencia más sencilla, personalizada y libre de fricciones, no necesariamente sustituirla.

Esto abre una oportunidad especialmente interesante para el sector: utilizar la tecnología para conseguir que el mundo físico y el digital dejen de funcionar como experiencias separadas.

Primero entendimos cómo Angular era capaz de “saber” cuándo actualizar la UI gracias a Zone.js, el árbol de componentes y las estrategias de detección de cambios. Después dimos el salto a Signals y vimos cómo Angular comenzaba a actualizar únicamente aquello que realmente dependía del estado reactivo.

• Estrategia de detección de cambios: la magia de Angular
• Angular Signals: evolución de la reactividad y detección de cambios

En este tercer capítulo vamos a cerrar el círculo. Porque si Signals solucionaba qué debe actualizarse… Zoneless cambia completamente cuándo Angular decide ejecutar la detección de cambios.

Y sí: Angular ya puede funcionar sin Zone.js.

Del “Angular lo detecta todo” al “Angular detecta solo lo necesario”

En el primer artículo vimos que Angular utilizaba Zone.js para interceptar operaciones asíncronas:

• Clicks
• setTimeout
• Peticiones HTTP
• Promesas
• Eventos del navegador…

Cada vez que ocurría cualquiera de esas operaciones, Angular lanzaba un ciclo de detección de cambios completo. El problema es que Angular realmente no sabía si había cambiado algo relevante.

Simplemente asumía:

“Ha ocurrido algo asíncrono. Por si acaso… reviso toda la aplicación”.

Y eso funcionaba muy bien, pero también implicaba trabajo innecesario.

El ejemplo del reloj

Sigamos exactamente el mismo ejemplo de los artículos anteriores. Tenemos:

• Un reloj que se actualiza cada segundo
• Una lista de usuarios.

@Component({
 selector: 'app-root',
 template: `
   <h2>{{ clock }}</h2>

   @for (user of users; track user.id) {
     <app-user-row [user]="user"></app-user-row>
   }
 `
})
export class AppComponent {
 clock = '';

 users = USERS;

 ngOnInit() {
   setInterval(() => {
     this.clock = new Date().toLocaleTimeString();
   }, 1000);
 }
}

En el primer artículo vimos que:

• Cada segundo, Angular recorría el árbol completo
• Recalculaba bindings
• Ejecutaba expresiones
• Revisaba todos los componentes

Aunque los usuarios no hubieran cambiado.

OnPush fue el primer parche

Después apareció ChangeDetectionStrategy.OnPush.

@Component({
 changeDetection: ChangeDetectionStrategy.OnPush
})

Con OnPush, Angular dejaba de revisar componentes “porque sí” y solo los comprobaba cuando:

• Cambiaba un @Input
• Ocurría un evento dentro del componente
• Se emitía un observable con async
• O llamábamos manualmente a markForCheck()

Era mucho más eficiente, pero seguíamos dependiendo de Zone.js porque Angular seguía necesitando un mecanismo global que dijera:

“Oye, acaba de pasar algo asíncrono”.

Signals cambió las reglas del juego

Y aquí llegó la gran revolución. Con Signals, Angular ya no necesita “preguntarse” qué ha cambiado, ahora lo sabe.

clock = signal('');
setInterval(() => {
 this.clock.set(new Date().toLocaleTimeString());
}, 1000);

En la plantilla:

<h2>{{ clock() }}</h2>

Angular registra automáticamente qué partes de la UI dependen de cada signal y, cuando el signal cambia:

• Angular marca únicamente los componentes afectados
• Evita recorrer ramas innecesarias
• Actualiza solo los bindings dependientes

Esto ya suponía un salto enorme de rendimiento, pero todavía quedaba una pregunta importante: si Signals ya sabe exactamente qué cambia… ¿para qué seguimos necesitando Zone.js?

Aquí entra Zoneless

La respuesta corta es que ya no lo necesitamos tanto. Angular empezó a introducir soporte para aplicaciones “zoneless”, es decir, aplicaciones sin Zone.js y eso cambia completamente el modelo mental.

¿Qué hace realmente Zone.js?

Zone.js parchea APIs del navegador para interceptar tareas asíncronas:

• Timers
• Eventos
• Promesas
• XHR
• Fetch
• etc.

Cuando cualquiera de esas tareas termina, Angular ejecuta detección de cambios global. El problema es que eso tiene costes:

• Más trabajo innecesario
• Más ciclos de detección
• Peor startup
• Stack traces más difíciles
• Y más complejidad interna

De hecho, uno de los objetivos principales de Zoneless es mejorar el rendimiento, el Core Web Vitals, la compatibilidad con APIs modernas y la experiencia de debugging.

¿Cómo funciona Angular sin Zone.js?

En modo zoneless, Angular deja de “espiar” todo el navegador. En lugar de eso, solo actualiza la UI cuando recibe notificaciones explícitas. Por ejemplo:

• Un signal cambia,
• Un AsyncPipe emite
• Ocurre un evento Angular ((click))
• Se llama a markForCheck()
• Un @Input recibe un nuevo valor

Es decir: Angular ya no hace polling implícito del estado. Ahora el propio framework sabe exactamente cuándo algo relevante ha cambiado y aquí está probablemente la idea más importante de todo el cambio: Angular pasa de un modelo reactivo implícito a uno explícito.

Activando Zoneless

Actualmente, Angular permite habilitarlo mediante:

bootstrapApplication(AppComponent, {
 providers: [
   provideZonelessChangeDetection()
 ]
});

Y eliminando:

npm uninstall zone.js

Volvamos al ejemplo del reloj

Ahora, nuestro ejemplo cambia bastante.

@Component({
 selector: 'app-root',
 template: `
   <h2>{{ clock() }}</h2>
   @for (user of users(); track user.id) {
     <app-user-row [user]="user"></app-user-row>
   }
 `})
export class AppComponent {
 clock = signal('');
 users = signal(USERS);

 ngOnInit() {
   setInterval(() => {
     this.clock.set(
       new Date().toLocaleTimeString()
     );
   }, 1000);
 }
}

¿Qué ocurre ahora cada segundo?

• Cambia únicamente clock
• Angular marca únicamente ese binding
• La tabla de usuarios ni siquiera entra en el ciclo.

Ya no existe ese “revisar toda la aplicación por si acaso”.

Entonces… ¿Signals sustituye a OnPush?

No exactamente. Signals y Zoneless mejoran muchísimo cómo Angular programa la detección de cambios, pero OnPush sigue siendo importante.

Porque Zoneless no cambia cómo Angular recorre el árbol de componentes, lo que cambia es cuándo decide lanzar detección de cambios.

Así que:

• OnPush sigue ayudando a limitar comprobaciones
• Signals sigue marcando componentes concretos
• Zoneless evita disparar ciclos globales innecesarios.

Las tres piezas se complementan y, de hecho, la propia documentación oficial recomienda OnPush como paso natural hacia compatibilidad zoneless.

Algo importante: Angular sigue detectando eventos

Hay un detalle muy interesante. Aunque eliminemos Zone.js, esto sigue funcionando:

<button (click)="increment()">
 Incrementar
</button><br>

counter++;

¿Por qué? Porque los eventos registrados a través de Angular siguen notificando al framework automáticamente.

Pero cuidado: esto NO ocurre con APIs externas al ecosistema Angular. Por ejemplo:

element.addEventListener('click', () => {
 this.counter++;
});

Aquí, Angular ya no sabe que algo cambió y necesitaríamos:

markForCheck()

O utilizar Signals.

Lo que empieza a “romperse” en Zoneless

Aquí es donde la teoría se vuelve interesante, porque la mayoría de aplicaciones Angular actuales dependen indirectamente de comportamientos automáticos de Zone.js.

Y cuando lo eliminamos… aparecen ciertas sorpresas. Por ejemplo, este patrón clásico deja de funcionar correctamente:

this.userService.users$
 .subscribe(users => {
   this.users = users;
 });

Si luego mostramos users directamente en plantilla, Angular podría no enterarse del cambio porque la suscripción ocurre fuera de cualquier mecanismo reactivo observable para Angular.

La solución moderna pasa por:

• Usar async pipe
• Convertir observables a signals
• Llamar explícitamente a markForCheck().

Por ejemplo:

users = toSignal(this.userService.users$);

Aquí empieza a verse claramente hacia dónde quiere ir Angular: menos magia implícita y más reactividad explícita.

Otro detalle importante es Reactive Forms. Operaciones como form.patchValue(...)siguen actualizando el estado interno del formulario…pero ya no fuerzan automáticamente detección de cambios.

¿Desde qué versión existe Zoneless?

Angular ha ido evolucionando esta capacidad durante varias versiones.

El verdadero cambio de paradigma

Angular deja atrás un modelo basado en “revisar por si acaso” para pasar a un modelo basado en reactividad explícita.

Mucho más predecible, mucho más eficiente y bastante más cercano a cómo funcionan frameworks modernos como Solid o Vue Signals.

¿Está listo para producción?

A día de hoy, Zoneless ya forma parte de la estrategia oficial de Angular y el framework está claramente orientado hacia este modelo reactivo, pero eso no significa que cualquier aplicación pueda eliminar Zone.js mañana sin más. Conviene validar cuidadosamente:

• Librerías de terceros
• Integraciones DOM manuales
• Código legacy
• Formularios reactivos
• SSR
• Testing
• Patrones basados en side effects implícitos

De hecho, Angular insiste bastante en que el futuro pasa por Signals, async pipe, OnPush, APIs reactivas y notificaciones explícitas al framework.

Conclusiones

Durante años, Angular se apoyó en Zone.js para detectar cualquier posible cambio en la aplicación. Después llegó OnPush para reducir trabajo innecesario. Más tarde apareció Signals para permitir una reactividad mucho más precisa.

Y ahora Zoneless termina de cerrar esa evolución eliminando la necesidad de vigilar constantemente todo lo que ocurre en el navegador.

La combinación de Signals, OnPush, y Zoneless nos permite construir aplicaciones mucho más eficientes, predecibles y fáciles de razonar.

Pero también obliga a entender mucho mejor cómo funciona realmente la reactividad del framework. Porque Angular ya no intenta adivinar lo que ocurre, ahora espera que seamos explícitos y, probablemente, ahí está el cambio más importante de todos.

Referencias

Artículos previos de la serie

• Estrategia de detección de cambios: la magia de Angular
• Angular Signals: evolución de la reactividad y detección de cambios

Documentación oficial de Angular

• Angular Zoneless Guide
• Angular v18 Experimental Zoneless Guide
• provideZonelessChangeDetection API

Artículos y análisis técnicos

• Angular 20 y el futuro sin ZoneJS: la revolución zoneless ha llegado a developer preview
• Zoneless Angular: What Works, What Breaks, and Why It Matters
• What Does Zoneless Angular Mean?

Es un documento de sobra conocido. Evidentemente, su contenido no está escrito en piedra y no tiene el contexto del mercado español como tal pero sí que aporta una visión general del estado del arte y su tendencia ya que, si lo sigues en sus diferentes volúmenes, puedes ver cómo evolucionan los conceptos que en él se incluyen.

Creo que en este momento de brutal cambio e incertidumbre en el sector, consultar documentos de este tipo y calidad es de vital importancia para saber qué va siendo una realidad contrastada o qué hay que tomar con precaución.

La fuente de conocimiento: el radar de Thoughtworks

Como he comentado en la introducción, el Radar de Thoughtworks es de sobra conocido. Seguramente lo hayas consultado más de una vez pero si no, te animo a hacerlo porque me parece muy interesante, sobre todo en estos tiempos de tanto cambio e incertidumbre.

Cada seis meses, más o menos, suelen publicar un volumen con lo que estiman relevante. Los volúmenes son documentos amplios y detallados, de unas 45-50 páginas cada uno, orientados bajo cuatro pilares fundamentales:

• Técnicas
• Plataformas
• Herramientas
• Lenguajes y frameworks

De cada pilar se analizan una serie de “cosas o ítems interesantes” (”blips” en su terminología) que se terminan clasificando en cuatro niveles:

• Adoptar: la industria debería adoptar esos ítems. Son items que ya están consolidados en el sector.
• Probar: vale la pena probarlos porque es importante entender cómo desarrollar estas capacidades. Las empresas deberían probar esta tecnología en proyectos en que se puede manejar el riesgo.
• Evaluar: merece la pena explorar esos ítems con el objetivo de comprender cómo afectará a la empresa.
• Resistir: proceder con precaución a la hora de implantarlos.

Lo realmente interesante no es tanto qué blips hay en cada bloque sino la tendencia: qué blips aparecen, cuáles son “promocionados” a probar o adoptar y cuáles hay que tratar con precaución, bien porque su madurez así lo indica o porque se han detectado riesgos o carencias que hay que tener en cuenta.

El medio para la entrevista: un RAG avanzado

Como no podía ser de otra forma en los tiempos que corren, me he apoyado en la IA para realizar la entrevista, pero no como se puede pensar a priori, utilizando ChatGPT, Gemini, NotebookLM o similar para que analice el radar y emita conclusiones, preparando un sistema al que he intentado dotar de un pensamiento lo más “humano” posible que permita que esto parezca una entrevista de verdad.

El sistema está basado en una arquitectura 100% serverless en AWS (Cloudfront, API Gateway, Lambda, Bedrock, Opensearch, DynamoDB, S3), que se puede levantar y tirar mediante IaC.

El “core”, básicamente consiste en un RAG avanzado con búsqueda híbrida (BM25 + embeddings vectoriales) sobre una serie de fuentes indexadas (chunking jerárquico) en AWS Bedrock Knowledge Base en Opensearch.

El diagrama de arquitectura es el siguiente:

Cuando se hace una pregunta, se recuperan los fragmentos más relevantes del corpus, se inyectan en el contexto del modelo junto con un resumen acumulativo de la conversación (generado automáticamente por modelo ligero tras cada turno y persistido en DynamoDB), manteniendo así el hilo de la entrevista sin depender de la memoria nativa del modelo.

Para intentar dotar al sistema de “cierto comportamiento humano” y que parezca una entrevista de verdad, el prompt de sistema está pensando para que actúe como una persona que trabaja en la realización del radar, miembro del Thoughtworks Technology Advisory Board (TAB), que va a ser entrevistado.

Para esta PoC he decidido establecer la base de conocimiento dentro de un rango temporal más o menos de dos años, analizando los últimos cuatro volúmenes:

• 📊 Volumen 31 (octubre 2024)
• 📊 Volumen 32 (abril 2025)
• 📊 Volumen 33 (noviembre 2025)
• 📊 Volumen 34 (abril 2026)

La UI, a la que he intentado dar un estilo editorial periodístico, permite configurar tanto los parámetros más importantes de la consulta (modelo, tokens, fragmentos recuperados o incluso el prompt de sistema) como explorar el radar por anillo, cuadrante y edición.

También permite exportar la transcripción completa como PDF en formato periódico a doble columna. Al finalizar la sesión, si es necesario, un segundo modelo genera un informe ejecutivo estructurado (resumen, temas clave, tendencias y recomendaciones) basado exclusivamente en lo discutido durante la entrevista.

No voy a dar muchos más detalles del proyecto en este artículo porque no es el objeto del mismo (es la entrevista en sí) y publicaré un artículo más técnico próximamente con todos los detalles.

Ahora sí, la entrevista

Una vez detallado el contexto en el que se realiza la entrevista, procedamos a su realización y a la formulación de las preguntas. He de decir que, en mi opinión, ha dejado insights muy significativos:

• Hola, vamos a comenzar esta esperada entrevista. Vamos con la primera pregunta. Este 2026 está siendo un año de vértigo en lo que se refiere al impacto de la tecnología pero, desde tu punto de vista, hasta llegar a este punto actual, ¿cómo describirías la evolución del sector tecnológico en los últimos años?

Buena pregunta para arrancar. Si tuviera que resumirlo en una frase: hemos pasado de la experimentación entusiasta a la ingeniería responsable, pero con mucho ruido en el camino.

Lo que hemos observado a lo largo de las últimas ediciones del Radar es una aceleración que no tiene precedentes, pero con un patrón reconocible. Cada ciclo tecnológico sigue una curva similar: euforia, saturación, y luego — si la tecnología tiene valor real — consolidación. Con la IA generativa hemos vivido esa curva en cámara rápida.

Hace tres o cuatro años, el debate era si los LLMs eran algo más que un juguete sofisticado. Luego vino la explosión del ecosistema — RAG, vector databases, guardrails, frameworks de agentes — que en el Radar de 2024 ya describíamos como una “explosión cámbrica”. Era caótico, pero tenía sentido: la simplicidad inicial del prompt de texto estaba dando paso a la ingeniería de software real.

Este es el punto que más nos importa subrayar: la tecnología madura cuando deja de ser magia y se convierte en disciplina. Y eso es exactamente lo que estamos viendo ahora en 2026 con los agentes, con el context engineering, con los patrones de evaluación de LLMs.

Pero también hemos visto lo que no funcionó como esperábamos. Fuimos inicialmente optimistas con la autonomía total de los agentes de código, y hemos tenido que ser honestos: el enfoque supervisado sigue siendo imprescindible. La complacencia con el código generado por IA es un antipatrón real, documentado, con datos que lo respaldan.
Uno de los patrones que seguimos viendo es que la velocidad de las herramientas supera la madurez de las prácticas. Y eso tiene un coste: deuda cognitiva, shadow IT acelerado por IA, arquitecturas que derivan sin control.

El sector está en un momento apasionante, pero los fundamentos de ingeniería — testing, observabilidad, diseño arquitectónico — nunca han sido más relevantes que ahora.

• Me parece muy interesante lo que comentas de que “los fundamentos de ingeniería nunca han sido más relevantes qué ahora”. ¿Por qué ahora son una pieza clave? ¿No lo han sido siempre?

Sí, siempre lo han sido. Pero hay una diferencia crucial entre que algo sea importante y que su ausencia sea inmediatamente catastrófica.

Antes, si un equipo tenía poca cobertura de tests o una arquitectura mediocre, el daño se acumulaba lentamente. Había fricción, deuda técnica, pero el sistema degradaba de forma gradual y visible. Ahora, con agentes de código generando changesets masivos en minutos, esa misma ausencia de disciplina puede destruir la coherencia de un sistema en horas. La velocidad amplifica todo, lo bueno y lo malo.

This is where things get interesting. Lo que estamos documentando en el Radar como codebase cognitive debt no es simplemente deuda técnica tradicional. Es algo más sutil y más peligroso: es la pérdida del modelo mental colectivo sobre cómo funciona el sistema. Cuando el código lo genera la IA y nadie lo revisa en profundidad, el equipo empieza a operar sobre una caja negra que ellos mismos construyeron sin entender. Los datos de GitClear son bastante elocuentes al respecto: más código duplicado, más churn, menos refactoring.

Y aquí está la paradoja que más nos preocupa: los agentes de código funcionan mejor en codebases bien estructuradas, bien testeadas, con diseño limpio. Es decir, las prácticas que algunos equipos estaban tentados a relajar porque “la IA lo arregla” son exactamente las que hacen que la IA funcione bien. El buen diseño para humanos también es buen diseño para agentes.

Por eso en el último Radar hemos puesto en Adopt cosas como DORA metrics, context engineering, zero trust, OpenTelemetry. No son novedades. Son recordatorios de que sin esa base, la velocidad que promete la IA se convierte en deuda compuesta.

Lo que ha cambiado no es la importancia de los fundamentos. Es el coste de ignorarlos.

• Viendo la evolución de estos últimos años, ¿qué puntos consideras clave para que la incorporación de la IA sea un éxito hoy día en una empresa?

Lo primero que diría es que el fracaso más común que vemos no es técnico. Es organizacional. Las empresas que están fallando con IA no fallan porque eligieron el modelo equivocado o el framework incorrecto. Fallan porque intentaron incorporar IA sobre una base que ya era frágil.

Dicho esto, hay varios patrones que hemos documentado como críticos.

Primero, tratar el contexto como un activo de ingeniería, no como un detalle de implementación. Context engineering está en Adopt en el último Radar precisamente porque hemos visto que las organizaciones que lo hacen bien —que diseñan el contexto como una pipeline dinámica y gestionada— obtienen resultados cualitativamente distintos. Las que lo ignoran acaban con agentes alucinando o comportándose de forma inconsistente.

Segundo, invertir en las señales de feedback antes de escalar. DORA metrics en Adopt no es nostalgia. Es un recordatorio de que si no mides lead time, deployment frequency y rework rate, no sabrás si la IA está generando valor real o simplemente más código. Y el rework rate específicamente es el canario en la mina para detectar deuda cognitiva acumulada.

Tercero, gobernar los agentes desde el principio. Zero trust architecture en Adopt para agentes no es opcional. El “lethal trifecta” que describe Simon Willison —datos privados, contenido no confiable, acción externa— describe a la mayoría de los agentes útiles por defecto. Si no tienes least privilege y monitorización continua desde el día uno, estás construyendo sobre arena.

Y cuarto, y esto es quizás lo más contraintuitivo: las empresas que más éxito tienen son las que primero invierten en limpiar su codebase y sus prácticas de ingeniería, y después incorporan agentes. No al revés.

Lo que observamos repetidamente es que la IA amplifica lo que ya existe. Si tienes disciplina, la amplifica. Si tienes caos, también lo amplifica. Y a una velocidad que no da tiempo a reaccionar.

• A nivel de tecnologías, durante estos últimos años, ¿cuáles son las que se han asentado totalmente y cuáles se han perdido por el camino o se van diluyendo?

Esta es una pregunta que me encanta porque el movimiento entre rings es donde realmente se ve si algo tiene sustancia o si era ruido.

Las que se han asentado de verdad:

OpenTelemetry es quizás el ejemplo más limpio. Pasó de Assess a Adopt de forma casi inevitable, porque resolvió un problema real —la fragmentación de observabilidad— con una abstracción correcta. Cuando Datadog, New Relic y Grafana adoptan el mismo protocolo, sabes que algo ha ganado. Eso no es hype, es consolidación genuina.

RAG —Retrieval-Augmented Generation— llegó a Adopt en tiempo récord. Lo que nos sorprendió no fue la velocidad, sino que la técnica sobrevivió al escrutinio de producción. Sigue evolucionando —GraphRAG, Corrective RAG, Self-RAG— pero el patrón central aguantó.

Y en tooling, cosas como Renovate o Vite: sin glamour, sin conferencias keynote, pero en Adopt porque simplemente funcionan y los equipos no quieren vivir sin ellos.

Las que se están diluyendo o nunca despegaron:

SAFe sigue en Hold, y cada edición el lenguaje se vuelve más duro. No es que no se use —se usa demasiado— sino que seguimos sin ver los resultados que promete.

Local coding assistants es interesante: llegaron con mucha expectativa por razones de privacidad, pero los pusimos en Hold porque los modelos locales simplemente no compiten con los cloud-based en capacidades agenticas. La realidad técnica ganó al deseo organizacional.

Y lo más revelador: “Replacing pair programming with AI” en Hold. Esto es casi una declaración de principios nuestra. No porque la IA no ayude, sino porque confunde velocidad individual con salud del equipo. Son cosas distintas.

El patrón que veo: lo que se asienta resuelve fricción real con abstracciones durables. Lo que se diluye suele ser o bien una solución buscando problema, o bien una optimización local que ignora consecuencias sistémicas.

• ¿Cuáles crees que son los principales riesgos o antipatrones que se han detectado durante estos últimos años y que pueden hacer mucho daño de no tomar medidas?

Esta es quizás la pregunta más importante que podemos hacernos ahora mismo, porque estamos en un momento donde la velocidad de adopción supera claramente la velocidad de comprensión de las consecuencias.

El primero y más peligroso: la complacencia con el código generado por IA. No es nuevo —lo llevamos poniendo en Hold desde hace varios volúmenes— pero se está agravando. Lo que antes era un desarrollador revisando sugerencias de Copilot, ahora es un agente modificando decenas de ficheros en paralelo mientras el desarrollador supervisa a alto nivel. El riesgo de automation bias se multiplica exponencialmente. Y lo que obtienes no es código malo —es código que funciona pero que nadie entiende del todo. Eso nos lleva directamente al segundo antipatrón.

La deuda cognitiva del codebase. Este término lo introdujimos recientemente en Caution y creo que es uno de los conceptos más importantes que hemos articulado en años. No es deuda técnica clásica —es la brecha entre lo que el sistema hace y lo que el equipo comprende que hace. Con agentes generando cambios a alta velocidad, esa brecha se ensancha silenciosamente hasta que un día un cambio pequeño rompe algo inesperado, y nadie sabe por qué.

Tercero: MCP by default. Lo pusimos en Caution explícitamente. El patrón que vemos es: “tengo una API, la convierto en MCP server, listo.” Sin pensar en el modelo de seguridad, sin analizar los flujos tóxicos, sin preguntarse si realmente necesitas MCP o si un CLI script resuelve el problema igual de bien. La conversión naïve de APIs a MCP es una superficie de ataque que la mayoría de organizaciones no está gestionando.

Y cuarto, uno que me preocupa especialmente a nivel organizacional: el shadow IT acelerado por IA. No-coders construyendo workflows agenticos que procesan datos sensibles, sin governance, sin audit trail, sin que IT lo sepa. La diferencia con el shadow IT clásico es la escala y la velocidad. Lo que antes tardaba meses en convertirse en un problema crítico, ahora tarda semanas.

El patrón común en todos estos antipatrones es el mismo: la IA amplifica la velocidad antes de que la organización haya construido los mecanismos de control necesarios. Y cuando algo falla, falla rápido y a escala.

• Me parecen muy interesantes estos puntos, sobre todo cuando se está hablando de la desaparición del rol de programador. Pero, sin embargo, detectáis muchos riesgos asociados con la generación automática de la mayor parte del código sin revisar, aumentando la deuda técnica. ¿Cómo afecta esto realmente al rol de desarrollador? ¿Acabará desapareciendo este rol o tendrá mayor importancia de la que tiene?

La narrativa de “el programador va a desaparecer” es, francamente, una de las más irresponsables que circulan ahora mismo. Y lo digo con convicción porque los datos que vemos en el Radar apuntan exactamente en la dirección contraria.

Lo que estamos observando es una transformación del rol, no su extinción. Y esa transformación lo hace, si cabe, más crítico y más difícil de ejercer bien.

Piénsalo así: cuando un agente genera cientos de líneas de código en segundos, ¿quién decide si esa solución es la correcta arquitectónicamente? ¿Quién detecta que el agente ha resuelto el problema con treinta condicionales anidados en lugar de aplicar el patrón Strategy? ¿Quién entiende el acoplamiento oculto que ese cambio introduce? Eso requiere más criterio técnico, no menos.

Lo que sí desaparece —y esto es importante— es el desarrollador que solo sabe escribir código mecánico, sin entender diseño, sin entender sistemas, sin entender trade-offs. Ese perfil ya estaba en declive antes de la IA. Lo que emerge es un desarrollador que actúa más como ingeniero de sistemas y director técnico de agentes: alguien que sabe especificar intención con precisión, que puede evaluar output a alto nivel, que mantiene el modelo mental del sistema completo.

Y aquí está la paradoja que nos preocupa profundamente: la IA está bajando la barrera de entrada al mismo tiempo que eleva el listón de lo que significa hacerlo bien. Eso crea una brecha enorme. Tendrás más gente generando código, pero menos gente capaz de entender lo que se ha generado. Y esa brecha es exactamente lo que alimenta la deuda cognitiva del codebase que mencionábamos antes.

**Lo que el Radar refuerza consistentemente —pair programming, TDD, fitness functions, code review riguroso— no son reliquias del pasado. Son los mecanismos que permiten que un equipo mantenga comprensión colectiva del sistema mientras la velocidad de generación se dispara.

El rol del desarrollador no desaparece. Se bifurca: los que entienden profundamente los sistemas se vuelven exponencialmente más valiosos; los que delegaron ese entendimiento a la IA se vuelven prescindibles. La IA no elimina la necesidad de criterio técnico. La hace más cara cuando falta.

• Por otro lado, has comentado también “MCP by default” y me parece muy interesante ya que hubo o hay un boom alrededor de este concepto, naciendo MCPs de debajo de las piedras. ¿Qué riesgos reales tiene abusar de este concepto o usarlo cuando realmente no se necesita?

El boom de MCP es un caso de libro de lo que pasa cuando una tecnología resuelve un problema real pero la industria la sobreextiende hasta convertirla en un martillo que busca clavos.

MCP tiene valor genuino. Cuando necesitas contratos de herramientas estructurados, límites de autenticación OAuth y acceso multi-tenant gobernado, es la solución correcta. El problema es que estamos viendo equipos y vendors usarlo como capa de integración por defecto, incluso cuando un CLI bien diseñado con --help decente y respuestas JSON estructuradas daría exactamente lo mismo sin el overhead del protocolo.

El primer riesgo real es lo que llamamos el “abstraction tax”. Cada capa de protocolo entre un agente y una API pierde fidelidad. Para APIs simples eso es tolerable; para APIs complejas, esas pérdidas se acumulan. El agente recibe una versión empobrecida de la interfaz original, y eso se traduce en comportamiento degradado o en prompts cada vez más elaborados para compensar.

El segundo riesgo es de seguridad, y este es el que más nos preocupa. Las APIs internas típicamente exponen datos sensibles o permiten operaciones destructivas. Cuando un desarrollador humano las consume, hay arquitectura, code reviews y contexto organizacional que mitigan esos riesgos. Cuando haces una conversión naïve de API a MCP y se la entregas a un agente autónomo, eliminas esas salvaguardas. No hay forma determinista de prevenir que el agente abuse de esos endpoints. Y aquí aparece de nuevo el lethal trifecta: datos privados, contenido no confiable, acción externa. La mayoría de los MCP servers útiles lo cumplen por defecto.

El tercer riesgo es de complejidad operacional innecesaria. MCP introduce overhead de mantenimiento, versionado y gobernanza. Si lo adoptas sin necesitarlo, estás pagando ese coste sin recibir el beneficio.

Lo que recomendamos es una pregunta previa obligatoria: ¿tu sistema realmente requiere interoperabilidad a nivel de protocolo? Si la respuesta no es un “sí” claro, un CLI bien diseñado o una función directa es mejor opción. MCP tiene su lugar, pero ese lugar no es “en todas partes”.

• También me gustaría hablar del último riesgo que has apuntado “shadow IT acelerado por IA”. ¿Cómo afecta realmente esto a una organización? ¿Qué implicaciones tiene en todos los sentidos, incluyendo los costes o la seguridad?

Este es uno de los riesgos que más nos preocupa precisamente porque no parece peligroso hasta que ya es demasiado tarde.

Lo que estamos observando es una versión turbocargada de algo que ya existía. Las hojas de cálculo que “silenciosamente gobiernan el negocio” llevan décadas siendo un problema. Pero ahora, con herramientas como Claude Cowork, n8n con integración de APIs de IA, o simplemente un product manager con acceso a un coding agent, el salto de “automatización informal” a “sistema crítico no gobernado” se produce en días, no en meses.

El impacto organizacional es multidimensional.

En seguridad, el problema central es que estos sistemas se construyen sin threat modeling, sin revisión de permisos, sin gestión de secretos. Un workflow de n8n que conecta Slack con un CRM vía OpenAI puede estar exfiltrando datos de clientes sin que nadie lo sepa. Y aquí vuelve el lethal trifecta: datos privados, contenido no confiable, acción externa. Ese workflow lo cumple por defecto.

En costes, el problema es la invisibilidad. Los equipos de finanzas no ven las llamadas a APIs de modelos que se están acumulando en tarjetas corporativas o cuentas cloud personales. Hemos visto organizaciones con docenas de integraciones paralelas haciendo llamadas redundantes a GPT-4 porque nadie sabía que el equipo de al lado ya había resuelto el mismo problema.

En deuda técnica y gobernanza, lo que empieza como un prototipo desechable se convierte en infraestructura crítica. Nadie lo documenta, nadie lo testea, y cuando el creador original se va, nadie sabe cómo funciona. Es exactamente el patrón de las macros de Excel, pero con capacidad de ejecutar acciones en sistemas externos.

Lo que recomendamos no es prohibir, sino canalizar. Sandboxes internos instrumentados donde los no-desarrolladores puedan experimentar con visibilidad. Un catálogo compartido de workflows existentes para evitar duplicación. Y criterios claros para determinar cuándo un prototipo necesita convertirse en una aplicación de producción con ingeniería real detrás.

La IA democratiza la construcción de software. Eso es genuinamente valioso. Pero democratizar sin gobernar es simplemente acelerar el caos.

• Muchas gracias por toda esta información tan valiosa que nos estás dando. Para terminar la entrevista y concluir, en pocas palabras, ¿qué crees que tenemos que tener en cuenta tanto los profesionales del sector como las empresas para sobrevivir a este tsunami que ya está aquí?

Lo que hemos aprendido de todos estos ciclos del Radar se puede condensar en algo que puede sonar paradójico: la mejor forma de adaptarse a la velocidad de la IA es invertir en lo que no cambia.

Los fundamentos de ingeniería —código limpio, testing, diseño deliberado, feedback loops cortos— no son nostalgia. Son exactamente lo que permite que la IA amplifique valor en lugar de amplificar caos. Lo hemos visto una y otra vez.

Para los profesionales, el mensaje es claro: no compitas con la IA en velocidad de generación de código. Compite en juicio. En capacidad de hacer las preguntas correctas, de detectar cuándo un agente está tomando un camino equivocado, de entender el sistema completo. Eso es lo que la IA no puede reemplazar todavía, y es lo que más valor tiene ahora mismo. Invierte en entender profundamente los sistemas que construyes, no solo en construirlos más rápido.

Para las empresas, el error más costoso que podemos ver es tratar la IA como una iniciativa de productividad individual en lugar de una transformación sistémica. Si introduces agentes sobre procesos rotos, sobre codebases sin disciplina, sobre equipos sin cultura de feedback, simplemente vas a llegar al desastre más rápido.

Y hay algo que me parece crítico para ambos: aprender a distinguir entre velocidad y progreso. Más PRs, más líneas de código, más workflows automatizados no son progreso si el rework rate sube, si nadie entiende lo que se ha construido, si la deuda cognitiva se acumula silenciosamente.

El tsunami ya está aquí, sí. Pero los que van a sobrevivir no son los que nadan más rápido. Son los que saben cuándo nadar, cuándo parar y cuándo cambiar de dirección.

Si quieres tener el contenido de la entrevista en PDF, puedes descargártelo directamente.

Conclusiones

Para mí, una de las conclusiones más relevantes es que los fundamentos de ingeniería (testing, observabilidad o diseño arquitectónico) nunca han sido más críticos que ahora, no porque sean nuevos, sino porque su ausencia tiene consecuencias inmediatas y a gran escala en un entorno donde los agentes pueden generar código nuevo y cambios de código masivos en minutos.

Me gusta como concluye la entrevista con el mensaje claro, tanto para profesionales como para organizaciones, de que la mejor forma de adaptarse a la velocidad de la IA es invertir en lo que no cambia. La clave no es competir con la IA en velocidad de generación, sino en juicio, criterio técnico y comprensión profunda de los sistemas.

En mi opinión, y creo que comparto la opinión del radar, las empresas que traten la IA como una iniciativa de productividad individual en lugar de una transformación sistémica corren el riesgo de llegar al desastre más rápido.

Espero que os haya gustado el enfoque que he dado al artículo y, como comentaba, publicaremos otro artículo con el “making of”, el repositorio y los detalles técnicos del RAG usado. ¡Te leo en comentarios! 👇

También revisamos las limitaciones de ese enfoque, que forzaron la transición estocástica de los años 80 y 90, donde los modelos estadísticos (n-gramas y HMM) empezaron a inferir información directamente desde los datos.

Estos modelos rápidamente se toparon con la dispersión de datos y la ceguera semántica del one-hot encoding.

En este post veremos la introducción de conceptos como Word2Vec, redes neuronales recurrentes (RNN) y redes Long-Short Term Memory (LSTM).

La revolución de las representaciones distribuidas: Word2Vec

Los sistemas tradicionales asignaban un índice arbitrario a cada término, creando matrices gigantescas donde las relaciones semánticas desaparecían por completo. Esta falta de vinculación impedía que el software extrajera valor real de los datos no estructurados. En 2013, un equipo de investigadores liderado por Tomas Mikolov presentó Word2Vec.

Word2Vec propuso un modelo basado en redes neuronales superficiales que nos permite representar palabras en un espacio continuo, como vectores densos (generalmente de entre 50 y 300 dimensiones, en lugar de decenas de miles). Este modelo mejoraba la relación semántica y matices de las palabras con una alta precisión.

Word2Vec transformó el texto plano en vectores densos dentro de un espacio continuo y logró que conceptos similares coexistieran en zonas matemáticas cercanas.

La arquitectura de Word2Vec introdujo dos variantes de modelos predictivos para calcular las representaciones continuas de las palabras a partir de corpus de texto extensos:

• Continuous Bag-of-Words (CBOW): la red neuronal predice la probabilidad de una palabra objetivo actual basándose en la ventana de palabras del contexto que la rodea.
• Skip-Gram: opera bajo el principio inverso al de CBOW. Utiliza la palabra actual para predecir las palabras que la rodean dentro de un rango o ventana determinada.

Gracias a este enfoque, se pudieron capturar analogías de patrones semánticos y sintácticos, como la famosa ecuación vectorial: “rey – hombre + mujer ≈ reina”.

El modelo dedujo, sin instrucción externa, el vector que representaba el concepto de "realeza" y el vector de "género", lo que le permitió navegar por el léxico como si fuera un plano de coordenadas geográficas.

Todo esto a través de simples operaciones vectoriales y mediciones por similitud de coseno, sin recurrir a costosos procesos de computación.

Su bajo coste computacional y libre disponibilidad de código, publicado en abierto para la comunidad de investigación, impulsaron casi instantáneamente la adopción del uso de embeddings en todo el espectro del PLN.

Este hito marcó el camino hacia las arquitecturas de aprendizaje profundo, específicamente las Redes Neuronales Recurrentes (RNN) y, más tarde, los modelos basados en la arquitectura Transformers (Church, 2017).

La llegada del Aprendizaje Profundo (DL) y la gestión del contexto: Redes Neuronales Recurrentes (RNN)

Superado el reto de dar significado a las palabras de forma aislada, el siguiente gran desafío fue entender el contexto. El lenguaje es, por naturaleza, una secuencia temporal. Aquí el orden de los factores sí altera (y drásticamente) el producto.

Por eso, un sistema conversacional no puede tratar los textos como simples bolsas de palabras desordenadas, necesita una memoria dinámica capaz de evolucionar al mismo ritmo que la propia frase.

El DL revolucionó el campo del PLN al permitir el desarrollo de modelos mucho más eficientes y potentes en la gestión de datos secuenciales. Dentro de las múltiples arquitecturas del DL destacan las RNN, que fueron introducidas en los años 80 como una mejora respecto a las redes neuronales tradicionales.

A diferencia de las redes tradicionales, donde la información fluye unidireccionalmente desde las capas de entrada hacia las capas de salida, las arquitecturas RNN introdujeron conexiones recurrentes en sus neuronas ocultas.

Esta recurrencia funcionaba como una memoria a corto plazo que dotaba al sistema de un contexto continuo. De este modo, al procesar una secuencia, las RNN empezaron a capturar de forma natural las dependencias temporales del texto.

Sin embargo, al implementar RNNs profundas en tareas complejas como los chatbots generativos, los equipos de investigación se percataron del problema del descenso del gradiente, un fenómeno que saboteaba por completo la memoria a largo plazo del sistema.

Durante el entrenamiento, mediante el algoritmo de retropropagación a través del tiempo, el cálculo de errores exige multiplicar las matrices de pesos de forma iterativa.

Si esos valores son inferiores a la unidad, el gradiente se reduce exponencialmente hasta desaparecer de las ecuaciones. La consecuencia práctica fue un escenario donde los chatbots olvidaban el inicio de la frase al llegar al segundo párrafo del diálogo.

Las RNN tradicionales eran incapaces de conectar una petición inicial con una respuesta final si la secuencia superaba un límite de palabras, por lo que terminaba empañando la experiencia del usuario.

La solución a largo plazo: redes Long Short-Term Memory (LSTM) (1997)

Para solucionar el problema del descenso del gradiente, los investigadores Sepp Hochreiter y Jürgen Schmidhuber desarrollaron en 1997 las Long Short-Term Memory (LSTM), una arquitectura que redefiniría el procesamiento secuencial.

Las LSTM eran capaces de preservar información relevante durante periodos de tiempo significativamente más prolongados. En lugar de permitir que los nuevos datos destruyeran el contexto previo, establecieron un canal central de memoria protegido por tres capas de redes neuronales:

1. Forget gate: descarta la información obsoleta mediante un filtrado que limpia el ruido del sistema. Analiza el contexto de la palabra en curso y el estado previo para devolver un valor entre cero y uno.
2. Input gate: selecciona los nuevos datos que merecen incorporarse a la memoria a largo plazo. Así evita la saturación del espacio de almacenamiento con términos irrelevantes.
3. Output gate: determina qué porción del contexto acumulado debe transmitirse al siguiente paso secuencial. Esto regula la respuesta inmediata que hereda el sistema.

La integración de estas estructuras ayudó a mitigar casi en su totalidad el descenso del gradiente.

Esto permitía un modelado conversacional más coherente, donde un agente artificial podía recordar el nombre o la intención del usuario a través de múltiples turnos de diálogo.

Conclusiones

En este post hemos analizado cómo el éxito de los sistemas conversacionales dependía de resolver un delicado equilibrio entre la representación semántica y la gestión de la memoria.

Mientras que Word2Vec transformó el significado de las palabras en coordenadas accesibles, las arquitecturas RNN y LSTM consiguieron que las máquinas capturaran la naturaleza secuencial y temporal del lenguaje humano.

Sin embargo, la búsqueda de una comprensión aún más profunda y escalable no se detuvo ahí.

En el próximo post daremos el gran salto hacia la era moderna de la IA, donde analizaremos la llegada de los modelos Seq2Seq, el nacimiento de los mecanismos de atención, y la arquitectura Transformers.

¡Nos vemos en la siguiente entrega!

Referencias

• LSTM
• Fundamentals of Recurrent Neural Network (RNN) and Long Short-Term Memory (LSTM) Network

Suena bastante bien. El problema es que una inteligencia artificial puede ser extremadamente eficiente y, al mismo tiempo, estar haciendo exactamente lo equivocado.

Estos son cuatro ejemplos que lo demuestran.

Cuando Barbie se convierte en una tragedia

En 2023, un medio de comunicación estadounidense utilizó inteligencia artificial para generar automáticamente artículos sobre tendencias a partir de lo que estaba ocurriendo en redes sociales.

La película de Barbie era uno de los grandes fenómenos del momento. El problema llegó cuando el sistema se encontró con expresiones coloquiales y exageraciones habituales en redes sociales.

Frases como “I'm dying”, utilizada para expresar entusiasmo o diversión, fueron interpretadas literalmente. El resultado fue un artículo cuyo titular hablaba de una supuesta reunión de miles de personas para cometer un asesinato en masa en honor a Barbie.

Una expresión que para una persona resulta evidentemente metafórica puede convertirse para una máquina en un dato que interpretar literalmente.

La IA que descubrió que ganar no era necesario

Otro ejemplo muy conocido procede de un experimento de aprendizaje por refuerzo realizado en el videojuego Coast Runners. El objetivo era sencillo: conseguir la máxima puntuación y completar la carrera.

Pero la inteligencia artificial descubrió que podía obtener más puntos explotando una determinada mecánica del juego.

En lugar de competir y llegar a la meta, comenzó a dar vueltas en una zona concreta del circuito, chocando repetidamente contra obstáculos para conseguir potenciadores.

Desde nuestra perspectiva, estaba jugando fatal. Desde la perspectiva del algoritmo, estaba haciendo exactamente lo que se le había pedido: maximizar la puntuación. De hecho, consiguió una puntuación superior a la de los jugadores humanos.

El experimento demuestra uno de los problemas más interesantes de los sistemas de IA: si definimos mal el objetivo, la máquina puede encontrar estrategias que optimicen el indicador pero destruyan el propósito real de la tarea.

El algoritmo que confundió tanques con nubes

Durante la Guerra Fría, el ejército estadounidense investigó el uso de redes neuronales para detectar tanques camuflados en fotografías aéreas.

Los resultados iniciales parecían espectaculares. El sistema alcanzaba una precisión del 100% con las imágenes utilizadas durante las pruebas. Pero cuando se enfrentó a fotografías nuevas, el rendimiento se desplomó.

La explicación era mucho más sencilla de lo que parecía: las fotografías de los tanques se habían tomado en días nublados, mientras que las imágenes del bosque sin tanques correspondían a días soleados.

La inteligencia artificial no había aprendido a detectar tanques, había aprendido a distinguir fotografías con cielos grises de fotografías con cielos despejados.

Este caso es un ejemplo clásico de overfitting y de uno de los grandes riesgos de la inteligencia artificial: un modelo puede encontrar correlaciones que funcionan perfectamente con los datos de entrenamiento, pero que no tienen ninguna relación con el problema que queremos resolver.

El robot aspirador que decidió escapar

En 2022, un robot aspirador de un hotel de Cambridge protagonizó una pequeña aventura cuando consiguió salir del edificio a través de una puerta automática.

El sensor encargado de detectar desniveles no identificó correctamente el pequeño bordillo de la entrada. Para el sistema, el suelo continuaba al otro lado de la puerta, así que siguió avanzando.

Los empleados tardaron varias horas en darse cuenta de que el robot había desaparecido. Finalmente apareció al día siguiente, escondido bajo un seto y sin batería, después de pasar la noche intentando aspirar el exterior del hotel.

Historias distintas con un aprendizaje común

Estas cuatro historias son muy diferentes, pero tienen algo en común. En ninguno de los casos la inteligencia artificial estaba intentando hacer algo mal. Al contrario: estaba tratando de cumplir el objetivo que se le había marcado.

El problema aparece cuando existe una diferencia entre lo que las personas queremos conseguir y aquello que realmente estamos pidiendo al sistema que optimice.

Por eso, a medida que los sistemas de IA empiezan a asumir tareas más complejas y tomar decisiones con mayor autonomía, el contexto, la supervisión y la correcta definición de los objetivos se vuelven tan importantes como la capacidad del propio modelo.

No basta con conseguir que una IA haga algo. También tenemos que asegurarnos de que entiende qué significa hacerlo bien.

El punto de partida es una pregunta incómoda: si mañana tuvieras carta blanca para rediseñar tu plataforma con criterios ambientales, sociales y de gobernanza como condición, ¿seguirías tomando las mismas decisiones que hoy? A partir de ahí, construimos un mapa de ocho decisiones tecnológicas clave donde esa integración es posible y necesaria.

¿La conclusión? Decidir tecnología es decidir el futuro. Las plataformas con propósito no son más caras ni más lentas, son más competitivas, y las organizaciones que lo entiendan antes tendrán una ventaja difícil de replicar.

Plataformas tecnológicas con propósito: integrando criterios ESG desde el diseño

¿Seguirías tomando las mismas decisiones tecnológicas si ESG fuera una condición de diseño y no un añadido? Con esa pregunta arranca esta serie. Argumentamos por qué los criterios ambientales, sociales y de gobernanza han dejado de ser un complemento de la estrategia para convertirse en su núcleo y presentamos el mapa de 8 decisiones tecnológicas clave desde el que construir plataformas con propósito real.

Plataformas tecnológicas con propósito: alineando tecnología, negocio y sostenibilidad

Profundizamos en los primeros cuatro pilares del mapa: arquitectura cloud sostenible, IA responsable, diseño inclusivo y plataformas interoperables. Cada decisión tiene impacto directo en los tres ejes ESG y, lejos de ser un coste, genera ventajas competitivas tangibles: reducción de huella de carbono, confianza regulatoria, ampliación de mercado y eliminación de silos que frenan la innovación.

Plataformas tecnológicas con propósito: gobernanza, seguridad y resiliencia digital

Cerramos el mapa con los cuatro pilares que garantizan la integridad y la continuidad del ecosistema digital: gobierno del dato y trazabilidad, ciberseguridad y resiliencia, integración ESG en la cadena de suministro y optimización del ciclo de vida del software. Porque una plataforma con propósito no solo se construye bien, también se gestiona y protege con el mismo nivel de consciencia.

De hecho, implantar IA sobre procesos ineficientes es un poco como ponerle un motor de carreras a un coche que no tiene frenos: solo acelerará el desastre.

La verdadera agilidad no consiste en coleccionar las últimas herramientas del mercado, sino en diseñar un sistema donde las personas trabajen a gusto y el valor fluya sin atascarse en silos jerárquicos.

En este recopilatorio dejamos a un lado la teoría abstracta y vemos las principales claves sobre transformación y cultura de ingeniería:

• Deuda organizacional: cómo identificar y limpiar esas ineficiencias internas que queman a tu equipo mucho más que la deuda técnica.
• Extreme Programming (XP) al rescate: por qué las prácticas de ingeniería de los 90 son hoy el mejor escudo frente al burnout en la era de la IA.
• La operativa real: las tres barreras invisibles que hacen que tus mejores planes estratégicos se rompan al chocar con el día a día.
• El "Sprint Cero": una defensa firme de por qué parar a pensar un poco al principio te ahorra meses de parches y dramas en el futuro.

¿Empezamos? 👇

La IA no resolverá tus problemas organizativos

La IA no soluciona las taras de una empresa, funciona como un espejo que las amplifica. Implantar herramientas de IA sobre silos de información, desalineamiento de objetivos o falta de foco estratégico no arregla los flujos internos, solo hace más evidente la lentitud burocrática. La IA es un acelerador potente, pero necesita que el sistema organizativo y la cultura corporativa estén preparados para adoptarla. Si el terreno no es el adecuado, la tecnología solo automatizará la ineficiencia.

Por qué XP (y no la IA) es lo que evitará que tu equipo se queme

La Inteligencia Artificial promete generar código de forma instantánea, pero la velocidad desmedida puede quemar a los equipos de desarrollo. Si quieres evitar este tipo de colapsos, en este post recuperamos los principios de Extreme Programming (XP) como un mecanismo técnico de sostenibilidad humana. Prácticas clásicas como el ritmo sostenible, el Pair Programming evolucionado frente a la amenaza del incontrolable Vibe Coding, y el desarrollo guiado por pruebas (TDD) actúan como contrapesos necesarios para mitigar la ansiedad y garantizar la mantenibilidad y diseño del software en la era de la IA.

Tres barreras sistémicas que ningún excel detecta y cómo superarlas

Cuando los planes estratégicos fallan, no suele ser por falta de visión, sino por ceguera sistémica. Vemos las tres dimensiones invisibles que fracturan la ejecución en la operativa: la barrera cognitiva (el colapso por incertidumbre y falta de seguridad psicológica), la estructural (la trampa de la optimización local por incentivos de silo) y la de flujo (el valor estancado en colas de espera invisibles). Superarlo exige cambiar el control jerárquico por la arquitectura del sistema, aplicando Value Stream Management (VSM) y métricas de conducta compartidas (KBIs).

¿Qué es la deuda organizacional y por qué tu empresa necesita gestionarla hoy?

Así como medimos la deuda técnica en el software, las empresas acumulan una deuda organizacional silenciosa: procesos obsoletos, silos y roles difusos que frenan la proactividad. ¿Sabes que puedes mitigar este problema estructural aplicando patrones de la ingeniería y el movimiento Lean? Vemos cómo visibilizar la deuda en un backlog colaborativo, priorizar las acciones según su ROI en el negocio, ejecutar planes de acción pragmáticos e iterativos, y reservar una capacidad orgánica continua para su refactorización interna.

¿Qué hay que tener en cuenta antes del primer Sprint?

A pesar de que la ortodoxia de Scrum no reconoce el "Sprint Cero", la práctica demuestra que lanzarse a picar código en el Sprint 1 sin asentar las bases aboca el proyecto al fracaso. En este post te contamos el por qué de la necesidad de un periodo de descubrimiento para alinear expectativas, dimensionar riesgos, acordar las reglas del juego y estructurar una primera versión del backlog junto al cliente. Un ejercicio de mitigación temprana indispensable para forjar la confianza del equipo, diseñar un roadmap adaptativo y pensar lo justo al principio para no pagar las consecuencias después.

Hablamos de decisiones técnicas aparentemente pequeñas que tienen un impacto enorme en usuarios con dificultades motrices o en pantallas táctiles, de hacia dónde evoluciona el estándar internacional de accesibilidad y qué significa ese cambio para quienes construyen productos digitales.

Además, hay algo que muchas veces se olvida: la accesibilidad también es responsabilidad de quien escribe. Encabezados, enlaces, emojis, imágenes, todas son decisiones editoriales que marcan la diferencia para muchos usuarios y mejoran la experiencia de todo el mundo.

Target Size, el gran ignorado de la accesibilidad

Un icono de 16x16 píxeles puede parecer un detalle menor, pero para alguien con dificultades motrices o en una pantalla táctil puede ser una barrera real. En este post exploramos el criterio Target Size de las WCAG, qué tamaños mínimos exige en los niveles AA y AAA, cómo cumplirlos con padding sin alterar el diseño visual, y una extensión de navegador creada específicamente para analizar estos elementos directamente en cualquier página.

WCAG 3.0: cómo está cambiando la forma de entender la accesibilidad web

Las WCAG 3.0 siguen siendo un borrador, pero ya dejan ver un cambio profundo en la forma de evaluar la accesibilidad. Este post analiza las novedades más relevantes: el nuevo sistema de conformidad con niveles Bronce, Plata y Oro, el concepto de declaraciones de rendimiento funcional que describe limitaciones de uso en lugar de discapacidades concretas, y cómo el modelo pasa de ser binario a estar basado en la experiencia real del usuario.

Escribe mejor para todo el mundo: guía de accesibilidad para la redacción de contenidos web

La accesibilidad no empieza ni termina en el código. Quien escribe también tiene una responsabilidad. Este post recorre cinco buenas prácticas editoriales: estructurar el contenido con encabezados jerárquicos, escribir texto alternativo que transmita el mensaje y no solo describa la imagen, usar enlaces que tengan sentido por sí solos, moderar el uso de emojis que los lectores de pantalla traducen literalmente, y evitar contenido visual que pueda provocar ataques fotosensibles.

Extreme Programming lleva casi treinta años entre nosotros, discretamente eclipsado por Scrum y Kanban, pero nunca tan relevante como ahora. No porque la industria lo haya redescubierto por nostalgia, sino porque la irrupción de la IA Generativa ha puesto en evidencia exactamente el problema que XP fue diseñado para resolver: ¿cómo vas rápido sin romper el producto ni quemar al equipo?

En este recopilatorio hablamos de los fundamentos de XP y su evolución a lo que Justin Beall denomina AI-XP. La IA no hace obsoleto el marco, lo potencia. De Pair Programming a Cyborg Pairing, Planning Game y TDD como red de seguridad, hablamos de cómo XP se adapta a los tiempos de la IA.

Eso sí, el marco trae sus propias paradojas: ¿estamos volviendo a la hiper-documentación para que la IA nos entienda? ¿Se convierte la IA en el nuevo silo de conocimiento que XP siempre quiso eliminar?

AI-XP: del manifiesto del craftsmanship a la era de la IA

Kent Beck no inventó nada radicalmente nuevo cuando creó XP: recopiló lo que funcionaba y lo llevó al extremo. Tres décadas después, la IA Generativa nos plantea el mismo reto en sentido inverso: tenemos una herramienta que genera código a velocidad vertiginosa, pero sin la estructura adecuada solo acelera el caos. En este post exploramos cómo XP evoluciona hacia AI-XP con nuevos bucles de retroalimentación que integran la inteligencia artificial en la planificación, las iteraciones y la ejecución diaria, y las paradojas que ese modelo trae consigo.

La paradoja de la velocidad: por qué XP (y no la IA) es lo que evitará que tu equipo se queme

Si la IA no se cansa, ¿esperamos que nuestros equipos humanos sigan ese ritmo? En este segundo post abordamos el lado humano de la ecuación: el ritmo sostenible, la seguridad psicológica y el fin del lobo solitario que XP lleva décadas defendiendo como reglas técnicas, no como soft skills. También revisamos qué ocurre con el Pair Programming cuando entra la IA en la ecuación, por qué el Vibe Coding es una trampa y cómo el TDD se convierte, paradójicamente, en la herramienta de productividad más potente de la era artificial.

La clave de una interfaz memorable está en la fluidez de sus microinteracciones y en la precisión del feedback gráfico que recibe quien navega por la web.

En este recopilatorio nos centramos en exprimir el rendimiento de GSAP (GreenSock Animation Platform) a través de dos guías de código puramente prácticas.

Te enseñamos a estructurar un efecto de partículas en el DOM controlando variables físicas como la gravedad o la velocidad, y a implementar un cursor tracking fluido que reaccione al movimiento del ratón en tiempo real sin penalizar la carga ni la maquetación del navegador.

Prepara tu entorno de desarrollo y dale una dosis extra de reactividad y dinamismo a tus proyectos web.

Cómo usar GSAP para crear efectos de partículas en el DOM

No hace falta saturar una web con animaciones pesadas; a veces, el secreto de una buena UX está en el feedback visual de las microinteracciones. En este post te enseñamos a estructurar un efecto de partículas en el DOM utilizando GSAP y su plugin Physics2DPlugin. Vemos paso a paso cómo registrar el plugin, capturar los elementos HTML esenciales y configurar variables físicas como la gravedad, la velocidad o la cantidad de partículas. Un flujo limpio y mantenible mediante Custom Properties de CSS para transformar la respuesta visual de cualquier botón.

Cursor tracking con GSAP: dándole vida al movimiento del ratón

El movimiento del ratón es una excelente oportunidad para enriquecer la UX, y el cursor tracking con GSAP permite exprimirlo con un gran rendimiento. Te explicamos cómo implementar efectos interactivos fluidos y cursores personalizados basados en las coordenadas del puntero. En esta guía técnica vemos la captura de eventos en tiempo real, el suavizado de los movimientos y cómo evitar problemas clásicos de rendimiento al manipular el DOM en maquetaciones complejas. Una solución directa para aportar reactividad y dinamismo a la interfaz web.

Cada vez es más habitual encontrar sistemas de IA en asistentes virtuales, chatbots de atención al cliente, herramientas de generación de contenido, cámaras inteligentes, robots autónomos o aplicaciones capaces de analizar enormes cantidades de información en cuestión de segundos.

Sin embargo, aunque estos avances son impresionantes, existe una realidad que a menudo pasa desapercibida: la inteligencia artificial también se equivoca, y algunas de esas equivocaciones pueden llegar a ser tan sorprendentes como divertidas.

En este episodio analizamos cuatro casos reales que se hicieron virales en todo el mundo y que demuestran que la IA, por muy avanzada que sea, sigue teniendo importantes limitaciones.

El chatbot que casi vende un coche por un dólar

Uno de los casos más conocidos fue el de un concesionario de automóviles que incorporó un chatbot basado en inteligencia artificial para responder automáticamente a las consultas de los clientes.

Lo que parecía una excelente forma de mejorar la atención terminó convirtiéndose en un problema cuando un usuario consiguió manipular las respuestas del sistema mediante instrucciones cuidadosamente redactadas.

El resultado fue una conversación que parecía cerrar la venta de un vehículo valorado en decenas de miles de dólares por un precio irrisorio. Aunque la operación nunca llegó a realizarse, esta historia dejó claro que los modelos de lenguaje necesitan controles, supervisión y una configuración adecuada para evitar respuestas incoherentes.

Un abogado, ChatGPT y sentencias que nunca existieron

Otro ejemplo muy llamativo tuvo lugar en el ámbito legal. Un abogado decidió utilizar ChatGPT como apoyo para preparar la documentación de un juicio y terminó presentando referencias a sentencias que nunca habían existido.

El sistema había generado información falsa con apariencia completamente real, un fenómeno conocido como "alucinación" en inteligencia artificial.

Este incidente puso de manifiesto la importancia de verificar siempre cualquier dato generado por una IA, especialmente cuando se utiliza en contextos profesionales donde la precisión resulta imprescindible.

El algoritmo que siguió al árbitro en vez del partido

El deporte tampoco ha escapado a este tipo de errores tecnológicos. Durante un partido de fútbol retransmitido mediante un sistema de cámaras automatizadas con visión artificial, el algoritmo confundió repetidamente la cabeza calva de un juez de línea con el balón.

Como consecuencia, la retransmisión dejó de seguir el juego para enfocar al árbitro durante buena parte del encuentro.

Aunque esta anécdota provocó miles de comentarios en redes sociales, también sirvió para explicar cómo funcionan los sistemas de visión por computadora, que identifican patrones visuales pero carecen del contexto y del sentido común que posee una persona.

El robot de reparto: entrega completada, contexto ignorado

La última historia de este episodio tiene como protagonista a un robot autónomo de reparto.

Mientras seguía la ruta programada para entregar un pedido, atravesó sin detenerse el perímetro de una escena policial acordonada.

El robot no entendía el significado de las cintas de seguridad ni era capaz de interpretar la gravedad de la situación. Simplemente continuó siguiendo las instrucciones de navegación para completar su recorrido.

Este ejemplo demuestra que una máquina puede cumplir perfectamente una tarea concreta y, al mismo tiempo, ser incapaz de comprender el contexto que la rodea.

Cuatro errores, una misma lección

Todos estas historias comparten una misma conclusión: la inteligencia artificial no piensa como un ser humano.

Analiza patrones, procesa datos y genera respuestas basándose en probabilidades, pero no comprende realmente el significado de aquello que hace.

Carece de intuición, experiencia, criterio propio y sentido común, por lo que siempre necesita supervisión humana cuando sus decisiones pueden tener consecuencias importantes.

Lo que nació como una forma sencilla de compartir conocimiento sobre Google Cloud se acabó convirtiendo en una comunidad increíble de más de 240.000 escuchas y en un punto de encuentro para los/as profesionales del sector.

Las buenas historias merecen un gran cierre y, aunque los micrófonos ya se han apagado, no queríamos dejarte sin un último mapa de carreteras técnico.

Por eso, te traemos este recopilatorio especial con los cinco capítulos más potentes y recientes del canal, ideales para entender cómo hemos pasado de pelearnos con los prompts de un chatbot a diseñar ecosistemas complejos basados en la Web Agéntica y la automatización total.

Prepara tus auriculares y dale al play para repasar con el equipo de Goodly desde el potencial de los protocolos MCP y las Skills en Gemini, hasta el gobierno de la IA con Vertex AI o el duelo definitivo de la automatización entre n8n y Google Workspace.

¡Arrancamos con este último gran viaje por la infraestructura actual!

Guía definitiva de los nuevos protocolos de la IA

Pasamos del software pasivo a la "web agéntica": agentes autónomos que buscan, negocian y compran por nosotros/as.

En este episodio, nuestro equipo de Goodly analiza los protocolos que definen este nuevo stack tecnológico. Repasan cómo MCP (Anthropic) conecta LLMs con datos externos, la comunicación entre IA mediante A2A y Agent-to-UI, y el impacto de UCP en el eCommerce.

Nos asomamos a un escenario donde el cliente final es un algoritmo, lo que obliga a cambiar por completo las reglas del SEO tradicional y las estrategias de posicionamiento.

Los MCPs y Skills llegan a Gemini. Diferencias clave y casos de uso

La llegada de MCP y Skills a Gemini Enterprise entierra las integraciones a medida. Analizamos en este podcast cómo personalizar la IA corporativa sin el coste de entrenar modelos desde cero.

Mientras el protocolo MCP estandariza la conexión segura de sistemas con agentes de IA, las Skills funcionan como "recetas" en Markdown que otorgan capacidades específicas sin saturar el contexto del modelo.

Combinar ambas tecnologías duplica la precisión y ofrece una portabilidad real para saltar entre entornos como Cursor, Claude o Gemini casi sin despeinarse.

¿El próximo gran hit de Google? Descubriendo los experimentos de IA más prometedores

La era de las aplicaciones AI Native ya es una realidad y el laboratorio de Google no para de lanzar prototipos.

Vemos en detalle los experimentos más prometedores de Google Labs: desde herramientas creativas como Pomelli (campañas de marketing mediante una URL) o Stitch (diseño de interfaces que exporta a Figma), hasta apuestas técnicas como Project Genie, que genera mundos jugables con una frase, y Jules, un agente autónomo que firma Pull Requests directamente en GitHub.

¡Una radiografía perfecta de hacia dónde se dirige el desarrollo de software!

Vertex AI: el centro de mando de la GenAI empresarial

Vertex AI ya no es solo para Machine Learning tradicional, es el ecosistema central de Google Cloud para gobernar y escalar IA generativa enterprise.

Nos adentramos en este universo para ver la creación visual de agentes con Agent Designer, el despliegue en producción mediante Agent Engine y la integración de datos corporativos con Vertex AI Search y Vector Search (RAG).

Además, analizamos la seguridad con Model Armor y cómo Gemini Enterprise democratiza el uso de estas herramientas poniéndolas a un clic del usuario de negocio.

¿Quiere Google matar a n8n?Opal y Workspace Studio a debate

¿Quién se quedará con el trono de la automatización? Google Opal llega como una propuesta experimental para montar prototipos multimodales solo con lenguaje natural.

Si buscas exprimir Gemini de forma nativa en Gmail o Drive, Workspace Studio es la opción clave para la productividad diaria.

En el otro extremo, el veterano n8n sigue siendo imbatible si necesitas flujos lógicos complejos, grandes volúmenes de datos y un despliegue self-hosted que garantice la privacidad absoluta del negocio.

Bonus: el último episodio del canal

En este último capítulo tan especial, el equipo de Goodly echa la vista atrás para recordar los curiosos inicios del canal (¡cuando se grababa en mitad de la montaña!) y repasar las mejores anécdotas, debates internos y risas que nunca salieron en el guion.

Pero no todo es nostalgia: este episodio también mira hacia adelante para analizar hacia dónde se dirigen el futuro del ecosistema cloud y la Inteligencia Artificial. Una despedida cargada de agradecimiento para la comunidad que ha hecho posible superar las 240.000 escuchas. ¡Gracias por acompañarnos!

Ya no basta con anunciar un modelo más potente que el anterior o con conseguir una puntuación superior en un benchmark concreto.

A medida que estas herramientas se incorporan al desarrollo de software, la automatización, el análisis de información y los procesos empresariales, la pregunta realmente importante empieza a ser otra: ¿qué modelo funciona mejor para cada tipo de trabajo?
La comparativa entre ChatGPT 5.6 y Fable 5 refleja precisamente esta evolución. No hay un ganador absoluto, sino dos modelos con fortalezas diferentes.

Mientras Fable 5 destaca especialmente en razonamiento profundo, análisis y resolución de problemas complejos de programación, ChatGPT 5.6 apuesta por una mayor eficiencia, un mejor rendimiento en escenarios agénticos y una clara ventaja en coste y capacidades multimodales.

La elección, por tanto, depende cada vez menos de cuál es “el modelo más inteligente” y más de qué tipo de inteligencia necesita realmente cada organización o cada usuario.

ChatGPT 5.6: más inteligencia por token

Uno de los principales argumentos de la nueva generación de ChatGPT 5.6 es la búsqueda de una mayor eficiencia. La propuesta no consiste únicamente en ofrecer un modelo más potente, sino en conseguir más capacidad de razonamiento utilizando menos tokens y, por tanto, reduciendo el coste asociado a las tareas complejas.

Esta cuestión es especialmente relevante en entornos empresariales. El precio por token no siempre refleja el coste real de utilizar un modelo. Un sistema aparentemente barato puede terminar siendo más caro si necesita consumir una enorme cantidad de tokens para completar una tarea. Por eso, la eficiencia debe medirse teniendo en cuenta el coste total de resolver un problema, y no únicamente el precio unitario de cada token.

ChatGPT 5.6 se presenta además en diferentes niveles de capacidad (Sol, Terra y Luna), lo que permite ajustar el modelo a las necesidades concretas de cada tarea. La idea es sencilla: no utilizar siempre la máxima capacidad de razonamiento cuando el problema no lo requiere.

A esta estrategia se suma la posibilidad de configurar diferentes niveles de intensidad y un modo Ultra capaz de combinar múltiples agentes trabajando en paralelo. Esta orientación refuerza una de las principales apuestas de la nueva generación de modelos: pasar de responder preguntas a ejecutar tareas complejas mediante flujos de trabajo cada vez más autónomos.

En este sentido, el valor de ChatGPT 5.6 no está únicamente en su capacidad para generar una buena respuesta, también en su potencial para integrarse en procesos en los que intervienen herramientas externas, terminales, búsquedas y diferentes pasos de ejecución.

Fable 5: cuando el contexto y el razonamiento marcan la diferencia

Si ChatGPT 5.6 apuesta especialmente por la eficiencia y la capacidad agéntica, Fable 5 parece encontrar su principal fortaleza en otro terreno: la comprensión profunda del contexto y la resolución de problemas complejos.

La sensación de uso es, en muchos casos, la de estar trabajando con un modelo que entiende especialmente bien grandes cantidades de información y es capaz de mantener una visión global del problema. Esto resulta particularmente relevante en tareas de análisis, razonamiento prolongado y desarrollo de software sobre bases de código grandes.

La diferencia se hace especialmente visible cuando el trabajo requiere algo más que generar código que “parece correcto”. En proyectos reales, donde existen dependencias entre módulos, código heredado, restricciones técnicas y errores difíciles de reproducir, la capacidad de comprender el contexto completo puede marcar una diferencia importante.

Es precisamente en este tipo de escenarios donde Fable 5 consigue una ventaja significativa frente a ChatGPT 5.6.

Los benchmarks cuentan una historia diferente según el problema

Comparar modelos de inteligencia artificial únicamente a partir de benchmarks puede resultar engañoso. La razón es sencilla: el ganador cambia dependiendo del tipo de tarea que se esté midiendo.

En inteligencia general, ambos modelos se encuentran en una posición muy cercana. Diferencias pequeñas en una prueba concreta pueden estar dentro del margen de variabilidad y no necesariamente representan una superioridad clara de un modelo sobre otro.

Sin embargo, cuando se analizan capacidades específicas aparecen diferencias mucho más interesantes.

Uno de los terrenos donde ChatGPT 5.6 destaca especialmente es ARC-AGI 3, un benchmark diseñado para evaluar la capacidad de los modelos para enfrentarse a problemas nuevos y situaciones que no han encontrado previamente.

En este escenario, ChatGPT 5.6 Sol alcanza un 7,8 % de aciertos y establece un nuevo estado del arte, mostrando una capacidad especialmente destacada para orientarse ante problemas desconocidos.

La situación cambia radicalmente cuando se analiza la resolución de bugs reales en proyectos de software. En SWE-bench Pro, Fable 5 alcanza un 80% frente al 64,6% de ChatGPT 5.6.

La diferencia es considerable y apunta a una fortaleza concreta del modelo de Anthropic: su capacidad para enfrentarse a problemas complejos de ingeniería de software en contextos reales.

Esto demuestra por qué conviene mirar los benchmarks con perspectiva. No existe un único indicador capaz de definir qué modelo es mejor para todas las situaciones. Un modelo puede destacar en razonamiento abstracto y otro ofrecer mejores resultados en ingeniería de software, mientras un tercero puede ser más eficiente en tareas multimodales.

La pregunta correcta no es “¿qué modelo ha ganado?”, sino “¿qué modelo gana en la tarea que necesito resolver?”.

El coste: la ventaja silenciosa de ChatGPT 5.6

Hay un aspecto que quizá tenga menos impacto en los titulares, pero que puede ser decisivo cuando hablamos de uso empresarial: el coste.

Según las notas analizadas, ChatGPT 5.6 presenta una estructura de precios de aproximadamente 5 dólares por millón de tokens de entrada y 30 dólares por millón de tokens de salida, frente a los 10 y 50 dólares, respectivamente, de Fable 5.

Pero la diferencia más interesante no está únicamente en el precio por token. La eficiencia del modelo hace que, en determinadas tareas, el coste total por trabajo completado pueda situarse alrededor de un tercio del de su competidor.

Este factor cambia completamente la conversación cuando pasamos de experimentar con IA a desplegarla a escala.

Para un perfil de desarrollo que utiliza un modelo ocasionalmente, la diferencia de precio puede no ser determinante. Para una compañía que ejecuta miles o millones de tareas automatizadas, utiliza agentes de forma continua o integra modelos dentro de sus productos, la eficiencia económica puede convertirse en una de las principales ventajas competitivas.

En esta situación, disponer de diferentes niveles de capacidad también permite optimizar el consumo. Las tareas sencillas pueden resolverse con modelos más ligeros, reservando Sol para aquellos problemas que realmente requieren una mayor capacidad de razonamiento.

¿Cuál elegir?

La respuesta depende del tipo de trabajo.

Fable 5 parece la opción más adecuada cuando el objetivo principal es trabajar con código complejo, resolver bugs reales en bases de código grandes o realizar análisis que requieren razonamiento profundo y una comprensión prolongada del contexto.

También puede ser una buena elección cuando el coste no es la principal restricción y se prioriza el margen adicional de calidad en tareas complejas.

Por su parte, ChatGPT 5.6 resulta especialmente atractivo para escenarios agénticos, automatizaciones, integración con herramientas externas y tareas multimodales. Su estructura de costes lo convierte además en una opción especialmente interesante cuando existe un volumen elevado de operaciones y la factura final es un factor importante.

También ofrece una ventaja práctica al permitir utilizar diferentes niveles de capacidad según la complejidad de cada tarea. En un entorno empresarial, esta flexibilidad puede facilitar una estrategia de optimización de costes sin renunciar a utilizar modelos más potentes cuando realmente son necesarios.

Una de las conclusiones más interesantes de esta comparativa es que la estrategia más inteligente no tiene por qué consistir en elegir un único modelo para todo.

En una empresa pueden coexistir diferentes necesidades. Un equipo de desarrollo puede necesitar Fable 5 para trabajar sobre una base de código compleja, mientras que otros departamentos pueden utilizar ChatGPT 5.6 para automatizaciones, análisis visuales o procesos agénticos.

Incluso dentro de un mismo flujo de trabajo puede tener sentido utilizar diferentes modelos en función de la tarea. El verdadero reto no será decidir qué modelo gana, sino construir una arquitectura de IA capaz de seleccionar el modelo adecuado para cada problema.

Esto nos lleva hacia un escenario en el que los modelos dejan de competir únicamente por ser “el mejor” y empiezan a competir por ser el más adecuado para cada contexto.

Una carrera que cada vez parece más cosa de dos

La evolución de los últimos meses apunta además a una tendencia evidente. El debate sobre los modelos de frontera parece concentrarse cada vez más alrededor de dos grandes actores: OpenAI y Anthropic.

Mientras otros competidores siguen avanzando y ofreciendo propuestas interesantes, la distancia en capacidades de razonamiento, programación y uso agéntico parece haberse reducido a una disputa cada vez más directa entre estos dos laboratorios.

Y quizá la clave esté precisamente ahí. La carrera ya no consiste únicamente en conseguir un modelo capaz de responder mejor que el anterior. Ahora se trata de construir sistemas que razonen, utilicen herramientas, comprendan grandes volúmenes de contexto, ejecuten tareas y lo hagan de forma económicamente sostenible.

La comparativa entre ChatGPT 5.6 y Fable 5 es un buen ejemplo de este cambio de paradigma. Fable 5 parece tener ventaja cuando la prioridad es la profundidad y la complejidad; ChatGPT 5.6 cuando importan la eficiencia, la velocidad, la multimodalidad y la capacidad de operar como agente.

Por eso, más que buscar un ganador absoluto, conviene entender qué necesita cada proyecto. Porque en la nueva generación de inteligencia artificial, la pregunta ya no es qué modelo es mejor, sino qué modelo es mejor para cada trabajo.

El primer síntoma suele aparecer en la forma de gestionar el trabajo. Las PMO tradicionales, diseñadas para controlar costes y plazos, se quedan cortas cuando lo que se necesita es demostrar valor real. Al mismo tiempo, los equipos de desarrollo se encuentran saturados, atrapados en ciclos largos y dependientes de perfiles senior para tareas que podrían automatizarse. Y en el plano industrial, la presión sobre la cadena de suministro no da tregua: volatilidad, escasez de talento y exigencias regulatorias que no esperan.

La buena noticia es que la IA está dejando de ser parte del problema para convertirse en parte de la solución, y no de forma teórica. Hablamos de frameworks que transforman el conocimiento en código automático, probado y seguro, de oficinas de proyectos que evolucionan hacia modelos orientados al valor con apoyo de IA en la priorización y la toma de decisiones y de cadenas de suministro que ya operan con autonomía real gracias a tecnologías como los Gemelos Digitales de Operación, Edge AI o la IA Agéntica.

Estos tres informes comparten una misma idea: el cambio no es solo tecnológico, es organizativo y cultural. Y quienes lo aborden antes no solo ganarán eficiencia, sino una ventaja competitiva difícil de replicar.

¿Te has perdido alguno? Échale un vistazo a este recopilatorio 👇

Informe - 7 buenas prácticas para evolucionar tu PMO a VMO

Las oficinas de gestión de proyectos tradicionales han dejado de ser suficientes. En este informe exploramos cómo transformar la PMO en una Value Management Office que alinee estrategia con ejecución, priorice el impacto en el negocio y ponga al cliente en el centro. No es solo un cambio metodológico: es una evolución cultural que, además, incorpora la IA en aspectos clave como la priorización y el seguimiento del flujo de valor.

Informe - Industria 2026: el salto haciala supply chain autónoma

En 2026, la IA ha dejado de ser una herramienta de consulta para convertirse en un motor de acción. En este informe analizamos las cinco tendencias que están redefiniendo el sector industrial: IA Agéntica, Gemelos Digitales de Operación, Edge AI, GreenOps y cobótica de nueva generación. En un entorno de volatilidad global y escasez de talento, la autonomía operativa ya no es una opción tecnológica, es una necesidad financiera.

Informe - Desarrollo AI First: acelera laentrega de software con IA, contexto y activos reutilizables

¿Tu modelo de delivery ha tocado techo? Equipos saturados, ciclos largos y dependencia de perfiles senior para tareas repetitivas es uno de los patrones actuales. Paradigma Context Delivery Framework es un framework que mueve el eje hacia el desarrollo AI First para generar código automático, probado y seguro, y escalar sin disparar los costes.

Con la entrada en vigor de normativas como la CSRD y la urgencia de cumplir con los criterios ESG, la sostenibilidad ha dejado de ser una declaración de intenciones corporativa para convertirse en un requisito de arquitectura y testing.

En este recopilatorio nos adentramos en el Green QA, analizamos las cinco capas de su framework de implantación y desgranamos los KPIs fundamentales para detectar fugas energéticas en la infraestructura cloud.

Además, compartimos pautas para transicionar hacia un modelo de testing contextual que elimine por completo el desperdicio digital en los pipelines de CI/CD.

¡Arrancamos!

¿Qué es Green QA? La calidad que respira

El Green Quality Assurance redefine las pruebas y el control de calidad para reducir el consumo energético y la huella de carbono del software sin perder rigurosidad. Este enfoque conecta la ingeniería de calidad con los criterios ESG y la normativa europea CSRD, midiendo el impacto técnico directo en vatios y emisiones de CO2. Implica optimizar las suites automatizadas, mitigar el tráfico ineficiente en peticiones de API y auditar la infraestructura cloud. Una práctica necesaria para alinear el desarrollo de software con los objetivos de sostenibilidad actuales.

El framework de Green QA, la calidad que respira

Implementar Green QA requiere una estructura metodológica clara. En este post podrás ver las 5 capas esenciales de su framework (gobernanza, procesos, datos, tecnología y mejora continua) y propone un modelo de madurez inspirado en TMMi. El enfoque define responsabilidades compartidas entre los equipos de desarrollo y cumplimiento, e introduce herramientas como Scaphandre para metrología energética o plugins específicos en SonarQube para análisis estático de código. Una guía práctica para automatizar el control de la huella de carbono dentro de los pipelines de CI/CD.

Métricas en Green QA, la calidad que respira

Este post es el último de la serie de Green QA y se centra en la medición mediante KPIs y OKRs para identificar fugas energéticas y desperdicio digital. Las métricas se agrupan en eficiencia técnica (intensidad energética y ciclos de CPU), impacto planetario (huella de carbono por release), cumplimiento ESG y optimización operativa (eliminación de tests zombis y datasets redundantes). Te contamos los mecanismos para auditar estos datos bajo normativas como CSRD, GHG Protocol e ISO 21031, asegurando que cada métrica se corresponda con evidencias técnicas verificables.

Bonus: un podcast para ponerte al día en Green QA en pocos minutos

Si prefieres actualizarte en formato audio, te proponemos este episodio de nuestro podcast "Apasionados por la tecnología". Debatimos los retos de implantar Green QA, su impacto en la estrategia ESG de la compañía y las claves para eliminar el desperdicio digital en tus pipelines.