Como usar LLM para código com critério

O problema

Tem gente usando LLM para código de dois jeitos ruins.

O primeiro é este:

• pede uma mudança grande
• cola o resultado
• roda uma coisa rápida
• faz merge porque “parece certo”

O segundo é o extremo oposto:

• rejeita a ferramenta inteira
• age como se qualquer uso de IA fosse trapaça técnica
• perde tempo fazendo manualmente trabalho repetitivo que poderia ter sido acelerado

Os dois erram.

O problema não é usar LLM.

O problema é perder o controle sobre o que você está aceitando.

Código gerado com confiança continua podendo estar:

• parcialmente certo
• certo no caso feliz e errado nos cantos
• usando API desatualizada
• ampliando demais o escopo da mudança
• introduzindo risco que o diff não deixa óbvio de primeira

Em entrevista, quando alguém pergunta como você usa IA no trabalho, quase nunca está tentando descobrir qual ferramenta você paga.

Está tentando descobrir se você ainda pensa como engenheiro quando a geração ficou barata.

Modelo mental

Pense assim:

LLM para código é uma máquina de propor. Quem decide o que entra continua sendo você.

Essa frase resolve bastante confusão.

Porque ela coloca o modelo no lugar certo.

Ele pode ajudar a:

• resumir código que você ainda não entendeu
• sugerir testes
• gerar rascunho de implementação
• comparar alternativas
• lembrar edge cases

Mas ele não deveria ganhar o direito de decidir sozinho:

• se a solução está correta
• se o escopo do diff está aceitável
• se o risco operacional faz sentido
• se aquele código combina com o sistema real

Se você trata o LLM como autor confiável, terceiriza critério.

Se trata como acelerador de proposta, ganha velocidade sem abrir mão de julgamento.

Quebrando o problema

O melhor uso inicial é reduzir trabalho mecânico, não pular entendimento

LLM costuma ajudar muito quando o custo principal é fricção mental repetitiva.

Exemplos bons:

• pedir resumo de um arquivo grande antes de você ler com calma
• pedir casos de teste que talvez tenham passado batido
• pedir uma primeira versão de transformação repetitiva
• pedir sugestões de naming, validação ou estrutura
• pedir uma explicação de trade-offs entre duas abordagens

Note o padrão.

Em todos esses casos, o modelo acelera raciocínio ou execução.

Mas não substitui sua leitura final.

Quanto maior o risco, menor o escopo que você deveria delegar

Esse é um critério simples e forte.

Trecho de baixo risco:

• formatter de payload
• teste
• script pequeno
• adaptação repetitiva

Trecho de alto risco:

• autenticação
• autorização
• concorrência
• transação
• cobrança
• migração de dados
• lógica de segurança

Nos casos de alto risco, usar LLM ainda pode fazer sentido.

Mas o jeito muda.

Em vez de pedir:

• “reescreva isso tudo”

você pede coisas como:

• “explique o fluxo atual”
• “aponte riscos deste trecho”
• “sugira testes para este comportamento”
• “proponha a menor mudança possível para validar X”

Ou seja: você reduz a autonomia da proposta quando o custo de erro sobe.

Código gerado precisa passar por critério de aceite de verdade

Muita gente usa LLM e depois valida assim:

“rodei aqui e funcionou”

Isso é pouco.

Critério melhor costuma envolver perguntas como:

1. Eu entendo o que o diff mudou?
2. Eu entendo por que isso resolveria o problema?
3. O comportamento esperado ficou verificável?
4. O tamanho da mudança ainda permite revisão séria?
5. Se quebrar, eu sei onde olhar e como reverter?

Se várias dessas respostas forem “não”, a mudança ainda está crua.

O maior risco não é sintaxe errada. É plausibilidade enganosa

Esse ponto importa muito.

LLM frequentemente produz código que:

• compila
• parece limpo
• usa nomes bons
• passa confiança

E mesmo assim:

• ignora uma regra do domínio
• abre um buraco de segurança
• cria acoplamento demais
• assume comportamento que não existe
• muda mais coisa do que precisava

Esse é o perigo real.

Erro óbvio você pega rápido.

Erro plausível entra sorrindo no repositório.

Prompt melhor não é o mais sofisticado; é o que limita bem a tarefa

Você não precisa escrever prompt mirabolante para usar LLM melhor.

Na prática, costuma ajudar mais pedir:

• escopo pequeno
• arquivos específicos
• premissas explícitas
• riscos percebidos
• testes sugeridos
• resposta em diff curto

Exemplo de direção útil:

“Não reescreva a função inteira. Sugira a menor mudança possível para validar entrada e manter comportamento atual. Explique riscos e testes que eu deveria rodar.”

Isso é melhor do que:

“Melhore este código.”

Pedido vago quase sempre devolve mudança vaga.

O time precisa revisar código gerado do mesmo jeito que revisa código humano

Tem equipe que, sem perceber, começa a tratar código gerado por IA como se fosse “bônus”.

Algo como:

• veio rápido
• parece bem escrito
• tem cara de pronto

Então a barra cai.

Não deveria cair.

Na verdade, em alguns casos ela sobe.

Porque a saída bem escrita do modelo pode esconder problema melhor do que código ruim feito às pressas por uma pessoa cansada.

Quem aprova merge continua sendo responsável pela mudança.

O autor material do trecho ter sido humano ou modelo não muda isso.

Segurança e privacidade continuam existindo

Mesmo neste artigo o ponto merece aparecer.

Controle não é só técnico.

Também é operacional.

Então usar LLM para código sem perder controle inclui:

• não colar segredo
• não colar dado de cliente sem autorização
• entender política da ferramenta
• evitar jogar contexto sensível em ambiente errado

Isso não é paranoia.

É limite básico de confiança.

Exemplo simples

Imagine que você precisa corrigir um endpoint que cria cupons.

O bug report diz:

• valor negativo está passando
• alguns testes não existem
• o fluxo também está com erro de mensagem

Uso ruim de LLM:

1. você cola o arquivo inteiro
2. pede “corrija e melhore”
3. recebe um diff com 200 linhas
4. aceita porque os testes passaram

O problema é que, no meio da resposta, o modelo:

• reorganizou funções sem necessidade
• mudou nomes demais
• alterou mensagem de erro em outro fluxo
• mexeu em validação que você nem tinha pedido

Agora você até pode ter corrigido o bug.

Mas perdeu controle do custo da mudança.

Uso melhor:

1. primeiro pede um resumo do fluxo atual e onde o valor negativo entra
2. depois pede a menor alteração possível para bloquear esse caso
3. pede também dois ou três testes que deveriam existir
4. lê o diff com calma
5. roda testes
6. testa manualmente o caso negativo e o caso feliz
7. verifica se mais alguma regra foi alterada sem querer

Nesse segundo fluxo, o LLM continua acelerando.

Mas você continua no comando.

Essa é a diferença.

Erros comuns

• Aceitar mudança grande demais só porque o modelo devolveu rápido.
• Usar LLM para escapar da leitura do código legado que você precisava entender.
• Tratar teste passando como prova suficiente de correção.
• Pedir refactor, validação e melhoria de performance tudo de uma vez.
• Não pedir que o modelo explicite premissas e riscos.
• Colar código sensível sem considerar privacidade, contrato ou política da ferramenta.
• Confundir velocidade de geração com velocidade real de entrega segura.

Como um senior pensa

Quem tem mais maturidade não entra nem no hype nem na negação.

Pensa assim:

“Onde isso realmente economiza esforço cognitivo sem comprar risco escondido?”

Essa pessoa costuma usar LLM para:

• explorar código desconhecido
• gerar rascunho de partes mecânicas
• levantar edge cases
• acelerar teste
• comparar alternativas

E costuma apertar o controle quando vê:

• domínio crítico
• diff grande demais
• regra de negócio delicada
• impacto operacional alto
• risco de segurança ou dados

Ela também sabe uma coisa importante:

quem assina o merge não é o modelo.

É você.

Então a responsabilidade não some só porque a geração ficou mais barata.

Resposta sênior sobre IA em código não parece:

• propaganda de ferramenta
• medo moralista
• confiança vaga

Ela parece critério operacional.

O que o entrevistador quer ver

Quando esse tema aparece em entrevista, normalmente o avaliador quer ver quatro coisas.

• Se você usa IA como acelerador com julgamento, e não como muleta cega.
• Se você sabe reduzir escopo quando o risco sobe.
• Se você tem critério de aceite verificável para código gerado.
• Se você entende que responsabilidade, segurança e revisão continuam existindo.

Resposta forte costuma soar mais ou menos assim:

“Eu uso LLM para explorar código, gerar rascunhos menores, levantar testes e reduzir trabalho repetitivo. Mas não terceirizo a decisão de merge. Quanto maior o risco do trecho, menor o escopo que eu deixo o modelo propor. Eu aceito mudança quando consigo explicar o diff, verificar comportamento e entender o impacto.”

Isso mostra maturidade.

Porque a conversa deixa de ser sobre moda.

E vira sobre controle.

LLM pode acelerar a escrita do código. Não deveria acelerar o seu relaxamento de critério.

Se você não consegue defender a mudança sem citar a ferramenta, ainda não deveria aceitar o diff.