Pregunta qué NO tocó tu agente
Pregúntale a tu IA qué decidió no cambiar a propósito. Es la pregunta más útil que le puedes hacer a un agente de código, y casi nadie la hace. Revisas lo que está en el diff — pero el riesgo vive en lo que el agente tocó de paso sin avisar, o en lo que decidió dejar quieto sin decírtelo.
El scope creep se esconde dentro de un diff verde y enorme
A los agentes les encanta arreglar cosas que nunca pediste. Pides una corrección de bug; recibes la corrección, más un refactor de "ya que estaba aquí", un bloque de imports reformateado y una variable renombrada en otros tres archivos. Cada edición parece razonable por separado. Juntas convierten una corrección de 20 líneas en un diff de 300 — y la atención del revisor no crece al mismo ritmo.
Los datos son contundentes sobre lo que eso cuesta. La tasa de detección de defectos cae con fuerza a medida que crece el cambio: las revisiones de cambios pequeños atrapan la gran mayoría de los defectos, mientras que pasadas las ~400 líneas modificadas se detectan muchos menos defectos por línea a medida que aparece la fatiga. La concentración del revisor decae marcadamente después de unos 60 minutos. Un diff inflado no solo molesta: esconde bugs de forma medible.
Haz que cada cambio termine con un resumen
La solución es una instrucción permanente, no algo que pides una sola vez. Dile al agente que cada cambio termina con tres listas cortas:
| Sección | Qué responde |
|---|---|
| Cambios hechos | Las ediciones que pediste, archivo por archivo. |
| Cosas que no toqué | Código cercano que dejó quieto a propósito — y por qué. |
| Dudas | Lo que no está seguro, lo que no pudo verificar, el riesgo a seguir. |
La lista del medio es lo importante. "Cambios hechos" repite el diff que ya ves. "Cosas que no toqué" es el agente narrando el límite que trazó — la función vecina que notó fea y dejó quieta, la config que eligió no migrar, el test que no actualizó. Ahí es justo donde aparecería la renovación no invitada, así que su ausencia es la prueba que buscabas.
Ponlo en tu CLAUDE.md, AGENTS.md o system prompt para que se dispare en cada tarea:
End every change with three lists:
1. Changes made — file by file.
2. Things I didn't touch — nearby code left alone on purpose, and why.
3. Concerns — anything unverified or risky to follow up on.
Do not make changes outside the stated task without flagging them here.Por qué funciona
Un "listo" sin resumen no te dice nada accionable. Un cierre estructurado convierte al agente en su propio primer revisor. La lista de "no toqué" hace visible el scope creep antes que tu revisor humano, y prueba que el agente se mantuvo en su carril en vez de renovar sin permiso. La lista de dudas atrapa el honesto "no pude correr los tests" o "esto asume que la cache está tibia" que un agente de tono seguro normalmente entierra.
También combina con la disciplina de diffs pequeños que señala la investigación: un objetivo por cambio, y un cierre que nombra todo lo que quede fuera de ese objetivo. Si la lista de "no toqué" empieza a llenarse de cosas que el agente sí tocó, esa es tu señal para dividir la tarea.
Movidas avanzadas
- Haz que el revisor lea la lista, no solo el diff. Si usas un subagente de revisión, pásale las tres listas y que compare "cambios hechos" contra la tarea declarada — cualquier cosa en el diff que no esté en la lista es scope creep sin marcar.
- Convierte las dudas en tests. Cada ítem de la lista de dudas es un candidato a test o a ticket de seguimiento. No dejes que se evapore al cerrar la sesión.
- Vigila cuánto crece la lista de "no toqué". Una lista corta significa un cambio enfocado. Una larga significa que el agente estuvo tentado muchas veces — aprieta la tarea o el prompt.
- Pídela de forma retroactiva. Incluso en un cambio ya hecho, "lista lo que dejaste sin cambiar a propósito cerca de este código, y por qué" saca el límite a la luz antes de mergear.
Recursos
- Best practices for Claude Code — un objetivo por cambio, y cerrar con qué cambió, qué se verificó y qué queda incierto.
- Code Review for Claude Code — revisar diffs contra el alcance declarado para que nada fuera de la tarea se cuele.
- Does PR size actually matter? (cubic) — datos sobre cómo cae la detección de defectos al crecer los diffs.
- The impact of PR size on code review quality (Propel) — desglose de la tasa de detección por tamaño de cambio.
- Pull Request Size Matters (BSSw) — la guía clásica de ~200–400 LOC por revisión.