Lo que rompieron nuestros probadores de la beta, segunda ronda: el silencio que lo bloqueaba todo

Después de una primera prueba con un usuario real, 21 comentarios escritos revelaron un defecto invisible internamente: un tipo entero de etapa no se gestionaba en ninguna parte del motor. La cadena se congelaba en silencio, esperando una respuesta que nunca llegaba.

Después de nuestra primera semana de beta, una segunda prueba con un usuario real produjo 21 comentarios escritos. El más serio no era visible en nuestras propias pruebas: un tipo entero de etapa, el que hace una pregunta y espera la respuesta, no se gestionaba en ninguna parte del motor. La cadena se detenía en silencio y nunca se reanudaba.

El síntoma: una cadena que se congela sin decirlo

La definición de un proyecto a veces hace una pregunta al usuario antes de continuar. En un caso concreto, el brief empezaba a escribirse antes incluso de que la persona hubiera leído la pregunta: el motor avanzaba como si la respuesta ya se hubiera dado, cuando no era así. Un probador con prisa no habría notado nada hasta descubrir, más tarde, un documento que no correspondía a lo que realmente había querido decir.

Por qué nunca nos había pasado

Internamente, un tipo de etapa que se activa rara vez se cuela fácilmente entre las mallas de una revisión de código centrada en los casos frecuentes. Hizo falta un usuario real, en una conversación real, que se tomara tiempo para responder de verdad a una pregunta real, para que apareciera el defecto: exactamente el tipo de escenario que una prueba interna escrita deprisa habría omitido sin darse cuenta. La corrección impone una regla sencilla: la cadena se detiene y se reanuda sin volver a ejecutar una etapa ya superada y, en caso de duda, avanza en lugar de bloquear indefinidamente una secuencia completa.

Una opción eliminada en lugar de añadida

La misma prueba aportó una señal inversa: un selector de modelo de IA, presentado pronto en el recorrido, no ayudaba a nadie a decidir. El feedback de la beta fue claro: la opción predeterminada del motor basta; la mayoría no tiene ganas ni medios para elegir entre dos modelos de IA en ese momento del recorrido. Se eliminó el selector de ese punto concreto en lugar de mejorarlo: a veces, la mejor corrección quita una opción en lugar de añadir otra. Es un reflejo contrario al instinto habitual de producto (añadir otra opción para satisfacer a todos) y exige disciplina real para mantenerse cuando vuelve la calma.

Lo que mostró la telemetría y no los emails

Los comentarios escritos dicen lo que sintió alguien; la telemetría anónima dice lo que ocurrió realmente, etapa por etapa, antes del bloqueo. Cruzar ambas fuentes permitió localizar el defecto en un día, en lugar de adivinar a partir de una descripción aproximada del problema. Sin telemetría, la única pista habría sido un usuario frustrado diciendo que «no pasa nada», una frase que no indica el punto exacto en que el motor se quedó callado.

Lo que sigue pendiente

No todos los defectos detectados en una prueba de usuario se corrigen el mismo día. Algunos esperan una decisión de producto más amplia antes de resolverse, y preferimos decirlo en lugar de fingir que todo está solucionado. Es el mismo principio de nuestros benchmarks publican nuestras derrotas: mostrar lo que falló importa tanto como mostrar lo que funciona.