Construimos Ulyssify con una flota de agentes de programación con IA. En un día ajetreado, la flota abre y aterriza decenas de pull requests en nuestro backend, web, iOS, macOS, Windows y Android. Los humanos dirigen y aprueban; los agentes hacen la implementación. Este post trata de la parte de la que nadie te advierte: una vez que tus agentes pueden hacer casi cualquier cosa, el problema difícil deja de ser la capacidad y pasa a ser el criterio.
El modo de falla de un agente capaz
Un ingeniero junior que técnicamente puede hacer cualquier cosa, sin noción de qué acciones son reversibles, no es un activo. Con los agentes pasa lo mismo. Un agente que refactoriza un archivo con gusto también hará, si tiene la oportunidad, un force-push a una rama compartida, ejecutará una migración destructiva sobre datos reales o desplegará a producción porque las pruebas salieron en verde. Que las pruebas estén en verde significa que nada falló. No significa que el cambio fuera seguro de enviar. Así que lo primero que construimos no fue un agente mejor. Fue una forma de decirle al agente qué decisiones le corresponde tomar.
Tres niveles: AUTO, NOTIFY, ASK
Cada decisión recurrente que enfrentan nuestros agentes se clasifica en uno de tres niveles.
AUTO es para cualquier cosa reversible con un radio de impacto pequeño: crear una rama desde main, ejecutar las pruebas, abrir un pull request. El agente simplemente lo hace.
NOTIFY es para acciones recuperables pero que vale la pena ver: el agente hace la acción y luego la anota en el resumen de su ejecución para que una persona pueda vetar una mala decisión. La regla de NOTIFY es estricta: solo aplica si deshacerla cuesta un único comando barato. Si deshacerla es confuso o caro, nunca fue NOTIFY.
ASK es para las puertas de un solo sentido: promover a producción, una migración destructiva, cualquier cosa que toque dinero, el cumplimiento o un compromiso público. El agente se detiene y espera a una persona.
Dos reglas están por encima de los tres niveles. Las puertas de un solo sentido siempre preguntan. Y cuando el agente no está muy seguro, pregunta. Una pregunta aclaratoria siempre es más barata que construir algo mal con total seguridad.
El hallazgo que cambió cómo escribimos reglas
Mantenemos las reglas de operación de nuestros agentes como instrucciones escritas, y durante un tiempo simplemente seguimos agregando más. Luego auditamos un mes del comportamiento real de la flota, y el resultado fue incómodo: las reglas respaldadas por un mecanismo real (un git hook que rechaza el commit, un job de CI que bloquea el merge, una barrera de permisos) tenían una tasa de incumplimiento prácticamente nula. Las reglas que solo existían como prosa se cumplían alrededor de tres cuartas partes de las veces, y el cumplimiento empeoraba a medida que agregábamos más prosa, no mejoraba.
La lección que sacamos: seguir instrucciones es un presupuesto, no una garantía. Cada regla que escribes en prosa compite con todas las demás por la atención del modelo, y la pila siempre crece. Así que una regla que de verdad nunca quieres que se incumpla no pertenece a la prosa. Pertenece a un mecanismo que hace imposible la acción incorrecta. Ahora consideramos que la verdadera solución es convertir una regla que nunca debe incumplirse de instrucción en hook o en barrera, y que agregar otro párrafo es lo que hay que evitar.
Verifica el mecanismo, no el linaje
Un hábito más que nos salva una y otra vez. Cuando un agente, o una persona, recomienda una salvaguarda, es tentador confiar en ella porque está bien razonada y tiene historia detrás. Pero una recomendación es una afirmación, y la única pregunta que importa es si el mecanismo realmente se sostiene. Nuestra prueba de una línea para cualquier protección: ¿el valor del que depende lo conoce la parte que la hace cumplir, o lo ofrece voluntariamente la parte a la que debe restringir? Un límite que la parte restringida puede esquivar con solo quedarse callada no es una protección, por buenas que sean sus razones. Encontrar la línea de código que lo hace cumplir zanja la cuestión más rápido que cualquier debate sobre si la idea es buena.
Nada de esto está terminado. Es un sistema vivo, y cada semana nos equivocamos de formas nuevas. Pero la dirección ha sido constante: darles a los agentes criterio real sobre qué decisiones les corresponden, y poner las decisiones que más importan detrás de mecanismos en lugar de palabras. Iremos compartiendo más sobre cómo funciona la flota.