Boilerplate Verboso.

Um revisor identifica Boilerplate Verboso quando um diff é muito mais longo do que o problema exige: cada linha é narrada por um comentário que apenas a reafirma, expressões simples são embrulhadas em escadas defensivas de null/undefined e o mesmo formato de código reaparece duas ou três vezes em vez de ser fatorado em um único helper. O sinal revelador é uma alta razão comentário-para-lógica e linha-para-comportamento, além de blocos que poderiam ter sido três linhas de código idiomático.

// Função para obter o nome completo do usuário
function getFullName(user: User): string {
  // Verifica se o usuário está definido
  if (user === null || user === undefined) {
    // Retorna uma string vazia quando nenhum usuário é fornecido
    return "";
  }
  // Obtém o primeiro nome, usando string vazia como padrão
  const firstName = user.firstName ? user.firstName : "";
  // Obtém o sobrenome, usando string vazia como padrão
  const lastName = user.lastName ? user.lastName : "";
  // Concatena o primeiro nome e o sobrenome com um espaço
  const fullName = firstName + " " + lastName;
  // Remove espaços em branco e retorna o resultado
  return fullName.trim();
}

Três linhas de comportamento enterradas em ~12 linhas de cerimônia. Em um PR real você costuma ver esse mesmo padrão copiado e colado como getDisplayName, getLabel e getInitials, cada um escrevendo à mão uma lógica que um util formatName() já cobre — o clássico smell de Código Duplicado. Outros sinais: construtores/wrappers de passagem vazios, cerimônia try { ... } catch (e) { throw e } e um validador de e-mail/URL sob medida ao lado do módulo de validação já existente do projeto.

Por que os modelos produzem isso

• Viés de verbosidade do próximo token. LLMs são treinados em enormes volumes de código de tutoriais, Stack Overflow e iniciantes, onde comentários passo a passo e cerimônia explícita são a norma. A continuação mais provável é a mais profusamente explicada, não a mais concisa.
• O RLHF recompensa "parecer minucioso." O ajuste de prestatividade/verbosidade empurra os modelos para uma saída que parece completa e autoexplicativa — comentários em cada linha, verificações defensivas por toda parte — que avaliadores e usuários recompensam mesmo quando não agrega valor.
• Sem contexto do repositório = sem reutilização. Sem a base de código ao redor no contexto, o modelo não consegue saber que um util formatName() ou validateEmail() já existe, então ele o reconstrói inline. Isso é exatamente a Superespecificação da OX Security ("soluções hiperespecíficas e de uso único em vez de componentes generalizáveis e reutilizáveis," encontrada em 80–90% do código de IA) e a Evitação de Refatorações (80–90%).
• Geração, não consolidação. Agentes produzem código novo a cada prompt e nunca voltam para desduplicar. A análise de 2025 da GitClear sobre 211 milhões de linhas alteradas constatou que o código copiado/colado subiu de 8,3% (2020) para 12,3% (2024) e superou as linhas "movidas" (refatoradas) pela primeira vez, enquanto as linhas refatoradas caíram de ~24% para 9,5% e os blocos duplicados de 5+ linhas cresceram ~8x.
• Padrão de comentar tudo. A OX Security encontrou "Comentários por Toda Parte" em 90–100% do código gerado por IA.

Por que isso é prejudicial

• Manutenibilidade: mais superfície para ler e alterar; comentários redundantes saem de sincronia com o código e passam a enganar ativamente (o smell Comentários de Fowler).
• Correção e segurança: blocos duplicados significam que um bug ou vulnerabilidade precisa ser corrigido em N lugares — o Bugs Déjà-Vu da OX (70–80%). Código clonado se correlaciona com 15–50% mais defeitos.
• Carga de revisão: diffs grandes e de baixo sinal escondem mudanças reais e induzem fadiga no revisor, então problemas genuínos passam despercebidos.
• Dívida técnica que se acumula: cada quase-duplicata torna a próxima extração mais difícil, enraizando o problema que o modelo não consegue enxergar entre arquivos.

Táticas de revisão / prompting

• Force a reutilização antes da geração: "Procure na base de código por helpers existentes (formatName, validate*) e reutilize-os; não reimplemente." Forneça os utils relevantes no contexto.
• Estabeleça um orçamento para a saída: "Mantenha isto em menos de ~15 linhas; sem comentários que reafirmem o código — apenas comentários explicando o porquê."
• Faça o modelo executar as ferramentas: exija eslint/ruff e uma passada de duplicação com jscpd, e faça-o relatar e corrigir as violações antes de retornar.
• Peça o menor diff possível e uma etapa explícita de desduplicação: "Se algum bloco se repetir, extraia uma única função compartilhada (Extrair Função) e a chame."
• Consolide na revisão: quando você vir a terceira quase-cópia, aplique Extrair Função, Subir Método ou Consolidar Fragmentos Condicionais Duplicados, e Substituir Comentário por Código (renomeie para que o código se autodocumente).

Refatoração (antes → depois)

// depois: comentários removidos (o código é autoevidente), cerimônia eliminada,
// util compartilhado reutilizado em vez de reconstruído
function getFullName(user?: User): string {
  return [user?.firstName, user?.lastName].filter(Boolean).join(" ");
}

E elimine de vez as duplicatas — se getDisplayName/getLabel faziam a mesma coisa, apague-as e direcione os chamadores para uma única função (Remover Código Morto / Função Embutida). Substitua o validador feito à mão pela importação do módulo existente em vez de manter uma cópia paralela.

Regra prática para o catálogo: trate qualquer bloco de IA em que os comentários superem as linhas de lógica, ou em que você consiga nomear um helper existente que ele ignorou, como candidato à exclusão-por-reutilização — a correção mais rápida para boilerplate costuma ser menos código, não mais.