A geração de código por LLM pode levar ao enfraquecimento da confiança

• Recentemente, a geração de código baseada em LLM vem sendo cada vez mais usada entre desenvolvedores
• O código gerado automaticamente tem ampliado as preocupações com a qualidade e a confiabilidade do código
• Desenvolvedores relatam maior dificuldade de manutenção de projetos devido à falta de compreensão do código e à validação insuficiente
• A disseminação do uso de código não confiável afeta todo o ecossistema de software
• Com o avanço da tecnologia, destaca-se a necessidade de criar formas de garantir a confiabilidade

---

Visão geral

Em seu blog, Jay aborda o impacto recente das tecnologias de geração de código baseadas em LLM (modelos de linguagem de grande porte) no desenvolvimento de software. Embora a evolução dessas ferramentas esteja aumentando a eficiência no desenvolvimento, também traz à tona questões de confiabilidade e qualidade do código.

A ascensão da geração de código com LLM

• Ferramentas de geração automática de código com uso de LLM estão se espalhando rapidamente no ambiente de desenvolvimento
• Elas oferecem alta produtividade na implementação de funcionalidades complexas ou em tarefas repetitivas de programação
• Têm como vantagens a prototipagem rápida e a redução da carga de aprender novas linguagens

Problemas de confiabilidade

• O código gerado por LLM nem sempre funciona como pretendido
• Como a intenção e a lógica de projeto dentro do código nem sempre ficam claras, os processos de compreensão e validação se tornam difíceis
• Se os processos de revisão e teste forem insuficientes, podem surgir bugs ou vulnerabilidades inesperadas

Manutenção de projetos e impacto no ecossistema

• Surgem problemas de falta de documentação e explicações insuficientes sobre o código gerado automaticamente
• Como os desenvolvedores têm dificuldade para entender como o código funciona, a complexidade da manutenção aumenta
• Existe o risco de deterioração da cultura de desenvolvimento de software confiável

Conclusão e sugestões

• A geração de código baseada em LLM é inovadora, mas garantir a confiabilidade é um desafio essencial
• Ao adotar código gerado automaticamente, destaca-se a necessidade de reforçar a validação e realizar revisões de código sistemáticas
• No longo prazo, é importante estabelecer critérios para proteger a confiança no ecossistema computacional

[GN⁺]

Opiniões do Hacker News

• Compartilhando o link do archive.is, funciona até em navegadores antigos, e JavaScript só é necessário para contornar o CloudSnare

• Um amigo meu sempre dizia: "a inovação acontece na velocidade da confiança". Desde o surgimento do GPT-3, essa frase não sai da minha cabeça. Verificar custa caro, e a confiança é um dos principais meios de reduzir esse custo. Mas eu não sei como construir confiança em LLMs. Eles são extremamente fluentes tanto em código quanto em linguagem natural, mas ao mesmo tempo também se perdem em direções que, se fosse uma pessoa, pareceriam maliciosas

  • Sou o autor: gostei muito dessa citação. Ela resume de forma muito concisa o que tentei explicar em vários parágrafos. Sinceramente, viver num mundo em que agora é preciso verificar tudo manualmente é realmente cansativo e lento
  • Não dá para ter confiança total no resultado de LLMs. Mas dá para fazer sanitização e limitação de impacto. Filtrar entrada de usuário, fazer testes de invasão, esconder segredos em arquivos dot — no fim, isso vai convergir para padrões como "boas práticas" e "conformidade regulatória SOC-AI". Os LLMs são úteis demais para serem ignorados, por mais que se queira. A confiança também se constrói um passo de cada vez. Humanos também estão longe de ser confiáveis, e, comparando com carros autônomos, acho que vai ser possível produzir código com menos bugs do que humanos dentro de regras definidas. Depois disso, a complexidade só vai melhorando aos poucos
  • Essa frase, "a inovação acontece na velocidade da confiança", precisa de um pouco mais de explicação. Quando eletricidade, voo e radioatividade foram descobertos pela primeira vez, existia esse nível de confiança? Na ciência, a confiança se constrói ao longo do progresso

• Acabei vivenciando esse tema no trabalho de um jeito inesperado. Sob pressão por resultados rápidos, eu e um colega acabamos fazendo merge de um grande refactor em que eu estava trabalhando, mesmo o PR ainda estando em estado temporário. Depois disso, surgiu um bug em código não testado. Durante a depuração, o colega confessou que achou que eu tinha programado com IA e que estava frustrado por tentar entender, depois do fato, um código que a IA teria gerado. Mas aquele código era trabalho manual, escrito cuidadosamente por mim, e os bugs vieram de pequenos erros durante uma mudança simples de API. Ainda assim, essa experiência acabou revelando de forma natural uma tensão de confiança entre mim e meu colega, e conseguimos conversar sobre isso de forma construtiva. Olhando para trás, foi uma experiência significativa de construção de confiança, e imagino que, em outro contexto, isso poderia ter se complicado muito mais. Dá uma sensação de que sempre é preciso tomar cuidado

• Eu não entendo muito bem a premissa. A confiança de que alguém escreve bom código vem da experiência real de ver que essa pessoa codificou diretamente e o resultado foi bom. Se a pessoa usa LLM e mesmo assim entrega código sem bugs, eu confio; se usa LLM e entrega código com bugs, eu não confio. Não vejo no que isso difere de escrever tudo só com a própria cabeça

  • Sou o autor: meu ponto é que, em ambientes de baixa confiança — como equipes grandes com confiança mediana, ou open source — o uso de LLM torna cada vez mais difícil julgar a capacidade de um desenvolvedor apenas olhando o código submetido. Como não dá para perceber o perfil da pessoa, no fim você precisa voltar ao estado de "confiança zero" e revisar tudo com muito cuidado. Os atalhos que antes serviam para revisão rápida deixam de funcionar, e isso pode ser bem doloroso em organizações acostumadas com essa cultura. Se sua equipe já tem alta confiança, talvez esse problema simplesmente não faça sentido para você
  • Antes, se A=B, um B alto também significava que A era bom. Agora virou A+AI=B, então mesmo que B seja alto, A pode não ser. E, como a IA atual é probabilística, às vezes ela é pior do que não fazer nada
  • Você disse "só confio em código que funciona", mas a base dessa confiança é o desenvolvedor saber de antemão que o código realmente não tem bugs. Só que, em sistemas complexos, para entender como o código interage com o resto e que edge cases podem surgir, quem escreveu precisa compreender o contexto inteiro. Se o LLM escreveu o código e o desenvolvedor não entendeu tudo, então esse peso da verificação acaba indo para o revisor, causando sobrecarga. Esse é o argumento
  • Quando se programa com LLM, depois de algumas vezes em que dá certo, a pessoa fica confiante demais e relaxa nos testes. Na prática, muitos problemas vêm de erro de comunicação. Mesmo que o operador entenda a tarefa inteira, LLMs têm dificuldade de manter estado e, quando o contexto é ambíguo, fazem suposições absurdas. Eu gostaria que a abordagem do 4o, de primeiro pedir continuamente mais informações, virasse padrão em todos os modelos de geração de código; isso realmente evitaria muitos problemas
  • A confiança não se constrói só pelo fato de funcionar. Também conta explicar claramente as mudanças, ter histórico de contribuições boas, fazer mudanças em unidades apropriadas (commits com tamanho razoável), priorizar corretamente os problemas (corrigir bug antes de adicionar recurso), manter bem o código existente, participar com consistência etc.

• Já estamos nessa era. Vejo demais frases como "desculpe por ter deixado isso passar, você está certo". Já vi isso 8 ou 9 vezes em cada 10. Por outro lado, também vejo muita gente fazendo copy-paste sem sentido de código gerado por LLM e ficando brava quando o resultado não corresponde ao esperado. Na verdade isso é melhor. Prefiro algo claramente quebrado a algo que parece certo por fora

  • Pela minha experiência, LLMs tendem mais a alterar o código para passar nos testes do que para de fato cumprir os requisitos
  • Você está usando LLM por chatbot no navegador? Nós usamos um agente de IA com acesso direto ao código, e ele fala muito menos e frequentemente faz trabalho melhor do que vários juniores ao redor. Ele executa bem tarefas curtas e específicas, a ponto de quase só precisar de code review antes de usar. Claro, o prediction engine realmente não sabe fazer engenharia de verdade. Por exemplo, se você não pedir explicitamente um generator em Python, ele muitas vezes entrega código que consome memória demais. Mas muitos desenvolvedores Python à minha volta cometem exatamente o mesmo erro. Na verdade, isso ajuda porque força a escrever uma especificação clara, em vez de só dizer "add feature". O lugar em que agentes de IA são mais úteis é em código legado que ninguém quer tocar. Temos um sistema antigo que extrai dados de um documento recebido por fax com 200 coordenadas; ele ficou mais de 30 anos sem mudanças, e recentemente o documento mudou. O copilot levou 30 segundos para ajustar as coordenadas. Para uma pessoa, isso facilmente levaria um dia inteiro. Mas eu não sei como alguém vai virar especialista numa era de programação com esse clima
  • 8 ou 9 vezes em cada 10 é exagero demais. É uma estatística 100% inventada

• Ferramentas de abstração anteriores reduziam complexidade partindo do pressuposto básico da "correção" da abstração. Claro, não eram perfeitas e tinham bugs, mas isso era um problema da implementação, não um erro inerente. Uma vez corrigidas, tendiam a ficar mais robustas. Já LLMs são mecanismos probabilísticos de previsão que só apresentam uma precisão aproximada por um período. O ponto que o autor deixa passar é que ainda dá para construir sistemas determinísticos confiáveis usando agentes probabilísticos imperfeitos. Por exemplo, você não confia num coletor de lixo porque acredita no autor da ferramenta, mas porque a ferramenta foi suficientemente testada e demonstrou funcionar como desejado. Acho que no futuro o desenvolvimento orientado a testes vai ficar mais forte. Em vez de confiança, verificação

  • Achar que testes automatizados podem capturar todos os problemas é ingenuidade. Concorrência, gerenciamento de recursos, vulnerabilidades de segurança — há coisas demais difíceis de automatizar. E quem vai validar os próprios testes? Código e testes implementam lógica separadamente, e às vezes a origem do bug aparece no teste, não no código. Também não dá para confiar cegamente nos testes
  • Sou o autor: aqui estou falando menos do efeito da ferramenta e mais da ferramenta em si. Por exemplo, se o próprio modelo atuasse diretamente como coletor de lixo, recebendo dumps de memória do programa e liberando blocos desnecessários, eu nunca conseguiria confiar nesse julgamento para sempre. Não importa quanto se complemente com "patches" ou "fine-tuning", existe um limite. Num output determinístico como o da JVM, se surge um erro e ele é corrigido, esse erro desaparece para sempre. Com LLM isso não acontece. Acho que essa diferença é o ponto de bifurcação essencial entre abstrações anteriores e o mundo dos LLMs. Acredito que os LLMs terão grande impacto na indústria, mas é realmente território desconhecido, porque há poucos precedentes históricos
  • Essa parte sobre "sistemas determinísticos confiáveis surgirem de um fator probabilístico (máquina de entropia)" soa bem radical para mim. E TDD sempre aparece como se fosse uma ferramenta universal que resolvesse tudo. Mas eu já vi, em quantidade constrangedora, software totalmente errado sendo construído a partir de testes errados

• Ser contra LLMs não adianta em nada. Hoje os LLMs aumentam a produtividade dos desenvolvedores. Pelo menos para desenvolvedores menos experientes, isso é ainda mais útil. Uma ferramenta que aumenta muito a produtividade não vai ser abandonada, não importa o que digam. Mesmo que apareçam casos de danos, como grandes serviços ficando fora do ar por muito tempo por causa de bugs graves, se a produtividade continuar sendo valiosa a tecnologia não vai parar. O único caminho realista é seguir junto com a tecnologia, resolvendo (ou mitigando) suas fraquezas. Nesse processo, se a mitigação atrapalhar o ganho de produtividade, ela vai ser contornada, e acabarão se estabelecendo medidas complementares que convivam com a tecnologia

  • Dizer que "LLMs aumentam a produtividade dos desenvolvedores" varia demais conforme a pessoa e o contexto. Pela minha experiência, quem fala em "10x de produtividade" costuma ser júnior de frontend ou gente de startup que faz app inicial com frequência. Tudo bem, são bons casos, mas esse tipo de desenvolvedor e um sênior de C embarcado muitas vezes estão praticamente falando línguas diferentes. Por isso o debate sobre produtividade com IA costuma ser uma conversa entre contextos distintos. E, quanto ao "uso racional", eu mesmo questiono se a ideia de agente de IA é boa. Olhando o caso do Copilot, tanto a MS quanto a IA viraram motivo de piada. Delegar trabalho de forma autônoma para IA talvez não seja automaticamente inteligente. Do mesmo jeito, blockchain também teve todo tipo de exagero na fase de euforia das criptomoedas, mas houve casos como a Coinbase, que encontrou um nicho realmente relevante. Em 2020, a IBM dizia que gerenciava a cadeia de suprimento de grãos de café com blockchain (visto hoje, em 2025, parece piada de Twitter, mas na época era sério). No fim, os atuais agentes de IA, e outras aplicações de IA generativa, também podem acabar virando exemplos de hype excessivo no futuro caso do Copilot artigo da Forbes
  • A expressão "mais produtivo" aparece o tempo todo, mas isso não quer dizer que a combinação humano/IA esteja de fato atendendo melhor às necessidades do usuário no resultado final; só quer dizer que "mais código está sendo produzido". Nunca ouvi falar de um LLM que abriu um PR deletando 2 mil linhas de código. "Aumentar a produtividade do engenheiro" na prática significa escrever mais código
  • É um mal-entendido achar que a intenção do autor é realmente crítica no sentido de rejeitar a tecnologia. A questão não é um dilema binário entre usar ou não usar LLM, e sim focar em gestão e mitigação de risco. Fazendo uma analogia: não é ser contra o desenvolvimento de automóveis, e sim dizer que, como carros podem explodir, precisamos nos concentrar mais em reduzir essas explosões
  • Para mim, o texto original não parece uma "lamúria sem sentido", mas uma preocupação realista sobre armadilhas fáceis de ignorar ao colaborar com LLMs e sobre que tipo de contramedidas propor dentro da equipe
  • Quando o React apareceu pela primeira vez, eu me arrependo de não ter aprendido. Ainda tenho resistência ao GPT, e ao meu redor o pessoal vive dizendo coisas como "o chatGPT disse isso" ou "isso aqui é código de chatGPT", enquanto eu tenho orgulho de sofrer e codar com as próprias mãos. Eu não uso GPT, mas, pensando bem, talvez Google ou Stack Overflow também possam ser vistos como um GPT lento

• Em vez de políticas como "prometer que o código contribuído não é produto de LLM, é original e foi totalmente compreendido" ou "exigir que a maior parte seja manual", o foco deveria estar só no resultado. Exigir que quem contribui entenda bem as mudanças faz sentido. Já políticas como "júnior deve evitar ou ser proibido de usar ferramentas LLM por um período" não parecem boas. LLMs ajudam bastante nos problemas caóticos de setup de ambiente durante o onboarding. Além disso, são úteis para entender código e documentação, e também funcionam bem como ferramentas de busca textual e resumo

  • O onboarding na prática também é um processo de aprender a resolver problemas aleatórios de ambiente. Se toda dificuldade e complexidade forem eliminadas por automação, tenho a impressão de que depois ninguém mais vai saber o que fazer nessas situações. Não sei se só eu penso assim

• Foi a primeira vez que ouvi o conceito de "AI Cliff" (fenômeno em que a precisão do LLM despenca de repente). Queria saber se mais gente já passou por isso

  • Eu passo por isso com frequência. Quando a complexidade do código passa de um certo limiar, o LLM não consegue mais manter todo o contexto na cabeça e começa a agir de forma estranha. Meu papel é gerenciar a complexidade que o LLM vai enxergar. Os LLMs atuais tendem a tornar a estrutura mais complexa com o tempo. Basicamente, eu peço refactors para simplificar ou, quando complica demais, eu mesmo reorganizo. Se você continuar delegando, os LLMs de hoje acabam criando uma confusão gigantesca à la Rube Goldberg, e no fim um humano precisa limpar. Um desenvolvedor experiente percebe rápido até onde o LLM está levando tudo mar adentro e consegue voltar cedo; um iniciante pode se perder completamente antes mesmo de perceber o que aconteceu
  • Eu chamo isso de context drunk. Se o contexto de entrada tem 10 mil tokens e está 99% correto, o LLM produz uma resposta de 1.000 tokens com só 90% de acerto. Conforme a conversa segue de um lado para o outro, grande parte da janela de contexto vira repetição desse output menos preciso gerado pelo LLM. Os erros se acumulam, e como a informação recente pesa mais, o resultado vai ficando cada vez mais errado. Esse problema aparece não só em código, mas também em prosa
  • Eu chamo de context rot. À medida que o contexto se acumula, a qualidade do output cai. Quanto mais conversa fiada ou conteúdo irrelevante, mais rápido piora. Isso é especialmente ruim quando chain of thought (COT) fica no contexto; se o raciocínio se perde, esse rastro só piora tudo. Eu pessoalmente gostaria de uma função de pruning para cortar partes do contexto. Eu lido com context rot resumindo manualmente e levando isso para uma sessão nova
  • Eu só passei por isso em interfaces de chat, tipo vibe coding; ferramentas no estilo agente gerenciam a própria janela de contexto de código e executam diretamente dev tooling para fazer sanity check, então isso acontece bem menos
  • Eu reseto com frequência as sessões de IA no trabalho, então não costumo sentir esse "AI cliff". Mas, ao escrever ficção, o comprimento e a consistência do contexto importam muito, e já aconteceu de a IA, em certo momento, deixar de manter bem a personalidade dos personagens e começar a reagir de forma estranha. Como não dava para reverter, foi uma experiência bem desconcertante

• O autor diz que não vai resumir textos de várias pessoas, mas na prática parece ser isso mesmo. Ainda assim, eu gostaria que existisse uma marcação em PRs indicando arquivos com código gerado por IA. Os tipos de erro em código de LLM e em código humano são diferentes, então poder distinguir isso na revisão economizaria tempo. Queria saber se alguém já viveu uma política assim em organizações grandes, ou se já existem ferramentas automatizadas para isso. Se empresas medem a proporção de código gerado por LLM, talvez ferramentas desse tipo já existam para métricas mais detalhadas

  • Sou o autor: na prática, ainda não vi muita discussão explícita sobre confiança dentro da equipe em relação a LLMs, então não conheço casos formalizados. Não sei se isso é um problema do lugar onde trabalho ou se é algo difícil de encontrar no mainstream mesmo