Notas de producto sobre herramientas, pruebas y lanzamiento
La aplicación tiene cien funciones. Cinco importan.
TL;DR: Los equipos añaden opciones más rápido de lo que las quitan, y publican sin probar la puerta principal. La solución no tiene nada de glamour. Dibuja el recorrido del usuario antes que la pantalla. Reduce cien funciones a las cinco que cargan con el uso. Describe las herramientas con claridad suficiente para que un modelo pueda construir la interfaz a partir de ellas. Prueba con el modelo más pequeño disponible, y después prueba a mano cada mañana hasta que la automatización se gane el derecho a sustituirte.
Este artículo también está disponible en English , Deutsch y Italiano .
Dibuja el recorrido antes que la pantalla
El trabajo de producto suele empezar con una pantalla. Alguien abre un archivo de diseño, arrastra componentes, dibuja una tarjeta, añade un interruptor, añade tres botones. El resultado se ve pulido y no ayuda a nadie a terminar una tarea.
El orden es el problema. Lo primero que hace falta es un diagrama de flujo del recorrido del usuario. Qué va primero. Qué va después. Qué va en tercer lugar. Qué depende de qué. Qué funciones se usan con más frecuencia. Qué funciones importan más.
Cuando ese dibujo está limpio, la aplicación se puede diseñar alrededor de él. Y las herramientas que hay detrás también se pueden diseñar alrededor de él. Un dibujo, dos resultados: la interfaz y la API.
Cien funciones, cinco que importan
Un producto puede tener cien funciones, o cien cosas que se pueden configurar, y probablemente solo cinco de ellas se usan el 99.9 por ciento del tiempo.
Esas cinco tienen que estar delante. Tienen que funcionar todas las veces. Todo lo demás pasa al fondo, donde sigue accesible sin competir por la atención.
Esto no es un argumento contra las funciones. Es un argumento sobre la colocación. Una capacidad que nadie encuentra en la primera pantalla es una capacidad que nadie usa.
Reduce el presupuesto de confusión
La misma lección aparece dos veces, una en el diseño de herramientas y otra en el diseño de interfaces. Dale a un agente demasiadas herramientas y demasiadas capacidades y se confunde. Duda, elige lo que no toca, inventa argumentos o vuelve al punto de partida.
Una persona frente a una pantalla llena de opciones se comporta igual. Más botones y más ajustes no añaden potencia. Añaden caos.
La respuesta no es mejor documentación. Son menos cosas. Reduce, reduce, reduce, y concentra toda la superficie en la tarea.
Herramientas, capacidades, particularidades
La forma correcta de un servidor de herramientas no es una lista plana. Tienes una herramienta, la herramienta tiene capacidades, y las capacidades tienen capacidades. Se abre hacia atrás, como un árbol.
En el primer nivel solo están las herramientas. En el segundo nivel están las capacidades. En el tercer nivel están las particularidades de esas capacidades.
Esa estructura no es decoración. Es como un lector, humano o modelo, aprende el producto sin una conversación. Una lista plana de cuarenta endpoints no le dice a nadie por dónde empezar.
Una descripción clara ya contiene la interfaz
Un servidor MCP es una API con descripciones de cómo funciona esa API. Cuando la descripción no da lugar a dudas, el lector conoce el recorrido del usuario a partir de ella.
Eso abre una puerta. Si un modelo tiene el sistema de diseño por un lado y la herramienta por el otro, puede generar la pantalla que hay en medio. El traductor en el medio es un modelo de lenguaje.
Esto elimina toda una clase de reunión. Cuando la descripción es clara, no queda nada que discutir. O el flujo se puede construir a partir de ella o no se puede.
La prueba es la velocidad, no el gusto
Los debates de diseño suelen terminar en una opinión. Si la opción A va encima de la opción B no es una pregunta que alguien pueda resolver discutiendo.
Hay una versión medible. Cuánto tarda un agente en ir de A a B dentro del producto. Cuánto tiempo tiene que pensar. Dónde se confunde.
Eso convierte la calidad de la interfaz en un número. También expone la realidad: un agente que lee un servidor MCP en vivo dirá, sin rodeos, que no entiende esto y que esto no está bien resuelto.
Prueba con el modelo más tonto que encuentres
Un modelo de frontera arregla los nombres malos adivinando por el contexto. Rellena el argumento que falta, elige la herramienta probable y llega igual. Eso lo convierte en un mal juez de si una interfaz es clara.
Los modelos pequeños, de poco razonamiento y poco contexto, no arreglan nada. Si el nombre está un poco desviado, fallan. Si el flujo se ramifica sin necesidad, se pierden.
Así que el modelo pequeño se convierte en el instrumento. Si el modelo más tonto que encuentres llega, la interfaz es realmente clara. Si no llega, el problema es la descripción, no el modelo.
Simplificar significa quitar
El objetivo es simplificarlo todo, reducirlo al mínimo y quitar elementos. No añadir elementos. Menos opciones, menos funciones, menos funcionalidad en cada pantalla.
Eso también descarta una jugada popular. Reconstruir desde cero no es progreso automático. Una reescritura que termina en el mismo sitio ha costado un trimestre y no ha cambiado nada.
El deseo que vale la pena proteger es la reducción a lo necesario. Todo lo demás es actividad.
Un trabajo, una pantalla, en todas partes
Cambiar de una moneda a otra no debería tener dos pantallas distintas. Debería verse 100 por ciento igual en todos los sitios donde aparece.
Lo mismo en la aplicación, lo mismo en un enlace de pago, lo mismo cuando alguien añade dinero a un wallet. El enlace de pago es para gente que está fuera del producto, y eso no cambia nada. Añadir dinero a tu wallet y pedir dinero por email son el mismo trabajo.
Cada pantalla que se ve distinta para el mismo trabajo es otra cosa que el usuario tiene que aprender. La consistencia no es una preferencia de estilo. Es una decisión de coste.
Los agentes de navegador leen la misma pantalla
Hay dos tipos de agente. Uno llama a una API que se construyó para él. El otro abre un navegador y mira lo que vería una persona.
El segundo tipo está creciendo, y no necesita una interfaz especial. Necesita que la interfaz normal se explique por sí misma de inmediato.
Esa es la prueba real de un diseño. Si un agente de navegador en un teléfono o en un escritorio no puede deducir para qué sirve la pantalla, una persona en esa misma pantalla también está adivinando.
Prueba a mano hasta que la automatización se lo gane
Las pruebas automatizadas solo comprueban lo que alguien ya pensó en afirmar. Hasta que una suite cubre de verdad los recorridos que importan, una ejecución en verde no es prueba de que la puerta principal se abra.
Así que la regla es manual. Elige los diez recorridos que importan, y todo el equipo los recorre en un dispositivo real por la mañana, antes del email y antes del primer pull request. Hazlo hasta que algo automático lo sustituya.
Esta es la parte menos de moda de la lista y la que más cosas atrapa. Una pantalla de login que nadie puede pasar no es un caso límite. Es el producto.
Cuando nadie del equipo abre el producto
Un login roto es un bug. Un login roto que sobrevive varios días es la respuesta a otra pregunta.
Si el equipo no abre el producto una mañana normal, el producto no lo están usando las personas más cercanas a él. Cada bug se convierte entonces en un ticket abstracto en lugar de una molestia personal.
La versión directa: haces una fiesta y no viene nadie. Esa sensación es un dato. Normalmente significa que el producto nunca estuvo en la rutina diaria, y ninguna cantidad de funciones nuevas cambia eso.
Una fecha límite gana a un modelo mejor
La generación de código cambió la forma del problema del junior sin eliminarlo. Un ingeniero junior con un modelo de frontera y sin un socio senior no va más rápido. Se pierde, con educación, durante días.
El patrón es predecible. Se pide un componente, aparece una implementación enorme, falla la compilación, el error vuelve al modelo, el modelo propone un refactor. Diez días después sigue sin haber un swap terminado.
Lo que falta no es habilidad ni motivación. Es una fecha límite, y alguien con quien trabajar el problema. La generación de código sin un límite de entrega produce la sensación de trabajar y ningún resultado.
Cuando una persona puede construirlo todo
Hay un modo de fallo que solo aparece cuando una persona senior se vuelve muy rápida. Antes, algunas partes de un sistema simplemente quedaban fuera del alcance de una sola persona. El trabajo tenía que entregarse entero, y solo avanzaba cuando la otra persona lo entregaba.
Esa dependencia creaba urgencia. Quítala y pasa algo silencioso. Cuando todos saben que la persona más rápida va a intervenir y arreglarlo, nadie se queda hasta tarde con el problema difícil. Esperan la queja y la reescritura.
Poder hacerlo todo uno mismo no es lo mismo que ser efectivo. En algún punto la regla tiene que ser que una cosa rota siga rota para quien es su dueño, el tiempo suficiente para que lo note. La alternativa es un proyecto donde una persona hace el trabajo y el resto mira.
Distribución sin presupuesto de anuncios
Pagar por tráfico es la forma cara de que te ignoren. La ruta más barata ya está sentada en las llamadas de integración.
Antes, los eventos que salían bien eran los que se construían con diez equipos independientes, cada uno trayendo su propia audiencia. El mismo movimiento funciona con socios de infraestructura. Graba una llamada corta, haz cinco preguntas reales sobre la integración, publica el resultado, y los dos lados lo comparten.
Un artículo técnico escrito con un socio llega a la audiencia del socio y a la audiencia de quien construye a la vez. Eso son 200 usuarios nuevos de una sola conversación, más un documento que demuestra que la integración funciona.