- O processo completo de desenvolvimento do recurso de notificação automática de atualização não intrusiva do Ghostty no macOS, feito principalmente com ferramentas de coding agentic com IA, foi divulgado publicamente; em 16 sessões, com custo de US$ 15,98 em tokens, um recurso realmente pronto para produção foi concluído em cerca de 8 horas
- O ponto de partida foi o incidente em que um prompt de atualização do Ghostty atrapalhou uma keynote da OpenAI, levando à decisão de adotar um modelo não modal que mostra o status de atualização em um pequeno elemento de GUI na barra de título ou na parte inferior da janela, sem interromper o trabalho
- Antes de começar com IA, foi definido um plano inicial de backend/frontend com base no protocolo de UI customizada do framework Sparkle e no controlador de acessórios da barra de título, usando a IA como ferramenta de prototipagem
- Foi usada uma abordagem em etapas com prototipagem de UI, mudança de direção quando a correção de bugs falhava e sessões repetidas de cleanup (documentação, refatoração), além de geração de código de simulação para melhorar o desempenho das futuras sessões com IA
- O texto destaca o valor de um modo de trabalho assíncrono, em que é possível fazer outras coisas, como preparar o café da manhã da família, enquanto a IA trabalha; todo código gerado por IA foi implantado apenas após revisão manual rigorosa, seguindo o princípio de nunca publicar código que não fosse totalmente compreendido
Visão geral do recurso
- O recurso concluído é a notificação de atualização não intrusiva no macOS
- Exibe o status da atualização dentro da janela do terminal sem atrapalhar o trabalho, como criar janelas ou roubar o foco
- A necessidade de melhorar a UX ficou clara após o incidente em que um prompt de atualização do Ghostty apareceu durante uma keynote da OpenAI
- Foi decidido tornar a notificação de atualização não invasiva
- Em vez de uma janela pop-up, a ideia passou a ser mostrar em algum lugar um pequeno elemento de GUI não modal que não interrompesse o usuário
- O local padrão da notificação seria a direita da barra de título, com alternativas como um overlay na parte inferior da janela dependendo do estilo, como quando a barra de título está oculta
- Ao longo de todo o desenvolvimento, foram usados agentes de IA, mas com uma estratégia de ferramenta auxiliar guiada por humanos, combinando ajustes manuais, polimento e revisão final
Planejamento antes de usar IA
- Antes mesmo de abrir a ferramenta de IA, foi feito primeiro um plano geral
- Pesquisa da documentação do Sparkle, o framework de atualização para macOS usado pelo Ghostty e muito popular
- Foi encontrado suporte a UI customizada via protocolo Obj-C; embora exigisse reimplementar muita coisa, era viável
- Depois de obter uma ideia geral do backend, veio a concepção do frontend
- Havia uma ideia vaga de embutir um pequeno botão na barra de título
- Já se sabia que o macOS oferece suporte a UI customizada na barra de título por meio do controlador de acessórios da barra de título, mas ainda não estava claro como isso deveria parecer e se comportar
- Com um ponto de partida suficiente, já era possível começar
- Como a IA é excelente para prototipagem, já bastava saber o que ainda não se sabia
- Havia uma noção forte o bastante do panorama geral
Primeira sessão: prototipagem de UI
- Prompt inicial da primeira sessão de coding agentic
- Customizar o
SPUUserDriver para notificações de atualização não invasivas e solicitação para ativar a instalação
- Restringir o trabalho apenas à UI
- Pedir um plano para criar uma view SwiftUI capaz de mostrar os vários estados exigidos pelo
SPUUserDriver
- Pedir um plano para exibição no canto superior direito da barra de título da janela do macOS
- Oracle? — um subagente somente leitura exclusivo do Amp, que usa um modelo mais lento e mais caro, geralmente melhor para raciocínio
- Foi decidido focar primeiro no protótipo da UI
- Não foi pedido ao agente para construir o recurso inteiro de uma vez
- Primeiro, porque ainda não se sabia qual deveria ser a aparência e a UX, então não dava para esperar de forma consistente que a IA resolvesse isso junto com outras mudanças
- Segundo, porque blocos menores de trabalho são mais fáceis de revisar, entender e iterar
- Foi pedido que o agente escrevesse apenas o plano, sem gerar código
- Como a solicitação era relativamente ambígua, era importante revisar o plano antes de fazer muito trabalho — e gastar muitos tokens
- Dica: construir um plano abrangente de forma interativa com o agente é um primeiro passo importante em tarefas não triviais
- Em geral, isso pode ser salvo em um arquivo como
spec.md, e em sessões futuras basta pedir algo como “consulte @spec.md e execute determinada tarefa”
- O agente apresentou um plano considerado suficientemente aceitável, e a implementação pôde avançar
- A UI gerada tinha uma direção muito boa
- Havia muitos problemas de polimento, como espaçamento e cores, mas ver a UI trouxe uma faísca de inspiração sobre o que se queria
- Dica: a IA é usada com muita frequência para buscar inspiração; neste caso, boa parte do código de UI gerado foi mantida, mas também é muito comum dar um prompt ao agente, descartar tudo e refazer manualmente
- A etapa criativa do “zero ao um” é muito difícil e consome muito tempo, e a IA funciona muito bem como musa
Batendo em uma parede
- Entre os chats 11 e 14, entrou-se na slop zone
- O código gerado pelo agente tinha bugs graves, e ele falhou completamente em corrigi-los
- Nem eu sabia como corrigir
- Foram feitas algumas tentativas de último recurso para corrigir os bugs
- Se o agente resolvesse, daria para estudar e aprender
- Se falhasse, o custo seria praticamente zero
- Se o agente resolvesse, mas o resultado não fosse compreendido, seria revertido; código que não se entende não é publicado
- Enquanto as tentativas falhavam, eu alternava de aba para pesquisar o problema e tentar resolvê-lo por conta própria
- Nesse ponto, ficou claro que era preciso recuar, revisar o que havia sido feito e montar um plano próprio
- Era hora de estudar por conta própria e pensar criticamente
- A IA já não era mais uma solução, e sim uma dívida
Sessões de cleanup
- As sessões seguintes foram gastas orientando o agente a organizar o código
- Segunda sessão: mover alguns métodos para um lugar melhor
- As funções de preenchimento de plano de fundo, primeiro plano e badge foram movidas de UpdateAccessoryView.swift para UpdateViewModel.swift e generalizadas
- Terceira sessão: adicionar documentação ao código
- Atualização da documentação de UpdateBadge.swift
- Dica: adicionar documentação ajuda a reconfirmar a própria compreensão do código e a treinar futuros agentes que venham a ler e modificar esse código
- Os agentes têm desempenho muito melhor quando dispõem tanto de explicações em linguagem natural quanto do código
- Quarta sessão: mover o view model para um local global do app
- O trabalho original o havia colocado no escopo da janela, mas as informações de atualização pertencem ao escopo do app
- Durante esse processo, também foram feitas pequenas alterações manuais, como de costume
- Importância da etapa de cleanup
- Para organizar o código de forma eficaz, é preciso ter uma compreensão razoavelmente boa dele, o que força a não aceitar cegamente o código escrito pela IA
- Código mais bem estruturado e documentado ajuda a melhorar o desempenho de futuras sessões agentic
- Isso foi apelidado em tom de brincadeira de “sessões anti-slop”
Diante dos bugs
- Hora de voltar ao bug encontrado na sessão inicial
- Foram necessárias mais algumas sessões para fazer o agente entender isso
- Comecei de forma ambígua e fui tornando a abordagem cada vez mais específica
- Primeira sessão ambígua: no caso das abas nativas padrão, a view acessória de atualização não aparece; ela deveria continuar visível na barra de título da janela — falhou
- Segunda mais específica: atualizar as constraints da barra de abas em TerminalTabsTitlebarTahoe.swift para alinhar a borda direita da barra de abas à borda esquerda da view acessória de atualização — falhou
- Terceira tentativa de outra abordagem específica: e se eu alterasse TitlebarTabsTahoeTerminalWindow.swift para fazer a barra de abas virar uma view acessória superior em vez de uma view acessória inferior, colocando assim as abas na barra de título — falhou
- Última tentativa: a view acessória da direita e o layout entram em conflito com a configuração da view acessória de atualização em TerminalWindow.swift; dá para restringir a barra de abas para que ela sempre apareça à esquerda da notificação de atualização? — falhou
- Durante todo esse processo, também tentei resolver por conta própria com pesquisa manual e esforço humano
- Os prompts mais específicos se basearam no que aprendi nesse processo
- No geral, claramente não estava funcionando
- Concluí que não conseguiria resolver sozinho e decidi mudar de direção
- Para o estilo problemático da barra de título, colocar a notificação de atualização no canto inferior direito, sobreposta acima da view de conteúdo da janela em vez da barra de título
- O Ghostty tem uma configuração para ocultar totalmente a barra de título, então de qualquer forma isso precisava ser suportado
- Mesmo que depois fosse possível resolver o problema do estilo da barra de título, esse outro modo ainda precisaria ser suportado
- A sessão seguinte seguiu esse plano usando um prompt bem específico
- Reforçar o sistema de Update para também suportar a abordagem de overlay em TerminalView.swift
- A notificação de atualização deve aparecer na parte inferior da janela e sobre o texto, sem redimensionar a view do terminal
- Todo o comportamento de clique igual ao da view acessória
- Fez isso muito bem; depois tive bastante trabalho manual de polimento (mover, renomear etc.), mas o essencial ficou sólido
Início do backend
- Senti que a UI já estava boa o suficiente
- Anotei vários problemas de polimento para tratar depois, mas queria ir para o trabalho de backend principalmente para descobrir incógnitas desconhecidas que poderiam atrapalhar o plano
- Criei manualmente um arquivo scaffold com funções incompletas e vários comentários
TODO. Iniciei uma nova sessão
- Pedi para completar UpdateDriver.swift e ler a documentação do Sparkle para entender a funcionalidade
- Dica: a IA é muito boa em preencher lacunas ou terminar de desenhar o resto da coruja
- Esse padrão de criar scaffolding com nomes de função descritivos, parâmetros, comentários todo etc. é muito comum e funciona bem
- Na prática, fez um trabalho muito ruim e joguei todo esse código fora
- O código gerado funcionava, mas era claramente a abordagem errada
- Misturava muitas preocupações diferentes, e a forma como armazenava estado no driver era obviamente errada
- Ao estudar o que tinha feito, percebi que os view models estavam estruturados de uma forma nada ideal
- Para dar à IA (e a um humano, caso eu optasse por escrever manualmente) um framework melhor, mudei para modo de limpeza
Grande reorganização
- Pela minha experiência, a limpeza do frontend da UI e do backend da lógica de negócio costuma ser determinada pela qualidade dos view models no meio
- Gastei tempo reestruturando manualmente os view models
- Troquei structs cheias de opcionais por tagged unions, além de renomear e mover alguns tipos
- Pela experiência, eu sabia que esse pequeno trabalho manual no meio ajudaria o agente a ter sucesso nas sessões futuras, tanto de frontend quanto de backend
- Depois de concluir a reestruturação, a primeira coisa que fiz foi pedir ao agente mais uma vez para terminar de desenhar a coruja
- Desta vez, revisar as mudanças, atualizar o código dependente para o novo estilo e remover o código antigo
- Continuei uma série de sessões maratona de limpeza
Simulação
- Na primeira sessão de UI, pedi ao agente que gerasse código de demonstração para que eu pudesse realmente ver a UI sem fazer uma checagem de atualização de verdade
- O fluxo de atualização tem vários cenários, e até esse ponto eu só tinha testado o happy path
- Na sessão seguinte, extraí o código de simulação para um arquivo dedicado e pedi ao agente para gerar mais cenários
- Extrair o código de simulação de atualização de AppDelegate.swift para um arquivo dedicado em Features/Update
- Incluir vários cenários de simulação (happy path, não encontrado, erro etc.) para poder testar facilmente demos variadas
- Dica: o agente é excelente para gerar testes e simulações
- O código de simulação gerado aqui, sinceramente, ficou bem horrível, mas funciona e não faz parte do binário de release, então a qualidade não importa
- Nem cheguei a limpar além do básico visível na sessão
- Executei várias simulações e encontrei diversas melhorias de UX
Reta final
- Nesse ponto, eu tinha backend e frontend funcionando, e só precisava conectar tudo
- Na sessão seguinte, dei o seguinte prompt ao agente
- Criar uma classe UpdateController para o tipo de updater, equivalente ao SPUStandardUpdaterController.m do Sparkle
- Foi preciso um pouco de ida e volta e polimento manual, mas cheguei lá
- Depois adicionei pequenas melhorias
- Para o estado atualizável com appcast, olhar para SUAppcastItem e mostrar outros metadados relevantes, se definidos
- Por exemplo, content length para tamanho
Mais alguma coisa?
- Para o agente, o último prompt é sempre perguntar o que ficou faltando
- Fazer isso independentemente de eu ter escrito o código manualmente ou não
- Há outras melhorias que podem ser feitas na funcionalidade Features/Update, não escrever código, consultoria estilo Oracle, considerar quais partes do código poderiam receber mais testes unitários
- Como destaquei o problema real, pedi para implementar
- Descobri que é mais fácil dizer ao agente para “fazer tudo” do que perguntar por itens específicos a executar, já que depois dá para organizar isso facilmente em commits opcionais
- O ponto engraçado desta sessão foi que o agente realmente começou a entrar numa toca de coelho maluca, então intervim para mandar parar
- “para para para. Cancelar todos os itens dos atores principais”
- Também percebi que havia uma forma melhor de fazer algo que foi executado de maneira meio ruim
- No caso das mensagens de erro, será que não existe uma forma padrão do SwiftUI em vez de truncar, com necessidade de adicionar um elemento extra de UI para ver a mensagem completa
Custos e tempo
- O trabalho totalizou 16 sessões separadas no Amp, com US$ 15,98 gastos em tokens
- Não vou especular se isso é caro ou barato em geral, mas pessoalmente gastei mais do que isso no café durante os 2 dias que dediquei a esse recurso
- Estimo que o tempo real total gasto nesse recurso foi de cerca de 8 horas
- O primeiro e o último commit se estendem por 3 dias, mas trabalhei no computador só cerca de 4 horas por dia
- Nem todo esse tempo foi dedicado apenas a esse recurso
- Por exemplo, durante esse período também fiz o lançamento da atualização do Ghostty, participei por 1 hora como convidado do ThePrimeagen e dei uma apresentação como convidado no evento anual geral da Zoo
- Tenho uma criança pequena em casa, então meu “tempo de computador” é muito programado e bem limitado
- Portanto, a estimativa de 8 horas é até generosa
- Muita gente na internet debate se a IA permite trabalhar mais rápido
- Neste caso, acho que entreguei mais rápido do que teria feito se tivesse feito tudo sozinho
- Especialmente porque iterações triviais de estilização em SwiftUI são pessoalmente tediosas demais e consomem muito tempo, e a IA faz isso muito bem
- Mais do que o debate de mais rápido/mais lento, o que eu mais gosto: a IA pode trabalhar por mim enquanto vou fazer outra coisa
- Tirei uma foto de uma das sessões de limpeza enquanto preparava o café da manhã para a família
- Existem todo tipo de críticas do tipo “não quero programar enquanto cozinho” ou “esteja mais presente”
- Tudo bem se você quiser fazer assim; no meu caso, neste exemplo específico, eu era a primeira pessoa a acordar em casa e estava preparando o café da manhã enquanto todo o resto ainda dormia
- Não faço isso em todos os momentos em que estou acordado
- Conclusão: funciona para mim
- Não estou tentando convencer ninguém
- Não tenho nenhuma ligação financeira com qualquer empresa de IA
- Como alguém que tem tido muito sucesso com ferramentas de IA e gosta de falar sobre isso, as pessoas sempre pedem que eu compartilhe exemplos
- É isso que estou fazendo aqui
Conclusão
- O recurso ficou bonito, funciona muito bem e foi mesclado após a revisão manual final
- A “revisão manual final” é muito, muito, muito importante; não publique código escrito por IA sem uma revisão manual minuciosa
- Se você é usuário do Ghostty e usa releases tip, isso já está disponível agora
- Se você usa releases com tag, isso estará disponível no Ghostty 1.3
- Sou um defensor declarado da importância de compartilhar publicamente sessões de codificação agêntica
- Um dos motivos é que isso é uma forma incrivelmente poderosa de educar outras pessoas sobre como usar essas ferramentas com eficácia
- Espero que este post ajude a mostrar isso
2 comentários
Opiniões do Hacker News
Costumo usar IA como ferramenta de inspiração com frequência; desta vez também mantive bastante código de UI gerado por IA, mas às vezes mando o agente fazer algo, jogo tudo fora e reescrevo eu mesmo (manualmente!). A etapa criativa de “zero a um” é sempre muito difícil e consome muito tempo, então a IA funciona excepcionalmente bem como minha musa. Essa é justamente a maior vantagem dos agentes de código. Muita gente se preocupa com manutenção ou bagunça em projetos centrados em IA, mas eu não ligo. Se eu conseguir chegar rapidamente a um ponto em que já dê para mexer de verdade na funcionalidade do projeto e continuar refinando, depois disso tudo realmente acelera. Até esse “momento de ouro” estão, para mim, os 80% mais caros da programação. Por isso, sinceramente, não entendo muito as opiniões contrárias aos agentes de código. Mesmo que no fim só reste código completamente descartável, ainda assim sinto que isso tem um valor óbvio. PS. Bacon deve sempre ser pesado
Conversei com alguém sobre esse tema recentemente e, no geral, concordo também. Essas ferramentas são excelentes por permitirem criar com facilidade protótipos com os quais você pode interagir diretamente para testar ideias. Mas há dois problemas. Primeiro, já é um incômodo convencer alguém de que um protótipo que parece quase pronto na superfície ainda está longe de estar pronto para produção, e código baseado em LLM está ainda mais longe de produção do que os protótipos que eu fazia do jeito antigo. Segundo, os protótipos que eu fazia à mão me ensinavam algo diretamente sobre a stack técnica e a implementação. O objetivo principal era fazer algo rápido, mas no processo eu aprendia muitas lições técnicas, e com frequência meus protótipos acabavam influenciando até a direção técnica. Já os protótipos baseados em LLM têm um código em si quase inútil, e se algo realmente começar, quase sempre é preciso recomeçar praticamente do zero. Eu validei a ideia, mas sinto que não validei nem a tecnologia nem o design. Ainda assim, continuo achando útil. Eu sigo a crença de que “protótipos devem ser rápidos”, e com LLM consegui montar sistemas bem grandes quase imediatamente. Só que isso exige uma mudança no conceito de processo. Um protótipo sem LLM corresponde talvez à etapa 4 ou 5 de 10, enquanto um protótipo com LLM está mais perto da etapa 2. Isso não é ruim, mas é preciso ajustar as expectativas quanto ao volume de trabalho que sobra depois do protótipo, porque ele é maior do que antes
O valor que você dá a “colocar o projeto num ponto em que já dá para sair correndo com ele” é importante. Para mim, ao contrário, a etapa “zero a um” é a mais gratificante e divertida. É quando existe realmente muito que pode ser feito e quando dá para criar algo que não existia antes. Se a IA já define a direção antes, sinto que se perde bastante dessa criatividade
Pela sua opinião, parece que o medo da página em branco é uma preocupação grande. Concordo que uma ferramenta que elimina isso contribui muito para a produtividade. Mas nem todo mundo tem essa mesma dificuldade. Desenvolvimento de software é uma atividade muito pessoal, então o workflow e a experiência de cada um podem ser diferentes. Não é que o jeito de alguém seja melhor que o de outro; o importante é que as ferramentas adequadas são diferentes para cada pessoa, e é preciso reconhecer e confiar na experiência de cada um como ela é. Nas controvérsias sobre LLM, os dois lados tendem a presumir que eles e os outros são iguais
Vi esta semana uma entrevista sobre o setup de desenvolvimento do Mitchell, e me marcou quando, ao perguntarem por que ele usa neovim, ele respondeu: “eu não quero ferramentas que escrevam código no meu lugar”. Não estou criticando, mas vale notar que até um desenvolvedor excelente como o Mitchell vê valor em LLMs, diferentemente do intellisense de antigamente
Eu explico isso aos colegas como “usar a Lei de Cunningham em mim mesmo” Cunningham's Law: 'a melhor maneira de obter a resposta certa na internet não é fazer uma pergunta, e sim postar a resposta errada'. Se eu fico olhando para uma tela em branco sem pensar em nada, passo um tempão travado; mas se surge algo para criticar, eu imediatamente me torno produtivo
Eu realmente respeito a opinião do Mitchell em resposta ao incidente da OpenAI, mesmo sendo algo positivo para o ghostty. Quase nunca vejo empresas de software tentando reduzir ativamente a frustração ou irritação dos usuários — especialmente se pensar em coisas como o MS Auto Update —, então isso é uma mudança muito bem-vinda. E este texto mostra um uso responsável da IA na programação; acho que não se encaixa em nada na definição original de vibe coding, que vinha sendo citada de forma exagerada
Acho que a própria expressão “vibe coding” não combina em nada com este caso. Esse termo está sendo usado em excesso e jogado para todo lado
Concordo com a opinião sobre “usar IA de forma responsável na programação”. Isso não é vibe coding, e sim vibe engineering, conceito que simonw apresentou aqui primeiro. Post relacionado
Só para constar, o Ghostty recentemente tornou obrigatória a divulgação do uso de ferramentas de IA para programação link do PR relacionado
Este texto mostra por que agentes de IA são especialmente fortes em trabalho com frameworks de UI. Eu também desenvolvo apps com Rust e GTK, e o workflow é muito parecido. Não é que eu não saiba como implementar algo; é que a IA ajuda muito porque faz a maior parte da busca repetitiva, entediante, e da tentativa e erro no trabalho com frameworks de UI. O Mitchell entende o código inteiro durante todo o processo. Como ele já sabe o que precisa fazer, isso é completamente diferente do que chamam de “vibe coding”. Não existe atalho separado para se tornar especialista. Gosto muito do Ghostty
Graças aos LLMs, programar ficou divertido de novo. No trabalho, os LLMs ajudam com a parte mais difícil do começo, então consigo entrar em ação rapidamente. Também são muito úteis para entender uma codebase nova ou escrever as partes chatas. Mas a diversão de verdade começa nos projetos paralelos. Agora dá para implementar ideias impulsivas muito rápido. Não preciso mais gastar horas escrevendo boilerplate ou brigando com tooling. As partes com que não tenho familiaridade eu delego ao agente, ou extraio uma funcionalidade inteira com um prompt de uma vez só e, se não gostar do resultado, simplesmente reverto
Pergunta meio fora do tópico, mas por que quase todos os apps ainda precisam ter seu próprio framework de atualização? Não daria para integrar isso à App Store ou a um gerenciador de pacotes?
No ecossistema macOS, isso tende a ser bem difícil
Por exemplo, no Ubuntu isso é bastante conveniente. Se você baixar e instalar manualmente a versão mais recente, depois disso continua recebendo atualizações automáticas
No fim, justamente a parte em que você reconhece não ser muito bom — isto é, a etapa de zero a um — se torna uma área que você nunca poderá aprender de fato por conta própria se a delegar à IA. Se quiser continuar capaz de fazer isso você mesmo no futuro, precisa praticar isso deliberadamente
O Ghostty era realmente muito bom, e eu quase abandonei o iTerm, mas apertei cmd-f e nada aconteceu, então desisti página de issues e feedback
Se cmd-f existisse desde o começo, fico curioso sobre que tipo de conversa teria acontecido nos posts sobre o ghostty. Está ficando até um pouco cansativo ouvir isso em todo post. Na verdade, poderia haver discussões muito mais interessantes sobre ferramentas de LLM ou formas de programar, mas no fim todo mundo acaba falando de cmd-f
Curiosamente, eu usei o Claude no fim de semana passado para implementar busca no Ghostty. Já havia um código meio improvisado em que a busca realmente funcionava, então a maior parte do trabalho foi conectar isso à UI. Em duas sessões (cerca de 10 horas no total), consegui fazer busca básica, destaque e navegação para correspondência anterior/próxima funcionarem no frontend Linux. Essa funcionalidade de busca ainda está claramente em WIP, então não está pronta para uso geral. Trabalhando nisso, percebi o quão complexo é fazer até uma funcionalidade que parece “básica” funcionar com texto em streaming
Eu também achei o Ghostty minimalista demais e, infelizmente, voltei rápido para o Warp. Só para referência, o buffer padrão de scrollback do Ghostty é de cerca de 10MB, mas isso pode ser ajustado à vontade nas configurações
Essa funcionalidade de busca está prevista para março de 2026 como meta da v1.3 link do roadmap
Ao ver o trecho do artigo dizendo “vamos examinar o que motivou a adição deste recurso”, voltei a pensar em quanto desconforto a gente tolera nos sistemas operacionais. Apresentações e compartilhamento de tela já são algo corriqueiro há décadas, então por que ainda é tão difícil até mesmo uma configuração básica para forçar que só a janela da apresentação apareça na tela?
É o Ghostty, ferramenta à qual Mitchell Hashimoto, cofundador da HashiCorp, tem dedicado quase todo o seu tempo ultimamente.
Lançamento do Ghostty 1.0 - emulador de terminal rápido e multiplataforma
O libghostty está chegando
Ele defende a codificação agêntica e diz que o compartilhamento de sessão é realmente importante,
mas a maioria dos links aponta para sessões do AMP Amp - ferramenta de codificação agêntica