Criar uma UI de terminal agora ficou mais fácil

• Apresenta o caso da equipe da Hatchet, que desenvolveu rapidamente uma UI baseada em terminal (TUI) usando Claude Code
• Com a stack Charm (Bubble Tea, Lip Gloss, Huh), implementaram um desenvolvimento baseado em componentes no nível do React e um estilo consistente
• Mesmo usando a mesma API da UI web existente, aumentaram a eficiência dos desenvolvedores com uma interface centrada em texto e densa em informação
• O Claude Code executou sessões do tmux e automatizou os testes, desempenhando um papel importante no desenvolvimento iterativo e na garantia de estabilidade
• Concluída em apenas 2 dias, a TUI da Hatchet é avaliada como um caso que mostra uma melhoria prática de produtividade com desenvolvimento baseado em LLM

---

Motivação para desenvolver a TUI

• A equipe da Hatchet queria uma TUI semelhante ao k9s, e os usuários a avaliaram como mais rápida e intuitiva do que a UI web
  • Entre os feedbacks dos usuários, houve a opinião de que “a CLI e a TUI têm desempenho muito melhor”
• A TUI permite visualizar e executar fluxos de trabalho no mesmo ambiente do código, eliminando a necessidade de trocar de abas
• Como os principais usuários da Hatchet são desenvolvedores que trabalham dentro do IDE, o objetivo era oferecer uma experiência de gerenciamento de workflow dentro do terminal

Stack tecnológica

• Foi usada a stack Charm, equivalente a uma stack de frontend comum (React, Tailwind etc.)
  • Bibliotecas principais: Bubble Tea, Lip Gloss, Huh
  • Mantidas pela equipe da Charm, com documentação e exemplos abundantes
• Com Lip Gloss e os temas do Huh, foi aplicado um estilo consistente em toda a TUI
  • O mesmo tema também foi reutilizado nos comandos da Hatchet CLI para oferecer uma experiência de usuário unificada
• Configurações personalizadas fora do Bubble Tea são um pouco mais difíceis, mas ainda são muito mais simples do que implementar diretamente um motor de renderização baseado em React

Abordagem de testes

• O Claude Code executou diretamente as ferramentas baseadas em terminal para realizar os testes
  • Usou tmux capture-pane para capturar a view renderizada e verificar se a saída estava correta
• Essa abordagem foi muito eficaz para automatizar a primeira etapa dos testes, e permitiu verificar a renderização com estabilidade mesmo à medida que o número de views aumentava
• Depois, testes manuais e testes unitários foram combinados para formar um loop de desenvolvimento iterativo estável
• Como o Claude Code é otimizado para tarefas repetitivas em ambientes ASCII, o loop de feedback dos testes convergiu rapidamente

Montagem de um ambiente de desenvolvimento eficiente

• O Claude Code aumentou a eficiência do desenvolvimento ao consultar a implementação de frontend existente da Hatchet
  • Com uma estrutura simples de componentes baseada em React e a especificação OpenAPI, foi possível definir limites claros
  • Com um cliente de API REST gerado automaticamente, tornou-se possível um desenvolvimento orientado por especificação
• A implementação do renderizador baseado em DAG foi a parte mais difícil, porém
  • Com referência ao mermaid-ascii, conseguiram implementar com sucesso um renderizador de grafos ASCII
  • Embora não seja perfeito, foi possível garantir uma funcionalidade utilizável de visualização de DAG

Resultados e lições

• O período total de desenvolvimento foi de cerca de 2 dias, muito mais rápido e estável do que uma refatoração anterior do frontend
• O desenvolvimento com Claude Code foi avaliado como o primeiro caso a mostrar uma melhoria de produtividade real e não aleatória
• A equipe da Hatchet planeja expandir gradualmente, no futuro, o desenvolvimento baseado em LLM para funcionalidades fora do caminho crítico
• As principais lições são a importância de loops curtos de feedback, modularização, design orientado por especificação e testes contínuos
• A TUI concluída da Hatchet está disponível em https://tui.hatchet.run, e a equipe está coletando feedback dos usuários

[GN⁺]

Comentários do Hacker News

• Há uma ironia em uma página da web falar sobre desempenho de UI de terminal e, ao mesmo tempo, engasgar na rolagem até no meu Dell XPS de alto desempenho por causa de efeitos complexos como composição de máscara em CSS e gradientes cúbicos
  Segundo o Gemini, isso é um “Scrim ou Easing Gradient” e, em vez de criar um fade suave com 16 paradas de cor, acaba recalculando as cores de milhões de pixels a cada rolagem
  No Firefox, a maioria das páginas rola suavemente, então recomendo testar também em notebooks hiDPI com iGPU, não só em Macs
  Aliás, há também uma imagem com o gradiente desativado — link

  • Verdade. Vou primeiro avaliar remover esse efeito para melhorar o desempenho, ou simplesmente eliminá-lo. Obrigado pelo feedback
  • Dizer que está em “nível Commodore 64” é exagero. O C64 na verdade tinha rolagem suave
  • Compartilham uma forma de ler no Firefox ou em outros navegadores sem CSS nem JS. Apresentam um script simples que extrai o HTML com busybox ssl_client e grep e o abre no Firefox
  • Chamou atenção quantas vezes Claude Code foi citado no post do blog
  • Não culpem meu Commodore 64. Depois que o programa carrega, ele roda muito suavemente a 50~60Hz

• Acho meio triste essa tentativa de fazer TUI parecer GUI. A acessibilidade é pior, a estrutura fica achatada, e o usuário não consegue usar fora do caminho previsto. Já a GUI moderna é estruturalmente integrada ao sistema operacional e muito mais livre

  • Não concordo. Em alguns domínios de problema, TUI é muito mais adequada. Por exemplo, caixas de diálogo de configuração de pacotes Debian são bem mais confortáveis do que texto simples, e funcionam bem também em SSH ou console serial. Também é útil em casos que exigem informação visual, como ferramentas que mostram gráficos de CPU
  • Eu uso TUI porque gosto de não precisar instalar mais um app Electron. É leve e desperdiça menos recursos por não embutir um navegador
  • Sinto que as restrições da TUI até aumentam o foco do designer de UI. Hoje em dia muitos apps escondem menus e ficam incômodos; TUI é mais clara
  • Gosto de ter tudo rodando dentro do terminal. Meu fluxo de trabalho gira em torno de multiplexadores como tmux, então quando uma janela separada abre, quebra meu ritmo. As limitações acabam trazendo simplicidade e consistência
  • Exemplos como Emacs, Vim, mc, htop e mutt mostram que TUI pode ser poderosa o bastante. Nem toda UI precisa ficar aberta

• Hoje em dia, desenvolver TUI ficou muito mais fácil. Isso graças a frameworks como BubbleTea, Textualize e Ratatui.
  Com os LLMs, ficou possível criar esse tipo de ferramenta rapidamente, e eu mantenho a biblioteca de gráficos TUI NTCharts
  Resolvi bugs graças ao entendimento espacial do Gemini e, no momento, estou criando um visualizador local de conversas com LLM em BubbleTea
  Links relacionados: issue do NTCharts, projeto thinkt

• Não consigo entender essa obsessão por TUI em apps de LLM. Olhando o Copilot do VS2026, a GUI mostra muito mais informação com muito mais rapidez. Dá para clicar no diff em tempo real e verificar tudo com eficiência

  • Eu uso VSCode, e desde que ficou possível abrir a barra lateral do agente de IA em uma janela separada, passei a achar isso bem mais confortável que Claude Code. A densidade e a precisão da informação visual são muito maiores do que em TUI
  • O motivo é simples. TUI é a forma mais simples de colocar uma UI rápida em cima do sistema de arquivos. Para fazer isso com tecnologias web, é preciso navegador e servidor
  • As funções do Claude Code são boas, mas acho a UI de pré-visualização de diff com IA do VSCode muito melhor. Só que a nova versão integrada ainda tem muitos bugs
  • Na verdade isso parece meio que um LARP (roleplay). É só um gesto simbólico para parecer um “hacker de verdade”, mas na prática é um app web feito com React/CSS

• Na era em que LLMs consomem os recursos de computação, isso acabou virando um estímulo para criar ferramentas com stack leve.
  Escrevi em C, aumentei o desempenho da CPU em milhares de vezes e reduzi a RAM pela metade. TUI é um bom exemplo dessa eficiência

  • Mesmo assim, uma GUI nativa ou frameworks como Flutter podem ter desempenho melhor do que TUI
  • Fico em dúvida sobre quanto da energia usada para treinar LLMs pode realmente ser compensada por otimização
  • TUI também é boa para reduzir dependências. Antes eu precisava de 100 pacotes npm; agora, 200 linhas de JS bastam

• Acho que o Midnight Commander (mc) continua sendo uma das melhores TUIs. Oferece quase os mesmos recursos da versão GUI (Double Commander) e ainda pode ser executado remotamente.
  Neste momento estou trabalhando em um novo skin e espero que ele entre na próxima versão

  • Pessoalmente, sinto que Far Manager ou Dos Navigator são mais estáveis
  • Agradecimentos aos desenvolvedores do mc

• O Gemini criou uma TUI para o meu projeto de scraper DHT — imagem
  A primeira versão precisou de ajustes por causa de problemas com caracteres CJK, mas no geral foi impressionante. Graças a isso, pude focar no algoritmo

  • Fiquei curioso para saber qual biblioteca foi usada
  • Tenho interesse em projetos relacionados a DHT. Queria entender como isso é usado em mecanismos de busca e afins
  • Confirmam se “DHT” significa Distributed Hash Table. Avaliam que é uma TUI legal

• Não vejo muito bem em que a TUI é melhor que formulários web ou GUI. Em compensação, acho composição de pipelines CLI muito poderosa

  • Algumas instituições (NSA, CSE, GCHQ etc.) proíbem UI web de administração por motivos de segurança. Por isso nosso produto é administrado por TUI baseada em console local ou SSH. Usamos configurações de SELinux MAC extremamente restritivas
  • TUI é prática para apps que podem rodar lado a lado com a CLI. É fácil dividir janelas com tmux/zellij, e há menos diferença de UI entre sistemas operacionais
  • TUI é especialmente útil em ambientes SSH. Funciona bem até em clientes SSH de smartphone
  • O Gemini criou uma TUI para meu projeto em C#, mas depois sugeriu que embutir o servidor web Kestrel seria melhor. E estava certo
  • TUI oferece bons atalhos de teclado e pode ser acessada diretamente do lugar onde o comando é executado, então serve bem para tarefas rápidas

• Gosto do Claude Code, mas sinto que a estrutura de TUI baseada em React é realmente muito ineficiente

  • Principalmente ao rolar textos longos, a queda de desempenho é severa. Parece que a arquitetura é assim desde o início, e fico curioso sobre por que é tão difícil corrigir isso
  • Se a renderização já está sendo feita em JS, talvez faça sentido usar o React como um motor de reaproveitamento

• Criei meu próprio frontend de prompts com base no Cursor CLI — imagem
  Integrei git, diff e histórico de chat, e também consigo acessar facilmente pelo celular via Tailscale.
  Ele reconhece minhas regras e consegue fazer grep no projeto, então a usabilidade é muito alta