Software calmo: eliminar um botão que pisca e ensinar o chat a dizer em que modo está

Nem toda a versão é uma história de guerra. Algumas são apenas uma lista de coisas pequenas, quase invisíveis, que estavam discretamente erradas — daquelas que não fazem nada ir abaixo mas fazem uma app parecer ligeiramente pouco fiável, ligeiramente nervosa, ligeiramente não-tua. O GeekBye v2.0.3 e o v2.0.5 foram duas dessas. Sem funcionalidades novas. Só calma.

"Software calmo" soa a estado de espírito. Na verdade é uma pilha de decisões concretas. Aqui estão três delas.

Um botão que não se decidia

Havia um botão de definições — o que controla a recuperação de áudio — que piscava quando o clicavas. Ativavas, e durante uma fração de segundo mostrava ligado, depois voltava de repente a desligado, e por fim assentava. Uma gaguez visual minúscula, mas o teu olho apanha-a, e lê-se como a app não tem bem a certeza do que está a fazer.

A causa é uma corrida de interface clássica chamada atualização otimista. Quando clicas um botão, a app tem duas opções: esperar que a definição se guarde de facto e depois atualizar o interruptor (correto, mas parece lento), ou virar o interruptor de imediato e guardar em segundo plano (parece instantâneo). O GeekBye fazia a segunda — virar já — mas também relia o valor guardado quando este voltava. Então a sequência era: clicas, o interruptor liga otimisticamente, o valor guardado real chega um instante depois, e durante um fotograma os dois discordavam e o interruptor saltava visivelmente.

A correção é fazer o valor otimista e o valor confirmado concordarem de forma limpa — o interruptor compromete-se com o estado que escolheste e deixa de duvidar de si próprio quando o guardar se confirma. A par disso, o v2.0.3 fez uma passagem de texto pouco vistosa: a descrição de recuperar-áudio foi encurtada para alinhar com as suas linhas irmãs, e o texto das definições foi humanizado. Nada disto é uma funcionalidade. Tudo isto é a diferença entre um painel de definições que parece fabricado e um que parece tratado com esmero.

Um tour que não se ia embora

Os tours para utilizadores novos são úteis exatamente uma vez. O problema é essa unicidade: depois de o teres visto, uma sobreposição de boas-vindas que não podes dispensar torna-se entulho que sinaliza esta app acha que ainda és novo. O v2.0.3 corrigiu ambos os lados — o tour do produto pode agora ser ocultado, e se realmente o quiseres de volta, há um botão Repetir tour. Mostra-o quando ajuda, sai da frente quando não ajuda, e deixa o utilizador convocá-lo nos seus termos. Respeitar que o utilizador já não é novo é a sua própria pequena forma de calma.

O assistente que não dizia como estava a pensar

Este é o que de facto importava, e liga-se a um problema mais profundo que andávamos a perseguir.

O assistente do GeekBye responde de forma diferente conforme o contexto. Numa reunião, "o que achas disto?" deve receber uma resposta conversacional, ciente da reunião. Numa sessão de programação, as mesmas palavras devem receber uma técnica. Por isso o backend passa a pergunta pelo enquadramento certo — chama-lhe modo reunião ou modo programação — e esse enquadramento muda genuinamente a resposta que obténs.

O problema: a app nunca te dizia que modo respondeu. Então quando o assistente te dava uma resposta com sabor a código a uma pergunta conversacional — ou respondia a uma pergunta de código como se estivesses a conversar — parecia que a IA estava simplesmente errada. Não estava errada; estava no outro modo, e não tinhas forma de o ver. Um estado oculto fazia um comportamento correto parecer avariado. (A lógica de modo em si é uma peça de trabalho maior — o orquestrador que decide como responder a perguntas não relacionadas com código durante uma sessão de programação — mas nada disso te serve de nada se não conseguires ver a decisão que tomou.)

O v2.0.5 adicionou uma etiqueta de modo só de leitura ao chat: uma pequena etiqueta a mostrar se o assistente respondeu em modo reunião ou em modo programação. Só de leitura é o ponto todo — não é um controlo que defines, é uma janela para uma decisão que o sistema já tomou. Deixas de adivinhar por que uma resposta parece estranha; podes ver o enquadramento de onde veio.

O detalhe que torna a etiqueta honesta

Aqui está a escolha de engenharia que vale a pena transmitir, porque é o tipo de coisa que separa um indicador aparafusado de um digno de confiança.

A informação de modo vem do backend como parte da resposta em streaming — um pequeno fotograma mode no fluxo de eventos enviados pelo servidor. Mas um cliente antigo, anterior a esta funcionalidade, não saberia o que é um fotograma mode; no melhor caso ignora-o, no pior renderiza algo distorcido. Por isso o cliente anuncia a sua capacidade: envia um cabeçalho de pedido a dizer sei mostrar uma etiqueta de modo, e o backend só emite o fotograma mode aos clientes que o enviaram. Os clientes antigos nunca recebem um sinal que não conseguem tratar; os novos recebem exatamente o fotograma que pediram.

É um aperto de mão de um só cabeçalho, e é a diferença entre "adicionámos uma funcionalidade" e "adicionámos uma funcionalidade sem partir nada para quem ainda não atualizou." A mesma passagem de revisão apertou o resto do comportamento: a etiqueta limpa-se ao reiniciar e quando o contexto da conversa muda (uma etiqueta de modo obsoleta é a sua própria pequena mentira), e só aparece na vista de chat, onde pertence.

O que duas versões "sem funcionalidades" nos ensinaram

1. O nervosismo é um sinal de confiança. Um botão que pisca, um interruptor que salta, uma etiqueta que fica um fotograma a mais — nenhum é um bug no sentido de ir abaixo, mas cada um sussurra esta app não está bem no controlo de si própria. A calma é a ausência desses sussurros, e ganha-se uma condição de corrida de cada vez.
2. Um modo oculto faz um comportamento correto parecer um bug. O assistente estava a fazer a coisa certa e a levar a culpa por isso, puramente porque o utilizador não conseguia ver o enquadramento. Quando o teu sistema toma uma decisão invisível que muda a saída, mostra a decisão — uma etiqueta só de leitura é muitas vezes a correção inteira.
3. As novas funcionalidades devem ser invisíveis para os clientes que não as conseguem usar. O aperto de mão por cabeçalho de capacidade faz com que o sinal de modo só chegue aos clientes capazes de o renderizar. A retrocompatibilidade não é uma verificação de versão aparafusada mais tarde; é um cliente a dizer o que entende e um servidor a respeitar a resposta.

Estas são as versões sobre as quais ninguém escreve títulos de changelog, e são grande parte da razão por que o GeekBye v2 se sente como se sente. Para a versão sobre a qual esta calma foi construída, vê o que uma versão 2 de facto custa (v2.0.0). Para o trabalho de fiabilidade a par dela, o dia em que a nossa app fez DDoS a si própria (v2.0.1) e por que o teu notetaker de IA deixa de gravar a meio da reunião (v2.0.9).