Charity Majors: IA pede mais disciplina de engenharia, não menos

Charity Majors não é uma cética de IA. A CTO da Honeycomb, empresa de observabilidade, emitiu um mandato interno de IA em agosto passado e passou 2026 defendendo que a tecnologia é real e chegou rápido. Por isso o ensaio que ela publicou em 27 de julho, primeiro no próprio blog e depois republicado no O'Reilly Radar, pesa tanto. O título já entrega a tese, que vai contra a moda: sistemas não determinísticos vão exigir mais disciplina de engenharia, não menos. Para quem coloca IA em produção, é a leitura mais útil do mês.

O que mudou em 2025, segundo ela

Majors é cirúrgica ao definir o que aconteceu. Não foi que a IA ficou mágica. Foi que a economia da produção de código virou de cabeça para baixo. Gerar código deixou de ser difícil, demorado e caro, e passou a ser instantâneo e praticamente gratuito. A linha de código, que era tesouro reutilizado, cuidado e curado, virou algo descartável e regenerável quase do dia para a noite.

Ela marca a virada com precisão: desde o Opus 4.5, em novembro passado, a IA gera código mais ou menos tão bom quanto o do engenheiro mediano, ao menos para padrões comuns, e muito mais rápido e barato. Quem achava que código de IA era e sempre seria lixo perdeu a discussão. E ela é dura com a própria tribo, a da confiabilidade: duvidar foi perdoável na primeira vez, menos na segunda.

O código como cache, não como ativo

O centro do argumento vem de uma ideia que ela credita a Chad Fowler, o engenheiro que cunhou o termo infraestrutura imutável em 2013. Fowler propõe pensar o código como aquilo que a computação já aprendeu com servidores: pare de consertar a coisa que roda, substitua ela. Quando reescrever é barato, editar no lugar vira risco, porque mutação acumula entropia e substituição zera a entropia.

Majors destaca a frase que fez a ficha cair para ela. O código, diz Fowler, é "uma visão materializada do entendimento, útil enquanto atual e descartável quando velha". Ou seja, o código nunca foi o produto. Ele era só o lugar onde o entendimento ficava guardado, porque produzir código era o gargalo. Tirado esse gargalo, fica exposto o que sempre importou: o entendimento do sistema e o comportamento em produção.

Só prod é prod. Teste em produção, ou viva uma mentira. A visão dela de SRE, aplicada à IA, dá o tom: produção não é o que acontece depois do desenvolvimento, produção é uma etapa do desenvolvimento.

Aqui entra a analogia que costura tudo. Majors viveu a passagem dos servidores artesanais, tratados como bichos de estimação, para a infraestrutura imutável tratada como gado. A lição foi que mutabilidade é a inimiga do entendimento: todo artefato editado no lugar cria drift, e drift é o que torna sistema impossível de manter. Na Honeycomb, ela conta, um nó do Kafka é morto por cron toda terça, e é justamente por conseguir regenerar tudo que eles confiam no sistema. Não conseguir regenerar o código do mesmo jeito, ela provoca, é sinal de que a gente não entende o próprio código.

Validar virou o gargalo, e o humano é o elo fraco

Se o código ficou barato, o trabalho difícil migrou para outro lugar: validar o que o sistema faz de fato, não o que deveria fazer. E aqui Majors é provocadora de propósito. Cérebro humano é ruim em validação. A tarefa é repetitiva, exige atenção a detalhes minúsculos e resistência ao tédio, exatamente onde a máquina ganha e a pessoa cansa. Apostar a defesa do valor humano em sermos o melhor portão de qualidade, para ela, é o pior argumento possível.

O papel humano está em outro lugar: encodar o entendimento no sistema, para que a IA possa usá-lo. Isso significa instrumentar com traces, escrever testes de comportamento e de caracterização, usar captura e replay de tráfego, rodar avaliação contínua em produção. Técnicas que, ela nota com ironia, vêm de operações e QA, duas áreas que a engenharia de software sempre tratou com esnobismo. O retorno desses investimentos, diz Majors, será grande e não linear.

Nossa leitura para quem opera IA no Brasil

O ensaio é sobre engenharia de software, mas serve como manual para qualquer time colocando IA em produção, inclusive fora do código.

Primeiro, pare de mirar a revisão no artefato errado. Revisar linha de código gerada por agente, uma a uma, é usar o humano onde ele é fraco. O que precisa de revisão humana é a decisão, o comportamento e o limite: o que o sistema faz com dado real, onde ele erra, o que é inaceitável falhar. Isso conversa direto com o Kent Beck dizendo que testar virou o superpoder do programador e com o Gergely Orosz apontando a verificação como o novo gargalo. Três vozes, o mesmo diagnóstico.

Segundo, observabilidade deixou de ser luxo de time grande. Se o sistema é não determinístico, você não sabe o que ele faz sem instrumentar. Colocar um agente em produção sem trace, sem eval e sem forma de ver o comportamento real é operar no escuro. O barato do código só compensa se o caro da validação estiver resolvido.

Terceiro, valor mora na durabilidade, não na descartabilidade. Majors lembra o óbvio que o hype esquece: ninguém quer acordar e achar os botões do sistema movidos de lugar, nem transação financeira que completa "na maioria das vezes". Determinismo não vai a lugar nenhum. A parte descartável é o código, não o comportamento que o usuário espera.

A frase que fecha o raciocínio dela vale colar na parede: disciplina primeiro, biscoito depois. Todo CEO quer os biscoitos da IA agora. O jeito de entregá-los sem quebrar produção é investir, antes, na disciplina de engenharia que a gente vinha adiando faz vinte anos.

Se o seu time está colocando agentes em produção e quer montar a camada de observabilidade e avaliação antes de o comportamento fugir do controle, fale com a AI Boutique no WhatsApp. A gente ajuda a instrumentar IA para produção, não para o PowerPoint.