En 1962, Bennet Murdock publicó un experimento que cambió la psicología cognitiva.

Pidió a sus sujetos memorizar listas de cuarenta palabras y, después, recitarlas en cualquier orden. Recordaban las primeras (efecto de primacía). Recordaban las últimas (efecto de recencia). El medio se evaporaba.

Sesenta y cuatro años después, los LLMs hacen exactamente lo mismo. Solo que, en lugar de palabras, lo que se evapora son los tokens por los que estás pagando.

La curva es idéntica. La explicación no.

Cuando empecé a usar Claude y ChatGPT a diario, asumí que los olvidos eran un capricho del modelo o algo relacionado con su naturaleza no determinista. Le pasaba un contexto largo, le hacía una pregunta concreta sobre algo del medio, y a veces respondía bien y a veces no. Una lotería. Tardé en cogerlo. Lo cogí cuando dejé de leer papers y empecé a visualizar la atención capa por capa en un transformer pequeño. Ver el mapa cambia las cosas. El código, los demos y la reproducción con GPT-2 están [aquí](https://github.com/josemerca/gemba-attention-from-scratch).

Hoy te cuento por qué los LLMs olvidan, cuánto te está costando ese olvido, y qué puedes hacer para minimizarlo. Si trabajas con IA, esto es ergonomía básica del producto.

La memoria no es lo que parece

Cuando hablas con Claude o con ChatGPT, tienes la sensación cómoda y engañosa de estar conversando con algo que recuerda. Le dices una cosa, le dices otra, le pides que vuelva a la primera. La mayoría de las veces parece funcionar. Y eso es justo el problema.

Lo que llamamos “memoria” en un LLM no se parece en nada a la memoria humana. No hay un sitio donde el modelo “guarda” lo que le has dicho. No aprende mientras hablas con él. Sus pesos están congelados desde el día en que terminó de entrenarse, y no cambian ni un decimal durante toda la conversación. Lo que sí existe es una ventana de contexto: una secuencia finita de tokens que el modelo tiene delante cada vez que genera una respuesta. Y cuando llega tu siguiente mensaje, la ventana se reescribe entera con todo lo anterior más lo nuevo, y el modelo vuelve a procesarla desde cero.

Lo que llamamos memoria es, técnicamente, releer.

Cada conversación con Claude Opus 4.7 cabe en hasta un millón de tokens. GPT-4o trabaja en 128.000. Gemini 1.5 Pro estira hasta dos millones. Parecen cifras enormes, y lo son comparadas con los 2.048 tokens del GPT-3 original o los 4.096 con los que se lanzó ChatGPT, pero siguen siendo finitas. Cuando una conversación pasa de ese tope, los tokens más antiguos se descartan literalmente: el modelo deja de “verlos”. No los olvida en sentido figurado; desaparecen del input.

Dentro de la ventana, los tokens viven en una estructura de la que rara vez somos conscientes: el KV cache —caché de claves y valores, keys y values en inglés, las dos siglas detrás de las dos letras—. Es un buffer físico en memoria de GPU donde se almacenan, por cada token y por cada capa del modelo, esas dos matrices: una de claves y otra de valores. Piensa en la clave como la etiqueta del token —algo así como “yo soy un trozo de texto que habla de esto”— y en el valor como el contenido que ese token aporta cuando otro token decide mirarlo. Para Llama 3 70B con 100.000 tokens de contexto en precisión BF16 (dos bytes por número), el KV cache ocupa unos 30 GB de VRAM —la memoria interna de la GPU—, casi la mitad de una GPU H100 dedicada solo a recordar lo que ya le has dicho. Y eso gracias a Grouped-Query Attention (GQA), una técnica que comparte claves y valores entre varios cabezales de atención para abaratar el coste; sin GQA esos mismos 100k tokens ocuparían más de 150 GB. Es por eso que GQA es estándar de facto en casi todos los modelos abiertos modernos: Llama 3, Mistral, Qwen 2.5, Gemma. No es una metáfora ni una abstracción: es hardware. Cuando los proveedores te cobran por “input tokens”, parte de lo que estás pagando es ese hardware encendido durante el tiempo que tu contexto está cargado.

Y aun así, el KV cache no resuelve el problema. Resuelve el “cómo se almacena el contexto”, pero no el “cómo se mira”. Esa segunda parte —la atención— es donde nace el olvido. Y es donde se origina la factura que pagamos sin darnos cuenta.

El cuello de botella cuadrático

La operación matemática que define a un transformer no es la multiplicación de matrices grande ni el softmax exótico. Es una sola fórmula que mide cuánto le importa cada token a cada otro token:

Atención(Q, K, V) = softmax(Q · K^T / √d) · V

Donde Q, K y V son las matrices de queries, keys y values que mencionamos en §1. Lo importante no es la fórmula. Lo importante es lo que hace por debajo: para cada token de la secuencia, compara su query con la key de todos los demás tokens y calcula un peso. Luego, usando esos pesos, mezcla los values de todos los demás tokens en una nueva representación.

Cada token mira a cada otro token. Cada uno. Sin excepciones.

Si tienes n tokens, eso son n × n comparaciones por capa, por cabezal de atención y por paso de generación. Y en un Llama 3.1 405B (126 capas × 128 cabezales), esa cifra se multiplica por unas dieciséis mil veces antes incluso de empezar a generar el siguiente token. Esa propiedad —que el coste crece con el cuadrado del contexto— se escribe en la jerga como O(n²), y es lo que en este artículo llamaré el cuello de botella cuadrático.

Veámoslo con una tabla. Lo que cuesta procesar un contexto de tamaño n, comparado con uno de mil tokens:

Si nunca habías visto los números así, deja que asienten un segundo: una conversación con Claude Opus 4.7 que llena la mitad de su ventana —medio millón de tokens— hace doscientas cincuenta mil veces más trabajo de atención que una conversación de mil tokens. No quinientas veces. Doscientas cincuenta mil. Y si llenas la ventana entera hasta el millón, un millón de veces más. Un billón europeo de comparaciones por capa de transformer.

Doblar el contexto no cuesta el doble. Cuesta cuatro veces más.

Aquí es donde aparece la consecuencia incómoda. Ese coste cuadrático tiene que pagarlo alguien. Los proveedores no lo pueden absorber indefinidamente, así que aparece en tres sitios distintos: en el precio por millón de tokens de input (que va subiendo con el tamaño de la ventana), en la latencia (modelos como Claude tardan más en arrancar cuando el contexto es muy largo), y —el más sutil de los tres— en cómo el modelo distribuye su atención dentro de la ventana.

Porque cuando una operación cuesta n², la forma más natural de abaratarla es no mirar a todos los tokens por igual. Y eso, aplicado mil veces durante el entrenamiento, deja una huella permanente en el modelo: aprende a atender preferentemente a unos sitios y a ignorar otros. La forma exacta de esa huella es lo que descubrió Liu en 2024. Y se parece sospechosamente a lo que descubrió Murdock en 1962.

Lost in the middle

En julio de 2023, Nelson Liu y un equipo de Stanford colgaron en arXiv un paper con un título poco humilde: Lost in the Middle: How Language Models Use Long Contexts. La versión revisada apareció en 2024 en TACL, una de las revistas de referencia del procesamiento del lenguaje natural. Es uno de esos papers que confirman, con números, una sospecha que todo el mundo en el sector tenía pero nadie había medido bien.

El experimento es elegante por lo simple. Cogieron diez modelos —GPT-3.5-Turbo en sus dos versiones, GPT-4 en un subconjunto, Claude-1.3 y Claude-1.3-100k, MPT-30B base e Instruct, LongChat-13B-16K, Flan-T5-XXL y Flan-UL2— y les pasaron contextos largos con una técnica que en la jerga se llama needle in a haystack —literalmente, “una aguja en un pajar”—: meter dentro de un texto enorme una “aguja” —un dato único, una clave, una respuesta a una pregunta concreta— y luego preguntar por esa aguja. El truco está en variar la posición. La aguja puede estar a la entrada del pajar, a un cuarto, en el centro, a tres cuartos o al fondo. Y medir cuántas veces el modelo la encuentra.

Lo que descubrieron es la curva en U. Los modelos —todos— recuperan mejor lo que está al principio o al final del contexto y peor lo que está en el medio. La caída entre la mejor posición y la peor es de quince a veinticinco puntos porcentuales. Para GPT-3.5-Turbo en su versión 16K, supera los veinte. No es ruido. Es un patrón sistemático, replicable, y aparece en arquitecturas, tamaños y proveedores distintos.

Pongamos a Murdock y a Liu en la misma tabla, separados por sesenta y cuatro años:

No es una coincidencia poética. Es una propiedad estructural de los sistemas con atención limitada, biológicos o de silicio. Cuando una operación cuesta n², el sistema aprende a no mirarlo todo. Y la heurística que emerge, casualmente, prioriza los extremos. Sea porque al principio del contexto suele ir lo importante (el system prompt, la pregunta original), sea porque al final está lo más reciente (el último turno del usuario, el detalle preciso), los modelos se vuelven especialistas en los bordes y amateurs en el centro.

La consecuencia práctica es brutal y sorprende a casi todos los equipos que la oyen por primera vez. Si metes un PDF de cien páginas a Claude y le preguntas algo de la página cincuenta, las probabilidades de que conteste bien caen entre 15 y 25 puntos porcentuales respecto a la misma pregunta sobre la página cinco o la noventa y cinco — esos son los órdenes de magnitud que midió Liu en los diez modelos de su experimento. No porque el modelo sea perezoso. No porque haya un bug. Porque ese token, sencillamente, está en el peor sitio posible.

Y hay algo aún más inquietante. Hsieh y un equipo de NVIDIA (RULER, presentado en 2024 en COLM —la Conference on Language Modeling, una de las nuevas conferencias específicas de modelos de lenguaje) extendieron el experimento de Liu con un benchmark más completo y midieron lo que llaman context efectivo: el tamaño real al que el modelo funciona bien, no el que aparece en la ficha técnica. El resultado es brutal: la mayoría de los modelos —comerciales y abiertos— tienen un context efectivo entre dos y ocho veces menor que la ventana que anuncian. Un modelo que vende 128k puede degradarse a partir de los 16k-32k. La ventana es marketing; el context efectivo es lo que importa.

Y la pregunta inmediata, claro, es: ¿se puede arreglar?

Cuatro mecanismos esquivan el problema. Y un quinto lo elimina

Spoiler de los cuatro primeros: ninguno lo elimina. Lo esquivan, cada uno con un compromiso distinto. Y lo esquivan con cuatro mecanismos conceptualmente independientes: truncar la atención (mirar solo a una ventana móvil), anclar ciertos tokens para que nunca se pierdan dentro de la ventana, externalizar el conocimiento preindexado fuera de la ventana, y navegar el entorno bajo demanda en lugar de cargarlo.

El quinto es más radical: salir del transformer entero. Cambiar la arquitectura por otra que no tenga atención cuadrática. Es lo que prometen los SSMs y los modelos híbridos, y ya hay opciones comerciales en producción.

Entender los cinco es lo que separa a un equipo que diseña con LLMs en serio de uno que reza para que la próxima versión sea mágica.

Sliding Window Attention — truncar la atención

La idea más obvia: si mirar a todos los tokens cuesta demasiado, trunca la atención. Que cada token solo mire a los W tokens más recientes. El coste cae de O(n²) a O(n·W), que es lineal con n. Lo que se pierde son las dependencias a larga distancia.

Esta es la familia de Longformer (Beltagy, Peters y Cohan, 2020), una de las primeras propuestas serias del problema, y la que adoptó Mistral 7B (Jiang et al. 2023) como pieza central de su arquitectura. Mistral usa una ventana W de 4.096 tokens en cada capa. Como los transformers tienen muchas capas apiladas, lo que un token “ve” en capas profundas es más ancho que su ventana literal —porque cada capa intermedia ya ha mezclado información de un tramo distinto—. En la práctica, encadenando capas, el modelo accede a un contexto efectivo de hasta 131.072 tokens sin pagar el cuadrático.

El precio es claro: si lo importante para responder está más allá de la ventana acumulada, el modelo no lo verá. Bien para hojear un documento largo de un tirón. Mal para una conversación donde lo que importa se dijo hace mil turnos.

Attention Sinks — anclar tokens críticos

La segunda familia introduce un mecanismo distinto: anclar ciertos tokens para que nunca se pierdan, independientemente de cuánto crezca la conversación. Surgió como respuesta a un problema raro y persistente que sufría la sliding window pura: cuando los primeros tokens de la secuencia llegaban al borde de la ventana y desaparecían, los modelos empezaban a colapsar. Salidas incoherentes, perplejidad disparada. En 2023, Guangxuan Xiao y un equipo del MIT (con Yuandong Tian, Beidi Chen, Song Han y Mike Lewis) descubrieron por qué.

Los primeros tokens de la secuencia, da igual cuáles sean, acumulan una cantidad enorme de atención durante el entrenamiento. No porque su contenido sea más valioso —pueden ser tokens basura, espacios o —, sino porque la softmax obliga a que los pesos sumen uno y, cuando un token no encuentra a quién atender bien, “deposita” peso en cualquier sitio. Y los primeros tokens, por construcción, siempre están ahí. Se vuelven attention sinks: sumideros de atención.

Su propuesta —que llamaron StreamingLLM— es preservar los primeros K tokens del contexto siempre, además de la sliding window normal. Esos K son las anclas; la ventana es el corto plazo. Con esa combinación, mostraron que un modelo puede generar de forma estable hasta cuatro millones de tokens sin fine-tuning. Sin colapsar.

La evolución natural de esta idea llegó en 2025 con Native Sparse Attention (DeepSeek, Best Paper de ACL 2025 —la conferencia más importante del campo): en lugar de aplicar el ancla como parche post-hoc sobre un modelo ya entrenado, se entrena al modelo desde el principio con un patrón de atención dispersa que aprende qué tokens funcionan como anclas y cuáles no. DeepSeek V3.2 ya lo usa en producción. Pasamos de la atención dispersa como remiendo a la atención dispersa nativa.

El precio: hay que modificar el caching del modelo o, en el caso de Native Sparse Attention, entrenarlo desde cero con esa estructura. No es algo que se aplique transparentemente a cualquier checkpoint público que ya tengas.

RAG con embeddings — externalizar el conocimiento preindexado

La tercera familia es la que probablemente ya estás usando sin saberlo, y es estructuralmente distinta de las dos anteriores: en lugar de tocar el mecanismo de atención, externaliza el conocimiento. La ventana del modelo se mantiene pequeña; el grueso del corpus vive fuera, en una base de datos vectorial aparte, y solo se trae a la ventana lo que parece relevante para la pregunta actual. Eso es RAG (Retrieval-Augmented Generation).

Cursor es el ejemplo más visible en el ecosistema de desarrollo: indexa el repositorio con embeddings, los almacena en una base vectorial, y en cada consulta usa búsqueda por proximidad para traer los trozos relevantes. Es también la base de cualquier agente conversacional serio que tenga que trabajar sobre una base de conocimiento más grande que la ventana del modelo.

El precio: dependes del retriever. Si el retriever falla en encontrar el trozo relevante, el modelo no tiene la información y se la inventa con la confianza de quien sí la tiene. La calidad del producto se vuelve, en buena medida, la calidad del recuperador.

Agentic search — navegar el entorno bajo demanda

La cuarta familia es la más reciente y la más radical: no preindexar nada. En lugar de calcular embeddings de todo el conocimiento por anticipado, el modelo navega el entorno bajo demanda usando las mismas herramientas que un programador en una terminal: grep —el comando de Unix de toda la vida para buscar texto dentro de los ficheros—, lectura de ficheros concretos, listar directorios, seguir referencias entre archivos.

Es la estrategia de Claude Code cuando te ayuda a editar un repositorio grande. Anthropic la defiende explícitamente frente a RAG con embeddings: “Claude Code navega un repositorio como lo haría un ingeniero: recorre el sistema de ficheros, lee ficheros, usa grep para encontrar exactamente lo que necesita, y sigue referencias”. El argumento es práctico: los pipelines de embeddings no aguantan el ritmo de equipos activos y devuelven referencias obsoletas. Mejor que el modelo decida en cada turno qué leer, como haría un humano.

El precio: latencia añadida en cada turno (cada grep o lectura es un viaje a la ventana del modelo), y dependencia de que el modelo razone bien sobre dónde buscar. A cambio, gana frescura (no hay índice que se quede obsoleto) y precisión local (el modelo lee el código real, no un trozo embebido hace tres semanas).

Salir de la jaula — arquitecturas no-transformer

Hasta aquí, todo dentro del transformer. Pero hay un quinto camino, conceptualmente distinto de los cuatro anteriores: cambiar la arquitectura. Si el problema es la atención cuadrática, ¿por qué no usar un modelo que no la tenga?

La candidata más madura en 2026 son los SSMs (State Space Models, o modelos de espacio de estados). Mamba (Gu y Dao, 2023) y su sucesor Mamba-2 (2024) procesan secuencias en tiempo lineal con n, sin atención cuadrática. La memoria del modelo se mantiene en un estado oculto que se actualiza recurrentemente, como una red neuronal recurrente (RNN) moderna, pero con una calidad de aprendizaje que se acerca a la del transformer.

¿Funciona en producción? Sí, hay ya modelos comerciales que apuestan por esta vía. Jamba 1.5 (AI21 Labs, 2024) combina capas Transformer, capas Mamba y MoE (Mixture of Experts, una técnica que activa solo una fracción de los parámetros del modelo en cada paso para abaratar el cómputo). Tiene ventana de 256k tokens y un throughput (tokens generados por segundo) tres veces mayor que Mixtral. Mistral Codestral Mamba, Google RecurrentGemma e IBM Granite 4.0 son apuestas comerciales del mismo enfoque.

El precio: la atención cuadrática, aunque cara, captura dependencias largas con precisión casi quirúrgica. Los SSMs comprimen esas dependencias en su estado oculto, y todavía no igualan al transformer puro en algunas tareas de retrieval exacto. Por eso los híbridos llevan ventaja por ahora: combinan transformers (precisión) con SSMs (escala) y se quedan con lo mejor de los dos mundos.

La dirección está clara: el O(n²) ha dejado de ser la única opción.

Compactación — la pieza ortogonal

La compactación (compaction en las docs de Anthropic) no es una quinta familia: es una pieza que combina con cualquiera de las cuatro. Cuando el historial de conversación empieza a llenar la ventana, le pides al modelo que resuma los turnos antiguos y sustituyes el detalle por el resumen. Pierdes precisión sobre lo viejo, ganas espacio para lo nuevo.

Anthropic ha hecho la compactación explícita en Claude Code: existe un comando /compact manual y un auto-compact que se dispara cuando el contexto se acerca al 95% del límite. Es una decisión deliberada: mejor que tú o el sistema decidan qué se comprime, en lugar de dejar que el lost-in-the-middle haga la criba por sus propios mecanismos.

Los cinco, vistos juntos

Los cuatro primeros esquivan el problema. El quinto lo elimina cambiando de arquitectura. Y la compactación es una pieza ortogonal que combina con cualquiera de ellos. La pregunta correcta para diseñar un producto con LLM no es “qué solución uso”, sino “qué combinación me conviene en cada parte de mi sistema”. Y para responder eso, conviene saber cuánto te está costando el olvido cuando no haces nada.

La factura del olvido

En el artículo anterior de Gemba expliqué que el coste de los tokens es multiplicador, no sumatorio: si tu modelo es caro y su tokenizer es malo para tu idioma, no pagas el sobrecoste una vez, lo pagas dos. Con el olvido pasa lo mismo, pero peor, porque la factura llega en tres formatos distintos y casi nadie la suma entera.

Primer formato: latencia. Generar el primer token de la respuesta requiere procesar todo el contexto. Si tu contexto crece linealmente, el tiempo hasta el primer token —Time To First Token, TTFT en la jerga— crece de forma más que lineal. Los proveedores aplican optimizaciones agresivas, pero las leyes de la física no se negocian: Claude Sonnet 4 con mil tokens de input tarda alrededor de un segundo en empezar a responder; con cien mil, entre dos y cinco (mediciones de Artificial Analysis). El crecimiento no es lineal, y la curva se empina a medida que te acercas al techo de la ventana. Multiplica eso por el número de turnos de un agente que reflexiona en bucle, y la latencia agregada empieza a ser dinero.

Segundo formato: repetición. Esta es la más invisible y la más cara. Cuando el modelo no recupera bien algo del medio de la ventana, el usuario lo nota y lo vuelve a meter. Le copia el bloque otra vez. Le repite la instrucción. Le recuerda el dato. Cada repetición son tokens duplicados que vuelves a pagar y que, encima, aumentan el tamaño del contexto y empeoran el problema en el siguiente turno. Es una espiral. Si llevas la cuenta de cuántas veces le has repetido la misma cosa a un LLM en una conversación de tarde, la respuesta es un número incómodo.

Tercer formato: alucinación. El más sutil y el más peligroso en producción. Cuando el modelo no encuentra información en su atención efectiva, no dice “no lo sé”. Rellena. Inventa con la prosodia de quien sabe. Y como el dato que necesitaba estaba en el contexto —solo que en el medio, donde la atención no lo procesa bien— el operador humano confía en que el modelo lo ha leído. La factura aquí ya no es de tokens. Es de decisiones tomadas con información incorrecta.

Pongámoslo en una tabla, que se ve mejor:

La parte cínica es que los tres costes se realimentan. Repites más → contexto más largo → latencia más alta + más medio donde olvidar → más alucinación → más repetición. No es una resta. Es un multiplicador, igual que con los tokens.

Y como pasa con los tokens, esta factura no aparece en una línea aparte de la factura de Anthropic o de OpenAI. Aparece como tiempo de tu equipo dándole vueltas a por qué Claude “se olvidó”, como horas de soporte explicando al cliente que sí, que la respuesta era inventada, y como una vaga sensación de que la IA “no termina de hacer lo que debería”. Eso es la factura del olvido. La pagas todos los meses, y casi nunca la mides.

¿Y se puede medir? Sí. Y es más fácil de lo que parece, una vez sabes mirar.

Lo que puedes hacer mañana por la mañana

Hasta aquí hemos visto la mecánica. La parte práctica es más corta porque, una vez entiendes que el olvido es estructural y no un capricho, las decisiones de diseño se ordenan solas. Estas son las seis que mejor amortizan el esfuerzo:

1) Pon lo crítico al principio y al final, nunca en el medio. Las instrucciones de sistema, los criterios de calidad, las restricciones inviolables, el formato de salida que esperas: todo eso va en zona de primacía. La pregunta concreta, los últimos datos, el matiz que el modelo no debe perder: zona de recencia. Lo que termine en el medio es lo que pondrás en riesgo. Diseña como diseñarías una landing: arriba lo importante, abajo el CTA, y haz que el medio sea pasaje, no producto.

2) No metas un PDF de cien páginas y reces. Si el contenido supera la mitad de la ventana, parte y recupera. Indexa el documento por secciones, monta un buscador sencillo —un retriever, en la jerga— y deja que el LLM solo vea los tres o cuatro trozos relevantes para la pregunta. La precisión sube y la factura baja a la vez. RAG funciona aunque sea con embeddings básicos —no hace falta exotismo para mejorar.

3) Repite las reglas críticas al principio Y al final. Si tu system prompt dice “responde solo en español y nunca inventes datos”, y la conversación es larga, el modelo verá la regla solo en zona de primacía. En conversaciones que pasen de varios miles de tokens, conviene reinyectar las restricciones críticas en el último turno antes de la respuesta. Es feo y funciona.

4) Compacta antes de que la ventana te compacte. No esperes a que el sistema decida qué tirar. Cada N turnos, pídele al modelo un resumen estructurado de la conversación hasta ese punto y sustituye los turnos antiguos por ese resumen. Pierdes detalle, ganas precisión sobre lo que queda. Mejor decidir tú qué se pierde a que lo decida una heurística que no controlas.

5) Subagentes para descargar contexto. Cuando una tarea requiere mucha investigación o exploración previa, hazla en un subagente con su propia ventana. El agente principal recibe solo el resultado final, no los miles de tokens intermedios. Es lo que hace Claude Code para no contaminar tu sesión con cada exploración del repo. La diferencia, en conversaciones largas, es brutal.

6) Mide tu propia curva en U. Los datos del paper de Liu son una referencia sólida, pero tu caso de uso — tu modelo, tu idioma, tu tipo de pregunta, tu tamaño de contexto — puede tener una curva distinta. No asumas. Mide. Bastan tres tamaños de contexto y cinco posiciones por cada uno para tener un mapa razonable de dónde está tu zona segura. A partir de ahí, diseñas con datos.

Diseñar para LLMs es, en buena medida, diseñar para sistemas con sesgo de primacía y recencia. Como diseñar páginas web para humanos. Lo curioso es que llevamos décadas haciendo esto último por buenas razones cognitivas, y ahora descubrimos que las mismas razones cognitivas, en silicio, exigen lo mismo. Murdock se hubiera reído.

Dos toolkits abiertos

Como hice con el artículo de tokens, he liberado dos repos en abierto (MIT) para que puedas experimentar y decidir, no solo leerme.

▪ Uno para entender — gemba-attention-from-scratch. Los tres mecanismos de atención —la versión vanilla del transformer, la sliding window de Mistral y Longformer, y los attention sinks de StreamingLLM— implementados desde cero en Python sin librerías externas. Y una demo viva que reproduce la curva en U usando GPT-2 small: mete una aguja en distintas posiciones de un texto largo y mide cuánto la recuerda el modelo. Para entender qué pasa por dentro.

▪ Otro para decidir — gemba-context-needle-runner. Una herramienta que mide el lost-in-the-middle en tu propio uso. Lanza el experimento de la aguja en el pajar contra OpenAI, Anthropic y modelos abiertos, varía el tamaño del contexto y la posición de la aguja, y te devuelve la curva de aciertos por posición. Para que dejes de adivinar dónde colapsa tu modelo y empieces a medirlo.

Uno para entender el mecanismo. El otro para saber cuánto te afecta a ti.

Sesenta y cuatro años después del experimento de Murdock, encontramos su curva en U dentro de unas máquinas hechas de matrices. Él la midió en sujetos humanos memorizando palabras. Nosotros la medimos en GPUs procesando tokens. Los mecanismos no tienen nada que ver. La forma sí. Y la consecuencia práctica también: lo que importa, va al principio o al final. El medio es zona muerta.

Los LLMs no olvidan. Pagan la factura cuadrática de la atención. Y mientras esa factura siga siendo n², el olvido no es un bug que vayan a arreglar en la próxima versión. Es una propiedad estructural, y diseñar productos con LLMs es, antes que cualquier otra cosa, diseñar alrededor de ese sesgo.

La pregunta práctica que te lleva todo esto: ¿en qué punto de tu contexto colocas lo crítico?

¿Habéis medido en tu equipo qué porcentaje del contexto que pasáis a Claude o ChatGPT influye realmente en la respuesta? Porque hasta que no lo midas, estás pagando una factura cuya magnitud no conoces.

Cada llamada a un LLM se cobra en tokens. Tu plan de Claude tiene un límite de tokens. La ventana de contexto se mide en tokens. Las empresas comparan modelos por su precio por millón de tokens. Y a pesar de eso, si paro a diez profesionales del sector y les pido la definición exacta de un token, nueve me dan algo aproximado y uno me dice que “más o menos es una palabra”.

Pues Chorprecha!! No es una palabra!!.

Hace unos meses me obligué a entenderlo de verdad. No leyendo artículos: implementando el algoritmo desde cero en Python, byte a byte, sin librerías. El código está al final del artículo por si te apetece mirarlo después.

Hoy te cuento qué es un token, cómo se inventan, por qué un emoji cuesta cinco veces más que la palabra “el”, y qué decisiones de producto cambian cuando entiendes la unidad en la que pagas. Si trabajas con IA, esto es contabilidad básica de tu negocio.

Un token no es una palabra

La aproximación que más oirás —”un token es más o menos una palabra”— es útil para hacer una estimación rápida en una pizarra y desastrosa para casi todo lo demás. Veámoslo con tres palabras.

“Hola” es un token. Una palabra, un token. El mito sobrevive.

“Mercadona”, en cambio, se parte en tres trozos cuando la procesa el tokenizador de GPT-4: algo parecido a Merc, ad, ona. Tres tokens para una sola palabra. El mito empieza a romperse.

“Supermercado” se parte en dos: super y mercado. Dos tokens, dos sub-palabras que sí aparecen mucho en el corpus de entrenamiento y que el algoritmo ha decidido guardar como piezas reutilizables.

Y un emoji como 🛒 puede convertirse en cuatro o cinco tokens él solo, porque ni siquiera cabe en un byte: hay que codificarlo en UTF-8 y luego volver a juntarlo.

¿Por qué tanta variación? Porque un token no es una unidad lingüística. Es una unidad estadística. El tokenizador no sabe español, no sabe inglés y no sabe que “Mercadona” es una empresa: lo que sabe es que ciertos pedazos de texto aparecen mucho juntos en su corpus de entrenamiento, y los guarda como piezas. Lo que aparece menos, lo deja sin agrupar.

La regla útil para hacer cuentas rápidas, si trabajas con tokenizadores entrenados sobre todo en inglés (la mayoría de los grandes), es algo así:

• Inglés: 1 token ≈ 0,75 palabras

• Español: 1 token ≈ 0,5 palabras

• Código fuente: 1 token ≈ 3-4 caracteres

Si solo te llevas una cosa de esta sección: cuando escribes en español, estás pagando casi el doble que un anglosajón por decir lo mismo. Y eso no es un accidente. Es una consecuencia directa de cómo se entrena el tokenizador, que es de lo que va la siguiente sección.

BPE: el dominante de la era GPT

El algoritmo más usado se llama BPE (Byte Pair Encoding). Es engañosamente simple y resuelve un problema concreto: cómo cubrir todo el texto del mundo —cualquier idioma, emojis, código, errores de teclado— con un vocabulario fijo y eficiente.

No puedes hacer un diccionario “a mano”. Tampoco puedes usar bytes sueltos (H, o, l, a son cuatro tokens para una sola palabra: ineficiente). BPE encuentra el punto medio: un vocabulario aprendido a partir de los datos.

Funciona en tres pasos. La versión esencial:

Paso 1 — Empezar por lo más básico. El vocabulario inicial son los 256 bytes posibles. Cualquier texto del universo se puede expresar como una secuencia de estos 256 elementos. Eso garantiza que nada queda fuera, ni los emojis ni los caracteres japoneses ni nada.

Paso 2 — Contar pares por frecuencia. Aquí “frecuencia” significa algo muy concreto: cuántas veces aparece cada par de tokens adyacentes en los documentos que forman el corpus de entrenamiento. Y ese corpus no es pequeño: hablamos de cientos de miles de libros, páginas web, repositorios de código, foros, conversaciones y artículos —en GPT-4 son varios billones de tokens en total—. El algoritmo recorre ese mar de texto y, para cada par adyacente posible, lleva un contador. Esa cuenta —y nada más— es lo que decide qué tokens nacen y cuáles no. No hay análisis sintáctico, no hay reglas, no hay diccionarios. Solo recuento de coapariciones.

Paso 3 — Fusionar el ganador y repetir. Coges el par más frecuente, lo declaras un nuevo token, le asignas un identificador nuevo (256, 257, etc.) y recorres todo el corpus reemplazándolo. Vuelves a contar pares —ahora los nuevos tokens también participan— y repites. Cada vuelta, el vocabulario crece en uno.

Un ejemplo con la cuenta de la vieja

Para ver qué significa exactamente esa “frecuencia”, reduzcamos el corpus a algo que se pueda contar a mano. Imagina que tu corpus de entrenamiento es minúsculo: solo cuatro palabras, cada una repetida un número conocido de veces en los documentos.

Empezamos descomponiendo cada palabra en sus letras y contamos cuántas veces aparece cada par adyacente en todo el corpus, multiplicando por la frecuencia de su palabra:

El par más frecuente es e + r con 11 apariciones. Lo fusionamos: nace un nuevo token, er, y todo el corpus se reescribe con él:

• lower ahora es l, o, w, er

• newer ahora es n, e, w, er

• wider ahora es w, i, d, er

Volvemos a contar. Esta vez ganará w + er, que aparece en lower y newer un total de 8 veces, y nacerá el token wer. Y así sucesivamente. Cada iteración añade un token al vocabulario y comprime un poco más la representación del corpus.

Si dejas correr el algoritmo 50.000 veces, tienes un vocabulario de 50.000 tokens. La mayoría serán sub-palabras frecuentes (ción, mente, super, inter), algunas serán palabras enteras muy comunes (de, que, the), y otras serán piezas raras que el algoritmo decidió guardar porque aparecían lo bastante.

Lo interesante: no hay reglas lingüísticas en ningún sitio. El algoritmo no sabe que ción es un sufijo ni que super es un prefijo. Lo descubre solo porque aparece mucho en los datos. Es el equivalente, en mi mundo de Information Retrieval clásico, a descubrir bigramas frecuentes en un corpus —”New York”, “machine learning”— sin que nadie te diga que son entidades.

Quién usa BPE hoy. GPT-4 y GPT-4o (con tiktoken), Claude (variante propia de BPE), Mistral, Qwen, Llama 3 y prácticamente todos los modelos generativos de uso masivo en producción. Si trabajas con un LLM comercial moderno, casi seguro estás pagando en tokens BPE.

Unigram + Viterbi: el algoritmo que trabaja al revés

Si BPE construye el vocabulario de abajo arriba —empezando con bytes sueltos y fusionándolos—, Unigram hace lo contrario: empieza con un vocabulario gigante de candidatos y va podando los menos útiles hasta dejar solo los que de verdad valen la pena.

Lo curioso es que aquí “frecuencia” deja de ser un simple recuento. En Unigram, cada candidato a sub-palabra tiene asociada una probabilidad estimada a partir del corpus: la probabilidad de que esa sub-palabra aparezca en un documento elegido al azar. Y la probabilidad de una palabra entera —por ejemplo, lowest— se calcula multiplicando las probabilidades de los trozos en los que se segmenta.

El algoritmo funciona así, simplificado en cuatro pasos:

Paso 1 — Construir un vocabulario inicial enorme. Se extraen del corpus todas las sub-palabras candidatas hasta cierta longitud: las que aparecen al menos N veces se incluyen. Es habitual empezar con un vocabulario diez veces más grande del que queremos al final.

Paso 2 — Estimar la probabilidad de cada candidato. Con un algoritmo iterativo llamado EM (Expectation-Maximization), ajustas las probabilidades de todas las sub-palabras del vocabulario de forma que el corpus completo se explique con la máxima verosimilitud posible.

Paso 3 — Encontrar la mejor segmentación con Viterbi. Dada una palabra y un vocabulario con probabilidades, ¿cuál es la mejor forma de partirla? Aquí entra el algoritmo de Viterbi, un método de programación dinámica que encuentra el camino óptimo entre todas las segmentaciones posibles sin tener que probarlas una por una. Por cierto: es el mismo algoritmo que se usaba en los años ochenta y noventa para etiquetar gramaticalmente las palabras de una frase —POS tagging, de Part-of-Speech: marcar cada palabra como sustantivo, verbo, adjetivo, etc.— combinado con HMM (Hidden Markov Models, modelos probabilísticos de secuencias en los que los estados que generan las observaciones permanecen ocultos). Era el estado del arte del procesamiento del lenguaje natural antes de los transformers.

Paso 4 — Podar y repetir. Los candidatos cuya eliminación apenas afecta a la verosimilitud del corpus se descartan. Se vuelven a estimar las probabilidades, se vuelve a podar, y así hasta llegar al tamaño deseado de vocabulario.

Un ejemplo con la cuenta de la vieja

Imagina que hemos entrenado un Unigram y la palabra lowest puede segmentarse de varias formas. Cada candidato tiene una probabilidad estimada a partir del corpus:

Viterbi recorre estas opciones eficientemente y se queda con la de mayor probabilidad: low + est. Esa es la segmentación que el modelo “verá”.

Mientras BPE fusiona por frecuencia bruta, Unigram elige por verosimilitud. Eso le permite manejar mejor casos ambiguos y, sobre todo, idiomas con morfología compleja —japonés, coreano, finés— donde la segmentación no es obvia.

Una nota histórica que conviene recordar. Tendemos a pensar que todo lo que rodea a los LLMs es tecnología muy reciente, pero la mayoría de los ladrillos que sostienen esto llevan décadas inventados. El algoritmo de Viterbi lo publicó Andrew Viterbi en 1967 para decodificar señales de telecomunicaciones; lo trasladó al procesamiento de lenguaje natural toda una generación de investigadores en los años setenta y ochenta. Los HMM se formalizaron como modelo probabilístico a finales de los sesenta y dominaron el reconocimiento de voz y el etiquetado gramatical durante treinta años. El algoritmo EM —el que ajusta las probabilidades del vocabulario en Unigram— lo publicaron Dempster, Laird y Rubin en 1977 en uno de los papers más citados de la historia de la estadística. Incluso BPE como técnica de compresión es de 1994 (Phillip Gage), y solo se reutilizó para NLP en 2016 (Sennrich, Haddow y Birch). Cuando alguien te diga que la IA generativa es “magia nueva”, recuerda que detrás de cada token que pagas hay matemáticas con cincuenta años de historia.

Quién usa Unigram + Viterbi. T5 (Google), mBART, ALBERT, XLNet y, en general, muchísimos modelos entrenados con SentencePiece en modo Unigram. Es especialmente popular en modelos multilingües y en buena parte del ecosistema asiático.

WordPiece: BPE con un criterio más exigente

WordPiece es, esencialmente, BPE con una pequeña diferencia conceptual que cambia bastantes cosas en la práctica. Sigue construyendo el vocabulario de abajo arriba, fusionando pares iteración a iteración, pero el criterio para elegir el par ganador es distinto.

Mientras BPE elige siempre el par más frecuente, WordPiece elige el par que más mejora la probabilidad del corpus al fusionarse. La fórmula que usa en la práctica para puntuar cada par (A, B) es:

score(A, B) = freq(AB) / (freq(A) × freq(B))

Léelo despacio: el numerador es cuántas veces aparece el par junto en el corpus; el denominador es cuántas veces aparece cada pieza por separado, multiplicadas. El cociente premia los pares cuyos componentes casi siempre van juntos, aunque su frecuencia bruta no sea la más alta. Es, en espíritu, una versión simplificada del pointwise mutual information (PMI) que llevamos décadas usando en lingüística computacional.

El mismo ejemplo, otro ganador

Volvamos al corpus de antes (low: 5, lower: 2, newer: 6, wider: 3). Comparemos dos pares:

BPE habría elegido e + r. WordPiece elige i + d, porque la fusión es más “informativa”: cuando ves i en el corpus, prácticamente siempre viene d justo detrás, así que tratarlos como un solo token reduce mucho más la ambigüedad.

En la práctica, los vocabularios resultantes de BPE y WordPiece se parecen mucho, pero WordPiece tiende a capturar mejor las unidades con asociación fuerte —prefijos, sufijos, raíces poco frecuentes pero cohesionadas— y peor las simples coapariciones de piezas individualmente comunes.

Una nota histórica más. WordPiece se publicó originalmente en 2012 por Schuster y Nakajima (Google), para mejorar el reconocimiento de voz en japonés y coreano. Solo en 2018 lo redescubrió el público general cuando Google lo usó para entrenar BERT.

Quién usa WordPiece hoy. BERT y toda su familia de encoders: DistilBERT, ELECTRA, MobileBERT, los primeros ALBERT. Es la elección dominante en modelos de búsqueda semántica, clasificación y information retrieval moderno. En LLMs generativos de uso masivo, en cambio, ha quedado relegado a un papel secundario.

La factura: cómo el tokenizer cambia lo que pagas

Aquí es donde toda esta arqueología algorítmica aterriza en tu cuenta corriente. Resumamos lo que llevamos:

• El tokenizer decide cuántos tokens caben en cada texto.

• Esa decisión depende del corpus con el que se entrenó.

• Tú pagas por token.

Esas tres líneas son toda la teoría que necesitas para entender la factura. Lo que falta son los matices, que son los que se cobran.

Por qué un emoji cuesta cinco tokens y “el” cuesta uno

“el” aparece varios cientos de millones de veces en cualquier corpus en español. Cualquier tokenizador decente lo guarda como un token único y lo encuentra al primer intento. Un emoji como 🛒, en cambio, aparece poquísimo en los corpus de entrenamiento (las páginas web técnicas, los libros y los repositorios de código no rebosan emojis). El tokenizador no le asigna un token propio. Resultado: hay que codificarlo en UTF-8, que son cuatro bytes, y cada byte se trata como un token aparte. Un solo emoji puede convertirse en cuatro o cinco tokens él solo.

La misma lógica se aplica a tu jerga técnica, a nombres propios poco habituales o a esa expresión regional que no salía en los foros del corpus.

Por qué pagas más por escribir en español

Aquí entra el sesgo de corpus. La mayoría de los grandes modelos —GPT, Claude, Llama— se entrenan con un corpus en el que el inglés domina muy ampliamente. Los pares de bytes en inglés son más frecuentes y, por tanto, los pares en inglés tienen sus propios tokens “comprimidos”. Los pares en español, no tanto. La consecuencia práctica: una frase en español tiene entre un 30% y un 80% más tokens que la misma frase en inglés, dependiendo del modelo.

“House” es un token. “Casa” suelen ser dos: ca + sa. Multiplica eso por cada mensaje, cada usuario, cada día.

La cifra real (mayo 2026)

Para que la factura aterrice, una foto del mercado a precios de hoy, por millón de tokens:

Parecen cifras pequeñas hasta que multiplicas por usuarios reales. Un asistente conversacional con un usuario activo medio consume con facilidad 50.000–200.000 tokens al día entre input y output. Saca la cuenta para 10.000 usuarios.

El multiplicador oculto

Y aquí está el detalle que más se escapa: si tu modelo es caro y su tokenizer es malo para tu idioma, no pagas el sobrecoste una vez, lo pagas dos veces. Pagas más caro por token, y pagas más tokens por cada mensaje. Es factor multiplicador, no sumatorio.

Un 30% más caro por token × 50% más tokens por mensaje = casi el doble de factura mensual para el mismo producto, comparado con un modelo equivalente con tokenizador bien afinado a tu idioma.

Esa es la razón por la que la decisión “qué LLM usamos” no se puede tomar solo mirando el ranking de calidad ni solo mirando el precio por token. Hay que mirar las dos cosas a la vez, y mirarlas en el idioma en el que tu producto se usa de verdad.

Lo que entender los tokens te permite hacer

Llegados aquí, sabes qué es un token, cómo nace, por qué unos cuestan más que otros y cómo todo eso se traduce en factura. La pregunta práctica es qué cambia en tu trabajo a partir de mañana. Cuatro cosas concretas, todas accionables.

Audita tu gasto en la unidad correcta. La métrica útil no es “cuántas peticiones hace mi producto al LLM al día”. Es cuántos tokens consume cada funcionalidad por usuario activo al día. Esa diferencia es la que separa los equipos que escalan IA en serio de los que se llevan sorpresas a final de mes. Si trabajas con un proveedor cerrado, instrumenta tu código para registrar tokens de input y de output por endpoint, por feature y por usuario. Sin ese dato, no estás gestionando un producto IA: estás cruzando los dedos.

Elige el tokenizer cuando elijas el modelo. Si estás evaluando modelos open source, no mires solo el ranking ni la latencia. Mete tu propio texto representativo en el tokenizer de cada candidato y mide cuántos tokens te salen. Un modelo “barato” con un tokenizer malo para tu idioma puede ser, en la práctica, más caro que un modelo “caro” con un tokenizer bien afinado.

Decide con criterio entre las cuatro palancas. Hablamos en el [artículo anterior](https://www.gemba.es/p/por-que-tu-proximo-llm-en-produccion) de las cuatro herramientas para mejorar un LLM: prompt engineering, RAG, tools y fine-tuning con LoRA. Cada una tiene un coste muy distinto medido en tokens. Un buen prompt te ahorra tokens en cada llamada; RAG mete más tokens en cada llamada; tools puede tener cualquier perfil; LoRA paga el coste una vez en entrenamiento y ninguno en inferencia. Entender el coste en tokens de cada palanca es lo que convierte la decisión “¿cuál uso?” en una decisión con número, no con intuición.

Optimiza el prompt cortando contexto barato. El último ejercicio: revisa los prompts de sistema que más se ejecutan en tu producto y mira cuántos tokens consume el contexto fijo. Casi siempre hay un 10%-30% que se puede recortar sin pérdida de calidad. En productos con tráfico real, ese 20% se traduce directamente en miles de euros al mes.

Los tokens son la unidad de tu producto. Tratar la unidad como una caja negra es trabajar a ciegas. Tratarla con criterio es lo que separa los productos IA que escalan de los que se hunden en su propia factura.

Dos toolkits abiertos para que lo experimentes

Para que esto no se quede en lectura, he preparado dos repositorios públicos, ambos con licencia MIT, pensados para roles distintos.

📦 gemba-tokenizers-from-scratch — Los tres algoritmos implementados desde cero en Python, sin librerías externas.

Es la versión código de este artículo. BPE, Unigram con Viterbi y WordPiece, cada uno en un fichero corto, comentado, con ejemplos paso a paso y comparativas sobre el mismo texto. No es código de producción: es código para entender. Pensado para que lo abras, lo ejecutes, lo modifiques y veas en directo cómo cada algoritmo toma decisiones distintas con el mismo corpus. Incluye un playbook para Claude Code que carga el repo y permite hacer preguntas tipo “tokeniza esta frase con los tres algoritmos y compara”.

🧮 gemba-token-cost-calculator — Calculadora de coste real en varios modelos y varios idiomas.

Esto es lo opuesto: producción, no didáctica. Usa los tokenizadores reales —tiktoken para OpenAI, transformers de HuggingFace para Llama 3, Qwen, Mistral, T5 y BERT, y la API oficial de Anthropic para Claude— y los combina con una tabla de precios actualizable. Le metes un texto representativo de tu producto (o un fichero), eliges los modelos y los idiomas que quieres comparar, y te devuelve cuánto te cobraría cada combinación. También se invoca como skill de Claude Code: /calcular-tokens texto.md gpt-4o,claude-opus,qwen3-8b. Pensada para tomar decisiones de presupuesto con número, no con intuición.

Uno para entender, el otro para decidir. Los enlaces directos están al final, en el cierre.

Para terminar

Llevamos dos años pagando IA en una moneda que casi nadie se ha parado a mirar de cerca. Hoy ya la has mirado. Sabes que un token no es una palabra, que se inventa contando frecuencias sobre un corpus, que hay tres familias —BPE, Unigram con Viterbi, WordPiece— y que cada una toma decisiones distintas con consecuencias muy concretas en tu factura. Sabes también que detrás de esa “magia nueva” hay matemáticas que algunos investigadores estaban escribiendo cuando aún no había internet.

La pregunta con la que te dejo es esta: ¿sabes cuántos tokens consume un usuario tuyo en un día normal? Si la respuesta es no, mañana es buen día para empezar a medirlo. Es la primera métrica que tienes que dominar para construir productos IA que escalen sin reventar la cuenta.

Hasta el lunes que viene.

La respuesta cabe en una frase: porque el modelo tiene que ser nuestro.

Este artículo explica qué significa eso, cómo lo estamos haciendo, y por qué creo que es la decisión correcta para cualquier empresa que meta IA dentro de su producto — no al lado.

Por qué frontier es la primera respuesta lógica

Si me hubieras preguntado hace dieciocho meses qué LLM íbamos a meter en nuestros productos, te habría dicho lo mismo que te diría cualquier CTO razonable: el mejor disponible. Claude, GPT, Gemini. La pregunta no era cuál, era cuál de los tres ganará la próxima eval.

Y tiene su lógica. Los modelos frontier resuelven el 99% de los casos de uso de manera espectacular. Tienen el mejor razonamiento, el mejor multilingüe, el mejor tool use. Pagas una API, mandas un prompt, recibes una respuesta. Cero infraestructura, cero entrenamiento, cero deuda técnica.

Es la elección por defecto. Y es exactamente eso lo que la convierte en un problema cuando empiezas a hacer producto en serio.

Porque la pregunta que importa no es «¿qué LLM es el mejor?». Es «¿qué pasa cuando tu producto crece?».

Los cuatro problemas de frontier dentro del producto

Cuando metes un LLM frontier en una funcionalidad concreta de tu producto, hay cuatro cosas que cambian en silencio. Las cuatro son contables con los dedos. Las cuatro son las que te van a obligar, en algún momento, a replantearte la decisión.

Tus datos salen de tu perímetro

Cada vez que llamas a la API de un proveedor frontier, le estás mandando algo: un prompt, un fragmento de tu catálogo, una pregunta de un cliente, un trozo de tu histórico. Da igual lo que diga el contrato sobre retención: ese dato ha cruzado tu frontera.

Para una empresa como Mercadona, el catálogo, los procesos internos y las conversaciones con clientes son parte del activo. No son cosas que mandes a un tercero porque es más cómodo. Y el problema no es el cumplimiento legal — eso se gestiona —. El problema es que tu ventaja competitiva, lo que de verdad sabe tu empresa hacer, se convierte en training data potencial para el modelo que mañana vas a tener que comprar a precio de mercado.

El coste escala con cada cliente, cada feature y cada conversación

Frontier cobra por token. Suena razonable hasta que haces los números a escala.

Si tu producto tiene un asistente que se usa una vez por sesión, multiplicado por millones de sesiones al mes, multiplicado por cada nueva funcionalidad de IA que añades — el coste no crece, explota. Y crece exactamente en el peor momento: cuando tu producto funciona bien y la gente lo usa más.

Pero el problema de fondo no es el coste absoluto. Es que tus costes suben al mismo ritmo que tu facturación. Y eso rompe el apalancamiento operativo.

El apalancamiento operativo es el motivo por el que un negocio digital es atractivo: tu coste de servir al cliente número 10 millones es prácticamente el mismo que el del cliente número uno. Cada usuario nuevo entra casi todo a margen. La curva de ingresos sube, la de costes se aplana, y el beneficio se dispara. Esa es la promesa del software desde hace cuarenta años.

Frontier por token rompe esa promesa de raíz. Cada conversación nueva es un coste nuevo. Cada feature de IA es una factura adicional. Tu margen no se expande con la escala — se queda fijo, en el mejor caso. En el peor, se contrae cuando el proveedor sube tarifas o cuando empiezas a usar modelos más capaces para no quedarte atrás de la competencia.

No es la primera vez que el sector tropieza con esto. Es exactamente lo que pasó con el SaaS y con el cloud público a escala. Empresas como Dropbox descubrieron que pagar a AWS por cada terabyte de cliente se comía sus márgenes brutos, y acabaron repatriando el almacenamiento a infraestructura propia — con ahorros de cientos de millones y márgenes brutos que pasaron de no llegar al 35% a superar el 65%. Basecamp y otras empresas más pequeñas han hecho el mismo viaje en los últimos años: cuando operas a escala, cloud público es dos o tres veces más caro que infra propia bien dimensionada. La conveniencia inicial se convierte en un impuesto permanente sobre tu crecimiento.

Frontier en producción es el siguiente capítulo de esta misma historia. Y los CFOs que aprendieron la lección con AWS la van a aprender otra vez con OpenAI y Anthropic — solo que esta vez el coste no es almacenamiento, es cada palabra que tu producto le dice a un cliente.

Lo que dice tu producto lo decide tu proveedor

Un día Anthropic decide que su próximo modelo se comporta distinto en una tarea concreta. Otro día OpenAI deprecia la versión que tú habías evaluado. Otro día cambian el system prompt por defecto y tu producto empieza a responder con un tono que no es el tuyo.

No estoy hablando de hipotéticos. Esto pasa cada pocos meses. Y cuando tu funcionalidad crítica depende del modelo de un tercero, tú no decides cómo se comporta tu producto. Lo decide la última versión que ese tercero ha desplegado.

Para una herramienta interna eso es asumible. Para un producto que ven millones de clientes, no.

Pagas por capacidades que no necesitas

Los modelos frontier son generalistas. Saben de poesía persa, de derecho mercantil húngaro y de combinatoria avanzada. Y los pagas todos, en cada token, aunque tu producto solo necesite hablar de pedidos, productos y entregas.

La paradoja es que para tu tarea específica — la única que de verdad importa para tu producto —, un modelo open source mucho más pequeño, afinado con tus datos, iguala o supera al frontier. No porque sea mejor en general. Porque está concentrado en lo tuyo.

Estás pagando un Ferrari para ir a comprar el pan a la esquina.

El OSS ya cerró la brecha donde importa

Todo lo anterior sería un debate teórico si el open source no fuera una alternativa creíble. Hace dos años no lo era. Hoy sí, y el cambio se ha dado tan rápido que mucha gente decidiendo arquitectura de IA en empresas todavía no se ha enterado.

Conviene fijar primero qué quiere decir “open source” en este contexto, porque el término se usa con cierta ligereza. Cuando hablo de modelos OSS me refiero a modelos cuyos pesos — los parámetros que el modelo ha aprendido durante el entrenamiento — son públicos, descargables y vienen con licencias que permiten uso comercial: Apache 2.0, MIT o equivalentes. No son APIs a las que llamas. Son modelos que te bajas, que ejecutas en tu propia infraestructura, que puedes inspeccionar, evaluar, modificar y reentrenar. La diferencia con los modelos cerrados — Claude, GPT, Gemini — no es solo de licencia. Es de ubicación: un modelo OSS vive donde tú decides; uno cerrado vive donde decide su proveedor.

En 2024, los modelos abiertos iban dos generaciones por detrás. Llama 2 contra GPT-4 era una pelea perdida. La diferencia de calidad era visible a simple vista, en cualquier tarea, y nadie en su sano juicio metía en producción un modelo abierto si tenía presupuesto para frontier.

En 2026, el panorama es otro. Qwen3 de Alibaba lidera evaluaciones públicas de código y compite de tú a tú en razonamiento, con licencia Apache 2.0. DeepSeek-V3.1 combina razonamiento profundo con una eficiencia en inferencia muy difícil de igualar para los frontier, también con licencia abierta. Mistral Large viene de Francia, con buen rendimiento multilingüe en lenguas europeas, y Llama 4 de Meta tiene el ecosistema de fine-tuning más maduro del mercado.

Cuatro familias serias, con licencias que permiten uso comercial, con pesos descargables, con comunidades activas. Eso no existía hace dieciocho meses.

Pero conviene afinar la palabra “abierto”, porque no todas las licencias son iguales y el matiz importa más de lo que parece. Apache 2.0 (Qwen3) y MIT (DeepSeek) son licencias open source puras: puedes usar el modelo, modificarlo, redistribuirlo, integrarlo en productos comerciales sin restricciones de tamaño, sector o uso. Son el equivalente, para modelos, de lo que Linux representa en software de servidor: libertad real.

La Llama Community License de Meta no es eso. Es lo que en la industria se llama source available: los pesos están disponibles y puedes hacer mucho con ellos, pero la licencia introduce condiciones. La más conocida es que si tu producto supera cierto umbral de usuarios mensuales activos tienes que negociar una licencia comercial separada con Meta. Y mantiene una cláusula de usos prohibidos sobre la que Meta tiene la última palabra. Para una empresa pequeña la diferencia es invisible. Para una empresa que crece — y ese suele ser el plan — no lo es.

Mi recomendación, cuando alguien me pregunta por dónde empezar, es clara: si haces este viaje, hazlo con licencias OSS puras. El motivo principal por el que una empresa va a OSS es evitar depender del roadmap de un tercero. Una licencia “casi abierta” reintroduce exactamente esa dependencia, solo que con menos visibilidad — porque la dependencia no se manifiesta hasta que tu producto crece o hasta que el proveedor decide cambiar los términos. Apache 2.0 o MIT son la garantía de que la decisión sobre qué hacer con tu modelo la sigues tomando tú dentro de cinco años, no Meta o quien sea.

Aclarado esto, el punto importante de fondo es la trampa mental de comparar modelos en abstracto.

Cuando alguien dice “Claude es mejor que Qwen”, normalmente está mirando un benchmark generalista: MMLU, GPQA, evaluaciones de razonamiento puro. Y es verdad — en general, frontier sigue ganando. La pregunta es si “mejor en general” tiene algo que ver con tu producto.

Tu asistente de pedidos no necesita resolver olimpiadas matemáticas. Tu chatbot de atención al cliente no necesita escribir poesía. Tu motor de recomendaciones no necesita debatir filosofía moral. Necesitan entender tu catálogo, tu tono, tus operaciones, tus clientes. Necesitan ser excelentes en una superficie muy concreta.

Y para esa superficie concreta, un modelo open source pequeño afinado con tus datos iguala o supera a un modelo frontier de un orden de magnitud más grande. No porque sea mejor en general — sigue sin serlo. Porque está concentrado en lo tuyo, sin la dispersión de tener que saberlo todo.

Hay una intuición técnica detrás de este resultado que merece la pena explicitar. El espacio de razonamiento que un modelo tiene que cubrir para ser excelente en una tarea concreta es órdenes de magnitud menor que el que necesita un modelo generalista. Un asistente que solo tiene que entender pedidos, productos y entregas no razona sobre química orgánica, ni resuelve acertijos lógicos arbitrarios, ni traduce poesía clásica. Tiene que ser excelente en una superficie acotada. Y cuando acotas la superficie, acotas la dificultad: hacer bien una sola cosa es más fácil que hacer bien muchas.

Es un principio que se aplica a humanos, a software y a modelos. Un equipo pequeño centrado en un problema vence sistemáticamente a un equipo grande que intenta abarcarlo todo. Una herramienta que hace una cosa la hace mejor que una suite que pretende hacer cinco. Y un modelo de menor capacidad bruta, especializado en tu dominio, supera a uno de capacidad bruta superior pero atención dispersa, en tu dominio. Por eso un OSS bien afinado puede competir de tú a tú con un frontier diez veces más grande en lo que de verdad importa para tu producto: porque la pelea no es la que el benchmark cuenta. Es una pelea acotada, y en peleas acotadas, especialización gana.

Es la diferencia entre un médico de cabecera que conoce a tus pacientes desde hace veinte años y el mejor diagnosticador del mundo al que llamas por teléfono. El segundo sabe más medicina. El primero acierta más con tus pacientes.

Tres herramientas para tres problemas distintos: prompts, RAG y LoRA

Una de las confusiones más frecuentes en este terreno es presentar prompts, RAG y fine-tuning como un escalón: que primero pruebas prompts, luego subes a RAG y, si no llega, terminas en fine-tuning. La realidad es otra. Son tres herramientas que resuelven problemas distintos. Elegir la equivocada es una de las maneras más caras de fracasar con IA en producto.

System prompts es siempre la primera capa, porque opera sobre algo que las otras dos no tocan: el comportamiento del modelo en cada llamada. RAG y LoRA, en cambio, no son alternativas escaladas. Son respuestas a preguntas distintas, y pueden coexistir o no según lo que necesite tu funcionalidad.

Capa 1 · System prompts: el comportamiento, en cada llamada

Es la capa más rápida y la más barata. Le dices al modelo, en cada llamada, qué tono usar, qué decir, qué nunca decir, y en qué formato responder. Reglas de comportamiento, guardarrales, estilo.

El cambio es inmediato — editas el prompt, despliegas, listo. Minutos. El coste es marginal: los tokens del prompt en cada llamada. Y el alcance, aunque parezca modesto, no lo es: la mayor parte del tono y de los errores graves de un asistente se arreglan aquí, no en el modelo.

System prompts es la única capa que siempre tiene sentido. Si no resuelves un problema con prompts, lo más probable es que lo tengas mal planteado antes de plantearte ninguna otra cosa.

Capa 2 · RAG: cuándo sí, cuándo no

RAG no es “prompts pero más potente”. Es una herramienta concreta para un problema concreto: que el modelo responda apoyándose en información tuya que el modelo no podía conocer en su entrenamiento.

Tiene sentido cuando:

• Tu funcionalidad necesita responder con datos que cambian (catálogo, precios, disponibilidad, estados de pedido, FAQs vivas).

• Necesitas trazabilidad: poder mostrar de dónde sale cada afirmación, citar la fuente, auditar.

• El cuerpo de conocimiento es demasiado grande para meterlo en el prompt en cada llamada.

• Quieres que el conocimiento se actualice sin tocar el modelo — basta con reindexar.

No tiene sentido cuando:

• El problema es de tono, estilo o formato. Eso lo arreglan prompts; RAG no añade nada.

• Tu dominio es estable y cabe en un prompt. Montar un vector store para guardar tres páginas de documentación es complicar gratis.

• La latencia es crítica. RAG añade pasos: embeddings, búsqueda, recuperación, contexto extra. En productos donde la respuesta tiene que ser instantánea, ese coste pesa.

• Tu información no se busca bien por similaridad semántica. Si lo que necesitas es una consulta SQL contra una tabla, una API o una búsqueda exacta por ID, RAG no es el camino — es un rodeo caro.

Y un punto que muchos equipos descubren tarde: RAG mal hecho es peor que no tener RAG. Si tu sistema de recuperación devuelve fragmentos irrelevantes — chunks mal troceados, embeddings pobres, mezcla de fuentes que no tocan — no estás dándole al modelo más contexto. Le estás metiendo ruido. Y el modelo no responde “centrándose en lo relevante”: se confunde, mezcla información, alucina con apariencia de rigor citando fuentes que no aplican. Un RAG sin evaluación seria de la calidad de recuperación puede degradar las respuestas respecto a no tener RAG en absoluto. La parte cara de hacer RAG bien no es la generación — es la recuperación.

RAG es muy útil cuando aplica. El error es asumir que aplica siempre.

Capa 3 · LoRA: cuándo sí, cuándo no

LoRA es la única capa que toca el modelo en sí. Reentrenas una fracción de los pesos con datos tuyos. El modelo no consulta tu conocimiento en cada respuesta: ha aprendido patrones que antes no tenía.

Tiene sentido cuando:

• Necesitas un comportamiento que no se puede expresar como reglas en un prompt — un tono, una jerga, convenciones implícitas, decisiones de matiz que un humano experto reconoce pero no sabe articular.

• Tu volumen de uso es suficiente para amortizar el coste de entrenar y mantener una versión propia.

• Quieres reducir el coste por inferencia: un modelo abierto pequeño y bien afinado puede sustituir a uno grande generalista, con una fracción del coste por llamada.

• Tienes un dataset de entrenamiento de calidad — no solo cantidad, calidad. Sin esto, no hay LoRA que valga.

No tiene sentido cuando:

• El conocimiento que necesitas inyectar cambia frecuentemente. LoRA aprende patrones, no hechos. Si los datos cambian cada semana, estás reentrenando cada semana — y eso no es viable.

• Aún no has agotado prompts y, donde aplique, RAG. Casi siempre que un equipo siente “necesidad” de fine-tuning, el problema real está más arriba.

• No tienes equipo para mantenerlo: GPUs, evaluaciones, versionado, observabilidad, capacidad de revertir. LoRA no es un proyecto puntual — es una línea de mantenimiento.

• El volumen de uso no justifica el coste fijo. Para una funcionalidad de uso puntual, un modelo afinado es matar moscas a cañonazos.

Y luego están las tools: cuando el problema no es saber, sino hacer

Las tres capas anteriores son formas de afinar al modelo a tu contexto. Hay un cuarto recurso que opera sobre algo distinto y es muy fácil de olvidar: las tools (también llamadas function calling o tool use).

Una tool es una función externa que el modelo puede invocar por sí mismo cuando lo necesita: consultar tu API de pedidos, leer un registro en una base de datos, hacer un cálculo, llamar a un servicio interno, ejecutar una acción concreta. El modelo no la ejecuta — pide ejecutarla. Tu sistema la corre, le devuelve el resultado, y el modelo continúa la conversación con esa información en mano.

Tools no compiten con prompts ni con RAG: les añaden una dimensión que ninguna de las tres capas puede dar por sí sola. Donde RAG ofrece conocimiento estático (lo que has indexado de tu corpus), las tools dan información viva y capacidad de actuar: el estado actual de un pedido, el stock real en este momento, la respuesta de un sistema externo, una transacción ejecutada. Para muchas funcionalidades — sobre todo asistentes que tienen que hacer cosas, no solo responder — las tools son lo que convierte una conversación en un producto.

Y un detalle que ahorra muchos disgustos: el lugar correcto para datos estructurados que necesitas exactos — precios, stock, IDs, estados — no es RAG. Es una tool. RAG es para texto donde la similaridad semántica funciona. Tools son para hechos que tienen que ser exactos y vivos. Confundir las dos es la fuente número uno de respuestas seguras de sí mismas y profundamente equivocadas.

El criterio que importa

No subes de prompts a RAG, ni de RAG a LoRA. Eliges la herramienta que encaja con la naturaleza de tu problema:

• ¿El problema es comportamiento, tono o formato? → prompts.

• ¿El problema es conocimiento textual puntual y verificable? → RAG.

• ¿El problema es datos vivos, exactos o capacidad de actuar? → tools.

• ¿El problema es patrones implícitos, estilo profundo o coste por inferencia a escala? → LoRA.

Las cuatro pueden convivir en la misma funcionalidad, pero no porque sean niveles de una escalera. Porque resuelven cosas distintas.

El umbral económico que casi nadie cuenta

Hasta aquí los argumentos por OSS son cualitativos: soberanía, control, especialización, evitar que tu producto dependa del roadmap de un tercero. Son argumentos válidos. No son los que ganan la conversación con un CFO.

La conversación con un CFO la ganas cuando el cálculo cierra. Y el cálculo, cuando lo haces de verdad, es más matizado de lo que se cuenta en LinkedIn — en las dos direcciones.

El cálculo simple

Frontier es un coste variable. Pagas por token consumido, sin más. Empiezas en cero y subes con el uso. Es ideal para empezar — no necesitas comprometer nada hasta que la funcionalidad demuestra tracción.

OSS propio es un coste fijo. Tienes que tener GPUs (o reservar capacidad gestionada), un vector store si usas RAG, observabilidad, evaluaciones, y un equipo que mantenga todo eso. El primer token que generas te cuesta una fortuna. Los siguientes millones, prácticamente nada.

Donde se cruzan las dos líneas es tu umbral. Por debajo, frontier sale más barato. Por encima, OSS sale más barato — y la brecha se ensancha rápido a medida que el uso crece.

Lo que casi nadie cuenta del lado OSS

La trampa habitual al hacer este cálculo es subestimar el lado fijo. La cuenta ingenua compara €/M tokens de la API frontier contra el coste de una GPU. No es esa la comparación.

Tener un modelo en producción incluye, además del compute:

• Equipo: gente que entiende fine-tuning, evaluación, despliegue de modelos, observabilidad. Es perfil escaso, no barato.

• Evaluaciones: si no mides la calidad de tu modelo afinado contra una baseline frontier de manera continua, no sabes si has degradado. Eso es infraestructura de evaluación, datasets curados y proceso.

• Mantenimiento: los modelos abiertos sacan nuevas versiones. Tu LoRA está atado a una. Migrar tiene coste.

• Observabilidad: latencia, fallos, calidad de las respuestas, deriva. Todo eso te lo da gratis un proveedor frontier; en infra propia lo construyes tú.

Si haces el cálculo solo con GPUs y olvidas todo lo demás, tu OSS parece barato y luego no lo es. Y si haces el cálculo solo con GPUs y olvidas lo demás también en el lado frontier, te equivocas en la otra dirección — porque frontier al final también requiere tu propio observabilidad, evaluación y proceso de migración cuando cambian de modelo.

Cuándo OSS no sale a cuenta

Hay casos en los que la respuesta honesta es “frontier es la opción correcta hoy”:

• Volumen bajo o impredecible: si tu funcionalidad mueve un puñado de miles de llamadas al mes, no hay aritmética que cierre. Quédate en API.

• Funcionalidad experimental: si no sabes aún si la feature va a sobrevivir el próximo trimestre, es absurdo amortizar nada. Frontier es el modo de prototipar.

• Equipo insuficiente: si no tienes a nadie que pueda mantener el modelo, el coste real no es la GPU — es el riesgo. Y ese riesgo se cobra solo en el peor momento.

• Una sola funcionalidad pequeña: si tu único caso de uso es un asistente puntual de baja intensidad, el coste fijo no se reparte entre nada.

En todos estos casos, frontier no solo es razonable: es lo correcto. Pelear contra eso es ideología, no estrategia.

Cuándo sí, y por qué la brecha se ensancha

OSS empieza a tener sentido cuando se cumplen tres condiciones a la vez: volumen alto y sostenido, varias funcionalidades de IA que comparten infraestructura, y un horizonte previsible en el que ese uso va a crecer, no a desaparecer.

Cuando esas tres condiciones se cumplen, el coste fijo se reparte y el coste variable evitado crece a la vez. La diferencia entre las dos curvas no es lineal — se ensancha. Y a partir de cierto punto, el cálculo deja de ser interesante: frontier en producción simplemente no es competitivo.

Hay además un efecto temporal que muchos análisis ignoran: el umbral baja cada año. Las GPUs son más eficientes, los modelos abiertos son más capaces con menos parámetros, las técnicas de fine-tuning bajan en coste. Lo que hace dieciocho meses requería un cluster, hoy cabe en una máquina. Lo que hoy requiere un equipo dedicado, en dos años cabrá en una herramienta gestionada.

Si tu producto tiene volumen y horizonte, no estás eligiendo entre OSS y frontier en un instante: estás eligiendo en qué dirección quieres que tu coste por conversación evolucione durante los próximos cinco años. Y esa pregunta tiene una respuesta bastante clara.

Hazte el cálculo, no la teología

El error frecuente es tratar esta decisión como ideológica — “yo soy team OSS” o “yo soy team frontier” —. No lo es. Es aritmética con horizonte temporal. Coge tu volumen real, los precios actuales del proveedor que uses, una estimación honesta de tu coste fijo OSS (incluyendo equipo y mantenimiento, no solo compute), y proyéctalo dos o tres años con el crecimiento que esperas. La respuesta sale del cálculo, no de la convicción.

Lo que sí cambia es a quién le toca asumir el coste de equivocarse. Si te quedas en frontier y tu producto escala, lo paga el negocio en márgenes erosionados. Si saltas a OSS y tu producto no escala, lo paga el negocio en infraestructura ociosa. La pregunta es de qué error te puedes recuperar mejor.

El rol que sí tiene Claude (y los demás frontier): research, no producción

Todo lo anterior se puede leer mal: que estoy diciendo que los modelos frontier no sirven. No es eso, en absoluto. Frontier sirve — y mucho. Lo que defiendo es que su lugar no es producción. Su lugar es research y baseline.

Esos son dos roles distintos y los dos son importantes.

Rol 1 · Research: la prueba de viabilidad

Cuando tu equipo de producto pone encima de la mesa una idea de funcionalidad con IA, hay una pregunta que viene antes de cualquier otra: ¿es siquiera resoluble? ¿La mejor IA disponible en el planeta puede hacer lo que estamos imaginando, en las condiciones que necesita un cliente real?

Esa pregunta la contesta frontier en una tarde. Coges Claude o el equivalente, montas un prototipo rápido, le metes ejemplos reales, y observas. Si frontier no llega — si las respuestas son malas, si el razonamiento falla, si los casos límite se rompen — la idea no está lista. No vas a hacerlo mejor con un OSS más pequeño. Has ahorrado seis meses.

Si frontier sí llega, sabes dos cosas a la vez: el problema es resoluble, y has fijado el techo de calidad al que tu solución de producción tiene que aspirar. Eso es lo segundo.

Rol 2 · Baseline: la vara de medir

Aquí es donde frontier se vuelve imprescindible incluso para una empresa que ha decidido no tenerlo en producción. Frontier es el patrón contra el que mides tu propio modelo.

Cada vez que afinas un OSS para tu caso de uso, cada vez que cambias el sistema de RAG, cada vez que iteras sobre un LoRA — necesitas saber si has mejorado o has empeorado. Y “mejor” o “peor” no son adjetivos, son números: tasa de éxito en una eval, calidad subjetiva en muestras anotadas, porcentaje de respuestas correctas en preguntas reales de clientes.

La vara de medir es Claude. Si tu OSS afinado no se acerca a Claude en las tareas que importan a tu producto, no estás listo para producción. Habrás conseguido independencia, sí, pero a costa de degradar la experiencia del usuario. Eso no es una victoria — es haber metido complejidad operativa sin ganar nada.

Si tu OSS sí se acerca o lo supera en tu superficie concreta — y lo hace de manera medible y reproducible — entonces estás listo. Y solo entonces.

El flujo que ata las piezas

El proceso completo que se deduce de estos dos roles es bastante limpio y se puede aplicar a casi cualquier funcionalidad:

1. Idea con Claude: prototipas con frontier para confirmar que el problema es resoluble.

2. Eval contra baseline: defines cómo vas a medir éxito en este caso concreto, fijas la línea base con Claude.

3. RAG sobre OSS, si aplica: montas el sistema de recuperación con tu modelo abierto, evalúas contra la baseline.

4. LoRA, si aplica y se justifica: solo si los dos pasos anteriores no llegan y el caso lo merece económicamente.

5. Producción en OSS: cuando la calidad iguala o supera a la baseline frontier, despliegas.

Lo importante de este flujo no es lo que está en él. Es lo que está fuera: frontier no aparece en el paso 5. Aparece en los pasos 1 y 2, donde aporta lo que de verdad sabe aportar — capacidad bruta para explorar y rigor como vara de medir —, y se queda fuera de la operación diaria del producto.

Es la forma de tener lo mejor de los dos mundos sin pagar el coste de los dos mundos.

Dónde estamos en Mercadona Online (sin vender humo)

He hablado mucho de marco mental, principios y decisiones. Toca aterrizar en dónde estamos nosotros, porque me parece deshonesto publicar todo lo anterior sin contar la verdad de lo lejos — o cerca — que estamos del destino.

La decisión está tomada. Producción en OSS, frontier en research y baseline. Esa es la dirección estratégica de Mercadona Online y se ha discutido y aprobado al nivel donde estas decisiones se toman. No es una idea de un equipo aislado. Es por dónde queremos que vaya nuestra capa de IA en producto.

Lo que ya está pasando es la parte fácil de contar. Algunos de nuestros productos internos — asistentes de coordinadores, herramientas de calidad, sistemas de soporte a operaciones — tienen IA dentro hoy. Y esa IA está apoyada, en este momento, en Claude vía Vertex como solución provisional. Funciona, da valor y nos ha permitido validar que los casos de uso son resolubles. Eso es exactamente el rol 1 del que hablaba antes: research aplicado, prueba de viabilidad en producto real.

Lo que estamos construyendo es la parte que importa de verdad. Tenemos un modelo OSS propio en marcha — actualmente sobre Qwen3 8B, afinado con LoRA y datos nuestros — corriendo en infraestructura propia. Y estamos montando el sistema de evaluaciones que nos va a permitir comparar el comportamiento de nuestro modelo contra la baseline de Claude en cada una de las funcionalidades que importan, antes de cambiar nada en producción.

Hay una decisión consciente en lo que no estamos tomando: no usamos RAG. Enlazo esto directamente con lo que decía en la sección de las herramientas, porque en nuestro caso no se cumplen las condiciones para que aplique. Las funcionalidades que tenemos hoy no manejan grandes volúmenes de información textual que el modelo necesite consultar dinámicamente; lo que necesitan saber cabe en el system prompt, se resuelve por tools contra nuestros sistemas, o se aprende vía LoRA. Y la complejidad de montar bien la recuperación — con todo lo que hablábamos del ruido, la calidad de los embeddings, la evaluación continua de qué se devuelve — no nos compensa hoy. Si en algún momento aparece una funcionalidad que sí lo necesite, lo añadiremos. Pero la regla es exactamente la que recomendaba antes: RAG cuando aplica, no por defecto. Y a nosotros, hoy, no nos aplica.

Lo que aún no tenemos es la parte honesta. No tenemos producción 100% en OSS todavía. Estamos en mitad del viaje, no al final. Las funcionalidades que hoy llegan al cliente y al empleado de tienda van por Claude. La migración a nuestro propio modelo es un trabajo de meses — y por algunas funcionalidades concretas, posiblemente más — porque hay que evaluarlo bien antes de cambiar nada. Si nuestro OSS afinado no se acerca a la baseline frontier en una tarea concreta, no se cambia esa tarea. Se itera hasta que se acerque, o se acepta que esa tarea concreta no es candidata a OSS hoy.

¿Por qué cuento esto antes de tener números reales? Porque la decisión estratégica es lo importante, y los números van detrás. Si esperase a tener todas las métricas para hablar del enfoque, el enfoque ya estaría desfasado cuando lo contara. Prefiero publicar el plan ahora, con la honestidad de que es un plan en ejecución, y volver dentro de unos meses con los datos.

Lo que sí puedo decir hoy con seguridad es que la pregunta “¿esto sale a cuenta?” la hemos hecho. La aritmética cierra para Mercadona — volumen, horizonte y número de funcionalidades de IA suficientes para que el coste fijo se reparta. Y la pregunta “¿el OSS es bueno suficiente?” la estamos contestando funcionalidad a funcionalidad, no en abstracto. Es la única manera honesta de contestarla.

La pregunta que importa

Si tuviera que reducir todo lo anterior a una sola frase, sería esta: el lugar donde decides que viva tu IA es una decisión estructural, no técnica. Decide márgenes. Decide quién determina cómo se comporta tu producto. Decide la velocidad a la que puedes innovar. Decide qué activos quedan dentro de tu empresa y cuáles cruzan la frontera. Tratarla como una decisión de proveedor — “uso este o aquel” — es no ver lo que hay debajo.

La industria del software ya ha vivido este momento dos veces. La primera, con on-premise contra SaaS. La segunda, con servidor propio contra cloud público. En las dos, la conveniencia inicial del proveedor terminó convirtiéndose en un peaje permanente sobre el crecimiento. En las dos, hubo empresas que llegaron tarde a darse cuenta de que estaban subsidiando los márgenes de su proveedor con los suyos. Frontier en producto es el tercer ciclo de la misma película, ahora en directo.

Si tu producto va a tener IA dentro durante la próxima década — y casi todos los productos digitales serios la van a tener — la pregunta importante no es qué LLM usar este trimestre. Es qué relación quieres tener con tu capa de IA dentro de cinco años: una factura mensual creciente con un proveedor que decide cómo se comporta tu producto, o una infraestructura propia, ajustada a tu negocio, sobre la que tomas tus propias decisiones.

Para una empresa con volumen, horizonte y varias funcionalidades de IA que repartan coste fijo, la respuesta — cuando hace el cálculo honesto — sale casi siempre en la misma dirección. La diferencia entre las que actúan ahora y las que actúan dentro de tres años no es la respuesta. Es cuánto habrá pagado de más cada una para llegar al mismo sitio.

¿Dónde está tu umbral?

Gemba se publica todos los lunes a las 8:30. Si te ha resonado, comparte el artículo con un PM o un líder de tecnología que esté tomando esta decisión ahora.

El cuello de botella ya no es ejecutar código

Llevamos meses repitiendo lo mismo desde distintos ángulos: el cuello de botella ya no es escribir el código.

Con un agente bien dirigido, un ingeniero senior puede convertir una user story bien definida en una pull request con tests en verde en un fin de semana. El problema es que el agente solo es tan bueno como la user story que le das. Y antes de la user story, hay un PRD. Y antes del PRD, hay decisiones de roadmap. Y nadie te explica cómo se conecta todo eso sin contradicciones.

En Mercadona Tech estamos probando un pipeline que junta tres herramientas: GSD para roadmap y planificación, el Mercadona User Story Toolkit para definir y priorizar stories, y Superpowers para implementar con TDD. La hipótesis: si los tres hablan entre sí con un contrato claro, el flujo de “idea de producto” a “PR mergeada” se vuelve fluido sin perder rigor.

No es definitivo. Llevamos unas pocas semanas probándolo, no años. Tenemos la sensación de que funciona — el código sale más limpio, las stories aterrizan mejor en producción, hay menos rework. Pero no tengo números aún, así que esto es un playbook en pruebas. Lo publico hoy con un repo open-source para que más equipos lo prueben y lo mejoremos entre todos.

A quién sirve esto y a quién no

El pipeline está diseñado para equipos que tienen el problema de separación de responsabilidades entre producto y desarrollo:

• PMs que escriben PRDs y necesitan convertirlos en stories sin perder fidelidad

• Ingenieros que reciben stories y quieren implementarlas con disciplina (TDD, code review, verificación)

• Equipos donde la consistencia entre planning y ejecución tiene un equilibrio delicado — ROADMAPs que mienten, specs obsoletas, estados desincronizados

Si tu equipo es muy pequeño (1-3 personas), probablemente esto sea un overkill. Para equipos pequeños, Superpowers solo, con su skill de brainstorming, es suficiente: la persona que define producto es la misma que lo implementa o están muy cerca, y un solo agente puede acompañar el flujo completo. La separación de responsabilidades aquí es artificial. Mi recomendación honesta para un equipo de tres es: instala Superpowers, brainstormea la feature, escribe un plan con /superpowers:writing-plans, ejecuta con TDD, y ya. Sin GSD. Sin Mercadona User Story Toolkit. Vendrán cuando necesites coordinar más roles, mantener documentación o trabajar en funcionalidades más complejas en equipos más grandes.

Si tu equipo tiene PMs separados de Eng y trabaja en features de tamaño medium-large (varias stories, varias semanas, objetivos por Q), aquí es donde este pipeline puede brillar.

El pipeline en una imagen

Tres fases. Dos de PM, una de Eng. La separación entre las dos primeras es deliberada: planificación, roadmapping y definición de JTBDs y User Stories son trabajos distintos, con metodologías distintas.

• Fase 1 — GSD (PM): roadmap multi-fase, decisiones de scope, especificación de cada fase con requirements falsables. Output: el directorio .planning/ con PROJECT.md, REQUIREMENTS.md, ROADMAP.md, y por cada fase SPEC.md y PLAN.md.

• Fase 2 — Mercadona User Story Toolkit (PM): transforma el plan de GSD en stories de calidad. Empieza con /from-gsd que produce un PRD sintético, lo completa el PM con research (entrevistas Mom Test), genera JTBDs, escribe stories con scoring 6D, las valida y prioriza en batches anti-waterfall.

• Fase 3 — Superpowers (Eng): recibe el batch de stories y las implementa con TDD subagent-driven. Cada commit lleva el ID de requirement (feat: implement DETECT-01...). Tests verdes, code review, PR mergeada.

Y para cerrar el círculo: un puente. gsd-bridge es un CLI que detecta los REQ-IDs en los commits y actualiza automáticamente STATE.md, PLAN.md, ROADMAP.md y genera VERIFICATION.md. Sin él, los artefactos de GSD divergen de la realidad del código en cuanto la implementación arranca.

Esa es la idea. Ahora vamos a por el detalle.

Por qué tres herramientas y no una

La pregunta razonable es: ¿por qué no usar solo Superpowers para todo? Ya tiene brainstorming, writing-plans, executing-plans. ¿Para qué meter GSD y Mercadona User Story Toolkit en medio?

Porque cada herramienta está optimizada para un trabajo distinto, y mezclar trabajos en una sola herramienta produce resultados mediocres en todos.

GSD está optimizado para roadmap multi-fase. Tiene noción de fases con dependencias, success criteria, requirements falsables, y un ciclo de planning con verificación iterativa. Si intentas reproducir eso con Superpowers solo, acabas con un plan único gigantesco que no captura bien la cadencia trimestral del producto. Si pides a GSD que ejecute, ahí también flojea — su gsd-execute-phase no aplica TDD por defecto y tiende a generar código que pasa los tests pero no encajaría en una code review exigente.

El Mercadona User Story Toolkit está optimizado para definir stories con criterio de PM y unir ambos mundos. Es la pieza que traduce y asienta lo que sale de GSD con lo que entre a Superpowers. Quality gate del PRD, research Mom Test, JTBDs con evidencia, antipatrones detectados (fake stories, stories grandes mal divididas), priorización con cinco lentes ponderadas anti-waterfall. Esto es trabajo de PM con metodología propia, no de un copiloto general. Pedirle a Superpowers que escriba stories sin esta capa termina en tareas técnicas disfrazadas de user stories.

Superpowers está optimizado para ejecución disciplinada. TDD obligatorio (test-driven-development skill), subagent-driven para paralelizar tareas independientes, verification-before-completion para no mentir sobre el estado del código. La cultura de ingeniería de Mercadona Tech exige TDD y buenas prácticas. Superpowers se alinea perfectamente; GSD no fue diseñado con esa disciplina como requisito.

La separación es por especialización, no por dogma. Cada agente está afilado para un rol concreto, y el contrato entre ellos es lo que hace que el conjunto funcione.

Working backwards: el modelo mental que mejor encaja

Hay una metodología que llevo años admirando y que pocos equipos ejecutan bien: el Working Backwards de Amazon. La idea es radicalmente simple: antes de construir nada, el equipo escribe el press release del producto terminado y un FAQ de seis páginas que cualquier ejecutivo pueda leer y entender. Si no consigues articular el producto en ese formato — quién es el cliente, qué problema resuelve, cómo sabremos que ha funcionado — no estás listo para empezar. Bill Carr y Colin Bryar lo cuentan en detalle en Working Backwards (2021), y aunque la práctica original está pensada para humanos escribiendo narrativas en seis páginas, la lógica subyacente es la mejor modelo mental que conozco para trabajar con agentes.

Este pipeline es, en el fondo, una versión ejecutable de Working Backwards. Las correspondencias son directas:

• GSD obliga a escribir PROJECT.md, REQUIREMENTS.md y SPEC.md con acceptance criteria falsables antes de pisar código. Es la disciplina del PR/FAQ: definir el resultado deseado en términos verificables antes de empezar la implementación. Si el acceptance criteria no se puede testear, GSD no te deja avanzar.

• El Mercadona User Story Toolkit exige completar el PRD con JTBDs basados en entrevistas Mom Test. Es la customer obsession de Amazon — empezar por el cliente con evidencia, no con un buyer persona inventado.

• El quality gate del PRD se niega a continuar si hay GAPs no resueltos. Es el equivalente a “no pasamos a build hasta que el PR/FAQ esté aprobado”. El agente no construye sobre un brief que miente: si falta una métrica baseline o una cita literal de cliente, el toolkit lo marca como GAP explícito y exige resolverlo.

• La priorización en batches anti-waterfall replica la lógica de Amazon de equipos pequeños que entregan valor end-to-end por iteración, en lugar de “infra primero, UI después, valor al final”.

Lo que este pipeline aporta sobre el Working Backwards original es mecanizar el rigor. La metodología de Amazon depende mucho de la cultura: si el equipo no se compromete a escribir el PR/FAQ con honestidad, la disciplina se pierde rápido. Aquí los agentes son los guardianes — la skill se niega a inventar números, exige acceptance criteria testeables, y bloquea avance si las stories no derivan de evidencia real.

Esto importa especialmente cuando hay agentes de implementación de por medio: un agente no tiene contexto de negocio, solo ve la spec que le pasas. Si la spec es vaga, el código será vago. Si la spec inventa números, el código optimizará para números inventados. Working Backwards minimiza ese riesgo forzando claridad en la entrada.

Mi conclusión tras semanas de uso: si vas a orquestar agentes de planning con agentes de implementación, no hay modelo mental que encaje mejor que Working Backwards. Outcomes articulados con precisión, evidencia antes de hipótesis, narrativa antes de slides, falsabilidad antes de optimismo. Sin esa disciplina, los agentes producen volumen sin dirección.

Walkthrough: facetas en el buscador SearchMO

Veamos un ejemplo sencillo de como funciona todo el flujo:

Volvamos al buscador de la tienda de Mercadona, ya que hemos observado que cuando un cliente busca “café” — query ambigua porque hay molido, en grano, soluble, descafeinado no tenemos forma de desambigüar si intención de búsqueda. En este caso trans toda la fase de research vemos que tiene sentido añadir facetas inline a nuestro buscador. — la app le ofrecerá chips de filtro debajo del search bar para que afine sin tener que escribir más.

El walkthrough completo está en el repo. Aquí cuento solo lo esencial.

Fase 1 — GSD: roadmap y especificación

El PM arranca con /gsd-new-project. La conversación produce:

.planning/
├── PROJECT.md          # contexto + core value + key decisions
├── REQUIREMENTS.md     # 16 REQ-IDs, v1 vs v2, out of scope
├── ROADMAP.md          # 3 fases con success criteria
└── phases/01-faceted-search/
    ├── SPEC.md         # 7 requirements falsables (current → target → acceptance)
    └── 01-01-PLAN.md   # tasks granulares por REQ-ID

Lo importante de los artefactos GSD: cada requirement tiene un acceptance criteria concreto y testeable. No es “mejorar la búsqueda”; es “test con 50 queries (25 ambiguas, 25 específicas) — clasificador acierta ≥90%”. Esto se traduce directamente a tests más adelante.

Fase 2 — Mercadona User Story Toolkit: del plan al backlog

El paso clave aquí es /from-gsd., el cual lee todo el contenido de .planning/ y produce un PRD sintético:

$ /from-gsd
✓ PRD sintético generado: prd-from-gsd.md
  Secciones rellenas desde GSD:    7
  Secciones marcadas como GAP:     7
  
  GAPs típicos a completar tras /research:
  - 1.2 Farolas (cuantitativo)
  - 1.3 Penumbras (cualitativo)
  - 2.2 Aspectos Financieros
  - 2.3 Métricas baseline → target
  - 3.5 FAQs

Aquí pasa algo importante. El PRD sintético es fiel pero incompleto. GSD captura roadmap, scope y specs falsables — eso se mapea bien al PRD. Pero GSD no captura métricas con baseline, citas literales de clientes, ni ROI estimado. Esos huecos se marcan como GAPs explícitos que el PM completa después del research, no antes. La skill se niega a inventar números. Si tu PRD generado dice [⚠️ Pendiente: definir métrica con datos reales] es porque GSD no sabe esa métrica y tú tampoco la has aportado todavía.

El PM completa los GAPs con /research, que diseña entrevistas Mom Test y, tras realizarlas, sintetiza JTBDs:

## JTBD-01: Refinar búsqueda ambigua sin esfuerzo extra

Job principal: Cuando busco un producto y la consulta es ambigua, quiero
refinar el resultado sin tener que pensar palabras adicionales, para llegar
al producto correcto sin perder tiempo ni frustrarme.

Evidencia cuantitativa: 12% queries ambiguas, 28% search abandon
(vs 16% en específicas), 4.2s tiempo a primer click (vs 2.1s).

Evidencia cualitativa: "Cuando busco 'café' me sale de todo y no sé cuál
pillar" — cliente recurrente, sesión de discovery 22-abr.

Confianza en el JTBD: Alta (5/5 entrevistas)

/stories convierte los JTBDs en user stories con scoring 6D, /validate-stories detecta antipatrones, /split-stories divide stories grandes, y /prioritize agrupa en batches anti-waterfall:

Batch 1 — Backend mínimo viable end-to-end (Stories 1+2)
Batch 2 — UI funcional con orden básico (Stories 3+4)  
Batch 3 — Telemetría y validación (Story 5)

Cada batch entrega valor por sí solo. El batch 1 (backend solo) ya permite validar el algoritmo via API antes de invertir en UI. El batch 3 cierra el loop de medición. Nada de “infra primero, valor al final”.

Fase 3 — Superpowers: ejecución TDD

El PM pasa el batch 1 al ingeniero, que arranca Superpowers con /superpowers:writing-plans. La skill lee las stories + los acceptance criteria del SPEC.md y produce un plan de implementación TDD: pasos, tests a escribir antes del código, criterios de verificación.

Después, /superpowers:test-driven-development ejecuta el ciclo rojo → verde → refactor en cada step:

# Test rojo
def test_query_with_high_dispersion_is_classified_ambiguous():
    top_k_results = [...]
    classifier = SearchClassifier(threshold=AmbiguityThreshold(3, 0.10))
    result = classifier.classify(top_k_results)
    assert result == QueryClassification.AMBIGUOUS

# Implementación mínima → test verde → refactor solo si emerge una smell

Para batches con tareas independientes, /superpowers:subagent-driven-development dispara subagentes en paralelo (un subagente para el clasificador, otro para el generador de facetas). Más rápido pero más caro en tokens — volveremos a eso.

Cada commit referencia el REQ-ID:

feat(search): implement DETECT-01 + DETECT-02 + DETECT-03 ambiguity classifier
feat(search): implement FACET-01 + FACET-02 facet generator
feat(search): implement FACET-03 + FACET-04 ordering by usage and frequency
feat(search): integrate facets into /search endpoint
test(search): add load test verifying p99 ≤195ms with facets enabled

Tests verdes, code review pasada, PR mergeada. El ingeniero ha terminado.

Y aquí es donde sin un puente, la cosa se rompe, veámoslo en siguiente sección.

El problema de orquestación

Este es el problema más subestimado de unir planning y ejecución con agentes con herramientas distintas como GSD y Superpowers, y el que más nos costó resolver.

Cuando GSD planifica pero Superpowers ejecuta, los artefactos de GSD se quedan obsoletos en cuanto los commits empiezan a entrar. STATE.md sigue diciendo “phase not started” cuando en realidad está casi terminada. ROADMAP.md muestra checkboxes vacíos cuando los REQ-IDs están terminados en código. PLAN.md no se actualiza. VERIFICATION.md nunca se genera.

Esto importa más de lo que parece. El seguimiento del desarrollo de cada funcionalidad se basa en el estado de GSD; si miente, el PM termianrá por no saber por donde va. La trazabilidad de auditoría se rompe — quién hizo qué y cuándo deja de ser reconstruible. Y cuando empieza la siguiente fase, los artefactos divergen tanto que ya nadie los actualiza, y el proyecto se queda con dos fuentes de verdad incompatibles: el código y los planes que describían el código que se iba a hacer.

Nuestra solución es un CLI standalone llamado gsd-bridge. ~250 líneas de Python, sin dependencias externas:

gsd-bridge sync           # auto-sync desde git: detecta REQ-IDs en commits y actualiza .planning/
gsd-bridge mark-done X-01 # marcar manualmente si los commits no referencian REQ-ID
gsd-bridge amend "razón"  # registrar drift de diseño en SPEC-AMENDMENTS.md

El convenio mínimo: incluir el REQ-ID en el commit message. El bridge detecta el patrón [A-Z]{2,8}-\d{1,4} (ej: AUTH-01, DETECT-12), busca en qué PLAN.md aparece, lo marca como [x], y si todos los REQs de una fase están done, cierra la fase en ROADMAP.md, genera VERIFICATION.md y añade una entrada de sync al inicio de STATE.md.

Para automatizarlo del todo, hay un hook de Claude Code que ejecuta gsd-bridge sync --quiet al final de cada conversación. Si hay .planning/ en el directorio, sincroniza; si no, no hace nada. El usuario no se entera.

Un ejemplo concreto de “spec drift”. El SPEC.md de la feature de facetas decía que el threshold de ambigüedad sería un valor numérico simple (min_categories: 3). Durante la implementación, el ingeniero descubrió que necesitaba dos parámetros para que la heurística funcionase bien (min_categories + min_weight). Cambió el código y los tests, pero el SPEC.md siguió diciendo “valor numérico simple”. Tres semanas después, otro PM lee el SPEC.md para entender el feature, ve “valor numérico simple” y pierde 40 minutos antes de mirar el código. Esto es spec drift y pasa siempre.

Una decisión clave: no tocar SPEC.md. Cuando la implementación cambia decisiones de diseño respecto al spec original (cosa que pasa siempre que el problema no es trivial), el bridge no reescribe SPEC.md. En su lugar, crea/anexa SPEC-AMENDMENTS.md con cada cambio. Esto preserva el trail histórico — el “qué decidimos” original sigue intacto, los “qué cambió y por qué” quedan registrados al lado. Si reescribiésemos SPEC.md, perderíamos la capacidad de auditar decisiones a posteriori.

Por qué Superpowers y no gsd-execute

GSD tiene su propio comando de ejecución, gsd-execute-phase. Funciona, y para muchos proyectos comunitarios encaja bien, de hecho es la forma de mantener todo el status del proyecto correctamente actualizado sin toda la parafernalia que he descrito en las secciones anteriores. Sin embargo a nosotros no nos sirve.

La razón es cultura de ingeniería. En Mercadona Tech, las prácticas de desarrollo no son negociables: TDD obligatorio en el código de producción, code review exigente, verificación de aceptación antes de mergear, separación clara entre tests unitarios e integración. Esto no es ideología — es lo que mantiene un sistema con decenas de servicios y 12 equipos sin que se caiga.

Cuando probamos gsd-execute-phase para implementar funcionalidades reales, el código que producía pasaba los tests que se le pedían pero no aguantaba bien una code review estricta. Faltaba disciplina TDD: el orden tendía a ser “implementar → escribir test → ajustar test hasta que pase”. Eso es prácticamente lo opuesto del TDD que queremos. El resultado era código frágil, con tests que validaban lo que el código hace en lugar de lo que debe hacer. Y eso degrada con el tiempo.

Superpowers, sin embargo, se alinea con nuestra cultura. Su skill test-driven-development exige el ciclo rojo-verde-refactor. Su verification-before-completion se niega a declarar “hecho” sin evidencia fresca de que los tests pasan. Su requesting-code-review activa un revisor automático antes de que el ingeniero diga “está terminado”. Cada una de estas disciplinas es opcional en otras herramientas; aquí están reforzada por la skill.

Esto no es decir que gsd-execute-phase sea malo. Es decir que no es la herramienta adecuada para nuestra cultura de ingeniería. Si tu equipo no es TDD-strict, GSD-execute puede serviros bien. Si lo eres, Superpowers encaja mejor.

El coste real: tokens

Si vas a probar este pipeline, tienes que conocer el coste. Esto no es barato.

Mis estimaciones aproximadas para una feature mid-size (3 stories, ~1.5 semanas de trabajo):

• GSD planning (project + phase + plan + research): ~50-100k tokens. Hay multi-agent (planner + plan-checker), por eso sube.

• Mercadona User Story Toolkit pipeline (prd-quality-guard → research → analyze → stories → validate → split → prioritize): ~60-120k tokens. Las skills tienen muchos checkpoints y leen referencias bajo demanda.

• Superpowers TDD subagent-driven: ~150-300k tokens. Aquí está el grueso. Cada subagente que lanzas es una conversación nueva con su propio contexto. Para una feature pequeña con 5-7 steps de TDD, llegas fácil a 200k.

Total por feature medium: 250-500k tokens. Con Claude Sonnet a precios actuales, son unos pocos dólares. Con Opus, más. Para un equipo que ejecuta varias features a la semana, el gasto no es despreciable.

¿Vale la pena? Honestamente, todavía no lo sé con números. Lo que tengo es la sensación de que el código sale más limpio y el rework baja, y eso compensa con creces el coste de tokens, por no hablar de que la velocidad del desarrollo se dispara entre un 5x y un 10x. Pero esa sensación necesita validación empírica que aún no hemos hecho.

Si tu equipo tiene presupuesto ajustado, dos consejos: (1) usa subagent-driven solo cuando las tareas sean realmente independientes — si fuerzas paralelización innecesaria, gastas el doble sin ganar tiempo; (2) deja Opus para los pasos críticos (writing-plans, refactor) y usa Sonnet para el grueso de TDD repetitivo.

Qué falla todavía

Llevamos unas pocas semanas usando esto. No todo funciona perfecto. Lo que aún nos duele:

1. La automatización del bridge tiene huecos. Si el ingeniero olvida poner el REQ-ID en el commit, el bridge no detecta nada y hay que hacer mark-done manual. Hemos pensado en un pre-commit hook que rechace commits sin REQ-ID, pero genera fricción y no siempre tiene sentido (commits de typo, bumps de dependencias). Decisión pendiente.

2. El handoff entre fases no es 100% automático. Cuando el PM termina con Mercadona User Story Toolkit y produce el batch priorizado, el ingeniero tiene que copiar las stories al input de /superpowers:writing-plans. Es un copy-paste de markdown — funciona, pero es manual, lo mismo que si te llevas las user stories a Jira y montas algo para que Superpowers las lea de ahí. Idealmente Superpowers debería leer directamente del output del toolkit, lo que implica cambios estructurales en la forma tradicional de trabajar apalancada en Jira.

3. El gasto en tokens sigue preocupándonos. Optimizaciones (cache, mezcla de modelos) en exploración — ver sección anterior, no es tontería a ver si va a salir el collar más caro que el perro.

4. Spec drift es real. Aunque el bridge registra amendments, en la práctica los ingenieros no siempre los registran al momento; lo hacen al final, retrospectivamente, y a veces se pierden detalles. Hace falta más disciplina o más automatización.

5. La curva de aprendizaje es alta. Las tres herramientas tienen su propia metodología (GSD = roadmap-driven, Mercadona User Story Toolkit = JTBD + Mom Test, Superpowers = TDD subagent-driven). Introducir a alguien al pipeline completo lleva tiempo. Los equipos que ya están cómodos con Jira + sprint planning tradicional pueden ver esto como overhead innecesario, y no voy a decir que no lo sea.

6. Mediremos pronto. Esto es lo más importante: medir bien el valor de todo este flujo sigue siendo trabajo pendiente. Necesitamos definir baselines (rate de bugs en producción antes y después del pipeline, time-to-PR-mergeada, % de stories que vuelven a abrirse por rework) y compararlas. Hasta que tengamos esos números, esto es una hipótesis razonable, no una verdad demostrada, no te fies por muy bien que suene todo lo que has leido aqui.

Liberación open-source

Hoy publicamos el toolkit en un repo público para que cualquier equipo lo pruebe, esta es una cuenta pendiente que tenía con vosotros desde que os hablé del Mercadona User Story Toolkit:

Repo: github.com/josemerca/mercadona-user-story-toolkit — Licencia MIT.

Incluye:

• 8 skills del Mercadona User Story Toolkit (prd-quality-guard, gsd-to-prd, research-from-prd, jtbd-to-stories, user-story-builder, user-story-quality-coach, story-splitting, story-prioritization)

• 11 comandos de slash para Claude Code

• bridge/gsd-bridge.py — el CLI de sincronización GSD↔ejecutor, con README e hook de ejemplo

• examples/searchmo-facets/ — el walkthrough completo del feature contado en este artículo, con todos los artefactos al desnudo

• README + CONTRIBUTING + LICENSE MIT

Las dos herramientas que lo orquestan también son públicas:

• GSD: github.com/gsd-build/get-shit-done — meta-prompting + spec-driven development.

• Superpowers: github.com/obra/superpowers — agentic skills framework.

A ambos equipos, gracias. Sin sus herramientas no existiría este pipeline.

Millones de gracias al equipo de Producto e Ingeniería de Mercadona Tech que están probando todo este flujo y sin cuyas ideas todo este trabajo sería imposible, aunque lo que leéis aquí lo escriba yo (bueno en realidad lo escribe Claude 😂) muchas de las ideas surgen de mi equipo y no sería justo apropiarme de ellas, todo lo que leéis aquí ha surgido del equipo de Mercadona Tech, no de Jose Ramón Pérez Agüera.

Lo que pido: prueba el flujo en un proyecto real. Si te encaja, escríbeme. Si no te encaja, escríbeme también — quiero saber qué falla en otros contextos. Si encuentras bugs, abre issue. Si tienes una idea para mejorarlo, manda PR.

Esto está en versión 0.1. Vamos a iterarlo entre todos.

Cierre

El argumento de fondo de toda la serie Desarrollo de productos con agentes es que estamos en un momento bisagra. Las herramientas individuales (Claude Code, Cursor, Copilot, Superpowers) están bien. Las metodologías (vibe coding, spec-driven development) también. Lo que falta es estandarizar cómo se conectan entre sí para producir un flujo coherente desde la idea de producto hasta la PR mergeada.

Este pipeline es una propuesta. Probablemente no la mejor. Probablemente no la final. Pero es una concreta, ejecutable, y abierta para que tú la mejores.

¿Cómo lo estáis haciendo vosotros? ¿Qué herramientas os están funcionando para conectar producto e ingeniería en la era de los agentes? ¿Dónde se os rompe el flujo?

Lee, prueba, rompe, comparte.

Este es el cuarto artículo de la serie Desarrollo de productos con agentes. Anteriores:

• Vibe coding: ¿revolución o espejismo? (14 abril)

• Después del vibe coding: spec-driven development con GSD y Superpowers (20 abril)

• Cómo construimos nuestro buscador en Mercadona Tech (y cómo construir el tuyo) (27 abril)

No esperaba la reacción. Decenas de mensajes pidiendo detalles. Empresas pequeñas y grandes preguntando cómo lo habíamos hecho. Equipos de ingeniería contando que llevaban meses pensando en algo parecido pero no sabían por dónde empezar. Personas no técnicas queriendo entender qué hay realmente detrás de un buscador moderno.

Este artículo es la respuesta a todas esas preguntas. Y al final hay un fichero descargable que puedes darle a Claude Code para empezar tu propio proyecto siguiendo el mismo método.

Por qué lo cuento todo

En Mercadona tenemos un Modelo que se llama Calidad Total. No es un documento ni un manual: es el sistema que guía las decisiones de todos los que trabajamos en la compañía, desde la persona que repone en una tienda hasta el comité de dirección. Cuando hay que elegir entre dos caminos, el Modelo te dice cuál respeta lo que debe respetarse, y en qué orden.

El Modelo de Mercadona identifica cinco componentes a los que la empresa tiene que satisfacer simultáneamente, y lo hace en un orden concreto: primero El Jefe —que es como llamamos al cliente en Mercadona—, después el Trabajador, después el Proveedor, después la Sociedad y, finalmente, el Capital. Los cinco a la vez, pero con esa secuencia de prioridad. La frase que se repite internamente es que “para que el avión vuele, tienen que cumplirse todas las leyes de la física al mismo tiempo”: atender a todos, sin perder el orden.

El componente que me interesa hoy es el cuarto: la Sociedad. Las personas, entidades y lugares que rodean a la empresa. Juan Roig lo resume con una frase que cualquiera que trabaje cerca le ha oído alguna vez: mi sueño es compartir el modelo. Si alguien aprende a hacer las cosas bien, hay emprendedores. Si hay emprendedores, hay empresas. Si hay empresas, hay empleo. Si hay empleo, hay riqueza. Si hay riqueza bien gestionada, hay bienestar.

Compartir lo que aprendemos es, dentro del Modelo de Mercadona, una de las formas naturales de cumplir con el componente Sociedad.

Por eso este artículo no se queda en la anécdota. Voy a contar exactamente cómo está construido nuestro buscador: qué algoritmos lo componen, qué decisiones tomamos en cada capa, por qué descartamos algunas alternativas que parecían obvias, qué reglas de gobernanza aplicamos al modelo de aprendizaje, y qué stack abierto puede reproducirlo. Y voy a entregar al final un playbook descargable para que cualquier equipo, sin importar su tamaño, pueda usarlo como punto de partida.

Si lo que cuento sirve para que un equipo de tres personas en cualquier sitio reemplace un buscador caro por uno propio, mejor, y más controlable, este artículo habrá cumplido su función.

A quién le sirve esto

Antes de entrar en detalle, conviene aclarar para quién es útil lo que viene a continuación.

Este artículo está pensado para dos lectores muy distintos a la vez. El primero es alguien sin formación técnica que quiere entender realmente cómo funciona un buscador moderno: por qué a veces encuentra lo que busca y por qué otras veces no, qué está pasando cuando un sistema “aprende” de los clics, por qué unas tiendas online tienen buscadores que parecen leerte la mente y otras te muestran resultados absurdos. Para este lector, voy a explicar cada concepto antes de usarlo y a evitar la jerga gratuita.

El segundo lector es alguien técnico que quiere replicar el sistema. Para ese lector, voy a dar el detalle suficiente para que el playbook final tenga sentido: nombres concretos de algoritmos, parámetros, decisiones de validación, métricas. No voy a esconder nada relevante por miedo a que el artículo parezca denso.

Mi apuesta es que ambos lectores pueden convivir en el mismo texto si la estructura está bien. La parte técnica explica el porqué. La parte conceptual explica el qué. Y las dos juntas dan la única respuesta honesta a ¿cómo se hace un buscador?: no hay una respuesta corta, pero tampoco es magia.

Por qué un buscador propio

En una tienda online, el buscador es la puerta principal. La gente no navega catálogos cuando ya sabe lo que quiere: escribe el nombre y espera que aparezca. Si no aparece, se va. No reformula, no explora, no vuelve a probar dos veces. Se va.

En nuestra tienda online, el buscador maneja 4,4 millones de búsquedas a la semana. Si el 4% no devuelve resultados, hablamos de unos 176.000 usuarios a la semana que escriben algo razonable y no encuentran nada. Eso era exactamente lo que nos pasaba. Y era lo más educado que podía pasar: el resto de búsquedas, las que sí devolvían resultados, también podían ser mejores. Solo que ahí no teníamos un número rojo que nos avisara.

El problema con un buscador estándar —cualquier buscador estándar, sea un SaaS o el motor que viene con el e-commerce— es que está diseñado para ser bueno con cualquier catálogo. Eso suena bien hasta que recuerdas que tu catálogo no es cualquier catálogo. Tus usuarios no escriben como los de cualquier otra tienda. Tu negocio no premia los mismos resultados que el de tu competidor. Y, sobre todo, tienes datos de comportamiento real —qué buscan, qué clican, qué compran— que un buscador genérico no puede aprovechar bien porque no son suyos.

Construir el tuyo te da tres cosas concretas. La primera es control sobre el ranking: tú decides qué señales pesan más, cómo se ponderan, qué hacer con productos que aparecen mucho pero se compran poco, qué hacer con productos nuevos que todavía no tienen historial. La segunda es mejora dirigida: cada decisión que tomas se mide contra los datos reales de tu negocio, no contra un benchmark sintético. Si una decisión mejora un 1% el ranking de tu catálogo, te lo llevas tú. La tercera es propiedad de la pieza: una de las decisiones más críticas del negocio deja de depender de un proveedor externo y pasa a ser conocimiento que se queda dentro del equipo.

Hay una cuarta razón, menos romántica pero igual de relevante: el coste. Un buscador SaaS razonablemente serio cuesta varios miles de dólares al mes para un volumen como el nuestro. Un buscador propio bien diseñado cuesta una fracción. Eso no es razón suficiente por sí sola —si gastando dinero compras calidad, gasta dinero—, pero cuando construyendo el tuyo *además* mejoras la calidad, el cálculo deja de ser una decisión y se convierte en una conclusión.

Decidimos construir el nuestro. Lo que viene a continuación es exactamente cómo lo hicimos.

La arquitectura, en una página

Antes de entrar en cada componente, conviene tener una imagen mental. Un buscador moderno parece complejo, pero no lo es tanto si lo ves como un proceso de cuatro pasos.

Imagina que entras en una librería gigantesca con un papel donde has escrito tres palabras del libro que buscas. Para encontrarlo mandas a dos personas. La primera busca todos los libros cuyo título contenga literalmente esas tres palabras. La segunda busca libros que, aunque no usen exactamente esas palabras, traten del mismo tema. Vuelven las dos con su lista. Tú las cruzas, descartas los libros que no estén en esa librería concreta, y un experto en el catálogo te ordena lo que queda según lo que sabe del negocio: qué libros se prestan más, cuáles son recientes, cuáles encajan mejor con tu petición. Lo que tú ves es la lista final.

Eso es, casi literalmente, lo que hace un buscador como el nuestro. Cambia “libros” por “productos”, “dos personas” por “dos algoritmos de búsqueda” y “experto en el catálogo” por “modelo de aprendizaje”, y tienes toda la arquitectura.

Veamos las piezas.

1. Normalizar la consulta

Cuando alguien escribe “Café Molido”, el sistema convierte ese texto en su forma canónica: minúsculas, sin acentos, separado en palabras. “Café Molido” pasa a ser una lista con dos elementos: “cafe” y “molido”. La regla de oro: la normalización al consultar tiene que ser **exactamente la misma** que la normalización al indexar el catálogo. Si lo indexas con acento y lo buscas sin acento, no hay match. En nuestro catálogo descubrimos que el 100% de los usuarios escribe sin acentos: eso decidió la convención.

2. Dos búsquedas en paralelo

Sobre la consulta normalizada, el sistema lanza dos búsquedas simultáneas.

La primera es **léxica**: busca productos cuyo nombre, marca o descripción contenga literalmente las palabras del usuario. Si escribes “leche”, encuentra productos con “leche” en alguna parte. Lo hace con **BM25**, un algoritmo clásico que puntúa cada producto según cuántas veces aparece la palabra y lo rara que es esa palabra en el catálogo (las palabras raras puntúan más). Corre sobre **Tantivy**, un motor escrito en Rust, embebido en el servicio, sin clúster aparte. Devuelve los 100 mejores candidatos.

La segunda es **semántica**: convierte la consulta en un vector de 384 números que representa su “significado” y busca, en una matriz precomputada de todos los productos, cuáles son más parecidos en ese espacio. Encuentra cosas que la primera no encuentra: si buscas “para fregar”, puede traerte “estropajo” aunque no contenga la palabra “fregar”. El modelo que genera los vectores se llama **e5-small** —abierto, multilingüe, ligero— y lo ejecutamos como ONNX INT8, una versión optimizada que cabe en 6 MB de memoria y responde en milisegundos sin tarjeta gráfica. Devuelve los 50 mejores candidatos.

3. Fusionar las dos listas

Tenemos dos listas con candidatos que a veces se solapan y a veces no. La técnica que usamos para combinarlas se llama **Reciprocal Rank Fusion**: cada producto recibe puntos inversamente proporcionales a su posición en cada lista. Si aparece el 1º en una y el 5º en la otra, suma por ambas. Si solo aparece en una, suma por una. Es robusta y no requiere calibrar pesos: solo usa posiciones, no puntuaciones absolutas, lo que la hace ciega al hecho de que BM25 y similitud semántica viven en escalas distintas.

Tras la fusión queda una lista de unos 60 candidatos. A continuación se aplica un filtro: descartar los productos que no estén en el surtido de la tienda concreta del usuario. Cómo hacemos ese filtro de forma eficiente es una decisión interesante por sí misma — la cuento en la siguiente sección.

4. Reordenar con aprendizaje automático

Los 60 candidatos que quedan están razonablemente filtrados, pero no están bien ordenados. Decidir qué producto va arriba requiere algo más que las puntuaciones anteriores: requiere un modelo entrenado con datos reales del negocio.

Ese modelo se llama Learning To Rank. En nuestro caso es CatBoost YetiRank, un algoritmo basado en árboles de decisión optimizado para problemas de ordenación. Recibe los 60 candidatos junto con 14 características de cada uno —su puntuación BM25, su parecido semántico, cuántas veces se ha comprado en las últimas semanas, lo popular que es entre clientes habituales, si lleva poco tiempo en el catálogo— y produce el orden final. Tarda menos de un milisegundo en hacerlo.

A todo esto le acompaña una pieza separada: el autocompletado, las sugerencias que aparecen mientras el usuario escribe. Esto no es una búsqueda completa: es un Trie (un árbol de prefijos) que devuelve, en microsegundos, productos cuyo nombre empieza por lo que llevas escrito. Tres señales para ordenar las sugerencias: en qué campo aparece el match, si coincide la palabra entera o solo el prefijo, y la posición dentro del nombre.

El presupuesto total

Todas las piezas se ejecutan en un tiempo casi imperceptible: menos de 15 milisegundos en el 99% de las consultas. En la práctica nuestra mediana es de 12 ms. Parpadear tarda unos 300 ms — el buscador entero responde unas 20 veces más rápido que un parpadeo. Cada componente tiene su sub-presupuesto, y si alguno se pasa, el sistema deja de responder a tiempo y la experiencia se degrada. Esa restricción estructura las decisiones que vienen a continuación.

Cinco decisiones que separan un prototipo de un buscador real

Las decisiones que vienen a continuación son las que más nos costó tomar y las que más diferencia hicieron. Cada una es independiente: pueden adoptarse por separado en cualquier proyecto. Y cada una responde a una alternativa que parecía obvia al principio y resultó equivocada al final.

1. Búsqueda híbrida: ninguna de las dos por separado funciona

La tentación inicial es elegir uno: o lexical, o semántico. La búsqueda lexical es rápida, predecible y barata. La semántica es lista, encuentra sinónimos y maneja preguntas en lenguaje natural. ¿Por qué hacer las dos?

Porque por separado son malas. Si solo usas lexical, el 33% de las consultas no devuelven resultados: alguien escribe “para fregar”, no aparece la palabra “fregar” en ningún producto, y el sistema se rinde. Si solo usas semántica, todo encuentra algo, pero ese “algo” es a menudo ruido: el modelo cree que “agua mineral” se parece a “agua oxigenada” y te las mezcla en el ranking.

Las dos juntas se complementan. La semántica garantiza recall (que siempre haya candidatos) y la lexical garantiza precisión (que los candidatos obvios estén ahí). En nuestros datos, el recall@50 sube de 0,547 (solo lexical) a 0,853 (híbrido). El porcentaje de búsquedas sin resultados pasa del 33% al 0%. Y luego, sobre las dos listas combinadas, el modelo de aprendizaje hace de juez final: aprende de los clics qué resultados son realmente buenos y qué resultados, aunque parezcan relevantes, los usuarios ignoran.

Cómo decidirla en tu caso: si tu catálogo tiene vocabulario abierto, queries en lenguaje natural o sinónimos relevantes, necesitas la capa semántica. Si tu catálogo es pequeño y los usuarios escriben siempre con el vocabulario del catálogo, quizá puedas empezar solo con lexical y añadir la semántica después. Pero la mayoría de catálogos reales necesitan ambas.

2. Un solo índice maestro con bitsets, no un índice por tienda

El surtido de productos cambia de una tienda a otra: no todas las tiendas tienen los mismos productos en stock. La forma ingenua de manejar esto es construir un índice de búsqueda independiente para cada tienda. En nuestro caso, eso son 762 índices, replicarlos para distintos órdenes de resultados, mantenerlos actualizados, reindexar uno cada vez que cambia un surtido.

La alternativa que adoptamos: un solo índice maestro con todo el catálogo, y para cada tienda mantenemos un **bitset** —un mapa de bits, un array binario donde cada bit representa “este producto está disponible aquí, sí o no”—. Cuando alguien busca desde una tienda, ejecutamos la búsqueda contra el índice maestro y filtramos el resultado haciendo una operación AND entre los IDs de los productos encontrados y el bitset de su tienda.

Las cifras hablan solas: 254 bitsets, cada uno de 813 bytes, suman **200 KB en total**. Una operación AND sobre un bitset es cuestión de microsegundos. Actualizar un surtido es sustituir un bitset entero, otra operación trivial. Comparado con mantener 762 índices físicamente separados, multiplicas por mil la simplicidad operativa y por mil el ahorro de almacenamiento.

Cómo decidirla en tu caso: siempre que tengas multi-tenancy con catálogos solapado —tiendas, marcas, regiones, idiomas— el patrón “índice maestro + bitset por tenant” gana. La regla es: ¿la mayoría del catálogo es común a todos los tenants? Sí → bitsets. ¿Cada tenant tiene un catálogo radicalmente distinto? Entonces sí, índices separados.

3. Validación walk-forward: nunca mezcles clics al azar

Cuando entrenas un modelo de ranking, necesitas separar tus datos en entrenamiento y test. La forma estándar en machine learning es coger todos los datos, mezclarlos al azar, y reservar el 20% para test. Esto se llama validación cruzada aleatoria (random k-fold).

En un buscador esto está mal. Los clics tienen estructura temporal: estacionalidad, lanzamientos de producto, campañas internas, días con más tráfico que otros. Si mezclas clics aleatoriamente, mezclas pasado y futuro, y el modelo “aprende” cosas que en producción no podría haber sabido. El resultado son métricas infladas: tu modelo parece haber mejorado un 5-10% más de lo que realmente mejorará en producción.

La alternativa correcta se llama **walk-forward**: entrenas con las semanas 1, 2 y 3, validas con la semana 4. Después puedes deslizar la ventana: entrenas con 2, 3 y 4, validas con 5. Y así. El modelo siempre se evalúa contra un futuro real, no contra un futuro que ya conoce.

Cómo decidirla en tu caso: cuando los datos tengan dimensión temporal —y en un buscador siempre la tienen—, walk-forward es obligatorio. No es opcional. Es una de esas decisiones que parecen un detalle metodológico y son, en realidad, la diferencia entre desplegar un modelo que mejora la métrica de negocio y desplegar uno que la degrada.

4. Corregir el sesgo de posición: clics no es lo mismo que relevancia

Hay un problema sutil con entrenar un modelo a partir de los clics de los usuarios: los usuarios clican más los primeros resultados independientemente de si son relevantes o no. Hay estudios serios sobre esto: el primer resultado se clica unas seis veces más que el quinto, aunque el quinto sea exactamente igual de bueno. Si entrenas un modelo asumiendo que “clic = relevante”, el modelo aprende a poner siempre arriba los productos que ya estaban arriba. Tu modelo se refuerza a sí mismo, los productos del top dominan, los productos buenos pero menos visibles nunca emergen, la diversidad del catálogo colapsa, y la calidad cae sin que te des cuenta. Esto se llama feedback loop o Relevance Feedback para los padres de la Recuperación de Información.

La corrección estándar se llama Inverse Propensity Weighting (IPW): a cada clic le das un peso inversamente proporcional a la posición en la que apareció. La fórmula que usamos es 1 dividido entre el logaritmo en base 2 de la posición más uno. Un clic en la posición 1 cuenta poco; un clic en la posición 8 cuenta mucho más, porque el usuario tuvo que ignorar siete resultados antes de llegar a él. Eso sí es una señal fuerte de relevancia.

Y lo complementamos con exploración: en el 5% de las búsquedas, el sistema mete deliberadamente 2-3 resultados aleatorios en las posiciones 3, 5 y 7. Suena raro pero es necesario: sin exploración, los productos nuevos nunca reciben clics y se quedan atrapados abajo para siempre. El 5% es un coste tolerable para evitar un equilibrio subóptimo permanente.

Cómo decidirla en tu caso: si tu modelo aprende de clics, IPW es obligatorio y exploración también. No hay alternativa razonable.

5. Guardrail del −2%: ningún modelo peor pasa, automáticamente

Reentrenar un modelo cada semana suena bien, hasta que un día el reentrenamiento produce un modelo peor. Si lo despliegas sin más, los usuarios siguen buscando, los clics siguen llegando —porque no tienen alternativa— y tu siguiente reentrenamiento se hace con datos sesgados por un modelo malo. La degradación es invisible y se acumula.

La defensa que aplicamos es un guardrail automático: el pipeline de reentrenamiento solo despliega un modelo si **ninguna de cuatro métricas cae más de un 2%** respecto al modelo en producción. Las cuatro métricas son MRR y NDCG, evaluadas tanto sobre el conjunto de test temporal (walk-forward) como sobre un golden set estático de 500 consultas con la respuesta ideal anotada manualmente. El golden set no se modifica nunca: es la única referencia inmune al feedback loop.

El pipeline produce tres decisiones posibles. **PROMOTE** si el candidato mejora más de un 0,5%. **HOLD** si está en el rango neutro entre −2% y +0,5% (queda en cuarentena, no se despliega). **REJECT** si cae más de un 2%. Y aún en el caso de PROMOTE, el despliegue real espera una hora antes de activarse, durante la cual cualquier persona del equipo puede abortarlo. Es el último gate humano.

Cómo decidirla en tu caso: si despliegas modelos de forma automática, necesitas un guardrail. El umbral exacto depende de tu sensibilidad: un −2% es estricto pero adecuado para un buscador con tráfico crítico. Para un sistema con menos riesgo puedes usar −5%. Pero el patrón —reglas automáticas + métrica independiente del propio sistema (golden set) + ventana humana antes del deploy— es universal.

El stack (todo abierto, todo replicable)

Una de las cosas que más sorprende al construir esto es lo poco exótico que es el stack. No hay tarjetas gráficas dedicadas, no hay bases de datos vectoriales, no hay servicios externos de cobro. Todo lo que viene a continuación es código abierto, cabe en un repositorio Python, y se ejecuta sobre máquinas estándar.

El motor lexical: Tantivy

Para la búsqueda por palabras clave usamos Tantivy, una librería escrita en Rust inspirada en Apache Lucene (La madre de todos los motores de búsqueda que ves hoy en día creado por Doug Cutting hace más de 25 años en Xerox Park). Lo más importante de Tantivy no es el rendimiento (que es excelente: respuestas en milisegundos sobre catálogos de miles de productos), sino que se ejecuta dentro del propio servicio. No hay un clúster aparte, no hay servidores de búsqueda dedicados, no hay JVM que mantener. El índice ocupa unos 20 MB de memoria y vive en el mismo proceso que el resto del código.

Tantivy soporta de forma nativa lo que necesitas para un buscador real: tokenización configurable, búsqueda por prefijos para el autocompletado, *facetas* para filtros (por categoría, marca, etc.), y *highlighting* de los términos coincidentes. La alternativa habitual —Elasticsearch o OpenSearch— está pensada para catálogos del tamaño de los de Wikipedia: si tu catálogo tiene menos de 100.000 documentos, Tantivy es probablemente la elección correcta.

El modelo semántico: e5-small ejecutado con ONNX Runtime

Para la capa semántica usamos un modelo de embeddings abierto llamado multilingual-e5-small, publicado por Microsoft Research. “Small” significa que el modelo tiene unos 118 millones de parámetros: pequeño en términos de modelos modernos, pero más que suficiente para nombres de producto cortos. Genera vectores de 384 dimensiones por consulta y por documento.

Ejecutar este modelo en su forma original (PyTorch) tarda unos 20 ms por consulta en CPU. Demasiado para nuestro presupuesto de latencia. La solución estándar es convertirlo al formato ONNX (Open Neural Network Exchange) y ejecutarlo con ONNX Runtime, una librería de inferencia muy optimizada. Con la cuantización a enteros de 8 bits (INT8) —una técnica que reduce la precisión numérica a cambio de un 4× de velocidad sin pérdida medible de calidad— el modelo pasa a ocupar unos 118 MB en memoria y devuelve un vector en 3–5 ms en una CPU normal1.

No hace falta GPU, no hace falta una base de datos vectorial. La matriz completa de embeddings de todo el catálogo —unos 4.300 productos por 384 dimensiones— ocupa 6 MB en RAM. La búsqueda por similitud es una multiplicación de matriz NumPy y un argsort: 1 ms para todos los productos.

El modelo de ranking: CatBoost YetiRank

El re-ranking final lo hace CatBoost, una librería de gradient boosting publicada como código abierto por Yandex. Lo elegimos tras una competición interna entre cinco algoritmos: CatBoost YetiRank, XGBoost, LightGBM con LambdaRank, una baseline Pointwise y una Listwise. CatBoost YetiRank ganó con menor varianza entre folds (MRR 0,867 ± 0,014) y con la mejor inferencia: el modelo entrenado pesa unos 5 MB y predice el orden de 60 candidatos en menos de un milisegundo.

YetiRank es la función de pérdida específica para problemas de ordenación que CatBoost incorpora: en lugar de optimizar la predicción de un valor (regresión) o una clase (clasificación), optimiza directamente el orden relativo entre documentos para una misma consulta. Es lo correcto técnicamente para learning-to-rank y, en nuestra competición, fue también lo correcto empíricamente.

El autocompletado: un Trie

El autocompletado no usa el motor de búsqueda. Usa una estructura de datos clásica llamada Trie (un árbol de prefijos), donde cada nodo representa una letra y cada camino desde la raíz hasta una hoja es un prefijo de una palabra del catálogo. Para encontrar las sugerencias de “atu”, recorres tres pasos en el árbol y devuelves todas las palabras que cuelgan de ahí.

La búsqueda en un Trie es del orden de microsegundos, no milisegundos. En nuestro caso, p50 = 3 microsegundos, p99 = 388 microsegundos. Eso permite responder a cada tecla que el usuario pulsa sin que la red sea el cuello de botella.

El resto: Python, NumPy, scikit-learn

El pegamento que une todas estas piezas es Python. La capa de servicio recibe la consulta, llama a Tantivy, llama al runtime ONNX para el embedding, hace el merge RRF con NumPy, aplica el bitset de la tienda, calcula las 14 features de los candidatos restantes, llama a CatBoost para el ranking final, y serializa el resultado. Toda la lógica matemática descansa en NumPy, y scikit-learn se usa solo durante el entrenamiento offline (split de datos, métricas, baselines).

No hay nada en este stack que no puedas instalar con un pip install o un cargo add. No hay licencias propietarias, no hay servicios externos de cobro recurrente, no hay infraestructura especializada. Esa es deliberadamente la apuesta: si la infraestructura es estándar, el conocimiento que generes es portable, y la pieza queda dentro del equipo.

Resumen de dependencias

- Búsqueda lexica: **Tantivy** (Rust, licencia MIT)

- Embeddings: **multilingual-e5-small** (MIT)

- Inferencia de embeddings: **ONNX Runtime** (MIT)

- Ranker: CatBoost (Apache 2.0)

- Pegamento: **Python + NumPy + scikit-learn** (BSD)

- Almacenamiento de matrices: NumPy en RAM, sin base de datos vectorial

Todo esto cabe en un proceso del orden de 100 MB de RAM (modelo + índice + matriz de embeddings + runtime). Una máquina modesta lo ejecuta sin despeinarse.

El workflow: cómo se trabaja con Claude Code en un proyecto así

He escrito ya, en artículos anteriores, sobre cómo cambia el trabajo cuando una parte del equipo lo hace conversando con un agente de IA. No voy a repetir aquí ese debate. Voy a contar, en concreto, cómo se distribuyó el trabajo en este proyecto, porque creo que es la parte más útil para alguien que quiera replicarlo.

El reparto: humano decide, agente ejecuta

La regla mental que aplicamos es simple. Todo lo que sea explorar —analizar datos, probar configuraciones, comparar alternativas, escribir scripts de evaluación, generar tablas— lo hace el agente. Todo lo que sea decidir —qué arquitectura adoptar, qué validación usar, qué guardrails poner, qué descartar— lo hacen las personas.

Esa distinción importa porque las dos partes son del mismo trabajo. Sin la exploración masiva, las decisiones se toman a ciegas. Sin las decisiones, la exploración se vuelve una pila de experimentos sin convergencia. La velocidad del agente es lo que permite explorar 175 configuraciones de BM25 en lugar de 5, comparar 3 modelos de embeddings en lugar de quedarse con el primero que funciona, y validar el ranker contra una competición de 5 algoritmos en lugar de adoptar el de moda. Es lo que convierte “una decisión basada en intuición” en “una decisión basada en datos reales del catálogo”.

Las cuatro fases del proyecto

El proyecto avanzó en cuatro fases bien delimitadas, cada una con un experimento canónico, un fichero de evaluación versionado y una decisión documentada al final.

Fase 0: exploración de datos. Empezamos sin escribir una sola línea de código de producto. Conectamos al agente los 479 MB de datos del catálogo, las analíticas, las consultas reales y los datos de compras, y le pedimos que respondiera preguntas concretas: ¿cuántas palabras tiene una consulta media?, ¿qué porcentaje contiene tildes?, ¿qué vocabulario aparece y con qué frecuencia? Aprendimos cosas que cambiaron decisiones posteriores: el 93,7% de las consultas tienen una sola palabra, el 100% se escriben sin acentos, el vocabulario activo son unos 1.300 términos. Sin estos datos, habríamos optimizado el sistema para problemas que no teníamos.

Fase 1: baseline lexico. Antes de complicarse, hay que tener un baseline. El agente probó 175 configuraciones de BM25 en una *grid search*. El ganador resultó ser BM25 con k1=0,5 y b=0 — ese cero en b es importante: significa no normalizar por longitud del documento, contraintuitivo en un buscador típico, pero correcto en un catálogo donde los nombres de producto son cortos y uniformes. Esto solo se descubre probando.

Fase 2: capa semántica. Con el baseline encima de la mesa, el agente comparó tres modelos de embeddings. e5-small ganó por equilibrio entre calidad y velocidad. Lo más interesante de esta fase no fue ganar un punto de MRR, sino constatar que la búsqueda semántica por sí sola produce demasiado ruido, y que la idea correcta era combinarla con la lexical, no sustituirla.

Fase 3: Learning To Rank. La que más tiempo nos llevó. Cinco modelos, validación cruzada con cinco particiones temporales, comparación de features, análisis de importancias. La decisión final —CatBoost YetiRank con 14 features— es producto de un experimento controlado, no de una intuición. La importancia de cada feature se midió: popularidad 37,5%, embeddings 29,8%, BM25 12,9%. Saber esto no fue accesorio: nos dio confianza para defender decisiones más adelante, por ejemplo descartar reglas manuales que solo replicaban señales que el modelo ya estaba capturando.

Fase 4: personalización. Aquí aprendimos negativamente. Probamos features personalizadas (afinidad por categoría, si el usuario es habitual). Su importancia offline resultó ser del 0%. La conclusión no fue “la personalización no funciona”, fue “no podemos validarla offline sin un mapeo consulta-usuario que no tenemos”. La decisión: aplazarla para test A/B en producción. A veces, el resultado más útil de una fase es saber que la fase no estaba lista.

El truco que sostiene todo: un CLAUDE.md no negociable

Si hay un solo elemento del que depende que este método funcione, es el fichero de reglas que vive en la raíz del proyecto y que el agente lee al principio de cada sesión. Lo llamamos CLAUDE.md. No es documentación; son restricciones.

Las reglas se dividen en cinco bloques: presupuestos de latencia (cada componente con su milisegundo máximo), reglas de arquitectura (qué algoritmos no se sustituyen sin proceso explícito), reglas de aprendizaje automático (IPW, walk-forward, golden set, guardrails), reglas de integración continua (qué tests bloquean un merge), y reglas de despliegue. Cada regla viene con su justificación —el porqué— y la consecuencia de violarla. Si el agente, en una sesión cualquiera, sugiere algo que viola una regla, hay un mecanismo de bloqueo que lo detiene antes de que entre al repositorio.

Este fichero es el conocimiento estable del proyecto. Es donde vive lo que hemos aprendido y no queremos volver a aprender. Es lo que se queda cuando el agente de IA cambia de versión, cuando el equipo rota, cuando el contexto de una conversación se corta. Es, literalmente, el componente que hace que un proyecto construido con vibe coding sea un proyecto, y no una colección de scripts que funcionaron una vez.

Y es, precisamente, lo que viene a continuación: el playbook completo en formato CLAUDE.md que puedes descargar y usar como punto de partida para tu propio buscador.

El playbook que liberamos

Al pie de este artículo encontrarás un fichero descargable: **searchmo-playbook.md**. No es un manifiesto ni una guía teórica. Es la misma plantilla de reglas que rige nuestro propio buscador, generalizada para que cualquiera pueda darle uso.

¿Qué contiene?

El fichero tiene cuatro bloques:

Reglas no negociables. Las restricciones que rigen el proyecto y que un agente de IA no puede violar sin proceso explícito. Incluye los presupuestos de latencia por componente (15 ms en total, distribuidos), las decisiones de arquitectura (no usar base de datos vectorial, no clúster externo, índice maestro con bitsets) y las reglas de aprendizaje automático (IPW obligatorio, walk-forward obligatorio, golden set obligatorio, guardrail −2%).

Las cuatro fases del proyecto. El orden en el que avanzar, con un objetivo medible al final de cada una. Fase 0: caracterización del catálogo y las consultas. Fase 1: baseline lexical con grid search. Fase 2: capa semántica con comparación de modelos. Fase 3: learning-to-rank con competición de algoritmos. Cada fase incluye prompts sugeridos para Claude Code: cómo pedirle que ejecute el grid search, cómo pedirle que monte el comparador de embeddings, cómo pedirle que entrene los cinco modelos de ranking.

Checklist de las cinco decisiones algorítmicas. Para cada una, los criterios que te ayudan a decidir cómo aplicarla en tu caso concreto. Si tu catálogo tiene tales características, decisión X. Si no, decisión Y.

Stack mínimo. Las dependencias concretas, con versiones probadas. Tantivy, multilingual-e5-small, ONNX Runtime, CatBoost, Python, NumPy, scikit-learn. Todo abierto, todo replicable.

¿Cómo usarlo?

1. Descarga el fichero y guárdalo como CLAUDE.md en la raíz de un repositorio nuevo.

2. Abre Claude Code en ese directorio.

3. Pídele que lea las reglas y empiece por la Fase 0.

4. A partir de ahí, trabajas conversación por conversación, fase por fase, con el agente ejecutando los experimentos y tú tomando las decisiones al final de cada uno.

El proceso completo nos llevó un mes, pero el 70% del trabajo —exploración de datos, baseline lexical, capa semántica y primera versión del ranker— se hizo en un fin de semana largo. El resto del mes fue refinamiento: gobernanza del modelo, golden set, pipeline de reentrenamiento y guardrails. No es un proyecto de un fin de semana en el sentido amateur del término. Pero tampoco un proyecto que requiera un equipo de quince personas: es un proyecto que un par de personas con criterio y un agente de IA pueden afrontar.

Lo que el playbook no resuelve por ti

Hay tres cosas que el fichero no puede resolver, y conviene saberlo antes de empezar.

Tu catálogo.El playbook describe el método. Los datos de tu catálogo son tuyos: qué productos tienes, cómo los describes, qué señales de comportamiento tienes registradas. Cuanta más calidad tengan estos datos —especialmente el log de clics— más rápido converge el sistema.

Tu juicio. Las cinco decisiones algorítmicas tienen un porqué; ese porqué se aplica al 80% de los casos. El 20% restante necesita criterio. El playbook te enseña qué preguntar, no qué responder.

Tu rigor. La parte más exigente no es la algorítmica: es la disciplina de medir, evaluar contra un golden set inmutable y respetar los guardrails cuando tu propio modelo se degrada. Esa parte la pones tú.

Lo que pedimos a cambio

Nada. El fichero se libera bajo licencia MIT. Puedes copiarlo, modificarlo, usarlo en proyectos comerciales, no atribuir, no devolver nada. El componente sociedad del Modelo de Mercadona no funciona como un trueque. Funciona como una multiplicación: si lo que aprendimos sirve para que otros equipos hagan algo mejor, estamos cumpliendo con el cuarto componente del Modelo de Mercadona a nuestra manera.

Si el playbook te sirve, nos encantaría saberlo. Pero no es una condición. Es solo curiosidad.

Al principio del artículo dije que no quería quedarme en la anécdota. He dado el detalle algorítmico, las decisiones críticas, el stack, el método de trabajo y un fichero descargable que reproduce todo lo que hemos aprendido. Si has llegado hasta aquí, ya tienes lo que necesitas para empezar tu propio buscador.

Compartir un playbook técnico es una forma de cumplir con el componente Sociedad del Modelo de Mercadona: una manera de operar en el día a día que también beneficie a quien está fuera del perímetro de la empresa.

Yo no espero que un equipo en otra empresa lea esto y construya el mejor buscador de la historia. Espero que alguien con un buscador caro, lento o poco controlable lea el artículo, descargue el fichero y se ahorre semanas de prueba y error. Si le ahorramos a un equipo el coste de aprender a tropezar, ya hemos cumplido nuestra parte.

El sueño de Juan Roig es compartir el modelo. Aplicado a un buscador parece pretencioso, pero es exactamente el mismo gesto: si alguien aprende a hacer algo bien, hay emprendedores; si hay emprendedores, hay empresas; si hay empresas, hay empleo; y, al final del camino, hay bienestar. Compartir lo que sabemos no es generosidad ni marketing. Es el modo en que un componente del Modelo de Mercadona se conecta con el siguiente.

Este post está dedicado a Juanjo Ponz Jordi Chulia Benlloch y al resto del equipo de Shop que lleva la tienda de Mercadona Online que son los que realmente han hecho este proyecto realidad. Mención especial también para Cristian Moncho Ivorra del equipo de Staff por hacer que el buscador vuele.

SearchMO Playbook — CLAUDE.md para construir tu propio buscador

La otra mitad es la dirección. Qué estás construyendo exactamente, por qué esa decisión y no otra, cómo vas a saber que lo que el agente te devuelve es correcto. Todo eso sigue sin resolverse cuando la única herramienta que tienes es “hablar con la IA”.

En los últimos meses ha aparecido una respuesta concreta a ese hueco, y está empezando a consolidarse con un nombre: spec-driven development. La idea es vieja — escribir specs antes que código existe desde los setenta — pero lo que es nuevo es que ahora las specs no son para humanos. Son para el agente. Y cambian radicalmente lo que puedes construir con IA sin perder el control de lo que estás construyendo.

Qué significa “spec” ahora

Antes de entrar en herramientas concretas, conviene entender qué significa “spec” en este contexto, porque no es lo que significaba hace diez años.

Una spec tradicional era un documento muerto. Alguien lo escribía, alguien lo leía, alguien lo ignoraba cuando llegaba la hora de programar. Al final del proyecto el documento y el código no se parecían en nada, y todo el mundo había aprendido a convivir con esa divergencia como quien convive con el goteo del grifo del baño.

Una spec para un agente de IA es otra cosa. Es un artefacto vivo que el agente lee antes de actuar, actualiza cuando toma decisiones, y consulta para verificar que lo que ha hecho encaja con lo que se le pidió. No es documentación post-hoc: es el contrato de trabajo. Puede ser un plan de fases, un conjunto de criterios de aceptación, una descripción del comportamiento esperado, una lista de verificaciones. Todo junto normalmente.

La diferencia práctica es brutal. Con vibe coding puro le dices al agente “hazme un buscador” y te lo hace. Lo que no sabes es qué asunciones ha tomado, qué edge cases ha ignorado, qué ha decidido por ti sin preguntarte. Con spec-driven development le das al agente el mismo “hazme un buscador”, pero también le das un documento que dice “estos son los requisitos no funcionales, estos los casos que tiene que manejar, esta la forma de validar que funciona, y estas las decisiones que no puedes tomar sin consultarme”. El agente ya no es un genio caprichoso. Es un ingeniero con mandato.

Esto lleva cincuenta años intentándose

Antes de que nadie hablase de vibe coding, agentes o spec-driven, la industria del software ya tenía claro que escribir código sin especificar antes qué debía hacer era una forma elegante de construir castillos sobre arena. La historia intelectual es larga y los nombres son conocidos, aunque casi nadie los cita fuera de la academia.

En 1969, Tony Hoare publicó An Axiomatic Basis for Computer Programming. Su propuesta era incómoda y radical: cada fragmento de código debía poder describirse con una pre-condición (lo que es cierto antes de ejecutarlo) y una post-condición (lo que garantiza después). La spec no era un documento anexo. Era el programa. El código era solo una forma de implementarlo.

Tres años después, en 1972, David Parnas publicó On the Criteria To Be Used in Decomposing Systems into Modules. Introdujo la idea de que cada módulo de software debía ocultar sus decisiones internas y exponer solo un contrato: qué puede asumir el cliente del módulo, qué promete cumplir el módulo. Contrato primero, implementación después.

En 1976, Edsger Dijkstra llevó la idea al extremo con A Discipline of Programming. Su tesis: el programa se deriva de la especificación, no al revés. Primero formalizas qué quieres que haga. Luego demuestras, paso a paso, que tu código lo cumple. Ingeniería como matemática.

El giro decisivo lo dio Donald Knuth en 1984 con Literate Programming. Knuth no hablaba de pre-condiciones ni demostraciones formales. Hablaba de algo más humano: un programa es un documento dirigido a un lector, y el código está embebido en la prosa que lo explica, no al revés. Su frase famosa: los programas deben tratarse como obras de literatura dirigidas a seres humanos.

Dos años después, en 1986, Bertrand Meyer formalizó la idea en un lenguaje real con Design by Contract: invariantes, pre y post-condiciones como parte del código ejecutable de Eiffel, el primer y único lenguaje realmente Orientado a Objetos. No como documentación. Como contrato verificable en tiempo de ejecución.

Y en 1994, Leslie Lamport publicó TLA+, un lenguaje para especificar sistemas distribuidos antes de escribirlos. Amazon, Microsoft y Google lo usan hoy para verificar piezas críticas de su infraestructura.

¿Por qué entonces casi ninguna empresa aplica estas ideas en su día a día? Porque el coste siempre fue asimétrico. Escribir la spec primero era lento. Mantenerla sincronizada con el código era un trabajo extra que nadie pagaba. El software funcionaba sin ella, aunque mal. Así que la industria eligió la vía rápida y acumuló cincuenta años de deuda conceptual.

Lo que ha cambiado ahora es el lector. Knuth escribía para humanos que casi nunca leían los programas de otros. Hoy el agente sí los lee. Los lee siempre. Y si tu código, tu arquitectura y tus decisiones no son legibles para él, no puede trabajar. Lo que era una aspiración ética se ha convertido en un requisito funcional.

Spec-driven development no es una moda de 2026. Es la primera vez en cincuenta años que hay un incentivo económico real para hacer lo que Hoare, Parnas, Dijkstra, Knuth, Meyer y Lamport llevan diciéndonos desde los setenta.

GSD: el workflow como contrato

GSD son las siglas de Get Shit Done. Es un conjunto de comandos que se instala encima de Claude Code y que convierte cualquier trabajo no trivial en una secuencia estructurada de fases con artefactos versionados. Lo desarrolló un ingeniero llamado Dan Gooding y está ganando adopción en equipos que usan agentes de IA en proyectos serios.

La idea central es sencilla: antes de escribir una línea de código, el agente te obliga a pasar por cuatro etapas — discutir, planificar, ejecutar, verificar — y cada una deja un artefacto en disco que la siguiente lee. No hay atajos. Si intentas saltar directamente a “implementa esto”, GSD te detiene y te hace definir primero el qué, el cómo y los criterios de aceptación.

En la práctica, trabajas con una serie de comandos muy concretos. /gsd:discuss phase hace al agente preguntarte lo que necesita saber antes de planificar — qué asunciones está tomando, qué decisiones dependen de ti, qué riesgos ve. /gsd:plan-phase genera un PLAN.md con la descomposición en tareas, dependencias entre ellas, y los tests que definirán que está hecho. /gsd:execute-phase ejecuta ese plan con commits atómicos por tarea. /gsd:verify-work valida al final que lo que se ha construido cumple los criterios que se fijaron al principio.

El resultado es que tu carpeta de trabajo deja de ser un vertedero de código generado y se convierte en una estructura de carpetas tipo .planning/001-fase-auth/ con tres ficheros: RESEARCH.md (lo que el agente investigó antes de planificar), PLAN.md (lo que va a hacer), VERIFICATION.md (cómo demostramos que está hecho). Esto no es documentación. Es el contrato que el agente firma consigo mismo y que tú puedes leer, auditar y modificar en cualquier momento.

Lo potente de GSD es que te obliga a pensar arriba-abajo. Primero el roadmap del proyecto. Luego las fases. Luego los planes. Luego el código. Cuando lo usas durante un par de semanas notas algo incómodo y revelador: la mayor parte del valor no está en la ejecución con IA, está en la conversación estructurada que te fuerza a tener antes. El agente te obliga a concretar cosas que de otra forma habrías dejado ambiguas. Y esas cosas ambiguas son exactamente las que después reventaban en producción.

El coste es evidente: GSD es mucho más lento que vibe coding para tareas pequeñas. Si lo que quieres es un script de veinte líneas, usar GSD es matar moscas a cañonazos. Pero para cualquier proyecto que dure más de una sesión y tenga más de una decisión importante, la inversión se paga varias veces.

Superpowers: disciplina en cada decisión

Superpowers ataca el mismo problema desde el ángulo opuesto. Lo desarrolló Jesse Vincent, un ingeniero conocido en la comunidad de Claude Code, y su tesis es muy distinta a la de GSD: el problema no es que el agente no tenga un plan global, es que en cada microdecisión del día a día se salta el rigor que aplicaría cualquier ingeniero senior.

Un ejemplo concreto. Le pides al agente que arregle un bug. Sin Superpowers, el patrón habitual es: el agente lee el error, propone una hipótesis, modifica el código, dice “listo”. A veces funciona. Otras veces parchea un síntoma y deja la causa real intacta. Con Superpowers activada, el agente no puede responder hasta que invoque una skill llamada systematic-debugging. Esa skill e obliga a seguir unprocedimiento: reproducir el bug de forma determinista, formular hipótesis, aislarlas una a una, verificar el fix con un test antes de declarar victoria. No es una sugerencia. Es un gate obligatorio.

Superpowers es, en la práctica, una colección de unas quince skills que cubren momentos concretos en los que los agentes suelen pifiarla: brainstoring antes de diseñar una feature, test-driven-development antes de escibir código, verification-before-completion antes de declarar algo como terminado, receiving-code-review cuando el usuario le da feedback, dispatching-paralle-agents cuando hay trabajo independiente que se puede paralelizar. Cada skill s un procedimiento probado empaquetado en un fichero markdown qu el agente carga cuado elcontexto lo requiere.

La parte inteligente del diseño es que las skills se auto-invocan. No tienes que acordarte de decir “usa TDD ahora”. El agente detecta que va a escribir código nuevo y la skill se activa sola. Detecta que estás a punto de declarar una tarea como hecha y la skill de verificación le exige evidencia antes de dejarle hacerlo. Las skills son, en el fondo, contratos de comportamiento que el agente firma con su yo futuro: “cuando me toque hacer X, voy a seguir obligatoriamente Y pasos”.

Donde GSD es arriba-abajo (primero el plan, luego la ejecución), Superpowers es abajo-arriba (no importa qué estés haciendo, cuando hagas esto lo harás así). Donde GSD protege contra la falta de dirección, Superpowers protege contra la falta de disciplina. Y aquí está el punto: son dos problemas distintos que requieren dos soluciones distintas.

En mi experiencia, la skill más valiosa de Superpowers es la más aburrida de todas: verification-before-completion. El agente no puede decir “hecho” hasta que ha ejecutado el comando que demuestra que funciona y ha mostrado la salida. Parece obvio. En la práctica, evita el 80% de los “terminé” prematuros que provocan después una ronda entera de debugging innecesario.## La diferencia que importa

La primera reacción cuando ves GSD y Superpowers juntos es pensar que compiten. Las dos hablan de estructurar el trabajo con agentes. Las dos meten disciplina donde vibe coding la esquiva. Las dos generan artefactos y fuerzan procedimientos. Parecen dos respuestas al mismo problema. No lo son. Resuelven problemas distintos, y entenderlo es la diferencia entre elegir uno, elegir otro, o combinarlos.

GSD organiza el **proyecto**. Su unidad de trabajo es la fase, que dura horas o días, y su foco es asegurar que antes de ejecutar algo haya un contrato claro de qué se va a hacer, por qué, y cómo se va a validar. Es el equivalente moderno de la idea de Dijkstra: deriva el código de la especificación. Si tu problema es que los agentes se lanzan a construir sin saber bien qué están construyendo, GSD es tu respuesta.

Superpowers organiza la **decisión**. Su unidad de trabajo es cada interacción individual del agente, que dura segundos o minutos, y su foco es que en cada microdecisión el agente siga el procedimiento correcto. Es el equivalente moderno de la idea de Meyer: contratos ejecutables que se verifican en tiempo de ejecución. Si tu problema es que los agentes se saltan pasos que cualquier ingeniero senior daría por obligatorios, Superpowers es tu respuesta.

En términos prácticos, la diferencia se nota así. Un proyecto gestionado con GSD pero sin Superpowers acaba con planes y fases impecables, pero cada fase internamente tiene los mismos problemas de vibe coding — el agente se salta verificaciones, propone fixes sin hipótesis, declara cosas hechas sin evidencia. Un proyecto con Superpowers pero sin GSD tiene cada decisión bien tomada, pero el conjunto carece de dirección — el agente implementa bien cosas que quizá no tenía que implementar. Los dos fallan, por motivos opuestos.

Juntos, se complementan de manera casi perfecta. GSD define el qué y el por qué a nivel de proyecto. Superpowers garantiza el cómo a nivel de cada paso. El resultado es lo más cercano a trabajar con un ingeniero senior disciplinado que he visto hasta ahora — no porque el agente sea un ingeniero senior, sino porque la combinación de estructura y disciplina le impide actuar como un junior que se salta pasos.

Hay una lectura más profunda aquí que conviene no perder. GSD es la herencia directa de la escuela formal de Hoare, Dijkstra y Parnas: el rigor viene de especificar primero. Superpowers es la herencia directa de Knuth y Meyer: el rigor viene de construir las garantías dentro del propio acto de programar. Medio siglo después, los dos caminos siguen siendo válidos. Y siguen siendo complementarios.

El sistema de previsión que estamos construyendo así

Voy a aterrizar todo esto con el proyecto real en el que más lo estoy aplicando. En Mercadona Tech estamos construyendo un sistema de previsión de demanda a escala industrial: predecir cuánto se va a vender de cada producto, en cada centro, en cada franja horaria, para cada día. Más de doscientas mil series temporales reconciliadas en cinco niveles de agregación, con intervalos de confianza que tienen que tener garantías matemáticas de cobertura. No es un proyecto donde vibe coding pueda llevarte lejos. Una decisión mal tomada en una fase temprana contamina todas las posteriores, y muchas de las decisiones solo se ven con años de oficio.

Aquí GSD hace su trabajo. El proyecto vive en fases: exploración de datos, baselines, modelos candidatos, reconciliación jerárquica, calibración de intervalos, despliegue a producción. Cada fase tiene su plan, sus criterios de aceptación y su verificación. Los documentos que se generan no son reportes para enseñar a un jefe. Son el contrato que el siguiente paso del proyecto lee antes de ejecutar. Cuando un colaborador entra al proyecto, no tiene que preguntarme qué está pasando — lee la fase activa y lo sabe.

Aquí Superpowers hace el suyo. Las disciplinas de verificación impiden que el agente reporte una métrica sin haberla validado con backtesting riguroso. El procedimiento obligatorio de debugging aparece cada vez que un modelo degrada en una fracción del dataset y nos fuerza a aislar la causa antes de parchear. La skill de verificación-antes de-completar evita los falsos positivos clásicos de la ciencia de datos, donde algo parece funcionar porque se ha medido mal.

Sin GSD, un proyecto de esta envergadura se convierte rápido en treinta notebooks que nadie sabe cómo conectar. Sin Superpowers, publicas una métrica que parece excelente hasta que la realidad te corrige. Con ambos, la IA acelera cada fase sin renunciar al rigor que un sistema de este tamaño exige.

Las tres capas

Si hace una semana dejábamos vibe coding como la Thermomix del software —velocidad accesible para todo el mundo —, ahora podemos terminar de dibujar el cuadro completo. Construir con IA no es una técnica, son tres capas que se apoyan unas en otras.

La primera capa es la velocidad. Vibe coding. La capacidad de conversar con un agente y ver cómo el código aparece en segundos. Resuelve el problema que durante décadas fue el cuello de botella del desarrollo: la distancia entre idea y prototipo.

La segunda capa es la dirección. Spec-driven development en su encarnación moderna, con herramientas como GSD al frente. Resuelve un problema más sutil y más viejo: cómo garantizar que lo que el agente construye responde realmente a lo que hace falta, no a lo que el agente ha interpretado que hacía falta. Hoare lo vio en el sesenta y nueve. Dijkstra en el setenta y seis. Nosotros lo estamos aplicando por primera vez a escala gracias a que el coste de mantener specs vivas ha colapsado.

La tercera capa es la disciplina. Superpowers y el resto de frameworks que meten rigor en cada decisión individual del agente. Resuelve el problema de que un agente que en promedio lo hace bien puede hacerte daño en los pocos casos en los que se salta un paso crítico. Meyer lo formalizó en Eiffel en los ochenta. Hoy lo tenemos disponible como skills que el agente invoca solo.

Las tres juntas son mucho más que la suma de las tres por separado. Velocidad sin dirección te lleva rápido a un sitio que no era el que querías. Dirección sin disciplina te lleva al sitio correcto con un sistema que falla cuando más importa. Disciplina sin velocidad te deja atrás, fabricando calidad en un mercado que premia la iteración rápida. Y velocidad sin dirección ni disciplina es exactamente lo que los ingenieros senior temen cuando oyen hablar de vibe coding.

La pregunta que te deberías hacer no es si adoptar IA en tu proceso de desarrollo. Esa batalla ya está resuelta. La pregunta es si estás adoptando las tres capas o solo la primera. Porque la primera es la que sale gratis. Las otras dos son las que deciden si dentro de un año tendrás un sistema que se sostiene o una deuda técnica imposible de pagar.

Si en algún momento te descubres pensando “el agente lo hace rápido pero no me fío de lo que entrega”, lo que te falta no es más IA. Es spec y disciplina. Y ambas existen, están maduras, y llevan cincuenta años esperando su momento.

Para unos es el futuro. Para otros es el principio del fin de la ingeniería de software seria. Yo llevo meses haciéndolo, y mi conclusión es que ambos tienen razón — pero por motivos que ninguno de los dos está viendo.

El término lo acuñó Andrej Karpathy a principios de 2025. Ex-director de IA en Tesla, cofundador de OpenAI. No es precisamente alguien que no entienda código. Su definición era provocadora a propósito: “Te rindes al vibe, abrazas los exponenciales, y te olvidas de que el código existe.”

La reacción fue inmediata. Los ingenieros senior se echaron las manos a la cabeza. Los builders que llevaban semanas prototipando con IA asintieron en silencio. Twitter se convirtió en un campo de batalla entre puristas y pragmáticos.

Pero el debate se está dando en términos equivocados. La pregunta no es si vibe coding “funciona” o “no funciona”. La pregunta es para qué funciona, para qué no, y qué cambia en cómo organizamos equipos de producto cuando una parte del equipo lo adopta.

Piensa en la Thermomix. Cuando apareció, los chefs profesionales la despreciaron. “Eso no es cocinar.” Y tenían razón — técnicamente. Pero millones de familias empezaron a preparar platos que antes les parecían imposibles. La Thermomix no sustituyó a los chefs. Cambió lo que podía hacer la gente que no era chef.

Vibe coding es la Thermomix del software. Y eso tiene implicaciones enormes para cualquiera que gestione un equipo de producto.

Cuando funciona (y funciona más de lo que los puristas admiten)

Hay un patrón que se repite en todos los equipos que conozco que han adoptado herramientas de vibe coding: el primer éxito llega rápidamente y es espectacular.

Un prototipo funcional en horas en lugar de días. Una herramienta interna que llevaba meses en el backlog y de repente existe. Un script de migración de datos que hubiera requerido una semana de trabajo manual. Una prueba de concepto para convencer a un stakeholder que antes necesitaba dos sprints de inversión.

No es magia. Lo que está pasando es que una enorme cantidad de código que escribimos es estructural, repetitivo, predecible. Configurar un proyecto, conectar una API, montar un CRUD, escribir tests unitarios para casos estándar. Un buen agente de IA hace esto en minutos porque ha visto millones de implementaciones similares. Y lo hace razonablemente bien.

Donde el vibe coding brilla de verdad es en ese espacio donde sabes exactamente lo que quieres pero el coste de implementarlo siempre ha sido demasiado alto. Herramientas internas que nadie prioriza. Automatizaciones que “ya haré cuando tenga tiempo”. Prototipos para validar ideas antes de invertir un sprint entero. Para un PM o un tech lead, esto es transformador: la distancia entre idea y validación se acorta radicalmente.

Cuando explota (y explota más de lo que los evangelistas admiten)

Ahora la otra cara. Y es una cara que muchos están descubriendo de la peor manera posible.

El problema fundamental del vibe coding es lo que yo llamo la deuda técnica invisible. Cuando un ingeniero escribe código, toma cientos de micro-decisiones: cómo manejar un error, qué pasa si la conexión se cae, cómo escala esto cuando hay diez mil usuarios concurrentes, qué asunciones estoy haciendo sobre los datos de entrada. Cada decisión es una pieza de conocimiento que vive en la cabeza del equipo.

Cuando el código lo genera una IA y tú solo validas que “funciona”, esas decisiones se toman igualmente. Pero nadie sabe cuáles fueron. El código pasa los tests. La feature funciona en staging. Todo verde. Hasta que en producción un edge case que nadie consideró tumba el servicio un viernes a las once de la noche. Y entonces necesitas debuguear código que no escribiste, basado en decisiones que no tomaste, con asunciones que no conoces.

He visto equipos que prototiparon algo en dos días con vibe coding y luego necesitaron tres semanas para hacerlo production-ready. El ratio real no es 10x. Es 2x con asterisco. Y el asterisco es importante.

El segundo problema es más sutil: la falsa sensación de competencia. Cuando puedes generar código que funciona sin entender por qué funciona, empiezas a tomar decisiones de arquitectura sin tener las bases para tomarlas. Es como conducir un Fórmula 1 con piloto automático — funciona hasta la primera curva que el sistema no ha visto antes.

Lo que cambia para el PM y el Tech Lead

Si gestionas un equipo de producto, vibe coding ya te afecta aunque no lo hayas adoptado oficialmente. Alguno de tus ingenieros lo está usando. La pregunta es si lo sabes y si has pensado en qué significa.

Lo primero que cambia son las estimaciones. Cuando un junior puede entregar en días lo que antes costaba semanas, tus modelos de capacidad dejan de funcionar. ¿Asignas más trabajo? ¿Reduces el equipo? ¿Asumes que la velocidad es sostenible? Ninguna de las tres respuestas es correcta sin contexto.

Lo segundo que cambia es el code review. Ya no estás revisando el trabajo de un ingeniero que tomó cada decisión conscientemente. Estás revisando código generado donde el autor no puede explicarte por qué eligió ese patrón y no otro. Esto requiere un tipo de revisión diferente: menos “¿por qué hiciste esto así?” y más “¿qué pasa si esto falla?”. Más adversarial, menos colaborativo.

Lo tercero, y esto es lo más importante para PMs: cambia lo que puedes pedir. Antes, un prototipo era caro. Ahora es barato. Eso significa que puedes validar más hipótesis antes de comprometer al equipo. Puedes mostrar un prototipo funcional al stakeholder en lugar de un wireframe. Puedes probar tres enfoques en paralelo en lugar de apostar por uno. Si eres PM y no estás aprovechando esto, estás dejando dinero en la mesa.

El buscador que construimos hablando

Voy a ponerte un ejemplo real, porque creo que es la forma más honesta de hablar de esto.

En Mercadona Tech teníamos un problema con nuestro buscador de la tienda online. Usábamos Algolia, un SaaS que nos costaba entre 9.000 y 15.000 dólares al mes. Funcionaba, pero teníamos un 4% de búsquedas sin resultados, un ranking que no podíamos controlar como queríamos, y una dependencia total de un proveedor externo para una pieza crítica del negocio: 4,4 millones de búsquedas a la semana.

Decidimos construir nuestro propio buscador. Búsqueda híbrida con keyword y semántica, un modelo de Learning to Rank entrenado con datos reales de clics de nuestros usuarios, autocompletado, el stack completo. Y lo desarrollamos con Claude Code.

¿Qué funcionó? La velocidad de exploración fue brutal. Analizar 479 megabytes de datos de catálogo y analítica, iterar sobre 12 experimentos diferentes, hacer una competición de 5 modelos de ranking con validación cruzada — todo eso se hizo conversando con agentes de IA. Tareas que hubieran requerido semanas de trabajo de un equipo de data science las completamos en días.

¿Qué no funcionó sin intervención humana? Las decisiones que definen si el sistema aguanta en producción o se cae el primer día. No usar Elasticsearch porque el coste y la latencia no encajaban. No usar Cloud Run porque los cold starts son fatales para un buscador. Diseñar un índice maestro con bitsets en lugar de 762 índices separados. Establecer las reglas de gobernanza del modelo: validación walk-forward en lugar de aleatoria, corrección de sesgo de posición obligatoria, un guardrail que bloquea automáticamente cualquier modelo que degrade más de un 2% las métricas.

Esas 29 decisiones técnicas no las tomó la IA. Las tomó un equipo con criterio. Y son exactamente las decisiones que separan un prototipo que impresiona en una demo de un sistema que sirve 4,4 millones de búsquedas a la semana sin caerse.

El resultado: un buscador que mejora el ranking un 85% respecto a Algolia, elimina completamente las búsquedas sin resultados, y cuesta menos de 900 dólares al mes. Construido en gran parte con vibe coding. Pero las decisiones que importan, tomadas por personas.

La herramienta, no la respuesta

Vibe coding no es revolución ni espejismo. Es una herramienta extraordinariamente potente que está en manos de todo el mundo por primera vez.

La Thermomix no mató a los restaurantes. Pero cambió para siempre lo que una persona sin formación culinaria podía preparar en su cocina. Vibe coding no va a eliminar a los ingenieros senior. Pero va a cambiar radicalmente lo que puede construir alguien con una idea clara y ganas de iterar.

La pregunta que deberías hacerte no es “¿vibe coding sí o no?”. Es: ¿en qué partes de mi producto estoy gastando tiempo de ingeniería en trabajo que una IA puede hacer igual de bien? ¿Y en qué partes estoy en riesgo de confiar en código que nadie entiende realmente?

Si puedes responder a esas dos preguntas con honestidad, el vibe coding va a ser una ventaja enorme. Si no puedes, va a ser una trampa.

El Story Builder representa algo fundamental en la evolución del trabajo del Product Manager en Mercadona Tech. No es simplemente otra herramienta más. Es el reconocimiento de que no toda buena idea comienza con un documento formal. Es el puente entre el pensamiento rápido y la creación estructurada.

La Realidad que El Story Builder Resuelve

Cuando pensamos en cómo se generan las historias de usuario en una organización como la nuestra, es fácil asumir que todo comienza en un PRD bien estructurado. Que cada idea pasa por research, que cada problema viene documentado con datos y contexto. Pero la verdad es más matizada.

La verdad es que muchas de las mejores ideas surgen en conversaciones espontáneas. Un PM está en una reunión de planificación y alguien menciona un problema que ha visto repetidamente. Un stakeholder en un comité ejecutivo describe una fricción que existe en el sistema. Un cliente más grande reporta una ineficiencia que mata su productividad. El gerente de un almacén regional cuenta cómo sus equipos están desperdiciando tiempo en una tarea repetitiva. No hay PRD. No hay investigación formalizada. Hay un problema real, urgente, que merece atención inmediata.

En estas situaciones, los PMs se enfrentan a un dilema. Por un lado, el rigor que el framework exige es importante: necesitamos evidencia, necesitamos entender el contexto del usuario, necesitamos validar que estamos atacando un problema real y no una solución en busca de propósito. Por otro lado, la velocidad también importa. No queremos que la burocracia del proceso impida que ideas válidas lleguen al desarrollo.

Story Builder resuelve este dilema. Es la herramienta conversacional que permite a un PM con una idea, un problema detectado en el terreno, o una conversación reciente, transformar eso en una historia de usuario de calidad sin pasar por todo el pipeline formal. Pero —y esto es crítico— sin reducir la calidad ni las exigencias del framework.

La Base Teórica Sigue Siendo La Misma

Lo primero que es importante entender es que Story Builder no inventa una nueva metodología. Utiliza exactamente la misma base teórica que todos los módulos anteriores del AI Mercadona User Story Framework: Jobs to Be Done, el checklist de Wendel, y el análisis de cambio de comportamiento.

Lo que cambia es el punto de entrada. En el pipeline completo del framework, comenzamos con un PRD (o lo que en nuestros documentos internos llamamos DAPP). El Quality Guard la examina. Research & JTBDs descubre o refina los trabajos implícitos. Esos JTBDs validados se transforman en historias. El Quality Coach las evalúa. Story Splitting las organiza en entregas. Es un flujo lineal, casi una cadena de montaje de calidad.

Story Builder invierte el proceso. No comienza con un documento. Comienza con una persona que tiene una pregunta. Y a través de seis fases bien estructuradas, esa persona articula un problema lo suficientemente bien como para que los desarrolladores entiendan exactamente qué necesitan construir. La rigor viene en las preguntas, no en el documento de entrada.

Esta es una diferencia sutil pero profunda. Porque significa que el framework no es un procedimiento que requiere documentación previa. Es un conjunto de principios que pueden aplicarse conversacionalmente.

Las Seis Fases de Story Builder

Fase 1: Contexto Inicial — La Trampa de la Solución

Todo comienza con una pregunta simple: “¿Qué problema quieres resolver? ¿Para qué producto?”

Pero aquí es donde ocurre algo extraordinario. Muy frecuentemente, el PM responde algo como: “Quiero agregar un botón de filtrado”, o “Necesito una nueva columna en la tabla”, o “Debemos integrar con el sistema de CRM”.

El Story Builder hace algo que parece contradictorio: rechaza la respuesta. No rechaza el problema, sino la forma en que ha sido expresado. El módulo responde: “Veo que tienes una solución en mente. Pero primero necesito entender: ¿qué problema tiene el usuario que esta solución resolvería?”

Esta detección de la “trampa de la solución” es sorprendentemente común. Los PMs —especialmente aquellos con experiencia técnica o que han estado cerca del desarrollo— tienden a pensar en términos de características y soluciones, no en términos de problemas y trabajos. Es una deformación ocupacional completamente comprensible. Hemos pasado años diciendo “construyamos un filtrado”, así que es natural que los problemas se articulen automáticamente como soluciones.Pero Jobs to Be Done nos enseña que esta forma de pensar es exactamente invertida. El trabajo que el usuario está tratando de hacer existe independientemente de cualquier solución. Y hay múltiples formas de resolver ese trabajo. Si obligamos al PM a pensar en términos de el problema subyacente, abrimos la puerta a innovación, a mejores soluciones, a un entendimiento más profundo.

El Story Builder no permite pasar a la siguiente fase hasta que ha conseguido articular un problema, no una solución. Y lo hace sin hostilidad. Lo hace con la paciencia de un coach que ha visto este patrón cien veces antes.

Fase 2: Descubrir El Trabajo — El Método Del “¿Por Qué?”

Una vez que tenemos un problema articulado, el Story Builder entra en la Fase 2: descubrir el trabajo que el usuario está tratando de hacer.

Esta fase utiliza la técnica del “¿Por qué?” a tres, cuatro, o incluso cinco niveles de profundidad. Es la técnica clásica de investigación cualitativa, pero automatizada de una manera que es pedagógica.

Funciona así: el PM dice algo como “Nuestros usuarios quieren filtrar productos más rápido”. El Story Builder pregunta: “¿Por qué es importante que encuentren productos rápido?” La respuesta podría ser: “Porque se aburren y abandonan la sesión”. Entonces: “¿Por qué abandonarían la sesión? ¿Qué hay en juego?” “Porque están haciendo su compra semanal y tienen prisa, o porque se cansaron de desplazarse”. Y así sucesivamente.

Después de cinco minutos de este diálogo, lo que emergió es diferente de donde empezó. No es “agregar filtros”. Es “ayudar a los usuarios a completar su compra semanal de manera eficiente”. O quizás: “Permitirles acceder únicamente a los productos que realmente necesitan, ahorrándoles decisiones cognitivas”. O incluso: “Ayudarles a sentirse en control de una cantidad abrumadora de opciones”.

Cada uno de estos es un “trabajo” diferente. Y cada uno podría resolverse de múltiples maneras. El filtrado es una solución para algunos. Una lista de “mis productos habituales” podría ser la solución para otros. Un carrito inteligente que aprende con el tiempo sería la solución para otros.

El Story Builder tiene una prueba de validación para asegurarse de que realmente has descubierto un trabajo y no solo una solución reformulada: ¿puede este trabajo ser implementado de múltiples formas? Si la respuesta es sí, entonces es un trabajo. Si solo hay una forma de hacerlo, entonces probablemente sigue siendo una solución disfrazada de trabajo.

Fase 3: El Checklist De Wendel — Haciendo Específico Lo General

Ahora tenemos un trabajo. Pero “los usuarios quieren completar su compra rápida” es todavía demasiado general. ¿Qué usuarios? ¿Bajo qué circunstancias? ¿Con qué contexto?

La Fase 3 introduce el checklist de Wendel, que consta de cuatro preguntas mandatorias que deben responderse con datos concretos y específicos:

Primera pregunta: Experiencia previa. ¿Es este un trabajo nuevo o recurrente? ¿Cuánto tiempo llevan usando el producto? ¿Han intentado resolver este trabajo antes de otras maneras?

Segunda pregunta: Relación con el producto. ¿Cómo interactúan hoy con el producto? ¿Es su primer contacto o son usuarios veteranos? ¿Lo usan diariamente o ocasionalmente?

Tercera pregunta: Motivación situacional. ¿Qué los impulsa en ESTE momento? ¿Hay presión de tiempo? ¿Hay consecuencias por no lograr el trabajo? ¿Es voluntario u obligatorio?

Cuarta pregunta: Impedimento actual. ¿Qué específicamente les está impidiendo lograr el trabajo ahora mismo? ¿Es un problema técnico, cognitivo, de diseño?

Si el PM responde con generalidades —”todos nuestros usuarios”, “la mayoría de personas que compran”— el Story Builder rechaza y pide especificidad. “Eso es demasiado amplio. Necesito entender exactamente quién tiene este trabajo. ¿Es el cliente ocasional que viene cada dos semanas? ¿Es la ama de casa que compra para su familia? ¿Es el restaurante que compra para abastecer su cocina?”

Esta insistencia en la especificidad es lo que separa una historia de usuario útil de una que suena bien pero es imposible de desarrollar. Porque un desarrollador necesita saber: ¿para quién estoy construyendo esto? ¿En qué contexto? ¿Con qué limitaciones?

Si dices “como usuario” sin más, el checklist de Wendel rechaza la respuesta. Te obliga a ser específico.

Fase 4: Las Tres Dimensiones Del Trabajo

Ahora el Story Builder te lleva a la Fase 4, donde las cosas se ponen más interesantes. Porque un trabajo humano no es solo una tarea funcional. Tiene tres dimensiones.

La dimensión funcional es la más obvia. Es la tarea práctica que necesitan accomplir. Encontrar productos rápido. Completar la compra. Pagar. Recibir su pedido. Estas son las cosas medibles, las cosas que los desarrolladores pueden construir.

Pero luego está la dimensión emocional. ¿Cómo quieren sentirse? ¿Quieren sentirse en control? ¿Organizados? ¿Tranquilos de que están tomando buenas decisiones? ¿Confiados de que no se olvidan nada? ¿Seguros de que están obteniendo buen valor?

Y finalmente la dimensión social. ¿Cómo quieren ser percibidos? ¿Quieren parecer eficientes? ¿Responsables? ¿Sofisticados? ¿Atentos a los detalles?Estas tres dimensiones existen simultáneamente. Y la experiencia más potente ocurre cuando un producto resuelve las tres. No solo permite que la tarea sea completada (funcional), sino que hace que el usuario se sienta bien mientras la hace (emocional) y lo hace parecer bien (social).

Muchas historias de usuario se quedan atrapadas únicamente en la dimensión funcional. “Como usuario, quiero filtrar, para encontrar productos más rápido”. Es técnicamente correcta. Pero pierdes la motivación más profunda. El desarrollador no entiende realmente por qué importa esto. Y entonces no optimiza para las experiencias que harían que el usuario se sienta en control o que lo hiciera parecer eficiente.

El Story Builder te obliga a explorar las tres dimensiones. Y luego, como bonus, te hace pensar en las ansiedades y las barreras. ¿Qué temores tienen los usuarios? ¿Qué podría evitar que adopten esta característica incluso si funciona perfectamente?

Por ejemplo, alguien podría tener miedo de que los filtros sean tan complejos que sean más confusos que la búsqueda manual. O miedo de que el sistema filtre incorrectamente y pasen por alto algo que necesitaban. Estas ansiedades son reales. Y ignorarlas significa que construirás una característica que funciona pero que nadie usa.

Fase 5: Cambio De Comportamiento — Del Ahora Al Nuevo

Aquí es donde la historia de usuario se vuelve medible. El Story Builder te obliga a pensar en: ¿cómo cambiaría el comportamiento del usuario si logras resolver este trabajo?

Esto no es teórico. Es cuantificado. Tiene rangos.

El usuario está haciendo algo hoy de una cierta manera. El “ahora” es medible. Quizás: buscar productos en su carrito de compra semanal toma doce minutos. Quizás toman treinta y cinco decisiones sobre qué productos incluir o excluir. Quizás tienen una tasa de abandono de veinte por ciento.

Cuando resuelvens el trabajo con éxito, hay un “nuevo” comportamiento. Y ese nuevo comportamiento tiene tres rangos:

Mínimo: El umbral por debajo del cual el usuario estaría decepcionado. Para la búsqueda de productos, quizás: ocho minutos y cuarenta segundos. Ese es un treinta por ciento de mejora. No es espectacular, pero es notabilidad. Es suficiente para que el usuario piense: “Sí, esto es un poco mejor”.

Target: El resultado realista y deseable. Quizás: seis minutos. Una mejora del cincuenta por ciento. Aquí es donde realmente sientes que algo cambió. Tu compra semanal es notablemente más rápida.

Over-top: El resultado excepcional, la “vaya, esto es increíble” versión. Quizás: tres minutos y treinta y seis segundos. Una mejora del setenta por ciento. Tu compra que solía tomar el tiempo de un café ahora toma lo que cuesta pagar. Es transformador.

Estos rangos no son arbitrarios. Son validados contra datos reales. Contra el comportamiento actual. Contra benchmarks de soluciones comparables. Contra lo que los usuarios mismos dicen cuando se les pregunta: “¿Cuánto tiempo sería suficientemente rápido?”

El Story Builder insiste en estos números porque son lo que le permite al equipo de producto entender realmente si el trabajo está siendo resuelto. No es: “¿Funciona el filtrado?” Es: “¿Los usuarios pueden ahora encontrar un producto en menos de nueve segundos?” Eso es verificable. Eso es medible. Eso es lo que importa.

Fase 6: La Historia Completa En Formato JTBD Reforzado

Cuando has pasado por las cinco fases anteriores, la Fase 6 es casi ceremonial. El Story Builder te entrega una historia de usuario completa, pero no en el formato anticuado de “como [usuario], quiero [característica], para [beneficio]”.

Es una historia completa en lo que el framework llama “formato JTBD Reforzado”. Contiene:

• El trabajo articulado de manera clara y específica

• El usuario específico con los cuatro elementos del checklist de Wendel completamente rellenos

• Las tres dimensiones del trabajo (funcional, emocional, social)

• Las ansiedades y barreras identificadas

• El cambio de comportamiento cuantificado con los tres rangos (mínimo, target, over-top)

• Los criterios de Given-When-Then: la secuencia de eventos que debe ocurrir para que el usuario complique su trabajo

• La puntuación de 6D: cada historia se evalúa exactamente con las mismas seis dimensiones que todas las otras historias del framework

No hay atajos. La calidad es idéntica a la de una historia que vino de un PRD completo que pasó por todo el pipeline. Porque el rigor no vino del documento. Vino de las preguntas.

El Módulo No Te Permite Saltarte Pasos

Un aspecto del Story Builder que algunos PMs encuentran inicialmente frustrante es su inflexibilidad. El módulo no te permite saltarte fases. No puedes estar en la Fase 2 y pensar “ya he respondido esto, déjame pasar a la Fase 5”. No. El módulo es demandante. Es pedagógico. Es —podríamos decir— un poco obstinado.

Pero esta obstinación tiene un propósito. Porque lo que descubrimos en los primeros proyectos piloto fue que cuando los PMs podían saltarse pasos, lo hacían. Y invariablemente, cuando la historia llegaba a desarrollo, faltaba contexto crítico. Nadie había pensado realmente en las ansiedades del usuario. O no había claridad sobre las tres dimensiones del trabajo. O el cambio de comportamiento era vago.

Entonces el Story Builder fue diseñado para ser imposible de saltarse. Cada fase desbloquea la siguiente. Si no respondes la pregunta de la Fase 3 con suficiente especificidad, no puedes avanzar. Punto.

Esto es frustrante durante quince minutos. Y entonces se vuelve revelador.

El Efecto Formativo — La Verdadera Razón De Existencia De Este Módulo

Aquí está el insight clave que separa a Story Builder de ser simplemente otra herramienta de generación de contenido: el efecto formativo.

Después de usar Story Builder varias veces, algo cambia en cómo el PM piensa sobre los problemas. Ya no necesita que la IA le pregunte “¿cuál es el impedimento actual?” porque automáticamente se encuentra pensando en ello cuando alguien describe un problema. Ya no olvida preguntar sobre las dimensiones emocionales y sociales porque ha internalizado que un trabajo humano es tridimensional.

El módulo se vuelve gradualen dispensable. No porque haya generado contenido, sino porque ha cambiado la forma en que su usuario piensa.

Esto es lo que diferencia a un asistente de IA de un copiloto real. Un asistente genera salida. Un copiloto cambia cómo piensas sobre la entrada.

Un asistente te ahorra tiempo escribiendo. Un copiloto te hace ser mejor en tu trabajo. Y la verdadera medida del éxito no es cuántas veces lo usas, sino cuántas veces no lo necesitas porque has internalizado el modo de pensar que enseña.

Los PMs que han utilizado Story Builder durante dos meses en Mercadona Tech reportan algo similar: que las reuniones con stakeholders se sienten diferentes. Que naturalmente hacen preguntas más profundas. Que se sienten más seguros diciendo “no creo que eso sea realmente el problema que necesitamos resolver” porque pueden articular por qué. Que tienen más conversaciones sobre el contexto emocional y social de las decisiones de los usuarios, no solo la lógica funcional.

Eso es el efecto formativo. Y es potencialmente más valioso que cualquier historia de usuario que el módulo haya generado.

La Puntuación De 6D Sigue Siendo La Misma

Un punto que es importante mencionar explícitamente: cada historia generada por Story Builder es calificada con el mismo sistema de 6D que el resto del framework. No hay excepción. No hay “ya que fue conversacional, podemos relajar los estándares”.

Las seis dimensiones son:

1. Claridad del Usuario: ¿Sabemos exactamente quién es el usuario y en qué contexto opera?

2. Profundidad del Trabajo: ¿Entendemos la verdadera necesidad debajo de la característica, o estamos resolviendo una solución?

3. Especificidad del Comportamiento: ¿Podemos medir si el trabajo está siendo resuelto?

4. Viabilidad Técnica: ¿Es razonable construir esto con la tecnología disponible?

5. Alineación Estratégica: ¿Ayuda esto a alcanzar los objetivos del producto y la compañía?

6. Testabilidad: ¿Podemos diseñar un test que demuestre si esta característica logra su objetivo?

Una historia que viene de un PRD formal tiene que puntuar bien en estas seis dimensiones. Una historia que viene de una conversación de quince minutos en Story Builder también. No hay diferencia. El rigor es consistente.

Esto tiene un efecto importante: significa que Story Builder es genuinamente útil para problemas reales, no solo para brainstorming rápido. No es una herramienta para generar “ideas locas”. Es una herramienta para convertir problemas reales en historias de usuario que pueden ser desarrolladas inmediatamente.

Conclusiones: El Viaje Completo Del Framework

Hemos llegado al final. En estos siete artículos, hemos recorrido la totalidad del AI Mercadona User Story Framework. Comenzamos con Quality Guard, validando la solidez de nuestras investigaciones de usuario. Pasamos a Research & JTBDs, donde descubrimos los trabajos verdaderos que nuestros usuarios estaban tratando de hacer. Vimos cómo JTBD to Stories transformaba esos trabajos en historias de usuario estructuradas. Conocimos al Quality Coach, quien nos enseñaba a evaluar nuestro propio trabajo con rigor. Exploramos Story Splitting, entendiendo cómo particionar el trabajo complejo en incrementos que podían ser entregados en sprints reales. Y finalmente, aquí en este séptimo artículo, hemos visto el Story Builder, que nos permitía comenzar con una conversación en lugar de un documento y terminar con una historia de usuario de calidad idéntica.

¿Qué significa todo esto cuando se ve como un sistema completo?

El AI Mercadona User Story Framework no es un conjunto de herramientas separadas. Es un sistema coherente basado en un conjunto de principios compartidos. Jobs to Be Done no es simplemente una teoría que usamos en Research & JTBDs. Es la lente a través de la cual evaluamos historias en Quality Coach. Es la base sobre la que Story Builder construye sus preguntas. Es lo que nos permite saber que una historia es “realmente buena” en lugar de simplemente “técnicamente correcta”.

El checklist de Wendel no es solo algo que hacemos en Story Builder. Es lo que permite que Quality Coach sepa si tu historia especifica suficientemente al usuario. Es lo que hace que Story Splitting tenga sentido: porque sabemos exactamente para quién estamos dividiendo el trabajo.

Los seis criterios de puntuación son exactamente iguales en todas partes. La calidad de una historia de usuario no depende de cómo entró en el sistema. Depende de si resuelve un trabajo real para un usuario específico de una manera que pueda ser verificada.

Esto tiene implicaciones profundas. Significa que el trabajo del Product Manager no es “crear especificaciones”. Es “descubrir problemas reales y especificar soluciones verificables a esos problemas”. Es investigación, análisis crítico, pensamiento estratégico, y comunicación clara. No es redacción de documentos Word con viñetas.

El framework amplifica eso. No hace que el PM desaparezca. Lo libera del trabajo mecánico de traducir un PRD en historias para que pueda hacer más trabajo de pensamiento. Más investigación. Más conversación con usuarios. Más reflexión estratégica sobre qué problemas merecen ser resueltos. Más tiempo pensando en cómo los equipos de producto deben trabajar en lugar de gastar energía asegurando que las historias tengan la estructura correcta.

Los datos de adopción en Mercadona Tech han sido reveladores. Los equipos que utilizan el framework de manera completa reportan un aumento del diecisiete por ciento en la velocidad de desarrollo. No porque escriban historias más rápido. Sino porque escriben historias que son claras la primera vez. Las preguntas de aclaración durante el refinamiento disminuyen. El trabajo reescrito disminuye. El desarrollo que toma un camino equivocado porque la historia fue ambigua disminuye.

Los PMs reportan que se sienten más confiados en su trabajo. Porque no están dependiendo de su intuición para saber si una historia es “buena”. Tienen criterios. Tienen un sistema. Pueden mirar una historia y saber exactamente cuáles son sus fortalezas y dónde necesita más trabajo.

Los desarrolladores reportan que es más fácil trabajar. Porque las historias especifican lo que importa, no lo que es técnicamente fácil. Porque pueden hacer preguntas de aclaración que tienen respuestas reales, basadas en investigación de usuario, no simplemente en lo que el PM recordaba haber dicho.

Pero el insight más profundo es quizás que el framework es educativo. No es una solución que simplemente se implementa y se olvida. Es algo que los PMs internalizan. A través de la repetición, a través de las preguntas que el framework les obliga a hacer, a través del estándar que el framework establece para la calidad, los PMs se vuelven mejores en su trabajo.

El Story Builder, entonces, no es simplemente la última herramienta. Es la herramienta que cierra el círculo. Porque reconoce que no todos los problemas comienzan con un PRD. Algunos comienzan con una conversación. Y el framework debería ser lo suficientemente flexible para capturar eso, mientras mantiene el mismo rigor.

La verdadera revolución del AI Mercadona User Story Framework no es que exista. Es que es posible ser tanto flexible como riguroso. Es posible acelerar la creación de historias de usuario sin sacrificar la calidad. Es posible usar IA de una manera que amplifique la capacidad humana en lugar de reemplazarla.

El PM del futuro en Mercadona Tech no será el que escriba menos documentos. Será el que piense mejor sobre qué construir y por qué. Será el que pase menos tiempo en la mecánica de escribir especificaciones y más tiempo en investigación de usuario, pensamiento estratégico, y facilitación de decisiones entre equipos. El framework le da el espacio para eso.

Y eso, finalmente, es lo que todo esto ha sido sobre. No sobre historias de usuario. Sobre cómo trabajamos. Sobre cómo creemos que el trabajo de producto debería hacerse en una empresa que entiende que la velocidad sin claridad es simplemente caos con prisa, pero la claridad sin velocidad es un análisis infinito.

El AI Mercadona User Story Framework intenta ser ambos. Claro y rápido. Riguroso y flexible. Científico y accesible. Con esta séptima herramienta, el círculo está completo. Ahora es trabajo nuestro usarlo.

La paradoja del trabajo de software: El riesgo crece más rápido que el tamaño

Hace poco más de una década, mientras trabajaba en equipos de entrega continua, Eduardo Ferro se dio cuenta de algo que parecía desafiar la lógica. Si tomabas una tarea que normalmente tardaba una semana y la hacías el doble de grande, el riesgo asociado no se duplicaba. Se multiplicaba por cuatro. A veces, incluso por diez.

Este descubrimiento no era teórico. Lo vio una y otra vez en retros, en despliegues fallidos, en historias que se arrastraban sprint tras sprint. El patrón era consistente: cuanto más grande era una historia, más cosas podían salir mal. No de manera lineal. De manera exponencial.

La razón es simple pero profunda. Una historia pequeña —una que toma tres días o menos— es un “experimento sobrevivible”. Si algo falla, el equipo puede revertir rápidamente, aprender, y seguir adelante. El costo del error es manejable.

Pero una historia de dos semanas o más es diferente. Si falla, has invertido semanas en el trabajo. Otros equipos están esperando. Revertir no es una opción elegante; es un desastre. Los equipos no revierten. Aceptan un resultado mediocre. Dedican más tiempo a arreglarlo. La historia se estira. La incertidumbre crece. El riesgo se expande.

Esta es la razón por la que Eduardo Ferro diseñó el módulo de Story Splitting que hemos usado en el AI Mercadona User Story Framework: no como un ejercicio académico de descomposición, sino como una defensa práctica contra el riesgo exponencial. Su objetivo es simple pero ambicioso: detectar automáticamente las historias que son demasiado grandes para ser seguras y descomponerlas en incrementos que sean, cada uno, independientemente valiosos, desplegables por sí solos, y completables en tres días o menos.

El primer paso: Detectar cuando el peligro está oculto en el lenguaje

Eduardo reconoció que el tamaño excesivo de una historia casi siempre se anuncia a sí mismo. No a través del número de líneas, sino a través del lenguaje. Las historias que son demasiado grandes tienden a usar palabras específicas que revelan que esconden múltiples historias dentro de una sola.

Identificó seis categorías de indicadores lingüísticos que actúan como banderas rojas.

Primera categoría: las conjunciones coordinantes. Cuando una historia dice “Los usuarios pueden subir y descargar archivos”, está ocultando dos historias completamente separadas. Subir es un flujo completamente diferente al de descargar. Tienen diferentes interfaces, diferentes casos de error, diferentes criterios de éxito.

Segunda categoría: los conectores de acción. Palabras como “gestionar”, “administrar”, “procesar”, “manejar”. Estos verbos casi siempre esconden operaciones CRUD completas. “Gestionar usuarios” es crear, leer, actualizar y eliminar usuarios. Eso son potencialmente cuatro historias.

Tercera categoría: los conectores de secuencia. Palabras como “antes”, “después”, “luego”, “entonces”. Revelan historias que agrupan pasos separables que podrían entregarse de forma independiente.

Cuarta categoría: los indicadores de alcance. Palabras como “incluyendo”, “además”, “también”. Cada palabra de este tipo es un síntoma de que alguien añadió una característica más a lo que ya era una historia completa.Quinta categoría: los indicadores de opcionalidad. Palabras como “o bien”, “opcionalmente”, “alternativamente”. Cuando una historia presenta múltiples caminos opcionales, está escondiendo historias que deberían desarrollarse por separado.

Sexta categoría: los indicadores de excepción. Palabras como “excepto”, “a menos que”, “sin embargo”, “en caso de”. La mejor práctica es desarrollar y desplegar el caso base primero —el 80% del trabajo—, y después, en historias posteriores, añadir las excepciones y los bordes. Las excepciones son donde la mayoría de los bugs se esconden.

El genio de Eduardo en el diseño del módulo fue automatizar esto. El modulo de Eduardo que usamos en el AI Mercadona User Story Framework escanea la descripción de la historia buscando exactamente estas palabras y estructuras lingüísticas. Cuando las encuentra, levanta una bandera. No para rechazar la historia, sino para alertar al equipo de que aquí hay complejidad oculta que merece atención consciente.

El segundo paso: Transformar la detección en acción

Detectar que una historia es demasiado grande es solo el primer paso. El verdadero valor está en saber cómo dividirla. Eduardo Ferro, basándose en años de experiencia con equipos en entrega continua, destiló nueve heurísticas específicas de splitting que transforman las historias monolíticas en historias pequeñas, seguras, y todavía valiosas.

Heurística 1: Comenzar por los outputs. Los outputs son entidades discretas. Si estás construyendo un reporte, puedes entregar primero la versión más simple: el resumen en texto plano. Después, los detalles. Después, la exportación a CSV. Cada uno puede validarse, desplegarse y usarse de forma independiente.

Heurística 2: Estrechar el segmento. Entregar funcionalidad completa para el grupo más pequeño posible. Si estás construyendo una característica para “todos los usuarios”, pregúntate: ¿Puedo entregarla primero solo para los empleados de tienda? Esta heurística reduce dramáticamente la complejidad.

Heurística 3: Extraer la utilidad básica. El MVP es lo mínimo. Lo bello puede venir después. Si estás construyendo cancelación en lotes, la primera historia es subir una lista de IDs. La segunda añade filtros. La tercera añade validación. Cada una entrega valor y cada una es pequeña.

Heurística 4: De lo dummy a lo dinámico. Los datos estáticos primero, después los datos reales. Si estás construyendo un dashboard, la primera historia muestra datos hardcodeados. La segunda conecta a una fuente real. La tercera añade auto-refresh. Divide el problema arquitectónico del problema de datos.

Heurística 5: Simplificar los outputs. Formatos más simples primero. Si estás generando un reporte, la primera historia genera CSV. La segunda genera PDF. La tercera lo auto-envía por email. La complejidad crece de forma predecible.

Heurística 6: Dividir por capacidad. Limitar el alcance por volumen. La primera historia procesa 100 artículos. La segunda 1,000. La tercera es ilimitada. Cada versión es completamente útil por sí misma.

Heurística 7: Dividir por ejemplo. Para cambios grandes, usar casos de uso concretos. Si estás construyendo comunicación post-cancelación, la primera historia es email a usuarios web. La segunda es SMS a usuarios móviles. La tercera es tickets en soporte. Cada una es un flujo completo y valioso de punta a punta.

Heurística 8: Aprender vs Ganar. Separar la investigación de la entrega. Si estás construyendo un sistema de recomendaciones con machine learning, la primera historia es un spike de investigación: 3 días máximo, que responde una pregunta específica. La segunda es una versión simple basada en reglas. La tercera, quizás 3 sprints después, es el modelo de ML. La investigación y la entrega son diferentes tipos de trabajo. Mezclarlas casi siempre hace que ambas sean malas.

Heurística 9: Ponerla en muletas. Entregar con pasos manuales o backends más simples. Si estás sincronizando inventario, la primera historia es subir manualmente un CSV y procesar cambios. La segunda es un script semi-automático. La tercera es sincronización completa y automática. Cada una es una historia valiosa que el negocio puede usar.

Lo que Eduardo Ferro entendió es que estas heurísticas no son arbitrarias. Cada una separa una dimensión diferente de la complejidad. Cada una permite que un equipo entregue, valide, aprenda, y luego avance.

El concepto que todo lo une: El experimento sobrevivible

Hay un concepto central que recorre todas las heurísticas: el “experimento sobrevivible”.

Una historia pequeña —tres días o menos— es un experimento. Si descubre que no es el enfoque correcto, el equipo puede revertir rápidamente. El costo del aprendizaje es bajo. El experimento falló, pero fue barato.

Una historia grande —dos semanas o más— no es un experimento sobrevivible. Si falla, la inversión es demasiado grande. El equipo no puede revertir. Tiene que aceptar una solución mediocre. Esto es lo opuesto a la agilidad.

Cuando divides una historia grande en historias pequeñas, cada una de ellas se convierte en un experimento sobrevivible. El equipo puede validar supuestos de forma frecuente, obtener feedback frecuente, y ajustar el rumbo. La suma de las historias pequeñas no es solo más manejable. Es fundamentalmente más segura.

La regla que muchos olvidan: Siempre vertical, nunca horizontal

Hay una regla en el framework de Eduardo Ferro que es tan importante, y tan frecuentemente violada, que merece énfasis especial: las divisiones siempre deben ser verticales, nunca horizontales.

Una división horizontal sería separar la historia en capas técnicas: “Implementar el endpoint de API”, “Implementar la lógica de negocio”, “Implementar la interfaz de usuario”. Esto parece lógico desde la perspectiva técnica. Pero es una trampa. Porque ninguno de estos “trabajos” entrega valor por sí solo.

Si algo sale mal en la lógica de negocio, has comprometido también el trabajo del endpoint y la interfaz. Las “historias” horizontales no llegan nunca a done. Se agrupan de nuevo cuando llega el momento del release. Y estás de vuelta a una historia grande.

La manera correcta es vertical. La historia debe cruzar todas las capas de tecnología y entregar valor completo de punta a punta. “Los usuarios pueden crear un pedido con los datos básicos” cruza la interfaz, la API, la lógica de negocio, la base de datos. Y entrega valor.

El marco de validación: Criterios que no son negociables

Una vez que tienes una propuesta de split, el framework de Eduardo ofrece cuatro criterios que cada split propuesto debe cumplir. Si no los cumple, el split no es válido.

Primero, la historia debe ser independientemente valiosa. El usuario o el negocio pueden obtener valor de esta historia completada, sin necesitar las otras historias que se dividieron de la original.

Segundo, la historia debe ser desplegable sola. Si la completaste, puedes desplegarla a producción sin desplegar las otras historias.

Tercero, la historia debe ser completable en tres días o menos. Esta es la línea que dibuja Eduardo. Si toma más de eso, tiene riesgo exponencial.

Cuarto, la historia debe entregar valor de punta a punta. No es un “componente de la infraestructura”. Es una capacidad completa que el usuario puede ejercer.

La tabla de decisión: Automatizar lo que puede ser automatizado

Una de las características más útiles del módulo es la tabla de decisión. Es una asignación explícita de indicadores lingüísticos a heurísticas de splitting.

Si encuentras “gestionar”, la tabla recomienda Heurística #1 (comenzar por outputs). Si encuentras “y”, sugiere dividir por conjunción. Si encuentras “para todos los usuarios”, recomienda Heurística #2 (estrechar el segmento).

Esto convierte lo que podría ser un ejercicio subjetivo en algo sistemático. Eduardo capturó la sabiduría que un experto en descomposición tendría y la empaquetó en reglas que cualquier equipo puede aplicar. La descomposición no es un arte. Requiere disciplina. Y eso es escalable.

En la práctica: Cómo cambia el trabajo

Sin el framework, un equipo recibe una historia como: “Gestionar usuarios del sistema, incluyendo creación, actualización y eliminación, además de reseteo de contraseñas, con soporte para roles y permisos, opcionalmente con autenticación de dos factores.” Es grande. Se estima en 21 puntos. Se estira a tres sprints. El usuario obtiene algo, pero no es exactamente lo que esperaba.

Con el framework de Story Splitting, la misma historia se convierte en:

Historia 1 (3 días): Los usuarios administradores pueden crear usuarios locales con nombre, email y contraseña inicial.

Historia 2 (2 días): Los usuarios administradores pueden editar el email y el nombre de usuarios existentes.

Historia 3 (2 días): Los usuarios administradores pueden eliminar usuarios.

Historia 4 (3 días): Los usuarios administradores pueden asignar roles (admin, editor, viewer). Permisos se aplican basándose en roles.

Historia 5 (3 días): Los usuarios pueden resetear sus propias contraseñas a través de un link enviado por email.

Historia 6 (spike de 3 días): Investigación de autenticación de dos factores.

Historia 7 (3 días, después del spike): Los usuarios pueden opcionalmente configurar 2FA con SMS.

7 historias pequeñas en lugar de 1 gigante. El equipo completa la primera en dos días. Obtiene feedback. Para el final de las dos primeras semanas, ha entregado cuatro historias completamente funcionales — el 70% del valor. Comparado con el escenario tradicional donde aún están lidiando con bugs de permisos, esto es un cambio radical.

Conclusiones: El cambio que cambia cómo pensamos sobre el trabajo

El módulo de Story Splitting del AI Mercadona User Story Framework, diseñado por Eduardo Ferro, representa algo más profundo que una técnica de descomposición. Representa un cambio en cómo pensamos sobre el riesgo en el desarrollo de software.

El riesgo no es una constante que aumenta linealmente con el tamaño. Aumenta exponencialmente. Una historia de tres días tiene un tipo de riesgo. Una historia de tres semanas tiene un tipo de riesgo completamente diferente. Es el riesgo de no poder revertir. De estar atrapado. De ser forzado a aceptar una solución mediocre.

Cuando divides historias grandes en pequeñas, no estás solo haciendo que sean más manejables. Estás transformando el tipo de riesgo que asumes. Cada pequeña historia es un experimento. El blast radius de cualquier error es pequeño.

El framework de Eduardo automatiza el proceso de identificar dónde el riesgo está oculto —en el lenguaje de las historias que escribimos—, y proporciona un conjunto sistemático de heurísticas para transformar esas historias en incrementos seguros y valiosos.

Hay una razón por la que Eduardo ha enfatizado la regla vertical vs horizontal tan fuertemente. Es porque es fácil fingir que estás siendo ágil mientras estás cometiendo el mismo error viejo: crear trabajo que no entrega valor a nadie hasta que está 100% completo. El framework te obliga a ser honesto. Cada historia debe entregar valor de verdad. Cada historia debe poder ser desplegada sola. Cada historia debe ser completable en tres días.

Cuando pones estas restricciones, algo interesante sucede. Los equipos comienzan a preguntarse: “¿Cuál es la pieza más pequeña que puedo hacer que todavía agregue valor?” En lugar de: “¿Cómo puedo hacer todo de una vez?”

Esta es la pregunta que cambia los equipos de buenos a grandes. Y es la pregunta que el Story Splitting de Eduardo te obliga a hacer.

Próximo Artículo (7 de 7): Story Builder — El módulo final del AI Mercadona User Story Framework que permite a los equipos construir historias desde cero, sin un DAPP como punto de partida, usando un diálogo estructurado que asegura que lo que crean es una historia bien formada desde el inicio.

• Artículo 1: La investigación de DAPP como puerta de entrada al desarrollo impulsado por evidencia

• Artículo 2: Cómo transformar brechas de investigación en hipótesis de Jobs-to-be-Done verificables

• Artículo 3: De Jobs-to-be-Done a User Stories: El puente conceptual entre investigación y ejecución

• Artículo 4: El constructor de historias de usuario: cómo escribir desde cero

En este artículo, abordaremos el desafío que enfrenta cualquier organización de tecnología con múltiples equipos: ¿cómo asegurar consistencia en la calidad de las historias de usuario cuando tienes 12 verticales, decenas de historias por sprint, y cada Product Manager trae su propia intuición sobre qué es “bueno”?

La respuesta no es delegar la evaluación completamente al framework, ni tampoco ignorar el juicio humano experto. Es, en su lugar, crear un sistema compartido de evaluación que sea simultáneamente riguroso y accesible, que eleve los estándares sin paralizar la ejecución, y que permita a los equipos aprender de los patrones que se repiten una y otra vez en el pipeline.

Bienvenidos al Entrenador de Calidad (Quality Coach).

El Problema Invisible de la Inconsistencia

Hace pocos meses, durante una reunión de revisión de backlogs, sucedió algo que probablemente reconocerás si trabajas en una organización con múltiples equipos de producto.

Un Product Manager presentó una historia de usuario que comenzaba así: “Como usuario, quiero poder ver mis pedidos previos para poder realizar compras más rápidas.” El equipo de ingeniería hizo preguntas técnicas sobre la arquitectura. El equipo de diseño preguntó sobre wireframes. Pero nadie hizo la pregunta más fundamental: ¿Sabemos realmente si esto resolverá el problema del usuario?

Cuando examinas esa historia con rigor, descubres que no hay evidencia de cuántos usuarios realmente abandonan el flujo de compra por esta razón, no se especifica cuál es el perfil exacto del usuario, la métrica de éxito es ambigua, y no hay plan para validar experimentalmente si la hipótesis era correcta.

Pero la historia fue aprobada de todas formas. Porque se veía “suficientemente buena.”

En Mercadona Tech, con 12 verticales funcionando en paralelo y decenas de historias en cada sprint, esta inconsistencia se multiplica. El equipo de Checkout trabaja con un estándar de calidad. El equipo de Tienda trabaja con otro. El equipo de Primera Milla con otro diferente. No por incompetencia, sino porque no existe un framework compartido que defina qué es realmente “una buena historia de usuario.”

El Entrenador de Calidad (Quality Coach) existe para resolver exactamente esto: crear un sistema de evaluación que sea lo suficientemente riguroso para garantizar que las historias representen experimentos reales sobre comportamiento del usuario, pero lo suficientemente flexible para respetar el contexto, la urgencia y las realidades operativas de cada equipo.

La Filosofía: Calidad como Experimento, no como Checklist

Antes de sumergirnos en las seis dimensiones de evaluación, necesitamos establecer una premisa filosófica que guía todo el trabajo del Entrenador de Calidad.

La mayoría de los equipos evalúan historias de usuario usando un checklist: ¿Tiene un usuario? Sí. ¿Tiene un beneficio? Sí. ¿Es accionable? Sí. Siguiente.

Pero esto trata la historia como un artículo para entregar, no como una hipótesis para validar.

Jobs-to-be-Done, el framework que sustenta todo el marco de historias de usuario de IA Mercadona, nos enseña que el trabajo verdadero no es la característica que entregamos. El trabajo verdadero es el cambio de comportamiento que queremos producir en el usuario. Una vez que aceptas esa premisa, la pregunta sobre calidad cambia fundamentalmente.

Ya no preguntamos: “¿Está bien escrita?”

Preguntamos: “¿Es verificable como un experimento? ¿Podemos observar si el usuario realmente cambió su comportamiento de la manera que esperamos?”

Esta perspectiva viene del libro “50 Quick Ideas to Improve Your User Stories” de Gojko Adzic y David Evans, dos de los pensadores más influyentes en evolución del movimiento ágil. Su insight central es que una buena historia de usuario no es una promesa vaga, sino una hipótesis comprobable sobre cómo el usuario se comportará diferente después de que entregues la solución.

El Entrenador de Calidad formaliza esta filosofía en seis dimensiones medibles.

Las Seis Dimensiones de Evaluación

El Entrenador de Calidad evalúa cada historia de usuario en una escala de 0 a 10 en cada una de estas dimensiones. No es un enfoque de “pasar/fallar,” sino un sistema diagnóstico que te dice exactamente dónde están las debilidades de la historia y qué se necesita para fortalecerla.

Dimensión 1: Contexto JTBD y Evidencia del Problema

¿Realmente entendemos el trabajo que el usuario necesita hacer?

Esta es la dimensión más fundamental. Una historia que no está anclada en una comprensión profunda del trabajo del usuario es, en el mejor de los casos, un disparo a ciegas. En el peor, es trabajo que nadie quería hacer en primer lugar.

Una buena puntuación en esta dimensión requiere tres tipos de evidencia:

Primero, evidencia cualitativa: Observaciones directas de usuarios diciendo que necesitan hacer este trabajo. No es una encuesta. Es alguien en el campo viendo frustración real. Idealmente, esta evidencia viene del PRD, que a su vez proviene de investigación Mom Test (ver Artículo 1).

Segundo, evidencia cuantitativa con baseline y target: Si el trabajo es importante, debería ser observable en los datos. ¿Cuántos usuarios enfrentan este problema hoy? ¿Cuál es el baseline? ¿A qué número queremos llegar? Una historia sobre “mejorar la experiencia de búsqueda” podría tener un baseline de “40% de búsquedas no producen compra” con un target de “reducir a 25%.”

Tercero, observación del terreno (Gemba): Idealmente, alguien del equipo ha visitado el contexto real donde ocurre el trabajo. Si es un trabajo de logística, alguien estuvo en el almacén. Si es un trabajo de tienda, alguien estuvo en el punto de venta. Esto no siempre es posible, pero cuando es posible, proporciona insights que ningún análisis de datos puede dar.

Una historia con puntuación 9 en esta dimensión te dice exactamente por qué el trabajo importa, con números que lo respaldan, y con observaciones de campo que lo hacen real. Una historia con puntuación 3 dice: “Creemos que los usuarios podrían querer esto” y espera que tengas fe.

Dimensión 2: Especificidad del Usuario

¿Sabemos realmente quién es el usuario de esta historia?

Aquí llegamos a uno de los antipatrones más comunes en la industria: la historia de usuario genérica. “Como usuario, quiero poder buscar productos para encontrar lo que necesito.” Este es un ejemplo de lo que llamamos una “historia fantasma.” Es tan genérica que podría aplicar a casi cualquier plataforma digital.

El framework de Jobs-to-be-Done resuelve esto a través de lo que Wendell llama las cuatro preguntas de usuario específico:

1. ¿Quién exactamente es este usuario? No “usuarios de móvil.” Específicamente: “Mujeres que compraban entre dos y tres veces a la semana en la tienda física, y están experimentando con compra online por primera vez.”

2. ¿En qué contexto está intentando hacer su trabajo? “A las 7 AM en casa mientras se prepara para el trabajo, usando 5-10 minutos para hacer un pedido rápido.”

3. ¿Qué otras alternativas está considerando? “Podría seguir yendo a la tienda físicamente, podría usar Amazon Fresh, podría pedir a través de WhatsApp.”

4. ¿Qué obstáculos enfrenta para hacer su trabajo? “No sabe qué categorías están disponibles online, tarda 20 minutos en buscar lo que necesita.”

Una historia que no puede responder estas cuatro preguntas específicamente tiene una puntuación máxima de 5 en esta dimensión. Este es un hard rule, no una sugerencia. Porque sin especificidad de usuario, no puedes medir si la solución realmente funciona para alguien.Dimensión 3: Cambio de Comportamiento Cuantificable

¿Qué hará diferente el usuario después de usar nuestra solución?

Esta es la dimensión donde muchas historias de usuario tradicionalmente fracasan. Porque la mayoría de las historias definen el “beneficio” de manera abstracta. “Como vendedor de tienda, quiero un dashboard de inventario en tiempo real para tener mejor visibilidad.” ¿Mejor visibilidad? ¿Eso qué significa?

Con la óptica de Jobs-to-be-Done y la filosofía de experimento del Entrenador de Calidad, necesitamos traducir esto a cambio de comportamiento observable:

“Como vendedor de tienda en turno de mañana, quiero recibir alertas automáticas cuando un producto se queda sin stock para que pueda reabastecer en los próximos 15 minutos en lugar de esperar a la revisión manual cada hora. Baseline: 3 horas de espera promedio. Target: 15 minutos.”

Observa lo que cambió: el usuario es específico (vendedor en turno de mañana), el comportamiento es específico (recibir alertas, actuar rápido vs. revisar manualmente), y es cuantificable (15 minutos vs. 3 horas).

Esto es una historia que puedes validar experimentalmente. Despliegas el feature, y después de dos semanas observas: ¿Los vendedores realmente están reabasteciendo en 15 minutos en lugar de 3 horas?

Una historia sin cambio de comportamiento cuantificable tiene una puntuación máxima de 5 en esta dimensión. Este es otro hard rule. Sin cambio de comportamiento cuantificado, es solo un feature backlog, no una historia de usuario.

Dimensión 4: Zona de Control

¿Está el equipo en control de lo que necesita entregar para lograr este cambio de comportamiento?

Este es un tema sutil pero crítico. Imaginemos esta historia: “Como centro de distribución, quiero que los proveedores entreguen con exactitud 99% de las unidades pedidas para que nuestro sistema de picking sea más eficiente.”

Este es un problema real. Pero el equipo de tecnología no controla a los proveedores. Una historia en esta situación tiene que redefinirse para estar dentro de la zona de control del equipo:

“Como especialista de relaciones con proveedores, quiero un dashboard que muestre exactitud de entregas por proveedor en tiempo real para poder identificar patrones y contactar proactivamente a proveedores con bajo desempeño.”

Ahora el equipo controla lo que importa: generar datos confiables, alertar, facilitar la comunicación. El cambio de comportamiento del proveedor es el segundo efecto, no el primero.

Dimensión 5: Restricciones de Tiempo

¿Es la urgencia real o artificial?

He visto esto en cientos de organizaciones: llega el final del sprint, y de repente todo es urgente. Cuando más del 50% de las historias de un sprint tienen deadlines cercanas, algo está mal. No es un problema de ejecución. Es un problema de priorización.

El Entrenador de Calidad observa las restricciones de tiempo en dos dimensiones: Primero, ¿es la urgencia real o percibida? “Perderemos 10k en ventas por día si no lo entregamos” es real. “El stakeholder quiere verlo en la review” es artificial. Segundo, ¿es síntoma de un problema sistémico? Un sprint donde cada historia tiene presión de tiempo es un patrón que necesita atención.

Dimensión 6: Experimento Sobrevivible

¿Qué haremos si nos equivocamos?

Esta es la dimensión más futurista, pero también la más importante para una organización que quiere escalar. Una buena historia de usuario debería incluir desde el principio:

1. La hipótesis explícita: Lo que creemos que va a pasar

2. La métrica de éxito: Cómo sabremos si tuvimos razón

3. El plan de rollback: Cómo revertiremos si nos equivocamos

4. El plan de validación: Cuántos usuarios, durante cuánto tiempo, antes de la entrega completa

Un ejemplo de una historia que puntúa 9 en esta dimensión: “Hipótesis: Mostrar productos frecuentemente comprados juntos en la página de detalles del producto aumentará la cesta promedio de compra en 15% para usuarios que repiten compra semanal. Métrica de éxito: AOV sube a 15% en grupo de test vs. control después de 2 semanas. Plan B: Si AOV no aumenta, revertir automáticamente a control. Validación: 10,000 usuarios en grupo de test durante 14 días.”

Una historia que puntúa 3: “Queremos mostrar productos relacionados en la página de detalles del producto.” ¿Qué hipótesis estamos validando? No se sabe. ¿Cuándo sabemos que fue exitoso? Cuando termine el sprint.

Los Siete Antipatrones de Historia Débil

A través de analizar cientos de historias de usuario en Mercadona Tech, hemos identificado patrones recurrentes de debilidad. No son errores en sí mismos, sino síntomas de historias que no han sido pensadas como experimentos verificables sobre cambio de comportamiento.

Antipatrón 1: El Usuario Fantasma

“Como usuario, quiero poder filtrar por marca para buscar más fácilmente.” El usuario aquí es tan genérico que es invisible. ¿Quién? ¿Un usuario habitual que compra dos veces a la semana? ¿Un nuevo usuario que no sabe cuáles son las marcas disponibles? La solución es incluir el proto-personaje completo, respondiendo las cuatro preguntas de especificidad de usuario de Wendell.

Antipatrón 2: El Beneficio Fantasma

“Para poder encontrar lo que necesito.” ¿Qué significa “encontrar”? ¿Menos clics? ¿Menos tiempo? ¿Resultados más relevantes? Sin una definición operacional del beneficio, no puedes validar experimentalmente si la solución funcionó.

Antipatrón 3: La Historia Falsa

“Como equipo de ingeniería, quiero refactorizar la base de datos para poder tener mejor performance.” ¿Quién es el usuario aquí? No es el equipo de ingeniería. Es el usuario final que espera una aplicación más rápida. Una historia verdadera sería: “Como usuario que hace búsquedas frecuentes de ofertas en categoría Frescos, quiero que los resultados se carguen en menos de 2 segundos (vs. los actuales 5 segundos) para poder navegar sin frustración.”

Antipatrón 4: La Solución como Necesidad

“Quiero un botón de favoritos en la página de producto.” Estamos describiendo la solución técnica, no el trabajo del usuario. ¿Por qué el usuario necesita favoritos? ¿Es para comparar productos? ¿Es para volver a productos vistos anteriormente? Cada respuesta es una historia diferente, con métricas de éxito diferentes.

Antipatrón 5: Entrega Fuera de Control

“Como gestor de centros, quiero que el sistema de proveedores externo envíe datos de inventario cada hora.” El equipo no controla el sistema externo. La historia está configurada para fracasar porque está fuera de la zona de control del equipo.

Antipatrón 6: Todo es Urgente

Si tu sprint tiene 80% de las historias con deadlines apretadas, tu priorización está rota. No es un problema de ejecución. Una historia bajo presión de tiempo real es diferente de una sprint donde todo es urgente por defecto.

Antipatrón 7: División Técnica Horizontal

“Como desarrollador frontend, quiero crear la interfaz de filtros. Como desarrollador backend, quiero implementar los endpoints de filtros.” Lo que debería ser una única historia de usuario se divide en tareas técnicas de capas. Puedes tener dos “historias” completadas y el usuario seguir sin tener la funcionalidad de punta a punta.

El Mecanismo: Evaluación Rigurosa sin Rigidez

El Entrenador de Calidad utiliza las seis dimensiones para evaluar cada historia en una escala de 0-10. Pero el mecanismo es importante: no es un juicio de “bueno” o “malo.” Es un diagnóstico.

Una historia que puntúa 32/60 (53%) no es rechazada. Se dice: “Aquí está el diagnóstico. La historia es débil en especificidad de usuario, débil en cambio de comportamiento cuantificado, fuerte en contexto JTBD. Esto significa que entiendes el problema real, pero aún necesitas clarificar exactamente quién es el usuario y qué comportamiento esperas cambiar.”

Entonces el Entrenador proporciona una reescritura sugerida de la historia, reformulada en lenguaje JTBD, que el Product Manager puede adoptar, adaptar, o descartar.

Aquí es donde la filosofía es crucial: El Entrenador respeta la autonomía de decisión del PM, pero no respeta la vaguedad. Si decides ignorar el feedback del Entrenador, puedes hacerlo. Pero hazlo con los ojos abiertos, sabiendo exactamente dónde está el riesgo.

Ejemplo Completo: Reescritura de Una Historia Débil

Vamos a tomar una historia de usuario tal como aparecería en un backlog real, y mostrar exactamente cómo el Entrenador de Calidad la diagnostica y propone una reescritura.

Historia Original:

“Como usuario de la aplicación de compra, quiero poder ver recomendaciones personalizadas de productos en mi inicio de sesión para poder descubrir productos nuevos y aumentar mis compras.”

Diagnóstico del Entrenador:

Dimensión/Puntuación/Observación

D1: Contexto JTBD 4/10 Hay un problema implícito (”descubrir productos nuevos”) pero sin evidencia cuantificada.

D2: Especificidad de Usuario 2/10 ”Usuario de la aplicación de compra” es extremadamente genérico. Hard rule: máximo 5 sin especificidad.

D3: Cambio de Comportamiento 3/10 ”Descubrir productos nuevos” y “aumentar mis compras” son beneficios abstractos. Hard rule: sin cuantificación clara, máximo 5.

D4: Zona de Control 7/10 El equipo controla la recomendación y el display. Mayormente controlable.

D5: Restricciones de Tiempo 8/10 Sin deadline urgente aparente. Puede desarrollarse con rigor adecuado.

D6: Experimento Sobrevivible 2/10 No hay hipótesis explícita, no hay plan de validación, no hay métrica de éxito clara, no hay plan B.

Puntuación Total: 26/60 (43%)

Feedback del Entrenador:

“Esta historia toca un tema legítimo (personalization aumenta valor), pero está muy poco especificada. No sabemos quién es el usuario exacto, no sabemos en qué contexto está usando recomendaciones, y no sabemos cómo mediremos el éxito. Recomendación: Reformular incluyendo proto-personaje específico, contexto, cambio de comportamiento cuantificado, y métrica de validación.”

Historia Reescrita (Sugerencia del Entrenador):

“Como cliente en categoría de Frescos que históricamente compra el mismo tipo de productos cada semana (plátanos, leche, queso), quiero recibir recomendaciones de nuevos productos en las mismas categorías al iniciar sesión para poder descubrir ofertas o variantes que se alineen con mis preferencias sin incrementar el tiempo de búsqueda. Contexto: Cliente que dedica 8-10 minutos a completar su pedido. Hipótesis: Mostrar 3-5 recomendaciones de ‘también te pueden gustar’ en la pantalla de inicio aumentará el AOV (Average Order Value) en al menos 8% en este segmento, sin aumentar el tiempo de compra (permanecerá menos de 12 minutos). Métrica: Comparar AOV grupo test vs. grupo control durante 2 semanas. Plan de validación: 5,000 usuarios en grupo test. Plan B: Si AOV no aumenta en 5 días, revertir recomendaciones a grupo de control.”

Puntuación de la Historia Reescrita:

DimensiónPuntuaciónObservación D1: Contexto JTBD7/10Hay hipótesis clara, hay segmento de usuario identificado. Falta evidencia de campo, pero es sólida. D2: Especificidad de Usuario9/10Específico: cliente de Frescos que repite compra semanal. Proto-personaje claro. D3: Cambio de Comportamiento8/10Cuantificado: AOV aumenta 8%. Contexto: sin aumentar tiempo de compra. Claramente medible. D4: Zona de Control8/10Equipo controla recomendaciones y display. AOV es métrica observable del sistema. D5: Restricciones de Tiempo9/102 semanas de test. Plan de decisión claro. No artificial. D6: Experimento Sobrevivible9/10Hipótesis explícita, métrica de éxito, plan de validación, plan B. Es un experimento real.

Puntuación Total: 50/60 (83%)

Casos de Uso: Evaluar Historias en Cualquier Momento del Pipeline

Lo que hace al Entrenador de Calidad especialmente valioso es que funciona en múltiples puntos del pipeline, no solo para nuevas historias.

Caso 1: Evaluación Temprana (PRD → Story)

Durante la fase de investigación (Artículos 1-2), el Entrenador puede evaluar los PRDs para asegurar que contienen la evidencia necesaria. Un PRD que no tiene suficiente contexto JTBD para puntuar mayor a 6 en Dimensión 1 significa que necesitas más investigación antes de escribir historias.

Caso 2: Evaluación en Escritura (Story Builder)

Mientras escribes historias de usuario (Artículo 4), el Entrenador proporciona feedback en tiempo real. “Esta versión puntúa 4 en especificidad de usuario. Intenta nombrar el segmento exacto.”

Caso 3: Evaluación en Sprint (Historias Existentes)

El Entrenador puede evaluarse directamente desde Jira, incluso historias que fueron escritas sin el framework. Un Product Manager puede correr el Entrenador contra su backlog actual, ver dónde están los problemas, y enfocarse en las historias débiles para mejoramiento.

Caso 4: Benchmarking Entre Equipos

Cuando corres el Entrenador contra historias de 12 equipos diferentes, emergen patrones. El equipo de Tienda tiende a ser fuerte en especificidad de usuario pero débil en cambio de comportamiento cuantificado. El equipo de Primera Milla tiende a ser fuerte en contexto JTBD pero débil en experimento sobrevivible.

Estos patrones son datos de coaching. Permiten que los líderes de producto identifiquen dónde entrenar al equipo, qué hacer diferente, cómo transferir mejores prácticas entre equipos.

La Paradoja de la Consistencia

Aquí está la paradoja deliciosa del Entrenador de Calidad: Proporciona consistencia sin requerir rigidez.

En organizaciones tradicionales, intentas imponer consistencia forzando un estándar. “Todas las historias DEBEN tener este formato.” El resultado es que las historias son uniformes pero vacías. Todos cumplen con el checklist. Pero nadie realmente está pensando.

El Entrenador hace lo opuesto. Proporciona un sistema de diagnóstico que es lo suficientemente flexible para respetar contextos diferentes, pero lo suficientemente riguroso para garantizar que ciertas debilidades sean transparentes.

Una historia en Checkout puede priorizar diferente que una en Tienda. Pero ambas responden las mismas preguntas fundamentales: ¿Quién exactamente es el usuario? ¿Qué comportamiento espera cambiar? ¿Cómo validaremos que nuestra hipótesis fue correcta?

Porque si estos tres puntos no están claros, entonces no es realmente una historia de usuario. Es una tarea técnica disfrazada de historia.

La Importancia de “Especificidad de Usuario” y “Cambio de Comportamiento” como Hard Rules

Es importante enfatizar dos de las seis dimensiones porque emergen como los mayores predictores de fracaso en historias de usuario tradicionales.

Dimensión 2 (Especificidad de Usuario): El cambio de comportamiento observable, medible, requiere un usuario específico. Porque diferentes usuarios tienen diferentes contextos, diferentes limitaciones, diferentes motivaciones. Una historia que dice “usuario” en lugar de “usuario que compra en Frescos dos veces a la semana” es una historia que no puedes validar experimentalmente. Por eso tiene un hard rule: máximo 5 sin especificidad.

Dimensión 3 (Cambio de Comportamiento Cuantificado): El cambio de comportamiento es lo que distingue entre un feature backlog y una hipótesis verificable. “Mejorar la experiencia” es un feature backlog. “Reducir el tiempo de búsqueda de 180 segundos a 60 segundos” es una hipótesis verificable. Por eso tiene un hard rule: máximo 5 sin cuantificación.

Estos hard rules no son arbitrarios. Son las condiciones mínimas para que una historia sea experimentable.

Antipatrones en Mercadona Tech: Aprendizajes Específicos

En los meses que el Entrenador de Calidad ha estado operacional, hemos visto patrones específicos en cómo diferentes equipos de Mercadona Tech necesitan mejorar.

Tienda (Shop): Tendencia fuerte a cometer antipatrón #1 (Usuario Fantasma) porque el usuario es “vendedor” o “cliente.” Necesidad de entrenar en diferenciación de proto-personajes por turno, por antigüedad, por tipo de tienda.

Primera Milla: Tendencia a cometer antipatrón #3 (Historia Falsa) porque a menudo las historias están escritas desde la perspectiva del equipo técnico en lugar del usuario final (repartidor, cliente, operador de logística).

Ser Humano: Mezcla de antipatrón #2 (Beneficio Fantasma) con antipatrón #6 (Todo es Urgente). Historias frecuentemente bajo presión de tiempo, lo que significa menos tiempo para especificar. Necesidad de proteger tiempo de planning.

Colmena: Tendencia a antipatrón #4 (Solución como Necesidad) porque la mayoría del trabajo es automatización/reposición. Requiere pasos explícitos para conectar la solución técnica con el cambio de comportamiento del usuario humano (reponedor, operador, gestor).

Estos patrones no son críticos. Son observaciones que permiten coaching específico.

Conclusiones: De la Intuición a la Disciplina

A lo largo de cinco artículos de esta serie, hemos construido un framework completo para transformar investigación de usuarios en historias de usuario de alta calidad que actúen como experimentos sobre cambio de comportamiento.

Primero, aprendimos a investigar PRDs con rigor científico, usando Mom Test para validar hipótesis directamente en el campo (Artículo 1).

Segundo, aprendimos a traducir esa investigación en Jobs-to-be-Done, el lens conceptual que nos permite ver el trabajo verdadero que el usuario está intentando hacer (Artículo 2).

Tercero, aprendimos a hacer puente entre Jobs-to-be-Done y User Stories, manteniendo la especificidad y rigor a través de la transición (Artículo 3).

Cuarto, aprendimos a escribir historias de usuario desde cero cuando no tenemos un PRD, usando un proceso conversacional que extrae claridad (Artículo 4).

Ahora, aprendemos a evaluar historias consistentemente usando un sistema que es simultáneamente riguroso y flexible.

Lo que emerge de estos cinco pasos es una transformación organizacional profunda. Ya no estás entregando features basado en intuición de PM. Estás ejecutando hipótesis sobre cambio de comportamiento, validadas con evidencia de investigación, escritas con especificidad, evaluadas contra estándares claros.

El Entrenador de Calidad no es un policía que rechaza historias débiles. Es un coach que dice: “Aquí está exactamente dónde tu historia es débil. Aquí está lo que necesitas hacer para reforzarla. Tienes la autonomía de decidir si quieres hacer el esfuerzo.”

Algunos equipos lo harán. Otros usarán el diagnóstico para tomar decisiones conscientes sobre riesgo. Ambas opciones son válidas. Lo que no es válido es pretender que una historia vaga es una historia de usuario simplemente porque está en el backlog.

En Mercadona Tech, con 12 verticales en paralelo, la diferencia entre intuición y disciplina en la calidad de historias de usuario es la diferencia entre ejecutar y ejecutar con confianza.

El Entrenador de Calidad existe para hacer esa diferencia tangible y medible.

Próximo Artículo (6 de 7): Síntesis e Integración — Cómo todas las piezas del Marco de Historias de Usuario de IA Mercadona trabajan juntas en un workflow real, y cómo ha cambiado la forma en que Mercadona Tech ejecuta producto.

Imagina este escenario común en cualquier equipo de producto: Acabas de terminar una ronda de investigación rigurosa con clientes reales. Tienes notas ricas, videos de sesiones, transcripciones de conversaciones donde los usuarios explicaban exactamente qué estaban tratando de lograr, cuándo lo intentaban, qué les frustraba y qué resultados querían ver. Los insights están ahí, tangibles, cargados de contexto.

Entonces llega el momento de escribir las user stories para el sprint. Y aquí es donde sucede algo mágico y terrible a la vez: toda esa riqueza desaparece.

Lo que comenzó como “Una madre que intenta completar su compra mientras sus hijos corren entre los pasillos, y tiene miedo de olvidar items de su lista porque está distraída” se convierte en: “Como cliente, quiero poder acceder a mi carrito rápidamente, para completar mi compra.” El usuario se vuelve genérico. El comportamiento cambia desaparece. La frustración emocional se evapora. Los criterios de éxito se vuelven vagos. Y lo peor: el equipo de ingeniería recibe una descripción de una característica (carrito rápido), no de un resultado que el usuario necesita lograr.

Este es el problema central que resuelve el AI Mercadona User Story Framework en su segundo acto: convertir research validado en stories estructuradas sin perder información.

En este artículo —cuarto de una serie de siete sobre cómo construimos un framework de user stories que honra la research y produce historias implementables— te mostraremos exactamente cómo evitar que tu research valiosa se diluya en el camino hacia el backlog.

Ahora aprenderás tres marcos integrados que, usados juntos, garantizan que nada se pierda en la traducción.

Parte 1: Por Qué la Información se Pierde en la Traducción

Antes de mostrar cómo retener información, necesitamos entender por qué desaparece. Hay tres culpables principales.

El Culpable 1: La Abstracción sin Raíces

Cuando un PM comienza a escribir una story después de investigación, enfrenta una presión cognitiva inmediata: necesita abstraer, generalizar, “crear una historia que aplique a muchos usuarios.” Piensa que si escribes sobre María, una madre específica en Castellón con dos niños, un presupuesto de 40€ y el hábito de comprar los martes, estarás siendo demasiado anecdótica.

Pero aquí está el problema: esa especificidad no es una limitación, es tu mayor activo. María representa un patrón. Lo que la hace específica (el contexto de presión temporal, la carga cognitiva, el punto de dolor de olvidar items) es exactamente lo que hace su job relevante y observable.

Cuando el PM “abstracts away” estos detalles para crear un “usuario promedio,” lo que realmente está haciendo es desechar información.El Culpable 2: La Solución Oculta en el Comportamiento

Muy frecuentemente, lo que comienza como “el cliente quiere poder completar su compra sin olvidar nada” es en realidad un job expresado como solución. El cliente nunca dijo “quiero una lista de favoritos.” Lo que el cliente dijo fue: “Me olvido de items. Tengo miedo de llegar a casa y darme cuenta de que falta algo.”

El job es “asegurarme de que tengo todo lo que necesito para alimentar a mi familia esta semana.” Pero cuando el PM escribe “quiero una lista de favoritos” en la story, ha colapsado el job en una característica.

El Culpable 3: Las Dimensiones Ocultas de Motivación

Cuando María dice “tengo miedo de olvidar algo,” está expresando una motivación emocional de seguridad. Cuando dice “no quiero que mi familia se enfade conmigo por olvidar cosas,” está expresando una motivación social. Cuando dice “necesito ser eficiente porque solo tengo 20 minutos,” está expresando una motivación funcional.

Estas tres dimensiones —funcional, emocional, social— determinan completamente qué experiencia funcionará para María. Pero en la story tradicional, todas esas dimensiones se colapsan en una frase genérica: “Como cliente, quiero X para Y.”

Parte 2: La Trilogía de Marcos que Detiene la Pérdida

El framework de Mercadona resuelve estos tres problemas usando tres marcos integrados. Ninguno funciona solo. Juntos, son prácticamente a prueba de “desvinculación de información.”

Marco 1: JTBD Reforzado — El Contenedor de Contexto Completo

La versión reforzada de Jobs to Be Done que usamos en Mercadona extiende la simple estructura “cuando X, quiero Y, para Z.” Una JTBD Reforzada contiene ocho elementos:

A. Job Principal (El Qué)

La tarea fundamental que el usuario está tratando de lograr. Debe ser un job, no una solución. Un job responde “¿Por qué?” Un user puede hacer el job de múltiples formas.

B. Struggle (La Fricción Actual)

El dolor concreto, específico, frecuentemente expresado en citas literales de investigación. Preserva la intensidad emocional en múltiples capas: Operativa (”Me olvido items”), Emocional (”Me arrepiento”), Social (”Mi familia me reclama”), Contextual (”Especialmente cuando estoy con los niños”).

C. Trigger (El Cuándo)

El momento específico en el que el job se vuelve urgente. Determina completamente el contexto de diseño. El trigger debe ser observable y verificable.

D. Outcome (El Resultado Deseado)

El estado futuro específico que el usuario quiere ver. Los outcomes deben ser cuantificables o al menos observables.

E. Tres Dimensiones de Motivación

Motivación Funcional: ¿Qué quiere lograr en términos concretos, medibles?

Motivación Emocional: ¿Cómo quiere sentirse?

Motivación Social: ¿Cómo quiere ser percibida?F. Anxieties y Barriers

Los obstáculos que previenen que el cambio suceda:

• Ansiedad: “¿Y si la lista se borra?” “¿Y si el sistema no está actualizado?”

• Barrier operativa: “No sé si este producto está disponible en mi tienda”

• Barrier contextual: “En el supermercado no tengo WiFi estable”

Estas ansiedades y barriers no son “cosas que resolver después.” Son restricciones del diseño ahora.

G. Validación: Job vs Solución

Un elemento metacognitivo. El PM debe verificar continuamente: “¿Es esto realmente un job o una solución?” Herramienta: “¿Podría un usuario lograr esto de múltiples formas?” Si la respuesta es NO, has colapsado la solución en el job.

H. Rastreo de Fuente

Cada elemento de la JTBD Reforzada debe poder ser trazado hasta la evidencia de research. Cuando alguien cuestiona la story más tarde, puedes volver a la fuente.

Marco 2: Wendel Checklist — Las Cuatro Preguntas Que Revelan si tu Usuario es Real

Stephen Wendel identifica cuatro factores críticos que determinan si un usuario realmente hará el cambio de comportamiento que el producto espera.

Pregunta 1: ¿Cuál es la Experiencia Previa del Usuario?

¿Ha intentado algo similar antes? ¿Cómo le fue? Un usuario sin experiencia previa mapeada es una bandera roja.

Pregunta 2: ¿Cuál es la Relación del Usuario con el Producto Actual?

¿Usa el producto? ¿Confía en él? Determinará la fricción de adopción.

Pregunta 3: ¿Cuál es la Motivación Situacional del Usuario?

¿Qué sucede en el contexto específico que lo hace ahora motivado a cambiar? La motivación no es estática.

Pregunta 4: ¿Cuál es el Impedimento Actual que Previene el Cambio?

¿Qué específicamente está frenando el cambio ahora? La solución debe diseñarse para superar este impedimento específico.

Si no puedes responder completamente todas cuatro preguntas para tu usuario, tu story no está lista.

Marco 3: Behavior Change — De NOW a NEW

¿Qué cambia realmente cuando el usuario interactúa con tu solución? Muchas user stories describen características, no cambios de comportamiento. Un cambio de comportamiento responde: ¿Qué estaba haciendo el usuario ahora? ¿Qué hará diferente? ¿Cuánto cambiará?

Componente A: NOW — El Comportamiento Actual, Documentado

Para María: “Cada martes intenta recordar mentalmente qué necesita comprar. A menudo falla, olvidando items importantes. Para compras grandes, realiza una lista en papel que frecuentemente pierde. El resultado: olvidar alrededor del 15-20% de los items planeados.” La riqueza está en la especificidad: qué intenta, cómo falla, con qué frecuencia.

Componente B: NEW — El Comportamiento Deseado

NEW debe ser explícito sobre qué comienza, qué se detiene, qué cambia.

START: María comienza a usar la app de lista en el contexto del supermercado.

STOP: María deja de intentar memorizar completamente.

DIFFERENT: María cambia su relación con el riesgo de olvidos. De “es inevitable” a “es controlable.”

Componente C: Rangos de Cambio

Mínimo (aceptable): Usa la lista para el 30% de compras. Olvidos se reducen 50%.

Target (esperado): Usa la lista para el 70%. Olvidos se reducen 80%.

Over-top (aspiracional): Usa la lista para el 90%. Olvidos se reducen 95%.

Tres niveles porque diseño es una práctica bajo incertidumbre. Si defines solo “target,” cuando obtuviste “mínimo,” tu equipo pensará que fracasó.

Parte 3: Integrando los Tres Marcos — De Research a Stories

El workflow es: Input (JTBD Reforzado + Wendel Checklist + Behavior Change mapeado) → Proceso (PM estructura la información en Story Format) → Output (Story legible por ingeniería y diseño que mantiene toda la riqueza contextual).

La Estructura de Story que Retiene Información

Una story creada correctamente tiene esta estructura: EPIC (Job Principal), STORY (Nombre específico del comportamiento), ACCEPTANCE CRITERIA (Given/When/Then con Trigger, NEW behavior y Observable outcome), CONTEXT (Wendel Checklist), MOTIVATIONS (Funcional, Emocional, Social), BARRIERS (Anxieties e impedimentos), EVIDENCE (Rastreo a investigación), SUCCESS METRICS (Mínimo / Target / Over-top).

Cada elemento del marco aparece en la story. No hay colapso de información. El equipo de ingeniería puede leer “Acceptance Criteria” y entender exactamente qué construir. El equipo de diseño puede leer “Context” y entender por qué el usuario necesita lo que necesita.

Ejemplo Concreto: De JTBD a Story

Tomando la JTBD de María (madre de dos niños que compra los martes bajo presión de tiempo), la story resultante incluye: Epic “Confidence in Grocery Completeness”, Story “Load and Review Favorite List Before Shopping”, con criterios de aceptación que especifican carga en menos de 2 segundos, funcionalidad offline, persistencia de datos. El contexto incluye su experiencia previa fallida con listas y su relación con la app. Las métricas de éxito definen tres niveles: Mínimo (30% adopción, 50% reducción olvidos), Target (70% adopción, 80% reducción), Over-top (90% adopción, 95% reducción).

La riqueza de información retenida es total. El equipo de ingeniería sabe qué construir. El equipo de diseño entiende por qué María rechazaría algo complicado. El PM puede explicar por qué esta story es importante.

Parte 4: Puntuación 6D — Evaluando la Salud de tu Story

No todas las stories son iguales. El framework incluye un sistema de puntuación en seis dimensiones que evalúa la confianza en cada story:

Dimensión 1: JTBD Context (0-10)

¿Cuán rico y específico es el contexto de la JTBD? Stories de investigación real típicamente puntúan 8-10. Las especulativas puntúan 2-3.

Dimensión 2: User Specificity (0-10)

¿Cuán específico es el usuario? ¿Puedes describirlo sin decir “usuario” o “cliente”?

Dimensión 3: Behavior Change Clarity (0-10)

¿Cuán claro es el cambio de comportamiento? ¿Puedes describir observable NOW vs NEW?

Dimensión 4: Control Zone (0-10)

¿Cuánto de este cambio está dentro del control de tu producto?

Dimensión 5: Time Constraints (0-10)

¿Cuán bien entiendes las restricciones de tiempo del usuario?

Dimensión 6: Survivable Experiment (0-10)

¿Podría este cambio ser validado en un experimento pequeño antes de invertir en desarrollo completo?

La puntuación 6D no es “bueno si >7.” Es un diagnóstico. Una story que puntúa 2/10 en Behavior Change Clarity tiene un problema crítico. Las stories provenientes de research validado típicamente puntúan ≥7 en las primeras dos dimensiones automáticamente.

Parte 5: El Rol de AI en la Traducción

La IA —incluyendo sistemas avanzados— no puede reemplazar research. No puede inventar JTBDs válidas. Pero la IA es excepcional en:

Retener información sin colapsar: Puede producir una story estructurada que contiene todos los elementos sin perder densidad de información.

Verificar completitud: Puede preguntar “¿respondiste todas las preguntas de Wendel?” y rechazar una story incompleta.

Generar variantes: Puede generar múltiples versiones de story con diferentes puntos de entrada.

Puntuación 6D honesta: Puede puntuar basado en datos explícitos, evitando el sesgo humano.

Rastreo de evidencia: Manteniendo referencias explícitas a research original.

Pero —y esto es crítico— El PM todavía decide. El framework de Mercadona mantiene el criterio humano en decisiones de producto. La IA mantiene la consistencia y trazabilidad. Juntos, retienen información sin perder calidad.

Conclusiones: Síntesis de Cómo Retener Información en la Traducción

1. El Problema es Real: Tres fuerzas trabajan contra la retención: la presión de abstraer, la tendencia a colapsar el job en una solución, y la omisión de dimensiones motivacionales.

2. JTBD Reforzada es el Contenedor: Ocho elementos que preservan cada aspecto crítico de la investigación. La clave está en la especificidad.

3. Wendel Checklist Revela si tu Usuario es Real: Cuatro preguntas que convierten un usuario abstracto en uno concreto cuyas decisiones puedes predecir.

4. Behavior Change Especifica el Qué Cambia: Observable NOW vs NEW, con rangos mínimo/target/over-top.

5. La Story Estructurada Retiene Todo: Epic > Story > Acceptance Criteria > Context > Motivations > Barriers > Evidence > Metrics.

6. Puntuación 6D es Diagnóstico, No Veredicto: Seis dimensiones que revelan dónde está incompleta una story.

7. La IA Retiene, El Humano Decide: El rol de IA es mantener información. El rol del PM es investigar y elegir.

8. Honestidad Sobre Gaps: Un gap documentado es una oportunidad. Un gap no documentado es una bomba de tiempo.

Reflexión Final: De Donde Venimos, Hacia Donde Vamos

Si has leído los artículos 1, 2, 3 y este artículo 4, has recorrido un camino completo de research a product:

• Artículo 1: Identificaste un DAPP rico en contexto de negocio

• Artículo 2: Investigaste ese problema con metodología rigurosa

• Artículo 3: Validaste que habías encontrado Jobs verdaderos, no soluciones disfrazadas

• Artículo 4 (este): Tradujiste esos jobs en stories que retienen toda la información

Quedan tres artículos más: Artículo 5 sobre el Quality Coach para evaluar calidad de stories, Artículo 6 sobre Story Splitting para descomponer stories grandes, y Artículo 7 sobre el Story Builder conversacional.

Por ahora, la lección es simple: La información que pierdes en la traducción de research a story no se recupera después. Construye tus stories con estructura suficiente para retenerla. Integra los tres marcos. Puntúa honestamente. Y mantén el rastreo a las fuentes.

Tus usuarios —y tu equipo— lo agradecerán cuando las stories sean tan ricas en contexto que el desarrollo se vuelve claramente identificado hacia el outcome real, no hacia una característica genérica.

Este artículo es parte de la serie “Gemba” sobre el “AI Mercadona User Story Framework”. Próximo artículo: “Quality Coach: Evaluando la Calidad de tus User Stories.”

Última actualización: Febrero 21, 2026

Existe un momento crítico en el viaje de cualquier producto digital: el instante justo después de haber finalizado un Documento de Requerimientos de Producto (PRD). El equipo siente la satisfacción de haber articulado claramente qué se va a construir, por qué, y cuál será el impacto. Los números están en la hoja de cálculo. Las métricas de éxito definidas. Los casos de uso mapeados.

Pero hay un problema silencioso: el PRD describe el problema desde la perspectiva del negocio, pero las mejores historias de usuario se construyen desde la perspectiva del usuario. Entre esos dos universos existe un abismo lleno de suposiciones no cuestionadas, contextos incompletos, y comportamientos que nadie ha observado realmente.

En el artículo anterior exploramos cómo Quality Guard verifica que el PRD contenga información suficiente y separada (problema vs. solución) para que el producto pueda diseñar bien. Pero ahora nos enfrentamos a la pregunta siguiente: ¿Es ese problema realmente lo que el usuario experimenta?

Esta es la pieza que introduce Research Mom Test, el tercer módulo del AI Mercadona User Story Framework.

El Mom Test: La Filosofía de la Investigación Honesta

El nombre “Mom Test” viene de un concepto acreditado a Rob Fitzpatrick en su libro del mismo nombre. La idea es devastadoramente simple: si le preguntas a tu madre si tu idea de negocio es buena, te dirá que sí, porque te quiere. No porque la idea sea buena.

El Mom Test propone que las preguntas de investigación deben diseñarse para que incluso tu madre no pueda darte una respuesta falsa. Esto se logra evitando tres tipos de preguntas tóxicas:

Preguntas tóxicas que Mom Test prohíbe:

• Preguntas de opinión: “¿Te gustaría...?”, “¿Qué opinas de...?”, “¿Sería útil si...?”

• Preguntas hipotéticas: “¿Usarías X si existiera?”, “¿Cuánto pagarías por...?”, “¿Cambiarías tu proceso si...?”

• Preguntas dirigidas: “¿No crees que sería mejor si...?”, “¿El problema principal es X, verdad?”

En su lugar, Mom Test exige preguntas sobre comportamiento real, pasado, observable:

• “Cuéntame la última vez que hiciste X. ¿Qué pasó?”

• “¿Qué hiciste cuando ocurrió Y?”

• “¿Cómo resuelves Z actualmente?”

• “¿Cuánto tiempo te lleva?”

• “¿Qué intentaste antes de hacer lo que haces ahora?”

La clave es que estas preguntas revelan comportamiento real, no intención declarada. Y en Mercadona, donde cada cambio de proceso en un almacén puede impactar a 1,800 empleados, la diferencia entre intención declarada y comportamiento real puede costar millones.

Cómo Research Mom Test Transforma PRDs en Investigación de Campo

En el AI Mercadona User Story Framework, Research Mom Test recibe un PRD que ha pasado Quality Guard. El PRD contiene: métricas baseline y target, proceso AS-IS y TO-BE, actores y handoffs, y un problema limpio sin contaminación de solución.

Research Mom Test analiza este PRD y genera automáticamente:

1. Gap Detection (Detección de Huecos): Identifica qué información falta en el PRD para poder construir buenas historias de usuario. Busca: suposiciones no validadas, comportamientos asumidos pero no observados, actores mencionados pero no entrevistados, métricas que dependen de datos no recopilados, y procesos descritos teóricamente pero no verificados en campo.

2. Guía de Entrevistas Mom Test: Para cada gap detectado, genera preguntas de entrevista que cumplen estrictamente Mom Test. No preguntas de opinión. No hipotéticas. Solo preguntas sobre comportamiento real, pasado, observable.

3. Jobs-to-be-Done (JTBD) Reforzado: Después de las entrevistas, Research Mom Test procesa las notas y genera JTBDs enriquecidos con evidencia real: citas directas, patrones observados, frecuencia, contexto emocional.

Gap Detection: Encontrar lo que No Sabemos que No Sabemos

La parte más valiosa de Research Mom Test es su capacidad para detectar huecos en el conocimiento. Hay tres categorías:

Gaps de Proceso Funcional (PF): Información faltante sobre cómo funciona el proceso actual. Ejemplo: el PRD dice que “recepcionistas procesan pallets” pero no dice cuántos pallets por turno, cuánto dura cada procesamiento, o qué pasa cuando hay 3 camiones simultáneos.

Gaps de Inventario de Secciones (PI): Información faltante sobre las secciones o áreas afectadas. Ejemplo: el PRD menciona “almacén” pero no especifica si aplica a refrigerados, secos, congelados, o todos. Cada sección puede tener flujos diferentes.

Gaps de Contexto de Usuario: Falta de comprensión sobre cómo los usuarios realmente interactúan con el proceso. Qué workarounds usan, qué frustraciones tienen, qué han intentado antes.

La Guía de Entrevistas: Preguntas que Revelan Verdad

Para cada gap detectado, Research Mom Test genera preguntas de entrevista específicas. Un ejemplo real del almacén de Lleida:

Gap detectado: “El PRD asume que las discrepancias en recepción son un problema grave, pero no sabemos con qué frecuencia ocurren realmente, ni cómo las resuelven los recepcionistas.”

Preguntas Mom Test generadas:

• “Cuéntame sobre la última vez que recibiste un pallet con algo diferente a lo esperado. ¿Qué pasó exactamente?”

• “¿Cómo supiste que había una discrepancia? ¿Qué hiciste después?”

• “¿Cuántas veces esta semana te pasó algo así? ¿Es típico?”

• “Cuando encontraste la discrepancia, ¿a quién le avisaste? ¿Cuánto tardó en resolverse?”

• “¿Alguna vez inventaste una forma de resolver esto más rápido por tu cuenta? Cuéntame.”

Estas preguntas no preguntan “te gustaría un sistema mejor”. Preguntan “qué haces hoy”. La diferencia es fundamental.

Research Mom Test también genera preguntas para cada rol diferente. Para el recepcionista, para el analista de almacén, para el supervisor, para el operador logístico. Cada uno ve el proceso desde un ángulo diferente.

JTBD Reforzado: Jobs-to-be-Done con Evidencia Real

Después de las entrevistas, llega el momento más transformador: convertir las respuestas en Jobs-to-be-Done enriquecidos con evidencia.

Un JTBD tradicional dice: “Cuando [situación], quiero [motivación], para poder [resultado esperado].”

Un JTBD Reforzado en nuestro framework añade capas críticas:

• Funcional: ¿Qué tarea específica necesita completar?

• Emocional personal: ¿Cómo quiere sentirse durante y después?

• Emocional social: ¿Cómo quiere ser percibido por colegas/supervisores?

• Cambio de comportamiento: ¿Qué debería empezar (START), dejar de hacer (STOP), o hacer diferente (DIFFERENT)?

• Evidencia de entrevista: Citas directas y observaciones que soportan cada JTBD

Ejemplo real del almacén de Lleida:

JTBD Funcional: “Cuando recibo un pallet con discrepancias, necesito poder registrar la diferencia y obtener una decisión inmediata sobre qué hacer con los items sobrantes o faltantes, para no tener que parar mi flujo de trabajo esperando al analista.”

JTBD Emocional Personal: “Quiero sentir que tengo control sobre mi zona de trabajo y que puedo resolver problemas sin depender de otra persona que a veces no está disponible.”

JTBD Emocional Social: “Quiero que mi supervisor vea que manejo discrepancias de forma profesional y rápida, sin generar colas en el muelle.”

Evidencia: 3 de 5 recepcionistas entrevistados mencionaron esperar entre 15-45 min al analista. Uno dijo: “A veces resuelvo yo solo porque ya sé lo que hay que hacer, pero después me reganan por no seguir el proceso.”

Dos Modos de Operación: Discover y Validate

Research Mom Test opera en dos modos según el estado del PRD:

Modo Discover: Cuando el PRD tiene gaps significativos. La investigación es exploratoria. Se busca entender el territorio completo. Preguntas abiertas, observación en campo, seguimiento de workarounds. Resultado: mapa completo de JTBDs con evidencia.

Modo Validate: Cuando el PRD está bastante completo pero necesita confirmación. La investigación es confirmatoria. Se busca validar que lo que asumimos es correcto. Preguntas más específicas, verificación de hipótesis. Resultado: JTBDs confirmados o corregidos.

En ambos modos, Research Mom Test SIEMPRE se ejecuta. No hay camino del PRD a las historias de usuario que no pase por investigación de campo. Es un principio no negociable del framework.

El Wendel Checklist: Validando Cambio de Comportamiento

Una innovación importante de nuestro framework es integrar el Wendel Checklist (inspirado en los principios de diseño conductual de Stephen Wendel) en la validación de JTBDs.

La idea: cada JTBD implica un cambio de comportamiento. Si queremos que el recepcionista registre discrepancias en tiempo real en lugar de en papel, estamos pidiendo un cambio de hábito. Y los cambios de hábito fallan si no se diseñan bien.

El Wendel Checklist verifica cinco condiciones para cada JTBD:

1. CUE (Señal): ¿Hay un momento claro que dispara la acción? Si el recepcionista no sabe CUÁNDO usar el nuevo sistema, no lo usará.

2. REACTION (Reacción): ¿La reacción instintiva es positiva? Si el sistema parece complicado, el recepcionista volverá al papel.

3. EVALUATION (Evaluación): ¿El usuario ve el beneficio inmediato? Si el beneficio es “mejor para la empresa” pero no “mejor para mí”, la adopción será baja.

4. ABILITY (Capacidad): ¿El usuario PUEDE hacerlo? Si necesita 3 manos (una para el pallet, una para el papel, una para el dispositivo), no es factible.

5. TIMING (Momento): ¿Es el momento adecuado? Si el recepcionista tiene 5 camiones esperando, no va a pararse a aprender un sistema nuevo.

Cada JTBD que sale de Research Mom Test se evalúa contra estas cinco condiciones. Si alguna falla, el JTBD necesita ajuste antes de convertirse en historia de usuario.

El Poder del Comportamiento START/STOP/DIFFERENT

Research Mom Test introduce una clasificación de cambio de comportamiento para cada JTBD:

• START: Algo que el usuario NO hace hoy y debería empezar. Ejemplo: registrar discrepancias digitalmente.

• STOP: Algo que el usuario hace hoy y debería dejar. Ejemplo: anotar en papel, esperar al analista.

• DIFFERENT: Algo que el usuario hace hoy pero de forma diferente. Ejemplo: comunicar discrepancias por radio en vez de caminando.

Los cambios STOP son los más difíciles. Dejar de hacer algo que funciona (aunque sea ineficiente) requiere que la alternativa sea significativamente mejor. Los cambios START son los más riesgosos. Añadir un nuevo paso a un proceso ya cargado genera resistencia. Los cambios DIFFERENT son los más fáciles de adoptar. El hábito ya existe; solo cambia la herramienta.

Conclusiones: La Investigación como Puente entre Negocio y Usuario

Research Mom Test es el puente que conecta la claridad del PRD con la realidad del campo. Sin él, las historias de usuario se construyen sobre suposiciones. Con él, se construyen sobre evidencia.

Aprendizajes clave de este artículo:

El Mom Test es no negociable: No preguntar opiniones. No preguntar hipótesis. Solo comportamiento real, pasado, observable.

Gap Detection antes de entrevistar: Saber qué no sabemos antes de ir al campo es la mitad del trabajo.

JTBD Reforzado: Funcional + Emocional Personal + Emocional Social + Cambio de Comportamiento + Evidencia. No solo “qué quiere hacer” sino “cómo quiere sentirse” y “cómo quiere ser visto”.

Wendel Checklist: Cada JTBD implica un cambio de comportamiento. Si no pasa las 5 condiciones (Cue, Reaction, Evaluation, Ability, Timing), la historia de usuario que salga de ahí fracasará en adopción.

START/STOP/DIFFERENT: Clasificar el cambio de comportamiento para saber dónde está el riesgo de adopción.

En Mercadona, donde cada cambio impacta a miles de personas en cientos de ubicaciones, esta rigurosidad no es un lujo. Es una necesidad. La diferencia entre un producto exitoso y un producto abandonado a menudo no está en la calidad del código, sino en la calidad de la investigación que lo precedió.

En el próximo artículo, exploraremos cómo JTBD to Stories toma estos JTBDs reforzados y los transforma en historias de usuario de alta calidad, listas para el equipo de desarrollo.

Próximo artículo: Artículo 4 — “JTBD to Stories: La Transformación de JTBDs en User Stories de Calidad”

Serie “AI Mercadona User Story Framework” — Febrero 2026

En el artículo anterior de esta serie sobre el “AI Mercadona User Story Framework”, establecimos la visión general: un camino desde el descubrimiento profundo del problema hasta la entrega de historias de usuario que realmente resuelven el negocio. Hablamos de por qué el descubrimiento importa, de cómo la mayoría de los fracasos de producto no vienen de implementar mal la solución, sino de resolver el problema equivocado.

Hoy nos enfrentamos a una pregunta incómoda: ¿cómo sabemos cuándo un problema está realmente bien definido?

Introducción: Cuando el Problema No Es Problema

En el artículo anterior de esta serie sobre el “AI Mercadona User Story Framework”, establecimos la visión general: un camino desde el descubrimiento profundo del problema hasta la entrega de historias de usuario que realmente resuelven el negocio. Hablamos de por qué el descubrimiento importa, de cómo la mayoría de los fracasos de producto no vienen de implementar mal la solución, sino de resolver el problema equivocado.

Hoy nos enfrentamos a una pregunta incómoda: ¿cómo sabemos cuándo un problema está realmente bien definido?

La respuesta que hemos descubierto en Mercadona es que la mayoría de los equipos no lo saben. Y más preocupante aún: la mayoría de los PRDs (Documentos de Requisitos de Producto) que llegan a manos de los ingenieros no contienen suficiente información para que el producto pueda tomar decisiones inteligentes.

Esto no es culpa de nadie. Es un síntoma de una confusión estructural que existe en prácticamente todas las organizaciones tecnológicas: la falta de claridad sobre dónde termina el trabajo de entender el problema (responsabilidad del negocio) y dónde comienza el trabajo de diseñar la solución (responsabilidad del producto).

Cuando esos límites se difuminan, pasan cosas. Se mezclan responsabilidades. Se empieza a construir sin claridad. Y tres sprints después, descubrimos que nunca entendimos realmente qué estábamos tratando de resolver.

Para evitar eso, necesitamos un guardián en la puerta. Alguien (o algo) que diga: “Espera. Antes de que el producto comience a diseñar, verifiquemos que el problema esté realmente bien definido.”

Ese guardián se llama Quality Guard.

El Problema: PRDs que No Son Realmente Especificaciones

Imaginemos un escenario típico en cualquier equipo de tecnología de Mercadona:

Un gerente de tienda en Barcelona entra en una reunión con el equipo de producto de In-Store. El gerente dice: “La gente tarda mucho en hacer recuento de inventario. Necesitamos una app que lo haga más rápido.”

El PM asiente. Suena como un problema legítimo. El PM escribe un PRD:

“El equipo de In-Store debe desarrollar una herramienta de recuento rápido que permita a los empleados completar inventarios en la mitad del tiempo actual.”

¿Ves el problema? No hay métricas baseline. ¿Cuánto tiempo tarda hoy? ¿Qué significa “la mitad”? No hay observación de campo. ¿Por qué tarda tanto? ¿Es porque el proceso está mal diseñado? ¿Porque hay demasiados SKUs? ¿Porque la app actual es lenta? No hay claridad sobre restricciones. ¿Pueden trabajar en paralelo? ¿Necesitan estar online o offline? ¿Qué datos son críticos vs. secundarios?

El PM pasa este PRD al equipo de producto. El equipo de producto comienza a diseñar una interfaz moderna, optimizada, con sinc automático y dashboards en tiempo real. Bonita. Compleja.

Diez semanas después, el equipo de In-Store comienza a usar la herramienta. Descubren que el verdadero problema nunca fue la velocidad de la UI, sino que los recuentos se hacen con dos personas que se comunican verbalmente, una llamando los SKUs y otra marcándolos. La app que se diseñó es para una sola persona. El problema real era: ¿cómo hacemos que dos personas puedan trabajar juntas sin perder sincronía?

Tres semanas de ajustes. Conversación tensa entre producto e In-Store. La pregunta incómoda: “¿Por qué no preguntaron esto antes de empezar?”

La respuesta es sencilla: porque el PRD nunca pidió que preguntaran. El PRD era un deseo vagamente articulado, no una especificación de un problema.

La Teoría: Separación Estricta entre QUÉ y CÓMO

Para entender por qué Quality Guard existe, necesitamos primero entender una verdad fundamental sobre cómo se construye bien en organizaciones maduras:

La distinción entre QUÉ y CÓMO es sagrada.

El QUÉ es: ¿Cuál es el problema que existe en la realidad?

El CÓMO es: ¿Cuál es la mejor solución tecnológica para ese problema?

Estos dos espacios tienen dueños diferentes:

• El negocio es responsable de especificar el QUÉ. El negocio vive en las tiendas, en los almacenes, en los repartos. El negocio conoce los procesos, las restricciones, los usuarios finales, las métricas que importan.

• El producto es responsable de diseñar el CÓMO. El producto entiende de experiencia, arquitectura, escalabilidad, factibilidad técnica.

Cuando estos espacios están bien separados, pasan cosas buenas:

1. El negocio tiene claridad. Se enfoca en lo que importa: definir el problema, los datos, los actores.

2. El producto tiene libertad. Puede explorar soluciones creativas sin estar atado a prescripciones del negocio.

3. La comunicación es clara. Sin límites claros, todo se vuelve adivinanzas.

Pero en la mayoría de las organizaciones, estos espacios se contaminan mutuamente. El negocio pide soluciones específicas (CÓMO). El producto asume lo que quiere el negocio (QUÉ) sin preguntar.

Las Tres Dimensiones de Quality Guard

Quality Guard evalúa el PRD en tres dimensiones independientes. Cada dimensión se califica de 0 a 10. El puntaje final es el mínimo de las tres.

Dimensión 1: Completitud del Problema

Pregunta fundamental: ¿Existe suficiente información cuantitativa y cualitativa para que el producto entienda qué está siendo resuelto?

Esta dimensión verifica que el PRD contenga tres tipos de evidencia:

1.1. Métricas cuantitativas con baseline y target

Un problema sin números no es especificación, es opinión.Veamos ejemplos malos:

• ❌ “Los empleados tardan mucho tiempo en hacer recuento de inventario”

• ❌ “Queremos mejorar la experiencia de checkout”

• ❌ “La gente está frustrada con la app de rutas”

Todas son intuiciones. Ninguna es datos.

Ejemplos buenos:

• ✅ “El recuento de inventario toma 3.5 horas hoy (medido en 5 tiendas piloto, Feb 2026). Meta: 2.0 horas. Impacto: 1.5 horas × 50 tiendas × 365 días = 27,375 horas/año.”

• ✅ “En checkout, el 23% de los carritos que inician no se completan. Baseline: 23% (Oct-Dec 2025). Meta: <15%. Impacto: +180 transacciones/mes en tienda media.”

• ✅ “La app de rutas se usa 8 minutos/sesión. Competidor usa 5 minutos. Meta: <4 minutos.”

Los ejemplos buenos tienen: un estado actual medible (baseline), un estado deseado medible (target), una unidad de medida clara, una muestra o período especificado, y un impacto cuantificado.

1.2. Observaciones de campo con citas directas

Los datos sin contexto son números huérfanos. Quality Guard busca que el PRD contenga visitas a tiendas o almacenes (Gemba walk), notas verbatim, observaciones de cómo hacen las cosas hoy, y fricción observada.

Ejemplo malo: “El sistema de picking genera mucho rechazo entre los colaboradores de almacén.”

Ejemplo bueno: “Durante la Gemba walk del 10 de febrero en el almacén de Lleida, observamos a 4 preparadores. Uno comentó: ‘Esto es un show. Tengo que estar constantemente revisando si el item ya fue preparado’. Otro: ‘Los olvidos pasan porque la batería se me muere a mitad de la jornada’. Observamos que 23 de 80 preparaciones tuvieron pick errors en 2 horas. 18 de esos 23 errores fueron en las últimas 2 horas de la jornada, cuando la batería se agota.”

1.3. Impacto claro en personas, procesos, herramientas

El problema debe conectarse a: ¿Quién sufre? ¿Cómo sufre? ¿Qué herramientas están implicadas?

Scoring Dimensión 1: 9-10: Métricas baseline y target claras, observaciones de campo recientes, impacto articulado. 7-8: Métricas parciales, observaciones presentes. 5-6: Datos parciales, impacto vago. 3-4: Algún número, sin observaciones. 0-2: Sin métricas ni claridad.

Dimensión 2: Calidad del Proceso

Pregunta fundamental: ¿Está documentado cómo funciona hoy el proceso? ¿Y cómo debería funcionar idealmente?

Quality Guard busca dos documentos:

2.1. Mapa AS-IS — Cómo funciona hoy, paso a paso, con todos los actores y herramientas.

2.2. Mapa TO-BE — Cómo debería funcionar idealmente, abstrayendo de la tecnología. No dice “usa app mobile” sino “cómo debería ser la experiencia de proceso”.

2.3. Actores y Handoffs — Quiénes son, qué hacen, dónde están, cuándo interactúan.

Scoring Dimensión 2: 9-10: AS-IS detallado, TO-BE idealizado, actores claros. 7-8: AS-IS presente, TO-BE parcial. 5-6: Superficial. 3-4: Vago. 0-2: Sin descripción de proceso.

Dimensión 3: Separación QUÉ/CÓMO (Contaminación de Solución)

Pregunta fundamental: ¿Hay pistas de que alguien en el negocio está prescribiendo la solución en lugar de describir el problema?

Esta es la dimensión más peligrosa. Cuando el negocio dicta soluciones en el PRD, el producto pierde toda libertad de diseño.

Quality Guard detecta antipatrones de contaminación:

Antipattern 1: Jobs-to-be-Done en el PRD — Los JTBD son responsabilidad del producto, no del negocio. Malo: “Los preparadores necesitan visualizar la ruta de picking optimizada en tiempo real para minimizar desplazamiento.” Bueno: “El preparador tarda 45 min en completar 80 items en almacén de 8000 m². Anda ~2.3 km por ruta (datos GPS). Benchmark: almacén comparable anda ~1.2 km. Diferencia: 1.1 km × 10 min/km = 11 min/ruta × 8 rutas/día = 88 min/día/persona. Con 15 preparadores = 22 horas/día perdidas.”

Antipattern 2: Prescripciones técnicas — “Usa API REST”, “usa blockchain”, “usa inteligencia artificial”. Malo: “Se requiere integración vía REST API con SAP para sincronizar inventario en tiempo real.” Bueno: “Hoy hay retraso de 4 horas entre preparación de item y reflejo en sistema de inventario. Causa sobreventa: 8-12 devoluciones/día. Se necesita actualización dentro de 15 min del evento.”

Antipattern 3: Prescripciones de UI/UX — “Necesita un botón para...”, “La app debe tener...”. Malo: “Se requiere pantalla táctil de 10 pulgadas en cada posición de picking.” Bueno: “Hoy los preparadores cometen error en 2.3% de picks (confunden artículos similares). Con foto de referencia, error baja de 2.3% a 0.6%. El preparador necesita acceso a información visual clara.”

Antipattern 4: Lenguaje de solución — “La solución debería...”, “necesitamos software que...”. Sin contaminar: “Cuando una devolución ocurre en campo, el registro toma 6 horas. En 40% de casos, driver re-entrega a almacén equivocado. Necesitamos información en punto de devolución inmediatamente.”

Antipattern 5: Hipótesis de solución disfrazada de requerimiento — “Reducir número de clics en 50%” es hipótesis, no problema. Problema puro: “40% de usuarios abandonan carrito en paso de pago. 65% abandona después de ver opciones. Flujo actual: 7 pantallas, 45 campos. Benchmark competidor: 3 pantallas, 20 campos.”

Scoring Dimensión 3: Quality Guard comienza asumiendo 10 puntos. Por cada antipattern: crítico (-3), alto (-2), medio (-1).

La Prueba de Herramienta Alternativa

Quality Guard usa una técnica elegante para detectar contaminación de solución: el Alternative Tool Test.

La idea: si reemplazas la herramienta digital por papel/manual y la descripción SIGUE SIENDO VÁLIDA, entonces es descripción de problema legítima. Si la descripción se disuelve, era prescripción de solución.

Ejemplo: “El equipo de recepción necesita verificar que lo que llega en el pallet coincide con la orden esperada, y registrar las discrepancias.” ¿Sigue siendo válido en papel? Sí. Totalmente. De hecho, hacerlo en papel es exactamente lo que hacían antes.

Ejemplo: “En tiempo real, cada cambio en la posición de preparador debe actualizarse en un mapa.” ¿Sigue siendo válido? El problema real es “supervisor necesita visibilidad de ubicación preparadores”. La versión original prescribe “en tiempo real” y “mapa”, que son detalles de solución.

Los Tres Veredictos

Cuando Quality Guard termina de evaluar un PRD, entrega uno de tres veredictos:

PASS (≥ 7.0)

El PRD está listo. El problema está bien definido. Las tres dimensiones están en buen estado. El producto puede comenzar a diseñar con confianza.

CONDITIONAL (5.0 - 6.99)

El PRD está cerca, pero tiene agujeros específicos. Quality Guard genera un documento de handoff estructurado que le dice al negocio exactamente qué falta. No es un rechazo. Es una guía: “Vuelve, agrega esto, y estaremos listos.”

Ejemplos: “Métrica baseline clara pero falta target. ¿Cuál es el estado deseado?”, “Observaciones de campo de solo 2 personas. Necesitamos 5+ para validar patrón.”, “AS-IS documentado pero TO-BE falta.”

FAIL (< 5.0)

El PRD está muy lejos. Falta información crítica o hay tanta contaminación que no se puede confiar en que el problema esté bien entendido. Quality Guard genera un documento de escalada con: qué dimensión es más débil, qué información falta, y sugerencia de próximos pasos (Gemba walk, entrevistas, mapping de proceso).

La Filosofía detrás de Quality Guard

Quality Guard no está juzgando si el problema es importante. Lo que verifica es diferente: está verificando que la información necesaria para que el producto tome buenas decisiones esté realmente presente.

Es un check de integridad de información, no de importancia estratégica.

Imagine que está a punto de hacer cirugía. El cirujano necesita: diagnóstico claro, datos de laboratorio, comparativa, y anatomía. Si el doctor no tiene eso, no importa cuánto quiera operar. Podría operar en el lugar equivocado.

Quality Guard es el enfermera que dice: “Doctor, ¿tenemos todos los datos que necesita antes de entrar al quirófano?”

Un Caso Real: Recepción en Almacén de Lleida

El equipo de Supply trae un PRD: “Mejorar eficiencia de recepción de merchandise en almacenes mediante modernización del proceso.”

Análisis D1 (Completitud): No hay métrica baseline. Dice “recepción lenta” sin decir qué tan lenta. Hay nota de una visita a Lleida con una persona. Impacto vago. Score: 4/10.

Análisis D2 (Proceso): Diagrama vago sin actores ni herramientas. TO-BE falta. Actores mencionados sin claridad. Score: 3/10.

Análisis D3 (Separación): “Sistema digital que integre escaneo de código de barras, sincronización automática con inventario central, y reportes automáticos.” Esto prescribe arquitectura completa sin especificar el problema. Score: 7/10 (10 - 3 por antipattern crítico).

Score final (mínimo): 3/10. Veredicto: FAIL.

Quality Guard genera documento de handoff con qué falta: datos baseline, observación de campo (Gemba walk 4 horas en Lleida, 20+ recepciones), entrevistas a 5+ recepcionistas, mapeo de proceso AS-IS/TO-BE, y limpieza de prescripciones técnicas.

El equipo de Supply hace la Gemba walk. Descubre: recepción toma 12 min/pallet, 1800 pallets/mes = 360 horas/mes. 18% de pallets tienen discrepancias. Investigar discrepancia toma 8 min/pallet en papel + sistema. 4 recepcionistas (turno 6-14h), 1 analista (turno 8-16h) — recepcionistas esperan al analista. Operador logístico recibe reporte por email 2 horas después, cuando ya se fue.

Supply trae PRD v2: D1: 9/10 (métricas, observaciones, impacto). D2: 8/10 (AS-IS y TO-BE claros). D3: 8/10 (sin prescripciones). Score final: 8/10. Veredicto: PASS.

Por Qué Quality Guard Importa: Separar Descubrimiento de Entrega

La idea central de Agile era correcta: no esperes a tener todo especificado, comienza a construir, itera. Pero una generación de gestores lo mal-interpretó como: “No necesitamos especificación de problemas.”

Lo que una organización madura necesita es diferente:

Fase 1: Descubrimiento (semanas o meses) — Negocio entiende el problema profundamente. Producto investiga alternativas. Resultado: PRD que PASS Quality Guard.

Fase 2: Entrega (semanas) — Producto diseña y construye. Negocio responde preguntas tácticas. Resultado: incremento completado.

Quality Guard es el guardián que separa estas dos fases. Para Mercadona, esto significa: menos sorpresas en sprints, mejor productividad del equipo de producto, y mejor velocidad general. Es una inversión de 1-2 semanas extra en descubrimiento para ahorrar 6-8 semanas en re-trabajo.

Conclusiones: El Guardián de la Claridad

La calidad de un PRD no se mide por cuánto detalle tiene, sino por cuánta CLARIDAD tiene sobre el problema, separado de la solución.

Aprendizajes clave: La separación QUÉ/CÓMO es sagrada. Tres dimensiones de evaluación (Completitud, Proceso, Separación). Tres veredictos claros (PASS, CONDITIONAL, FAIL). El Alternative Tool Test. La filosofía de integridad de información. Y el costo de no hacerlo: re-hacer cuesta 6-8 semanas; hacer bien desde el inicio cuesta 1-2 semanas extra.

La pregunta final: ¿Cuál es el costo de comenzar a construir sin saber realmente qué se está construyendo? En Mercadona, donde los cambios pueden afectar a 250 puntos de venta y miles de empleados, ese costo es extremadamente alto. Quality Guard existe para reducirlo.

En el siguiente artículo de esta serie, exploraremos cómo Research Mom Test toma estos PRDs claros y extrae de ellos las verdaderas necesidades del usuario, contrastadas contra la realidad. Porque “problema bien definido” no es lo mismo que “problema realmente entendido”.

Próximo artículo: Artículo 3 — “Research Mom Test: Validación de Problemas contra la Realidad del Campo”

Serie “AI Mercadona User Story Framework” — Febrero 2026

Introducción: El Dilema del Product Manager en Mercadona Tech

En Mercadona Tech, gestionamos doce verticales de producto que cubren prácticamente todos los aspectos de la operación de la compañía. Desde el checkout y tienda online, pasando por logística, flota, almacenes y última milla, hasta sistemas internos de recursos humanos y planificación de ventas. Cada vertical es compleja, con centenares de historias de usuario que fluyen a través del pipeline de desarrollo.

Los Product Managers de Mercadona enfrentan una paradoja moderna: están más ocupados escribiendo historias que entendiendo usuarios. El día se consume en redactar especificaciones, refinar criterios de aceptación, negociar con ingeniería sobre el alcance. Pero el verdadero valor del PM—entender los problemas del negocio, hablar con clientes, detectar oportunidades, tomar decisiones estratégicas—queda relegado a momentos robados entre reuniones.

Esta realidad nace de un problema estructural. Cada PRD (Product Requirements Document) que llega al equipo de producto requiere una transformación manual: se debe analizar el problema, investigar qué está faltando, generar hipótesis sobre qué quieren realmente los usuarios, fragmentar ese trabajo en historias pequeñas y deployables, evaluar si las historias resultantes son de calidad. Todo esto, antes de que un ingeniero escriba una línea de código.

El resultado es un cuello de botella silencioso. Los sprints no avanzan al ritmo que podrían. Las historias contienen inconsistencias porque los PMs escriben bajo presión. Se descubren gaps fundamentales cuando ingeniería intenta construir. Los stakeholders esperan con incertidumbre mientras el equipo de producto intenta cumplir.

Hace aproximadamente seis meses, decidimos experimentar. En lugar de contratar más PMs o aceptar que esto era simplemente “el costo de hacer negocio”, preguntamos: ¿Y si pudiéramos automatizar las partes rutinarias de este proceso? ¿Y si un sistema de IA pudiera hacer el trabajo mecánico—evaluar calidad de PRDs, detectar gaps, diseñar investigación, escribir borradores de historias—de modo que nuestros PMs recuperaran tiempo para lo que realmente importa?

Así nació el AI Mercadona User Story Framework, un sistema inteligente en seis módulos diseñado para asistir a los PMs, no para reemplazarlos. Este marco utiliza técnicas avanzadas de investigación de usuarios (Mom Test), Jobs-to-be-Done, patrones de escritura de historias de clase mundial, y scoring dimensional para ayudar a convertir PRDs en backlogs de calidad consistentemente alta.

Este artículo presenta la visión general del framework, cómo surgió, por qué cada módulo existe, y cómo juntos crean un nuevo modelo de trabajo para el product management. Los siguientes artículos profundizarán en cada uno de los seis módulos, mostrando ejemplos reales, casos de uso, y cómo los PMs pueden integrar esta herramienta en su día a día.

El Problema: La Brecha entre PRD y Backlog de Calidad

Antes de entender la solución, es importante clarificar el problema con precisión. En Mercadona Tech, cuando un PRD llega al equipo de producto, típicamente incluye una descripción del problema que se quiere resolver, contexto de negocio sobre qué objetivo estratégico respalda este trabajo, algunos requisitos funcionales o puntos de alcance, y a veces un diagrama o flujo de usuario.

Lo que rara vez incluye es evidencia real de que hemos entendido el problema desde la perspectiva del usuario. No hay investigación con usuarios reales. No hay hipótesis validadas sobre qué comportamiento queremos cambiar. No hay descomposición clara de lo que es un trabajo deployable versus lo que es demasiado grande para un sprint.

Los PMs heredan este PRD y comienzan el trabajo de transformación manual. Primero, intentan evaluar si el PRD está lo suficientemente bien definido para pasar a ingeniería. Si no, hay que rellenar gaps. Luego, diseñan una investigación informal (a menudo solo conversando con stakeholders, no con usuarios finales). Con esa investigación, generan hipótesis sobre qué beneficios buscan los usuarios. A continuación, escriben las historias de usuario, intentando separar el problema (JTBD) de la solución propuesta, asegurarse de que cada historia implique un cambio de comportamiento observable, y que sean lo suficientemente pequeñas como para ser completadas en un sprint.

Finalmente, deben validar que las historias sean de calidad—que no sean genéricas, que tengan criterios de aceptación claros, que sean independientes de otras historias, que no sean demasiado grandes ni demasiado pequeñas.

Este proceso, cuando se hace bien, toma entre 20 y 40 horas de trabajo del PM. Cuando se hace mal—cosa que ocurre bajo presión de tiempo—resulta en historias que ingeniería no puede ejecutar, que falta contexto, que tienen criterios de aceptación vagos, o que son tan grandes que requieren subsplitting en el medio del sprint.

Multiplicado por doce verticales, decenas de PRDs por trimestre, y el hecho de que nuestros mejores PMs son buscados constantemente para opiniones estratégicas, el resultado es un sistema crónicamente bajo de capacidad para hacer este trabajo bien.

La Hipótesis: Automatizar lo Rutinario, Liberar el Juicio

Nuestra hipótesis era simple pero radical: la mayoría de este trabajo no requiere un PM humano. Requiere inteligencia, pero no juicio humano. Un sistema de IA, entrenado en patrones de excelencia en product management, podría hacer el 70-80% del trabajo de forma completamente automática, con calidad consistente, eliminando variación y permitiendo que nuestros PMs usen su tiempo para las cosas que realmente requieren juicio: hablar con usuarios, entender el contexto competitivo, tomar decisiones sobre priorización y trade-offs.

El concepto central es que un PM moderno no debería ser un “escritor de historias”. Debería ser un “investigador de problemas y tomador de decisiones”. La IA puede ser el escriba, el revisor, el detector de inconsistencias. El PM puede ser el líder que formula preguntas, valida hipótesis, y aprueba o rechaza las propuestas que la IA genera.

Para esto, construimos seis módulos que juntos forman un pipeline coherente: cada uno tiene una responsabilidad clara, pero todos ellos se retroalimentan. Si el PRD es de mala calidad, el Quality Guard lo detecta temprano. Si la investigación encuentra gaps, se generan preguntas de Mom Test. Si las historias resultantes no son de calidad, el Quality Coach las rechaza. Todo el sistema está diseñado para mantener un estándar consistente de excelencia.

Los Seis Módulos: Arquitectura del Framework

1. Quality Guard: La Frontera de Calidad

El primer módulo, Quality Guard, cumple una función crítica: actúa como guardaespaldas de calidad en la frontera entre proceso de producto y equipo de ingeniería. Su responsabilidad es evaluar si un PRD está suficientemente bien definido para pasar a trabajar en historias.

Quality Guard opera bajo la premisa de que es más económico rechazar un PRD de baja calidad temprano que invertir decenas de horas de PM en transformarlo. Por eso analiza el PRD en tres dimensiones:

La dimensión de completitud del problema: Quality Guard verifica que el PRD articule claramente cuál es el problema que se quiere resolver. No lo que quieres construir, sino el problema real. Detecta PRDs que son meramente descripciones de features sin raíz en problemas observados. Verifica que hay contexto de por qué este problema importa, qué sucede hoy que es insatisfactorio, quién sufre ese problema.

La dimensión de calidad SOP: Mercadona Tech sabe que muchos problemas de producto no son realmente problemas de producto. Son problemas de proceso, de formación, de herramientas. Quality Guard analiza si el PRD confunde un problema de SOP (procedimiento operativo estándar) con un problema de producto. Quality Guard detecta estos escenarios y genera un documento de handoff para que el equipo de procesos lo maneje, no el equipo de producto.

La dimensión de separación QUÉ/CÓMO: Un PRD de calidad articula claramente qué problema queremos resolver sin prescribir cómo debe hacerlo. Muchos PRDs incurren en el error de llegar con solución propuesta ya decidida. Quality Guard analiza si hay una separación clara entre el problema y la solución, si se deja espacio para que ingeniería diseñe cómo construir esto.

Cuando Quality Guard rechaza un PRD, no es un rechazo definitivo. Genera un documento de retroalimentación clara indicando qué falta, qué está mezclado, qué debería ser un proyecto de proceso en lugar de producto. Cuando aprueba, le da paso al siguiente módulo con una evaluación de riesgos.2. Research & JTBDs: De la Incertidumbre a la Evidencia

Una vez que Quality Guard aprueba un PRD, comienza el trabajo de Research & JTBDs (Jobs-to-be-Done). Este módulo tiene dos responsabilidades entrelazadas: primera, detectar qué falta en nuestro entendimiento del problema; segunda, generar investigación validada que nos diga qué trabajo necesitan hacer realmente los usuarios.

El módulo comienza analizando el PRD y haciendo la pregunta fundamental: ¿Qué asunciones tenemos sobre este problema que aún no hemos validado? Genera una lista de gaps. Una vez identificados, diseña un plan de investigación utilizando la metodología Mom Test de Rob Fitzpatrick. El Mom Test enseña a hacer preguntas que revelan verdades, no soluciones. En lugar de preguntar “¿Te gustaría un dashboard de combustible?”, se pregunta “¿Cuándo fue la última vez que quisiste saber cuánto combustible consumiste? ¿Qué intentaste hacer? ¿Cómo lo resolviste?”

Con esa evidencia, el módulo genera Jobs-to-be-Done estructurados con evidencia real: Job Performer específico, trigger concreto, struggle documentada con citas, outcome deseado, tres dimensiones de motivación (funcional, emocional, social) y ansiedades y barreras.

3. JTBD to Stories: La Transformación Estructurada

Con JTBDs validados en mano, el módulo JTBD to Stories se dedica a la transformación estructurada que convierte trabajos deseados en historias de usuario deployables. Aplica tres frameworks integrados: el JTBD Reforzado (con struggle, trigger, outcome y tres dimensiones de motivación), la Wendel Checklist (cuatro preguntas obligatorias sobre experiencia previa, relación con producto, motivación situacional e impedimento actual), y el Cambio de Comportamiento (START/STOP/DIFFERENT con rangos cuantificados).

Cada historia recibe un scoring de seis dimensiones y el output se estructura en tres niveles: Epic (visión estratégica), Features (2-5 capacidades) y Stories (implementables en 1-2 sprints) con criterios de aceptación Given-When-Then derivados de comportamientos observados.4. Quality Coach: Evaluador de Excelencia

Después de que las historias son generadas y refinadas, el módulo Quality Coach actúa como evaluador de calidad final. Su responsabilidad es asegurar que las historias resultantes no solo sean funcionales, sino que sean de clase mundial. Quality Coach evalúa cada historia contra la métrica de seis dimensiones, pero también detecta siete antipatrones comunes: el usuario genérico (”Como usuario quiero...”), la ausencia de cambio de comportamiento, la historia falsa (tarea técnica disfrazada), la solución como necesidad, el entregable fuera de zona de control, el “todo urgente”, y el splitting horizontal por capas técnicas.

Para cada story que puntúa bajo, el módulo ofrece una versión reescrita en formato JTBD. No como imposición sino como sugerencia que el PM puede adoptar, adaptar o descartar.

5. Story Splitting (Eduardo Ferro): La Descomposición Experta

El módulo Story Splitting, basado en la metodología de Eduardo Ferro (@eferro), detecta stories demasiado grandes y las descompone en incrementos que cumplen tres condiciones: ser independientemente valiosos, desplegables por separado y completables en 3 días o menos. Aplica nueve heurísticas de splitting: comenzar por outputs, estrechar segmento, extraer utilidad básica, de dummy a dinámico, simplificar outputs, dividir por capacidad, dividir por ejemplo, learning vs earning, y ponerla en muletas.

La base teórica es el concepto de “experimento sobrevivible”: cada story debe poder fallar sin consecuencias graves. Una regla fundamental: los splits deben ser siempre verticales, nunca horizontales.

6. Story Builder: El Asistente Conversacional

El sexto módulo, Story Builder, es un asistente conversacional para PMs que quieren crear historias desde cero, sin partir de un PRD estructurado. Guía al PM a través de un diálogo en 6 fases: contexto inicial (con detección de “trampa de solución”), descubrir el Job (técnica del ¿Por Qué?), Wendel Checklist, tres dimensiones del trabajo, cambio de comportamiento cuantificado, y story completa en formato JTBD Reforzado.

Lo poderoso de Story Builder es que democratiza la escritura de historias y tiene un efecto formativo: después de varias sesiones, los PMs internalizan las preguntas y mejoran su criterio incluso sin la herramienta.

El Corazón del Framework: Scoring Dimensional Unificado

Corriendo a través de todos los seis módulos hay un lenguaje común: el scoring dimensional de seis dimensiones. Este es el nervio central que conecta todos los módulos y asegura que toda la evaluación de calidad sea coherente.

Las seis dimensiones son: Contexto JTBD (¿hay evidencia cualitativa y cuantitativa del problema?), Especificidad del Usuario (¿responde a las 4 preguntas del Wendel Checklist?), Cambio de Comportamiento (¿qué va a hacer el usuario de forma diferente y está cuantificado?), Zona de Control (¿el equipo controla el entregable?), Restricciones Temporales (¿la urgencia es real o artificial?), y Experimento Sobrevivible (¿qué pasa si nos equivocamos?).

Cada dimensión se puntúa de 0 a 10. Lo importante es que este scoring no es arbitrario. Está basado en décadas de investigación en product management, en patrones de historias de usuarios extraordinarias, y en lo que hemos aprendido en nuestras propias doce verticales.

Filosofía: PM Como Investigador y Tomador de Decisiones

En el fondo, el AI Mercadona User Story Framework está basado en una filosofía sobre qué debe ser el product management moderno. No creemos que un PM sea un “escritor de historias”. Una historia es un artefacto. Lo que importa es el pensamiento que la precede. Los grandes PMs son investigadores de usuarios, descubridores de oportunidades, y tomadores de decisiones bajo incertidumbre.

Este framework invierte esa relación. Usa IA para hacer el acto de escribir automático, permitiendo que el PM se enfoque en lo que realmente importa: entender el problema. Pasa el 80% de tu tiempo investigando, hablando con usuarios, entendiendo contexto. El 20% que antes gastabas escribiendo historias, ahora úsalo para refinar lo que la IA sugiere.

El Futuro: PM + IA, No PM O IA

Un PM sin IA disponible está constantemente bajo presión de tiempo. Escribe historias rápido porque hay muchas. Esas historias terminan siendo genéricas, con antipatterns, inconsistentes en calidad. El PM no tiene tiempo de investigar realmente.

Un PM con IA disponible puede hacer las cosas que realmente importan. Pasar tiempo en Gemba—ir donde ocurre el trabajo real. Hablar con conductores de flota sobre cómo toman decisiones. Observar gerentes de almacén en un cambio de turno. Entender frustración en tiempo real. Luego volver y decir a la IA: “Esto es lo que vi, genera historias alrededor de estos trabajos deseados.”

Hemos visto esto en nuestras primeras implementaciones. Los PMs que han abrazado el framework reportan que dedican 15-20% más tiempo a hablar con usuarios. Sus backlogs tienen 40% menos incidentes relacionados con historias mal definidas. Los sprints son más predecibles.

Conclusiones: El Viaje Comienza

El AI Mercadona User Story Framework no es una solución a un problema de “escribir historias de usuario”. Es una solución a un problema mucho más profundo: cómo puede la industria de product management escalar cuando hay más complejidad de la que un número finito de PMs puede gestionar.

Los seis módulos trabajando juntos—Quality Guard asegurando que PRDs sean sólidos, Research & JTBDs trayendo evidencia de usuario, JTBD to Stories transformando investigación en especificaciones, Quality Coach asegurando excelencia, Story Splitting creando backlogs ejecutables, Story Builder democratizando la creación—forman un ecosistema coherente de product excellence.

En los artículos siguientes de esta serie, exploraremos cada módulo en profundidad. Veremos ejemplos reales de cómo se ve cuando cada módulo trabaja. Compartiremos los patrones que hemos codificado, las métricas que importan, los casos de uso donde el framework agrega más valor.

El product management en Mercadona Tech está en transición. De un modelo donde PMs son principalmente escritores de historias, a un modelo donde PMs son investigadores respaldados por inteligencia artificial. Mercadona Tech está en el Gemba de esa transformación. El viaje apenas comienza.

Una versión que pasa de beta a live, una nota de prensa, un “ya está disponible”.

Pero con los productos impulsados por inteligencia artificial, esa lógica deja de funcionar. Porque la IA no termina de lanzarse nunca. Su valor no está en el día en que se publica, sino en cómo aprende y mejora con el tiempo.

El Go-To-Market de un producto con IA no es una línea de meta, es el inicio de una evolución permanente.

De la foto al proceso

Cuando lanzas un producto tradicional, entregas una promesa cerrada: esto hace X, cuesta Y, y funciona así.

En cambio, al lanzar un producto con IA, entregas una promesa viva: esto hoy hace X, pero mañana lo hará mejor.

El problema es que esa promesa viva también es un riesgo. Porque cuando la mejora depende del aprendizaje del modelo, el usuario puede percibir que el producto aún no está “maduro”.

Por eso, los equipos de producto que trabajan con IA tienen que repensar por completo su estrategia de Go-To-Market: no solo cómo lanzar, sino cómo comunicar la evolución, cómo gestionar la incertidumbre y cómo crear confianza en lo imperfecto.

Un nuevo tipo de lanzamiento

Lanzar un producto de IA no se parece a lanzar una app o un SaaS.

Hay tres grandes diferencias que cambian las reglas del juego:

1. La versión 1.0 nunca es definitiva

   Los modelos necesitan datos reales para mejorar. El producto que se lanza no es “final”, sino una base que se entrena con cada usuario.

2. El producto no se comporta igual para todos

   Dos personas pueden tener experiencias completamente distintas. El mensaje deja de ser “funciona igual para todos” y pasa a ser “se adapta a cada uno”.

3. La propuesta de valor evoluciona en público:

   Los fallos o sesgos del modelo se corrigen con exposición real. El Go-To-Market también es un ejercicio de humildad: reconocer que la versión inicial no es perfecta, pero que está diseñada para aprender rápido.

Caso: el lanzamiento de Copilot

Cuando GitHub presentó Copilot, el producto estaba lejos de ser infalible. A menudo generaba código incorrecto o sugerencias poco útiles. Pero el equipo fue transparente desde el principio:

“Copilot no reemplaza al desarrollador; es un asistente que aprende contigo.”

Esa frase cambió las reglas del juego. Ya no se esperaba precisión absoluta, sino colaboración progresiva. El lanzamiento fue un éxito, no porque el modelo fuera perfecto, sino porque se comunicó como un proceso vivo, no como un producto acabado.

La comunicación como diseño

En los productos con IA, comunicar el lanzamiento es parte del diseño del producto.

No es solo marketing, es diseño de expectativas.

Tres principios clave:

1. Comunicar el aprendizaje, no solo la funcionalidad

   El usuario debe entender que el producto va a mejorar con su uso.

   Ejemplo: Notion AI muestra claramente “Esta función aprende de cómo la usas”.

2. Mostrar límites con transparencia

   “Puede contener errores” o “Generado automáticamente” no restan confianza. La aumentan.

3. Celebrar la mejora continua

   Cada iteración del modelo es parte de la narrativa del producto. “Ahora entiende mejor el contexto” no es una nota técnica, es una historia de progreso.

Estrategias de GTM adaptadas a IA

Un Go-To-Market efectivo para productos con IA es una conversación continua, no una campaña puntual.

Algunas estrategias que están funcionando:

• Lanzamientos iterativos públicos

  Fases progresivas, betas por invitación, comunidades piloto.

  Ejemplo: Midjourney creció dentro de Discord antes de abrirse al público.

• Comunidad como canal de mejora

  Los usuarios no son audiencia, son co-entrenadores. Feedback, ejemplos, y sugerencias nutren el modelo.

• Métricas narradas

  No basta con decir “el modelo mejora”: hay que mostrarlo. Comparativas, ejemplos, cambios visuales. Cada mejora debe sentirse tangible.

• Feedback como feature

  El botón “Esto fue útil / no fue útil” es parte del producto, no un elemento decorativo.

GTM de productos internos: el cliente es tu propio equipo

No todos los productos con IA se lanzan al mercado. Algunos se lanzan dentro de las propias organizaciones, para optimizar flujos, automatizar procesos o asistir a equipos internos. Y aquí el Go-To-Market cambia completamente.

El reto ya no es captar atención, sino ganar confianza y adopción. Porque dentro de una empresa, la resistencia al cambio puede ser mayor que fuera.

1. Vender la utilidad, no la tecnología

Los usuarios internos no quieren saber qué modelo usas, sino cómo les ahorra tiempo o errores. La narrativa del GTM debe centrarse en valor tangible: tiempo, claridad, reducción de carga manual.

2. Integrar con lo que ya existe

Nadie quiere abrir otra herramienta. El éxito de un GTM interno depende de integrarse en los flujos actuales: Slack, Jira, Notion, correos, dashboards.

Cuanto más invisible, más adoptado.

3. Apoyarse en embajadores internos

Antes que una campaña, crea una red de early adopters dentro del equipo.

Son los que validan el valor real y ayudan a evangelizar el producto desde dentro.

4. Medir adopción como aprendizaje, no como éxito

Si una feature no se usa, no significa que haya fracasado. Significa que aún no resolvió un problema real o que el equipo no la entiende. En IA, el usage gap es feedback, no derrota.

5. Comunicar la evolución con transparencia

En entornos internos, la comunicación es aún más crítica. La confianza se gana mostrando avances concretos: ejemplos de mejora, comparativas, correcciones de errores.

El mensaje clave: “esto no es magia, es mejora continua”.

Gestionar la incertidumbre: el arte de la confianza imperfecta

El mayor obstáculo de los productos con IA no es técnico: es psicológico.

El usuario —interno o externo— debe aceptar que el producto está aprendiendo.

Y eso solo ocurre si hay transparencia y coherencia.

El caso de ChatGPT lo ilustra bien:

“El modelo no siempre tiene razón, pero siempre está aprendiendo.”

Esa frase define una relación basada en confianza imperfecta. Y esa confianza es lo que mantiene al usuario en el ciclo de mejora.

El rol del PM en el Go-To-Market de IA

El product manager ya no gestiona un “día de lanzamiento”. Gestiona un viaje de aprendizaje compartido. Su trabajo no termina cuando el producto sale, empieza ahí.

Debe diseñar el GTM como una narrativa que evoluciona: cómo cambia el producto, qué aprende de los usuarios, y cómo comunicar cada paso con claridad y coherencia.

El takeaway

Los productos impulsados por IA no se lanzan para ser perfectos. Se lanzan para aprender en público. El éxito del Go-To-Market no está en la campaña ni en el hype, sino en la capacidad de construir confianza, comunidad y continuidad.

En la era de la IA, el lanzamiento no es un evento. Es el comienzo de una conversación entre el producto, el modelo y las personas que lo hacen crecer.

¿quién está realmente al mando?

Cuando un algoritmo sugiere una canción, completa una frase o elige qué noticia aparece primero en nuestro feed, parece que seguimos decidiendo nosotros.

Pero la realidad es más ambigua: la IA ya está influyendo —sutilmente— en nuestras decisiones, preferencias y hábitos.

Y a medida que los modelos se vuelven más sofisticados, el equilibrio entre asistencia y autonomía se vuelve más frágil.

El gran reto del diseño de producto en esta era no es crear sistemas que piensen por nosotros, sino diseñar formas de colaboración donde humanos e inteligencia artificial trabajen juntos sin que uno borre al otro.

De la automatización al acompañamiento

Durante mucho tiempo, la tecnología se diseñó con un objetivo claro: automatizar tareas repetitivas.

Hacer las cosas más rápido, con menos intervención humana. Pero la IA moderna no se limita a ejecutar; interpreta. Analiza contexto, anticipa intenciones, sugiere caminos. Y eso cambia por completo la naturaleza del producto.

Un ejemplo claro es el salto entre los pilotos automáticos de los aviones y los sistemas de conducción asistida de Tesla. El piloto automático sigue reglas claras; el sistema de Tesla “aprende” de la experiencia colectiva.

Ya no obedece, colabora.

Y ese pequeño matiz —colaborar— es el que marca el inicio de una nueva era de diseño de producto: la era del human-in-the-loop.

Qué significa realmente

human-in-the-loop

El término nació en entornos industriales y militares, pero hoy es fundamental para diseñar experiencias con IA.

Un sistema human-in-the-loop es aquel donde el humano sigue en el circuito de decisión.

Supervisa, corrige, enseña. Y, sobre todo, puede intervenir antes de que algo salga mal.

En otras palabras: no se trata de evitar la automatización, sino de asegurarse de que la responsabilidad última sigue siendo humana.

Tres niveles de intervención humana

Podemos pensar en tres niveles donde el usuario participa en un sistema con IA:

1. Antes de la decisión (human-in-command)

El usuario establece los límites, los objetivos o las reglas del sistema.

Por ejemplo, al configurar ChatGPT para responder con un tono profesional o educativo.

2. Durante la decisión (human-in-the-loop)

El usuario colabora en tiempo real con la IA.

Un diseñador revisando las propuestas que genera Figma, o un médico validando un diagnóstico sugerido por un modelo.

3. Después de la decisión (human-on-the-loop)

El humano no participa directamente, pero supervisa el rendimiento y los resultados del sistema, interviniendo cuando detecta errores o sesgos.

El desafío está en elegir el nivel adecuado para cada contexto: más automatización no siempre significa más valor.

Ejemplo: el caso de Duolingo Max

Cuando Duolingo introdujo su versión con IA generativa —Duolingo Max—, la empresa tuvo claro que el sistema debía ayudar al usuario a aprender, no solo a acertar.

Por eso, en lugar de mostrar simplemente si una respuesta era correcta o no, la IA explica por qué está bien o mal.

El usuario puede pedir una aclaración, repetir la frase, o incluso “hablar” con el personaje que la corrigió.

Esa interacción —guiada pero abierta— es human-in-the-loop en estado puro:

el sistema automatiza la práctica, pero mantiene al humano en el centro del aprendizaje. La magia está en que la IA no sustituye al profesor, sino que amplifica su presencia.

Patrones de diseño para mantener el control humano

Diseñar productos que equilibren autonomía y supervisión no es fácil, pero hay patrones que están demostrando funcionar:

1. El modelo propone, el usuario decide

La IA nunca ejecuta sin aprobación.

Ejemplo: Gmail sugiere respuestas rápidas, pero tú eliges si las envías o no.

2. Transparencia contextual

El usuario debe saber cuándo está interactuando con una IA y cómo esa intervención afecta el resultado.

Ejemplo: Photoshop ahora etiqueta automáticamente las imágenes generadas con IA generativa.

3. Corrección reversible

Todo sistema inteligente debe permitir deshacer y enseñar.

Cuando corriges una recomendación de Spotify o rechazas una sugerencia de Copilot, no solo ajustas tu experiencia; ayudas al modelo a mejorar.

4. Confianza ganada, no asumida

La autonomía no se concede por defecto, se gana con el tiempo.

Tesla, por ejemplo, exige al conductor mantener las manos en el volante: la automatización se amplía solo si el sistema demuestra fiabilidad.

5. Explicabilidad sin fricción

Los mejores sistemas comunican sus límites sin romper la experiencia.

Un mensaje como “esta respuesta puede contener errores” puede parecer trivial, pero genera un efecto psicológico de control y honestidad.

Cuando la IA se pasa de lista

Hay un momento peligroso en todo producto con IA: cuando intenta anticipar demasiado. Piénsalo: cuando tu teléfono corrige una palabra que no querías cambiar, cuando un recomendador insiste en ofrecerte algo que ya has rechazado, cuando un sistema “decide” por ti con exceso de confianza.

Ese tipo de automatismo rompe la sensación de control, y lo que era mágico se convierte en frustrante.

Uno de los mejores ejemplos fue Microsoft Tay, el chatbot lanzado en Twitter en 2016.

Aprendía de las conversaciones con los usuarios, pero sin filtros ni supervisión humana.

En menos de 24 horas, el sistema empezó a emitir mensajes ofensivos y racistas.

El experimento fue un fracaso técnico, pero una lección de diseño: sin control humano, los sistemas aprenden lo peor de nosotros.

Ética, responsabilidad y producto

El human-in-the-loop no es solo una decisión de diseño; es una posición ética.

Porque toda automatización lleva implícita una transferencia de poder.

Y cada vez que un producto decide por nosotros, le estamos delegando una parte de nuestro juicio.

El trabajo del PM es asegurarse de que esa delegación sea consciente, reversible y explicable.

No se trata de desconfiar de la IA, sino de diseñar los límites de su autonomía con criterio y propósito.

El takeaway

El futuro del diseño de producto no será 100% automatizado, ni 100% humano.

Será colaborativo.

El desafío del control humano consiste en construir tecnología que amplifique nuestras capacidades sin apropiarse de ellas.

👉 Diseñar human-in-the-loop no es frenar la innovación; es darle dirección.

Porque si los humanos salimos del circuito, la inteligencia deja de ser realmente inteligente.

Durante años, en los equipos de producto hemos perseguido la velocidad como una virtud en sí misma. La velocidad como símbolo de agilidad, de foco, de ejecución. “Entrega rápido, aprende rápido”.

Pero de repente, la IA generativa ha cambiado el significado de esa palabra.

Ahora, “entregar rápido” puede significar algo radicalmente distinto: escribir un prompt, y en segundos tener un PRD, un wireframe o un test de usuario.

El cuello de botella ya no está en producir, sino en pensar. Y eso lo cambia todo.

1. Discovery: cuando entender lleva más tiempo que preguntar

Antes, el discovery era una carrera de resistencia. Recolectar datos, hacer entrevistas, sintetizar aprendizajes. El reto era procesar.

Hoy, un modelo puede leer cien entrevistas en diez segundos y devolverte un mapa de insights perfectamente redactado.

Y sin embargo, lo que no puede hacer es distinguir lo que es importante de lo que solo suena bien.

Ahí nace la paradoja: la IA te ahorra tiempo analizando, pero te obliga a invertir más tiempo en formular las preguntas correctas.

Cuando todo puede responderse en segundos, el verdadero trabajo es decidir qué merece la pena preguntar.

Un ejemplo sencillo: imagina que analizas feedback de clientes que abandonan el carrito.

El LLM te dirá que “la mayoría abandonan por los gastos de envío o la fricción en el pago”.

Perfecto, pero eso no es nuevo. El descubrimiento empieza cuando preguntas por qué ese problema sigue existiendo pese a que todos lo conocen.

Esa pregunta —más que la síntesis automática— es la que lleva al aprendizaje real.

La IA convierte el discovery en un proceso más rápido, sí, pero también más frágil: puedes moverte a toda velocidad… en la dirección equivocada.

Por eso, el valor está en la curiosidad bien dirigida, no en la rapidez de los análisis.

2. Prototipado: del arte de diseñar al arte de editar

Diseñar ya no es dibujar, es conversar.

Hoy puedes pedirle a un modelo: “hazme una app para comparar planes de energía con un tono confiable y claro” y tendrás un mockup convincente en segundos.

Pero esa facilidad tiene un efecto sutil: cuando el coste de producir baja a cero, sube el riesgo de conformarse con lo primero que parece “suficiente”.

El prototipado ya no sirve para construir algo que no existe, sino para pensar con las manos.

La diferencia es que antes necesitabas un diseñador para hacerlo tangible, y ahora puedes hacerlo tú mismo, pero la calidad del resultado depende de tu criterio.

La IA te da velocidad, pero no te da gusto, ni conocimiento del contexto, ni sensibilidad por los matices.

El diseñador del futuro —y el product manager también— tendrá que dominar algo que hasta ahora no se enseñaba: saber editar.

No generar más, sino discernir mejor.

Porque cuando todo el mundo puede producir, la ventaja pasa a estar en saber qué descartar.

3. Validación: más datos, menos comprensión

La IA también promete revolucionar la validación: puedes crear tests automáticos, sintetizar feedback y hasta simular usuarios reales.

Y sin embargo, nada de eso sustituye el contacto con la realidad.

Cuando validas con datos generados, lo que obtienes es una coherencia estadística, no una señal humana.

El peligro es validar una ilusión: una hipótesis que parece sólida porque los datos la confirman… pero que no ha pasado por la prueba del comportamiento real.

Por eso, en esta era, la validación debería ser menos sobre cantidad de tests y más sobre calidad del aprendizaje.

Un buen test no es el que se ejecuta rápido, sino el que te obliga a cambiar de opinión.

Un ejemplo: lanzar una nueva experiencia de checkout y ver un +2% en conversión puede parecer éxito.

Pero si al mes bajan los pedidos recurrentes, o suben las incidencias, el experimento rápido solo te ha enseñado a optimizar un síntoma.

La IA te acelera el corto plazo; el criterio es el que protege el largo.

4. El dilema del ritmo

La velocidad ha sido siempre una ventaja competitiva, pero en la era de la IA deja de ser un diferencial: es una commodity.

Todos pueden moverse rápido. Lo difícil es saber cuándo no hacerlo.

La pregunta clave ya no es “¿cómo vamos más rápido?”, sino “¿cuál es el ritmo adecuado para aprender sin romper lo importante?”.

El discovery, el prototipado y la validación son ahora más cortos, más iterativos, más baratos.

Pero si los haces sin pausa para pensar, solo habrás cambiado tiempo por superficialidad.

La IA nos enfrenta a un tipo distinto de presión: no la de hacer más, sino la de decidir mejor qué merece la pena hacer.

Y eso requiere algo que ningún modelo puede generar: criterio colectivo.

5. De la eficiencia al sentido

La eficiencia siempre ha sido el lenguaje del producto. Menos fricción, menos coste, menos ciclos.

Pero la IA lleva la eficiencia a un nivel tan alto que amenaza con vaciarla de propósito.

¿De qué sirve ser ultrarrápido, si no tienes claro hacia dónde te diriges?

Los equipos que mejor usen la IA no serán los que generen más entregables, sino los que logren aprender con intención.

Acelerar para explorar, no para cerrar. Prototipar para pensar, no para justificar. Validar para entender, no para confirmar.

La IA no hace que el oficio de producto desaparezca. Lo vuelve más filosófico.

Nos obliga a preguntarnos qué significa realmente “hacer progreso” cuando cualquier cosa puede producirse en segundos.

6. En resumen

• La IA acelera el ciclo de entrega, pero el límite real está en nuestra capacidad de aprender.

• Discovery se convierte en el arte de preguntar bien.

• Prototipado se transforma en el arte de editar y tener criterio.

• Validación exige más humildad que nunca: no todo lo que parece funcionar, funciona de verdad.

• Y la velocidad deja de ser el fin: pasa a ser una herramienta al servicio del sentido.

Porque en el fondo, construir producto siempre fue una conversación entre lo que el negocio puede, lo que el usuario necesita y lo que el equipo entiende.

La IA solo hace que esa conversación ocurra más rápido.

Pero el valor sigue estando, como siempre, en lo que decidimos escuchar.

El product manager vivía cómodo entre tasas de conversión, embudos y cohortes. Pero con la llegada de la inteligencia artificial, esa claridad empezó a desvanecerse. Porque, ¿cómo mides el éxito de algo que aprende, cambia y genera resultados diferentes cada vez? ¿Cómo sabes si el producto “funciona” cuando ni siquiera hay una única respuesta correcta?

Bienvenido a la nueva frontera del product management: las métricas vivas de los productos con IA.

Cuando las métricas clásicas ya no bastan

Las métricas de toda la vida —DAU, retención, conversión— siguen siendo útiles, pero cuentan solo una parte de la historia. Un chatbot puede tener miles de usuarios diarios, pero si la mayoría lo abandona frustrado después de tres respuestas, esa métrica deja de significar éxito. La IA introduce una capa de complejidad: no solo hay que medir lo que el usuario hace, sino cómo se siente y qué aprende el sistema.

Un producto inteligente no se mide solo por lo que entrega hoy, sino por qué tan bien mejora con el tiempo.

Dos tipos de aprendizaje: el humano y el del sistema

Un buen producto de IA evoluciona en dos direcciones:

1. El usuario aprende a usar el sistema.

   Por ejemplo, en ChatGPT o Midjourney, el usuario mejora sus prompts y obtiene resultados más precisos. La experiencia se vuelve más valiosa con la práctica.

2. El sistema aprende del usuario.

   Sus respuestas, recomendaciones o predicciones mejoran con cada interacción.

Medir estos dos aprendizajes —el del usuario y el del sistema— es el nuevo reto del PM. Porque el valor real no está en una acción puntual, sino en la relación dinámica entre ambos.

Nuevas métricas para una nueva era

Aquí tienes algunas métricas emergentes que los equipos más avanzados están usando para medir productos con IA:

1. Tasa de éxito percibido (Perceived Success Rate)

No mide si la IA “acertó” técnicamente, sino si el usuario sintió que la respuesta fue útil. En IA generativa, esa percepción es más importante que la precisión.

2. Confianza del usuario (User Trust Index)

Una métrica subjetiva, pero medible con feedback continuo: ¿qué tan dispuesto está el usuario a delegar tareas al sistema? ¿cuándo deja de revisar o corregir lo que la IA sugiere?

3. Reducción de esfuerzo (Effort Reduction Rate)

Mide cuánto trabajo ahorra el producto al usuario. Si antes necesitaba cinco pasos y ahora solo uno, el valor de la IA está ahí, aunque el flujo total sea más corto.

4. Tasa de aprendizaje del modelo (Model Learning Rate)

Indica cuánto mejora el modelo con cada nueva interacción. Por ejemplo, si el porcentaje de respuestas “satisfactorias” aumenta sin intervención humana, el sistema está aprendiendo bien.

5. Tasa de corrección humana (Human Correction Rate)

Cuántas veces el usuario necesita corregir o reintroducir una respuesta. Una IA con baja tasa de corrección inspira confianza; una con alta tasa genera frustración o desconfianza.

6. Calidad emergente

Mide cómo evoluciona la experiencia cuando el producto se usa en contextos distintos. Por ejemplo, ¿responde igual de bien un asistente de IA en inglés que en español? ¿mantiene consistencia entre usuarios expertos y novatos?

El cambio de mentalidad: de métricas absolutas a métricas evolutivas

El PM clásico medía estados: cuántos usuarios tengo, cuántos compran, cuántos se quedan. El PM de productos con IA mide trayectorias: cuánto aprende el sistema, cuánto confía el usuario, cuánto se reduce la fricción con el tiempo. El foco pasa de la foto al vídeo. No importa solo el resultado puntual, sino la curva de aprendizaje entre el usuario y la IA.

Métricas que también pueden engañar

No todo lo que se puede medir tiene sentido.

Algunos errores comunes:

• Confundir engagement con valor. Que el usuario interactúe mucho no significa que esté satisfecho. A veces, la alta interacción es síntoma de que la IA falla y el usuario insiste.

• Celebrar mejoras locales sin ver el sistema completo. Un modelo que reduce errores en un área puede generar nuevos sesgos en otra.

• Optimizar para la precisión, ignorando la percepción. Un asistente ultra preciso pero frío y robótico puede ser peor que uno algo menos exacto, pero más empático.

En IA, medir bien significa entender el contexto del error tanto como el acierto.

El rol del PM: diseñar la conversación con los datos

El PM ya no solo define qué construir, sino qué medir y por qué. Y, sobre todo, cómo conectar esas métricas con la experiencia real del usuario. Debe convertirse en traductor entre datos y significado. No basta con tener dashboards: hay que saber qué historia cuentan y qué historia ocultan. En productos con IA, las métricas no son solo indicadores de rendimiento; son parte del diseño del sistema. Lo que decides medir, termina moldeando lo que la IA aprende.

El takeaway

Los productos con IA no se evalúan solo por cuántos los usan, sino por qué tan bien aprenden, ayudan y generan confianza.

El éxito ya no está en las conversiones o los clics, sino en el grado de entendimiento mutuo entre el usuario y el sistema.

👉 En esta nueva era, el product manager no persigue métricas estáticas, sino señales vivas de aprendizaje, mejora y confianza.

El reto no es medir más, sino medir mejor.

La primera vez que usaste ChatGPT y te devolvió una respuesta perfectamente redactada, o cuando Spotify te descubrió una canción que parecía escrita para ti, sentiste esa mezcla de asombro y gratitud que solo generan los productos “mágicos”.

Pero esa misma magia tiene un lado oscuro: en cuanto el usuario no entiende por qué el sistema hace lo que hace, la confianza se resquebraja.

La línea entre el “esto es increíble” y el “esto da miedo” es más fina de lo que parece.

La paradoja de la IA: cuanto más acierta, menos entendemos cómo

La IA tiene una cualidad curiosa: cuanto más sofisticada es, más opaca se vuelve.

Los sistemas basados en reglas clásicas eran fáciles de explicar —si pasa X, haz Y—.

Pero los modelos modernos aprenden de millones de ejemplos, ajustan pesos invisibles y generan resultados imposibles de rastrear por completo.

Para un product manager, esto plantea un dilema nuevo:

• Si simplificas demasiado la experiencia, pierdes credibilidad.

• Si la haces demasiado transparente, pierdes fluidez y magia.

Diseñar con IA ya no es solo una cuestión de UX, sino de psicología de la confianza.

La magia bien dosificada

El usuario quiere sentirse entendido, pero no engañado.

Cuando un producto acierta de forma tan precisa que parece leer la mente, la reacción inicial es de asombro… y la siguiente, de sospecha.

Netflix lo aprendió pronto.

En los primeros años de su sistema de recomendaciones, cuando la interfaz explicaba en exceso (“te recomendamos esto porque viste aquello”), la gente desconfiaba del algoritmo.

Hoy, el enfoque es más sutil: te muestran afinidades (“basado en tu historial”) pero sin entrar en detalles que rompan la ilusión.

Por el contrario, Google Photos ofrece una transparencia funcional: “te hemos agrupado estas fotos porque reconocimos caras similares”.

No quita magia, pero añade contexto y control.

El secreto está ahí: mostrar la lógica sin desvelar el truco.

Explicabilidad como experiencia, no como disclaimer

Muchos equipos tratan la explicabilidad como una obligación legal o ética, cuando en realidad es una oportunidad de diseño.

No se trata de añadir un texto que diga “esta respuesta fue generada por IA”, sino de integrar señales que transmitan control.

Ejemplos:

• ChatGPT añade la frase “puede contener errores” como recordatorio sutil de incertidumbre.

• Midjourney permite ajustar el nivel de aleatoriedad de las imágenes generadas, dándole al usuario sensación de agencia.

• YouTube Music o TikTok dejan claro cuándo una recomendación es automática, sin romper el flujo.

La explicabilidad no tiene que restar fluidez; puede convertirse en parte de la confianza emocional del producto.

Diseñar con grados de opacidad

No todos los usuarios necesitan el mismo nivel de explicación.

El reto está en adaptar la transparencia al contexto y al perfil:

• En tareas de entretenimiento, la magia pesa más.

  Nadie quiere un análisis técnico de por qué Netflix cree que te gustará Succession.

• En tareas críticas —salud, finanzas, educación— la transparencia debe ser total.

  El usuario no quiere magia; quiere garantías.

Por eso, los mejores productos de IA no son completamente transparentes ni totalmente opacos. Son gradualmente explicables: ofrecen más contexto cuando el usuario lo necesita, no antes.

De la interfaz a la “interconfianza”

Durante años diseñamos interfaces: pantallas, botones, interacciones.

La IA nos obliga a diseñar algo nuevo: la interconfianza.

Ya no basta con que el usuario sepa qué hacer; debe creer que el sistema hará lo correcto.

Esa confianza se construye con señales sutiles:

• Feedback inmediato y coherente.

• Coherencia entre lo que el sistema dice y lo que hace.

• Capacidad de corrección cuando el modelo falla.

Un sistema de IA sin posibilidad de corrección es una caja negra; con corrección, se convierte en un compañero.

El rol del PM: guardianes de la confianza

En productos impulsados por IA, el PM no solo define qué hace el sistema, sino también cómo explica sus decisiones.

Debe asegurar que cada predicción, recomendación o acción tiene un nivel adecuado de claridad para su impacto.

No se trata de elegir entre magia o transparencia, sino de encontrar el punto exacto donde el usuario puede decir:

“No sé exactamente cómo lo hace, pero sé que puedo confiar en él.”

Esa es la frontera donde ocurre el verdadero valor de la IA.

El takeaway

Diseñar experiencias con IA no es un ejercicio de mostrar poder técnico, sino de construir confianza emocional.

El usuario debe sentir que el sistema le entiende,

pero también que él sigue al mando.

👉 La magia sin explicabilidad se vuelve sospechosa.

La explicabilidad sin magia se vuelve aburrida.

El equilibrio entre ambas es, probablemente,

la nueva frontera del diseño de producto.

Hoy esa visión se queda corta. Con la llegada de la inteligencia artificial, los productos han dejado de ser un catálogo cerrado de funciones para convertirse en ecosistemas vivos, donde la experiencia de usuario depende tanto de lo que el equipo diseña como de lo que el modelo aprende en cada interacción.

El PM ya no gestiona solo funcionalidades; gestiona comportamientos emergentes.

Del botón al comportamiento emergente

En un producto tradicional, el PM podía prever con exactitud lo que ocurriría tras cada acción del usuario.

• Si el usuario hacía clic en “añadir al carrito”, el sistema añadía un ítem.

• Si pulsaba “guardar”, el sistema guardaba.

Era una lógica determinista: input definido → output esperado.

Con IA, esto cambia radicalmente.

• Una misma acción puede generar resultados distintos según contexto y datos.

• La calidad ya no depende solo del código, sino también del dataset de entrenamiento, el modelo, y la situación particular del usuario.

• El producto evoluciona con el uso: cada interacción entrena al sistema, ajusta respuestas, mejora (o empeora).

Ejemplo claro: GitHub Copilot.

No es un simple “autocomplete” avanzado; es un copiloto que propone soluciones basadas en millones de repositorios y en el estilo concreto de cada desarrollador. El valor no está en un botón, sino en un ecosistema de datos y aprendizaje continuo.

Nuevos retos para el PM

Este cambio obliga a los product managers a repensar su rol en profundidad:

1. Diseñar experiencias, no outputs

Ya no puedes prometer un resultado fijo. Lo que diseñas son márgenes de confianza: qué es aceptable, cómo corregir errores y cómo comunicar incertidumbre al usuario. Un ejemplo es Google Translate, que hoy muestra alternativas a una traducción, reconociendo que puede haber más de una respuesta válida.

2. Gestionar datos como producto

Los datos dejan de ser un “input técnico” para convertirse en materia prima estratégica. El PM debe hacerse preguntas:

• ¿De dónde vienen nuestros datos?

• ¿Qué sesgos contienen?

• ¿Con qué frecuencia deben actualizarse?

  Sin buenos datos, no hay buen producto de IA, y ese es un terreno donde el PM ya no puede ser un invitado pasivo.

3. Equilibrar magia y control

El gran atractivo de la IA es su efecto “wow”: un sistema que parece entenderte. Pero demasiada magia puede romper la confianza si el usuario no entiende qué ocurre. Los mejores productos buscan equilibrio: sorprenden, pero también ofrecen explicabilidad y opciones de corrección.

4. Pensar en ecosistemas, no features

La IA rara vez es autosuficiente. Requiere integraciones, partners, APIs, comunidades. El rol del PM pasa de priorizar funcionalidades a orquestar un ecosistema.

Casos reales que lo ilustran

• ChatGPT Plugins: OpenAI no añadió “una feature” más; abrió un ecosistema de extensiones donde terceros aportan valor. El PM aquí diseña un marco, no un catálogo.

• Spotify + IA: su función de “DJ con inteligencia artificial” combina datos de escucha, modelos generativos y curación editorial. No es un botón nuevo; es una capa de inteligencia sobre todo su ecosistema de contenido.

• Tesla Autopilot: la conducción asistida no depende de una funcionalidad fija, sino de un sistema que aprende de millones de kilómetros recorridos. Cada coche alimenta al ecosistema.

En todos los casos, el PM deja de ser gestor de tareas para convertirse en arquitecto de sistemas complejos.

Qué cambia en la práctica del día a día

1. Discovery

   Ya no basta con entrevistas y encuestas. El PM debe considerar la disponibilidad y calidad de datos como parte del discovery.

2. Roadmap

   No se planifica solo en términos de funcionalidades, sino también de mejora de modelos, pipelines de datos e integraciones.

3. Validación

   El éxito no es binario (funciona / no funciona). Hay grados de precisión, confianza y satisfacción del usuario.

4. Iteración

   El aprendizaje continuo del modelo requiere pensar en ciclos de mejora diferentes a los de un producto de software clásico.

El nuevo toolkit del PM

El PM en la era de la IA no necesita ser ingeniero de machine learning, pero sí incorporar nuevas competencias:

• Entender lo básico de cómo funciona un modelo (inputs, outputs, limitaciones).

• Saber evaluar datasets: tamaño, representatividad, sesgos.

• Manejar métricas nuevas: confianza del usuario, tasa de error aceptable, impacto del feedback en la mejora del modelo.

• Diseñar flujos con “human-in-the-loop”: cuándo interviene la IA y cuándo debe decidir la persona.

El takeaway

La inteligencia artificial ha transformado la gestión de producto. Ya no se trata de añadir features, sino de orquestar ecosistemas donde datos, modelos, usuarios y partners conviven.

El PM deja de ser un gestor de funcionalidades para convertirse en un arquitecto de experiencias emergentes.

Su reto ya no es solo priorizar qué construir, sino también decidir cómo habilitar un sistema vivo que evolucione con cada interacción.

👉 En la era de la IA, el producto ya no es un catálogo de funcionalidades.

Es un organismo en constante aprendizaje.

Y el PM, más que nunca, es el responsable de que ese organismo crezca sano, útil y confiable.