O fato
Em 22 de setembro de 2026, o UX Collective publicou The Variance Problem in AI Products: Latency and Trust, de Adi Leviim. O ensaio parte de uma observação simples e incômoda para quem constrói produtos com LLM: o mesmo prompt pode responder em um segundo hoje e em quarenta amanhã, e a interface trata os dois casos exatamente igual. O texto discute por que tempos de resposta variáveis de IA erodem a confiança, e por que nomear o trabalho é melhor que estimativas de tempo e delays artificiais. Ele cruza isso com literatura clássica de usabilidade, Nielsen, Myers, Maister e Tognazzini, que já resolveu esse problema para software determinístico décadas atrás.
Este artigo destrincha o mecanismo, mostra onde ele bate no código e diz onde a solução do Leviim ainda deixa buraco.
Como funciona o problema da variância
O que é variância aqui, em termos concretos
Num sistema tradicional, um clique em Salvar tem latência com desvio pequeno. Se o P50 é 200ms, o P99 talvez seja 800ms. Você projeta o spinner assumindo esse envelope. Em produto com LLM, o envelope estoura. O mesmo pedido pode ter P50 de 2s e P99 de 45s, dependendo de tamanho do prompt, tokens gerados, roteamento do provedor, fila do modelo, ferramenta chamada no meio do caminho. E não estamos falando só de tempo. Não-determinismo não é caso de borda em produtos com LLM, é o padrão. A saída também varia: variância de output, drift comportamental e falha em nível de raciocínio.
O foco do Leviim é a variância de tempo, e é por aí que entramos.
As duas saídas erradas que a maioria dos produtos escolhe
Segundo o autor, produtos de IA hoje lidam com variância de dois jeitos, e cada um troca uma falha por outra. Ou expõem a variância crua, ou achatam com um piso artificial. Variância crua é o spinner com a palavra “Thinking” que parece idêntica em um segundo e em quarenta. O usuário não tem como distinguir uma tarefa longa de uma travada. O piso é mais sutil. Alguns times adicionam um delay mínimo para que respostas rápidas não criem uma âncora irreal. Funciona, no sentido estrito de que rodadas lentas param de parecer quebradas. Mas apaga o lado positivo para prevenir o negativo.
Traduzindo para código, o “piso” é isto aqui, e é mais comum do que parece:
// anti-padrão: piso artificial de 3s
async function askAI(prompt) {
const start = Date.now();
const answer = await llm.complete(prompt);
const elapsed = Date.now() - start;
if (elapsed < 3000) {
await sleep(3000 - elapsed);
}
return answer;
}Toda resposta que poderia ter chegado em 800ms passa a chegar em 3s. Você pagou latência real para comprar uniformidade percebida. Em produto onde a IA compete com uma alternativa rápida, isso é entregar terreno de graça.
Por que o spinner genérico falha, com Nielsen e Maister na mão
A literatura de usabilidade já resolveu metade disso. Nielsen aponta que 10 segundos é o limite para manter a atenção do usuário focada no diálogo. Para atrasos maiores, os usuários vão querer fazer outras tarefas enquanto esperam, então devem receber feedback indicando quando o computador espera terminar. Feedback durante o atraso é especialmente importante se o tempo de resposta tende a ser altamente variável, porque o usuário não saberá o que esperar.
Guarde essa última frase. IA generativa é o caso extremo de “altamente variável”. Um <div class="spinner">Thinking...</div> não é feedback, é um placeholder animado. Ele diz apenas “não travei”, e nem isso com confiança depois dos 30 segundos.
Do outro lado, Maister, no clássico The Psychology of Waiting Lines de 1985. Esperas incertas são mais longas que esperas conhecidas e finitas. As pessoas esperam mais calmamente quando ouvem “o médico atende você em trinta minutos” do que quando ouvem “o médico atende você em breve”. E ainda mais duro: esperar é desmoralizante. Esperar na ignorância cria uma sensação de impotência, que frequentemente resulta em irritação visível.
É por isso que o piloto que repete “só mais alguns minutinhos” enfurece. O usuário não está bravo com o atraso, está bravo por não conseguir mais confiar na estimativa. Interface de IA que fica trocando de “Thinking” para “Almost there” para “Just a moment” está cometendo o mesmo erro.
A proposta: nomear o trabalho, não estimar o tempo
A saída que o Leviim defende é abandonar o placeholder animado e a estimativa de tempo, e em vez disso nomear a etapa real que está acontecendo. Nada disso exige remover a variância. Sistemas de IA vão continuar sendo rápidos às vezes e lentos outras. O que os usuários precisam é de um produto que diga qual dos dois está acontecendo, em palavras que continuem verdadeiras enquanto acontece.
A analogia mais próxima é a cozinha aberta de restaurante. Você não sabe quanto tempo seu prato demora, mas vê o chef pegar a carne, ver a chapa aquecer, montar. A espera continua igual, a sensação muda porque o processo é observável e nomeado. A analogia quebra num ponto: no restaurante você vê o processo físico. Na IA, o processo é inventado pelo desenvolvedor, e essa é justamente a decisão de design.
É a diferença entre isto:
<div role="status" aria-live="polite">Thinking...</div>e isto:
<div role="status" aria-live="polite">
Lendo os 3 PDFs anexados
</div>
// depois:
<div role="status" aria-live="polite">
Cruzando cláusulas de rescisão entre os documentos
</div>
// depois:
<div role="status" aria-live="polite">
Escrevendo o resumo
</div>Os dois usam aria-live="polite" para que o leitor de tela anuncie as mudanças sem interromper a leitura em curso, o que já era o correto no primeiro exemplo, mas ali o leitor de tela não tem nada útil para anunciar.
O que isso significa na prática
A implementação depende de você conseguir emitir eventos do backend a cada transição real da pipeline. Server-Sent Events ou WebSocket resolvem. O padrão fica assim:
// backend emite eventos nomeados
for await (const step of agent.run(prompt)) {
res.write(`event: step\ndata: ${JSON.stringify(step)}\n\n`);
}
// frontend consome e troca o texto vivo
const es = new EventSource('/ask');
es.addEventListener('step', (e) => {
const { label } = JSON.parse(e.data);
statusEl.textContent = label; // "Buscando na base de contratos"
});Repare no que essa arquitetura força você a fazer no design: escrever o rótulo humano de cada etapa antes de escrever a etapa. Você não pode dizer “lendo os 3 PDFs” se a pipeline não tem uma etapa isolada de leitura. A frase honesta vira uma pressão sobre a arquitetura. Isso é bom.
Já num construtor de landing page que tirou a criação de pagina da fila da engenharia, vi o oposto: a pipeline era rápida o suficiente para que qualquer texto de espera acima de “salvando” fosse mentira. Ali, o certo era não inventar etapa nenhuma, e o spinner de 300ms bastava. Nomear trabalho que não existe é tão ruim quanto esconder trabalho que existe.
O caso em que a solução do Leviim se apoia
Vale reconhecer o limite prático que ele mesmo cita. Como Bilal disse na discussão sobre quanto disso um time pequeno consegue realmente construir: “A shipped sentence beats a coordinated system that never ships.” Se você não tem infraestrutura de streaming de eventos, comece por hardcode: quatro frases pré-escritas trocando em intervalos plausíveis já é melhor que “Thinking”. Só saiba que isso vira dívida no dia que a pipeline mudar e as frases continuarem as mesmas.
Onde quebra
Um. Rótulos honestos exigem que o backend saiba nomear o que está fazendo. Em pipelines com agente autônomo, o próximo passo é decidido pelo modelo em tempo de execução. Você acaba emitindo o pensamento cru (“Calling tool: web_search”), que é técnico demais, ou traduzindo em tempo real para linguagem humana, que introduz outra camada de latência.
Dois. Feedback frequente em aria-live pode virar poluição sonora para leitor de tela. Em dashboard denso em dados de medição de mídia, aprendi que qualquer região viva mal calibrada faz o NVDA anunciar de novo e de novo até o usuário desligar. Use polite, não assertive, e não atualize mais rápido que cerca de dois segundos.
Três. Nomear o trabalho aumenta a expectativa de sucesso. Se o rótulo diz “cruzando cláusulas de rescisão” e a resposta final não menciona rescisão, o usuário percebe a mentira. O texto de espera vira contrato implícito com o resultado. Time de design agora depende do time de modelo para manter esse contrato, e essa dependência não é gratuita.
Quatro. Para respostas de sub-segundo, nada disso importa. Nielsen lembra que 0.1 segundo dá a sensação de resposta instantânea, o resultado parece ter sido causado pelo usuário, não pelo computador. Não empilhe estados de progresso onde o usuário nem viu que houve espera.
O que não dá para afirmar ainda
O ensaio do Leviim não traz estudo controlado que meça, digamos, redução de taxa de abandono entre spinner genérico e progresso nomeado em produto de IA. Ele apoia a tese em princípios clássicos válidos e em relatos de produção citados por Bilal Skiani sobre um sistema chamado Genie 007, que eu não tenho como verificar. Portanto, o mecanismo é sólido pela ciência de percepção de espera, e a aplicação em LLM é razoável, mas o tamanho do efeito em cada tipo de produto continua sendo empírico. Teste no seu.
Também não está claro qual é o custo cognitivo de trocar o rótulo três, quatro, cinco vezes numa resposta longa. É possível que abaixo de certa duração o silêncio narrado seja melhor que a narração.
Como testar isso você mesmo
Pegue seu chat interno com LLM, ou faça um pequeno com a API que você já usa. Faça três variantes da mesma tela:
- A: spinner com “Pensando…”
- B: spinner com barra de progresso falsa que enche em 20 segundos e trava em 95%
- C: texto vivo em
aria-live="polite"que troca a cada etapa real da sua pipeline (ex.: “Lendo o documento”, “Procurando trechos relevantes”, “Redigindo resposta”)
Rode com dez pessoas, use um prompt que você sabe que demora entre 15 e 40 segundos. Pergunte três coisas depois de cada tentativa: quanto tempo achou que demorou, se em algum momento pensou que travou, e se confiaria no sistema para uma tarefa mais crítica. Você vai ter dados seus, não do post do Leviim, sobre onde vale nomear e onde não. Esse é o único jeito honesto de decidir.
