A emacsificação do software
(sockpuppet.org)- Graças aos agentes de IA, agora é possível criar apps nativos pessoais em poucas horas, fazendo o software migrar para um território de personalização no estilo do Emacs
- O MDV.app é um visualizador de Markdown para macOS, no qual busca, indexação SQLite FTS, favoritos, sumário e memória de posição foram implementados em poucas horas
- O problema de cada app Electron carregar sua própria cópia do Chromium e a dificuldade de desenvolver UI nativa eram grandes, mas o Claude lida com SwiftUI com muita competência
- Como na cultura do Emacs, estão surgindo mais ferramentas ultrarr específicas para resolver incômodos individuais, e ideias, observações e prompts passam a valer mais do que produtos acabados
- A programação com agentes facilita adicionar uma boa UI para uso a side projects e ferramentas de terminal, transformando a criação de UI nativa em algo divertido
Por que criei meu próprio visualizador de Markdown
- No desenvolvimento de software, Markdown já era uma língua franca antes dos LLMs, e com a volta do crescimento das ferramentas TUI após os agentes, a experiência de continuar rolando Markdown no terminal para ler ficou ainda mais difícil de tolerar
- Entre os visualizadores TUI de Markdown há o glow da Charm e o Markless criado por Josh; o Markless também suporta navegação por sumário, mas o terminal em geral usa fonte monoespaçada, o que cansa em leituras longas
- No macOS há editores gráficos de Markdown como Obsidian, Typora e Bear, que são bons para leitura, mas todos são editores, então no momento em que se abre um arquivo
.md, o ambiente de edição e o arranjo de janelas existentes acabam sendo perturbados - Os visualizadores de Markdown da App Store parecem promissores à primeira vista, mas no uso real revelam problemas como ausência de busca, compras dentro do app ou incapacidade de copiar para a área de transferência o texto selecionado
- Em 2026, em vez de continuar procurando um visualizador aceitável, a direção mudou para a ideia de gerar com um agente de IA o visualizador de Markdown desejado
O MDV.app feito com Claude
- O MDV.app foi criado em poucas horas, chegando a um nível melhor do que os visualizadores de Markdown dedicados encontrados na App Store, e o tempo real de interação foi de cerca de 30 minutos
- Xcode e git foram configurados em um MacBook antigo, o ambiente do Claude foi preparado, e a preparação prévia para buscar ajuda com Swift e design para macOS já vinha sendo feita há algumas semanas
- O MDV não é o melhor aplicativo de macOS nem um software especialmente extraordinário, mas como visualizador dedicado de Markdown para macOS é suficientemente melhor e melhora bastante a qualidade de vida
- Os principais recursos do MDV são seleção e cópia de texto em documentos, busca por string fixa, indexação SQLite FTS de todos os arquivos Markdown em um histórico editável, favoritos com atalhos e navegação por sumário
- Ao alternar entre documentos, ele lembra a posição e continua dali mesmo após reiniciar; também oferece temas de cor e tipografia confortável para leitura, de modo que ao clicar em um arquivo
.mdo ambiente de leitura desejado se abre imediatamente
Os limites do Electron e a mudança na UI nativa
- Sempre que chega uma mensagem no Signal, a tela pisca, e isso não para até que o app do Signal seja explicitamente ocultado, com esse piscar sutil chegando perto de provocar enxaqueca
- Esse fenômeno acontece porque o Signal é um app Electron; por fora ele parece um app nativo de macOS, mas na prática sua estrutura é uma cópia do Chromium renderizando uma página web secreta
- Quase todo app de UI lançado na última década parece carregar sua própria cópia do Chromium, e o Electron, embora não seja bom, conseguiu se sustentar como uma opção boa o suficiente
- Criar uma UI realmente nativa sempre foi historicamente difícil, e era complicado até encontrar profissionais medianos para assumir esse trabalho; desenvolvedores realmente competentes de UI nativa para macOS eram raros
- O Claude vai além de substituir um desenvolvedor mediano de SwiftUI; ele é visto, de fato, como alguém que lida com SwiftUI com desenvoltura
Como a cultura do Emacs está vazando para o software em geral
- O MDV faz mais sentido não como um produto acabado para recomendar instalação, mas como algo de onde se roubam ideias para criar algo melhor, como um usuário de Emacs olhando um
.emacsbrilhante - Na cultura do Emacs, usuários de longa data criam em elisp aplicações para resolver incômodos pessoais que começaram na edição de texto, e essas ferramentas se expandem para além do que seria um escopo razoável de um editor de texto
- O /r/emacs é mais próximo de uma cultura de mostrar o que fez do que de promoção de produtos ao estilo Product Hunt; existem pacotes elisp amplamente usados, mas fora o Magit há uma forte tendência de cada um refazer tudo em uma versão própria ainda mais brilhante
- A fraqueza da cultura do Emacs estava no fato de que, com exceção do Magit, os pacotes em geral eram feios, lentos e tinham uma experiência de usuário ruim que só era descoberta depois de muito tempo convivendo com elisp
- Os agentes de IA empurraram essa cultura para fora do Emacs e, com a possibilidade de criar UI nativa de forma confiável sempre que se tem acesso à tela e à entrada, a UI nativa saiu do território de programas empacotados de forma profissional e foi para o território da personalização individual
As possibilidades das ferramentas nativas pessoais
- O software emacsificado será, em sua maior parte, software pessoal útil só para quem o criou, e haverá mais ferramentas esquecidas, como velhos programas em elisp abandonados dentro do
.emacs - Às vezes, esses programas podem cruzar essa fronteira e se tornar úteis o bastante para que várias pessoas os instalem, mas mesmo então o mais importante talvez não seja o artefato distribuído nem o código-fonte
- Se o agente escreveu todo o código SwiftUI, pode se tornar mais importante do que ler o código-fonte em detalhe a ideia e observação de que “isso também pode ser feito e funciona bem”
- Nesse tipo de software, o prompt pode valer mais do que o código-fonte, e para quem já está acostumado a fazer software rodando-o diretamente, tudo passa a ser programável não só tecnicamente, mas também de forma prática
- Chamar de “build” o software feito com agentes parece exagerar o esforço investido; a sensação real fica mais próxima de configurar algo sobre uma plataforma que de repente ficou muito mais configurável
- Desenvolvedores que usam IA finalmente estão concluindo side projects aleatórios acumulados ao longo de vários anos
- Agora essas ferramentas ultrarr específicas não apenas conseguem ficar prontas, mas também podem ter uma UI boa de usar, o que enfraquece parte da justificativa anterior para aceitar a UI desajeitada do Emacs
- A possibilidade de melhorar apps de terminal ficou muito maior, e ferramentas como
iostat,iostatem vários hosts ebpftracetambém podem ganhar formas mais fáceis de entender - A complexidade que Brendan Gregg precisou aceitar para a visualização de terminal com
bpftracenão precisa mais ser tolerada como antes, e inclusive há um exemplo feito diretamente - Como pesquisador de vulnerabilidades, os avanços do desenvolvimento de exploits com programação baseada em agentes no primeiro semestre de 2026 foram interessantes, mas para a maioria das pessoas eram mudanças acompanhadas de medo; já a mudança de que criar UI nativa ficou divertido é algo próximo de uma boa notícia pura
- Recomenda-se criar ferramentas excessivamente específicas ajustadas ao próprio problema, aproveitá-las por um tempo e depois compartilhá-las — ou melhor ainda, compartilhar capturas de tela e os prompts usados
1 comentários
Comentários do Hacker News
Acho que agora os nerds já podem retomar áreas que hoje viraram, em sua maioria, softwares especializados pré-empacotados: apps de podcast, apps para ouvir música, leitores de feed, clientes do Bluesky, apps de notas, apps desktop de favoritos/ler depois, chat e mensageiros, rastreadores de tempo, gerenciadores de receitas e coisas do tipo
Dá para conseguir resultados com o Claude bons o bastante, melhores do que as alternativas. Talvez não sejam os melhores apps do mundo nem competitivos globalmente, mas dá para fazer apps que se encaixam muito melhor no seu jeito peculiar de trabalhar
O Music.app é sofrível de usar, mas a Apple já separou as funções principais faz muito tempo no MusicKit. Agora o produto de verdade é o MusicKit, então nem sei por que ainda usamos o Music.app, e isso é uma mudança nova
Um experimento nessa direção é https://github.com/dharmatech/9social
O primeiro cliente foi escrito para plan9, e isso ajuda a manter o design honesto. Se roda em plan9/rc/acme, então faz sentido
O vídeo de demonstração é https://youtu.be/q6qVnlCjcAI e a implementação atual tem menos de 3000 linhas de código
Já que estamos falando de Emacs, o 9social se inspirou bastante em um projeto Emacs chamado Org Social: https://github.com/tanrax/org-social
É uma interface inacabada baseada em planilha para registrar tempo. Foi feita para consultoria, mas nem chegou ao armazenamento dos dados. Tem um algoritmo bonitinho que consegue lidar com quase qualquer forma natural com que as pessoas registram o tempo, e eu fiz isso porque odeio como os rastreadores de tempo existentes forçam entrada estruturada: https://stackoverflow.com/a/49185071/59087
Gerenciador de receitas: https://repo.autonoma.ca/repo/recipe-fiddle
Na era dos LLMs, classificar ingredientes e formatar em TeX para publicação em PDF deve ficar muito mais fácil. A ideia desse projeto era fazer com que receitas da web ou scans de anotações manuscritas fossem formatadas automaticamente com quase um copiar/colar
No F-Droid não havia nenhum app que cobrisse tudo isso, então eu simplesmente gerei o APK
Acho que, graças à era dos LLMs, produzir software ficou tão fácil que tudo virou um arquivo .emacs. Ou seja, cada pessoa passa a ter um casulo de software totalmente pessoal e infinitamente customizável
Como o OP disse, ficou mais fácil criar a sua própria solução do que instalar ou aprender a usar o que já existe
Lisp também é uma boa analogia. Uma crítica antiga aos macros de Lisp era que todo programador acabava convertendo tudo para sua própria linguagem privada, de modo que ninguém mais conseguia ler
Isso também me lembrou o texto de 2007 do Mark Tarver, "The Bipolar Lisp Programmer": https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
Ele falava da "brilliant bipolar mind", o que hoje toca de forma interessante, de modo irônico ou sério, no tema da psicose por IA que aparece com frequência
No texto do Tarver https://www.marktarver.com/bipolar.html ele diz que o "throw-away design" da comunidade Lisp se encaixa perfeitamente na BBM. Lisp facilita tanto sair jogando coisas fora e criando outras que cada um faz sua própria solução e acha suficiente que ela sirva para si mesmo
Já em C/C++, fazer algo minimamente significativo é tão difícil que isso vira uma realização, e daí surge motivação para documentar e colaborar. Do ponto de vista do empregador, 10 pessoas que se comunicam, documentam e trabalham juntas são mais atraentes do que 1 hacker Lisp difícil de substituir
Quando produzir fica fácil, consumir vira o gargalo, e compartilhar fica difícil. Um arquivo .emacs é tão pessoal quanto uma impressão digital: dá para aproveitar pedaços, mas você não vai querer usar o de outra pessoa por inteiro
Quanto mais customizados esses casulos ficam, mais difícil é para os outros entendê-los ou querer usá-los. Há o custo cognitivo, mas também o desconforto de vestir a roupa dos outros. Em vez de chamar isso de psicose por IA, talvez faça mais sentido chamar de solipsismo por IA
Em software, a gestão de configuração está virando a parte difícil. Como compartilhar a fonte e versioná-la? O que é a fonte? É o prompt? No fim, o próprio OP vai na direção de compartilhar screenshots e prompts em vez de código
Até no Show HN teve um balão de ensaio propondo compartilhar prompts porque o código gerado já não seria mais a fonte, mas isso gerou muita reação negativa de quem entende do assunto: https://news.ycombinator.com/item?id=47213630
A pressão que o GitHub recebe também parece inevitável por causa dessa tendência. Não está claro como será o sucessor, mas ele vai acabar sendo necessário. Por enquanto ainda parece a fase da carruagem sem cavalos
Mais importante ainda é o trabalho em equipe. Se todo mundo virar BBM, ou se cada um de nós passar a ter sua própria legião frenética de BBMs gerando coisas 24 horas por dia só para nós mesmos, como vamos trabalhar juntos? Como esses casulos vão se comunicar e interoperar? Uma equipe de solipsistas de IA soa como uma contradição
Equipes e startups na linha de frente do desenvolvimento guiado por IA e por agentes provavelmente já estão enfrentando isso na prática. É o problema de como compor o meu código gerado com o seu código gerado. Por causa desse atrito, é bem possível que uma parte do ganho de produtividade do código gerado tenha de ser devolvida
É uma pena que ainda se fale tão pouco disso em público. Ninguém quer ser o primeiro a sentar durante a salva de palmas obrigatória, mas se fingirmos que é um almoço grátis sem desvantagens, a discussão fica chata e a evolução desacelera
Se as pessoas mais sérias e avançadas no uso dessas novas ferramentas não falarem sobre as desvantagens, então as críticas vão ficar só na mão dos cínicos que acham que a IA não tem valor para o desenvolvimento de software. Parece ser mais difícil falar de aumento de bugs ou estagnação de produtividade do que de extinção da humanidade
Eu queria saber o que realmente está acontecendo, como as pessoas estão reagindo e como isso vai mudar com o tempo. Talvez eu tenha de ir a meetups
O título de um artigo relacionado era "Easier to Write, Harder to Read": https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
Por que eu deveria ler o resultado de uma conversa específica com um LLM? Se eu souber o tema da conversa, posso ter uma conversa melhor eu mesmo
Software assim é parecido. Pode haver um pouco de gosto pessoal, mas no fim das contas o que importa são as ideias e a receita
Seria legal existir uma thread mensal "Vibe HN"
Fico curioso se alguém consegue compartilhar um vídeo criando um WhatsApp personalizado em menos tempo. E isso sem nem começar a tocar no problema de atrair outras pessoas para um mensageiro improvisado
Agora virou "vou jogar este ticket no Claude, você tenta com o Copilot e depois comparamos os resultados" ou "vou abrir um PR com o meu resultado tosco e você revisa com a sua ferramenta". Sinceramente, isso parece quase sem sentido, e o pair programming está completamente morto
Quem quer ficar assistindo várias agents rodando, corrigindo o problema em worktrees diferentes e depois arrumando inconsistências em agents.md?
Estão pressionando para montar pipelines em nuvem totalmente autônomos e auto-operados, mas parece que a gerência está segurando isso em silêncio. Dá a impressão de que existe um entendimento simples: no instante em que ficar provado que isso realmente pode voar, alguns vão perder posições confortáveis
O UNIX não era um produto, mas um ambiente otimizado para criar ferramentas e resolver problemas reais, e essas ferramentas eram escritas em C. Enquanto isso, os BBMs deviam estar ocupados com Lisp em Boston
C++ já é uma história completamente diferente, e aí você precisa de uma IDE
O Emacs tem essa característica porque usa Lisp. Essa tendência geral de os programadores passarem a fazer tudo por conta própria já foi observada em Lisp e recebeu o nome de The Lisp Curse
É uma maldição porque os programadores deixam de colaborar. Cada um vira um mago preso na própria torre, o progresso coletivo para e chega uma era das trevas
É verdade que a era dos LLMs criou software pessoal
Mas, sinceramente, o tempo que passei usando Emacs não me ensinou a fazer software pessoal. Minha configuração do Emacs era extremamente frágil e, quando tentei usá-la ao mesmo tempo no Windows e no macOS, virou um pesadelo
Meu projeto da faculdade foi escrito numa combinação estranha de org-mode com algum workflow que gerava belos arquivos LaTeX, mas hoje eu não saberia explicar como compilar aquilo de novo. Se eu tentasse, provavelmente pediria para um LLM traduzir tudo direto para LaTeX
Eu gostaria que minha vida tivesse o mínimo possível de manutenção, e fazer tudo por conta própria nem sempre combina com esse objetivo
Já reescrevi um aplicativo NETFX em Rust porque me irritava o fato de a instalação levar 20 minutos: https://github.com/bevan-philip/wlan-optimizer
O trabalho cotidiano de um programador é mudar o comportamento de sistemas computacionais locais, remotos, em nuvem, embarcados etc. Os requisitos mudam, o escopo oscila, o espaço do problema evolui e o acúmulo é inevitável
Você precisa transitar o tempo todo entre stacks de linguagem, tipos de dados, formatos, ferramentas CLI e web, protocolos, paradigmas, software open source e aplicativos proprietários
Então é preciso continuar se adaptando, e o seu plano de controle também precisa acompanhar as mudanças. A chave é a automação. Todo pequeno incômodo pode e deve ser automatizado. Isso significa deformar continuamente o workflow, ou seja, fazer manutenção contínua das ferramentas, mas não aquela manutenção reativa e dolorosa
Ser programador e não querer continuar criando software para si mesmo é uma ilusão. É como um cozinheiro que acende o fogo no restaurante, mas em casa não quer nem pegar na faca
O Emacs é a cozinha doméstica do cozinheiro. Existe a manutenção reativa, como consertar falhas e correr atrás de mudanças, e existe a manutenção generativa, que molda as ferramentas à medida que o entendimento evolui. O programador deve odiar a primeira e se sentir atraído pela segunda
O Emacs é quase singularmente adequado para manutenção generativa porque as ferramentas e o trabalho compartilham o mesmo temperamento
A reclamação de que "a configuração do Emacs dá trabalho demais" é comum, mas em geral significa "não quero investir antes de obter valor". Isso não é uma estratégia sábia no longo prazo. Faz mais sentido ver o Emacs como uma ferramenta universal para reduzir o custo total de manutenção ao longo da carreira e da vida
Configurações de Emacs ou VIM são só arquivos de texto, então dá para abri-las num editor comum, mexer no que for preciso e saber onde está cada coisa. Minha configuração do VIM tem 20 anos, e há 1 ou 2 anos a única mudança foi abandonar a gestão manual de pacotes e passar a usar um gerenciador de plugins
Aqui não existem gatekeepers nem dependências
Já o jeito atual exige pagar de 20 a 200 dólares para uma empresa terceirizada ou então ter uma GPU bem forte para rodar localmente, além de ficar colocando instruções em arquivos de texto e mexendo até sair como você quer
Isso adiciona uma dependência por conta própria, e se ficar tão emaranhado que humanos mal consigam revisar, então essa dependência será uma dependência forte. Seja uma GPU cara, seja enviar seus dados para uma empresa que precisa satisfazer acionistas
Precisamos distinguir como essas duas coisas diferem e qual é o custo real que estamos pagando
A ideia de software pessoal, isto é, escrever programas para si mesmo, era a visão original da computação doméstica nos anos 1960
O PC não foi previsto exatamente como veio a existir, mas havia a ideia de que todo mundo teria um terminal de computador em casa e escreveria programas para fazer o que precisasse. Imaginava-se que programar ficaria fácil o bastante para qualquer um aprender
Ainda não chegamos lá, mas os LLMs estão nos aproximando disso
A ideia é que não especialistas possam criar software interessante em um ambiente de autoria com componentes bem projetados e metáforas fáceis de entender. As camadas de complexidade acidental ou excessivamente projetada teriam de ser removidas
Mesmo nessa visão, software ainda exige raciocínio lógico cuidadoso, mas o esforço de transformar esse raciocínio em código executável seria muito menor. E também não existiria o pesadelo de toolchains e sistemas de build
Em vez disso, criamos modelos poderosos demais para repetir e recombinar, em nosso lugar, feitiços complexos. Só que a complexidade continua lá, e para não especialistas ela ainda é opaca
Ainda assim, talvez os LLMs possam ajudar a remover parte dessa complexidade. Continua possível imaginar um caminho em que software gerado por LLM seja fácil para indivíduos entenderem e modificarem diretamente, e isso pode complementar bem o mundo dos LLMs
Isso não é questão de possibilidade, mas de prazo: no máximo 10 anos, provavelmente muito antes. Parentes meus que não sabem programar já estão fazendo esse tipo de coisa
Esse futuro da computação é realmente adorável e extremamente empoderador
Meu app atual em Swift tem 15 mil linhas, sendo 5 mil de testes e 10 mil de implementação. Está quase pronto e faz o que eu preciso. Levou 20 horas
Eu nunca tinha mexido com Swift, então se fosse fazer por conta própria acho que levaria umas 500 horas
Como a maioria de nós é preguiçosa, provavelmente isso não vai tão longe, mas mesmo assim vale considerar
A própria ideia de aplicação vai ficar muito mais fluida
Se um app foi feito numa linguagem dinâmica, não há motivo para impedir que o próprio usuário reescreva o código e acrescente funcionalidades totalmente novas
Isso não tem relação direta com o texto principal, mas discordo da ideia de que terminais serem quase sempre monoespaçados torna cansativo ler textos longos. Pessoalmente, acho muito mais confortável ler textos longos em fonte monoespaçada
O autor apontou algo interessante. As variáveis em jogo são a dificuldade de criar ferramentas, a dificuldade de publicá-las, a utilidade para terceiros, a recompensa social por publicá-las e o incentivo negativo de adicionar dependências
O quanto fica difícil encontrar soluções prontas aumenta conforme o custo de alguém precisar construí-las e de alguém precisar descobrir como publicá-las. Em contrapartida, quanto mais útil for para a comunidade, mais fácil será encontrá-la porque as pessoas vão divulgá-la
Quando a dificuldade de criar e a de publicar divergem bastante, especialmente se criar for muito mais difícil, as pessoas tendem a simplesmente fazer por conta própria e esquecer. Se publicar for barato, haverá menos soluções para o problema
Se ambos forem baratos, e a utilidade para terceiros mais a recompensa social superarem o custo das dependências, surgem casos como o do leftpad. Muitos pacotes do NPM combinam alta utilidade e recompensa com baixo custo de dependência
Em Emacs Lisp, antes a dificuldade de criar era alta, mas agora é baixa; e, depois que se passa a curva de aprendizado, a dificuldade de publicar também é baixa. Utilidade, recompensa e custo de dependência também não tendem a ser altos em nenhum dos lados
Aí aparece o cenário em que a pessoa simplesmente faz antes mesmo de procurar se já existe uma ferramenta. VSCode e o Eclipse antigo eram diferentes porque o custo de publicar era alto
Aposto que alguém mais jovem do que eu ainda vai transformar isso em tema de artigo acadêmico
Este texto sugere uma mudança ainda não concretizada que o coding com LLM pode trazer. Será que agora dá para abandonar Electron/React Native e deixar que o LLM transforme Figma, wireframes e especificações de comportamento em apps realmente nativos para cada plataforma?
Se for um app CRUD, só a especificação da API e mockups de UI, ou até screenshots de uma plataforma já implementada, já podem levar bastante longe. Esse tipo de trabalho bem definido é algo em que os LLMs vão bem. Testes de equivalência também deveriam poder ser automatizados em grande parte
Ainda vai sobrar a desculpa de "talvez algum dia a gente adicione Android" ou "não temos usuários suficientes de Mac/Linux"? E ainda vai ser justificável que um app iOS abra uma WebView aleatória para fluxos menos usados como redefinição de senha?
Mesmo em apps com lógica não trivial no dispositivo, os LLMs já mostraram bastante potencial para reescrever isso em linguagens como Go ou Rust, que facilitam compilação cruzada
Indo mais longe: por que alguém deveria aprender SwiftUI neste momento? Para a maioria das tarefas, especialização em SwiftUI entra quase na mesma categoria de "aprender Microsoft Word profundamente"
Eu respeito quem investe tempo nisso, mas, fazendo ou não fazendo, a diferença no resultado final fica perto da casa dos milímetros
Não penso assim sobre programação em geral. Só acho que agora ficou mais complicado justificar a especialização em certas linguagens