Nomenclatura ciega al contexto.

Un revisor detecta la nomenclatura ciega al contexto cuando los nombres en un diff escrito por IA son localmente plausibles pero están desconectados del repositorio circundante. Señales reveladoras:

• Marcadores genéricos en código de dominio: data, result, temp, item, obj, payload, response, value, handleStuff, processData donde el módulo ya habla un lenguaje específico (grossPremium, Customer, getCustomerById).
• Deriva de convenciones: un símbolo en snake_case colocado en un archivo camelCase, un prefijo booleano is/has ausente, o un nuevo verbo CRUD (fetch*) en una base de código que estandarizó get*. Cada diff sigue el estilo que encontró por última vez, introduciendo una cuarta convención. Luego una quinta.
• Proliferación de sinónimos / conceptos duplicados: la IA inventa fetchUser cuando getCustomerById ya existe, o mezcla customer/client/user para una sola entidad, reimplementando en lugar de reutilizar.
• Nombres que describen el mecanismo, no la intención, o que mienten sobre el comportamiento: processData() que en realidad calcula el impuesto sobre las ventas. Los agentes (y el siguiente agente) leen processData() y proceden como si ese nombre contara toda la historia, así que el significado erróneo se propaga a cada punto de llamada.

// El repositorio ya exporta getCustomerById(id: CustomerId): Promise<Customer>
// La IA añade un casi-duplicado con nombres ciegos al contexto:
async function fetchData(id: string) {          // verbo genérico, tipo laxo
  const result = await db.query("select * from customers where id = $1", [id]);
  const temp = result.rows[0];                  // 'temp' oculta que es un Customer
  return temp;                                  // nada aquí dice "Customer"
}

Por qué los modelos lo producen

• Sesgo de frecuencia del siguiente token. En todo el corpus de entrenamiento, data/result/temp/foo están entre los identificadores más frecuentes, especialmente en el código de tutoriales y plantillas que los LLM ingieren en abundancia. Generar el nombre estadísticamente promedio es exactamente lo que un predictor del siguiente token está optimizado para hacer, lo que diluye la intención del dominio.
• Sin contexto del repositorio (o truncado). El modelo rara vez ve el glosario del módulo hermano ni el getCustomerById existente. El resumen de DevClass del informe de GitClear de 2025 señala que los asistentes son menos propensos a proponer reutilizar una función similar de otro lugar, en parte por el tamaño limitado del contexto (DevClass sobre GitClear 2025).
• Optimización local / instinto débil de refactorización. Cada turno optimiza el prompt inmediato, no el código base en su conjunto. OX Security halló la evitación de refactorizaciones —una IA que "destaca generando código nuevo pero nunca vuelve atrás para mejorar la arquitectura"— en el 80–90 % del código de IA que analizó (informe de OX).
• Desactualización por la fecha de corte del entrenamiento. Las convenciones y los nombres de API de corpus más antiguos resurgen incluso después de que un proyecto haya avanzado.

Por qué resulta perjudicial

• Legibilidad/mantenibilidad: los nombres son la documentación principal de una base de código; los genéricos obligan a cada lector a volver a deducir la intención a partir del cuerpo.
• Duplicación y defectos: renombrar un concepto genera una implementación paralela. El análisis de GitClear de 2025 sobre 211 millones de líneas modificadas (2020–2024) concluyó que las líneas asociadas a la refactorización (líneas «movidas») cayeron del 25 % de las líneas modificadas en 2021 a menos del 10 % en 2024, mientras que las líneas copiadas/pegadas subieron del 8,3 % al 12,3 % en el mismo periodo; 2024 fue el primer año en que las líneas copiadas/pegadas superaron a las movidas, y los bloques con cinco o más líneas duplicadas se multiplicaron aproximadamente por ocho durante 2024 (GitClear 2025).
• Bucle de retroalimentación de agentes (el daño específico de la IA): los nombres son la interfaz que el siguiente agente lee al pie de la letra. Como dice la Encyclopedia of Agentic Coding Patterns, "un agente de IA trata los nombres que encuentra en un código base como su principal señal para entender qué hace cada cosa", y "los nombres inconsistentes en el código existente producen nombres inconsistentes en el código generado" (AI Pattern Book).
• Carga de revisión y corrección: los revisores deben mapear mentalmente temp/data de vuelta a conceptos del dominio, lo que oculta errores; los nombres engañosos provocan un uso incorrecto en los puntos de llamada.
• Puntos ciegos de seguridad/auditoría: un secreto o token aparcado en una variable llamada data/tmp se cuela ante los greps basados en nombres y la atención de la revisión.

Nota: las herramientas estáticas detectan bien las infracciones de nombres locales y explícitas (mayúsculas y minúsculas, longitud, palabras vetadas), pero que un nombre refleje el significado del dominio depende de la intención y escapa en gran medida a la detección automatizada.

Tácticas de revisión y de prompting

• Incorpora las convenciones y el glosario al contexto. Mantén una guía breve de nomenclatura (mayúsculas, prefijos booleanos, verbos CRUD, términos del dominio) en CLAUDE.md/los documentos de estilo y exige que el modelo la siga. Aplica los términos del glosario del dominio de forma consistente para que los sinónimos colapsen en una sola palabra.
• Fuerza la reutilización antes de la creación. Prompt: "Busca en el repositorio una función/tipo existente para esto antes de añadir uno; reutilízalo." Esto contrarresta directamente el fallo de conceptos duplicados que señalan GitClear y OX.
• Nombra las cosas en el prompt. "Nombra el manejador createRefund" es mejor que "añade el procesamiento de reembolsos". Especifica nombres del dominio (monthlyRevenue, no float1).
• Exige que se ejecuten el linter + el escaneo de duplicación sobre el diff (naming-convention + id-denylist + jscpd) y haz que el modelo corrija las infracciones en lugar de hacerlo tú a mano.

La refactorización: aplica Renombrar método (y lo mismo con las variables) para corregir los nombres engañosos, y elimina el Código Duplicado llamando al símbolo existente en lugar del nuevo.

Antes:

async function fetchData(id: string) {
  const result = await db.query("select * from customers where id = $1", [id]);
  const temp = result.rows[0];
  return temp;
}

Después (elimina el casi duplicado y llama a la función existente del repositorio con el tipo del dominio):

// No vuelvas a consultar — reutiliza getCustomerById y conserva el vocabulario del dominio.
const customer = await getCustomerById(id as CustomerId);

Si un nombre engañoso ya se entregó, renómbralo para que coincida con el comportamiento (processData → calculateSalesTax) antes de construir sobre él, para que los agentes y las personas posteriores hereden la señal correcta.