- “Não ler o código” significa depender de especificações, testes, análise estática e sinais de produção em vez de revisão linha por linha, com possibilidade de escalar para revisão de código em áreas de risco específicas
- Os casos de Harness Engineering da OpenAI e do OpenClaw mostram uma abordagem focada em testes, observabilidade e infraestrutura de validação automática em vez do código em si
- Como resposta ao ceticismo sobre caixa-preta, segurança e acúmulo de bugs, o texto destaca o padrão histórico das camadas de abstração e a importância das ferramentas de validação automatizada
- A posição é equilibrada: não se trata de excluir totalmente a leitura de código, mas de reconhecer que segurança, proteção e decisões arquiteturais ainda exigem revisão direta
- O código está se tornando cada vez mais um detalhe de implementação, e vale apostar na trajetória em que camadas de especificação, arquitetura e validação emergem como os principais artefatos
O que “não ler o código” realmente significa
- A frase “eu não leio mais código”, de um texto anterior, provocou mais de 200 comentários acalorados no Hacker News
- O significado exato é que, para a maior parte do código de produto, a revisão linha por linha não é usada como método padrão de validação
- Especificações e testes, revisão seletiva do diff alterado e sinais de produção continuam sendo verificados, e em certas áreas de risco é possível escalar para leitura de código
- O motivo para não ler o código não é que ele seja menos importante, mas sim que, especialmente em ambientes de grande escala, a leitura linha por linha não é a forma mais eficaz de garantir correção
Casos que sustentam essa visão
-
Harness Engineering da OpenAI
- A OpenAI explicou no post do blog Harness Engineering que o papel central das equipes de engenharia de software está migrando da escrita de código para o desenho do ambiente, a especificação da intenção e a construção de loops de feedback
- Três engenheiros geraram 1 milhão de linhas de código usando apenas agentes Codex e construíram um produto utilizado por centenas de usuários internos
- Em vez de focar no código, o investimento foi concentrado no harness ao redor dele — documentação, regras de dependência, linters, infraestrutura de testes e sistemas de observabilidade
- Não houve investimento específico em revisão de código linha por linha
-
OpenClaw
- Criado por uma única pessoa, sem equipe, o OpenClaw se tornou um dos projetos open source de crescimento mais rápido dos últimos meses, alcançando mais de 100 mil estrelas no GitHub
- A estrutura opera com 5 a 10 agentes em paralelo, projetada e conduzida por um engenheiro experiente, não por um iniciante
- Na entrevista intitulada “Eu implanto código que não leio”, ele diz que investe fortemente em refatoração, arquitetura, testes e no harness em torno da codificação com IA
-
De Coder a Orchestrator
- Um engenheiro experiente que criou o ESLint e escreveu vários livros da O'Reilly afirma em um texto recente que o futuro da engenharia de software terá como centro não a escrita de código, mas a orquestração de agentes de IA
- As competências centrais estão migrando de sintaxe e implementação para projeto de arquitetura, redação de especificações e desenho de loops de feedback
Respostas ao ceticismo
-
Crítica da caixa-preta
- Em resposta à crítica de que “ninguém escolheria voluntariamente uma abordagem de caixa-preta”, o autor enfatiza que o resultado do código não é o código em si, mas o produto
- A analogia mais adequada não é a de um fotógrafo que não olha a foto, mas a de alguém que não inspeciona a estrutura interna da câmera que produz a imagem
- A prática de construir sistemas sobre camadas de abstração que não examinamos diretamente já é comum em várias áreas da engenharia, incluindo software
-
Preocupações com segurança
- Sobre o receio de que código gerado por IA possa conter backdoors, o argumento é que isso não é um problema de “todo ser humano precisa ler cada linha”, mas sim de tooling e sistemas de validação
- Análise estática, varredura de dependências e linters de segurança existem porque humanos também escrevem código vulnerável; a resposta é um sistema automatizado de validação mais forte, na mesma direção da abordagem centrada em harness
- Ainda assim, áreas especialmente sensíveis à segurança continuam exigindo revisão humana
-
O problema do acúmulo de bugs
- A crítica mais frequente é: “quando o código falha, o dinheiro das pessoas desaparece, aviões param e carros quebram. Leia o código”
- Segundo dados da CodeRabbit, código gerado por IA apresenta 1,7x mais defeitos na qualidade geral do software
- Mas há muitas formas de codificação com IA, e o desenvolvimento centrado em harness com especificações, testes hierárquicos e restrições arquiteturais é fundamentalmente diferente de simplesmente fazer vibe coding
- Uma abordagem sugerida em um comentário: confiar em especificações, testes e análise estática, manter mais de 85% de cobertura de testes, construir testing ladders com testes de integração que ampliam gradualmente o escopo, e expor erros cedo com benchmarking e dogfooding rigoroso
- A pergunta central não é “código de IA tem mais bugs em média?”, mas sim “dentro de um harness bem projetado, desenvolvendo na mesma velocidade, ele produz mais bugs do que as alternativas?”
- Greg Brockman, cofundador da OpenAI, também defende que os mesmos padrões aplicados ao código humano devem ser aplicados aqui
Como o sistema é montado na prática
- O autor escreve código há quase toda a carreira, em sistemas geralmente internos, mas dos quais usuários reais dependem
- Ele entende a forma e a estrutura do código, mas opta por não lê-lo diretamente
-
Workflow orientado por especificação
- Antes de o agente escrever código, ele primeiro elabora com a IA uma especificação muito concreta e detalhada
- A estrutura permite rastrear do spec do produto até o plano de execução por meio de IDs de requisitos
- Todas as tarefas do plano de execução incluem critérios de aceitação com método de validação explícito
- Testes automáticos são marcados como (TEST)
- Verificação visual como (BROWSER:DOM)
- (MANUAL) só é usado quando não há outro caminho; ainda assim, primeiro se tenta gerar verificações automáticas com curl ou bash
- Tarefas sem metadados de validação concretos são bloqueadas por uma skill de auditoria antes do início do trabalho
-
AI Coding Toolkit (harness)
- Um toolkit composto por prompts, skills, hooks e scripts restringe a forma de trabalho do agente, com mais de 35 skills, instruções estruturadas para agentes e uma infraestrutura de validação hierárquica
- As instruções para agentes são tratadas como infraestrutura
- O
AGENTS.md funciona como o conjunto principal de regras: mudanças conservadoras, preservação das interfaces existentes, adesão a TDD, proibição de adivinhação e de reescrever o histórico do git
- O
VISION.md define os limites estratégicos
- Um sistema de validação hierárquico é operado
- Ao final de cada etapa, uma skill de checkpoint executa gates em múltiplas camadas, incluindo type checking, linting, testes, build, mutation testing e security scan
- Quando ferramentas de navegador estão disponíveis, a verificação automatizada no browser também é executada
- O diff alterado é enviado para outro modelo de IA (Codex CLI) para uma revisão de segunda opinião
- A validação entre modelos compensa pontos cegos de um modelo único
- Há casos em que ele lê o código diretamente, mas apenas em situações excepcionais
- Quando todos os testes passam, mas o comportamento do produto parece estranho
- Quando é preciso tomar uma decisão arquitetural importante
- Ao depurar falhas que vários agentes não conseguiram resolver
- Mesmo nesses casos, o objetivo não é analisar o código em si, mas identificar que lacuna no harness permitiu o problema e evitar recorrência
Quando é preciso ler o código
- Em sistemas diretamente ligados à segurança, serviços sensíveis do ponto de vista de security e decisões arquiteturais importantes, engenharia de software é de fato engenharia; e, numa era de geração massiva de código, essa importância é ainda maior
- A analogia de "Children of the Magenta", no contexto da aviação, refere-se ao fenômeno de pilotos dependerem excessivamente da rota magenta exibida na tela de navegação
- A lição não é “não use piloto automático”, mas sim mantenha a capacidade de intervir quando necessário
- Quando algo dá errado, é preciso ser capaz de reduzir o nível de automação e voltar ao básico, mas exigir que todos os voos sejam sempre manuais seria ineficiente e mais arriscado
- O essencial é equilibrar o uso da automação sem perder a capacidade de intervenção
Aposte na trajetória
- Toda camada de abstração na computação enfrentou resistência ao surgir, e o caso de 1973, quando Dennis Ritchie e Ken Thompson reescreveram o Unix em C, é um exemplo representativo
- Na época, houve críticas de que isso deixaria o sistema mais lento, faria perder controle sobre o hardware e tornaria a manutenção mais difícil por causa da complexidade, mas a abstração de C permitiu expandir o Unix em um sistema operacional de alta portabilidade e enorme influência
- O padrão recorrente é que as pessoas com expertise na camada que está sendo abstraída enfatizam a importância de entendê-la; isso faz sentido em alguns cenários, mas, na maior parte do tempo, o trabalho tende a se deslocar para pensar e projetar em camadas mais altas de abstração
- Escolher não ler o código não é declarar que as ferramentas são perfeitas, mas reconhecer que em muitos casos de uso isso já é suficientemente válido e está melhorando rapidamente
- O código não está desaparecendo; ele está se tornando cada vez mais um detalhe de implementação, enquanto especificações, arquitetura e camadas de validação emergem como os principais artefatos
3 comentários
Parece que a programação com IA está mais próxima de externalização/terceirização do que de abstração ou automação.
E dá a impressão de que projeto e verificação estão sendo introduzidos não tanto como elementos para sofisticação e precisão, mas como algo parecido com regulamentações que mal conseguem manter de pé uma sociedade de baixa confiança.
É uma análise precisa.
Parece importante o fato de que a programação com IA é fundamentalmente probabilística.
Estou criando uma biblioteca com IA, e parece que também vou ter que usar IA para refatoração, aumento da qualidade do código e checagem de falhas.