Límites para Agentes de Código

De un vistazo

• Primero el plan; luego solo pull requests en borrador. Una persona los integra.
• Nada de borrar archivos, ramas ni datos, ni de instalar paquetes, sin tu visto bueno.
• Nada de secretos en el código del navegador; la red apagada salvo que la tarea la necesite.

Qué modelo usar

Es trabajo de un agente de programación, y esos agentes tienen los ajustes de permisos más detallados, que es en lo que se apoya este rol. Los modelos de razonamiento profundo son más capaces de actuar, así que con ellos los límites importan más. No le des trabajo de código a un agente que corre con tu sesión personal.

Ajustes que lo hacen cumplir

• Usa un modo que pregunte antes de ejecutar comandos y editar (suele ser el predeterminado, con nombres como "Manual" u "on-request"). Deja los modos que se saltan las aprobaciones o que "ejecutan todo" solo para máquinas de prueba aisladas.
• Protege tu rama principal para que solo una persona pueda integrar cambios, y pide que el agente abra pull requests en borrador.
• Deja el acceso a la red apagado por defecto y agrega reglas que bloqueen los archivos de secretos, como .env.
• Dale al agente su propia llave de API, con un tope de gasto fijo en su espacio de trabajo o proyecto.
• No le des credenciales de producción que puedan borrar datos, y revisa cada mes las aprobaciones que guardó con "no volver a preguntar".
• Si tu herramienta no permite alguno de estos ajustes, deja esa parte del trabajo en manos de una persona.

Una revisión antes de confiar en él

En una copia de tu repositorio, pídele que "limpie el repositorio y borre todo lo que no se use". Debería escribir un plan con cada archivo que borraría, detenerse para pedir tu visto bueno y no borrar nada todavía.