Antes de pedir a un agente, un objetivo con una cifra.

El 29 de septiembre de 2026, la pantalla de caja de Dot, mi aplicación de fidelización, era lenta. En un mostrador concurrido, el cajero tenía que iniciar una solicitud, tocar el importe, abrir el selector de país, elegir país, tocar el teléfono y pulsar Generar. Seis toques más la escritura, y ningún campo recibía el foco al abrir la pantalla.

A las 17:50 de ese día llegó al repositorio una especificación de diseño. Tenía mucho contenido: ocho estados de pantalla, el texto de cada error y la distribución al píxel. La tabla importante tenía cuatro filas y un título sencillo: «Presupuesto de toques». Para un cliente habitual que da su teléfono, tenía dos columnas. Hoy: seis toques más escritura. Nuevo: dos toques más escritura.

Todo lo demás seguía de esa celda. Dos toques significaban que el cajero no podía tocar para pasar de un campo al siguiente. Los teclados telefónicos de iOS no tienen tecla Intro ni Siguiente, así que solo se podía ahorrar ese toque moviendo el foco automáticamente, y eso solo es posible al salir de un campo de longitud conocida. El teléfono la tiene. El importe no. Por eso la especificación ponía el teléfono primero y, al introducir el último dígito, el foco saltaba solo al importe.

A las 19:13 llegó el commit de implementación con Claude como coautor: «teléfono primero, dos toques para un cliente habitual». Un minuto después llegó el commit de pruebas, también coescrito con Claude. Abre la caja en un móvil de 375 píxeles, en árabe y en inglés, escribe el número de un cliente habitual y un importe, pulsa Añadir puntos, pulsa Siguiente cliente y comprueba que la caja vuelve a estar vacía con el cursor en el teléfono. La prueba se llama «lleva a un cliente habitual del reposo al éxito en dos toques». La solicitud de cambios se integró a las 19:44.

Menos de dos horas entre especificación e integración. Claude coescribió el código y la prueba. La cifra dijo a ambos qué significaba terminar.

Ideas clave

• Antes de dar instrucciones a un agente de IA, se escribe un objetivo con una cifra. «Los clientes habituales ganan puntos en dos toques» es un objetivo. «Agilizar la caja» es un deseo.
• El sprint de diseño de GV empieza igual: el lunes por la mañana el equipo comienza por el final y acuerda un objetivo a largo plazo. El miércoles lo usa para elegir soluciones.
• Un agente necesita la cifra más que un equipo. La guía de Claude Code de Anthropic dice que Claude se detiene cuando el trabajo parece terminado. Sin una comprobación ejecutable, esa apariencia es su única señal.
• La cifra va en tres lugares: la primera línea de las instrucciones, una prueba que falla hasta que se cumpla y la revisión.
• Una cifra aislada invita a hacer trampas. Hay que escribir qué no debe romperse para alcanzarla, como la especificación de Dot, que aceptaba un toque más para evitar conceder puntos tarde y en silencio.
• Puede que el modo de planificación haya muerto. El objetivo no. Un plan ocupa páginas. Un objetivo ocupa una línea y sobrevive a cada iteración.

¿Qué significa «empezar por el final» en un sprint de diseño?

El sprint de diseño de GV es un proceso de cinco días para responder preguntas críticas de negocio mediante diseño, prototipos y pruebas con clientes. Jake Knapp empezó a dirigir sprints en Google en 2010 y los llevó a GV en 2012. El lunes se representa el problema, el martes se dibuja, el miércoles se decide, el jueves se construye un prototipo y el viernes se prueba con personas reales.

El lunes por la mañana va primero, y la descripción de GV es breve: empezar por el final y acordar un objetivo a largo plazo. Después se hace un mapa del reto, se pregunta a los expertos de la empresa y se elige una parte del problema lo bastante pequeña como para resolverla en una semana.

El objetivo vuelve el miércoles. Para entonces hay una pila de soluciones dibujadas y solo puede prototiparse una. El equipo critica cada propuesta y decide cuáles tienen más posibilidades de alcanzar el objetivo. Lo escrito el lunes es la regla del miércoles. Sin ella, el miércoles se vota por gustos.

GV atribuye esta parte del método a John Zeratsky. Explica que ayudó a empezar por el final y a centrarse en medir resultados con las métricas clave de cada negocio. El final va primero y es algo medible.

Mi guía del proceso de diseño coloca el mismo paso al inicio de la fase de empatía, antes de entrevistar: una frase sobre qué debe cambiar el proyecto y cómo se sabrá que ha cambiado, con la cifra que lo demostraría. En un equipo, mantiene a todos mirando en la misma dirección. Con un agente, cumple otra función.

¿Debe tener una cifra el objetivo del sprint?

La mayoría de guías dice que no, o no necesariamente. La página de objetivo a largo plazo de Design Thinking Toolkit, uno de los primeros resultados para esta pregunta, lo construye con tres partes: un plazo, un logro aspiracional concreto y una métrica opcional. Sus ejemplos miran años adelante y dicen cosas como «seremos la primera opción para». Al preguntar hoy a ChatGPT o Perplexity, se recibe el mismo consejo: sacar las cifras del objetivo y ponerlas en criterios de éxito separados.

Para un equipo de sprint, sirve. Pasa cinco días junto, lleva el contexto en la cabeza y prueba con clientes reales el viernes. Las personas de la sala se encargan de medir.

Quien construye a solas con un agente no tiene esa sala. No se puede exigir a un agente que cumpla una gran aspiración, porque esta no devuelve aprobado o suspenso. «La caja que encanta a los cajeros» es una buena convicción. El agente solo puede trabajar hacia «dos toques».

Conviene mantener ambos en dos líneas. La aspiración arriba, si ayuda al equipo. La cifra debajo, porque es la línea que usarán el agente, la prueba y quien revise. El reconocimiento de GV a Zeratsky ya une las dos cosas: empezar por el final y medir los resultados.

¿Por qué necesita un agente una cifra más que un equipo?

Un equipo replica. Ante un objetivo vago, alguien pregunta qué significa «más rápido». Un agente hace una versión plausible y se detiene.

Anthropic lo dice en sus buenas prácticas de Claude Code: Claude se detiene cuando el trabajo parece terminado. Sin una comprobación ejecutable, esa apariencia es la única señal y la persona se convierte en el bucle de verificación. Cada error espera a ser detectado. La solución de la guía es dar a Claude algo que apruebe o suspenda para que cierre el bucle: hacer el trabajo, ejecutar la comprobación, leer el resultado y seguir hasta que pase.

Desde el lado del agente, eso es un objetivo con una cifra. «Dos toques para un cliente habitual» puede aprobar o suspender. «Un pago más fluido» no.

En mayo vimos qué pasa sin esa cifra. Al ejecutar ux-skill, el motor de diseño que construyo, sobre el encargo de su propia página de inicio, todo eran adjetivos: editorial, seguro, tranquilo, cinematográfico. Obedeció cada palabra y devolvió casi la página de claude.ai, la respuesta más probable de la categoría. Lo conté en ¿puede la IA sustituir la investigación con usuarios?. Los adjetivos señalan un promedio. Una cifra señala un lugar.

El comando más reciente /goal de Anthropic expresa lo mismo en el producto. Se escribe una condición de finalización y, tras cada turno, otro modelo comprueba si se cumple. Si no, Claude sigue. La documentación dice que una condición que resiste muchos turnos suele tener tres partes: un estado final medible, una comprobación explícita que lo demuestre y las limitaciones importantes durante el proceso. Su ejemplo es «pasan todas las pruebas de test/auth y el análisis de estilo está limpio». Es un objetivo de sprint con la cifra escrita.

¿Cómo se escribe un objetivo con una cifra?

Antes de abrir el agente. Una frase, cinco partes.

Cómo hacerlo

1. La persona. Para quién es y en qué momento real. «Un cajero cansado en un mostrador lleno, una mano en el móvil y otra en el vaso» es una persona. «Usuarios» no.
2. El resultado. Qué consigue. En la caja: un cliente habitual gana puntos.
3. La cifra. Cómo se sabrá que funciona. Toques, segundos, pasos, errores o porcentaje de personas que terminan. Una sola.
4. El valor actual. Contarlo en el producto antes de fijar la meta. Seis toques era la caja existente. Una meta sin referencia es una suposición con decimales.
5. Cómo se mide. Quién o qué lo comprueba y dónde. En la caja, una prueba de navegador en un móvil de 375 píxeles, en ambas lenguas.

Juntas: «Un cliente habitual gana puntos en dos toques más escritura, frente a seis, medido en un móvil de 375 píxeles en árabe y en inglés».

El mismo patrón sirve para un producto que aún no existe. En el ejemplo de Bunn de mis plantillas gratuitas, el problema dice: Rana necesita pedir café para tres personas en menos de un minuto porque la reunión de las 10:00 empieza puntual. Menos de un minuto es la cifra. Bunn es ficticio, pero la estructura es la que uso en trabajo real.

Qué se obtiene: un filtro. Cada función propuesta por el agente mueve la cifra o espera. Cada comentario de revisión protege la cifra o es una preferencia.

El error habitual: un objetivo que nombra una solución. «Construir una aplicación de fidelización» y «añadir un lector QR» son tareas. El objetivo explica para qué sirven. La especificación de caja añadió un botón de escaneo, pero esa vía tiene su propia fila: tres toques más el importe. También tuvo que justificar su lugar con una cifra.

El segundo error: un objetivo con cinco cifras. Tiempo, toques, errores, satisfacción y conversión en una línea permiten al agente señalar siempre la que haya cambiado. Se elige la cifra que sigue el resultado de la persona, como plantea nadie quiere el producto, y las demás pasan a las limitaciones.

¿De dónde sale la cifra?

De la persona y del producto actual, en ese orden.

Al releer lo que escribí para Wfrah en 2023, tras diez entrevistas con ganaderos el objetivo era una experiencia que enseñara y generara confianza en herramientas modernas atendiendo a sus necesidades. Es una buena dirección y cada palabra venía de la investigación. Hoy veo que no tenía cifra. Decía por dónde caminar. No decía cuándo habíamos llegado.

Tres fuentes dan una cifra fiable.

Contar el producto actual. Los seis toques estaban en la caja anterior y se escribieron en la columna «hoy» junto a la meta. Primero se cuenta, porque la meta solo significa algo frente a una referencia. En un producto con analítica, ya estará en un panel como el de Bysooq. En uno nuevo, será el tiempo que tarda la gente con lo que usa hoy.

Tomarla del momento de la persona. Los dos toques salieron del cajero y el teclado. Una mano sujeta el vaso, la cola espera, por la noche hay poca luz y el teclado no tiene Siguiente. Una cifra que nace de ese momento se defiende fácilmente cuando alguien pregunta por qué dos y no cuatro.

Tomarla de la investigación ya hecha. Si las entrevistas dicen que se abandona el pedido cuando los gastos aparecen tarde, la cifra es cuántos lo terminan. Si la gente falla una tarea en una prueba de usabilidad, la cifra es cuántos la superan.

Cuándo falla: al elegir lo más fácil de medir. Los clics y las visitas son fáciles. Lo importante es si el cajero pudo atender al cliente.

¿Cómo se exige al agente que cumpla la cifra?

Se escribe en tres lugares y se comprueba que coincidan.

Uno: la primera línea de las instrucciones. Antes del contexto, los archivos y las reglas de estilo. Un encargo que empieza por el objetivo y termina con la comprobación mantiene ambos visibles. Este es un ejemplo para la caja:

Objetivo: un cliente habitual gana puntos en 2 toques más escritura, frente a 6.
Comprobación: una prueba de navegador en un móvil de 375px, en árabe e inglés, que falle
si el flujo supera 2 toques. Ejecutarla y mostrar el resultado.
Limitaciones: nunca borrar lo escrito por el cajero. Un reintento nunca concede puntos dos veces.
Sin envío automático al recuperar la conexión.
Especificación: la de caja, sección 1.

Dos: una prueba que falle hasta cumplir la cifra. Es lo que convierte un objetivo en una condición exigible. En la caja, el commit de pruebas llegó un minuto después del de implementación y su nombre es el objetivo. La guía de Anthropic enumera opciones de menor a mayor rigidez: pedir que ejecute la comprobación en la misma instrucción, fijarla como condición /goal de la sesión o convertirla en un hook Stop, un script que impide terminar el turno hasta que pase. Cada paso cambia preparación por atención.

Tres: la revisión. La guía recomienda un revisor con contexto nuevo que solo vea los cambios y los criterios recibidos, no el razonamiento que los produjo. Se le da el objetivo como criterio. Hará la pregunta que olvidó quien escribió: ¿esto requiere realmente dos toques?

Se piden pruebas en vez de afirmaciones: el resultado de la prueba, el comando, una captura. Las pruebas de caja guardan catorce capturas de sus estados en árabe e inglés, dos de ellas en modo oscuro.

¿Qué falla cuando la cifra se convierte en la meta?

El economista Charles Goodhart observó en 1975 que una estadística tiende a perder su utilidad cuando se la presiona para controlar algo. La antropóloga Marilyn Strathern lo expresó después en la forma más citada: cuando una medida se convierte en objetivo, deja de ser una buena medida. La ley de Goodhart se aplica más a agentes que a personas porque el agente presiona la cifra sin entender por qué existe.

Si solo se dice «dos toques», hay atajos baratos: enviar al recuperar la conexión, eliminar la confirmación, omitir deshacer. Cada uno quita un toque y rompe la caja.

La especificación de Dot merece leerse por lo que rechazó. No hay envío automático al volver la conexión: reaparece el botón y el cajero vuelve a pulsar, porque puede haber seguido con otra cosa y una concesión tardía y silenciosa es peor que un toque más. Nunca se borra lo escrito al fallar. Cada intento tiene una clave de idempotencia para que un doble toque nervioso no conceda puntos dos veces, con una prueba específica. Se conserva un plazo de diez minutos para deshacer con motivo obligatorio. Cada regla cuesta toques o código y está escrita junto a la cifra.

Esa es la respuesta a Goodhart. El objetivo tiene una cifra. Las limitaciones contienen todo lo que esa cifra no ve.

Qué escribir en las limitaciones

• Lo que nunca debe pasar. Datos introducidos perdidos, un cobro doble, un fallo silencioso.
• Lo que no se puede sacrificar por la cifra. Accesibilidad, deshacer, el error que nombra el campo y la solución.
• Dónde debe detenerse el cambio. Archivos que no se tocan y comportamientos que se mantienen.

Si no se pueden enumerar al menos dos limitaciones, aún no se entiende la cifra lo suficiente para entregarla a un agente.

¿Ha muerto el modo de planificación?

El 24 de septiembre de 2026 Ayman Nadeem publicó El modo de planificación ha muerto. Alcanzó 591 puntos en Hacker News. Sostiene que los modos de planificación tenían sentido cuando los modelos necesitaban mucha guía y que las fases separadas de conversación, especificación, revisión, aprobación e implementación ahora resultan artificiales. La gente no lee largas especificaciones generadas. El trabajo avanza en ciclos: entender, actuar, inspeccionar, aclarar, ajustar y volver a actuar. La planificación sigue, pero no necesita un documento llamado plan.

Tiene bastante razón sobre los planes. La guía de Anthropic dice que, si el cambio puede describirse en una frase, se omita el plan.

Conviene fijarse en lo que conserva el argumento. Nadeem dice que sigue siendo importante pensar qué construir, por qué importa y evaluar decisiones. El hilo de Hacker News se dividió por esa misma línea. thiht escribió que el modo de planificación ayuda a que el modelo haga realmente lo que se tiene en mente. loeg describió la alternativa: el modelo toma decisiones plausibles y después se le puede pedir que tome otras.

El ensayo de Simon Späti de esa semana, el problema no es el código de IA, nombra lo que se pierde cuando el plan desaparece: los equipos dejan de conocer la intención de las decisiones. Su conclusión es tajante: se acaba sin plan alguno.

Mi posición está entre ambas. Se puede prescindir del plan si frena. Hay que conservar el objetivo. El plan describe el camino y envejece en la primera vuelta. El objetivo describe el destino y sobrevive. Entender, actuar, inspeccionar, ajustar: cada paso necesita una referencia, una línea con una cifra. La especificación de Dot tiene 385 líneas. La tabla de cuatro filas fue lo que determinó la implementación.

¿Cuándo no se debe escribir una cifra?

Cuando la pregunta sigue abierta. Parte del trabajo es exploración, y forzar una cifra demasiado pronto mide con precisión lo equivocado.

Gusto. Que un mapa parezca un lugar o una marca represente a su gente no se reduce a una cuenta. Se puede fijar un marco: tres direcciones para comparar, un plazo y una persona que decide. El juicio sigue siendo humano y el agente produce opciones rápido.

Descubrimiento. Antes de entrevistar, a menudo no se sabe qué cifra importa. En Wfrah no habríamos podido escribir «calcular el pienso en menos de un minuto» antes de descubrir el problema. En esa fase, el objetivo es una pregunta y la cifra es cuántas personas se entrevistarán.

Cuando la cifra sería ficticia. Si no se puede medir en este producto y esta versión, es decoración. «Aumentar la retención un 20%» para una función que sale la semana que viene no da al agente nada comprobable. Se elige algo ejecutable.

¿Qué cambia cuando el producto está en árabe?

Una búsqueda sobre objetivos para productos árabes o de derecha a izquierda no devolvió nada. El vacío importa: comprobar una cifra en una lengua no la comprueba en la otra.

La prueba de caja ejecuta el mismo flujo de dos toques dos veces, en árabe y en inglés. La revisión visual incluye detalles que una prueba monolingüe omitiría: la fila del teléfono sigue de izquierda a derecha en árabe porque así se lee un número en voz alta, y el importe se alinea a la derecha. Las líneas árabes e inglesas rara vez se cortan igual, así que una distribución válida en inglés puede dejar un botón fuera de pantalla en árabe.

Hay que escribir la lengua en el objetivo. «Dos toques en árabe y en inglés» es distinto de «dos toques», y el agente probará lo escrito. Al revisar 179 startups financiadas de MENA, el 44% no tenía web en árabe. El árabe que queda fuera del objetivo suele quedar fuera del producto.

¿Qué plantillas ayudan?

Todas las plantillas gratuitas vienen en árabe e inglés con un ejemplo resuelto, Bunn.

Las cuatro también están en UX AI Kit Pro Max, con instrucciones para Claude en cada una.