Los equipos de ingeniería que evalúan agentes de codificación suelen empezar con la pregunta equivocada. Quieren saber qué tan autónomo puede llegar a ser el agente. ¿Qué parte del pipeline puede controlar? ¿Puede escribir la especificación, editar el repositorio y desplegar en producción sin molestar a nadie? Las demos facilitan esta obsesión. Ves un flujo de trabajo impecable donde un solo prompt desencadena una cascada de ediciones y despliegues, y el instinto es perseguir esa misma capacidad dentro de tu propia organización. Pero el glamour es un pésimo principio de diseño. Las mejores preguntas son mucho menos emocionantes: ¿quién le dio autoridad a esta cosa?, ¿qué sistemas puede tocar realmente? y ¿qué sucede cuando, inevitablemente, se equivoca?

La trampa de la autonomía

La autonomía emocionante es una trampa. Nos entrena para celebrar bots que generan especificaciones, modifican repositorios y despliegan código mientras afirman con calma que la tarea ha terminado. Eso no es ingeniería. Es un salto de fe con acceso a la shell. El trabajo en sí mismo se vuelve casi demasiado fácil de producir. Cualquier modelo puede generar código, documentación o planes de arquitectura en segundos. Pero el costo real en el desarrollo de software nunca ha sido la velocidad de escritura. Siempre ha sido la validación, la revisión y la decisión cuidadosa de decir: sí, esto es correcto y es seguro lanzarlo. El trabajo generado es barato. La aprobación es cara. Las empresas que descubran cómo gestionar la aprobación de forma limpia y consistente serán las que realmente lancen sistemas fiables.

Por qué falla la autorevisión

Los riesgos aparecen en patrones predecibles. Un modelo redacta un plan y luego evalúa si ese plan es bueno. Un agente edita tu base de código y te explica por qué sus cambios son seguros. Una herramienta ejecuta un comando y pide perdón en lugar de permiso. Cada uno de estos representa el mismo fallo fundamental. Si un agente produce una especificación, algo ajeno a ese agente debe darle el visto bueno antes de que se convierta en una verdad. Si un agente modifica código, un proceso separado debe inspeccionar el diff. Permitir que el generador actúe como su propio validador no es un atajo. Es un error estructural disfrazado de conveniencia.

Los prompts no son sistemas de permisos

No puedes asegurar un agente con una redacción ingeniosa. Decirle a un modelo que sea cuidadoso o que pregunte antes de borrar algo no crea un límite. Los prompts no son sistemas de permisos. Antes de permitir que un agente se acerque siquiera a producción, necesitas un inventario honesto de sus capacidades. ¿Puede leer todo el repositorio? ¿Puede ejecutar comandos de shell? ¿Puede abrir un navegador? ¿Puede extraer datos de clientes a su ventana de contexto? La mayoría de los equipos no conocen las respuestas completas. Asumen que la herramienta está confinada a un sandbox cuando, en realidad, tiene acceso de escritura a rutas críticas. Mapea primero la superficie de exposición. Luego construye los muros.

Construye un sistema de control por niveles

Una vez que entiendas lo que el agente puede hacer, diseña un sistema de control que relacione el riesgo con la fricción. Las acciones de bajo riesgo, como actualizar la documentación interna o dar formato consistente al código, pueden ejecutarse automáticamente. Las acciones de riesgo medio, como refactorizar un módulo o añadir una nueva dependencia, deben pasar por un punto de control donde un humano o una suite de pruebas verificada confirme el movimiento. Las acciones de alto riesgo —desplegar en producción, modificar la infraestructura o acceder a datos sensibles— necesitan un aprobador independiente que no haya participado en la generación. Cada una de las acciones debe dejar un registro de auditoría. Deberías poder reproducir exactamente qué archivos se leyeron, qué herramientas se invocaron y qué decisiones se tomaron. El desarrollo agéntico no es una licencia para saltarse las revisiones. La fricción aburrida es una característica. Una puerta de aprobación adecuada actúa como un disyuntor cuando las cosas empiezan a desviarse.

Ajusta el límite al riesgo

Calibra tus límites según el peligro real. Convertir cada pequeño ajuste de formato Markdown en una ceremonia de cumplimiento detendrá a tu equipo. Pero tratar las acciones de alto riesgo como inofensivas porque el agente parece seguro de sí mismo es igualmente insensato. El objetivo es un control proporcionado, no una restricción teatral.

Mantén los artefactos pequeños y observables

Los sistemas de agentes más útiles no intentan impresionarte con ejecuciones autónomas masivas. Producen artefactos pequeños y revisables. Un plan preciso. Un diff enfocado. Un log legible. Las ejecuciones autónomas gigantes son pesadillas de depuración. Cuando algo falla tras una sesión de agente de cincuenta archivos, tienes que desenredar la intención, la ejecución y los efectos secundarios, todo a la vez. Mantén el radio de impacto pequeño. Insiste en saber qué archivos leyó el agente y qué herramientas llamó. Los sistemas observables son sistemas mantenibles. La autonomía de caja negra es solo deuda técnica con mejor marketing.

Seis preguntas antes de conceder acceso

Antes de entregarle cualquier responsabilidad real a un agente, somete tu configuración a una prueba de presión con seis preguntas difíciles.

  • ¿Qué capacidades tiene realmente el sistema?
  • ¿Qué acciones están denegadas por defecto, bloqueadas a nivel de infraestructura en lugar de simplemente desaconsejadas mediante una frase cortés en el prompt del sistema?
  • ¿Qué acciones requieren aprobación explícita?
  • ¿Qué artefactos se congelan antes de que el agente los consuma, para que no pueda manipular silenciosamente sus propios inputs?
  • ¿Qué validador, totalmente independiente del generador, juzga el resultado final?
  • ¿Qué log demuestra, sin ambigüedades, lo que realmente sucedió?

Esto es higiene de ingeniería básica. Separa el generador del validador. Mantén la autoridad humana en el límite.

La verdadera prueba

Ahí