se centra en lo que pueden hacer.
La autonomía se plantea como el objetivo: darles herramientas, darles acceso, dejarlos correr.
Cuanta más libertad, mejor será el resultado.
Ese encuadre es en su mayor parte preciso. Utilizo agentes a diario. Realmente han aumentado mi producción. ¡Soy un creyente!
Y también perdí dos horas de trabajo a través de un agente que estaba haciendo exactamente lo que le pedí.
Estaba trabajando en la limpieza de una rama de funciones.
La descripción de la tarea decía “eliminar archivos no utilizados y limpiar el repositorio”. El agente interpretó “no utilizado” de manera amplia, eliminó un directorio de configuración que no había tocado en meses pero al que todavía hacía referencia en el script de implementación y continuó.
Lo capté durante la revisión de diferencias. La configuración no estaba en control de versiones. Dos horas reconstruyéndolo desde la memoria y el historial de git.
La tarea era clara y el agente siguió las instrucciones, el único problema fue que nada le decía dónde detenerse.
Saber qué tareas controlar es parte de la buena gestión de los agentes. Dales total libertad en la categoría equivocada y pasarás la tarde deshaciendo lo que les llevó treinta segundos.
¡Hola! Mi nombre es Sara Nóbrega y te enseño cómo convertirte en un usuario avanzado de IA en Learn AI. ¡Gratis para suscribirse!
Lo que el agente nunca debe tocar solo
Algunas tareas son reversibles. Por ejemplo, se puede revertir una función refactorizada o se puede eliminar una nueva prueba unitaria. El costo de un error es bajo.
El costo de recuperación varía según la tarea. Una función refactorizada tarda unos segundos en revertirse; simplemente revierte el compromiso, pero una tabla de producción eliminada puede llevar toda la semana, si es que la recuperación es posible.
La pregunta antes de ejecutar una tarea: ¿se puede deshacer?
En caso afirmativo, deje que el agente se mueva. Si no, agregue un punto de control antes de que se ejecute.
Aquí está la matriz de permisos con la que trabajo:
Las categorías que siempre deberían requerir un ser humano
Algunas categorías requieren un punto de control humano independientemente de qué tan bien especificada esté la tarea.
El riesgo de cometer un error es demasiado alto y el costo de recuperación demasiado elevado como para dejar que un agente decida por sí solo.
Operaciones destructivas de archivos
`rm -rf`, `git clean -fd`, `git reset –hard`.
Estos eliminan o descartan trabajos que pueden no ser recuperables.
Un agente los ejecutará si la descripción de la tarea implica limpieza.
Uno ejecutó `git clean -fd` en medio de una refactorización porque la tarea decía “limpiar archivos temporales”.
Mi trabajo no comprometido había desaparecido. No hubo ningún mal funcionamiento, ya que el agente hizo exactamente lo que decían las palabras. La salvaguardia es una lista de bloqueo explícita con un paso de confirmación, sin confiar en que el agente infiera dónde termina la “limpieza”.
2. Escrituras y migraciones de bases de datos
Cualquier DELETE sin una cláusula WHERE, cualquier DROP o TRUNCATE, cualquier migración de esquema que toque datos de producción.
Un error tipográfico en una cláusula WHERE puede borrar una tabla. Una migración que no funciona correctamente puede dañar datos que son imposibles de reconstruir. Revisa siempre antes de correr.
3. Infraestructura de la nube
`terraform apply`, `kubectl delete`, `aws iam *`, `gcloud iam *`.
Los cambios de infraestructura afectan a los sistemas activos y, a menudo, a otros equipos. Los cambios de permisos son especialmente peligrosos porque el daño puede ser invisible hasta que algo falla.
4. Implementaciones de producción
Cualquier implementación en un entorno de producción debe pasar por un paso de revisión humana, incluso si el código fue generado por un agente.
Las canalizaciones de CI/CD pueden ejecutar la salida del agente automáticamente, y eso está bien. La decisión de implementar la producción es suya.
Sabes qué hay en vuelo, qué incidencias están abiertas, qué mantenimientos están programados. El agente no tiene nada de ese contexto y no puede solicitarlo en la mitad del proceso.
5. Lógica de autenticación y seguridad
Flujos de autenticación, reglas de autorización, manejo de tokens, gestión de sesiones.
Los errores aquí no aparecen en las pruebas unitarias, aparecen en los informes de incidentes, a veces meses después.
Un agente que escriba la lógica de autenticación producirá algo que parece correcto y pasa por el camino feliz.
Los casos peligrosos son las condiciones extremas: un token que no caduca bajo una secuencia específica de llamadas API, una ruta que pasa por alto el middleware cuando falta un parámetro.
Eso es exactamente lo que las pruebas unitarias pasan por alto y lo que detecta la revisión de seguridad. Cada cambio de autenticación necesita un ser humano que busque específicamente esas brechas, no uno que esté satisfecho con que se haya recorrido el camino feliz.
6. Secretos, archivos `.env`, claves API
Un agente que lee o escribe credenciales crea un riesgo de exposición. Mantenga esta categoría fuera de los límites de forma predeterminada y manéjela manualmente.
git push –force se encuentra en su propia categoría porque reescribe el historial en el control remoto. Una vez presionadas, las sucursales locales de otros contribuyentes divergen. La recuperación es dolorosa y a veces imposible.
Los humanos también deberían tener cuidado con todos estos comandos. Los agentes simplemente hacen que sea más fácil activarlos por accidente, enterrados dentro de una secuencia más larga de pasos que de otro modo serían seguros.
AGENTES.md: redactar el contrato
Ofrezca a los agentes una estructura específica desde el principio. Un archivo AGENTS.md en la raíz de su repositorio le dice al agente qué es el proyecto, cómo ejecutarlo y qué no puede tocar sin preguntar.
Un AGENTS.md vago le ofrece un agente que llena los vacíos con conjeturas. Aprendí esto en una base de código que no tenía AGENTS.md en absoluto.
La tarea era “organizar la estructura del proyecto”. El agente movía archivos entre directorios basándose en convenciones de nomenclatura que tenían sentido para él. Todo lo que hacía referencia a esos caminos se rompió.
La tarea le llevó al agente veinte minutos; La limpieza me llevó dos horas. Tres líneas de limitaciones de alcance lo habrían impedido por completo.
Aquí está la plantilla que uso:
# AGENTES.md ## Proyecto
[Brief description of the project and tech stack]
## Configuración \`\`\`bash # Instalar npm install # o pip install -r requisitos.txt # Ejecutar npm run dev # Prueba npm test # Lint npm run lint \`\`\` ## Reglas de codificación: realice cambios mínimos. No refactorices código no relacionado. – Si el comportamiento cambia, agregue o actualice pruebas. – No toque archivos fuera del alcance de la tarea. – Mantenga las diferencias legibles. Una preocupación por confirmación. ## Reglas de seguridad Pregunte antes de ejecutar cualquier comando en block_commands.md. Si no está seguro de si un comando es seguro, deténgase y pregunte. ## Definición de hecho – Pruebas aprobadas – La diferencia se explica en una oración – Informe final proporcionado (ver más abajo) ## Formato del informe final Después de cada tarea, proporcione: 1. Resumen de cambios 2. Archivos modificados 3. Pruebas ejecutadas y resultado 4. Riesgos o suposiciones 5. Todo lo que no se haya completado “`
El archivo complementario, block_commands.md, enumera exactamente lo que necesita aprobación humana antes de ejecutarse:
# block_commands.md ## Operaciones destructivas de archivos – rm -rf – git clean -fd – git reset –hard ## Operaciones Git – git push –force – git push –force-with-lease ## Operaciones de base de datos – DROP TABLE – TRUNCATE TABLE – DELETE sin cláusula WHERE – Cualquier migración que altere un esquema de producción ## Nube/infraestructura – terraform apply – kubectl delete – aws iam * – gcloud iam * ## Secretos: cualquier comando que lea o escriba archivos .env: cualquier comando que toque claves o credenciales API
Cuando AGENTS.md es vago, el agente adivina. Cuando es específico, el agente lo ejecuta, por lo que el archivo es su contrato. Escríbalo antes de comenzar la tarea, no después de que algo se rompa.
Consulte mis dos últimos artículos donde puede aprender cómo darle a su IA un contexto ilimitado y explorar seis decisiones difíciles comunes que los ingenieros de IA deben tomar en producción.
El bucle de dos agentes
Para cualquier cosa de complejidad media o superior, no use un agente, use dos.
El Agente 1 se implementa. Reseñas del Agente 2. Entonces el Agente 1 aplica sólo la retroalimentación crítica.
Aviso del implementador:
Eres un ingeniero de software senior que implementa una tarea específica. Tarea: [describe the task]
Contexto: [link to AGENTS.md or paste relevant sections]
Reglas: – Realizar cambios mínimos. – Manténgase dentro del alcance. – No refactorices código no relacionado. – Agregar pruebas si el comportamiento cambia. – Cuando haya terminado, proporcione un informe final: resumen, archivos modificados, pruebas realizadas, riesgos, cualquier cosa incompleta.
Mensaje del revisor:
Usted es un revisor de código sin ningún apego a la implementación. Revisa esta diferencia: [paste diff]
Verifique: – Errores y casos extremos – Pruebas faltantes – Problemas de seguridad – Cambios de comportamiento no deseados – Cualquier cosa fuera del alcance indicado Salida: – Problemas críticos (deben solucionarse) – Problemas menores (opcional) – Cualquier cosa que usted marcaría para un humano No reescriba el código. Marcar, no arreglar.
El agente revisor no tiene ninguna inversión egoica en el código. Busca errores, casos extremos, cobertura de pruebas y problemas de seguridad sin intentar rehacer el trabajo.
La revisión del código es la forma de detectar lo que se perdió. El ciclo de dos agentes es el mismo proceso, automatizado.
El informe final
Requerir un informe final para cada tarea del agente:
1. Resumen de cambios
2. Archivos cambiados
3. Pruebas realizadas y resultado.
4. Riesgos o supuestos
5. Todo lo que no se haya completado
Esto hace que el agente sea responsable. Si no puede resumir lo que hizo en términos claros, es una señal de que la tarea no estuvo limpia.
También crea documentación sin que usted la escriba manualmente. Los informes se apilan. Cuando algo se rompe una semana después, puedes rastrear exactamente qué cambió y por qué.
El trabajo poco glamoroso
El revuelo en torno a los agentes de IA llegó para quedarse y, en su mayor parte, se ganó. Aumentan su producción.
Los profesionales que obtienen el máximo provecho de ellos son los que hicieron el trabajo de configuración: escribieron AGENTS.md, pensaron en los niveles de permiso, crearon la lista de comandos bloqueados y configuraron el bucle de dos agentes.
Los agentes funcionan bien cuando tienen instrucciones claras. Esa parte depende de ti.
¡Gracias por leer!
Puedes encontrarme en LinkedIn y Substack, donde comparto más detalles sobre AI y LLM.