Comentarios residuo del prompt.

Un revisor detecta los comentarios residuo del prompt cuando los comentarios documentan la conversación que produjo el código en lugar del código en sí. Cuatro indicios, que a menudo coinciden:

• Prompt reformulado: un comentario que parafrasea la petición textualmente (// Function to add two numbers) encima de una función literalmente llamada add.
• Narración de pasos: relato línea a línea de operaciones obvias (// Step 1: loop over the array, // increment i by 1 encima de i++).
• Apartes de chat: comentarios en segunda persona y tiempo presente dirigidos a ti, quien hace el prompt (// As requested, here is the updated handler, // Sure! Here's the fix, // Note: replace with your actual API key).
• Residuo de elisión / marcador: // ... rest of the code here, // keep your existing logic, // your code here, // TODO: implement error handling dejados en el código fuente confirmado.

// Function to add two numbers and return the result   <- reformula el prompt
function add(a: number, b: number): number {
  // Step 1: add the two numbers                        <- narra lo obvio
  const sum = a + b;
  return sum; // return the sum
}

// As requested, here is the updated handler            <- aparte de chat dirigido a "ti"
export async function handler(req: Req, res: Res) {
  // ... keep your existing validation logic here ...   <- elisión: código real descartado
  // TODO: implement error handling                     <- marcador entregado tal cual
  const user = await db.users.find(req.params.id);
  res.json(user);
}

La línea de elisión es la peligrosa: se lee como documentación pero en realidad es una instrucción para que un humano pegue código que el modelo omitió: aplica el bloque al pie de la letra y la validación existente desaparece en silencio. OX Security encontró "comentarios por todas partes" (Comments Everywhere) —"comentarios en línea excesivos que aumentan drásticamente la carga computacional … y hacen el código más difícil de revisar y mantener"— en el 90–100 % del código generado por IA de su estudio de más de 300 repositorios.

Por qué los modelos lo emiten

• Mimetismo del siguiente token de los corpus de tutoriales. La mezcla de entrenamiento está saturada de entradas de blog, respuestas de StackOverflow y documentación donde cada línea se explica para un aprendiz. El modelo reproduce ese registro didáctico —narración e intención reformulada— porque es la continuación estadísticamente probable, no porque el repositorio circundante lo necesite.
• Filtración del registro de chat / adulación. El RLHF afina a los asistentes para ser explicativos y complacientes en el canal de chat. Ese tono conversacional en segunda persona se filtra al canal de código, produciendo apartes de tipo "Como se solicitó…" y "Nota: deberías…" que carecen de sentido una vez que el código se separa de la conversación.
• Razonamiento narrado como comentarios. Los modelos externalizan su plan ("Paso 1… Paso 2…") como comentarios en línea: filtración de la cadena de pensamiento congelada en el archivo.
• La elisión es una comodidad del chat, mal aplicada. En una respuesta de chat, // ... rest unchanged ... es una forma educada de evitar reimprimir un archivo. Cuando esa respuesta se pega o se aplica automáticamente a un archivo real, la comodidad se convierte en residuo literal, y en pérdida de datos literal.
• Sin contexto del repositorio, reformula el prompt. A falta del ticket, el dominio y el verdadero "porqué", el modelo no tiene nada cierto que decir en un comentario, así que recurre a parafrasear lo único que tiene: tu prompt.

Por qué resulta perjudicial

• Carga de revisión. Cada línea de narración es ruido que una persona tiene que saltarse. El planteamiento de OX: la IA trabaja como "un ejército de desarrolladores júnior con talento pero sin experiencia", y "una revisión de código adecuada simplemente no puede escalar al ritmo de la nueva velocidad de producción"; los comentarios residuo encarecen cada diff justo cuando hay más diffs.
• Corrección / pérdida de datos. Los marcadores de elisión (// ...existing code...) provocan que se descarte código real cuando los bloques se aplican a ciegas.
• Putrefacción de comentarios. Los comentarios que reformulan el prompt duplican en prosa la intención del código; la prosa se desvía a medida que el código cambia y deja documentación activamente engañosa: el clásico olor Comentarios de Fowler, en el que los comentarios hacen de desodorante.
• Incompletitud oculta. // TODO: implement error handling es el modelo señalando que trabajó al borde de su competencia; entregado tal cual, es lógica sin terminar disfrazada de tarea rastreada.
• Indicios de seguridad. // replace with your actual API key normalmente se sitúa junto a una credencial de marcador codificada: el residuo marca exactamente la línea que le importa a un escáner (y a un atacante).

Tácticas de prompting / de generación

• Restringe el registro: "Genera el archivo completo. Nunca abrevies con // ..., // rest of the code o // existing code. No narres pasos: comenta solo la justificación no obvia (el porqué). Sin apartes conversacionales; esto va directo a un repositorio."
• Pide un diff unificado en lugar de un fragmento envuelto en prosa, para que las omisiones sean explícitas y aplicables en lugar de esquivadas con un comentario de elisión.
• Exige que el modelo ejecute el formateador y tu configuración de lint (p. ej. no-warning-comments con términos personalizados) e informe del resultado: cerrar el ciclo de lint y corrección detecta automáticamente el residuo de marcadores y TODO.
• Añade una barrera de grep en pre-commit / CI para los marcadores de residuo (rest of the code, your code here, existing code, As requested, Step \d) y trata los marcadores de elisión como un bloqueo duro, ya que a menudo significan que se descartó código en silencio.

La refactorización

Elimina sin más los apartes de chat y la narración. Cuando un comentario solo reformula qué hace el código, esa es la señal para hacerlo autodocumentado: aplica Extraer método y Renombrar método (o Extraer Variable para una sola expresión) para que el nombre lleve la intención, y conserva solo los comentarios que expliquen un porqué no obvio. Es el consejo de Fowler para el olor Comentarios: cuando sientas la necesidad de escribir un comentario, intenta primero refactorizar para que el comentario sobre.

// antes — residuo del prompt
// Create a function that validates an email address using a regex
function validateEmail(input) {
  // check if the input matches the email pattern
  const re = /^[^@]+@[^@]+\.[^@]+$/;
  // return true or false
  return re.test(input);
}

// después — el nombre carga con la intención; el único comentario explica el porqué no obvio
const EMAIL_RE = /^[^@]+@[^@]+\.[^@]+$/; // deliberadamente laxo: solo detectamos erratas antes del envío, no RFC 5322
const isValidEmail = (input: string): boolean => EMAIL_RE.test(input);

Para el residuo de elisión, nunca apliques el bloque tal cual: compáralo (diff) con el archivo actual y restaura lo que el modelo descartó. Para // TODO: implement …, o bien termina la lógica, o conviértelo en una incidencia rastreada y haz que la compilación falle ante el término de marcador para que no pueda entregarse tal cual.