As seis formas do código gerado quebrar em produção

A aula anterior tratou do erro que aparece na primeira execução. Esta trata dos outros — os que passam no seu teste manual, entram no merge e aparecem três semanas depois.

1. SQL montado por concatenação

Peça "uma busca por nome com filtro opcional de status" e é comum receber a montagem dinâmica da query com interpolação — especialmente quando o prompt menciona que o filtro é opcional, porque a saída mais provável para "opcional" é concatenar condições.

$sql = "SELECT * FROM users WHERE name LIKE '%$nome%'";
if ($status) {
    $sql .= " AND status = '$status'";
}
$rows = $pdo->query($sql)->fetchAll();

$sql = 'SELECT * FROM users WHERE name LIKE :nome';
$params = ['nome' => '%' . $nome . '%'];

if ($status !== '') {
    $sql .= ' AND status = :status';
    $params['status'] = $status;
}

$stmt = $pdo->prepare($sql);
$stmt->execute($params);

A diferença: O que muda não é o SQL ser fixo — é o dado do usuário nunca virar parte do texto da query. Nomes de coluna e direção de ordenação, quando precisarem ser dinâmicos, saem de uma lista fechada no seu código, nunca do request.

2. Consulta dentro de laço

$pedidos = $pedidoRepo->doMes($mes);

foreach ($pedidos as $pedido) {
    $pedido['cliente'] = $clienteRepo->find($pedido['cliente_id']);   // 1 query por pedido
    $pedido['itens']   = $itemRepo->doPedido($pedido['id']);          // mais 1 por pedido
}

Esse é o padrão mais traiçoeiro da lista porque o código está correto. Ele produz o resultado certo. Só não sobrevive ao volume real. E o assistente não conhece o seu volume real — a menos que você diga.

3. Erro capturado e engolido

try {
  await enviarNotaFiscal(pedido);
} catch (e) {
  // segue o fluxo
}

return { ok: true };

Modelos produzem esse padrão porque ele aparece muito em código de exemplo, onde o objetivo é não poluir a demonstração. Em produção, o catch vazio é a diferença entre um erro de dez minutos e uma investigação de dois dias.

A correção é sempre a mesma: registre com contexto, decida explicitamente se o fluxo continua, e faça o retorno dizer a verdade.

4. Verificar-depois-agir sob concorrência

// Gerado a partir de "não deixar reservar se não houver vaga"
$vagas = $repo->vagasDisponiveis($eventoId);

if ($vagas > 0) {
    $repo->criarReserva($eventoId, $usuarioId);   // ← duas threads chegam aqui juntas
    $repo->decrementarVagas($eventoId);
}

Concorrência é o assunto em que a resposta padrão do assistente é mais fraca, porque o código correto depende do seu banco, do seu nível de isolamento e de onde o processo roda. Aqui o prompt precisa ser explícito: "duas requisições podem chegar ao mesmo tempo; resolva no banco, com transação e trava, não em memória".

5. Regra de negócio inventada

Quando o requisito não diz o que fazer num caso, o modelo não pergunta — ele preenche. Peça "calcular o valor do frete grátis acima de R$ 200" e alguma resposta vai decidir sozinha se o valor considerado é antes ou depois do desconto, se inclui itens de terceiros, e o que acontece num cancelamento parcial.

Este é o único item da lista que nenhuma ferramenta pega. Não existe linter para regra errada. Só o confronto com o requisito e com quem o escreveu. É o assunto do módulo 2.

6. Dependência nova sem necessidade

Peça uma formatação de data e você pode receber uma biblioteca inteira junto. Nem sempre é errado — mas a decisão de adicionar uma dependência tem custo de segurança, build e manutenção, e ela chega escondida no meio de um diff que parecia ser de uma função.

Leia sempre o diff do package.json, composer.json ou requirements.txt. É a linha do diff que menos recebe atenção e a que mais muda o projeto.