Copilotos de IA já não bastam; precisamos de HUDs de IA

• A crítica de Mark Weiser à metáfora do "copiloto" de IA, publicada em 1992, continua válida até hoje
• Weiser defendia interfaces que se integrem naturalmente à experiência do usuário, e não um "assistente"
• O conceito de HUD (Head-Up Display) das aeronaves modernas ilustra bem essa filosofia
• Vários exemplos mostram o valor de uma UI em estilo HUD, que amplia os sentidos do usuário, em vez de automação ou interfaces de agente
• Para tarefas cotidianas, o copiloto é eficaz, mas em situações criativas ou não estruturadas, o HUD potencializa ainda mais a capacidade humana

---

A crítica de Mark Weiser ao copiloto em 1992

• Em 1992, Mark Weiser levantou críticas, em um evento do MIT Media Lab sobre “agentes de interface”, à visão que compara a IA a um "copiloto"
• Já naquela época se discutiam problemas que continuam atuais, como percepção de contexto e automação
• Em vez do "copiloto" (uma IA que auxilia o piloto como um humano virtual), Weiser defendia sistemas que permitissem ao usuário perceber informações de forma natural
• Seu ideal era o "computador invisível", um ambiente que se torna uma extensão natural do usuário, como se fosse parte do próprio corpo

HUD (Head-Up Display) e a filosofia de Weiser

• O HUD (Head-Up Display) das aeronaves modernas sobrepõe, em uma tela transparente, informações essenciais como horizonte e altitude, oferecendo-as de forma natural no campo de visão do piloto
• Diferentemente de um copiloto, o HUD não exige conversa e expande naturalmente a capacidade de percepção
• Esse conceito de HUD está alinhado com a usabilidade proposta por Weiser

A realização do HUD no software

• O corretor ortográfico não conversa como um "colaborador de IA"; ele funciona sublinhando automaticamente em vermelho os erros de digitação
• Esse tipo de fornecimento imediato e visual de informação é um exemplo de HUD que cria um novo sentido para o usuário
• Uma UI de depuração personalizada com IA também visualiza intuitivamente o comportamento do programa, permitindo que o usuário identifique e compreenda problemas diretamente
• Essa abordagem se distingue da automação tradicional ou de UIs de "assistente virtual" e amplia diretamente os sentidos humanos

Os trade-offs entre HUD e copiloto

• O autor não afirma que o HUD é sempre melhor que o copiloto; ele explica que cada abordagem tem vantagens e desvantagens
• Para tarefas rotineiras e previsíveis (ex.: voo em linha reta), a abordagem de copiloto é eficiente
• Para problemas não estruturados e criativos (ex.: percepção situacional durante um pouso de emergência), ferramentas que apoiam a cognição humana, como um HUD, mostram grande força
• Projetistas de IA devem ir além do "assistente" e considerar necessariamente UIs de expansão sensorial humana, como HUDs

Conclusão

• No design de IA do futuro, será necessário reconhecer o valor e os trade-offs tanto da abordagem de copiloto quanto da abordagem de HUD
• Deixe a automação comum para os assistentes virtuais; se você quiser resultados melhores, a forma mais poderosa pode ser oferecer ao especialista humano "novos superpoderes", como faz um HUD

[GN⁺]

Comentários do Hacker News

• Tenho muita curiosidade se seria útil ter um recurso para alternar um mapa de calor mostrando o quanto cada token de um arquivo-fonte é surpreendente para o modelo. Tokens vermelhos provavelmente indicariam erros, nomes ruins ou comentários incorretos
  • Às vezes código imprevisível é assim por causa de um algoritmo novo, mas nesses casos uma documentação melhor é indispensável. Se você explica o código direito, ele por si só se torna menos surpreendente. Ou seja, é possível estruturar partes específicas do código-fonte para que não sejam surpreendentes, e talvez isso seja uma boa prática de engenharia. Graças aos LLMs, todo mundo passou a se importar com a importância de uma boa documentação. Ela é ainda mais necessária não só para outras pessoas, mas também para que a IA consiga ler e entender o sistema
  • Acho a ideia muito legal. No sentido oposto, também seria muito útil se as sugestões da IA viessem com um mapa de calor por nível de confiança
  • Eu gostaria que houvesse algo assim dentro do editor. Também serviria para verificar se a escrita está previsível demais ou batida. Calcular perplexity também não é difícil, então bastaria integrar isso à UI do editor
  • Interessante. Muitas vezes sinto que não aproveitamos o suficiente os “frutos mais baixos” que surgiram desde o entusiasmo inicial com os LLMs. Isso é exatamente esse tipo de ideia
  • Acho uma ideia realmente fantástica
• Uns 10 anos atrás, Bret Victor disse que minimizar o atraso no feedback era um princípio de vida. Ele dizia que ciclos rápidos de iteração não só melhoram a programação, mas também contribuem para insights criativos. Ele criou vários programas de exemplo para mostrar alternativas, e o caso de HUD mencionado no post original é muito parecido com a demonstração dele de “voltar no tempo para entender o código”. Vídeo relacionado
• Gostei dessa ideia e fiquei pensando em como ela poderia ser aplicada à programação em geral. Imagine o seguinte: enquanto você escreve código, um LLM gera testes e a IDE executa esses testes em tempo real. A cada tecla digitada, de 10 a 100 testes rodam em <1ms, e os resultados são mostrados de forma discreta. Os testes aparecem em um painel separado ao lado do código, e se passaram ou falharam na última execução é indicado por pontos vermelhos/verdes. Só de ver quais testes existem ou não existem, e em que estado estão, já dá para entender o que o código está fazendo “por fora” enquanto você o escreve. Se parecer que falta um teste que o LLM não criou, isso pode ser sinal de que o prompt está errado ou de que o código não corresponde à intenção. Essa propriedade em tempo real ajuda muito a lapidar o código. Se você quiser fazer isso no estilo TDD tradicional, o usuário pode escrever os testes e o LLM escrever o código para fazê-los passar
  • É muito melhor quando a pessoa escreve os testes primeiro e o LLM gera o código. Isso porque os testes são a “verdade” e a “intenção” do código. Se você abre mão do controle sobre entradas e saídas, o desenvolvedor deixa de estar no banco do motorista
  • Em uma codebase séria em C++, isso é inviável. Só o tempo de compilação já torna a ideia impraticável, e também é difícil para o LLM adivinhar testes sem escrever o código inteiro. Por exemplo, se você está criando uma nova estrutura de dados, como o LLM saberia disso
  • Não é uma boa ideia deixar o LLM gerar testes enquanto você escreve código e fazer a IDE rodá-los toda vez. Testes são código que garante invariantes, então não é bom o LLM sair mexendo neles sem critério. Testes só deveriam mudar quando o usuário os altera explicitamente, e só eles. Com essas restrições, isso já vira um fluxo de trabalho comum. Tipo o modo watch dos frameworks de teste em JavaScript. Esse tipo de workflow os desenvolvedores já fazem há mais de 10 anos
  • Não seria preciso também testar se os testes foram escritos corretamente? Senão o LLM pode simplesmente fazer os testes passarem mesmo que estejam errados. Ou então pode escrever código só para enganar o sistema. No fim, a melhor configuração provavelmente seria um ambiente em que LLM e humano possam cruzar livremente as fronteiras entre suas áreas. Escrever só requisitos claros e deixar a IA cuidar da maior parte dos dois lados seria muito mais produtivo e streamlined
  • Rodar a suíte inteira de testes a cada entrada tem ROI muito baixo. A maioria das teclas digitadas produz um programa “incompleto”, então é preciso escolher com mais inteligência quando executar os testes para alcançar um equilíbrio razoável
• No fim, tudo se resume à pergunta: “qual é a interface ideal para humanos lidarem com informação digital?”. Estamos absorvendo cada vez mais informação todos os dias, e por causa da IA essa quantidade não vai diminuir, vai aumentar ainda mais. Se até informações complexas e especializadas, como logs de erro, puderem ser resumidas, abre-se um novo caminho para que pessoas que antes não tinham acesso consigam lidar com elas. Então como vamos administrar essa avalanche de informação de forma eficiente? Hoje temos todo tipo de interface, site, dashboard, e-mail e chat, mas não sei se ainda precisaremos de tudo isso daqui a 10 anos. Se eu puder receber todas as informações em uma única interface de chat, será que preciso mesmo entrar em sites? O fato de a IA agora também criar sites, apps e web UIs para nós já começa a parecer um pouco... redundante
  • Sites eram justamente o meio de receber informação “oficial” de lugares confiáveis, como uma empresa ou a Wikipédia. Essa confiabilidade era tão importante que investimos em “line of death”, ícone de cadeado, medidas anti-phishing e proteção contra ataques com caracteres homoglifos. Tudo partia da suposição de que aquele site trazia informação oficial e confiável. Num mundo em que todos dependem de LLMs sem senso crítico, fica realmente difícil entender o que é “confiança”. Mesmo que o LLM geralmente acerte, será que dá para confiar nele nos momentos realmente importantes?
  • Designers de caças de sexta geração estão batendo exatamente no mesmo problema. O cockpit é a interface entre a aeronave e o piloto, e seu papel está diminuindo cada vez mais. Na sétima geração, fica a dúvida se o humano ainda terá um papel valioso. (Ainda assim, ele pode continuar por questões de direito internacional ou gestão de riscos tipo Skynet.) Provavelmente as interfaces em todas as áreas vão evoluir desse jeito. A complexidade vai diminuir cada vez mais, e o humano só precisará explicar ao sistema o que quer em conceitos de alto nível. Não necessariamente em linguagem natural; se for preciso uma especificação precisa, pode ser uma interface adequada a isso
  • Como cada pessoa é diferente, não deveríamos generalizar a interface, e sim customizá-la dinamicamente na hora
  • É difícil dizer que o smartphone é realmente perfeito e que seu potencial já foi praticamente esgotado. Para mim ele ainda é o melhor formato
• Acho realmente útil a capacidade de a IA criar visualizações complexas em tempo real. Por exemplo, ao depurar um vazamento de memória em um caminho específico do código, a IA poderia visualizar as alocações/liberações de memória naquele caminho para ajudar a identificar o problema. Parece que está chegando uma era em que a própria IA vai criar ferramentas de visualização adequadas a problemas específicos. Uma palestra recente do Jonathan Blow na LambdaConf conversa diretamente com essa ideia. Ele mostrou ferramentas que visualizam programas de várias maneiras para encontrar problemas potenciais. Acho que a IA pode ser muito boa em criar esse tipo de ferramenta. Ver vídeo completo
• Quero ver imediatamente num HUD as mudanças ligadas aos itens de TODO do Claude Code. Não quero comentários inline, porque eles acabam se acumulando depois e o LLM não consegue organizar isso direito
• Um dos maiores motivos de HUDs ainda não terem se popularizado é a limitação dos meios de exibição usados hoje. Monitores e dispositivos móveis não são bons em fornecer informação periférica e não intrusiva. Quando um agente de IA está corrigindo bugs ou lidando com uma tarefa complexa, o tempo de espera pelo resultado fica num limbo. É curto demais para fazer outra coisa com calma, mas também é estranho ficar olhando fixamente para a tela. Com um HUD, daria para ter ciclos de feedback muito mais curtos. Você poderia acompanhar de canto de olho o que a IA está fazendo e intervir imediatamente, ou simplesmente continuar com outras coisas. O importante é poder escolher, em um estado de percepção ambiente, o nível de intervenção naquele momento, em vez de ficar preso entre os extremos de foco total ou abandono completo. Por isso acho que VR/AR pode ser o grande killer app do AI HUD. Graças à computação espacial, daria para receber ajuda da IA sem tirar os olhos da tela 2D. Esse tipo de abordagem também seria especialmente útil em tarefas físicas, como cozinhar ou consertar uma bicicleta
  • Eu já faço exatamente isso usando um monitor ultrawide junto com a tela do laptop. Enquanto fico imerso em um jogo ou em outro trabalho, deixo o Claude aberto em uma janela do tmux num canto e vou checando sempre que aparece o próximo passo ou alguma mudança importante
• Acho que uma interface de programação no estilo HUD é basicamente um AREPL. Serve bem para debugging, mas sinto que uma janela de chat ou um Q&A inline são muito mais versáteis. No geral concordo com a lógica de buscar interfaces alternativas ao chat, mas realisticamente o chat já é a interface dominante nos smartphones. Um HUD parece combinar melhor com um HUD de verdade, como óculos de AR
• Acho possível também ter um modelo de IA que funcione de forma autônoma por longos períodos em segundo plano e “empurre” informações quando necessário. Seria um sistema que detecta contexto de forma inteligente, filtra, resume e entrega o conteúdo, e ainda pode recomendar algo se preciso. Isso parece muito mais natural principalmente em ambientes de negócios onde é preciso monitorar vários clientes em 100 tipos de situação
  • Na verdade, a parte mais difícil é definir as situações e coletar os dados relevantes. O problema em si de um sistema autônomo fazer isso já foi resolvido tecnicamente há muito tempo
• Concordo com a afirmação de que, se vamos levar design para IA a sério, precisamos pensar em formas de expandir a mente humana que vão além de um simples copiloto. Na verdade, o auto-complete já faz esse papel. Você pode conversar com um LLM, mas também pode só dar comandos simples ou usar autocompletar. O que o autor parece querer enfatizar é que a IA precisa trabalhar ao nosso lado, olhando na mesma direção que nós. Não um copiloto tipo “humano virtual” sentado do outro lado da mesa discutindo, e sim um colaborador de verdade que faz imediatamente o que pedimos
  • Sou o autor. Exato, a UI de autocompletar do GitHub Copilot é, ironicamente, um ótimo exemplo de HUD. O tab completion se integra como se fosse parte do cérebro. Mas ultimamente o ambiente de programação está migrando para agentes de chat. Precisamos imaginar como seria uma UI de “tab completion” em um nível mais alto de abstração. Talvez isso se torne uma forma de projetar código realmente direta, sem ficar presa a detalhes incidentais