English

Nunca le pases tu conclusión a un agente revisor

Tu revisor de código con IA te está dando la razón a propósito.

Cuando le preguntas a un agente "¿esto está bien?", ya le dijiste la respuesta que esperas. Los modelos de lenguaje son sensibles al encuadre: la forma en que planteas la pregunta inclina la respuesta hacia el resultado que tu redacción sugiere. Le entregas tu conclusión y recibes de vuelta una validación bien argumentada de esa conclusión, no un juicio independiente. El teatro de la revisión es real; el escrutinio no.

Por qué el encuadre decide la respuesta antes de empezar

Un agente optimiza para dar una respuesta que encaje con el prompt. "¿Se ve correcto?" induce acuerdo; "confirma que está listo para publicar" induce un sello de goma. Es el mismo problema de adulación (sycophancy) documentado en asistentes ajustados con RLHF: los modelos tienden a coincidir con la postura planteada en vez de rebatirla. Un revisor que hereda tu encuadre hereda tus puntos ciegos. Si ya pudieras ver la falla, la habrías corregido, así que un revisor que te refleja no aporta nada.

El mecanismo: dale el artefacto, retén el veredicto

Separa lo que el revisor necesita de lo que lo sesgaría.

Entrégale:

• El artefacto a revisar (el diff, la función, el documento de diseño).
• El contrato que debe cumplir (la especificación, la interfaz, los criterios de aceptación).

Retén:

• Tu propia conclusión ("creo que está correcto").
• Cualquier pista de que quieres aprobación.

Luego define una tarea adversarial. En lugar de "¿esto está bien?", pídele:

Review this change against the contract below.
Assume the author is overconfident and has missed something.
List concrete defects: correctness, edge cases, contract violations.
Do not comment on what is right. Only surface what is wrong.

Ahora el revisor tiene que reconstruir de forma independiente si el artefacto cumple el contrato, en vez de confirmar un veredicto que tú le diste.

Encuadre de aprobar vs encuadre de refutar

Movidas avanzadas

• Dale el contrato, no la intención. Un revisor que verifica contra una especificación escrita detecta la desviación; uno al que le dices "el autor quería X" simplemente confía en el autor.
• Pide defectos, no un puntaje. Un "8/10" numérico esconde el único bug que importa. Una lista de hallazgos concretos es accionable.
• Corre el revisor en un contexto nuevo. Si la misma sesión que escribió el código también lo revisa, defiende su propio razonamiento. Un agente limpio no tiene ego que proteger.
• Que refutar sea el objetivo. Sesga la revisión para refutar el artefacto, no para aprobarlo. Los hallazgos que sobreviven a un intento honesto de romperlo son los que vale la pena creer.

Recursos

• Anthropic — Adulación y direccionabilidad en modelos de lenguaje
• OpenAI — Guía de prompt engineering
• Google — People + AI Guidebook (diseñar para la revisión humana)
• Simon Willison — Notas sobre usar LLMs para revisar código