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" en el 90–100 % del código generado por IA en su estudio de más de 300 repositorios, describiéndolos como marcadores que "parecen útiles pero sobre todo sirven a la propia IA, abarrotando los 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. OX caracteriza los comentarios como "marcadores internos para navegar los límites de contexto… dependencia de la memoria a corto plazo más que de la comprensión real".

Por qué resulta perjudicial

• Carga de revisión. Cada línea de narración es ruido que un humano debe leer por encima. El planteamiento de OX: la IA "programa como un desarrollador júnior" a velocidad de máquina, y la revisión humana "no puede escalar para igualar la producción de la IA": 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 la intención del código en prosa; la prosa se desvía a medida que el código cambia, dejando documentación activamente engañosa: el clásico olor de Fowler de los Comentarios como 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 bucle de "validar con el linter" detecta automáticamente el residuo de marcador/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 los apartes de chat y la narración sin más. Cuando un comentario simplemente reformula qué hace el código, esa es la señal para hacer el código autodocumentado: aplica Extraer función y Renombrar para que el nombre cargue con la intención, y conserva solo los comentarios que expliquen un porqué no obvio (Fowler: Elimina los comentarios que son desodorante para malos nombres).

// 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.