Bloquea la primera edición de tu IA
Tu IA edita archivos que nunca leyó de verdad.
Un agente reescribirá con gusto una función a partir de su nombre y una suposición de lo que hace, sin cargar nunca los llamadores, las pruebas ni los datos reales que fluyen por ella. La edición se ve segura y suele estar mal, porque el modelo rellenó el vacío con una suposición plausible en vez de un hecho. Esto no se arregla preguntándole "¿estás seguro?". La autoevaluación de un LLM no detecta de forma confiable su propio contexto faltante. Lo que cambia la salida es la investigación misma.
Por qué "¿estás seguro?" no funciona
Pedirle a un modelo que revise su propio razonamiento tiende a producir una reafirmación segura, no un reexamen genuino. El modelo no tiene información nueva, así que defiende la suposición. Lo único que convierte una suposición a ciegas en una edición correcta es cargar el contexto que faltaba desde el principio. Así que no audites la conclusión: fuerza la investigación antes de que exista la conclusión.
El mecanismo: una barrera antes de la primera mutación
Niégate a dejar que el agente haga su primera edición hasta que haya producido hechos concretos y verificables sobre el código que quiere cambiar. Exige los tres:
- Lista los importadores. ¿Quién llama a esto? Un cambio a una función con doce llamadores es un cambio distinto que uno con cero.
- Nombra las funciones públicas afectadas. ¿Qué parte de la superficie pública toca esto y cuál es su contrato?
- Muestra las formas de datos reales. Pega los tipos, registros o payloads de ejemplo reales que fluyen, no una forma supuesta.
La regla es simple: sin hechos, no hay edición.
Before editing <file>, produce:
1. Importers of the symbol you will change (grep the tree, list each).
2. Public functions this change affects, with their signatures.
3. Real data shapes: actual types / a sample payload, not assumed.
Do not propose an edit until all three are filled in from the code.Suposición a ciegas vs investigación forzada
| Sin barrera | Con la barrera |
|---|---|
| Edita a partir del nombre de la función | Lee los llamadores antes de tocar nada |
| Supone la forma de los datos | Muestra los tipos y payloads reales |
| Rompe en silencio un llamador que nunca vio | Ve primero los doce importadores |
| "Se ve correcto", pero está sutilmente mal | Hechos sobre la mesa, la edición está fundamentada |
La investigación forzada saca a la luz el contexto que convierte una suposición a ciegas en una edición correcta, y lo hace antes de que cambie cualquier archivo, así que una suposición equivocada te cuesta una frase, no un build roto.
Movidas avanzadas
- Conecta la barrera a la capa de herramientas. Un hook que bloquea la herramienta de escritura hasta que exista una nota de investigación es más fuerte que una instrucción cortés que el agente puede saltarse.
- Exige evidencia, no afirmaciones. "Revisé los llamadores" no es prueba; un resultado de grep pegado sí lo es.
- Acota la investigación al radio de impacto. Los importadores y la superficie pública definen qué puede romperse: eso es exactamente lo que el agente debe enumerar.
- Reutiliza la investigación como contrato de revisión. Los hechos que reunió al inicio son la lista de verificación que usa un revisor después.
Recursos
- Anthropic — Hooks de Claude Code (controlar el uso de herramientas)
- Anthropic — Construir agentes efectivos
- OpenAI — Function calling y uso de herramientas
- Simon Willison — Notas sobre programar con LLMs
¿Desarrollas sistemas de IA o en la nube? Yeda AI audita y refuerza pipelines de LLM y contenedores en producción. Hablemos · Lee el blog