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 do Hacker News

• Trabalhar com IA agora deixou de ser um processo simples de uma passada só e virou um longo loop de revisão de ida e volta
  Para recursos de porte médio que atravessam várias áreas, primeiro monto o desenho de implementação com IA e reviso os detalhes, depois implemento com o Claude 4.7 Max, que é lento, mas entrega bons resultados
  Depois reviso a implementação e peço uma nova revisão ao Codex GPT 5.5 xhigh fast, que quase sempre encontra casos de borda. Deixo o Claude fazer as correções, porque o Codex é forte em encontrar bugs e revisar, mas tende a superprojetar o código ou misturar atalhos, enquanto o Claude escreve código mais intuitivo e fácil de manter
  Em seguida, faço uma nova revisão das mudanças staged com uma instância nova de Claude/Codex, incorporo o feedback e ainda adiciono testes. Ainda é mais rápido do que escrever tudo manualmente, mas a maior parte do tempo vai para revisão e tratamento de casos de borda, e no fim a funcionalidade v1 já parece uma implementação tipo v3, iterada várias vezes

  • Funciona bem para mim passar um tempão discutindo o problema com a IA antes de implementar
    Dá uma sensação de produtividade, os resultados da IA melhoram, e em geral eu continuo entendendo o código. Depois de passar o dia inteiro debatendo design e arquitetura com o robô, sinto que esse é justamente o ponto em que a revolução da IA me tornou um engenheiro melhor
  • Acho que é exatamente isso. Muita gente tenta fazer a IA resolver tarefas complexas de uma vez só e depois se surpreende porque ela age como um júnior apressado
    O meu processo é fazer 5 rodadas de pesquisa/planejamento/plano de testes, e eu entro no loop em cada decisão importante. Começo pelo formato geral e desço para os detalhes; só o planejamento pode levar de 2 a 3 dias do meu tempo, e o agente de implementação (Opus 4.7) pode levar várias horas
    A implementação é dividida em várias etapas/commits, e em cada etapa há um loop de ajustes após code review. A revisão final profunda também pode levar de 1 a 2 horas; quando abro o PR, o Gemini revisa e eu leio o resultado para resolver os pontos
    O projeto ainda leva dias ou semanas, mas é 5 vezes mais rápido do que fazer tudo sozinho
    Extra: essa skill está em https://github.com/scosman/vibe-crafting
  • Meu fluxo ao programar com IA também é bem parecido, mas mesmo quando dá certo muitas vezes leva quase o mesmo tempo que escrever eu mesmo
    Em alguns casos joguei fora o que a IA fez e simplesmente fiz direto. Acho que isso é uma habilidade que as pessoas precisam aprender. Em algum momento você precisa saber a hora de parar. Já vi colegas ficarem discutindo sem parar com o LLM para tentar fazer ele realizar mudanças simples
  • Abordagem parecida, mas eu ainda configuro antes a arquitetura manual básica/contratos de alto nível/stubs para manter consistência com os outros sistemas e deixar tudo mais legível
  • E quando a Anthropic cai, você só pega um café e espera?
    Em troca de um pequeno ganho de velocidade por ficar pastoreando várias IAs, você não perde conhecimento e controle sobre o que a IA fez?

• O texto sobre fazer LLMs criticarem os code reviews umas das outras[1], a ferramenta magpie[2] e o post recente da Cloudflare sobre sua stack de code review[3] são bem convincentes
  Sou cético em relação à IA, mas mais por “isso faz bem para o mundo?” do que por “isso funciona?”. Esse tipo de trabalho de revisão parece ser um caso raro que não terceiriza o pensamento nem reduz a capacidade dos trabalhadores. Não me soa o mesmo alarme de deixar a IA escrever código, ou deixar a IA corrigir problemas que a própria IA encontrou. Claro, as questões ambientais e outras preocupações éticas ainda continuam muito fortes
  Fiquei impressionado com a qualidade recente dos code reviews com IA, mas a experiência de interagir separadamente com 3 revisores de IA em PRs do GitHub é horrível. Seria ótimo ter rodadas de revisão mais locais e que entendessem jj/rebase
  Contexto: backend grande em PHP/Laravel e frontend em Vue
  [1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
  [2]: https://github.com/liliu-z/magpie
  [3]: https://blog.cloudflare.com/ai-code-review/

• Em média, o tempo gasto nesses loops de revisão/correção com LLM é maior do que escrever código manualmente
  Em parte porque, quando entro no fluxo, escrevo código muito rápido e às vezes ele sai mais depressa do que eu esperava. E também porque o código que o LLM entrega nas primeiras tentativas geralmente é bem ruim
  Mesmo assim, o interessante é que, ao revisar eu mesmo e mandar várias rodadas de revisão e correção, em média o resultado acaba tendo qualidade mais alta do que o código que eu teria escrito no mesmo tempo. Ver o código de outra “pessoa” passar por várias iterações parece me fazer entender de forma mais ampla o objetivo que quero atingir, em vez de só aceitar o que saiu de um estado de imersão

  • Se a IA escreve código ruim, então você precisa trocar de IA. As IAs avançadas de hoje não deveriam produzir código ruim

• Este texto não fala de escrever código com IA, e sim só de code review
  O problema que encontro na programação agentic é que, enquanto programo, tomo inúmeras decisões microarquiteturais. Quase nunca existe uma especificação completa desde o começo; eu vou construindo a especificação enquanto escrevo
  Quando uso Claude Code ou Codex, esse processo desaparece. O Claude Code é empenhado demais em chegar ao destino, então a experiência de programar junto com ele parece um sonho febril. No fim, minha confiança sobre casos de borda ou sobre o quanto aquilo se encaixa nos objetivos de arquitetura/design do projeto diminui
  Além disso, eu gosto de programar, fazer engenharia reversa etc. O LLM até pode resolver um problema ou entregar uma funcionalidade, mas parece que tira a graça. Estou tentando encontrar um fluxo em que eu consiga usar isso com confiança, mas temo que no fim esse fluxo se resuma a chat, busca e ao papel de rubber duck para as minhas ideias

• Por outro lado, algumas empresas defendem que os engenheiros devem tornar robustos pipelines de agentes autoavaliadores com feedback humano no loop, para que os agentes escrevam a maior parte do código de produção
  O CEO da Creao disse em janeiro deste ano que re-arquitetou todo o sistema de produção em 2 semanas. Também afirmou que os agentes implementaram funcionalidades demais, rápido demais, a ponto de ter que esperar a área de desenvolvimento de negócios acompanhar
  Fico curioso sobre como avaliar a opção de aumentar a produção em 100x com IA versus a opção de desenvolver sua própria habilidade com IA
  Ao mesmo tempo, o ganho de produtividade com IA é real. Por exemplo, uma organização de engenharia da Snowflake atingiu antecipadamente todos os OKRs no primeiro trimestre pela primeira vez na história da empresa. Normalmente, atingir 70% dos OKRs planejados já era considerado um bom resultado, então dá para imaginar o estresse que os engenheiros sentiriam ao ver esse tipo de resultado

• O título deste texto parecia prometer mais profundidade, e eu esperava ver exemplos de código reais
  Mas é parecido com outros textos de opinião. Basicamente sugere os prompts que funcionam para o autor, isto é, a forma de mandar a IA encontrar bugs, e recomenda que todo mundo faça isso
  Eu uso essas ferramentas no trabalho e em projetos paralelos pessoais, então esperava observar e aprender, mas textos de opinião sem exemplos já são numerosos demais

  • Fico curioso se ele realmente testou o fluxo proposto. Eu considero um fluxo útil e, se ainda não tivesse encontrado um fluxo parecido, teria agradecido esse tipo de indicação
    O autor poderia criar ou montar rapidamente um harness de código para isso, mas agora essa instrumentação parece estar mais no domínio de alguém praticante como você. Se quiser automatizar e experimentar, provavelmente é mais rápido especificar você mesmo o que quer do que lidar com o código dele, sendo bem sincero

• Enquanto lia isso, eu estava trabalhando em uma funcionalidade bem densa, e isso exigiu bastante iteração
  O resultado final acabou tendo muito menos código do que o código que existia no meio do processo. Então fiquei me perguntando se a IA realmente ajudou, porque eu poderia ter escrito o código diretamente no tempo que gastei iterando
  Mas, graças à IA, consegui montar rapidamente e de forma tosca 4 variações da funcionalidade de que não gostei, e descartá-las com a mesma rapidez, sem peso na consciência

  • Um dos maiores avanços que tive usando IA é exatamente esse ponto
    Antes, eu precisava pensar muito no planejamento antes de começar a implementar uma funcionalidade nova, e muitas vezes só percebia a falta de encaixe com o código existente depois de já ter escrito bastante implementação. Agora posso pedir à IA um plano detalhado de implementação e descobrir esses pequenos problemas de detalhe em poucas horas, ou até em menos tempo
  • Então, qual é a conclusão? Valeu a pena?

• O que tem sido interessante nos últimos anos é acompanhar os limites da minha preguiça para programar
  Como programador, eu odeio código boilerplate. Não gosto nem de escrever nem de manter. Então eu costumava orientar design e arquitetura em torno dessa preferência; às vezes isso foi sábio, às vezes não. De qualquer forma, era a minha preferência, e eu evitava trabalhos que eram difíceis para mim
  Há alguns anos, quando os LLMs começaram a ficar minimamente úteis para programação, percebi que eles eram excelentes justamente em boilerplate, e por volta de 2023 eram quase só isso que faziam bem. Isso me fez pensar em quanto entendimento implícito e quanta consideração colocamos nas forças e fraquezas das pessoas com quem trabalhamos ao projetar sistemas e arquitetura
  Os modelos mais recentes têm forças e fraquezas muito diferentes das dos humanos, e alocá-los é um exercício interessante que exige outro tipo de arquitetura e de habilidade de engenharia. Tenho gostado disso e espero continuar gostando

  • Boilerplate vira algo opcional ou gerado automaticamente quando existem boas bibliotecas ou frameworks
    É muito melhor obter uma saída determinística com django-admin startproject, npm init, meteor create do que jogar um prompt num LLM sem saber o que vai sair
    Em ecossistemas web maduros, o boilerplate é minimizado. Agora que passamos esse trabalho para LLMs, fico preocupado que o esforço de desenvolvimento para criar CLIs do tipo startproject e bons padrões padrão diminua

• Gostei. Eu também uso uma abordagem parecida de ralph-loop
  Começo com um plano aprovado, passo para um coordenador e, simplificando, processo isso em 2 sessões: build e review, com um modelo separado em cada sessão

• O que me trava no uso de agentes de programação é ter que depender de serviços externos pagos
  Existe algum modelo local bom o bastante para usar em programação?

  • Neste mês, Qwen3.6 (27B ou 35B-A3B) e Gemma 4 são citados com frequência
    Isto também pode ajudar: https://hnup.date/hn-sota
    Os modelos Qwen são os meus modelos do dia a dia nesta semana

[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