Software tranquilo: matar un interruptor que parpadea y enseñar al chat a decir en qué modo está

No todos los lanzamientos son una batallita épica. Algunos son solo una lista de cosas pequeñas, casi invisibles, que estaban discretamente mal — de esas que no rompen nada pero hacen que una app se sienta un pelín poco fiable, un pelín nerviosa, un pelín no-tuya. GeekBye v2.0.3 y v2.0.5 fueron dos de esos. Sin funciones nuevas. Solo calma.

"Software tranquilo" suena a estado de ánimo. En realidad es un montón de decisiones concretas. Aquí van tres de ellas.

Un interruptor que no se decidía

Había un interruptor de ajustes — el que controla la recuperación de audio — que parpadeaba al pulsarlo. Lo activabas, y durante una fracción de segundo mostraba activado, luego volvía de golpe a desactivado, y por fin se asentaba. Un tartamudeo visual minúsculo, pero tu ojo lo capta, y se lee como la app no sabe muy bien lo que está haciendo.

La causa es una clásica carrera de interfaz llamada actualización optimista. Cuando pulsas un interruptor, la app tiene dos opciones: esperar a que el ajuste se guarde de verdad y luego actualizar el switch (correcto, pero se siente lento), o cambiar el switch al instante y guardar en segundo plano (se siente inmediato). GeekBye hacía lo segundo — cambiar al instante — pero además releía el valor guardado cuando este volvía. Así que la secuencia era: pulsas, el switch se activa de forma optimista, el valor guardado real llega un instante después, y durante un fotograma ambos discrepaban y el switch rebotaba visiblemente.

El arreglo es hacer que el valor optimista y el valor confirmado concuerden limpiamente — el switch se compromete con el estado que elegiste y deja de dudar de sí mismo cuando el guardado se confirma. Junto a eso, la v2.0.3 hizo un repaso de textos poco vistoso: la descripción de recuperar-audio se recortó para alinearse con sus filas hermanas, y el texto de ajustes se humanizó. Nada de esto es una función. Todo ello es la diferencia entre un panel de ajustes que se siente construido y uno que se siente cuidado con esmero.

Un tour que no se iba

Los tours para usuarios nuevos son útiles exactamente una vez. El problema es esa unicidad: una vez que lo has visto, una superposición de bienvenida que no puedes descartar se convierte en desorden que señala esta app cree que sigues siendo nuevo. La v2.0.3 arregló ambos extremos — el tour del producto ahora se puede ocultar, y si de verdad lo quieres de vuelta, hay un botón de Repetir tour. Muéstralo cuando ayude, apártate cuando no, y deja que el usuario lo invoque en sus propios términos. Respetar que el usuario ya no es nuevo es su propia pequeña forma de calma.

El asistente que no decía cómo estaba pensando

Este es el que de verdad importaba, y conecta con un problema más profundo que veníamos persiguiendo.

El asistente de GeekBye responde distinto según el contexto. En una reunión, "¿qué opinas de esto?" debería recibir una respuesta conversacional, consciente de la reunión. En una sesión de programación, las mismas palabras deberían recibir una técnica. Así que el backend pasa la pregunta por el encuadre correcto — llámalo modo reunión o modo programación — y ese encuadre cambia de verdad la respuesta que obtienes.

El problema: la app nunca te decía qué modo respondió. Así que cuando el asistente te daba una respuesta con sabor a código a una pregunta conversacional — o respondía una pregunta de código como si estuvieras charlando — parecía que la IA simplemente estaba equivocada. No estaba equivocada; estaba en el otro modo, y no tenías manera de verlo. Un estado oculto hacía que el comportamiento correcto pareciera roto. (La lógica de modo en sí es una pieza de trabajo mayor — el orquestador que decide cómo responder preguntas no relacionadas con código durante una sesión de programación — pero nada de eso te sirve de nada si no puedes ver la decisión que tomó.)

La v2.0.5 añadió una etiqueta de modo de solo lectura al chat: una pequeña etiqueta que muestra si el asistente respondió en modo reunión o en modo programación. Solo lectura es justo el punto — no es un control que tú fijas, es una ventana a una decisión que el sistema ya tomó. Dejas de adivinar por qué una respuesta se siente rara; puedes ver el encuadre del que vino.

El detalle que hace honesta a la etiqueta

Aquí está la decisión de ingeniería que merece la pena transmitir, porque es de esas cosas que separan un indicador atornillado de uno fiable.

La información del modo llega del backend como parte de la respuesta en streaming — un pequeño fotograma mode en el flujo de eventos enviados por el servidor. Pero un cliente antiguo que precede a esta función no sabría qué es un fotograma mode; en el mejor caso lo ignora, en el peor renderiza algo distorsionado. Así que el cliente anuncia su capacidad: envía una cabecera de petición que dice sé mostrar una etiqueta de modo, y el backend solo emite el fotograma mode a los clientes que la enviaron. Los clientes antiguos nunca reciben una señal que no pueden manejar; los nuevos reciben exactamente el fotograma que pidieron.

Es un apretón de manos de una cabecera, y es la diferencia entre "añadimos una función" y "añadimos una función sin romperle nada a quien todavía no ha actualizado." El mismo repaso de revisión apretó el resto del comportamiento: la etiqueta se limpia al resetear y cuando cambia el contexto de la conversación (una etiqueta de modo rancia es su propia pequeña mentira), y solo se muestra en la vista de chat, donde corresponde.

Lo que nos enseñaron dos lanzamientos "sin funciones"

1. El nerviosismo es una señal de confianza. Un interruptor que parpadea, un switch que rebota, una etiqueta que se queda un fotograma de más — ninguno es un bug en el sentido de cierre, pero cada uno susurra esta app no está del todo en control. La calma es la ausencia de esos susurros, y te la ganas una condición de carrera cada vez.
2. Un modo oculto hace que el comportamiento correcto parezca un bug. El asistente estaba haciendo lo correcto y se llevaba la culpa por ello, puramente porque el usuario no podía ver el encuadre. Cuando tu sistema toma una decisión invisible que cambia la salida, muestra la decisión — una etiqueta de solo lectura es a menudo el arreglo entero.
3. Las funciones nuevas deben ser invisibles para los clientes que no pueden usarlas. El apretón de manos por cabecera de capacidad significa que la señal de modo solo llega a los clientes que pueden renderizarla. La compatibilidad hacia atrás no es una comprobación de versión atornillada más tarde; es un cliente diciendo qué entiende y un servidor respetando la respuesta.

Estos son los lanzamientos de los que nadie escribe titulares en el changelog, y son buena parte de por qué GeekBye v2 se siente como se siente. Para el lanzamiento sobre el que se construyó esta calma, mira lo que de verdad cuesta una versión 2 (v2.0.0). Para el trabajo de fiabilidad junto a él, el día que nuestra app se hizo DDoS a sí misma (v2.0.1) y por qué tu notetaker con IA deja de grabar a mitad de reunión (v2.0.9).