antonio leandro

comentariotechen

Dan Luu

Engenheiro vindo de hardware de CPU, com passagens por Google, Microsoft, Twitter e Wave. Escreve um blog sem CSS onde mede o que o resto da indústria só opina: latência, bugs, bloat, contratação. Ficou quase dois anos calado e voltou em 2026 escrevendo sobre LLM.

128 textos no acervo · publica a cada ~21 dias · último em

escrito por pipeline de llm, revisado por antonio leandro antes de publicar

o que esta fonte defende

Há uma tese única atravessando os 128 textos, e ela é fácil de enunciar: quase tudo que a indústria de software acredita sobre si mesma é folclore que ninguém nunca mediu — e quando alguém se dá ao trabalho de medir, o número contradiz o folclore. O método é sempre o mesmo e é deliberadamente barato: pegar a fonte primária, contar, publicar a tabela. Daí saem os resultados que fizeram o nome do blog. Máquinas de 2017 com latência de tecla pior que a de um computador de 1983. Os estudos “da Apple” sobre mouse ser mais rápido que teclado, citados por décadas, que não existem na forma em que são citados. Revisões de literatura sobre tipagem estática que não acham a evidência que todo mundo assume existir. Afirmações apoiadas em “estudos mostram” cujo estudo, quando lido, diz o contrário. A conclusão implícita não é que a indústria mente; é que ela raramente verifica, e que verificar é mais fácil do que as pessoas imaginam.

A segunda posição recorrente é o corolário econômico da primeira: mercados não corrigem. O alvo explícito é o que ele chama de “versão de festa da hipótese dos mercados eficientes” — a ideia de que uma ineficiência grande não pode persistir porque a concorrência a eliminaria. Ele vira essa faca contra contratação, salário, qualidade de produto, discriminação e antitruste, e o veredito é sempre que a ineficiência sobrevive décadas em plena luz. Isso tem um lado prático que ele repete sem ironia: se o mercado não corrige, a ineficiência é explorável por quem estiver disposto a fazer o trabalho chato. É a mesma lógica de “95%-ile não é tão bom assim” — a maior parte das pessoas fica boa na maior parte das coisas com esforço bem menos heroico do que se diz.

O arquivo mudou de forma duas vezes, e a segunda mudança é a mais informativa. De 2013 a 2015 o blog é quase todo baixo nível: Verilog, arquitetura de CPU, cache, escrever um malloc — escrito por alguém que vinha de verificação de hardware. De 2016 a 2022 ele migra para organizações, incidentes, economia da contratação: são os textos que tornaram o site famoso. Depois vem um silêncio quase completo — entre o texto sobre Ballmer, de outubro de 2024, e a volta em julho de 2026, há vinte meses de nada, o que faz a cadência de “um a cada três semanas” ser um artefato da janela recente, não um hábito. E a volta é inteiramente sobre LLM. Aqui está a inversão que vale registrar: o sujeito que passou uma década documentando que tudo está quebrado não virou cético de IA. Ele usa agentes pesadamente, diz que um agente faz coisas pelas quais você demitiria um humano na hora e que a reação dele é subir mil agentes para fazerem mais daquilo, e aponta o instrumento de medição para os benchmarks de LLM em vez de apontar para os modelos. Em um dos textos de 2026 ele contraria diretamente o pânico corrente de que LLM está engordando o software: para ele não há mais desculpa para software lento, e a lentidão nunca foi por falta de ciclo de CPU.

Um pedaço considerável do arquivo, porém, não é argumento nenhum — e fingir o contrário seria desonesto. Talvez um em cada dez textos é hospedagem de fonte primária: transcrições de entrevistas, exibits de processo judicial, threads de USENET de 1997, tumblrs apagados que ele resgatou. Isso não é acaso nem preguiça: é a mesma tese aplicada à leitura, a de que quase todo relato de segunda mão sobre um documento está errado de algum jeito, então o serviço útil é publicar o documento legível. Da mesma família é a página em que ele lista os erros graves do próprio blog, com as correções — algo raro o bastante para ser um sinal por si só de como ele trata evidência.

por tema

tudo está quebrado e quase ninguém enxerga (20 textos)

A linha mais antiga e mais teimosa do arquivo. Ele afirma esbarrar em centenas de bugs por semana, ouve descrença, e no texto mais recente conclui que a diferença não está em como ele usa o computador: as pessoas foram treinadas a não registrar a falha. Culpam-se, tentam de novo, criam um contorno e seguem — e no minuto seguinte dizem que nada quebra. Em cima disso vem uma década de trabalho empírico bem menos filosófico: sistemas de arquivos que perdem dados em silêncio, código que não confere o retorno de funções que podem falhar, o caso do fsync que não avisa que falhou, bugs de concorrência cujas causas são triviais e mesmo assim derrubam clusters, memória sem ECC, dez anos de incidentes graves de cache no Twitter tabulados um a um.

O complemento organizacional é o conceito que ele importa da aviação e da NASA: normalização do desvio. A empresa não decide tolerar o defeito; ela para de perceber que aquilo é um defeito, porque todo mundo ali já viu aquilo mil vezes. É a explicação de por que os postmortems se repetem, de por que o build quebrado vira paisagem, e é a lente com que ele lê o relatório sobre o carro autônomo da Cruise que arrastou uma pedestre por seis metros. O mesmo mecanismo aparece, num registro mais leve, quando ele compara como fóruns reagem a viés de IA e a bugs comuns: a reação depende menos da gravidade do que do que já foi normalizado.

medir em vez de opinar (21 textos)

É o método da casa, e o tema com mais textos memoráveis. Ele carrega uma câmera de alta velocidade para cronometrar a latência real de máquinas de quarenta anos, de teclados de gamer vendidos a peso de ouro e de emuladores de terminal, e o resultado costuma ser desconfortável: o hardware antigo ganha, o produto caro não é mais rápido, o número da caixa não descreve nada. Em outros textos ele vai atrás das citações em vez do aparelho — e descobre que os estudos famosos sobre mouse versus teclado não dizem o que se atribui a eles, que a versão popular de Dunning-Kruger não é o que o artigo mostra, que a matéria viral sobre inexistência de diferença salarial de gênero olhava um recorte estreito demais para sustentar a manchete. A conclusão prática que ele repete é modesta e útil: ler a citação é mais fácil do que as pessoas acham.

A segunda metade do tema é o que acontece quando a métrica vira meta. Ele coleciona casos em que o benchmark é jogado em vez de perseguido — o compilador que reescrevia o subteste, os carros que vão bem no crash test padrão e mal no teste fora da amostra, a Oracle tentando demitir um professor que a mediu — e reencontra o mesmo padrão nos evals de LLM, onde diz ser hoje mais fácil forjar ganho do que obtê-lo. Um dos textos de 2026 refaz uma medição amplamente citada sobre eficiência de tokens por linguagem de programação e chega a um resultado diferente do que virou consenso repetido inclusive por buscadores com resumo de IA.

bloat: software lento e quem fica de fora (7 textos)

Dois textos separados por sete anos formam o argumento: um mede como a web se comporta em conexão lenta, outro em aparelho lento. A conclusão dos dois é que boa parte do site moderno simplesmente não funciona para uma fatia enorme de gente — e que quem projeta esses sites nunca testou fora de um laptop caro com fibra. O detalhe que ele gosta de apontar é a inversão: páginas de texto pesadas de framework ficam inutilizáveis enquanto blogs sem quase nenhum estilo carregam na hora, e quem mais precisa de leveza é quem menos a recebe.

A parte teórica é a recusa da desculpa. Ele discorda da distinção clássica entre complexidade essencial e acidental, usada há quatro décadas para argumentar que não dá para melhorar muito a produtividade de quem programa — para ele a linha entre as duas é móvel e boa parte do que se chama de essencial é histórico. No texto de 2026 sobre lentidão a posição fica explícita e vale contra os dois lados do debate atual: não há mais desculpa técnica para software lento, nem antes nem depois dos LLM, porque a lentidão quase nunca vem de falta de ciclo. Textos menores no mesmo veio: o crescimento do número de opções de linha de comando contra a promessa unix de fazer uma coisa só, mudanças de UI que quebram memória muscular, e o exercício de acelerar o próprio blog em cinquenta vezes.

mercados que não corrigem nada (21 textos)

O alvo explícito é a ideia de que uma ineficiência grande não sobrevive à concorrência. Ele ataca por vários flancos: contratação que descarta gente competente porque o currículo não passa pelo filtro de empresa da moda, entrevistas de algoritmos exigidas por motivos que não sobrevivem ao exame, salários que variam em múltiplos para o mesmo trabalho, opções de startup comparadas honestamente com dinheiro à vista, e a pergunta que dá título a um dos textos centrais — por que é tão difícil comprar coisa que funciona bem. A resposta que ele monta é que ineficiências persistem por décadas em plena vista, o que também derruba o argumento de que discriminação seria impossível por ser cara demais para a empresa.

O segundo braço é a escala. Ele defende que fraude, spam, suporte e moderação têm deseconomia de escala: a loja grande é pior que a pequena em confiar no que vende, e num raio grande o suficiente é matematicamente impossível ter uma política de moderação com que as pessoas concordem — ele usa um jogo simples sobre a placa “proibido veículos no parque” para mostrar que nem no caso trivial há acordo. Aparecem aqui também as leituras de documento primário sobre poder de mercado — os memorandos internos da investigação antitruste contra o Google, a ordem judicial no caso de combinação de salários entre Apple, Google, Intel e Adobe — e a defesa contraintuitiva de que Steve Ballmer foi um CEO subestimado, escrita contra a narrativa dominante em toda discussão online sobre o assunto.

arquitetura chata, operação e gente de casa (12 textos)

A posição de engenharia mais concreta do arquivo, e a mais fácil de aplicar. Ele descreve a empresa onde trabalhou — avaliada em mais de um bilhão de dólares, setenta engenheiros — rodando um monólito Python sobre Postgres, e argumenta que começar simples e resolver problema de forma simples foi exatamente o que permitiu chegar àquele tamanho. Na mesma família estão a defesa de linguagens entediantes e a defesa de monorepo, os dois escritos contra a reação automática de que aquilo é obviamente errado.

O contrapeso é que “simples” não quer dizer “sem gente que entenda”. Dois textos curtos e muito citados mostram que um dia de trabalho montando um jeito de consultar métricas de todos os hosts e serviços num intervalo qualquer achou uma economia de sete dígitos, e que tracing distribuído dá retorno bem antes do investimento heroico que as pessoas imaginam ser necessário. E o texto sobre ter um time de kernel dentro de uma empresa de produto sustenta a tese oposta à terceirização total: expertise interna se paga em problemas que ninguém de fora vai olhar por você — o problema de throttling de container e o particionamento de cache do processador são os exemplos que ele destrincha.

o andar de baixo: cpu, cache e verilog (18 textos)

A camada mais antiga do blog, escrita por alguém que trabalhava com verificação de CPU e aceleradores antes de migrar para infraestrutura. São textos didáticos de verdade, no formato de explicar uma coisa por vez: o que mudou nos processadores desde os anos 80, como funciona previsão de desvio, por que política de despejo aleatória em cache é menos ruim do que parece, quanto custa realmente ligar verificação de overflow de inteiro, como escrever um malloc do zero. Vários deles são transcrições de palestras, o que dá um tom de conversa que os posts mais argumentativos não têm.

Há também um subconjunto sobre desenvolvimento de hardware que quase não tem equivalente em blogs de software: por que projetar chip é difícil de um jeito diferente, por que Verilog é uma linguagem esquisita e cheia de armadilhas, e como escrever Verilog seguro num ambiente em que compilar leva cinco minutos e um teste curto leva quinze. É a área em que ele fala com autoridade de primeira mão, e boa parte do ceticismo dele com testes de software vem desse contraste — em hardware, o custo de errar depois do tape-out muda inteiramente o cálculo de quanto vale testar.

escrever, aprender e topar parecer burro (29 textos)

É o tema menos coeso do arquivo — e é onde mora o que há de mais pessoal. O centro é um texto sobre disposição a parecer burro: ele diz que as pessoas frequentemente o acham burro, que isso é consequência direta de não ajustar o comportamento para evitar essa impressão, e que a troca compensa porque perguntar a coisa óbvia é o que faz aprender rápido. Ao redor disso: por que ele acha que velocidade de execução importa mais do que se admite, por que indivíduos não são intercambiáveis num roadmap, o que cultura faz que incentivo e processo não fazem, o que vale a pena aprender quando todo conselho de carreira é autobiografia disfarçada, e conselhos sobre escrever que começam justamente recusando a ideia de que existe um jeito certo de escrever. Há também a defesa contraintuitiva de que os comentários do Hacker News são subestimados, e a lista pública dos erros graves do próprio blog com as respectivas correções.

O outro pedaço, bem diferente em natureza, é o de arquivista. Ele hospeda documento primário porque acha que quase todo relato de segunda mão sobre esses documentos sai torto: as mensagens trocadas no processo do Twitter contra Musk, transcrições de entrevistas, um artigo do John Carmack sobre latência em realidade virtual que sumiu da internet, textos de um blog de física apagado. Junto vêm os textos sobre acerto de previsão — o histórico de um previsor conhecido conferido item a item, os métodos dos futuristas — e um de 2015 que envelheceu de forma incômoda: o argumento de que IA não precisa ser muito boa para deslocar trabalho humano, porque a comparação relevante nunca foi com o humano ideal.

onde ela discorda de outras fontes do acervo

Boa parte do arquivo é escrita explicitamente contra alguém, e quase sempre contra nomes grandes. Ele contradiz Jeff Atwood ponto a ponto sobre não usar memória ECC; contradiz Joel Spolsky na tese de que os melhores desenvolvedores nunca estão no mercado; contradiz Fred Brooks ao recusar a divisão entre complexidade essencial e acidental do “No Silver Bullet”; contradiz Paul Graham na aritmética de entrar numa startup para ficar rico; contradiz Marc Andreessen na afirmação de que discriminação sistemática seria impossível porque o mercado é competitivo demais para tolerá-la; e contradiz os textos de Bruce Tognazzini sobre mouse ser mais rápido que teclado, mostrando que os estudos citados não sustentam a afirmação. Também vai contra dois consensos de fórum: a narrativa de que a Microsoft estava morta sob Ballmer e a de que os comentários do Hacker News são inúteis. Em 2026, contra a leitura corrente de que LLM está deixando o software mais lento e inchado, ele sustenta que a lentidão nunca teve desculpa técnica — e contra uma medição viral sobre eficiência de tokens por linguagem, refaz a conta e chega a outro resultado.

linha do tempo