Demanda latente: cómo nació Plan Mode en 30 min

Sobre este texto. Los detalles del origen de Plan Mode provienen del episodio de Boris Cherny en el podcast The Light Cone (Y Combinator, 17/02/2026). El marco de las 4 señales lo armé yo para uso propio, adaptando lo que él contó. No es un método oficial de Anthropic.

Un domingo a las 22h, Boris Cherny estaba revisando GitHub Issues de Claude Code. No buscaba una funcionalidad. Miraba qué comportamiento querían saltarse los usuarios. Ese domingo notó un patrón: decenas de usuarios escribían frases como “please don’t code yet, just plan first” al inicio de sus sesiones. Otros abrían el chat con “let me confirm the approach first”. Las palabras cambiaban. La necesidad era la misma.

A la mañana siguiente desplegó Plan Mode. La implementación había tomado 30 minutos la noche anterior. Una línea añadida al prompt del sistema: “please don’t code”. Eso fue todo.

Ese fenómeno tiene nombre: demanda latente. Y no aparece en ninguna encuesta de “¿qué funcionalidad quieres?”.

Por qué la demanda latente no sale en las encuestas

Boris lo dijo directamente en el podcast:

La gente solo hace algo que ya hace. No puedes lograr que la gente haga algo nuevo. Lo que sí puedes hacer es que aquello que ya está intentando hacer sea más fácil.

Si le hubieras preguntado al usuario del Issue “¿qué funcionalidad quieres?”, te habría dicho “no sé, mejor autocompletado” o “más velocidad”. Nadie contestó “quiero Plan Mode” porque Plan Mode no era un concepto en la cabeza del usuario. Era un comportamiento que ya estaba haciendo con un workaround, sin ponerle nombre.

La demanda latente aparece en tres lugares. Ninguno es la sección “feature requests” de tu repositorio.

En los workarounds que el usuario ya montó (el prompt manual antes de cada sesión, el copy-paste del CLAUDE.md, la pestaña paralela en la terminal)
En las frases repetidas que aparecen en tus logs, tickets de soporte o mensajes de Slack
En lo que el usuario deja de hacer porque el flujo actual lo cansa: la caída silenciosa cuenta tanto como el uso extra

4 señales para encontrar demanda latente en tu producto

Este es el marco que uso yo cuando reviso mis propios logs. Adapté lo que Boris hizo con GitHub Issues a lo que tenemos disponible en un producto más pequeño.

Señal 1: la frase repetida en prompts o comentarios

Boris encontró Plan Mode porque muchos usuarios escribían la misma frase. No idéntica, pero equivalente. “Don’t write code yet” / “plan first” / “let me confirm before implementing”. Si una idea vuelve con distintas palabras, es que existe en la cabeza del usuario antes de que tu producto le dé un botón.

Cómo detectarla: si tienes algo como Amplitude, busca las cadenas de texto más frecuentes en campos de texto libre. Si es un CLI, mira el historial de comandos de tus usuarios beta. Si es un chat, exporta el corpus y cuenta n-gramas.

Señal 2: el copy-paste manual

Cuando un usuario abre 5 sesiones seguidas y pega el mismo bloque de texto al inicio de cada una, ese bloque es un producto que todavía no existe. Eso fue CLAUDE.md: durante meses los usuarios pegaban “este proyecto usa Next.js 14, TypeScript, Prisma, tests con Vitest” en cada sesión nueva. Anthropic no inventó CLAUDE.md. Lo descubrió. Automatizaron el copy-paste.

Cómo detectarlo: si tienes un chat, busca mensajes con más de 200 caracteres que sean casi idénticos entre sesiones distintas del mismo usuario. Si es un CLI, mira alias en .bashrc que envuelvan tu comando.

Señal 3: la pestaña paralela

Cuando un usuario ejecuta tu herramienta en varias pestañas de la terminal a la vez, o abre 4 pestañas del mismo panel, está pidiendo paralelismo sin pedirlo. Eso fue SubAgent: los usuarios ya paralelizaban a mano con múltiples terminales. Boris solo automatizó lo que ya venían haciendo.

Cómo detectarlo: métrica de “sesiones concurrentes por usuario”. Si el 30% de tus usuarios activos tiene 2+ sesiones abiertas al mismo tiempo, hay demanda latente de paralelismo.

Señal 4: el drop-off silencioso

La más difícil. La demanda latente también aparece por ausencia. Un usuario que usaba tu producto 5 veces por semana y bajó a 1 no siempre te avisa. Se cansó de algo que le generaba fricción, y su comportamiento cambió antes de que su boca dijera nada.

Cómo detectarlo: análisis de cohortes. Segmenta usuarios por semana de activación y mira qué acción específica dejaron de repetir. La acción que desapareció es donde se esconde la demanda latente del próximo alivio.

Por qué la implementación tiene que ser “aburrida”

Lo otro que me quedó de Boris: la implementación fue muy simple. Una línea añadida al prompt del sistema. Nada de un modo nuevo con state machine, ni de un LLM router, ni de un botón personalizado. Una línea.

Boris lo dijo en el podcast: “nunca apuestes contra el modelo”. Si el usuario ya está haciendo el trabajo con un workaround, tu implementación no tiene que ser sofisticada. Tiene que automatizar el workaround exacto. Si te obsesionas con “hacer algo más elegante”, el usuario ya no reconoce lo que estás resolviendo y no adopta.

CLAUDE.md es un archivo de texto plano en la raíz del repositorio. Skills es una carpeta con archivos .md. Ninguna de estas funcionalidades tiene arquitectura. Tienen la misma forma que el workaround manual, solo que automatizada. Esa es la parte más difícil de aceptar para un ingeniero: lo bien resuelto se parece a lo obvio.

Cómo se conecta con lo que ya publiqué en este blog

Si quieres ver cómo se usa Plan Mode una vez que existe, dejé una publicación con el flujo de aprobar antes de ejecutar. Es la contraparte “cómo lo uso” de esta publicación, que es “cómo nació”.

Y si te interesa el patrón “archivo de memoria” que Boris también descubrió por demanda latente (el CLAUDE.md que la gente ya pegaba a mano), armé una guía con 3 patrones de memoria post-compact que uso para que el trabajo importante sobreviva a la compresión de contexto.

Cierre

Demanda latente = comportamiento que el usuario ya hace con un workaround, sin ponerle nombre
No sale en encuestas porque el usuario no tiene el concepto listo para pedirlo
4 señales para detectarla: frase repetida, copy-paste manual, pestaña paralela, drop-off silencioso
La implementación tiene que “parecerse al workaround” para que el usuario reconozca el alivio. Simplicidad radical, arquitectura mínima
Plan Mode tomó 30 minutos porque Boris no peleó contra el modelo. Añadió una línea al prompt del sistema y listo

La parte que a mí me costó aceptar es que la demanda latente no se busca con una entrevista de usuario. Se busca con un domingo por la noche revisando 100 tickets de gente que ya está usando tu producto mal. Es más aburrido y mucho más productivo.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev