Usando IA para escrever código melhor, mais devagar

• Codificação com IA pode ser usada não só para gerar rapidamente grandes volumes de código de baixa qualidade, mas também para revisar PRs em profundidade e produzir código de alta qualidade mais lentamente
• Agentes com LLM são fortes em detecção de bugs em codebases, mas a dificuldade real está em priorizar e validar os problemas encontrados
• Uma skill do Claude que usa vários modelos combina Claude sub-agent, Codex e Cursor Bugbot para revisar PRs e produzir um relatório final com menos falsos positivos
• O fluxo de trabalho repete correções de problemas critical/high, pula itens cujo custo-benefício é baixo e abandona o PR se houver muitos problemas críticos
• Essa abordagem prioriza a saúde da codebase acima da velocidade e reforça uma programação cuidadosa, com compreensão dos modos de falha e dos bugs já existentes

---

Uma forma mais lenta de programar com IA

• A visão de que a codificação com IA serve apenas para gerar rapidamente grandes volumes de código de baixa qualidade subestima a flexibilidade dos LLMs
• LLMs podem ser usados com eficiência não só para geração rápida de código, mas também para escrever código de maior qualidade mais lentamente
• Ao contrário de abordagens como slop cannons, que despejam PRs grandes e não verificados, também é possível adotar um método que revisa PRs com mais profundidade e verifica obsessivamente possibilidades de falha

Validação e priorização importam mais do que detectar bugs

• Mythos mostra que agentes com LLM conseguem encontrar bugs muito bem em codebases
• Em outro caso, modelos que não são o Mythos também conseguem encontrar muitos bugs em codebases não revisadas
• Os modelos públicos mais recentes da Anthropic e da OpenAI diferem na capacidade de detectar bugs sutis e evitar falsos positivos, mas conseguem encontrar bugs em quantidade suficiente
• A dificuldade real está menos em descobrir bugs e mais em priorização e validação

Uma skill do Claude para revisar PRs com vários modelos

• Uma abordagem de code review com IA que compara e coloca modelos para debater foca na ideia de que, quanto mais modelos diferentes forem usados, menor a chance de alucinações ou relatórios de bugs incorretos
• A skill do Claude em uso executa Claude sub-agent, Codex e Cursor Bugbot para revisar PRs
• Cada ferramenta classifica os bugs do PR como critical/high/medium/low e, depois, os resultados são consolidados em um relatório final que remove falsos positivos
• O escopo de “bug” pode ser ampliado de acordo com os critérios do projeto
  • violações dos princípios KISS e DRY
  • se o HTML/JSX foi escrito com acessibilidade em mente
  • se queries SQL usam índices apropriados
  • outros critérios de qualidade específicos do projeto

Fluxo de trabalho real e critérios de decisão

• Essa abordagem consegue encontrar muitos bugs em PRs e também reduzir a taxa de falsos positivos para algo próximo de zero
• Os problemas encontrados vão desde bugs críticos ligados à segurança e à correção até questões de performance e problemas de baixa gravidade, no nível de “o comentário induz ao erro”

• Fluxo de tratamento típico

  • problemas classificados como critical e high são corrigidos pelo agente, mas a solução adequada é orientada por uma pessoa
  • o processo se repete até que não existam mais itens critical/high
  • problemas high/medium com baixo retorno em relação ao custo da correção são ignorados
  • um caso típico é quando seriam necessárias 100 linhas de código para corrigir um edge case muito estreito
  • se houver problemas critical demais e a abordagem geral parecer errada, o PR é abandonado

Foco na saúde da codebase, não na produtividade

• Essa técnica não necessariamente aumenta a velocidade de desenvolvimento
• Durante a revisão, podem ser descobertos bugs já existentes antes mesmo do PR, o que pode levar à escrita de testes unitários e à correção de falhas sutis
• Isso é quase o oposto do estilo de desenvolvimento de “produtividade 10x” normalmente associado a “vibe coding”
• Em arquiteturas complexas, os modos de falha podem ser mais interessantes do que o caminho feliz, e entender e corrigir esses pontos de falha pode ser uma forma de aprender melhor a codebase
• É útil para melhorar a saúde da codebase como um todo enquanto se aprende sobre áreas menos conhecidas dela

Práticas para um vibe coding mais lento

• Se você é um desenvolvedor que usa agentes para criar PRs de centenas de linhas que nem você mesmo entende completamente, vale tentar uma abordagem mais lenta
• Você pode perguntar ao agente como o PR funciona e onde ele pode falhar
• Se necessário, pode pedir que ele escreva um documento em Markdown com Mermaid charts
• Você pode usar a skill /grill-me, de Matt Pocock, até entender o PR do começo ao fim
• A “produtividade” medida em linhas de código pode não aumentar, e você pode acabar gastando muitos tokens para concluir que o plano inicial estava errado
• Essa abordagem é mais próxima de uma versão potencializada da programação cuidadosa, sistemática e obcecada por qualidade que já era valorizada antes dos LLMs

[GN⁺]

Comentários no Lobste.rs

• No meu trabalho, já desistimos do sonho de avançar mais rápido com IA. No nosso caso, programação não é o gargalo
  Ainda assim, a parte boa dos agentes de código é que eles me permitem trabalhar como o engenheiro que eu sempre quis ser
  Por exemplo, criar um harness de testes decente que permita forçar um pouco mais o código, adicionar uma etapa de CI que verifique se o código gerado corresponde ao original e monitorar direito a implantação das mudanças
  Antes, isso seria algo inviável no cronograma, porque eu teria que ler o manual do GitLab CI, aprender a acertar as condições e entender o jeito enrolado da nossa empresa de fazer as coisas; agora isso se tornou possível, e acho que esse é o futuro

• Tenho tido bastante sucesso usando LLM como um parceiro de spike que conhece a API ou como um dispositivo de refatoração mecânica, especialmente em linguagens com tipagem forte. Também é bom para escrever testes, mas é preciso ter um processo em várias camadas para verificar se esses testes realmente impõem restrições
  Testes de mutação ajudaram bastante, e, como o texto original sugere, também são necessárias várias rodadas de revisão
  Eu era muito mais negativo em relação a LLM antes, e olhando para trás até de forma irracional, mas isso era principalmente por causa do software de baixa qualidade que elas despejavam
  Quando fui investigar por conta própria, percebi que o jeito certo era tratá-las como uma ferramenta de prototipagem de papelão e como alguém que digita muito mais rápido. Por exemplo, se eu disser “encontre este padrão em todos os teoremas deste projeto em Lean, troque por aquele padrão e marque os lugares em que não funcionar de imediato, me dando a lista do que restou”, ela corrige mais de 100 teoremas em blocos no tempo que eu levaria para fazer uma ou duas primeiras tentativas misturando vim, sed, awk e gambiarras
  Em Lean isso é especialmente bom porque, pelas características da linguagem e pelo tipo de trabalho que faço, a distância entre “compila” e “funciona” é pequena; em Rust, com uma boa suíte de testes e testes de mutação, sinto algo parecido
  Acho que a cauda longa dessas ferramentas não é “aperte um botão e sai um produto”, mas sim bons engenheiros adotando isso para concentrar energia no que importa e delegar à máquina boa parte das tarefas chatas de antes

  • Eu também via LLM de forma bem negativa no começo, mas agora acho que elas melhoraram a ponto de ajudar mais do que atrapalhar
    O exemplo é interessante: quando eu trabalhava numa equipe de framework JavaScript, eu mesmo escrevia codemods para lidar com coisas como upgrades ou migrações. Era um trabalho penoso de mexer em AST
    Hoje em dia, acho que daria para deixar isso com uma LLM e chegar em algo como 90%

• Gosto dessa perspectiva. Parece óbvio que a ferramenta é flexível e não precisa necessariamente produzir resultados ruins, mas tanto quem é a favor quanto quem rejeita costuma ignorar esse ponto
  Ainda não experimentei fazer revisão de código com LLM, mas acho que vou colocar isso na minha lista. Até agora, usei mais para gerar ideias e para pedir ajuda com SQL ou VimScript, e escrevo o código eu mesmo
  Um risco é que revisão de código também é uma habilidade, então depender demais do modelo pode atrofiar essa capacidade. Por outro lado, em ambiente comercial, até a melhor revisão de código normalmente é uma combinação de “tempo razoável” com “eu confio nessa pessoa?”, e não algo próximo de precisão matemática

  • Isso também é verdade, mas senti que esse fluxo de trabalho na verdade aumentou minha capacidade de revisar código. Isso porque eu preciso avaliar se o “bug” é realmente possível ou apenas teórico, se vale a pena corrigir e se deve ficar para o próximo PR
    Bugs complexos eu prefiro pensar até o fim por conta própria, porque 1) alucinações ainda aparecem, e 2) de qualquer forma vale a pena entender o sistema de ponta a ponta

• Falando em meta, não entendo as flags neste post. Uma de fora de tópico e três de spam é estranho
  O post no topo da primeira página também é sobre uso de LLM e, por ser sobre escrita em geral, parece até menos relacionado ao tema do que este aqui, que é focado em programação, mas aparentemente não recebeu flags

  • Acho que provavelmente estão marcando como spam por verem isso como autopromoção

• É revigorante ver essa perspectiva no Lobsters. O sentimento anti-IA generalizado está ficando cansativo. Acho que todo mundo consegue concordar que ninguém gosta de resultados de baixa qualidade
  Mas as pessoas que adotaram uma postura dogmática de boicote total à IA vão ter mais dificuldade de aceitar o futuro do que quem escolheu uma postura mais pragmática
  Eu digo desde o começo que a IA é parecida com a invenção das ferramentas elétricas. Se você quiser trocar um pneu com uma chave manual, tudo bem, mas os mecânicos não boicotaram a furadeira de impacto quando ela apareceu. Não é a melhor analogia no contexto do texto, mas ainda acho válida
  Aprendi mais usando IA do que lendo documentação, porque na documentação você não pode fazer perguntas quando precisa de mais contexto, explicação ou exemplos. Você pode até dizer “construa algo, sem errar”, mas eu prefiro uma abordagem mais lenta para realmente aprender

  • Não vi esse sentimento anti-IA generalizado aqui. Pode mandar alguns exemplos?
    O que eu vi foram críticas a mudanças feitas por LLM em milhões de linhas de código de uma vez e implantadas sem revisão humana. Mais especificamente, casos como a thread sobre o porte do Bun de Zig para Rust
    Este post também está criticando isso