Por que escrever código em 2026

• O papel do engenheiro de software se expandiu para além da produção de código, passando a incluir a construção e manutenção de uma fábrica de software, mas ainda é necessário lidar diretamente com código para entender e melhorar os sistemas
• Ao orientar agentes com prompts, AGENTS.md e bases de conhecimento, e proteger os resultados com testes, linting, sistemas de tipos e avaliações, até modelos de baixo desempenho conseguem produzir mudanças úteis o suficiente
• Codar diretamente permite pensar no ambiente de execução sem passar pelo inglês, fazendo sentir vulnerabilidades, testes fracos e exceções desnecessárias que uma revisão passiva de código pode facilmente deixar passar
• Agentes se parecem mais com estagiários recém-chegados do que com compiladores: seguem de forma conservadora o código existente e requisitos imprecisos, e podem ampliar até erros pontuais humanos por meio de wrappers e camadas indiretas
• Humanos precisam testar abordagens diretamente, estabelecer padrões e fazer os agentes repeti-los para manter senso de propriedade e capacidade de julgamento enquanto aproveitam a produtividade da automação

---

A fábrica de software onde agentes trabalham

• Engenheiros de software mantêm não só o software, mas também uma linha de montagem que permite que qualquer pessoa solicite mudanças via prompt e as coloque em produção imediatamente
  • Configuram proativamente a infraestrutura para que os agentes tenham sucesso, usando prompts, skills, AGENTS.md e bases de conhecimento
  • Protegem os resultados depois, com testes, linting, sistemas de tipos, avaliações e avaliação automatizada usando outras IAs
• Com restrições suficientes e contexto atualizado, até modelos menos inteligentes conseguem não sair do caminho e produzir mudanças utilizáveis, o que pode fazer parecer que humanos não precisam ler nem escrever código diretamente
• Porém, mesmo que existam agentes com inteligência no nível de Fable, codar diretamente ainda permite pensar diretamente no ambiente de execução, sem a camada intermediária do inglês
• Apenas ler passivamente diffs e patches criados por agentes dificulta criar uma conexão profunda com a arquitetura do sistema
  • Ao lidar diretamente com o código, é possível sentir o que quebra quando se adicionam funcionalidades por cima dele
  • Ao limpar o código e documentar princípios arquiteturais consistentes, sem várias exceções acopladas, a fábrica de software também passa a operar de forma mais estável
  • Ao encontrar e corrigir fraquezas na estratégia de testes durante a depuração, é possível bloquear uma classe inteira de novos bugs
• Codar diretamente não é a única forma de entender software, e não é preciso insistir em trabalho manual extremo como em agulhas magnetizadas e mãos firmes
  • Mesmo que a maior parte do código real seja gerada por IA, codar diretamente continua sendo uma ferramenta útil

Raciocínio e senso de propriedade preservados ao codar diretamente

• Ficar restrito ao papel de centauro reverso, apenas lendo e aprovando código, reduz a concentração e o senso de propriedade, facilita que código de baixa qualidade passe na revisão e dificulta ajustes finos
  • Quando não se presta atenção aos detalhes, vulnerabilidades se acumulam e, no longo prazo, código de baixa qualidade também prejudica os agentes
  • Se humanos testam a abordagem diretamente e depois fazem os agentes repetir padrões já estabelecidos, continuam participando do resultado e mantendo a propriedade sobre ele
• O inglês é uma linguagem com especificação insuficiente para representar computação com precisão
  • Em trabalhos algorítmicos, é preciso conceber e pensar em etapas executáveis
  • Dependendo da situação, pode-se ajustar a precisão necessária escolhendo uma linguagem de baixo nível, com amplo espaço de design, ou uma linguagem de alto nível, com um ambiente computacional mais restrito
• Tratar agentes de codificação como compiladores pode levar à atitude de que até código mal escrito pode ser colocado em produção
  • Agentes se parecem mais com estagiários recém-chegados do que com compiladores
  • Eles leem código existente, que pode ser incompleto e de baixa qualidade, e geram novas mudanças a partir de descrições imprecisas
  • Humanos não podem simplesmente transferir seu raciocínio e gosto a um grupo de estagiários; precisam se envolver diretamente em vez de permanecer como consumidores
• Agentes têm dificuldade de seguir espontaneamente a regra dos escoteiros, deixando o código em melhor estado do que encontraram, e também é pesado delegar isso a eles
  • Eles tendem a tornar a mudança atual o mais segura possível, preservando de forma conservadora decisões existentes
  • Em uma base de código, quando uma pessoa usou sem muita reflexão o armazenamento local do navegador para parte do estado, embora o restante fosse salvo em um banco de dados no backend, o agente tentou preservar essa decisão adicionando wrappers e camadas indiretas, fazendo o número de linhas de código crescer cerca de 3 vezes
  • Esse conservadorismo pode amplificar decisões pontuais equivocadas tomadas por humanos
• O processo de apagar código diretamente e explorar alternativas ajuda a chegar a uma arquitetura melhor do que apenas dar instruções em inglês
  • Quanto mais atenção se dá ao código, mais se fortalecem o raciocínio, o senso de autoria e a capacidade de conduzir a fábrica de software
• Em uma fábrica de software, os detalhes importam, dos padrões arquiteturais aos algoritmos e ao desempenho
  • Agentes aumentaram a necessidade de avaliações, medições e mecanismos de proteção, e incentivam a adicionar CI no início até em projetos pessoais, não como uma tarefa posterior
  • Com isso, o estado do desenvolvimento de software melhorou muito, mas toda linha de montagem ainda conserva pontos fracos
• Mesmo em uma fábrica de automóveis, às vezes é preciso desmontar a linha de montagem, mergulhar nos detalhes de um motor a combustão para obter uma melhoria de 10%, ou passar o dia inteiro observando testes de pastilhas de freio para descobrir por que um problema em campo não foi detectado antes
  • Também no software, para conectar detalhes e estrutura geral, não se deve traçar fronteiras arbitrárias sobre o que se pode manipular diretamente

[choijaekyu]

Porque não há valor de token :(

[GN⁺]

Opiniões no Hacker News

• Parece óbvio que, se você não consegue escrever código, também não consegue revisá-lo, mas há pessoas e empresas que dizem que basta o Claude escrever e o Codex revisar. Ainda assim, o motivo de pedirem o resultado em linguagens de alto nível como Python e Java, e não em assembly ou binários compilados, é que, no fim, humanos precisam conseguir ler o código.
  É contraditória a postura de querer que desenvolvedores leiam, depurem e raciocinem sobre código, mas não oferecer o treinamento para desenvolver justamente essa habilidade.

  • O motivo de não mandarem o Claude escrever assembly é que quase não há materiais de aprendizado sobre criar apps CRUD em assembly. Não gosto que LLMs tomem empregos, mas também é realidade que modelos de ponta são bons em tarefas repetidas e documentadas inúmeras vezes na internet; e também é fato que, nas últimas décadas, uma parte considerável do desenvolvimento de software foi a produção padronizada de apps CRUD.
    Fica a dúvida se o setor conseguirá continuar evoluindo entregando toda a criação aos LLMs.
  • O ato de escrever código é, em si, um ato de pensar; portanto, se você para de escrever código, também para de pensar. Mesmo que se diga que está pensando em um nível mais alto, o LLM também acabará sendo melhor até nesse projeto de alto nível, então a vantagem atual é apenas temporária.
  • No fim, parece uma diferença de modos de cognição. Para algumas pessoas, código é mais preciso e mais fácil de ler do que explicações em inglês; um desenvolvedor experiente entende o funcionamento só de bater o olho. Para outras, código é difícil de ler e linguagem natural é mais confortável.
    Isso não quer dizer que um lado seja melhor; pessoas que dão menos importância aos detalhes também podem liderar o mundo, e o nível de minúcia necessário pode variar conforme o problema.
  • Acho que Casey Muratori e Demetri Spanos trataram disso em um vídeo: o motivo de evitar binários tem menos a ver com confiança no LLM e mais com código de máquina e offsets diferentes em cada máquina, além da dificuldade de interpretar contexto. Assim como há uma diferença de compreensão entre o código C decompilado pelo Ghidra e o código-fonte C escrito por um desenvolvedor, linguagens de alto nível conseguem carregar a intenção do código.
    Compiladores ajudam o LLM a escrever código que de fato compila e executa; se ele emitir código de máquina diretamente, é bem possível que nem rode. Claro que, se a pessoa não consegue escrever código nenhum, revisar fica muito mais difícil.
  • Há quem realmente defenda que o Claude deveria emitir assembly ou binários diretamente. Só que isso provavelmente teria menos portabilidade do que uma linguagem de alto nível que pode ser compilada para assembly de várias máquinas.

• “Como a indústria chama uma especificação de projeto abrangente e precisa o bastante para gerar um programa? Ela chama de código” — CommitStrip
  Quando bem escrito, o núcleo do código deve expressar a lógica de negócio subjacente da forma mais simples possível. Talvez não seja necessário revisar todas as camadas de suporte, mas, se você não leu o código, é difícil dizer que entende completamente a lógica de negócio.

  • Link original
  • Em outro texto sobre esse assunto, também se recomendava usar código em vez de especificações. Tudo bem instruir o agente com código ou criar exemplos que ele deve seguir.
    https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
  • É por isso que precisamos de Lisp. Primeiro você cria uma linguagem de programação cujos elementos básicos são os elementos básicos da lógica de negócio; depois escreve, nessa nova linguagem, um programa simples que descreve o que o negócio faz.

• A pergunta importante é quem vai pagar pela escrita manual de código. Clientes pagam pela solução de problemas, não pela escrita ou geração do código em si; portanto, quem resolver com o menor custo e o menor atrito leva o negócio, e é difícil ignorar a vantagem de ferramentas de IA comprimirem cronogramas.
  Estou nessa indústria desde os anos 1990, e sempre houve muito desenvolvedor mediano produzindo resultados medianos. Há uma romantização excessiva do código feito à mão, mas bases de código reais tendiam a ficar difíceis de manter e cheias de bugs com o tempo; projetos mal executados também não são nenhuma novidade.

  • Na verdade, acho que escrever pessoalmente uma quantidade menor de código aumenta a produtividade. Passar um dia reestruturando manualmente a arquitetura pode poupar milhares de dólares em custo de tokens e semanas de dor de cabeça.
    Hoje é como tentar construir uma fábrica de software com as duas mãos amarradas.
  • Desenvolvedores medianos agora estão produzindo 10 vezes mais resultados medianos.
  • Espero que setores em que a qualidade do software é importante e regulada, como saúde, aviação e energia nuclear, continuem pagando pela escrita manual de código. Mas esse mercado é relativamente pequeno.

• Para se concentrar e entender, não basta observar um agente à distância e ler o código passivamente; é preciso vivenciar o código diretamente. No fim, isso significa que você precisa treinar seu próprio modelo mental.
  Ao programar, o inconsciente faz muitos julgamentos do tipo “isso parece certo”, e isso só se desenvolve com repetição e concentração profunda; revisão de código ou leitura de documentação têm limites. Com esse modelo mental formado, você consegue identificar imediatamente a causa só de ver uma mensagem de erro em uma falha de produção; já em código gerado, precisa procurar por muito tempo com pensamento consciente e lento.
  Para um LLM ser realmente útil, seria preciso poder presumir que ele assume toda a manutenção do código e funciona como uma biblioteca externa; caso contrário, os problemas inevitavelmente continuarão surgindo.

  • Humanos já tentaram fazer essa separação, e ela funcionou tão mal que até surgiu o termo pejorativo arquiteto de torre de marfim. Em sistemas reais, surgem projetos teóricos impossíveis de implementar; equipes de implementação ou LLMs contornam a arquitetura; e, enquanto arquitetos e implementadores discutem em desalinho, a velocidade de desenvolvimento cai muito.
  • Na área de observabilidade, se é difícil encontrar a causa apenas pelo comportamento dinâmico em execução, a visão seria tornar o sistema mais transparente e observável. Como pessoas podem mudar de função ou ir embora, a ideia de não depender do modelo mental de um indivíduo excepcional sempre foi um princípio válido.
    Ainda não sei qual lado está certo e continuo investigando.

• Mesmo em 2026, código gerado por IA ainda é péssimo. Seja no Fable, seja em um harness LeetCode customizado com Pi/opencode, os resultados são horríveis; se você não consegue distinguir a diferença de qualidade entre o seu código e o código da IA, tenho más notícias.

  • Meu código foi, ou ainda é, pior que o da IA, mas pelo menos sou pago por ele, então essas más notícias não importam muito.

• Eu deixei explicitamente nas regras que o agente deve seguir a regra do escoteiro: rodar profiling, verificar cobertura de código, fazer uma revisão crítica e escrever o relatório e as tarefas de acompanhamento. Os LLMs de ponta de hoje seguem essas regras muito melhor do que 90% das pessoas com quem trabalhei, e fico me perguntando se isso significa que é algo ruim

  • O agente hoje tende a tornar as mudanças o mais seguras possível. Uma vez, antes mesmo de tomar café, eu mandei sem pensar usar o armazenamento local do navegador; todo o restante do estado estava no banco de dados do backend, mas, para preservar essa decisão errada, ele adicionou wrappers e camadas indiretas e quase triplicou o número de linhas de código
    O agente é conservador, então pode amplificar erros pontuais de humanos. Há muitas formas de resolver isso, e cada pessoa pensa de um jeito; portanto, tanto a abordagem de não ler o código quanto a de ler e escrever diretamente podem funcionar, mas também há grandes benefícios na precisão do código que não passa por um LLM

• O motivo para eu mesmo escrever código é que, do contrário, o LLM cria código demais. É preciso entender completamente o problema e generalizá-lo para evitar que um “Hello World” venha com 10 mil linhas e 5 camadas de abstração
  Como LLMs são preditores de tokens, quanto mais problemas houver a resolver, mais tokens de código eles tendem a produzir

  • LLMs gostam de envolver o código de forma defensiva, em vez de pensar no conjunto de maneira integrada, e por isso tendem a deixá-lo inchado. Já desenvolvedores humanos conseguem seguir a regra do escoteiro, arrumando também o código ao redor enquanto trabalham
  • Peter Naur explicou, décadas atrás, que programar não é produzir mecanicamente código-fonte, especificações e documentação, mas uma atividade humana de construir uma teoria mental profunda sobre como cada parte do sistema se encaixa nos problemas do mundo real. O verdadeiro produto da programação é o modelo mental compartilhado pelos desenvolvedores
    Quem tem o problema a ser resolvido são humanos; se o problema não for entendido, pode surgir um problema X/Y, em que o LLM resolve algo sem relação com a necessidade real. LLMs abstraem melhor elementos não essenciais, como bibliotecas ou linguagens de alto nível, mas o núcleo do problema ainda precisa ser expresso formalmente
    O vibe coding, em que se adicionam restrições uma a uma até chegar ao resultado desejado, no fim também é uma programação frouxa e informal. É melhor deixar a periferia do problema para o LLM e escrever e entender diretamente o núcleo
  • 99% do meu trabalho é em C#, mas, graças aos LLMs, agora posso me autodenominar o programador de baixo nível que sempre quis ser, sem fazer nada
  • Pedi para configurar um projeto que rodasse em K8s, parecido com outros módulos da empresa, e o LLM acabou escrevendo até testes unitários para a implementação de Hello World
  • Dei a um modelo americano recente uma tarefa trivial de exibir informações do lado do cliente; ele alterou o código dos dois lados para que o servidor enviasse as informações ao cliente no handshake inicial, e isso até funcionou. Mas essas informações já estavam no cliente, então era uma tarefa que exigia mudar apenas uma linha no código do cliente
    Por fora, ele resolveu perfeitamente o pedido, mas o código era desnecessário e malfeito. Empresas que vendem tokens por uso têm incentivo econômico para criar soluções ao estilo Rube Goldberg, que resolvem o problema mais ou menos enquanto consomem o máximo de tokens; e não só na geração, mas também depois, quando se lida com uma massa enorme de código com novos bugs misturados, mais tokens são gastos
    É engraçado ver pessoas que zombavam de código copiado e colado agora se empolgando com código colado de qualquer jeito

• Olhando a evolução desde o ChatGPT 3.5, em novembro de 2022, até hoje, fico em dúvida se daqui a 4 anos ainda estaremos revisando código. Mesmo sem ser um extremista de IA, se o ritmo atual se mantiver, é bem possível que em 5 a 10 anos a engenharia de software e o desenvolvimento na forma atual desapareçam
  Talvez reste aos humanos apenas algo como design de UI, e todo o resto seja abstraído para a IA lidar com o trabalho real

  • Se fosse uma máquina que realiza desejos de uma só vez, uma única solicitação seria fácil de atender; mas software é o acúmulo de milhares de desejos, com decisões minuciosas em todos os cantos sobre querer isto e não querer aquilo. Na abordagem atual dos LLMs, humanos ainda precisam gerenciar todas essas decisões, mas no futuro talvez surja uma forma que hoje nem conseguimos imaginar
  • Parte-se do pressuposto de que o avanço continuará no mesmo ritmo, mas, ao que parece, já entramos em certa fase de estagnação. A cada aumento de tamanho dos modelos, o custo cresce de forma exponencial, e acho que já ficou bastante claro que o negócio de treinar modelos cada vez maiores não é lucrativo
  • Já detesto o futuro em que nem poderemos culpar diretamente os humanos incompetentes que criaram sites em que toda ação exige JavaScript e que nem conseguem lidar direito com alguém digitando em um campo. Se, por causa de executivos que valorizam aparência acima de funcionalidade e de materiais de treinamento cheios desse tipo de site, os LLMs passarem a produzir esse mesmo lixo em escala muito maior, acho que teremos uma crise existencial
    A web já é bagunçada o suficiente; pelo menos deixem a gente culpar humanos incompetentes enquanto a situação ainda é esta

• Independentemente da pressão por KPIs, escrevo código diretamente sempre que tenho oportunidade, e da IA espero algo como um autocomplete de código mais inteligente

• Eu escrevo código diretamente porque amo programar e isso me faz genuinamente feliz. Não há motivo para abandonar algo de que gosto

  • Há um encanto quase mágico em dar instruções ao computador e vê-lo processá-las bilhões de vezes mais rápido do que por qualquer outro meio
  • Entrei nessa área porque gosto de projetar programas e escrever código. Fiquei para trás no uso de IA e preciso aprender mais, mas nunca quero parar de programar com as próprias mãos
  • Se o que te faz feliz é programar e ainda receber por isso, a empresa pode deixar de pagar essa recompensa. Se você depende dessa renda para manter o visto, é muito provável que seja forçado a se adaptar à mudança e acabe abandonando a programação