Acredito que muitas empresas estão agora mergulhadas em uma psicose coletiva de IA
(twitter.com/mitchellh)- Mitchell Hashimoto: "Muitas empresas estão agora mergulhadas em uma grave psicose coletiva de IA, e é impossível ter uma conversa racional com elas"
- O debate MTBF vs MTTR da era da automação de infraestrutura em nuvem agora está se espalhando por toda a indústria de desenvolvimento de software, e a fé cega em agentes de IA está criando uma nova forma de loucura coletiva
- A visão absolutista do MTTR, resumida em "tudo bem lançar bugs porque os agentes vão corrigi-los rapidamente", está se espalhando, e esse é um modo de pensar que já se provou fracassado na era da infraestrutura
- Um sistema pode parecer saudável em métricas locais e ainda assim se degradar, no conjunto, para um estado incompreensível; a redução de relatórios de bugs e o aumento da cobertura de testes não garantem segurança real
- Quando esse problema é levantado diretamente, a conversa é bloqueada por refutações imediatas como "a cobertura de testes está em 100%" ou "os relatórios de bugs estão caindo", sem enxergar o quadro geral
- As mudanças estão rápidas demais, e ninguém percebe a erosão da arquitetura subjacente, enquanto se constrói uma "máquina resiliente de desastres" automatizada
Argumento central: psicose coletiva de IA (AI Psychosis)
- Atualmente, muitas empresas estão em um estado grave de psicose coletiva de IA, e é impossível sequer ter uma conversa racional com elas
- A razão para não citar nomes específicos é que entre elas estão amigos por quem ele tem profundo respeito pessoal
- Ele expressa grande preocupação com a forma como essa situação pode evoluir
A lição da era da infraestrutura: MTBF vs MTTR
- O debate MTBF (tempo médio entre falhas) vs MTTR (tempo médio para recuperação), vivido durante a migração para a nuvem e a automação em nuvem, voltou à tona
- Na época, isso ficava restrito à infraestrutura; agora, está se ampliando para toda a indústria de desenvolvimento de software (e além, para o mundo inteiro)
- Os defensores mais radicais da IA operam quase sob uma lógica absoluta de "MTTR basta"
- A ideia é: "como os agentes vão corrigir bugs em uma velocidade e escala que humanos não conseguem, tudo bem lançar bugs"
- A lição aprendida na era da infraestrutura: MTTR é ótimo, mas não dá para abandonar completamente sistemas resilientes
Bloqueio de conversa e padrão de refutação
- Quando ele levanta esse problema com pessoas que conhece pessoalmente, a reação é de desconsideração imediata
- Respostas como "não, a cobertura de testes está completa" ou "os relatórios de bugs estão diminuindo"
- Essas refutações não mostram o quadro completo
- Ele já expressou essas preocupações diretamente em privado, mas não foi ouvido, e concluiu que era importante compartilhar isso de forma mais ampla
A máquina automatizada de desastres
- Uma lição já aprendida na infraestrutura: é possível criar, com automação, uma "máquina de desastres altamente resiliente"
- O sistema parece saudável em métricas locais enquanto, no todo, se torna incompreensível
- Os relatórios de bugs diminuem, mas os riscos potenciais explodem
- A cobertura de testes sobe, mas a compreensão semântica cai
- As mudanças acontecem rápido demais, e ninguém percebe a erosão da arquitetura subjacente
Pontos levantados nas principais respostas
- @adamhjk: "o que o vibe coding puro destrói primeiro é a própria arquitetura"; para detectar erosão, é preciso haver arquitetura desde o início
- Explicação adicional de Mitchell Hashimoto: na infraestrutura, é possível atualizar sistemas online e aplicar MTTR a todos os usuários em um tempo razoável; porém, em softwares como bibliotecas, software desktop e apps móveis, que terceiros integram ou executam diretamente, essa abordagem não funciona
- @tinygrad: entramos em uma era em que não se leva 10 segundos, mas 20 minutos para determinar se algo dito pela IA está completamente errado, e as organizações precisam manter contato com a realidade
- @beyang: o UX atual de agentes está fazendo de "LGTM (Looks Good To Me)" o caminho de menor resistência, e a velocidade com que agentes geram código aparentemente plausível transforma o problema de validação no code review em uma ameaça imediata
- @beh_zod: a função de recompensa do lançamento é curta, e o tempo necessário para as pessoas perceberem a dívida que estão acumulando ultrapassa, na maioria dos casos, seu horizonte de atenção
- @shipwithjay: é sintomático quando a liderança de engenharia fica em silêncio e não consegue responder a perguntas contrafactuais (o que teria de ser verdade para interrompermos isso?)
- @chadfowler: ele está escrevendo um livro sobre esse problema, e o ponto central é realocar o rigor para a arquitetura e para o sistema de avaliação; este é o momento de colocar em prática boas práticas que antes não eram seguidas por falta de tempo e dinheiro
Respostas de Mitchell Hashimoto às perguntas e opiniões das pessoas
- P: "O que deveríamos fazer em vez disso?"
- R: "Pensem (usem IA, mas pensem)"
- P: Ele considera mais provável que a ideia de que "IA é superestimada" seja, na verdade, um sintoma ainda mais psicótico
- R: Toda tendência secular é superestimada, mas isso não é motivo para descartá-la em bloco
- P: "Se eu tiver de escolher entre proteger o que tenho agora e me jogar no risco, escolho a segunda opção"
- R: Isso não é um interruptor binário
1 comentários
Comentários do Hacker News
Consultoria de arquitetura de IA parece que vai virar uma grande categoria de consultoria de alto valor, como resposta a incidentes de segurança ou especialistas em recuperação de dados
Sistemas escritos puramente por IA podem crescer até um nível de complexidade que humanos não conseguem entender, enquanto a taxa de correção de defeitos cai e o consumo de tokens por defeito aumenta; no fim, mudanças feitas pela IA podem passar a criar mais defeitos do que corrigem, deixando tudo instável
Vai acabar sendo necessário algum procedimento especializado para organizar essa bagunça como em uma clean room, extrair os princípios centrais de design e, provavelmente ainda usando IA, reconstruir tudo do zero
A engenharia de software do futuro provavelmente vai girar em torno de princípios para evitar isso desde o começo, mas, assim como a engenharia de software tradicional levou mais tempo do que se esperava para chegar a princípios de design estáveis, deve levar 20 anos para aprender isso
O hospital até deu acesso aos servidores do departamento de TI, mas como ele não conseguia conectar o Claude, entrou em desespero sem saber como fazer o deploy e me procurou; o app também parece ter uns problemas interessantes relacionados a dados/estado
Lembra alguém recebendo entregas ilimitadas e grátis de produtos da Amazon em casa: em teoria é uma vida de abundância, mas na prática você acaba soterrado por algo que não é prosperidade
Todo mundo sabe no que isso deu
Tinham meio que reimplementado Kubernetes dentro de milhares de linhas de Github Actions, e era impossível entender aquilo
Não gosto do marketing de IA, mas acho útil como ferramenta para fazer gente experiente se mover mais rápido
Só que, para quem não é especialista, a IA parece produzir soluções complicadas para qualquer coisa que tentem fazer
Parece que ele está falando menos do uso da IA em si e mais do fenômeno de empresas e pessoas terceirizarem decisões e raciocínio para a IA
Escrever código com IA não é psicose de IA nem algo ruim, mas simplesmente mandar um prompt e acreditar no que a IA disser já parece mais próximo de psicose de IA
Vejo com frequência, no Twitter, gente do mercado financeiro e VCs substituindo pensamento e raciocínio por screenshots do ChatGPT em assuntos sobre os quais bastaria pensar um pouco por conta própria
Essas ferramentas são péssimas para ideias, reflexão e conselhos; só devolvem padrões que parecem corresponder por pattern matching, então quando você discute uma ideia com elas, normalmente sai o tipo mais genérico de besteira
Por outro lado, são bem úteis em tarefas como escrever código, em que pattern matching realmente ajuda, mas não deveriam receber a responsabilidade por pensamento e tomada de decisão
No geral, o teto ficou mais alto e o piso mais baixo, e a descrição acima é muito precisa
Escrevi sobre isso aqui: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
O último texto trata de uma mudança complexa que fiz graças à IA, e também mostra como abordo isso de forma razoável
Ela quase sempre gera um texto que parece logicamente correto, mas dentro dele pode haver premissas implícitas e decisões erradas que não se encaixam naquele caso de uso
Para chegar à solução realmente correta, a definição do problema precisa estar bem feita, e isso talvez seja mais difícil do que construir a solução
Ou então para algum consultor aleatório
“A IA disse que era uma boa ideia” é mesmo pior do que “seguimos a tendência do setor”?
Quando isso acontece com um indivíduo, amigos e familiares acabam apontando comportamentos ou falas estranhas e colocam algum freio
Mas quando o empregador começa a agir assim no nível da liderança, é difícil imaginar o quão ruim pode ficar
Você passa a sofrer pressão para aderir ou a temer demissão, e as únicas pessoas que poderiam ajustar seu pensamento são colegas que discordam, mas esses têm grande chance de sair ou serem mandados embora
Para manter o emprego, você precisa entrar no jogo
O agente toma decisões no seu lugar, então o trabalho anda na velocidade do agente, e muitas vezes ele decide tudo sem falar nada e só entrega no fim algo como “o plano é este”
Para revisar isso direito, você precisa entender profundamente o problema e voltar à velocidade humana, então no fim você só passa o olho e aprova
O ponto principal é escolher de forma consciente e cuidadosa quais decisões serão terceirizadas
Isso exige desacelerar, reduzindo aqueles ganhos inflados de 10x do vibe coding, mas em troca você participa mais e acumula menos dívida cognitiva
Decisões chatas, como como iterar por um array ou como encaixar a saída de uma chamada na entrada de outra, podem ficar com o agente
As decisões de verdade precisam ser tomadas antes e colocadas na especificação: definir limites, APIs, estruturas de dados centrais, sistemas e responsabilidades, tratamento de erros e restrições fortes de segurança e privacidade
Se estiver ambíguo, é preciso instruir o agente a parar; um bom engenheiro consegue ganhar 2–3x de velocidade sem efeitos colaterais
Talvez isso acabe transformando engenharia de software em uma disciplina de engenharia de verdade
Hoje, gente que só escreve prompts está montando a infraestrutura inteira da empresa
Conheço pessoalmente alguém que migrou o banco de dados da empresa para uma versão mais nova do Postgres e, no fim, deu certo, mas só de ouvir a descrição do processo eu fiquei rangendo os dentes
A sensação era tipo: “joguei gasolina no servidor e acendi um cigarro, mas relaxa, achei um extintor no porão. O medidor diz que está vazio, mas se eu sacudir ainda dá para ouvir líquido lá dentro”
Quando ele sair da empresa, vai ser preciso outro prompt engineer ainda mais autoconfiante para manter aquela infraestrutura de banco de dados
O texto observa que não dá para discutir com pessoas que dizem “não tem problema publicar bug, porque o agente consegue corrigir numa velocidade e escala que humanos não conseguem”
E, no entanto, a resposta principal logo acima é exatamente um exemplo de “mas os agentes são muito rápidos”
Talvez a suposição seja que o ganho de dobrar o codebase e as funcionalidades compense o prejuízo de dobrar os bugs
Pelo menos no relatório trimestral para investidores isso deve ficar bonito
Pode ser que só continuemos publicando mais lixo, e o loop de feedback seja o cliente?
A resposta foi: “É teoria dos jogos. Alguém vai fazer isso, e você também vai ser obrigado. Não pode ser tão ruim assim”
A lógica é útil, mas ignorar os riscos é outra coisa
Assumir que mover-se absurdamente rápido e quebrar tudo vai acabar produzindo um bom resultado é perigoso
Esse movimento da IA não está indo bem e eu não gosto dele
Não acho necessariamente que o lado em psicose seja “o nosso”
Trabalho numa empresa muito grande, e a nossa sempre foi glacialmente lenta para modernizar e adotar tecnologia
Mas, curiosamente, agora isso pode até virar uma vantagem competitiva
A vida imitando a arte
Antes eu fazia piada de que ainda existem fax por aqui, mas não imaginava que seria tão reconfortante estar numa cultura onde esse frenesi não existe
Quando leio o HN, parece que entrei na Alice's Wonderland dos maximizadores de tokens e dos psicóticos de IA
Aqui eu realmente não conheço uma única pessoa sendo forçada a trabalhar desse jeito
Se essa vibe é a sua cara, talvez você goste da nova ferramenta de CLI Burn, Baby, Burn (those tokens): https://github.com/dtnewman/burn-baby-burn/tree/main
O Show HN está aqui: https://news.ycombinator.com/item?id=48151287
Isso me lembra Simple Made Easy, do Rich Hickey, e a abordagem que ele teve ao criar Clojure
Mesmo antes de LLMs gerarem programas inteiros, frameworks complexos já permitiam que desenvolvedores criassem uma primeira versão do programa muito rapidamente, em troca de torná-lo difícil de entender e, portanto, difícil de depurar e modificar
Algumas pessoas estão apostando que, por mais emaranhados e complexos que os programas escritos por IA sejam, a IA sempre será inteligente o bastante para depurar, manter e modificar tudo isso
Eu não tenho essa confiança
Psicose de IA não é uma posição contra usar IA
Eu uso ferramentas de coding com IA todos os dias, mas as ferramentas de IA não têm noção de futuro
A construção de sistemas estáveis sempre dependeu daquele raciocínio egoísta do engenheiro que pensa: “se isso quebrar em produção, eu não vou conseguir consertar, e vão me chamar às 3 da manhã”
Também sempre existiu a preguiça comum de procurar uma biblioteca perfeita no CPAN para não precisar fazer o trabalho manualmente, e às vezes levava mais tempo procurar a biblioteca do que escrever aquilo por conta própria
Já usei ferramentas de IA para escrever milhares de linhas de código e colocar em produção, e no geral isso pareceu natural, porque desde 2017 venho dizendo às pessoas para não digitarem todo o código manualmente e, em vez disso, escrevê-lo, montando armadilhas nos testes para capturar código ruim
Mas uma coisa que a IA não faz é escrever menos código: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
Relatórios de bugs também diminuem quando as pessoas perdem a fé de que algo será corrigido
Isso acontece porque reportar bugs muitas vezes exige um investimento considerável de tempo
Esse tipo de coisa acontece com bastante frequência quando a confiança em algum grupo ou empresa entra em colapso
Por isso, há mais chance de serem reportados de forma errada, e partes do conteúdo podem estar incorretas
É como sofrer ataques por vários lados
E nem chegamos ainda às táticas adversariais
Se você não tivesse nenhuma moral, que método seria melhor do que usar agentes para inundar concorrentes com relatórios falsos de bugs?
Problema resolvido
Muito do que o Mitchell observou, talvez tudo, pode perfeitamente acontecer mesmo sem IA
Sinto que estou numa posição muito estranha
Odeio tanto as mudanças que a IA está trazendo para a experiência e a prática de escrever código que, se pudesse, preferiria fazer qualquer coisa que não envolvesse usar computador; ao mesmo tempo, também acho que essas ferramentas são muito poderosas e estão melhorando sem parar
O ponto do Mitchell faz sentido. Ferramentas assim podem introduzir fundações podres que talvez só sejam percebidas depois que a estrutura inteira desabar
Eu não quero estar na posição de ser responsável nessa hora sem compreender profundamente o codebase como antigamente
Mas humanos também vêm introduzindo bugs sutis e fatais no código há muito tempo
Então muita coisa ainda parece uma questão empírica em aberto
Vamos passar a ver muitos sistemas quebrando de formas horríveis que antes não existiam? Talvez alguns, sim
Ao mesmo tempo, será que vamos aprender que precisamos migrar mais para especificação e verificação? Não sei
De qualquer forma, essa forma de construir sistemas parece inevitável, mesmo que haja colisões no caminho
Também acho que existe uma espécie de psicose reacionária do lado anti-IA
Eu não queria me envolver com IA, mas também não posso negar minha experiência usando essas ferramentas
Queria que existissem mais espaços para esse tipo de discussão realista, porém negativa, sobre IA
Isso também é parte do motivo de o Mitchell ser um bom desenvolvedor