Phillip Mortimer, Senior Staff Machine Learning Engineer da Carta, afirmou na QCon London que todo software gerado por IA já é write-only, não por notação obscura, mas pelo volume de código impossível de revisar por humanos. A palestra, publicada pelo InfoQ, defende testes detalhados, revisão automatizada e arquitetura autorregenerativa como resposta, com a criatividade assumindo o papel central do engenheiro de software.
O que é código write-only e por que a IA mudou o jogo
Phillip Mortimer abriu a apresentação com o J Incunabulum, um interpretador completo da linguagem J escrito em C numa única tarde de 1989 por Arthur Whitney, com modelo de objetos, gerenciamento de memória, parser, lexer e REPL. Denso e ilegível, o código ilustra o conceito definido por Eric S. Raymond: software tão arcano que não pode ser modificado nem compreendido por ninguém além do autor.
Outros exemplos citados foram APL, criada por Ken Iverson na IBM em 1962 e popular em instituições financeiras nos anos, e expressões regulares. Mortimer lembrou sua experiência de dez anos na Morgan Stanley programando em A+, derivada de APL criada pelo próprio Whitney, e citou a frase de Jamie Zawinski sobre regex: ao resolver um problema com expressões regulares, você passa a ter dois problemas.
Leia também
Meta lança Muse Glimmer, IA de código aberto para agentes pessoais
Dessa vivência, ele extraiu dois princípios para lidar com complexidade de densidade: os testes definem o comportamento e o código é descartável. É mais fácil reescrever do que depurar. E agora, argumenta, esses princípios valem para todo o software.
A virada veio com o anúncio do Claude Opus 4.6 pela Anthropic: o modelo desenvolveu sozinho um compilador C em Rust durante duas semanas, com 500 mil linhas adicionadas, 277 mil removidas e 4 mil commits. Nenhuma linha é ilegível, mas nenhum humano consegue revisar tudo. A complexidade agora é de volume, não de notação, e o resultado é o mesmo: código write-only.
Código write-only por volume é o software gerado por IA em velocidade maior do que qualquer humano consegue ler. A solução de Mortimer: avaliar métricas e saídas, como já se faz com modelos de ML, em vez de revisar linha por linha.
Como gerenciar o novo mundo write-only
Mas se os humanos não revisam mais o código, o que garante a qualidade? Mortimer propõe quatro práticas concretas, várias já em uso na Carta.
A primeira é escrever testes extremamente detalhados. No projeto do compilador da Anthropic, o pesquisador Nicholas Carlini reuniu o máximo de casos de teste de compiladores C e montou um harness que guiou o Claude durante as duas semanas de trabalho autônomo.
A segunda é automatizar a revisão: se o Claude escreve o código, o Claude revisa. Na Carta, isso funciona porque o modelo revisor recebe prompt, instruções e contexto diferentes do gerador. Um caso real: a revisão por IA detectou catastrophic backtracking numa regex, uma falha que poderia travar a aplicação e causar negação de serviço, exigindo 500 mil combinações para uma string de 20 caracteres.
A terceira prática é a arquitetura autorregenerativa: um agente de IA conectado à plataforma de observabilidade, como Datadog ou Sentry, agrega alertas e abre pull requests para corrigir os problemas mais comuns. Na Carta, o sistema já roda como uma Claude skill, ainda não totalmente autônomo.
A quarta é a automação de limpeza. O colega Eric Vogl criou a skill Feature Flag Reaper, que já removeu autonomamente mais de 400 feature flags e dezenas de milhares de linhas de código morto acumuladas pelo uso de trunk-based development.
Dica: Se você já usa agentes de codificação, comece pelo básico: testes de entrada e saída abrangentes e revisão automática com prompt separado. É o caminho mais curto para ganhar confiança em código gerado por IA.
Monolitos voltam e intenção se separa da implementação
Mortimer prevê o retorno dos monolitos. A IA funciona melhor quando toda a lógica de negócio está num só lugar, e chamadas a LLMs substituem modelos de ML de tarefa única implantados como serviços independentes. Na Carta, ele passou semanas colapsando a antiga arquitetura de inteligência de documentos da Accelex em um único serviço.
A complexidade de software sobe, mas a complexidade arquitetural desce. E a geração de código por linguagem natural completa o desacoplamento entre intenção e implementação que o C iniciou há 50 anos ao separar software de hardware. Na prática, isso torna desenvolvedores portáteis entre linguagens: Mortimer, que trabalhou com A+, C++ e Python, hoje toca Terraform e escreve UIs em React.
Info: A tese se conecta à discussão que o portal já cobriu sobre como agentes de IA com contexto e memória mudam o papel do desenvolvedor, e ao debate sobre engenharia de contexto como sucessora do prompt engineering.
Por que a criatividade passa a ser o trabalho do desenvolvedor
Se o software se escreve, se revisa e se cura sozinho, como apontou Jensen Huang ao dizer que inteligência virou commodity, o que sobra para o engenheiro? Na visão de Mortimer, a criatividade.
Ele citou Arthur Koestler, que definiu criação como a colisão inesperada de dois referenciais antes não relacionados, e William Bernbach, para quem uma ideia é apenas uma nova combinação de elementos antigos.
O mito do gênio solitário, porém, não resiste aos dados: o estudo de Lewis Terman, iniciado nos anos 1920 com 1.500 crianças superdotadas, ignorou no grupo rejeitado dois futuros ganhadores do Nobel de Física, William Shockley e Luis Alvarez.
Criatividade é iterativa. Os irmãos Wright trabalharam por mais de uma década antes de voar em 1903. Peter Steinberger publicou 43 projetos open-source antes do sucesso do OpenClaw. Arthur Whitney levou 30 anos do APL ao q, criando pelo caminho a KX Systems, a linguagem K e o banco kdb+, ainda usados no setor financeiro.
Para destravar a criatividade, Mortimer sugere vencer o cold start com protótipos gerados por IA e hackathons (na Carta, com Claude Code e n8n), abraçar restrições que delimitam o problema e trabalhar sozinho: pesquisas mostram que quatro pessoas gerando ideias individualmente produzem de 30% a 40% mais ideias do que um grupo em brainstorming.
Ele citou ainda o ensaio Maker's Schedule, Manager's Schedule, de Paul Graham, sobre blocos longos de trabalho profundo.
Atenção: Um participante alertou para o risco circular de deixar a IA escrever o código e também os testes. Mortimer reconheceu que a própria Anthropic admitiu no model card do Opus 4.6 passar a depender do modelo para testar a si mesmo, e considerou o ciclo inevitável. Avalie os limites antes de delegar a verificação por completo.
Do analógico ao digital: quando o write-only amplifica a criação
Mortimer traz paralelos históricos: a fotografia liberou a pintura para o impressionismo e a arte abstrata; o design paramétrico permitiu a Zaha Hadid criar a estação de metrô KAFD em Riade, aberta em 2024, com milhares de estruturas impossíveis de desenhar à mão; Beethoven compôs em modo write-only após perder a audição e produziu obras que anteciparam o jazz em mais de 100 anos.
Na avaliação do Mercado de TI, a tese interessa aos times brasileiros porque reposiciona o esforço de engenharia: menos revisão linha a linha, mais especificação, testes e observabilidade, um movimento alinhado ao que já se discute em governança de IA em tempo de execução e no uso de Claude e Cursor pela Datadog em migrações test-driven.
Mortimer encerrou com duas citações: Jay Dweck, ex-líder de tecnologia da Morgan Stanley, lembrava que se usa o verbo escrever em toda atividade criativa, de prosa a software; e Arthur Whitney, ao ser questionado sobre o que programar mais se parecia, respondeu com uma palavra: poesia. Se o software sempre foi um ato criativo, a era da IA tende a torná-lo ainda mais.
Fonte: Infoq
