Seu trabalho é entregar código comprovadamente funcional

• Em ambientes de desenvolvimento assistidos por IA, está aumentando o número de casos em que engenheiros inexperientes enviam PRs grandes e não verificados
• A missão central do desenvolvedor não é simplesmente escrever código, mas entregar código com funcionamento comprovado
• Para isso, é obrigatório passar por duas etapas: teste manual e teste automatizado
• Agentes de programação também devem ser configurados para verificar por conta própria as alterações que produzem
• No fim, a responsabilidade é do desenvolvedor humano, e só o código acompanhado de evidências de verificação tem valor real

---

O problema de enviar código não verificado

• É mencionado o caso de engenheiros juniores que usam ferramentas com LLM para enviar PRs enormes e não verificados, confiando no code review
  • Isso é apontado como grosseiro, ineficiente e uma forma de abdicar da responsabilidade como desenvolvedor
• O papel do engenheiro de software não é simplesmente produzir código, mas entregar código com funcionamento comprovado
  • Código não verificado é visto como uma forma de transferir a carga para quem revisa

As duas etapas para provar que o código funciona

• A primeira etapa é o teste manual, em que é preciso confirmar diretamente que o código funciona corretamente
  • É necessário configurar o sistema em seu estado inicial, aplicar a mudança e então verificar o resultado
  • É possível comprovar isso anexando comandos de terminal e seus resultados em comentários do code review ou por meio de uma gravação de tela
  • Depois de confirmar o funcionamento normal, também é preciso procurar problemas por meio de testes de casos extremos
• A segunda etapa é o teste automatizado, destacado como procedimento essencial graças ao avanço das ferramentas com LLM
  • As mudanças devem vir acompanhadas de testes automatizados, e os testes devem falhar se a implementação for revertida
  • Escrever testes segue o mesmo procedimento do teste manual, e a capacidade de integrar com o test harness é importante
  • Considerar que apenas testes automatizados bastam e pular o teste manual é apontado como uma abordagem equivocada

O papel dos agentes de programação e a verificação

• Uma das principais tendências no campo de LLM em 2025 é o crescimento acelerado dos agentes de programação, com Claude Code e Codex CLI entre os principais exemplos
  • Eles conseguem executar código e corrigir problemas por conta própria
• Agentes de programação também precisam comprovar suas próprias alterações e devem realizar testes manuais e automatizados
  • No caso de ferramentas de CLI, é possível treiná-los para executar isso diretamente ou automatizar com sistemas como o CLIRunner do Click
  • Em mudanças de CSS, também é possível configurá-los para verificar o resultado por meio de captura de screenshots
• Se o projeto já tiver testes existentes, o agente pode expandi-los ou reutilizar padrões
  • A estrutura e a qualidade do código de teste afetam diretamente a qualidade dos testes gerados pelo agente
  • O senso estético para código de teste é citado como uma competência central que distingue engenheiros seniores

A responsabilidade humana e o valor do código

• Computadores não podem ser responsabilizados, então esse papel precisa ser assumido por humanos
  • Não há mais valor real em deixar que um LLM gere patches enormes
• O verdadeiro valor está em entregar código com funcionamento comprovado
  • Ao enviar um PR, é indispensável incluir evidências de que o código funciona corretamente

[ethanhur]

Concordo muito. No modelo atual de código via PR, a responsabilidade acaba sendo transferida para os mantenedores e revisores. Não há desvantagem para quem envia código gerado por LLM sem revisá-lo.

Ao contribuir para o codebase do Google, parece que eles medem algo como o crédito do contributor; acho que outros projetos open source e empresas também vão adotar algo assim. Tenho a impressão de que a confiança vai se tornar um ativo ainda mais importante.

[roxie]

Ah, então o Google usa esse conceito.

[tested]

> Vibe Engineering

[GN⁺]

Comentários do Hacker News

• Ultimamente tenho visto com frequência uma anedota deprimente: um engenheiro júnior fortalecido por ferramentas de LLM joga um PR enorme e não testado para colegas ou mantenedores de open source, esperando que o code review resolva o resto. Pior ainda é que esse comportamento aparece não só em juniores, mas também em desenvolvedores seniores

  • Ontem e hoje eu fiz exatamente isso. Nosso time recebeu um bug report e concluiu que era um problema de um fornecedor externo. Mas o fornecedor devolveu dizendo que o problema era do nosso lado. Então pedi ao Codex para investigar, ele encontrou o problema e preparou um PR. Eu não revisei nem testei pessoalmente e deixei a validação para o time. O processo ajudou a treinar a equipe a usar LLMs como ferramenta de trabalho
  • Nos últimos dois dias, dois membros não desenvolvedores do time perguntaram a agentes de IA como corrigir bugs mobile e simplesmente colocaram essas respostas como conteúdo principal dos tickets. No fim, eu tive que ler tudo e redescobrir quais eram os requisitos reais
  • Muita gente com o título de “sênior” age como júnior. Acho que isso acontece porque hoje em dia basta ter dois anos desde a graduação para já ser chamado de sênior
  • Os desenvolvedores mais perigosos são os que ignoram ou contornam regras. Isso me lembra os desenvolvedores 10x que conheci antes. Quando ignoram as regras e só despejam funcionalidades, no fim outras pessoas precisam limpar a bagunça
  • Durante o code review, fico me perguntando onde está o desenvolvedor júnior. Se ele não participa da revisão, é difícil que sinta responsabilidade pela qualidade do próprio código

• Saber escrever um bom PR vale não só para código gerado por IA, mas para qualquer caso. Quando escrevo a descrição de um PR, organizo na ordem: como funciona hoje, por que a mudança é necessária e o que foi alterado. Também incluo como testar, screenshots e até os comandos de teste E2E, para reduzir a carga do revisor. Isso ajuda até em colaboração assíncrona ou em times com fusos diferentes

  • Antes de pedir review, eu mesmo faço mais uma revisão. Resolver antecipadamente pequenos typos ou remover logs poupa tempo do revisor. O review do Copilot também pega bem esse tipo de detalhe
  • Mesmo escrevendo descrições detalhadas, muitas vezes ninguém lê. Ainda assim continuo escrevendo por senso de responsabilidade
  • Seja um PR com ajuda de IA ou não, ele deve incluir evidências de teste e validação
  • Antigamente eu escrevia explicações longas, mas percebi que ninguém lia. Resumir o essencial em bullet points era mais eficaz
  • O template de PR do nosso time inclui número do ticket, descrição da solicitação, estado atual, estado depois da mudança e até um “mood gif”

• A essência do engenheiro é entender requisitos, convertê-los em fluxo lógico, equilibrar trade-offs e responder pelo resultado. Gerar código ou enviar PRs aleatórios é sintoma da falta desses fundamentos. Os agentes de código, na verdade, estão servindo para relembrar qual é a essência da engenharia

  • Neste texto, há um caso em que uma linha de código causou prejuízo de 60 milhões de dólares. Um PR de 10 mil linhas gerado por IA sem entendimento do código é um desastre em potencial
  • Na prática, empresas dão mais importância a marketing e rentabilidade do que à qualidade. Produtos com selo “premium” vendem melhor do que produtos realmente de alta qualidade. No fim, “o que vende” vem antes da engenharia
  • Mas o problema é que, quando a organização pressiona dizendo “use IA e entregue a funcionalidade em três dias, ou terá reunião com o RH”, fica difícil seguir princípios ideais de engenharia

• Testes são necessários, mas não suficientes. É preciso validar o código logicamente. Testes apenas demonstram o funcionamento correto para entradas e ambientes específicos

  • Eu penso da mesma forma. Mesmo código que funciona bem ainda pode ser péssimo
  • Em vez de “provar”, a palavra “demonstrar” parece mais adequada. Testes são apenas evidência em casos específicos
  • Em vez de confiar só em testes, tento quebrar o app de várias maneiras por conta própria. Nesse processo, acabo melhorando o código
  • Como a maior parte do código não pode ser formalmente provada, abordagens como property-based testing parecem úteis
  • Mesmo atingindo 100% de cobertura de testes, não adianta se o código não for robusto

• Eu não testo por obrigação. Faço isso simplesmente porque quero ver o código funcionando de verdade. Se ver o código rodando não te empolga, talvez essa profissão não seja para você

• Ouvi falar que, graças aos LLMs, juniores estão jogando PRs gigantes, mas na nossa organização isso ainda não acontece

  • Não são PRs gigantes, mas vejo com frequência código gerado por LLM que o desenvolvedor não entende
  • Na nossa organização também há casos assim. Os problemas são os seguintes
    • o agente reverte feedback anterior
    • não segue os padrões da codebase
    • reinventa soluções já existentes
    • responde ao feedback do PR com saída do agente
    • envia um PR de 50 mil linhas para algo que exigiria 10~20 linhas
    • faltam testes e o tratamento de erros é fraco
  • As pessoas que já enviavam PRs de baixa qualidade antes só estão enviando isso mais rápido graças aos LLMs
  • Em WireGuard Android PR #82 e #80, dá para ver respostas copiadas e coladas da IA que ficaram lá intactas. Se olhar a aba “files changed”, é confuso
  • Um amigo trabalha numa startup de 11 pessoas, e o CTO dá push direto na main de madrugada com 10 mil linhas de código. Na fase de exploração isso pode até passar, mas na fase de estabilização é um risco terrível

• Não concordo com a frase “seu trabalho é entregar código em estado comprovado”. O trabalho real é resolver problemas de negócio. Claro, na maioria dos casos isso leva a código, mas a distinção é importante

  • Mas provar a correção do código faz parte de resolver problemas de negócio. Não é algo separado
  • Não dá para resolver um problema de negócio entregando código que não atende aos requisitos
  • O importante é resolver o problema sem criar novos. Por isso segurança e estabilidade são necessárias
  • Talvez por eu ainda ter pouca experiência, não consigo entender como alguém resolveria um problema com código não validado
  • No fim, toda profissão existe para resolver problemas. Nós apenas fazemos isso por meio de computadores

• Em um emprego anterior, trabalhei num fabricante japonês de hardware de alta qualidade, e quando o departamento de QA encontrava um bug, o lançamento do produto era interrompido. Por isso, cada departamento de desenvolvimento criou seu próprio time de QC para reforçar os testes prévios. Como resultado, o software era validado com muito rigor

  • Fiquei curioso sobre o significado de “get dinged”. Uma estrutura dessas também pode acabar fazendo as pessoas terem medo de mudar qualquer coisa

• Hoje em dia, a essência do trabalho virou fechar tickets. Como qualidade de código não aparece nas métricas, ela deixa de importar. Eu não participo desse tipo de sistema. O artesanato acabou; agora todo mundo quer compensado barato e cola

  • No momento em que se adota LLM em tudo e se espera que todos usem, engenharia de software deixa de ser uma engenharia séria
  • Também há quem responda a esse tipo de crítica perguntando: “então você vive de subsídio do governo?”

• O problema é o que significa “código comprovado”. Há casos em que a pessoa anexa testes feitos por LLM e envia um PR gigantesco. Eu também faço vibe coding em projetos pessoais, mas fazer isso em nível de equipe é um mau hábito. A razão de contratar engenheiros é comprar sua especialização

  • Por isso eu enfatizo testes manuais. Mostrar o funcionamento real com screenshots ou vídeo já pode gerar muita confiança