En la mayoría de las conversaciones sobre ingeniería de agentes, la acción ha pasado de dar instrucciones a operar. Esto es lo que se vislumbra en la frontera: fábricas de software, objetivos, bucles, sesiones en segundo plano, subagentes, ganchos, entornos aislados, agentes que aprueban agentes. Para muchos creadores del futuro, este comportamiento vendrá integrado en los productos desde el primer día: Claude Code y Codex muestran este cambio directamente.
Desde el punto de vista del ingeniero, usarás baja autonomía para limitar riesgos y aumentar la reversibilidad, pero mayor autonomía para actividades explícitas, y flotas de agentes paralelos que refactorizan de forma segura bases de código enormes. La pregunta fundamental sobre una acción siempre es: ¿qué nivel merece esta tarea y qué verificación hace que ese nivel sea defendible?
El borde de la frontera es el agente gestor que se activa cuando corresponde, delegando en sus ayudantes mientras verifica continuamente sus resultados, y regresa solo con las decisiones que debe tomar un humano. Quienes usan este tipo de configuración probablemente ya estén ejecutando cientos o miles de agentes, principalmente en bases de código que evolucionan constantemente. Como ocurre con casi todo lo relacionado con la autonomía, la percepción de la escala sigue siendo diferente para cada persona.
La escala mencionada con más frecuencia proviene de la escalera de un solo eje de Steve Yegge, descrita en "Welcome to Gas Town" y en The Pragmatic Engineer. Es una buena referencia si quieres un número que indique qué tan nativo eres de la IA: la escalera te da un número único para medir tu confianza en un solo agente. Aquí tienes una versión:
A principios de 2026, incluso cuando el trabajo comenzaba a pasar de la delegación a la orquestación, esto era un buen indicador para medir el riesgo. Sin embargo, hoy en día, muchos conjuntos de habilidades pueden tener más importancia y apalancamiento cuando puedes ejecutar varios agentes a la vez. Un solo escalón no puede ayudar a medir la habilidad con múltiples agentes.
En cambio, casi todos los debates sobre autonomía que he visto combinan dos preguntas que deberían separarse: ¿qué tan lejos de nosotros mismos dejamos ir a este único agente y cuál es nuestra habilidad para coordinar muchos agentes?
Para capturar estas dos dimensiones por separado, usaremos dos ejes: agencia y orquestación.
En el eje de agencia, el nivel bajo incluye sugerir acciones candidatas y esperar una decisión.
El nivel medio significa que el agente está trabajando en una tarea específica, pero delimita lo que hace e informa constantemente lo que hace junto con evidencia, para que puedas seguir guiándolo.
En el extremo de agencia alta, el agente trabaja hacia un objetivo, experimenta, aprende, prueba, encuentra formas de resolver un problema, se bloquea, hace preguntas, prueba diferentes enfoques y devuelve todo este trabajo con evidencia.
En el eje de orquestación, el nivel bajo significa un agente, un hilo. En el nivel medio, tienes varios agentes, cada uno trabajando en su propio árbol de trabajo, posiblemente hacia diferentes objetivos, pero aislados. En el nivel alto, tienes un orquestador que puede tomar un backlog, un rastreador de incidencias, un cronograma u otra cola, y convertirlo en trabajo continuo, y solo necesitas intervenir cuando algo falla: "gestión por excepción". Los productos y funciones que incorporan estas ideas incluyen:
- Los modos /plan, /goal, /loop, /background, /batch, /code-review, /security-review de Claude Code, subagentes, ganchos, puntos de control, prácticas de delegación y gestión de agentes, sesiones en segundo plano, patrones de equipos de agentes, argumentos /schedule
- Los hilos local/nube de Codex, modo Goal, árboles de trabajo, Automations, subagentes, paneles de revisión, revisión de código en GitHub, ganchos, entornos aislados, Auto-review y re-ejecución
Estas capacidades no encajan en una sola escalera.
La subida: tres eras y una sola pila
Si lees la escalera de abajo arriba, te imaginas escalando tanto agencia como orquestación al mismo tiempo. En efecto, los seis niveles representan tres eras distintas por las que todos pasamos:
Primero, estás al volante y un agente principalmente solo ayuda, esperando a que lo dirijas.
Segundo, el agente se hace cargo de una tarea u objetivo acotado, pero tú sigues presente para dirigirlo y verificar lo que hace.
Y tercero, en la era de la orquestación, el sistema es capaz de gestionar el espectáculo, distribuyendo trabajo entre muchos agentes, y tú solo necesitas intervenir cuando algo sale mal: "gestión por excepción".
Esto simplifica las cosas, porque la posición vertical en la escalera captura perfectamente los dos ejes (la orquestación solo entra en juego cerca de la parte superior), convirtiéndolo en una única subida constante a través de los escalones. Y aún así, la subida sigue siendo parte de un cambio por el que todos estamos pasando.
Un buen día de ingeniería incluye tocar varios escalones, a veces más: es normal cambiar entre las eras varias veces en el transcurso de una tarea.
Los seis niveles en detalle
Nivel 0: Asistencia
El agente hace sugerencias que son mayormente buenas y a menudo perfectas, pero siempre decidirás tú si son lo suficientemente buenas para actuar. Piensa en autocompletado, sugerencias de edición en línea, o estar en una sesión de chat discutiendo un cambio del que nadie se ha hecho cargo todavía. Úsalo para errores costosos, cambios pequeños o cuando estás formando tu propio juicio. La verificación ocurre principalmente a nivel local.
Nivel 1: Acción supervisada
El agente edita o ejecuta comandos en tu nombre, preguntándote antes de ejecutar algo importante. Esta es la postura predeterminada para la mayoría de las personas. Puede hacerse en un entorno aislado local con aprobaciones antes de aplicar cambios, donde cada aprobación es una verificación independiente de que el cambio está bien aplicarlo, o en una sesión interactiva. El modo de fallo es la fatiga de aprobación; todas las aprobaciones se sienten igual sin importar lo que estén aprobando. Podrías solucionarlo revisando minuciosamente el diff, siguiendo algunas heurísticas, consultando con otra persona antes de aprobar, o simplemente aceptando dejar que el agente sea responsable. Codex Auto-review resuelve este problema delegando la aprobación final de las condiciones límite a un agente revisor separado.
Nivel 2: Delegación de tareas acotadas
Entrega una tarea acotada al agente. Esa tarea tendrá un objetivo claro, restricciones y una definición funcional de cómo se ve el "terminado". Te mantendrás cerca, con la capacidad de interrumpir, pero mayormente no involucrado. Este es el centro de gravedad en el mundo de la ingeniería de software. La verificación se está desplazando de ti (puede que necesites descansar y dormir) hacia la evidencia que el agente puede producir: pruebas automatizadas que pasan, tipos adecuados, sugerencias de lint, capturas de pantalla, pasos para reproducir, procedencia mediante ejemplos, etc.
Nivel 3: Autonomía impulsada por objetivos
El agente hace lo necesario para lograr un objetivo, deteniéndose solo cuando se cumple alguna condición. En modo de instrucción, esto significa que la instrucción misma se convierte en el objetivo (por ejemplo, "¿Puedes reducir el tiempo de interacción de esta página a menos de 1 segundo?"). En Codex, esto es el modo Goal: el agente pasa por los pasos de planificar->actuar->probar->revisar hasta que deja de cumplir los criterios de éxito. En Claude Code, son los comandos /goal, /loop y /schedule. Para que este nivel sea útil, la condición de parada debe ser medible de forma que pueda automatizarse.
No le pidas a tu agente que ayude con objetivos vagos y difusos como "mejorar la experiencia de usuario en general" o "hacer que la base de código sea más testeable". Elige algo específico, medible y automatizado: encontrar errores en producción que eluden el análisis estático, reducir el tiempo de carga, asegurar que tenemos una compilación estricta de TypeScript sin ningún "any", clasificar todas las dependencias para mantener solo aquellas que entendemos y que pasan nuestras pruebas, etc. Y, finalmente, para encontrar errores en producción, el agente necesitará estar en un entorno similar al de producción.
Nivel 4: Delegación paralela
Trabajar con muchos agentes en paralelo. Cada agente trabaja en una porción aislada de la tarea. El mayor cuello de botella en este nivel es la descomposición: definir las porciones correctas para delegar. Los soportes incluyen: subagentes, sesiones en segundo plano, /batch, árboles de trabajo, equipos de agentes, etc. El modo de fallo es el paralelismo falso: ejecutar muchos agentes en porciones superpuestas a la vez, por lo que en lugar de más trabajo obtienes conflictos de fusión y decisiones duplicadas. Para hacer esto bien, los agentes deben estar aislados unos de otros, cada uno siendo dueño de sus propios archivos y estado. Cada uno también necesita tener su propia cola de revisión. Y finalmente, cada agente incurre en un costo, en términos de tokens consumidos, proporcional al número de agentes que se ejecutan al mismo tiempo. En el lado humano, el impuesto de orquestación hace que el costo marginal de añadir un agente aumente después de unos pocos.
Nivel 5: Orquestación gestionada por excepción
Define cómo se ve el éxito y qué políticas deben aplicarse. Un agente gestor se activará según desencadenantes (por ejemplo, nueva incidencia, nueva tarea, reloj), enviará agentes trabajadores, monitoreará su progreso, verificará los resultados, reintentará en caso de fallo, escalará a agentes más competentes o humanos cuando se cumplan las condiciones, agregará resultados y, en última instancia, devolverá productos de trabajo (por ejemplo, PRs) y evidencia a sistemas externos. Piensa en una fábrica: el rastreador de incidencias o el backlog es la entrada, y el producto de la fábrica es la salida (es decir, muchas incidencias y errores corregidos). Los agentes trabajan en un entorno apropiadamente aislado con muchas paredes (y si es necesario, escotillas de escape), y solo un sistema operativo, definido por el agente gestor, define lo que se espera que haga la fábrica.
El diseño de este sistema operativo queda a cargo del humano; OpenAI ha propuesto una especificación para Symphony que tiene un tablero de Linear en el centro: cada incidencia obtiene su propio espacio de trabajo de agente, y el agente se asegura continuamente de que está avanzando hacia su objetivo según lo definido en un archivo de especificaciones en su propio espacio de trabajo. La revisión humana se puede hacer al nivel donde se genera la evidencia, pero la frontera (es decir, lo más poderoso en el mundo de la orquestación) es construir fábricas de agentes continuas con cientos o incluso miles de agentes. En este punto de la subida, se vuelve cada vez más importante tener verificación independiente: implementadores y revisores separados, ejecutores de pruebas y QA separados, controles de seguridad separados, compuertas de proceso separadas para la aceptación.
El riesgo y la reversibilidad establecen el techo.
Recuerdo haber leído un estudio anterior de Anthropic sobre algunas de las tareas más difíciles con Claude Code, donde pedía aclaraciones más del doble de veces de las que los usuarios interrumpían. Los usuarios experimentados (~750 sesiones frente a menos de 50) eran más propensos a auto-aprobar e interrumpir manteniendo un ojo en el progreso.
También hicieron un análisis más amplio de cómo la gente usa Claude Code. Analizaron ~400K sesiones de ~235K personas entre octubre de 2025 y abril de 2026. De cada sesión podían deducir las decisiones que alguien toma, como cuántas acciones solicitan en cada instrucción, cuáles de estas eligen auto-aprobar, con qué frecuencia interrumpen, etc. Las personas toman ~70% de las decisiones de planificación, pero Claude realiza ~80% de la ejecución. La alta autonomía no se trata de dejar a las personas fuera del circuito, sino de pasar de que hagan cada paso a que decidan en qué dirección ir a continuación.
Si queremos determinar si un sistema de IA grande está operando con alta autonomía, las tres preguntas que debemos hacernos son:
- ¿Qué tan rápido sabremos que estamos equivocados sobre lo que está haciendo?
- ¿Qué tan limpio podemos deshacer lo que está haciendo?
- ¿Qué probaría que estamos en lo correcto sobre lo que está haciendo?
Si la respuesta a las tres es: no rápidamente, con gran dificultad y confiando en el resumen, no es alta autonomía.
Cada ejecución de un agente debe ir precedida de un contrato que defina lo que está tratando de hacer.
El objetivo: lo que estamos tratando de lograr (no una actividad, no la técnica, sino un resultado).
El alcance: el dominio en el que estamos operando y qué técnicas están permitidas.
No-objetivos: lo que no es parte del objetivo.
Herramientas y permisos: cómo el agente puede interactuar con el mundo. Condición de parada: cuándo detenerse; idealmente, una variable medible.
Evidencia: pruebas específicas, capturas de pantalla, registros, registros de base de datos u otros indicadores que puedan usarse para confirmar que algo se ha hecho (independientemente del agente).
Escalación: quién se involucra y en qué circunstancias (incluyendo quién ejecuta el agente).
Y presupuesto: un límite en la cantidad de tiempo, esfuerzo y tokens que se dedicarán a la tarea (los tokens son el presupuesto de los grandes modelos de IA; también puedes incluir un límite en el número de veces que puede intentar la tarea y un límite en el grado de paralelismo).
Las métricas hacen que la autonomía sea un poco más confiable
Decidir la métrica después del hecho probablemente no sea suficiente. Las métricas se pueden establecer de antemano, en un documento conciso. Y eso hace que la autonomía se sienta más confiable y que el salto de fe sea un poco más fácil de dar.
Si bien hay muchas formas de medir el éxito, considera hacer un seguimiento de alguna versión de estas métricas para cada nivel de autonomía:
- Tiempo medio entre intervenciones
- Ejecución no supervisada exitosa más larga con trabajo aceptado
- Proporción de acciones ejecutadas en el entorno aislado frente a las escaladas
- Porcentaje de acciones auto-aprobadas frente a rechazadas
- Número medio de acciones del agente por instrucción humana
- Tasa de solicitudes de aclaración / Tasa de solicitudes de interrupción
- Tiempo de revisión por cambio aceptado
- Tasa de retrabajo en cada nivel de confianza
- Tasa de defectos que escapan en cada nivel de confianza
- Costo de tokens por cambio aceptado
Tales métricas pueden contar una historia: un solo agente mantenido ocupado por traspasos humanos es el Nivel 4 con un panel de control. Un agente conservador, que no está dispuesto a proceder sin ingreso automatizado, reintentos y evidencia decente, es el Nivel 5 con una compuerta real.
Piensa en la preparación
Clasifica el trabajo por riesgo y por lo fácil que es deshacerlo. Aplica la autonomía de forma conservadora, aumentando solo a medida que se acumula evidencia que respalde el nivel superior. Una refactorización del motor de pagos protegida por pruebas sólidas y agentes revisores con una ruta de reversión limpia puede soportar una autonomía mucho mayor que una tarea de automatización de documentación que carece de cualquier verdad canónica. El nivel de autonomía debe seguir el proceso de verificación, no el nombre de la tarea.
Cuatro antipatrones
Todo sistema puede caer fácilmente presa de estos cuatro antipatrones de autonomía a menos que se eviten vigilantemente.
Autonomía como estatus: la calificación de autonomía de un agente se convierte en una insignia de estatus sin sentido. Una mayor autonomía se trata como una prueba de capacidad, no de seguridad, y los agentes se ejecutan a un ritmo más alto de lo que la verificación respalda. Solución: elogia y recompensa a quienes se establecen en el nivel correcto de autonomía y evitan implacablemente excederse.
Blanqueo de permisos: la tiranía de la fatiga de aprobación nos lleva a otorgar a los agentes y herramientas de IA un acceso enormemente más amplio de lo necesario. Solución: mejores límites son siempre una solución, como perfiles de entorno aislado, raíces de escritura acotadas, comandos en lista blanca, ganchos y Auto-review.
Sustitución del resumen: el resumen del trabajo del agente sustituye la revisión, asumiendo que el resumen es suficiente. Solución: incluye el mismo paquete de evidencia que con las revisiones totalmente manuales (un diff, pruebas, registros, capturas de pantalla, hallazgos del revisor, riesgos, brechas, etc.) mientras se evita la rendición cognitiva.
Disfraz de flota: docenas de agentes se ejecutan en paralelo, pero un humano persiste en orquestar manualmente cada dependencia. Solución: el estado compartido, las reglas de propiedad y un mejor seguimiento de dependencias reducen gradualmente la necesidad de coordinar manualmente. Límites de trabajo en progreso (WIP) más pequeños obligan a centrarse en codificar y documentar los pasos coordinados hasta que la orquestación se automatice.
Un ejercicio de calibración
Revisa las últimas diez tareas que emprendiste con la ayuda de un agente. Para cada tarea, registra el nivel de autonomía ejercido, el riesgo involucrado, qué tan fácilmente se podía deshacer el trabajo, la evidencia producida para cumplir con los requisitos de verificación, el tiempo de revisión, si se necesitó algún retrabajo y si el nivel de autonomía elegido seguiría siendo adecuado la próxima vez.
Cómo subir de forma segura
Sube un eje a la vez. Comienza con un solo agente supervisado para realizar una sola tarea acotada que produzca evidencia defendible de éxito (un nivel de autonomía 1, si es lo suficientemente ordenado). Luego, expande gradualmente en las tres direcciones ortogonales. Paraleliza tareas de exploración intensivas en lectura (nivel de autonomía 4). Añade agentes de escritura que actúen en árboles de trabajo separados con reglas de propiedad de archivos restringidas (nivel de autonomía 4). Añade automatizaciones recurrentes, luego orquestación liderada por agentes basada en incidencias, voz, etc. Cada paso hacia arriba en la palanca requiere un nuevo conjunto de mecanismos de seguridad (como nuevos modos de fallo).
Nómbralos: las ejecuciones de un solo agente más largas pueden llevar a desviación, pudrición del contexto, comunicación perdida u objetivos extraviados. El trabajo en segundo plano puede llevar a suposiciones obsoletas y transferencias débiles. Demasiado trabajo en paralelo puede llevar a conflictos de fusión o decisiones duplicadas. Demasiado trabajo recurrente puede llevar a un gasto silencioso de tokens o instrucciones desactualizadas. La gestión por excepción puede llevar a largas colas de revisión y fatiga de alertas. La solución no es confiar más; en cambio, reduce el alcance, asegura una mejor evidencia, habilita rutas de reversión más baratas, endurece las compuertas y define reglas de propiedad más claras.
Usa el nivel de autonomía:
- El Nivel 0 es mejor para trabajo delicado y cuando el juicio aún se está formando.
- El Nivel 1 es mejor para la mayor parte de la exploración, si el trabajo se realiza cerca de los límites de lo que se comprende bien.
- El Nivel 2 es mejor para la mayoría de las tareas acotadas, sabiendo que puede haber dependencias desconocidas y problemas imprevistos.
- El Nivel 3 es mejor cuando las condiciones de éxito se pueden establecer con suficiente claridad.
- El Nivel 4 es mejor cuando el trabajo se puede dividir limpiamente entre estas condiciones de éxito.
- El Nivel 5 es mejor una vez que la coordinación y comunicación necesarias entre las diversas condiciones de éxito están completamente codificadas.
La verificación siempre será el cuello de botella.
A pesar de la fanfarronería y las herramientas actuales, la postura madura de un equipo de ingeniería que trabaja con agentes de IA es la autonomía calibrada.
Los cuellos de botella son la coordinación, la verificación, el mantenimiento, el juicio del producto y el aprendizaje de incidentes.
En el futuro cercano, necesitaremos diseñar bucles que sepan cuándo trabajar, cuándo verificar y cuándo preguntar, pero la habilidad del ingeniero seguirá estando en elegir el nivel correcto de autonomía y en construir patrones y evidencia defendible que protejan contra sus aspectos más oscuros.
Nota: Pangram etiqueta este artículo como 100% escrito por humanos: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
