Tu coding agent asume más riesgo si aplicas el mismo margen de autonomía a todos los cambios

TL;DR

Ya tienes el dedo encima de activar la autonomía total porque aprobar cada comando rompe el ritmo. El problema no es que el coding agent piense demasiado, sino que un modo global concede el mismo margen a una errata y a una migración. Aprenderás a clasificar cada cambio como verde, ámbar o rojo y a colocar el checkpoint humano donde reduce riesgo.

El modo global confunde comodidad con control

La autonomía no debe configurarse solo por herramienta; debe combinar las capacidades de la herramienta con el riesgo del cambio. Un agente puede resolver bien una tarea y, aun así, ejecutar una acción que no debía estar a su alcance.

El fallo técnico aparece porque el permiso global ignora cuatro propiedades locales:

• Alcance: cuántos módulos, contratos o servicios toca.
• Reversibilidad: si basta con revertir un commit o hay datos y efectos externos que reparar.
• Validación: si existe una prueba determinista que actúe como oráculo.
• Efectos externos: red, secretos, despliegues, facturación o escritura en producción.

Aceptar cada operación tampoco resuelve el problema. Las confirmaciones repetidas para acciones inocuas convierten el permiso en ruido y favorecen la aprobación por inercia. La fricción está mal colocada: sobra al editar una prueba local y falta antes de ejecutar una migración.

La solución encaja con el principio de separación de responsabilidades: el modelo propone y ejecuta trabajo acotado, mientras la política del repositorio decide qué operaciones requieren evidencia o autorización.

Una política de autonomía es un contrato del repositorio

El modelo aporta capacidad; la política define autoridad. Son responsabilidades distintas, aunque muchas interfaces las presenten juntas.

Una política de autonomía para coding agents es un contrato versionado que decide qué puede leer, editar, ejecutar y publicar el agente según el riesgo del cambio. No confía en un único modo global: combina alcance, reversibilidad, validación y efectos externos para insertar revisiones humanas justo donde reducen daño.

A 04/07/2026, esta separación ya aparece en las herramientas principales. La documentación de Claude Code distingue modos de lectura, planificación, edición y ejecución autónoma, y advierte que su modo automático no garantiza seguridad ni reemplaza la revisión de operaciones sensibles.

OpenAI separa explícitamente sandbox mode, lo que Codex puede hacer técnicamente, de approval policy, cuándo debe detenerse y preguntar. Su documentación de seguridad para Codex también mantiene la red desactivada y la escritura limitada al workspace en la configuración habitual.

Esto implica que un sandbox no decide si una modificación es correcta. Solo limita el daño posible cuando no lo es.

La regla: clasifica por el riesgo máximo, no por el promedio

Si una sola dimensión es roja, el cambio completo es rojo. Esta es una heurística propia y deliberadamente conservadora para proyectos pequeños y medianos.

• Rojo: hay datos persistentes, autenticación, secretos, CI/CD, producción, pagos o un efecto externo difícil de deshacer. El agente investiga y prepara el plan, pero no ejecuta la operación sensible.
• Ámbar: no hay efecto irreversible, pero el cambio cruza módulos, altera un contrato o carece de una prueba clara. Revisa el plan antes de editar y el diff antes de integrar.
• Verde: el alcance está acotado, el cambio es reversible y existe un comando concreto que demuestra el resultado. Deja editar y probar sin interrupciones.

Sin tests u otro oráculo determinista, normalmente no conviene clasificar el cambio como verde. Si el agente no dispone de un oráculo, la confianza del modelo no sustituye la verificación. Cuando el problema sea el número de iteraciones y no los permisos, aplica un presupuesto de intentos para el coding agent como control independiente.

Artefacto: matriz de autonomía verde, ámbar y roja

Copia esta matriz en AGENTS.md o en la documentación operativa del repositorio. Cada tarea debe declarar su nivel antes de empezar; el agente puede proponerlo, pero no rebajarlo por sí mismo.

Nivel	Úsalo cuando	Evítalo cuando	Margen del agente	Checkpoint y evidencia
Verde	Copy, documentación, tests locales o cambio aislado con comportamiento verificable.	Toca contratos compartidos, permisos, datos o servicios externos.	Leer, editar y ejecutar tests dentro del workspace.	Antes del merge: diff, comando ejecutado y resultado.
Ámbar	Refactor entre módulos, dependencia nueva o aceptación ambigua, pero reversible.	La operación escribe en producción o no existe una recuperación clara.	Investigar y planificar; editar solo tras aprobar el plan.	Antes de editar y antes de integrar: alcance, archivos, tests y riesgo residual.
Rojo	Migraciones, auth, secretos, workflows, pagos, despliegues o acciones externas.	No lo rebajes por tocar pocos archivos o tener un diff corto.	Lectura, diagnóstico, plan y parche propuesto sin ejecutar efectos sensibles.	Autorización humana antes de implementar, ejecutar y desplegar.

Plantilla copiable para cada tarea:

CAMBIO:
ALCANCE Y CONTRATOS AFECTADOS:
REVERSIÓN DISPONIBLE:
ORÁCULO O COMANDO DE VALIDACIÓN:
EFECTOS EXTERNOS:
NIVEL: verde | ámbar | rojo
EL AGENTE PUEDE:
DEBE PARAR ANTES DE:
EVIDENCIA QUE ENTREGARÁ:

La tarjeta obliga a expresar lo que un prompt abierto suele ocultar. Si no puedes completar reversión, oráculo o efectos externos, clasifica la tarea como ámbar hasta investigarla.

Ejemplo funcional: el mismo agente, dos márgenes distintos

Un timeout configurable puede ser verde; una política de reintentos de pagos debe empezar en rojo. La diferencia no está en la dificultad aparente, sino en el efecto de equivocarse.

Caso verde: timeout de un cliente FastAPI

El cambio añade una variable de entorno, conserva el valor anterior como predeterminado y modifica una prueba unitaria. El agente puede editar y validar con pytest tests/unit/test_client.py -q. Debe entregar el diff y la salida del test, pero no necesita parar tras cada archivo.

Con Claude Code, un punto de partida concreto es claude --permission-mode acceptEdits. Con Codex, usa codex --sandbox workspace-write --ask-for-approval on-request. Mantén bloqueados red, secretos y rutas fuera del workspace.

Caso rojo: reintentos de un webhook de pagos

Aunque el parche ocupe pocas líneas, un reintento incorrecto puede duplicar una operación externa. Si también incluye una migración para registrar intentos, el rollback del código no restaura por sí solo el estado de los datos.

Empieza con claude --permission-mode plan o codex --sandbox read-only --ask-for-approval on-request. Exige al plan idempotencia, migración reversible, prueba con dobles del proveedor y procedimiento de recuperación. La ejecución contra infraestructura queda fuera del margen del agente.

Los checkpoints fallan si solo preguntan continuar

Un checkpoint sin evidencia preparada suele aportar menos control y puede limitarse a una pausa formal. La revisión debe recibir información suficiente para tomar una decisión sin reconstruir toda la sesión.

• Clasificar por número de archivos: dos líneas en autorización pueden tener más impacto que un refactor de veinte archivos.
• Permitir que el agente se apruebe: puede sugerir el nivel, pero un conflicto de interés aparece si también decide que su resultado cumple.
• Mostrar solo un resumen: exige diff, comandos, resultados y riesgos pendientes. El resumen narrativo puede omitir el detalle que importa.
• Ejecutar CI privilegiada sin revisar: GitHub recuerda que los workflows pueden acceder a secretos y recomienda inspeccionar los cambios antes de autorizarlos en pull requests creadas por agentes. Consulta su guía oficial para revisar la salida de Copilot.
• Relajar todo tras un bloqueo: autoriza la operación concreta o cambia el plan. No conviertas una excepción en permiso global.

La revisión humana tampoco debe buscar cada posible bug desde cero. Una revisión de código con IA bien repartida usa automatización para reunir evidencia y reserva la decisión humana para intención, contratos y riesgo residual.

Cuándo esta matriz no aplica

No necesitas el ritual completo para código desechable dentro de un entorno aislado. Un prototipo local sin credenciales, datos reales, red ni intención de integrarse puede trabajar con autonomía amplia, siempre que eliminar el entorno sea una recuperación suficiente.

En el extremo contrario, la matriz tampoco basta para software regulado, sistemas con impacto físico o procesos que exigen separación formal de funciones. Ahí necesitas controles organizativos, auditoría, revisores autorizados y políticas de despliegue externas al agente.

Si el agente navega, consume issues o usa herramientas MCP, la clasificación de autonomía no reemplaza la defensa frente a contenido hostil. Aplica por separado una defensa por capas contra prompt injection.

Por regla general, un incidente urgente no justifica permisos globales; cualquier acceso de emergencia debe ser temporal, aislado y auditado. Reduce el alcance, trabaja en una rama, conserva un rollback probado y aumenta la frecuencia de checkpoints. La presión temporal hace más valiosa una puerta clara, no menos.

Preguntas frecuentes

¿Qué diferencia hay entre un sandbox y un checkpoint humano?

El sandbox limita qué recursos puede tocar el coding agent. El checkpoint decide si el cambio propuesto merece continuar según intención, impacto y evidencia. Necesitas ambos cuando una acción técnicamente permitida sigue teniendo riesgo de negocio.

¿Debe un coding agent hacer merge por sí solo?

En repositorios compartidos, conviene reservar el merge autónomo para cambios verdes con validaciones deterministas y protecciones de rama externas. Para cambios ámbar o rojos, separa la generación del parche de la aprobación e integración.

¿Cómo clasifico un cambio pequeño que modifica autenticación?

Como rojo. El tamaño del diff no reduce el alcance semántico de una decisión de autenticación, autorización o gestión de secretos.

El margen correcto importa más que el modo automático

Un coding agent no necesita libertad total ni confirmaciones constantes. Necesita una frontera distinta para cada cambio: verde cuando puede demostrar y revertir, ámbar cuando debe acordar el plan y rojo cuando aparecen datos, seguridad o efectos externos. La idea que conviene recordar es simple: como regla práctica, detén al agente antes del primer punto donde un error deje de resolverse de forma fiable con un revert.