He aplicado el autoresearch de Karpathy a una UX mobile y su nivel de "excelencia" pasó del 54% al 100%

El problema era bastante simple. Tengo una funcionalidad de planificación dentro de almirant.ai que funciona bien en desktop, pero en mobile nunca terminaba de sentirse del todo bien. No estaba rota, técnicamente todo funcionaba, pero había demasiada fricción; sentía que se podía simplificar con pequeños ajustes: botones ligeramente desalineados, flujos que requerían un tap extra, layouts que no eran todo lo limpios que deberían. Ese tipo de problemas que son fáciles de tolerar pero difíciles de priorizar.

Ya tenía una lista de correcciones preparada, pero en lugar de recorrer la UI manualmente y “pulir cosas”, quise probar algo diferente. La idea era tratar la mejora de UX como un loop, no como una serie de decisiones aisladas. Medir la experiencia actual, identificar lo más débil, aplicar un cambio, volver a medir y quedarte solo con lo que realmente mejora el resultado.

El primer paso fue definir qué significa realmente “mejor”. Antes de tocar nada, creé un scorecard con varias áreas: funcionalidad, calidad de UX en mobile, calidad visual/layout, responsiveness y robustez. Cada una tenía un peso y criterios concretos detrás.

Para definir ese scorecard no partí solo de teoría. Utilicé la lista de problemas en mobile que ya habíamos identificado como ejemplos concretos de cosas que el sistema debía ser capaz de detectar y mejorar. En ese sentido, Claude Code me ayudó bastante: no solo en la implementación, sino en convertir problemas de UX vagos en algo mucho más estructurado y medible.

Más concretamente, el sistema evaluaba cosas como:

• Funcionalidad (30 puntos): si la sesión se completaba de extremo a extremo, si las preguntas avanzaban correctamente, si las respuestas personalizadas funcionaban y si los mensajes enviados durante el procesamiento se gestionaban bien.
• Calidad de UX en mobile (25 puntos): tamaño de los tap targets, legibilidad de inputs, spacing, overflow horizontal, visibilidad con el teclado y evaluación mediante screenshots por parte del LLM.
• Calidad visual/layout (20 puntos): si el botón “Next” era siempre visible, si el stepper tenía sentido, si había solapamientos y si el chat mantenía correctamente el scroll.
• Responsiveness (15 puntos): tiempo hasta interactivo, velocidad de transición entre preguntas, fluidez del streaming y recuperación tras estados idle.
• Robustez (10 puntos): resistencia a dobles taps, reconexión, rotación de pantalla y estabilidad del flujo ante edge cases raros.

Una vez definido todo eso, automaticé el loop. Ponderé las áreas así porque no quería que el sistema optimizara una “UI bonita” mientras rompía silenciosamente el flujo real. El objetivo era simple: después de cada iteración, el sistema debía poder asignar un número a la experiencia y decir si estaba mejorando o no.

Cada iteración ejecuta el flujo completo de planificación en mobile, toma screenshots en momentos clave, evalúa la UI tanto de forma programática como con un LLM y genera una puntuación. El modelo identifica la parte más débil, propone un cambio, lo aplica y vuelve a ejecutar todo el flujo. Si la puntuación mejora, el cambio se mantiene. Si no, se revierte.

Lo interesante de este enfoque es que elimina mucha subjetividad. En lugar de pensar “esto se siente mejor”, tienes un sistema que intenta optimizar constantemente una superficie definida. Cosas como el tamaño de los tap targets, la visibilidad de botones, el comportamiento del scroll o los solapamientos dejan de ser quejas vagas y pasan a ser constraints que pasan o fallan.

El resultado no fue un gran rediseño. Fue una secuencia de pequeñas mejoras que se van acumulando: arreglar la visibilidad del botón Next, mejorar los tap targets, hacer los inputs más legibles, manejar mejor edge cases como rotaciones o interacciones rápidas. Cada cambio por separado es aburrido, pero juntos mueven bastante la experiencia.

Después de 20 iteraciones, el score de UX en mobile pasó de un 54% a un 100%. No porque el modelo “diseñara algo brillante”, sino porque fue eliminando fricción paso a paso, sin introducir regresiones.

La principal lección: no le pidas a la IA que diseñe cosas. Pídele que las optimice. Define qué significa “mejor”, deja que el loop corra y quédate solo con lo que mueve la métrica. Se parece más a un entrenamiento que a una sesión de diseño. Y funciona.

No creo que esto sustituya la intuición de producto, pero sí te da una forma de formalizarla y hacerla accionable. Y más importante, crea un loop donde el producto puede mejorar de forma mucho más sistemática que simplemente haciendo ajustes manuales.