Esto ocurre, principalmente, por lo que podríamos llamar una especie de "ceguera sistémica". Cuando miras la empresa desde la mesa del Comité de Dirección, todo parece un organigrama perfecto, limpio y ordenado. La realidad operativa, en cambio, es una red compleja de interdependencias tanto humanas como técnicas. Intentar gestionar un cambio profundo basándose solo en el organigrama es, básicamente, gestionar una ilusión.

Si de verdad queremos conectar la estrategia con la ejecución del día a día y proteger los beneficios de una transformación exitosa, toca mirar tres dimensiones invisibles que pocos tienen en cuenta. No aparecen en los informes financieros pero son las fuerzas que impulsan o frenan el avance de la compañía:

1. Dimensión cognitiva: la capacidad mental y emocional disponible de tu equipo.
2. Dimensión estructural: las reglas del juego reales (como incentivos e interacciones entre las personas y departamentos) más allá de los cargos.
3. Dimensión del flujo: el camino real que recorre el valor, independiente de la jerarquía.

Veamos cómo estas barreras invisibles pueden bloquear la ejecución con ejemplos reales.

1 Barrera cognitiva: el coste oculto de la incertidumbre

Esta dimensión se refiere al "ancho de banda mental" de la organización. Pensemos: si el cerebro de los y las profesionales gasta su energía en sobrevivir al miedo o la duda, biológicamente no tiene recursos ni para innovar ni para pensar a largo plazo.

Pongamos un ejemplo típico. Imaginemos una empresa que anuncia una fusión o una reestructuración con la promesa de "ganar agilidad". Pasan los meses y nadie sabe cuál es exactamente su rol, si su responsable seguirá siendo su responsable o si su puesto peligra porque está duplicado.

La Dirección revisa los perfiles y piensa: "Tenemos al mejor talento del mercado, ¿por qué hay tanta resistencia y tan poca proactividad?".

No es un problema de actitud, es pura biología. El cerebro humano procesa la incertidumbre social como si fuera una amenaza física. Diferentes estudios e investigaciones tratan este tema y llegan a las siguientes conclusiones:

• El alto rendimiento colapsa sin seguridad psicológica (como demostró el famoso Proyecto Aristóteles de Google).
• Vivir bajo el estrés de la incertidumbre llega a reducir el Coeficiente Intelectual funcional en unos 13 puntos (según las investigaciones de Mullainathan y Shafir -Harvard/Princeton).

Añadamos, aunque no lo resolvamos aquí, el punto de cómo la IA puede ayudar o limitar la inteligencia humana y la incertidumbre que ello está generando.

¿Cómo superarlo?

Entendiendo la seguridad psicológica como una gestión de riesgos para proteger la inteligencia del equipo y no como un tema de "buenismo". Y sí, se puede medir, dando un paso más allá de los clásicos KPI de resultados, empezando a utilizar Key Behaviour Indicators (KBI): indicadores que miden conductas reales, como la frecuencia con la que el equipo reporta errores sin miedo (que conecta directamente con la seguridad psicológica) o la colaboración entre áreas… Así visualizamos qué nos hace tener éxito y que es necesario mejorar.

2 Barrera estructural: la trampa de la optimización local

Esta dimensión trata sobre cómo se diseñan las interacciones y los incentivos entre las cajas del organigrama, no sobre cómo se pintan esas cajas.

Imaginemos el clásico cierre de trimestre. La dirección comercial tiene un bonus por volumen de ventas. Por su parte, la dirección de tecnología/operaciones tiene su propio incentivo por estabilidad y reducción de costes. ¿El resultado? Ventas cierra contratos metiendo "customizaciones" complejas que implican mucho trabajo para llegar a su cuota. Mientras, Operaciones frena los despliegues o reduce “customizaciones” para reducir coste y conseguir sus objetivos.

El resultado es que ambos departamentos cumplen estrictamente sus objetivos o KPI individuales pero los clientes no tienen lo que esperaban, la empresa pierde dinero, los equipos derrochan tiempo y esfuerzo y, en conjunto, se dedica un tiempo inestimable a buscar culpables.

Como explicaba Russell Ackoff, es frecuente caer en esta trampa de la optimización local: cuando mejoras las piezas por separado, a menudo se acaba destruyendo el rendimiento del todo.

¿Cómo superarlo?

Rediseñando las interacciones: mientras los incentivos premien el silo vertical, las formas de trabajo colaborativas y las metodologías ágiles será difícil que funcionen. Aquí, el rol del C-Level tendrá que, entre otras funciones, rediseñar cómo interactúan las diferentes áreas y no tener en cuenta solo el performance de cada una de ellas de forma aislada.

Por tanto, se necesitan objetivos que impacten directamente en toda la empresa, haciendo que Ventas y Operaciones (en este caso) trabajen conjuntamente para conseguirlos. Objetivos compartidos con los que se gana (o se pierde) juntos.

3 Barrera del flujo: lo que no ves te está costando dinero

Esta dimensión se centra en la diferencia entre "gente ocupada" y "trabajo terminado".

Pongamos un escenario en el que si miras alrededor ves a todo el mundo sin parar, saturados de tareas: todas las agendas están llenas y la gente al 100% de capacidad. Sin embargo, una iniciativa clave tarda 12 meses en llegar al mercado. ¿Te suena?. Y claro, surge la pregunta “¿Cómo podemos tardar tanto con todo lo que se trabaja?".

La realidad es que el valor no se mueve cuando la gente trabaja; se mueve cuando el trabajo fluye. En la mayoría de empresas, las tareas pasan una parte importante del tiempo en "colas invisibles" (esperando presupuesto, esperando validación, esperando un entorno de pruebas…).

¿Cómo superarlo?

Utilizando Value Stream Management (VSM). Imaginémoslo como una capa de "Rayos X" que ignora la jerarquía y visualiza el flujo de trabajo y de información hasta convertirse en valor. Como indica Mik Kersten en Project to Product, al gestionar el flujo en lugar de los proyectos aislados, eliminas las esperas que ningún organigrama es capaz de mostrar.

Conclusión: del control a la arquitectura

Existe una inercia tradicional en el mundo empresarial: si algo falla, solemos culpar a las personas e intentamos "arreglarlas" metiéndolas más presión o formación. Pero W. Edwards Deming ya demostró con su Regla 94/6 que el 94% de los problemas pertenecen al sistema y solo el 6% al individuo.

Las organizaciones que lideran hoy el mercado, se dedican a "arquitecturar el entorno". Tener en cuenta los datos cálidos en procesos de cambio y optimización puede contribuir a pasos más robustos en la evolución de la organización.

¿Y qué significa "arquitecturar el entorno"?

Significa diseñar deliberadamente un ecosistema de trabajo donde “hacer lo correcto” sea lo más fácil. De esa forma:

• Se protege el intelecto colectivo (Neurociencia).
• Se alinean incentivos y formas trabajo para que se colabore (Sistemas).
• Se eliminan obstáculos para que el trabajo fluya (VSM).

Como señalan Skelton y Pais en Team Topologies, la ventaja competitiva no es para quien presiona más a sus equipos, sino para quien diseña mejores sistemas.

La pregunta que queda en el aire es: ¿estamos gestionando personas o estamos diseñando el sistema para el éxito?

Referencias

• PMI-The Economist (2013). Why good strategies fail: Lessons for the C-suite.
• CIO Magazine (April,2026).
• Google re:Work - Project Aristotle.
• Mullainathan, S., & Shafir, E. (2013). Scarcity: Why Having Too Little Means So Much.
• Ackoff, R. L. (1994). The Democratic Corporation. Oxford Univ. Press.
• Kersten, M. (2018). Project to Product. IT Revolution.
• Deming, W. E. (1986). Out of the Crisis. MIT Press.
• Skelton, M., & Pais, M. (2019). Team Topologies.

Esta es una noticia de las que cambian el juego, porque nos abre la puerta a customizar la inteligencia artificial de nuestras empresas sin tener que pasar por el calvario (y el coste) de entrenar modelos desde cero.

En este episodio, el equipo de Goodly al completo se reúne para analizar estos dos aliados que prometen jubilar las integraciones hechas "a pedal".

Poniendo orden al caos de las integraciones con MCP

Para entender dónde estamos, primero hay que mirar atrás. Pasamos de modelos encerrados en sí mismos a las famosas Function Calling y los RAG, pero seguíamos teniendo un problema: el crecimiento exponencial de integraciones tipo "M x N".

Si querías que tu IA hablara con diez sistemas, tenías que picar diez conectores distintos. El protocolo MCP, de Anthropic, llega para poner orden en este caos tecnológico, ofreciendo un marco estandarizado para que cualquier sistema pueda exponer sus herramientas a los agentes de IA de forma segura y reutilizable.

Skills en Gemini: definiendo capacidades con Markdown

Pero no todo es conectar cables, también hace falta saber qué hacer con ellos. Aquí es donde entran las Skills. Si el MCP son los ingredientes y las herramientas de cocina, la Skill es la receta detallada.

A través de un sencillo fichero Markdown, podemos darle a la IA capacidades específicas (como generar presentaciones corporativas siguiendo una plantilla o analizar informes financieros) sin sobrecargar el contexto del modelo.

Es, en esencia, un "salvar partida" de un flujo de trabajo que funciona, permitiendo que la IA sea mucho más determinista y eficiente.

Cómo encontrar el equilibrio perfecto entre MCPs y Skills

La gran pregunta que resolvemos en este episodio es: ¿cuándo usar cada uno? Aunque existe la tentación de "sobre-skilear" o convertirlo todo en MCP, la verdadera potencia reside en el equilibrio.

Hablamos de cómo empresas como Supabase ya están demostrando que combinar ambos mundos dobla la precisión y capacidad de los agentes. Además, hablamos de la portabilidad: cómo una misma Skill puede saltar de Cursor a Claude o Gemini casi sin despeinarse, dándonos una flexibilidad que hasta hace poco era ciencia ficción.

Orquestación inteligente: el futuro de la arquitectura en la nube

Como todo en este mundo de la IA, el secreto no está solo en la herramienta, sino en cómo orquestas el talento de tu nube.

No te pierdas este repaso por la "arqueología" y el futuro inmediato del cloud en el nuevo episodio de “Cómo conocí a nuestro cloud”.

¡Dale al play y actualiza tu arquitectura!

Más sobre el Google Next 2026

A pesar de usar una implementación mono hilo, Redis, el sistema de almacenamiento clave-valor en memoria de alto rendimiento, es conocido por su increíble velocidad.

¿Cómo es posible que Redis pueda gestionar cientos de miles de solicitudes por segundo? Antes que nada, hay que aclarar que Redis sí usa múltiples hilos, no es estrictamente un sistema monohilo.

Aunque es cierto que mantiene un hilo responsable del procesado de las peticiones de cliente y para el manejo de las estructuras de datos, Redis usa otros hilos de fondo para ejecutar otras tareas necesarias para su funcionamiento.

Entonces, ¿por qué es tan rápido?

• Redis mantiene todos los datos en memoria, favoreciendo la velocidad de acceso a los mismos.
• El uso de un sencillo modelo de datos clave-valor permite tener una complejidad O para las búsquedas de claves.
• El uso de multiplexación de E/S con E/S no bloqueante permite gestionar múltiples operaciones de E/S de forma eficiente.
• Uso de comandos simples que requieren poco uso de CPU.
• Uso de tipos de datos optimizados para operaciones en memoria.

Optimizaciones multihilo

• Asynchronous Memory Release: a partir de Redis 4.0, se introdujo el mecanismo de liberación diferida (lazy-free mecanismo) para liberar memoria de forma asíncrona. La liberación de memoria al eliminar claves de gran tamaño se realiza en un hilo en segundo plano.
• Multi-threading: podemos leer en el blog de Redis que “a partir de la versión 6.0, Redis hace uso de hilos de E/S para gestionar las peticiones de clientes, incluyendo sockets de lectura y escritura, y el parseo de comandos. Sin embargo, la implementación no llega a aprovechar al máximo las ventajas en cuanto a rendimiento.”

El uso de ejecución multihilo permite reducir la presión que se tiene en la ejecución monohilo de las peticiones entrantes en escenarios de alta concurrencia. Este proceso multihilo se aplica únicamente al análisis del protocolo de peticiones de datos, manteniendo la ejecución monohilo en el procesado de comandos y la manipulación de datos.

Con la publicación de Redis 8.0 llegó una nueva implementación E/S multihilo que anunciaba grandes mejoras en la transferencia de datos (entre el 37% y el 112%, según los datos publicados por Redis) en CPUs multinúcleo.

Probando la nueva implementación multihilo

Como ya hemos comentado, Redis procesa las peticiones en un único hilo, dividiendo la ejecución en los siguientes 4 pasos:

1. Lectura de la petición desde el socket
2. Análisis de la petición
3. Procesado de la petición, ejecutando las operaciones necesarias sobre los datos
4. Escritura de la respuesta en el socket

No se comenzará a procesar una nueva petición hasta que estos 4 pasos se hayan completado en orden para la petición actual.

La escritura de los resultados en el socket que se realiza en el paso 4 es típicamente una operación lenta en cuanto al tiempo necesario para completarla. Es en este punto donde podemos beneficiarnos de la nueva implementación multihilo de la E/S, configurando nuestro Redis para que ejecute las operaciones E/S en un nuevo hilo. De esta forma, Redis está en disposición de comenzar a procesar una nueva petición en paralelo, mejorando así el rendimiento.

La propiedad io-threads de Redis (esta propiedad es inmutable) será la que utilicemos para configurar la escritura multihilo en el socket. Recordemos que esta propiedad se inicializa a 1 por defecto, y que se usa para indicar el número de hilos máximo que se podrán crear para las escrituras en el socket.

También tenemos disponible la propiedad de configuración io-threads-do-reads en Redis que nos daría la posibilidad de usar ejecuciones multihilo en la lectura y análisis de peticiones desde el socket (pasos 1 y 2 descritos anteriormente). Esta opción, sin embargo, y de acuerdo a la información que dan desde Redis, no tiene un impacto significativo sobre el rendimiento.

Por tanto, vamos a centrarnos únicamente en el impacto que tiene la configuración de io-threads.

Tests sintéticos: ¿cómo se han ejecutado?

Herramienta de benchmarking

Para las pruebas se ha usado memtier_benchmark, una herramienta de benchmarking Open Source desarrollada por Redis Labs que integran en sus procesos de desarrollo, principalmente para hacer tests de no regresión y optimización de rendimiento.

memtier_benchmark fue presentada en el blog oficial de Redis y el proyecto está disponible en GitHub.

Nuestro Redis de pruebas

Vamos a usar un cluster Redis, desplegado en un Openshift Container Platform (OCP), con la siguiente configuración:

• Nodos del cluster: 5
• CPUs por nodo: 4
• Memoria por nodo: 4Gi

Usaremos 4 imágenes diferentes para montar los nodos, así podremos hacer una comparativa de rendimiento entre las distintas versiones:

• redis.redis-stack-server:7.2.0-v10 (imagen basada en la imagen oficial redis-stack-server en la que se habilitan algunos módulos)
• redis:7-bookworm (imagen oficial)
• valkey/valkey:8-bookworm (imagen oficial)
• redis:8-bookworm (imagen oficial)

Objetivos de los tests

Con la ejecución de estos tests perseguimos:

• Determinar el valor óptimo del parámetro de configuración io-threads.
• Decidir con qué sabor de Redis nos quedamos: el viejo y bien conocido Redis o el fresco y joven Valkey

Como hemos visto, podemos establecer cualquier valor por encima del valor por defecto de un hilo en el parámetro io-threads. Nos interesa ver el impacto en el rendimiento que tienen los cambios en esta configuración.

Por otro lado, sabemos que tras el anuncio que hizo Redis en el que se explicaba que dejaría de ser open source surgieron unos cuantos forks del proyecto. Tras revisar aquellos que habían tenido más actividad y que más habían crecido en número de contribuidores, decidimos limitar las pruebas a Valkey.

También nos interesa comparar el rendimiento de Valkey frente a las últimas versiones de Redis. Este último ha recibido muy buenos comentarios en cuanto a la mejora en términos de rendimiento desde la publicación de su versión 8.

Resultados de los tests

Cada test se comienza con un cluster Redis recién creado en un namespace concreto en nuestro OCP. Igualmente, se crea un pod nuevo desde el que se ejecutará la herramienta de benchmarking al comienzo de cada prueba.

Los valores utilizados para io-threads fueron: 1, 8, 12 y 16.

En la siguiente tabla se recogen los valores obtenidos en los distintos tests, mostrando la media de operaciones por segundo, para cada imagen y cada una de las configuraciones de io-threads.

Estos mismos datos en forma de gráfica:

Parece que el punto óptimo se sitúa en una configuración de io-threads correspondiendo a 2 veces el número de CPUs configuradas por nodo de Redis.

A partir de este valor vemos cómo el rendimiento se ve degradado en Valkey 8, mientras que Redis 8 mantiene un rendimiento estable si vamos más allá de este punto óptimo. Por tanto, los resultados de Redis 8 son más consistentes.

Como esperábamos, no se ha observado ninguna mejora de rendimiento en Redis 7 con el incremento de io-threads. Al contrario, nos ha sorprendido observar una degradación.

Redis 8 ha rendido mejor que Valkey 8 en todos los escenarios. Por tanto, nos quedamos con la regla de 2xCPU como configuración por defecto para io-threads y, en principio, la balanza se decanta, al menos por ahora, por el uso de Redis 8 como la imagen a usar para nuestros clusters de Redis.

Aplicando el conocimiento adquirido: optimización de recursos en un escenario real

El escenario: una aplicación desplegada en Kubernetes, haciendo uso intensivo de un cluster de Redis, requiriendo de tasas realmente altas de peticiones por segundo.

El cluster de Redis, en periodos de pico de uso de la aplicación se ha de escalar a 100 nodos para poder soportar el rendimiento requerido. Actualmente, este cluster está formado por nodos instanciados a partir de la imagen Redis Stack 7.2, con 1 CPU por nodo.

Nuestro objetivo es intentar reducir el número de nodos del cluster a la mitad, pasando de 100 a 50 nodos, usando la imagen Redis 8. Para ello, duplicaremos el número de CPUs por nodo, pasando de 1 a 2 CPUs, y estableciendo la configuración de io-threads en 4, como habíamos determinado, con el fin de beneficiarnos de las mejoras que ofrece la nueva implementación del I/O threading.

Para validar que la plataforma con esta nueva configuración es capaz de soportar el uso en periodos de pico, se usa un conjunto de tests complejos elaborados precisamente para someterla a cargas similares a las previstas en esos periodos y así poder validar que estamos en disposición de aguantar los periodos de demanda extrema.

Estos tests End-to-End (E2E) se han desarrollado a medida basándose en Spring Framework, haciendo uso del cliente de [Redis Lettuce(https://github.com/redis/lettuce).

Aprovechando la ventana de disponibilidad de la plataforma, se ejecutó la suite completa de tests con las siguientes configuraciones, para poder comparar los resultados:

• Redis Stack 7.2 - 100 nodos (1 CPU)
• Redis 8 - 50 nodos (2 CPU)
• Valley 8 - 50 nodos (2 CPU)

Aprovechamos que el Operador de Redis desarrollado para gestionar todos los clusters de Redis (actualmente liberado como Open Source) despliega, junto a los pods del propio cluster, un pod encargado de extraer una gran cantidad de métricas y las expone para poder ser recuperadas por Prometheus, junto a las métricas propias de Kubernetes, y mostradas en un panel en Grafana.

Pasemos a revisar los resultados obtenidos.

Comandos procesados

Vemos como el cluster montado con Redis 8 aprovecha la ventaja de la configuración de io-threads y la nueva implementación, llegando prácticamente a alcanzar el número de comandos por unidad de tiempo del cluster de referencia con Redis Strack 7.2. Vemos que cada nodo prácticamente llega a duplicar el número de comandos procesados por unidad de tiempo respecto a los valores de Redis Stack 7.2.

Valkey 8 presenta un comportamiento similar a Redis 8. Lamentablemente, al comienzo del test se produjo el desalojo de el pod de uno de los nodos, lo que explica la pequeña caída que se aprecia en la gráfica.

Hits

El mismo comportamiento que vimos en los comandos procesados por unidad de tiempo se repite en el número de hits. Se llega casi a alcanzar el rendimiento de referencia de Redis Stack 7.2 con la mitad de nodos tanto en Redis 8 como en Valkey 8.

Para dar una idea de la cantidad de datos que se manejan durante los tests, se incluyen las siguientes gráficas que muestran el número de keys almacenadas por nodo.

Cache entries

Si echamos un vistazo al uso de CPU, vemos resultados más consistentes en Redis 8 que en Valkey 8.

CPU usage

Para finalizar la comparativa de las métricas obtenidas, echemos un vistazo a la tasa de transferencia de salida de red de los nodos.

Network out throughput

Conclusiones finales

La nueva implementación de I/O threading incluida en Redis 8 y Valkey 8 realmente marca la diferencia con las antiguas implementaciones. Haciendo uso de múltiples hilos para hacer la escritura de los resultados de los comandos al socket se alivia significativamente la carga en el hilo principal, permitiendo un incremento impresionante del rendimiento por nodo.

De los datos de los tests podemos extraer que se ha alcanzado una mejora de rendimiento del 90-95%.

Usando Redis 8, con las mejoras que introduce y, sobre todo, con la implementación de I/O Threading, podemos llegar a una reducción considerable de recursos. Tras las pruebas pudimos pasar los periodos de pico con la mitad de nodos por cluster, subiendo la CPU de 1 a 2.

Si nos basamos únicamente en las métricas de Redis aquí expuestas (y algunas más que no se han incluido por no resultar tan interesantes) Redis 8 y Valkey 8 presentan rendimientos muy similares. Sin embargo, también revisamos logs y métricas de la aplicación cliente. En estas observamos que Redis 8 se comportó de forma más estable que Valkey 8. Consiguió mantener tasas de transferencia durante todos los tests más estables, mientras que Valkey 8 mostró algunas fluctuaciones.

Redis 8, tras su vuelta al mundo Open Source, ha demostrado un rendimiento impecable. También ha mostrado tener un mayor nivel de optimización, además de comportarse más estable y más consistente antes las distintas configuraciones de io-thread.

Por todo esto, nos quedamos con Redis 8, al menos por ahora.

Referencias

• Redis 8.0-M03 is out. Even more performance & new features, Blog de Redis
• memtier_benchmark: A High-Throughput Benchmarking Tool for Redis & Memcached, Blog de Redis
• Github RedisLabs
• Github Redis Lettuce

¿Qué cambia, para quién cambia y cómo sabremos que ha cambiado?

Cuando eso no está claro, suele pasar que hemos arrancado con energía, el backlog crece, entregamos cosas… y a las pocas semanas alguien pregunta: “vale, ¿y esto para qué era?” Y no suele ser un problema de esfuerzo, sino un problema de enfoque.

Para mí, la mentalidad de producto no va de roles, ceremonias o herramientas. Se trata de poner el foco en tres cosas antes de lanzarnos a construir: qué problema queremos resolver, para quién y qué valor esperamos generar.

El error más habitual es arrancar por el “qué”. Las primeras conversaciones giran alrededor de lo que hay que construir, los entregables que se esperan, para cuándo, quién lo hace y dónde lo seguimos. Son preguntas válidas. El problema es que, si arrancamos así, corremos el riesgo de organizarnos en torno a la ejecución de algo que quizá no era lo más importante.

Por eso, antes de bajar a la operativa, conviene aterrizar el propósito, el usuario y el valor con estas preguntas:

• ¿Por qué hacemos esto? ¿Qué problema estamos intentando resolver?
• ¿Quién es el usuario real?
• ¿Qué mejora esperamos ver y cómo la vamos a notar?

Si esto no está claro, bajar al backlog demasiado pronto no nos va a ayudar. Esto sucede con frecuencia con iniciativas que ya llegan formuladas de esta forma:

• “Necesitamos un dashboard.”
• “Hay que automatizar este proceso.”
• “Queremos una nueva pantalla.”

Ahí el riesgo es aceptar la solución sin haber entendido bien la necesidad. Pasa, por ejemplo, con peticiones como esta: “automatizar la aprobación de solicitudes”. Hasta ahí, lo que tenemos es una solución. La conversación útil empieza cuando preguntas: “vale, ¿para qué?”. Y entonces aparece el problema real: reducir tiempos de respuesta y evitar errores. A partir de ahí ya puedes concretar mejor:

• Usuario: el equipo operativo que gestiona las solicitudes y el cliente final que sufre las esperas.
• Valor esperado: pasar de 5 días a 24 horas y reducir retrabajo.
• Decisión: quizá antes de automatizar es recomendable eliminar validaciones redundantes, aclarar criterios y definir excepciones.

La necesidad de fondo no ha cambiado. Lo que cambia es la calidad de la decisión.

Producto es el compendio de propósito, usuario y valor

Cuando hablamos de producto, para mí hay tres elementos que no pueden faltar: propósito, usuario y valor. Si falta uno de estos tres, es fácil caer en una dinámica peligrosa donde trabajamos mucho pero con un impacto difuso.

• Sin usuario, el valor se vuelve abstracto: no sabemos para quién estamos mejorando algo ni qué cambio queremos provocar. Y esto aplica también cuando el usuario es interno. Que el usuario esté en Operaciones, Tecnología, Riesgos o Finanzas no cambia nada de fondo: también ahí hay que concretar quién es, qué fricción tiene y qué mejora sería realmente valiosa para esa persona.
• Sin valor, el usuario se queda en una descripción vacía. En este post no vamos a entrar en detalle en qué se entiende por valor, pero sí quiero aclarar que cuando hablo de valor, no me refiero solo a negocio. Puede aparecer en varias capas, ya sea:
  • Valor para el usuario: menos fricción, más claridad, menos esperas, menos errores.
  • Valor para el negocio: más adopción, menos coste, menos riesgo, mejor conversión.
  • Valor para el sistema de entrega: más calidad, más estabilidad, menos retrabajo, menos urgencias artificiales.
• Sin propósito, todo suena razonable, pero cuesta priorizar. Aquí hay una distinción que me parece útil y que conecta con el Círculo Dorado de Simon Sinek: no es lo mismo hablar del porqué que del para qué. El porqué habla del propósito de la iniciativa. El para qué aterriza ese propósito en impacto, en el cambio que queremos provocar.

Lo importante es que algo cambie de forma observable. Si no cambia nada visible, probablemente no estamos generando valor; únicamente estamos haciendo cosas.

Una buena pregunta para aterrizarlo es: ¿Qué mejora real se producirá para el usuario si esto funciona?

Cómo aterrizar esto en el día a día

1. Arrancar por problema y valor, no por entregable.

Antes de hablar de solución, deja claro qué dolor quieres resolver, para quién y qué mejora esperas ver. Herramientas como una Inception bien enfocada ayudan justo a eso: alinear propósito, usuario, valor y cómo sabremos si vamos bien.

Para ese arranque ayuda de forma sustancial dejar por escrito algo tan simple como:

• Nuestro objetivo: estamos aquí para...
• El problema actual: hoy en día pasa que...
• A quién afecta: esto afecta sobre todo a...
• Lo que esperamos: si todo va bien, debería cambiar...
• Cómo lo sabremos: lo notaremos porque veremos...

No lo veas como burocracia. Tómalo como una manera de alinear mejor y de evitar que el backlog se convierta en lista de tareas.

2. Conectar estrategia, foco y backlog.

Si una iniciativa no está conectada con una prioridad real, el backlog acaba lleno de trabajo, pero no necesariamente de valor. Por eso conviene enlazar bien estrategia, priorización y roadmap.

3. Traducir intención en seguimiento real.

Si dices que buscas impacto, luego tienes que revisarlo. Y ahí ayuda formular bien los objetivos y acompañarlos de resultados observables, sin confundir actividad con impacto. Para eso, puedes complementar bien con el uso de OKRs, prestando atención a sus anti-patrones.

En conclusión

Trabajar con mentalidad de producto va de tomar mejores decisiones desde el principio. La próxima vez que arranques una iniciativa, yo me pararía un minuto en estas tres preguntas:

• ¿Qué valor concreto queremos generar?
• ¿Para quién, exactamente?
• ¿Y cómo sabremos que lo estamos consiguiendo?

Porque el valor no aparece al final. Se decide desde el inicio y se revisa durante el camino.

Tu backlog no debería demostrar que trabajas. Debería demostrar que estás cambiando algo valioso para alguien. ¡Te leo en comentarios! 👇

Las compañías ya no solo tienen que garantizar que sus productos funcionen bien, sino también que sean sostenibles, medibles y alineados con nuevas exigencias regulatorias y sociales.

En este contexto surge Green QA, un enfoque que amplía el concepto tradicional de calidad incorporando variables como la eficiencia energética, la huella de carbono y la trazabilidad ambiental del software.

Más allá del testing: qué es Green QA y por qué importa

Green QA parte de una idea sencilla pero potente: no basta con validar que un sistema funciona, también hay que entender cómo se ha construido y qué impacto ha generado en el proceso.

Tradicionalmente, los equipos de calidad se han centrado en verificar entregables. Pero rara vez se ha tenido en cuenta el coste energético de ejecutar pruebas, el consumo de infraestructura o la huella de carbono asociada a todo el ciclo de desarrollo. Green QA introduce precisamente esa capa de conciencia.

Este cambio no es solo conceptual, también responde a dos grandes fuerzas. Por un lado, el creciente peso de la regulación, con normativas como la directiva europea CSRD o las leyes nacionales de sostenibilidad empresarial.

Por otro lado, la propia competitividad del mercado: las empresas que integran sostenibilidad en su ciclo de desarrollo no solo cumplen, también se diferencian.

ESG y software: una relación cada vez más directa

El auge de los criterios ESG (Environmental, Social & Governance) ha llevado a las empresas a medir su impacto más allá de lo financiero. En este marco, Green QA se convierte en una pieza clave para trasladar esos principios al desarrollo de software.

Desde el punto de vista ambiental, permite medir y optimizar aspectos como el consumo energético de servidores o la eficiencia del código. En la dimensión social, introduce variables como la accesibilidad o la ética en el uso de datos.

Y en el ámbito de la gobernanza, aporta trazabilidad, auditoría y cumplimiento normativo en los procesos de desarrollo. En otras palabras, Green QA traduce los principios ESG en métricas técnicas accionables dentro del ciclo de vida del software.

Este enfoque está redefiniendo profundamente el papel del QA. Ya no se trata solo de probar más, sino de probar mejor.

Uno de los cambios más relevantes es el paso de un testing exhaustivo a un testing contextual. Ejecutar todas las pruebas posibles ya no es siempre la mejor opción, especialmente si implica un coste energético elevado. En su lugar, se busca optimizar qué se prueba, cuándo y cómo.

Además, aparecen nuevos indicadores en los cuadros de mando: la eficiencia energética pasa a ser un KPI más, junto a los tradicionales de calidad o rendimiento. También cobra importancia la gestión del “desperdicio digital”, es decir, el uso innecesario de recursos en automatizaciones, datos o infraestructuras.

A esto se suma un cambio cultural: la sostenibilidad debe integrarse desde el inicio del desarrollo, no añadirse al final como una capa adicional.

Impacto real en el ciclo de vida del software

Green QA no es una teoría, es un enfoque con impacto tangible en todas las fases del desarrollo. Desde la validación, donde ya no solo se verifica el funcionamiento sino también el impacto ambiental, hasta el diseño del código, que se optimiza para ser más eficiente y mantenible.

Un código más limpio no solo es más fácil de entender, sino que reduce costes y consumo a largo plazo.

También influye en la infraestructura, promoviendo entornos temporales y bajo demanda frente a sistemas permanentemente activos. Incluso en la gestión de datos, donde se pone el foco en eliminar información innecesaria que consume recursos sin aportar valor.

Un dato ilustrativo: almacenar información sin uso durante días puede tener un impacto energético comparable al de mantener dispositivos encendidos de forma continua. El software también consume, aunque no siempre lo veamos.

Medir para mejorar: las nuevas métricas de la calidad sostenible

Uno de los grandes retos de este enfoque es la medición. Sin embargo, cada vez existen más herramientas que permiten cuantificar el impacto del software.

Algunas de las métricas que empiezan a cobrar relevancia incluyen el consumo energético por ciclo de pruebas, las emisiones de CO₂ por despliegue o la eficiencia en el uso de CPU y memoria. Estos datos permiten detectar anomalías, optimizar procesos y tomar decisiones informadas.

Lo importante no es solo medir, también hacerlo de forma continua y automatizada, integrando estas métricas en los pipelines y en los sistemas de observabilidad del proyecto.

Cómo empezar: de la conciencia a la estrategia

Adoptar Green QA no ocurre de un día para otro. Requiere un proceso progresivo que comienza con la formación y la concienciación de los equipos. En una primera fase, muchas organizaciones ni siquiera son conscientes del impacto ambiental de sus procesos de testing. A medida que avanzan, empiezan a identificar recursos, incorporar métricas y definir procesos más eficientes.

El siguiente paso es la estandarización, con KPIs claros y prácticas sostenibles integradas en el día a día. Posteriormente, se alcanza un nivel en el que la medición es continua y automatizada, y finalmente, las compañías más maduras alinean completamente su estrategia de software con los objetivos ESG.

Green QA representa un cambio profundo en la forma de entender la calidad. Ya no se trata solo de entregar software que funcione, sino de hacerlo de manera responsable, eficiente y alineada con el entorno: la sostenibilidad no es un coste añadido, es una oportunidad para ser más eficientes, reducir gastos y mejorar la competitividad.

En un contexto donde la tecnología es responsable de una parte creciente del consumo energético global, integrar este enfoque no es solo una ventaja estratégica: empieza a ser una necesidad.

El futuro ya está aquí. Y está lleno de deuda técnica.

Lo que el mercado está revelando en este segundo trimestre de 2026 no es una historia de promesas tecnológicas. Es una historia de ejecución y de quién es capaz de acometerla y quién no. Las compañías energéticas líderes no se diferencian hoy por el modelo de IA que han elegido ni por el proveedor de nube que firman en sus contratos. Se diferencian por algo mucho más prosaico y mucho más difícil: la capacidad de poner en producción sistemas complejos en entornos operativos que llevan décadas acumulando parches.

Analizando el comportamiento del mercado en lo que va de año, emergen cinco perspectivas que dictan quién liderará la segunda mitad de esta década. No son tendencias. Son diagnósticos.

Perspectiva 1: tu IA agéntica tiene un problema de fontanería, no de algoritmos

Hasta hace poco, la Inteligencia Artificial en el sector energético vivía en presentaciones de PowerPoint y en proyectos piloto aislados. En 2026, la conversación ha madurado hacia la IA Agéntica: sistemas autónomos integrados en los flujos de trabajo críticos que no solo recomiendan decisiones, sino que las ejecutan, hacen balanceo de carga en milisegundos, mantenimiento predictivo coordinado o gestión de carteras de recursos distribuidos.

La realidad operativa que hemos constatado en 2026 es esta: no te frena el algoritmo. Te frena la arquitectura de datos sobre la que intentas ejecutarlo.

Las organizaciones que han fracasado en escalar sus agentes no lo han hecho por elegir el modelo equivocado. Lo han hecho porque intentaron automatizar sobre un ecosistema de datos fragmentado, con silos heredados, con pipelines que nadie documenta y con gobernanza que existe en teoría pero no en producción. Automatizar un proceso roto no lo repara, lo escala. Y el fracaso escala con él.

Los líderes del sector están obligados a dar el paso que nadie quiere dar: rediseñar los cimientos. No parchear. Rediseñar. Eso significa abandonar los enfoques de integración cosmética y construir arquitecturas verdaderamente AI-Native: lagos de datos unificados, gobernanza real, pipelines con observabilidad end-to-end. Solo desde ahí puede un agente reducir los tiempos de inactividad en doble dígito. Solo desde ahí la IA deja de ser un coste y se convierte en un motor de eficiencia financiera.

El problema no es de ciencia. Es ingeniería. Y la ingeniería es trabajo duro.

Perspectiva 2: la soberanía del dato no es una opción regulatoria, es una condición de negocio

La transición energética exige orquestación a una escala que ninguna compañía puede resolver sola. La integración de la red eléctrica con la movilidad eléctrica, con los sistemas de climatización, con los mercados intradiarios de flexibilidad: todo ello requiere un intercambio de información fluido entre actores que son, simultáneamente, socios y competidores.

Mientras tanto, los ataques a infraestructuras críticas no han dejado de crecer. La soberanía digital ha dejado de ser un debate jurídico para convertirse en un imperativo de seguridad nacional y europea.

Iniciativas como energy data-X o los proyectos V2G (Vehicle-to-Grid) lo están demostrando en la práctica: es posible conectar contadores inteligentes, puntos de recarga y mercados de flexibilidad sin ceder el control sobre los activos de información propios. La arquitectura que lo hace posible separa el plano de control (quién accede, bajo qué condiciones, con qué contrato) del plano de datos. El estándar abierto como condición de interoperabilidad. El conector como mecanismo de soberanía.

La conclusión para los tomadores de decisiones es directa: participar en la economía energética descentralizada va a requerir infraestructura federada. Las compañías que no construyan esa capacidad hoy no podrán monetizar sus activos de información mañana. El mercado de la nube soberana no es una apuesta tecnológica, es la única vía de entrada.

Perspectiva 3: la eficiencia energética ya no se reporta, se contabiliza

2026 marca el año en que la sostenibilidad dejó de ser un ejercicio de reputación corporativa para convertirse en una operación financiera de alto impacto. No es retórica, es aritmética.

El sistema de Certificados de Ahorro Energético (CAE) en España ha alcanzado una madurez suficiente para que los ahorros energéticos verificables se conviertan en activos líquidos y monetizables. Cada kilovatio-hora ahorrado mediante modernización de infraestructuras, optimización de procesos industriales o implantación de tecnología eficiente genera un certificado que las comercializadoras están obligadas a adquirir. El ROI es inmediato, es medible y está auditado.

En paralelo, la directiva CSRD exige este año una contabilidad del carbono tan rigurosa como la contabilidad financiera tradicional. No es una fecha futura, es ahora.

Las compañías que carezcan de plataformas software capaces de automatizar la captura de datos de consumo, simular escenarios de descarbonización antes de comprometer el CAPEX, e integrar la toma de decisiones ambiental en el comité de dirección, no van a perder puntos de sostenibilidad, van a perder competitividad financiera. La eficiencia energética ya no se gestiona desde el departamento de medio ambiente. Se gestiona desde la dirección de negocio. Y se ejecuta con herramientas de datos.

Perspectiva 4: tu red necesita un gemelo que piense, no uno que represente

Las redes eléctricas están operando al límite. La electrificación masiva, la generación intermitente de renovables y el auge de los centros de datos, paradójicamente impulsado por la misma IA que debería optimizar la red, han convertido la infraestructura de transporte y distribución en el principal cuello de botella de la transición energética.

La respuesta del mercado ha sido el Gemelo Digital. La realidad de 2026 nos demuestra que el Gemelo Digital como representación 3D es condición necesaria, pero no suficiente. Lo que los operadores necesitan hoy son Gemelos de Simulación: motores de decisión que ingieran datos de dispositivos IoT en tiempo real y permitan probar escenarios de forma predictiva. ¿Qué ocurre si un macrocentro de datos en el polígono industrial demanda un pico bestial en cuatro horas? ¿Cómo responde la red ante una ola de calor con penetración fotovoltaica a un tanto por ciento muy por encima de lo normal? ¿Dónde rompería el sistema?

Para llegar ahí, los operadores están obligados a modernizar sus plataformas legacy, no hay alternativa. Una infraestructura rígida diseñada para flujos unidireccionales no puede procesar transacciones bidireccionales masivas ni dialogar con la nube con la latencia que exigen los mercados intradiarios. La modernización no es un proyecto de TI, es el único camino para gestionar activos de forma resiliente sin depender exclusivamente de ampliaciones físicas que tardan años y cuestan cientos de millones. Los que lo resuelvan con ingeniería de plataformas ganarán margen de maniobra operativo y los que no, dependerán del hierro.

Perspectiva 5: la tecnología que nadie adopta no existe

Podemos desplegar la arquitectura más sofisticada del mercado pero si la organización que debe operarla sigue funcionando con lógicas de hace diez años, el valor se evapora antes de llegar a producción.

Abril de 2026 lo confirma con claridad: la volatilidad geopolítica, los cuellos de botella en la cadena de suministro y la velocidad de la innovación en IA no perdonan a las organizaciones lentas. No es un problema de talento ni de presupuesto sino de diseño organizacional.

La transformación digital en el sector energético no se resuelve con metodologías, se resuelve con cultura operativa. Equipos multidisciplinares donde la ingeniería, la ciberseguridad y el negocio trabajan en el mismo sprint, con el mismo objetivo y con visibilidad compartida sobre los datos. Estructuras que priorizan el flujo de valor por encima de la jerarquía. Organizaciones capaces de absorber un cambio regulatorio, una disrupción tecnológica o una crisis de suministro sin paralizarse.

Esta capacidad tiene un nombre y no se consigue comprando una herramienta. Se construye rediseñando la forma en que los equipos toman decisiones, priorizan el trabajo y entregan valor. Las compañías que lo han entendido están reduciendo su deuda técnica de forma sistemática, acelerando su time-to-market y construyendo estructuras que no se rompen ante la próxima disrupción. Las que no lo han entendido seguirán automatizando procesos rotos y llamándolo transformación digital.

Conclusión: el riesgo no es tecnológico, es de integración

Si el panorama de 2026 deja una lección clara, es esta: la tecnología correcta mal integrada es peor que la tecnología imperfecta bien ejecutada.

Las fuerzas que moldean el mercado hoy, la IA agéntica, la soberanía del dato, la monetización de la eficiencia, la simulación predictiva y la agilidad organizacional, no son independientes. Se refuerzan o se anulan mutuamente. Una compañía con una IA agéntica excelente sobre datos fragmentados fracasa. Una compañía con una plataforma de datos impecable y una organización incapaz de iterar sobre ella también fracasa.

El éxito en esta industria ya no pertenece a quien tiene la mejor tecnología. Pertenece a quien tiene la disciplina de integrarla, la ingeniería para sostenerla y la cultura para adaptarla. No hay atajo y tampoco hay misterio.

Es el momento de liderar el presente para asegurar la energía del mañana.

Si marzo estuvo marcado por la consolidación de los agentes, en abril hemos visto cómo esa tendencia madura y se combina con otra igualmente relevante: la convergencia entre modelos avanzados y herramientas creativas profesionales, especialmente en imagen, vídeo y diseño.

Además, el sector ha entrado en una nueva fase de competencia directa. Los grandes actores ya no compiten solo en benchmarks, sino en algo mucho más tangible: casos de uso reales, integración en workflows y valor práctico para empresas.

Modelos: hacia una IA más autónoma y especializada

Uno de los lanzamientos más relevantes del mes ha sido GPT-5.5, con el que OpenAI sigue avanzando hacia sistemas más autónomos. Más allá de mejoras incrementales en calidad de respuesta, lo verdaderamente significativo es el cambio de comportamiento: el modelo empieza a funcionar como un sistema capaz de ejecutar tareas complejas de forma prolongada.

Este salto se nota especialmente en programación avanzada, automatización de tareas de oficina, investigación inicial y ejecución de workflows largos. Ya no se trata solo de responder mejor, sino de mantener contexto, tomar decisiones y avanzar en procesos de múltiples pasos.
En otras palabras, se acerca cada vez más a un agente continuo.

En paralelo, Anthropic ha presentado Claude Mythos, un modelo que marca un punto de inflexión, no solo por sus capacidades, sino por su estrategia de lanzamiento. A diferencia de iteraciones anteriores, Mythos no está disponible públicamente. Se encuentra en fase de acceso restringido para un grupo selecto de socios, debido a los riesgos asociados a su potencial uso en ciberseguridad ofensiva.

Este modelo destaca por su capacidad para identificar vulnerabilidades desconocidas y generar exploits funcionales en tiempos extremadamente reducidos.

También supone un salto notable en benchmarks de ingeniería de software y muestra un comportamiento claramente agéntico, capaz de ejecutar secuencias complejas de acciones para alcanzar un objetivo.

Paradójicamente, cuanto más potente es el modelo, más evidente se vuelve la necesidad de controlarlo: Anthropic reconoce que cualquier desviación, por pequeña que sea, puede tener consecuencias significativas.

Agentes: integración real en herramientas profesionales

Otra de las tendencias más claras del mes es la integración de la IA en herramientas de trabajo reales. Un buen ejemplo es Claude Design, que lleva los agentes directamente al flujo de trabajo creativo.

La diferencia frente a generaciones anteriores es importante. Ya no hablamos de herramientas que sugieren ideas o generan propuestas aisladas, sino de sistemas que participan activamente en el proceso. Claude Design puede iterar sobre diseños, ajustar interfaces, trabajar con sistemas de diseño completos y evolucionar propuestas dentro de un flujo continuo.

Este enfoque posiciona a la IA no como un asistente puntual, sino también como una pieza integrada en el proceso creativo, compitiendo directamente con herramientas profesionales tradicionales.

Imagen: OpenAI entra de lleno en la competición

En el terreno de la imagen, abril marca un punto de inflexión con el lanzamiento de ChatGPT Images 2.0. OpenAI entra así de lleno en un espacio donde otros modelos llevaban meses liderando, y lo hace con una propuesta claramente orientada a uso profesional.

Las mejoras son evidentes: mejor renderizado de texto, mayor coherencia visual, capacidad de trabajar con múltiples estilos y generación consistente de imágenes a partir de un mismo prompt. A esto se suma un modo de “razonamiento visual” que introduce una capa adicional de control en la generación.

El resultado es un modelo capaz de producir imágenes hiperrealistas que, en muchos casos, son difíciles de distinguir de fotografías reales. Esto no solo abre nuevas oportunidades en diseño, marketing o generación de contenido, sino también debates relevantes sobre veracidad, autenticidad y uso responsable.

Lo importante es que la generación de imagen deja de ser una curiosidad para convertirse en una herramienta útil en contextos de negocio: campañas, mockups, contenido para redes o diseño de producto.

Vídeo: consolidación y reajustes estratégicos

En contraste con el avance en imagen, el vídeo ha vivido un mes más complejo. OpenAI ha decidido cerrar Sora, su herramienta de generación de vídeo, alegando altos costes computacionales, baja adopción y un cambio en su estrategia de producto.

Este movimiento deja una lectura clara: no basta con demostrar capacidad técnica. Para que un modelo sobreviva, necesita encajar en un modelo de negocio viable.

Mientras tanto, otros actores como Google, ByteDance o Kuaishou continúan avanzando en este ámbito. La evolución sigue una dirección clara: mayor realismo, mejor control de escena y una integración más profunda en flujos de trabajo profesionales.

Conclusión: la IA deja de impresionar para empezar a ser útil

Abril de 2026 deja una conclusión bastante contundente: la inteligencia artificial está dejando atrás la fase de “demo impresionante” para entrar en una etapa centrada en la utilidad real.

Los modelos ya no compiten solo en calidad, sino en su capacidad para ejecutar tareas, integrarse en herramientas y aportar valor continuo. La generación de imagen alcanza un nivel cercano a producción profesional, mientras que los agentes empiezan a formar parte activa de los procesos de trabajo.

En este contexto, la pregunta ya no es qué modelo es mejor, sino cuál encaja mejor en cada caso de uso. Y esa es, probablemente, la señal más clara de que la IA ha empezado a madurar.

La promesa de la Inteligencia Artificial Generativa es seductora: código instantáneo, soluciones en segundos y una productividad que se dispara. Pero para el perfil de gestión de proyectos, esto plantea una pregunta incómoda: si las máquinas no se cansan, ¿esperamos que nuestros equipos humanos sigan ese ritmo? En el boom de la productividad, el "ritmo sostenible" de XP es la única garantía de que tu equipo no implosione por agotamiento.

Aquí es donde Extreme Programming (XP) vuelve a la escena, no como una metodología de ingeniería, sino como un manifiesto de sostenibilidad humana. Paradójicamente, para ir a la velocidad de la IA, necesitamos los frenos de seguridad y el bienestar psicológico que Kent Beck diseñó en los ‘90.

¿Cómo garantiza XP el bienestar en entornos de "alta velocidad"?

A diferencia de otros marcos ágiles que a veces se convierten en una "fábrica de tickets", XP tiene principios explícitos sobre la salud mental del equipo. No son sugerencias de recursos humanos, son reglas técnicas estrictas.

• La regla del ritmo sostenible (Sustainable Pace)

XP prohíbe explícitamente el heroísmo. La premisa es simple: una persona cansada introduce más bugs en una hora que los que puede arreglar en dos. XP dicta que si hay horas extra una semana, es una excepción. Si ocurre dos semanas seguidas, el problema es del plan, no del equipo.

• Seguridad psicológica (el valor del "coraje")

XP exige coraje para decir "no" o "no sé", pero también exige el respeto de la dirección para escuchar esa verdad. Al eliminar la estimación basada en el miedo y reemplazarla por la "responsabilidad aceptada", donde quien hace el trabajo estima el trabajo, se reduce drásticamente la ansiedad por fechas límite irreales.

• El fin del concepto de "lobo solitario"

Mediante la Propiedad Colectiva del Código, XP elimina el estrés de ser la "única persona que sabe cómo funciona esto". Si alguien enferma o necesita vacaciones, el proyecto no se detiene y nadie tiene que recibir llamadas de emergencia en la playa.

¿Es la IA el fin del Pair Programming o su resurgimiento?

Una de las prácticas más polémicas de XP siempre ha sido el Pair Programming (dos personas, un ordenador). Con la llegada de Copilot, ChatGPT, Windsurf, Cursor u otro sin fin de opciones, muchas personas en gestión se preguntan: "¿Para qué pagar a dos personas si tengo una IA?".

A la pregunta de si la IA sustituirá al perfil de desarrollo en la programación podría responderse con otra analogía: “El piloto automático en los aviones lleva décadas funcionando, optimizando el trabajo, pero nunca ha reemplazado al piloto. ¿Por qué sigue siendo necesario el factor humano?”.
En el caso de los equipos de programación, no podemos depender del Vibe Coding (de la misma forma que no podemos depender únicamente del piloto automático en los vuelos).

El Vibe Coding genera código que aparenta ser funcional, pero que es incomprensible y a la larga imposible de mantener, lo que puede provocar fallos en producción por falta de supervisión humana, con un coste e impacto a la larga mucho mayores.

Para evitar este escenario, XP propone una evolución crucial:

• De "Driver y Navigator" a "Cyborg Pairing". La IA no reemplaza a nadie; eleva el nivel de la pareja. En el nuevo modelo, la IA actúa como un "acelerador de aprendizaje" para los perfiles junior, reduciendo el tiempo que tardan en buscar información, pero (y esto es crítico) sin eliminar la necesidad de validación humana.
• El peligro del "Vibe Coding". Martin Fowler y Kent Beck advierten sobre el riesgo de aceptar código de IA porque "parece que funciona" (vibe coding). XP actúa como contrapeso: el Pair Programming humano sigue siendo vital para la estrategia y el diseño arquitectónico, áreas donde la IA tiende a alucinar o crear deuda técnica compleja. La IA escribe, el ser humano navega y XP pone las reglas de tráfico.

TDD, ¿por qué trabajar el doble para ir más rápido?

XP exige escribir el test antes que el código (Test-Driven Development).

• TDD no es una técnica de testing, es una técnica de gestión de ansiedad. Saber que tienes una red de seguridad automatizada que te avisa en segundos si rompiste algo da una confianza "extrema" al equipo.
• La IA es excelente generando tests. Utilizar la IA para generar la batería de pruebas TDD antes de generar el código es el "truco" definitivo de productividad segura. Convierte a la IA en el guardián de calidad más estricto.

La muerte de la documentación (tal como la conocemos)

XP tiene fama de no documentar, lo cual es falso, pero se debe a que rompe (con el manifiesto ágil) a seguir haciendo la documentación tal y como la conocíamos en los años 80’s (páginas y páginas de información que rara vez se llegaban a consultar).

• XP se apoya en prácticas de clean code y código autoexplicativo que sea más fácil de entender por otra persona sin contexto.
• Hoy, disponemos de herramientas con IA que pueden leer ese clean code de XP y generar la documentación para negocio automáticamente. Pero esto solo funciona si el equipo ha seguido la disciplina de "Simplicidad" y "Nombrado" de XP. Si el código es un desastre, la IA documentará un desastre.

Conclusión: volver a lo humano para sobrevivir a lo artificial

En la era de la IA, la velocidad es una commodity. Cualquiera puede generar código rápido. La ventaja competitiva de un equipo ya no es cuánto código produce, sino su capacidad para mantenerlo, adaptarlo y, sobre todo, no implosionar por agotamiento en el proceso. XP es la metodología que nos recuerda que el software lo hacen personas, para personas.

La IA ya no es solo una herramienta de consulta, sino un ecosistema de agentes autónomos listos para tomar el control y operar en la nube.

En el episodio de hoy, el equipo de Goodly se reúne en su particular sanedrín para desgranar, ordenar y dar sentido a todos los anuncios, rebrandings y novedades que nos ha dejado este evento tecnológico de Google.

Gemini Enterprise Agent Platform, la gran apuesta de Google

Si te has perdido un poco con la sopa de letras y los cambios de nombres, no te preocupes, no te ha pasado solo a ti. El gran protagonista del evento ha sido Gemini Enterprise Agent Platform, el nuevo centro de mando que viene a reorganizar lo que antes conocíamos como Vertex AI.

El enfoque ha cambiado: ya no se trata únicamente de entrenar modelos, sino de ofrecer una plataforma empresarial centralizada para gobernar, monitorizar y desplegar nuestros agentes de IA, facilitando además su conexión a través de múltiples integraciones (MCPs).

La apuesta de Google por la ciberdefensa: agentes autónomos para mitigar amenazas en tiempo real

Pero tener ejércitos de agentes operando en la nube requiere un pilar fundamental: la seguridad. Por ello, Google ha dado un golpe en la mesa presentando nuevos agentes autónomos especializados en ciberdefensa, capaces de buscar amenazas de forma activa (Threat Hunting) y mitigarlas en tiempo real.

Esto, sumado a las esperadas mejoras en el entorno de Google Workspace (que por fin incorpora skills y un contexto unificado de usuario para hacer frente a la competencia) demuestra que la estabilización de la IA en el entorno corporativo ya es una realidad.

Cloud Run y BigQuery siguen encandilando a los perfiles tech

Más allá de la fiebre agéntica, las grandes superestrellas clásicas de GCP no se han quedado atrás y han reclamado su cuota de pantalla. Cloud Run sigue enamorando a los equipos de desarrollo introduciendo entornos aislados (sandbox), montajes directos de volúmenes y, lo más aclamado, límites estrictos de facturación para evitar sustos en la tarjeta.

Por su parte, BigQuery mejora su ecosistema de compatibilidad y nos sorprende integrando consultas continuas impulsadas por IA que reaccionan a flujos de eventos en tiempo real.

Más allá de lanzamientos y novedades

Como en todo buen evento, también ha habido espacio para el "salseo": desde el inoportuno lanzamiento de un nuevo modelo por parte de la competencia en pleno Next, hasta el gran misterio de por qué seguimos esperando la versión GA de Gemini 3.1 en Europa.

Si quieres enterarte de lo bueno, lo malo y de todo lo que echamos en falta, ponte los cascos y escucha este nuevo episodio de “Cómo conocí a nuestro cloud”. ¡No te lo pierdas!

Este detalle, que puede parecer una tontería, es precisamente lo que separa un producto digital bien cuidado y pensado de una aplicación genérica y aburrida.

Ojo, tampoco hace falta llenar tu web de animaciones innecesarias. Pero cuando las usas en el lugar justo (como en ese botón de acción principal) consigues algo muy potente: que el usuario reciba un feedback inmediato y satisfactorio.
Y en realidad, hacer este tipo de animaciones es mucho más sencillo de lo que parece. Así que en el post de hoy vamos a hacer, paso a paso, una microinteracción de partículas en un botón de like.

¿Qué herramientas vamos a necesitar?

Para este proyecto usaremos HTML, CSS y JavaScript, pero el verdadero motor de la animación será GSAP.

Si no has oído hablar de GSAP, es una de las herramientas más conocidas para animar casi cualquier cosa en la web. Nos ahorra un montón de tiempo (y de líneas de código) en comparación con la forma nativa de hacerlo.

He preparado un ejemplo en CodePen para que puedas probarlo y ver el resultado final ahora mismo, pero aún así lo vamos a ver paso a paso. Puedes ver el ejemplo pulsando sobre el siguiente enlace: Like Button (GSAP)

Estructura HTML: definiendo la estructura semántica del botón

Para empezar, vamos a configurar una estructura básica de HTML. Lo más importante aquí, además de enlazar nuestros archivos locales de estilos y lógica, es importar las librerías necesarias para que la animación de las partículas sea posible.

<html>
  <head>
    <meta charset="UTF-8">
    <link rel="stylesheet" href="./style.css">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Like Button</title>
  </head>
  <body>
    <!-- GSAP -->
    <script src="https://unpkg.com/gsap@3/dist/gsap.min.js"></script>
    <script src="https://assets.codepen.io/16327/Physics2DPlugin3.min.js"></script>

    <!-- SCRIPT -->
    <script src="./script.js"></script>
  </body>
</html>

Para que este efecto funcione correctamente, necesitamos importar dos piezas clave del ecosistema de GSAP:

• GSAP Core: es el motor principal de la librería. Es lo que nos permite crear las líneas de tiempo (timelines) y gestionar las propiedades básicas de los elementos que vamos a animar.
• Physics2DPlugin: este plugin es el motor de simulación física de la animación. Nos permite definir parámetros como la gravedad, la velocidad y el ángulo de dispersión, delegando en GSAP todos los cálculos matemáticos complejos necesarios para lograr trayectorias realistas.

Nota: el plugin Physics2D es una herramienta premium de GSAP. En este ejemplo lo utilizamos mediante la URL específica para uso en CodePen, pero requiere una licencia si tienes pensado implementarlo en un proyecto comercial.

Ahora, dentro de nuestro <body> (y siempre antes de las etiquetas <script>), añadiremos la estructura del botón.

<button id="like-btn">
  <div id="emitter">
    <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2" stroke="currentColor">
      <path stroke-linecap="round" stroke-linejoin="round" d="M21 8.25c0-2.485-2.099-4.5-4.688-4.5-1.935 0-3.597 1.126-4.312 2.733-.715-1.607-2.377-2.733-4.313-2.733C5.1 3.75 3 5.765 3 8.25c0 7.22 9 12 9 12s9-4.78 9-12Z" />
    </svg>
  </div>
  <span>Like</span>
</button>

En este esquema hemos definido dos identificadores importantes:

• like-btn: es el ID del botón principal. Lo utilizaremos en JavaScript para escuchar el evento de clic y para gestionar los cambios de estilo o texto cuando se interactúe con él.
• emitter: este elemento es esencial. Actúa como el contenedor del icono, pero su función principal es servir de "punto de origen" para las partículas. Al tenerlo separado, podemos controlar que la explosión nazca exactamente desde la posición del corazón y no desde cualquier parte del botón.

Estilos CSS: preparando la estética y el contenedor

Para definir los estilos, crearemos un archivo llamado style.css. El primer paso será importar la tipografía y definir una serie de variables CSS (Custom Properties). Esto nos permitirá gestionar los colores y valores reutilizables desde un solo lugar, haciendo que nuestro diseño sea mucho más fácil de mantener.

@import url('https://fonts.googleapis.com/css2?family=DM+Sans:ital,opsz,wght@0,9..40,100..1000;1,9..40,100..1000&display=swap');

:root{
  --color-bg: #e9ecef;
  --color-primary: #495057;
  --color-accent: #ff3562;
  --color-on-accent: #ffffff;

  --text-sm: 1.1em;
  --text-md: 1.8rem;
    
  --transition-default: all 0.25s ease;
}

A continuación definiremos el estilo global para limpiar márgenes y centrar nuestro botón en pantalla.

*{
  font-family: "DM Sans", sans-serif;
}

body,
html {
  height: 100%;
  margin: 0;
  padding: 0;
  overflow: hidden;
}

body {
  display: flex;
  align-items: center;
  justify-content: center;
  flex-direction: column;
  min-height: 100vh;
    background-color: var(--color-bg);
}

Además, prepararemos la clase .particles-container. Aunque este contenedor lo crearemos dinámicamente en JavaScript, por claridad del código, el estilo lo definiremos aquí:

.particles-container {
  position: absolute;
  left: 0;
  top: 0;
  overflow: visible;
  z-index: 2;
  pointer-events: none;
  opacity: 0;
}

En la clase .particles-container, hay un par de propiedades que merecen especial atención:

• z-index: 2: el z-index es la propiedad que controla el orden de apilamiento de los elementos en el eje Z (profundidad). Por defecto, los elementos tienen un valor de 1 (o auto). Si queremos que las partículas exploten por encima del botón y no queden ocultas detrás de él, debemos asignarles un valor superior, en este caso 2.
• pointer-events: none: esta propiedad es clave. Evita que las partículas interfieran con el ratón. De esta forma, aunque una partícula pase por encima del cursor, el usuario podrá seguir haciendo clic en el botón sin problemas.
• opacity: 0: inicialmente, el contenedor es invisible. Solo lo mostraremos mediante GSAP en el momento exacto de la animación.

El siguiente paso es definir el estilo de nuestro botón. Verás que aquí hacemos uso de las variables CSS que definimos al principio, lo que nos permite mantener el código más limpio y coherente.

Además, prepararemos el estado .clicked. Esta clase la añadiremos mediante JavaScript en el momento del clic para modificar el estilo del botón y sus elementos internos (como el icono y el texto):

button{
  border-radius: 8px;
  cursor: pointer;
  padding: 12px 26px;
  font-size: var(--text-md);
  border: 2px solid var(--color-primary);
  display: flex;
  align-items: center;
  gap: 12px;
  color: var(--color-primary);
  background-color: #e9ecef;
  transition: var(--transition-default);
}

button.clicked{
  border-color: var(--color-accent);
  background-color: var(--color-accent);
  color: var(--color-on-accent);
}

button svg{
  width: var(--text-sm);
  fill: var(--color-primary);
  stroke: var(--color-primary);
  transition: var(--transition-default);
}

button.clicked svg{
  fill: var(--color-on-accent);
  stroke: var(--color-on-accent);
}

Por último, necesitamos definir el aspecto de la partícula. En este ejemplo se ha optado por un diseño de puntos circulares. No obstante, este estilo lo puedes ajustar como más te guste.

.dot {
  position: absolute;
  border-radius: 50%;
}

Lógica con JavaScript: creando el sistema de partículas con GSAP

Es hora de pasar a la acción. Ahora configuraremos la lógica necesaria para que el botón responda a nuestros clics y genere la explosión de partículas. Todo este proceso lo gestionaremos desde nuestro archivo script.js.

Paso 1. Registrar los plugins de GSAP

Lo primero que debemos hacer es registrar el plugin al motor principal de GSAP. Esto es fundamental para que la librería reconozca las propiedades físicas que vamos a usar más adelante.

gsap.registerPlugin(Physics2DPlugin);

Paso 2. Declarar los elementos

En este paso vamos a capturar los elementos del DOM con los que vamos a interactuar. También aprovecharemos para crear, de forma dinámica, el contenedor donde vivirán nuestras partículas:

// Main emitter element (used as explosion origin)
const emitter = document.getElementById("emitter");

// Like button + text
const likeBtn = document.getElementById("like-btn");
const text = likeBtn.querySelector("span");

// Container that holds all particles
const container = document.createElement("div");
container.className = "particles-container";
document.body.appendChild(container);

Paso 3. Configuración de GSAP y estados

En este punto definiremos las variables que controlan el comportamiento de nuestra animación. Lo interesante de este enfoque es que, simplemente modificando estos valores, puedes transformar por completo el efecto.

Te animo a que pruebes a cambiar los parámetros como la velocidad o la gravedad para ver cómo cambia la física del movimiento. Además, en este paso, aprovecharemos para declarar el estado inicial del botón:

const emitterSize = 2;        // spawn area radius
const dotQuantity = 12;     // number of particles
const dotSizeMax = 12;      // max particle size
const dotSizeMin = 4;       // min particle size
const speed = 0.6;            // initial velocity multiplier
const gravity = 0.1;          // gravity strength

// Toggle state (liked / not liked)
let liked = false;

Paso 4. Configuración de la explosión

En este paso crearemos una función reutilizable que se encargará de generar la "explosión" cada vez que sea llamada. La idea es crear un timeline de GSAP que contenga las animaciones individuales de cada partícula.

const explosion = createExplosion(container);

function createExplosion(container) {
  const tl = gsap.timeline({ paused: true });

  for (let i = 0; i < dotQuantity; i++) {

    // Create particle element
    const dot = document.createElement("div");
    dot.className = "dot";

    // Assign random color
    const colors = ["#ff4d6d", "#fb6f92", "#ff8fab", "#ffb3c1", "#cdb4db", "#a2d2ff"];
    dot.style.backgroundColor = colors[Math.floor(Math.random() * colors.length)];

    container.appendChild(dot);

    // Random size & direction (angle in radians)
    const size = gsap.utils.random(dotSizeMin, dotSizeMax, 1);
    const angle = Math.random() * Math.PI * 2;

    // Initial offset inside emitter radius
    const length = Math.random() * (emitterSize / 2 - size / 2);


    gsap.set(dot, {
      x: Math.cos(angle) * length,
      y: Math.sin(angle) * length,
      width: size,
      height: size,
      xPercent: -50,
      yPercent: -50,
      force3D: true,
      scale: gsap.utils.random(0.8, 1.2)
    });

    tl.to(
      dot,
      {
        physics2D: {
          angle: (angle * 180) / Math.PI, // convert to degrees
          velocity: (120 + Math.random() * 200) * speed,
          gravity: 500 * gravity
        },
        duration: 1 + Math.random()
      },
      0
    )
    .to(
      dot,
      {
        opacity: 0,
        scale: 0.5,
        duration: 0.3,
        ease: "power2.in",
      },
      0.3
    );
  }

  return tl;
}

En esta función hay algunos conceptos técnicos que debemos entender:

1. Bucle de creación. Usamos un for basado en la variable dotQuantity para generar todas las partículas de golpe. Cada una recibe un color y un tamaño aleatorio para que la explosión no parezca artificial ni repetitiva.
2. Cálculo de trayectoria. Utilizamos funciones matemáticas (Math.cos y Math.sin) para posicionar las partículas en un círculo alrededor del punto central. Es lo que permite que salgan disparadas en todas las direcciones (360 grados).
3. El poder de Physics2D. En lugar de animar manualmente las coordenadas x e y, simplemente le pasamos al plugin un ángulo, una velocidad y una gravedad. GSAP se encarga de dibujar la parábola perfecta de caída.
4. Sincronización (parámetros de posición). Verás que las funciones .to() tienen un 0 o un 0.3 al final. En GSAP, esto se llama Position Parameter.

• El "0": obliga a todas las partículas a empezar su animación exactamente en el segundo cero del cronómetro. Sin este "0", las partículas saldrían una detrás de otra y gracias a él, todas saltan a la vez creando la sensación de explosión.
• El "0.3": indica que la partícula debe empezar a desvanecerse (opacidad 0) cuando el cronómetro llegue a los 0.3 segundos, permitiendo que la partícula desaparezca mientras todavía se está moviendo, logrando un efecto mucho más fluido y natural.

Paso 5. Función de la explosión

Una vez que tenemos la lógica de la animación preparada, necesitamos una función que "coloque" el contenedor de partículas en el lugar correcto y active el movimiento. Sin este paso, las partículas podrían aparecer en una esquina de la pantalla en lugar de nacer desde el centro del botón.

function explode(element) {
  const bounds = element.getBoundingClientRect();

  // Move container to element center
  gsap.set(container, {
    x: bounds.left + bounds.width / 2,
    y: bounds.top + bounds.height / 2,
    opacity: 1
  });

  // Restart animation from the beginning
  explosion.restart();
}

Esta función se encarga de posicionar el efecto en el espacio: primero, utilizamos getBoundingClientRect() para calcular las coordenadas exactas del botón en la pantalla y, mediante gsap.set(), movemos instantáneamente el contenedor de partículas a su centro.

Finalmente, ejecutamos explosion.restart() para que el timeline de la animación vuelva al inicio y se reproduzca desde cero con cada nuevo clic, asegurando que la explosión nazca siempre desde el lugar correcto.

Paso 6. Evento de clic e interacción final

Para terminar, necesitamos detectar cuándo el usuario interactúa con el botón y disparar toda la lógica que hemos programado. Con el siguiente código, gestionamos el cambio de estado, la actualización visual y el lanzamiento de las partículas:

likeBtn.addEventListener("click", () => {

  // Toggle like state
  liked = !liked;
  text.textContent = liked ? "Liked" : "Like";

  // Toggle active class (for styling)
  likeBtn.classList.toggle("clicked", liked);

  // Button press animation (quick scale feedback)
  gsap.fromTo(
    likeBtn,
    { scale: 1 },
    { scale: 0.9, duration: 0.1, yoyo: true, repeat: 1 }
  );

  // Trigger particle explosion
  liked && explode(emitter);
});

En este bloque final ocurren dos cosas clave:

• Feedback táctil: mediante gsap.fromTo, creamos una sensación de pulsación real haciendo que el botón se escale ligeramente. El uso de yoyo: true hace que el botón vuelva a su tamaño original automáticamente.
• Lógica condicional: gracias al operador &&, la función explode solo se ejecuta cuando el usuario da "Like", evitando que las partículas salten también al deshacer la acción.

Espero que este post te haya ayudado a entender mejor cómo funcionan este tipo de efectos y que, a partir de ahora, te sientas capaz de implementar tus propias animaciones de partículas para dar un toque extra de "magia" a tus interfaces. ¡A experimentar!

En este post te contamos la realidad. ¿Qué sucede si no mides la latencia, el coste por token y la trazabilidad de cada llamada? Simplemente, tendrías un experimento poco útil para un entorno profesional. Integrar LLMs en producción requiere una mentalidad de ingeniería donde el prompt es solo la punta del iceberg de un sistema complejo y auditable.

¿Es el prompting una moda o una disciplina de ingeniería?

Existe una idea equivocada que simplifica el rol de ingeniería de prompts a saber redactar instrucciones a modelos de lenguaje con buenos modales. La realidad en los equipos de desarrollo es otra muy distinta. Cuando intentas escalar un sistema agéntico, te das cuenta de que el prompt es código y, como tal, necesita versionado, pruebas y monitorización constante.

Nos hemos encontrado con organizaciones que lanzan prompts directamente en su código fuente, creando un infierno operativo cada vez que quieren ajustar una coma o probar un modelo nuevo. Tratar el prompt como un activo externo y gestionado permite iterar sin desplegar de nuevo toda la infraestructura de microservicios.

El problema real surge cuando pasamos de un simple chat a una malla de agentes especializados. Aquí, un error de interpretación en el "agente supervisor" puede derivar en un bucle sin fin de llamadas a la API que disparen la factura a final de mes. Diseñar un sistema de IA robusto implica controlar qué modelo responde a cada tarea según su complejidad.

¿Cuánto te cuesta realmente cada palabra que genera tu modelo?

Si no tienes visibilidad sobre el consumo de tokens, estás navegando a ciegas. La elección del modelo es una cuestión de economía de procesos. Utilizar modelos de alto rendimiento para tareas de clasificación simple es un desperdicio de recursos que penaliza tanto el presupuesto como la experiencia de usuario por la latencia acumulada. En nuestras implementaciones, segmentamos las tareas: dejamos los modelos más pesados para el razonamiento complejo y recurrimos a versiones "Flash" o modelos locales para la extracción de metadatos o la categorización de intenciones.

¿Por qué conformarse con la respuesta que sale a la primera? La optimización del prompt mediante técnicas avanzadas de Few-Shot o Chain of Thought mejora la precisión y reduce la necesidad de reintentos. Cada llamada fallida o alucinada es tiempo de espera para el usuario y dinero tirado a la basura en llamadas innecesarias. La trazabilidad end-to-end se vuelve obligatoria para entender en qué paso de la cadena se está perdiendo la eficiencia o dónde el modelo está empezando a divagar.

¿Por qué seguir operando una caja negra sin métricas reales?

La observabilidad es el gran talón de Aquiles de muchos proyectos de IA. Aquí es donde herramientas como Langfuse entran en juego para dar luz sobre lo que ocurre tras cada petición. No basta con saber que el sistema respondió, necesitamos saber cuánto tardó cada nodo del grafo de ejecución, qué versión del prompt se utilizó y si el contexto recuperado (RAG) fue realmente útil para la respuesta final. Contar con un repositorio centralizado de prompts con políticas de caché nos permite reducir la latencia de recuperación, garantizando que el sistema sea escalable en entornos de alta demanda.

La evaluación no puede ser subjetiva. Implementamos sistemas de "LLM-as-a-judge" y datasets de prueba para calificar automáticamente la toxicidad, la concisión y la fidelidad de las respuestas, entre otros evaluadores, frente a una "verdad absoluta". Automatizar la evaluación del rendimiento nos permite detectar regresiones de calidad antes de que el usuario final se encuentre con una respuesta incoherente.

¿Cómo influye el tamaño del modelo en la estructura de tus instrucciones?

No todos los LLMs procesan la información con el mismo nivel de agudeza, y aquí es donde la eficiencia de costes choca con la realidad técnica.

En nuestra arquitectura orquestamos versiones flash, mini, nano o pro dependiendo de la tarea, lo que nos ha llevado a confirmar una regla inversamente proporcional: a mayor tamaño del modelo, menor esfuerzo de prompting necesitas. Si disparas contra un modelo pesado, rara vez te hará falta montar una estructura laberíntica para obtener un resultado decente, ya que el sistema lo resuelve por pura fuerza bruta.

El problema llega cuando necesitas optimizar la latencia al milisegundo y configuras modelos con menos parámetros. Esta exigencia técnica crece de forma exponencial: cuanto más ligero es el modelo, más te obliga a diseñar un prompt avanzado y sin ambigüedades para evitar que devuelva respuestas inconsistentes.

Conclusiones

El éxito de una implementación de IA generativa no depende de encontrar el "prompt mágico", depende de construir un ecosistema de ingeniería a su alrededor. Controlar la latencia, optimizar los costes mediante la selección inteligente de modelos y medir cada interacción con herramientas de observabilidad son los pasos obligatorios para cualquier equipo que quiera salir de la fase de prototipo. La transparencia operativa es la única forma de generar confianza en sistemas que, por definición, son probabilísticos.

Por si te ha quedado alguna duda de que cualquier perfil puede trabajar como ingeniero/a de prompts, te dejo este bonus extra:

¿Hablas con el motor real o con la versión edulcorada?

Existe un choque de realidad cuando pasas de interactuar con un modelo de lenguaje desde su interfaz conversacional a integrarlo mediante código. La interfaz que consumes a diario esconde un prompt de sistema inmenso que condiciona todo. Esa cortesía artificial y la tendencia a dar explicaciones extensas son producto de una capa diseñada específicamente para el usuario final. Al conectar tu sistema directamente contra la API, te estrellas contra un entorno crudo que no asume absolutamente nada por ti. Aquí desaparecen los asistentes proactivos y te topas con sistemas vagos. Operar a este nivel te obliga a construir tus propias barreras de contención. Cada detalle marca la diferencia.
Si sigues pensando que este perfil no es necesario en un equipo de IA y te atreves a intentarlo, ¡SUERTE🍀!. Te leo en comentarios 👇.

Referencias y enlaces

• Documentación de integración con Langfuse
• Guía de gestión de prompts y caché de dos niveles
• Sistemas de evaluación de calidad y fidelidad en LLMs
• Arquitectura de orquestación agéntica con LangGraph

Del 22 al 24 de abril, el mundo cloud mirará hacia Google para ver qué cartas tiene bajo la manga. En este episodio de "Cómo conocí a nuestro cloud", nos mojamos y abrimos la veda de las predicciones para adivinar qué veremos en el evento más importante del año para el ecosistema de Google Cloud.

Tras un año marcado por la consolidación de Gemini 3 y la resaca de la fiebre de la IA generativa, la gran pregunta es si este Next servirá para afianzar el dominio de Google o si seguiremos en una fase de "anuncios en preview".

Analizamos la agenda del evento y los datos son claros: la IA sigue devorándolo todo. Con apenas un 10% de sesiones que no mencionan palabras como GenAI o Gemini, parece que la infraestructura tradicional ha quedado relegada a ser el soporte silencioso de la inteligencia artificial.

Debatimos sobre el futuro de los protocolos de integración, con el dilema entre cuándo usar MCPs y cuándo usar A2A, y cómo la incertidumbre tecnológica está frenando la adopción masiva en el mundo enterprise.

También ponemos el foco en el hardware: ¿veremos una nueva versión de las TPUs (Ironwood) que logre romper el monopolio de NVIDIA? Además, exploramos la necesidad de que Google "cierre el círculo" integrando de verdad la IA en el flujo de trabajo diario de Workspace, para que generar una presentación de slides deje de ser una batalla contra imágenes estáticas.

Para terminar, no podíamos cerrar sin nuestra clásica sección de triples. Desde apuestas arriesgadas por el mundo multimedia y la generación de mundos, hasta la posible explosión de Project Astra o la integración total de conectores externos en la App de Gemini.

¿Cuántos de nuestros vaticinios se harán realidad? No te pierdas esta tertulia con la "aristocracia" del programa: José Berenguer, Andrés Navidad, Óscar Ferrer y Tomás Calleja.

Como todo en la nube, el Next promete emociones fuertes y algún que otro suflé que puede desinflarse.

¡Escucha el episodio completo y prepárate para el evento del año!

Sin embargo, para el perfil de Manager/Scrum Master/ Flow Master que busca no solo organizar tareas, sino garantizar la excelencia técnica y la sostenibilidad del equipo, pasar por alto XP es un error estratégico. Mientras otros marcos se centran en el flujo de gestión, XP pone el foco en la trinchera, en cómo se construye el producto para que sea robusto, flexible y rentable.

¿Qué es XP?

Si nunca has profundizado en XP, piensa en ello no como una invención radical, sino como una recopilación de aquello que funciona. Del mismo modo que J.R.R. Tolkien no inventó los mitos de elfos y enanos, sino que recopiló y sistematizó siglos de folclore europeo para crear una mitología coherente y funcional, Kent Beck hizo lo mismo con la ingeniería de software a finales de los ‘90.

Beck no inventó las pruebas, ni la revisión de código, ni la comunicación con el cliente. Lo que hizo XP fue recopilar estas "buenas prácticas" aisladas, que la industria ya sabía que mejoraban la calidad, y llevarlas al extremo de su efectividad, ordenándolas bajo un criterio unificado.

A parte de la excelencia en las buenas prácticas técnicas, en XP también destacó la importancia de tener lo que hoy entendemos por Product Owner presencialmente junto al equipo (on-site customer) para mejorar la conversación entre negocio y desarrollo (en aquel momento denominado “cliente”). Además, una de las aportaciones de XP al Agilismo, y la que tal vez sea la más recordada, son las Historias de Usuario tal y como las conocemos hoy (con las 3 C’s) para tumbar los requisitos pesados y difíciles de entender por el Dev Team.

En definitiva XP es un marco diseñado para reducir el riesgo en proyectos con requisitos vagos o cambiantes aplicando buenas prácticas técnicas, favoreciendo la comunicación entre las partes y descartando aquello que no se necesita en este momento. En resumen: priorizando la satisfacción del cliente y la calidad del software.

Hasta aquí el resumen rápido de lo que es XP para aquellos que no fueron a clase ese día.
Pero cuidado: creer que XP es solo esto (un puñado de buenas prácticas de programación) es como leer la siguiente sinopsis: "es la historia de una familia disfuncional en el espacio" y creer que ya conoces la saga de Star Wars.

Lo que esa sinopsis omite es el verdadero valor para quien lidera el equipo. XP es un sistema de gestión de riesgos y seguridad psicológica.
XP asume que la agilidad sin excelencia técnica acaba convirtiéndose en una fábrica de deuda técnica. Por eso, crea una red de seguridad inquebrantable (a través de pruebas automatizadas, integración continua y diseño simple) que garantiza que el equipo pueda ir rápido, adaptar cambios constantes y no sufrir burnout en el proceso. Es la garantía de que la velocidad no destruya la calidad.

Y es precisamente este dilema entre velocidad y seguridad el que nos golpea de lleno en la actualidad.

Hoy tenemos en nuestras manos el mayor acelerador de producción de la historia: la Inteligencia Artificial Generativa. Pero generar código a una velocidad vertiginosa no es lo mismo que generar código mantenible o correcto. ¿Cómo gobernamos esta nueva hiper-velocidad sin quemar al equipo ni romper el producto? La respuesta lleva casi 30 años inventada.

Una nueva esperanza: evolucionando XP con Inteligencia Artificial

¿Cómo encaja este marco de los ‘90 en la era de la IA Generativa? La realidad es que la irrupción de la IA no hace que XP sea obsoleto, al contrario, lo convierte en la estructura de seguridad necesaria para esta nueva velocidad. Estamos ante el nacimiento del AI-XP (término usado por Justin Beall).

La integración de la IA en XP no es solo usar herramientas de autocompletado, es una evolución sistémica que potencia los principios originales del marco a través de tres bucles de retroalimentación modernizados. Según Justin Beall, estos bucles son:

1. VISION (Planificación). Donde antes dependíamos solo de la intuición humana para definir objetivos a largo plazo, ahora la IA puede analizar datos de mercado para alinear el "Planning Game" de XP con necesidades reales y predicciones de tendencias.
2. ADAPT (Iteraciones ágiles). La IA actúa como un facilitador que mejora la capacidad de respuesta. Puede ayudar a descomponer historias de usuario complejas y asegurar que todo el equipo entienda los criterios de aceptación, eliminando la ambigüedad en la comunicación.
3. LEAP (Ejecución diaria). Aquí es donde la práctica clásica del Pair Programming evoluciona hacia el "AI Pairing". La IA asume las tareas rutinarias y de generación de código base, permitiendo que la persona de desarrollo, que llamaremos "navegante", se centre en la estrategia, la seguridad y el diseño.

Las nuevas paradojas del AI-XP

Antes de cantar victoria y asumir que la IA más las prácticas de los '90 resolverán todos nuestros problemas, como líderes técnicos y de gestión debemos pararnos a reflexionar. La adopción de este nuevo modelo trae consigo paradojas e incertidumbres que cambiarán las reglas del juego:

• La paradoja de las historias de usuario

En su origen, XP nos liberó de los tediosos documentos de requisitos de cientos de páginas creando las historias de usuario (promesas de una conversación escritas en un par de líneas). Sin embargo, hoy, para que un modelo de IA no alucine y genere código útil, necesitamos nutrirlo con un contexto profundísimo (SPECs hiper-detalladas, prompts exhaustivos, reglas de negocio escritas). ¿Estamos volviendo a la era de la hiper-documentación técnica solo para que la máquina nos entienda? El reto será que el exceso de especificaciones para la IA no mate la conversación entre humanos.

• La redefinición del "equipo híbrido"

Hace apenas un par de años, el gran debate en el management era cómo gestionar equipos híbridos, refiriéndonos exclusivamente a la dicotomía entre trabajo presencial y 100% remoto. Hoy, el concepto ha mutado radicalmente: un equipo híbrido moderno es el formado por mentes humanas y agentes de Inteligencia Artificial. Gestionar la confianza, las expectativas y el flujo de trabajo en esta nueva convivencia es el verdadero desafío del Agile Coach de esta década.

• La IA como el nuevo "silo de conocimiento"

XP promovía la Propiedad Colectiva del Código para evitar que el conocimiento residiera en una sola persona (el temido "bus factor"). Pero, ¿qué ocurre si la IA escribe la mayor parte de la base de código y los equipos de desarrollo se limitan a hacer aprobaciones rápidas? Corremos el riesgo de convertir a la IA en una "caja negra", perdiendo el control y la comprensión profunda de nuestro propio producto.

Retorno a la humanidad

Como conclusión, la IA tiene el potencial de acelerar la producción de software, pero también de acelerar el caos si no hay gobierno, y XP proporciona ese gobierno. Al automatizar la complejidad técnica y la generación de código rutinaria, la IA permite que XP cumpla su promesa original más ambiciosa: humanidad y respeto.

Al liberarnos de la tarea mecánica de "picar código" repetitivo, los equipos pueden centrarse en lo que XP siempre valoró más: la creatividad, la resolución de problemas complejos y la colaboración humana de alto valor. XP no ha muerto, simplemente ha encontrado, treinta años después, la herramienta perfecta para alcanzar su máximo potencial.

En este post os quiero enseñar cómo diseñé un pipeline de NLP para atacar este problema. No es solo "meter IA por meter", sino crear un flujo lógico que clasifica, extrae y limpia la información por nosotros. Lo bueno de este enfoque es que, con un par de ajustes, te sirve igual para riesgos que para clasificar tickets de soporte o contratos legales.

Lo que vamos a construir hace cuatro cosas clave:

• Prioriza. ¿Esto es un incendio o un aviso rutinario?
• Etiqueta. ¿Es fraude, un fallo técnico o un tema legal?
• Detecta datos. Saca IPs, cuentas, correos... lo "duro".
• Entiende el contexto. Identifica qué leyes o empresas se mencionan.

La arquitectura del flujo (Keep it simple)

No hace falta complicarse la vida con modelos gigantes para todo. Aquí combinamos lógica de negocio (reglas) con modelos estadísticos.

El flujo es este:

Documento bruto → Clasificador de Urgencia → Etiquetado de Riesgos → Extractor de Datos Técnicos → NER (Entidades) → JSON Estructurado.

Un caso real para probarlo

Para que no sea todo teoría, vamos a usar este aviso de incidencia (me lo he inventado, pero es muy parecido a lo que te podrías encontrar en un sistema real):

ALERTA DE RIESGO OPERACIONAL - ID-2026-00142 Se ha detectado un fallo crítico en el sistema de procesamiento de transacciones... afecta a tarjetas de crédito. Empezó a las 14:23 UTC y afecta a unos 15.000 clientes. Datos: IP 192.168.1.50 | Error: ERR-DB-TIMEOUT | TXNs: TXN-A7B3C9D2, TXN-F4E8A1B6. Ojo: Supera el umbral del 0.5% de la MiFID II. Hay que avisar a la CNMV.

Clasificando la quemazón: criticidad

Lo primero es saber si tenemos que mandar un mensaje al jefe o si puede esperar a mañana. Para esto, usamos un sistema de pesos. Si aparecen palabras como "sanción" o "fraude", el score sube como la espuma.

class CriticalityClassifier:
    def __init__(self):
        # Aquí definimos qué nos quita el sueño
        self.keywords_critico = {'fraude': 10, 'pérdida': 10, 'incumplimiento': 10, 'multa': 10}
        self.keywords_alto = {'riesgo': 7, 'alerta': 6, 'fallo': 5}
        # ... (otros niveles)

    def _calculate_scores(self, text: str):
        text_lower = text.lower()
        # Sumamos puntos según lo que encontremos
        return {
            'critico': sum(w for k, w in self.keywords_critico.items() if k in text_lower),
            'alto': sum(w for k, w in self.keywords_alto.items() if k in text_lower),
            # ...
        }

Resultado: en nuestro ejemplo, nos daría un nivel ALTO con una confianza del 57%. Suficiente para disparar una alerta automática.

¿De qué estamos hablando? (Categorías)

Un documento puede ser de varias cosas a la vez. Por ejemplo: tecnológico (caída de servidor) y cumplimiento (incumplimos una norma). He usado patrones de Regex precompilados porque, sinceramente, para palabras clave específicas son mucho más rápidos y baratos que una red neuronal.

# Un pequeño mapa de qué buscar para cada riesgo
self.category_keywords = {
    'operacional': ['fallo', 'error', 'caída', 'incidencia técnica'],
    'cumplimiento': ['normativa', 'sanción', 'cnmv', 'mifid'],
    'ciberseguridad': ['ataque', 'malware', 'hackeo', 'brecha']
}

Extracción de "hilos" técnicos

Aquí es donde el NLP brilla ahorrando tiempo. En lugar de que un analista copie y pegue las IPs o los códigos de error, dejamos que las expresiones regulares hagan el trabajo sucio.

Sacamos a la vez:

• IPs: 192.168.1.50
• IDs de transacción: TXN-A7B3C9D2
• Emails: incidencias@banco-ejemplo.com

NER. ¿Quién es quién?

Para extraer entidades (organizaciones, leyes, productos), uso spaCy. Es la navaja suiza para esto. Le añadimos un diccionario personalizado porque spaCy sabe qué es una "persona", pero a veces le cuesta entender qué es la "MiFID II" o la "CNMV" si no se lo decimos.

# Combinamos spaCy con nuestras propias reglas de dominio
self.custom_entities = {
    'normativas': ['mifid ii', 'gdpr', 'pci dss'],
    'organismos': ['cnmv', 'bce', 'banco de españa']
}

El resultado final: JSON

Al final, el pipeline nos escupe algo así de limpio:

{
  "criticality": "alto",
  "categories": ["operacional", "cumplimiento", "tecnológico"],
  "indicators": {
    "ipv4": ["192.168.1.50"],
    "error_code": ["ERR-DB-TIMEOUT"]
  },
  "entities": {
    "normativas": ["MiFID II"],
    "organismos": ["CNMV"]
  }
}

¿Esto escala?

Si lo lanzas de forma secuencial, te puede dar el sueño. Pero usando ThreadPoolExecutor en Python, he conseguido procesar unos 1.500 documentos por minuto. Para la mayoría de empresas, eso sobra para procesar todo el flujo de entrada en tiempo real.

• Métricas reales:
• Latencia: 38ms (vuela).
• Precisión: ~95% (el 5% restante suele ser lenguaje muy ambiguo que requiere ojo humano).

Conclusión

Automatizar esto no es solo por ahorrar costes, es por reacción. Si un sistema detecta un incumplimiento normativo en 40 milisegundos, puedes mitigar el riesgo antes de que se convierta en una multa millonaria.

¿Qué opináis? ¿Meteríais modelos más pesados tipo Transformer (BERT/LLMs) o creéis que para clasificación de riesgos este enfoque híbrido es más estable? Os leo en comentarios.

Hoy es difícil encontrar un equipo técnico que no utilice asistentes como GitHub Copilot, Cursor o modelos conversacionales como Claude para acelerar tareas, resolver dudas o construir fragmentos de código con mayor rapidez.

La promesa inicial se ha cumplido en buena medida: escribir código es hoy más rápido que hace apenas dos años. Sin embargo, cuando el desarrollo sale del terreno individual y entra en el contexto de una gran organización, aparecen límites muy claros.

Porque una cosa es generar código que funciona y otra muy distinta generar código que encaja dentro de una arquitectura empresarial compleja, respeta estándares internos y sigue reglas técnicas que muchas veces no están escritas en un prompt.

Ese es precisamente uno de los grandes debates actuales en torno al llamado vibe coding: la idea de interactuar con la IA de forma casi conversacional, describiendo lo que se necesita y dejando que el modelo complete el resto.

En proyectos pequeños o prototipos rápidos puede resultar extremadamente eficaz, pero en sistemas corporativos con años de evolución, múltiples equipos y dependencias cruzadas, el contexto local ya no basta.

El problema de fondo es que estos asistentes trabajan, en la mayoría de los casos, con una visión parcial del sistema. Ven el archivo abierto, algunas referencias cercanas y las instrucciones inmediatas del desarrollador/a, pero no tienen acceso real a la fotografía completa de la organización: ni conocen las librerías aprobadas, ni distinguen qué patrones arquitectónicos son obligatorios, ni saben qué decisiones previas condicionan una implementación concreta.

Por eso, uno de los riesgos más frecuentes es que la IA produzca código técnicamente correcto, pero incompatible con el ecosistema real de la compañía.

Puede introducir dependencias no autorizadas, repetir soluciones ya resueltas internamente o romper convenciones críticas de diseño. A medida que crece el tamaño del sistema, también crece la entropía del software generado si no existe una guía estructurada.

En ese punto, la conversación deja de ser puramente sobre productividad y pasa a ser una cuestión de gobernanza tecnológica.

Del prompt aislado al conocimiento corporativo estructurado

La respuesta que muchas organizaciones están empezando a explorar consiste en dejar de tratar la IA como un simple asistente conversacional y empezar a integrarla dentro de una arquitectura de conocimiento empresarial.

Aquí es donde aparecen conceptos como RAG, MCP y SDD, tres piezas que juntas cambian completamente el enfoque.

El primero, Retrieval-Augmented Generation o RAG, permite que el modelo no dependa únicamente de su entrenamiento general, sino que consulte conocimiento interno antes de responder. Pero no basta con almacenar código sin más. La diferencia real aparece cuando ese conocimiento se organiza con jerarquía.

No todo el código tiene el mismo valor. Hay documentación, librerías comunes, aplicaciones históricas y, sobre todo, proyectos de referencia que representan cómo debe hacerse realmente una implementación dentro de la organización.

La IA necesita distinguir entre cualquier fragmento heredado y aquello que verdaderamente define el estándar interno.

Ese conocimiento estructurado es lo que permite que una respuesta deje de ser genérica y pase a parecerse al modo real de construir software dentro de una compañía.

MCP: el estándar que conecta la IA con el ecosistema real de desarrollo

La segunda pieza es MCP, un protocolo que está ganando protagonismo porque resuelve uno de los grandes problemas actuales: cómo conectar modelos de IA con herramientas corporativas sin crear integraciones frágiles.

En lugar de enlazar cada modelo con cada sistema interno de forma individual, MCP actúa como una capa estándar de conexión. Eso permite que distintos modelos puedan consultar las mismas fuentes sin depender de integraciones duplicadas.

En la práctica, esto significa que un modelo puede consultar información funcional de Jira, recuperar ejemplos del repositorio interno, acceder a convenciones por lenguaje o framework y mantener sesiones de trabajo consistentes sin que importe demasiado si detrás está Claude, GPT o cualquier otro modelo.

La clave no es solo conectar herramientas, sino desacoplar el conocimiento del modelo concreto que se esté utilizando.

Eso aporta algo especialmente valioso en entornos corporativos: flexibilidad tecnológica sin rehacer toda la arquitectura cada vez que cambia el modelo dominante.

El gran cambio: dejar de pedir código y empezar pidiendo intención

Donde realmente cambia el paradigma es en el flujo de trabajo. En el enfoque tradicional de asistentes, el/la desarrollador/a abre el IDE, redacta una instrucción y espera código.

Todo ocurre dentro de una conversación más o menos sofisticada. Pero cuando se trabaja con especificaciones guiadas, el proceso empieza antes del código.

Lo primero no es generar una implementación, sino una propuesta de cambio. A partir de una necesidad funcional o de una historia de usuario, el sistema construye una cadena de artefactos: especificaciones, diseño técnico, escenarios concretos y tareas de implementación. La IA deja de improvisar y empieza a trabajar sobre una intención formalizada.

Esto tiene una consecuencia importante: el contexto deja de depender de una conversación efímera y pasa a convertirse en un activo persistente.

Uno de los grandes límites del llamado context engineering es precisamente su fragilidad. Cada desarrollador/a construye manualmente el contexto que entrega al modelo, decide qué archivos incluir, qué ejemplos mostrar y qué instrucciones reforzar. Ese contexto desaparece cuando termina la sesión y no deja rastro verificable.

Además, cuando el volumen crece demasiado, aparece un fenómeno cada vez más conocido: la saturación de contexto. El modelo empieza a priorizar unas señales sobre otras, atiende menos a ciertas restricciones y pequeños ajustes pueden desalinear requisitos previamente bien resueltos. La IA no se vuelve inconsistente por azar: simplemente compite por atención dentro de una ventana finita.

Por eso el enfoque basado en especificaciones gana fuerza. Porque las specs se convierten en el verdadero contexto: estructurado, persistente, versionado y auditable.

Cuando el código no es la única fuente de verdad

En este modelo, el código ya no es el único artefacto importante. Cada decisión queda acompañada de su intención original, su diseño técnico y su validación funcional. Si algo cambia, no se corrige directamente el código: se actualiza la especificación y la implementación evoluciona desde ahí.

Esto transforma también el proceso de revisión. En un pull request, el revisor ya no ve únicamente líneas nuevas o modificadas. Ve también por qué se hizo ese cambio, qué problema resuelve y qué criterios guiaron la implementación.

El contexto viaja junto al código, y eso mejora radicalmente tanto la calidad del review como el onboarding de nuevos perfiles en el proyecto.

¿Funciona de verdad en sistemas complejos?

La pregunta crítica es si todo esto resiste cuando el entorno deja de ser controlado y aparece la complejidad real: monolitos heredados, migraciones cloud, plataformas híbridas, integraciones con Kubernetes, Terraform o Apache Kafka. Y precisamente ahí es donde más sentido cobra.

En un sistema heredado de cientos de clases, el contexto manual simplemente deja de ser viable. No cabe en la ventana del modelo ni es razonable esperar que un/a desarrollador/a decida manualmente qué partes son relevantes en cada momento.

Una de las aplicaciones más interesantes de este enfoque es la modernización de software legacy. La IA puede analizar módulos antiguos y generar especificaciones formales de comportamiento. No captura todo desde el primer momento, pero sí una parte muy significativa que luego puede refinarse iterativamente.

Esas especificaciones pasan a ser el puente entre el sistema heredado y la nueva arquitectura. Lo importante es que el conocimiento extraído persiste. Un prompt desaparece, una especificación permanece.

El “100% automático” sigue sin ser realista

A pesar del avance, el objetivo NO es que la IA entregue software listo para producción sin intervención humana. Actualmente, incluso en los mejores escenarios, el resultado suele situarse en torno al 80% o 90% del trabajo útil. El resto sigue requiriendo criterio técnico, validación y comprensión profunda del sistema.

Existe además un riesgo menos visible: el knowledge lag. Si todo lo hace la IA y el/la desarrollador/a deja de recorrer mentalmente el código, termina perdiendo conocimiento real sobre el sistema que mantiene.

Ese último tramo que todavía exige intervención humana no es una limitación accidental: es también una garantía de control.

Lo que probablemente veremos en los próximos años

El debate ahora no es si habrá agentes autónomos o no, sino dónde encajan mejor. En tareas repetitivas, scaffolding masivo o migraciones mecánicas, la orquestación pura de agentes tiene mucho sentido.

Pero cuando entra en juego lógica de negocio compleja, auditoría, cumplimiento normativo o arquitectura crítica, el enfoque cambia. Porque en una gran empresa no basta con que el código funcione, también debe poder explicarse, trazarse, revisarse y sostenerse en el tiempo.

Y ahí es donde modelos basados en especificaciones, conocimiento corporativo y control arquitectónico parecen estar marcando ya el camino de 2026.