Pasé meses construyendo un arnés independiente del modelo para hacer trabajo de software real con agentes de codificación. Al final, las funciones importaron mucho menos de lo que esperaba. Lo que realmente importó fue un puñado de ideas que cambiaron mi forma de pensar sobre construir con agentes, en lugar de solo darles instrucciones.
Estas son las ideas que tienen más peso. Las tres primeras cambiaron genuinamente mi modelo mental. El resto son cosas prácticas que puedes empezar a usar casi de inmediato.
1. Congela los criterios de aceptación antes de que el agente comience
Y colócalo en un lugar donde no pueda editarlo.
Este es probablemente el cambio más grande para mí. Suena obvio en retrospectiva, pero no aprecié realmente lo importante que era hasta que lo vi en acción.
Si los criterios de aceptación pueden cambiar después de que el trabajo existe, se desplazarán lentamente hacia lo que se produjo. El agente no está siendo deshonesto, simplemente está juzgando el trabajo contra un objetivo que aún puede moverse. Si los postes son móviles, eventualmente se moverán.
Eso no es un problema de instrucciones, es un problema estructural, por lo que la solución también debe ser estructural.
Escribe los criterios de aceptación primero. Guárdalos fuera del espacio de trabajo editable y bloquea automáticamente cualquier intento de editarlos. Ahora el agente está trabajando hacia un contrato que no puede renegociar. La tarea no está terminada porque el agente lo diga. Está terminada porque satisface el contrato original.
2. Nadie debería calificar su propio trabajo
El modelo que escribió el código es el peor juez posible para decidir si es correcto. Para cuando termina, ya se ha convencido a sí mismo de que la solución tiene sentido.
Así que divide las responsabilidades.
Deja que los scripts deterministas verifiquen todo lo mecánico. Un script no puede inventar un código de salida exitoso. Trata al modelo de codificación como un ingeniero, no como el revisor. Luego entrega el resultado a un contexto fresco revisor, uno que nunca vio cómo se escribía el código, para juzgar el diseño, la intención y la calidad general.
Esa simple separación detecta muchos más problemas de los que esperaba, y es sorprendentemente barata de implementar.
3. Hacer cumplir es fácil. La calibración es la parte difícil.
Esta comprensión cambió cómo pensaba sobre todo el arnés.
La mayoría de los sistemas de agentes, incluyendo versiones anteriores de los míos, tratan cada tarea de manera similar. Una corrección de un error tipográfico de una línea pasa por el mismo proceso que un rediseño arquitectónico importante. Eso es o una pérdida de tiempo o demasiado arriesgado.
La clave es el esfuerzo proporcional.
Primero clasifica el trabajo. ¿Es un cambio pequeño del que nada depende, o una infraestructura central de la que todo depende? ¿Es lógica de negocio o código de utilidad genérico?
Luego deja que esa clasificación decida cuánta revisión recibe, qué modelo debería manejarlo y cuánta autonomía se le permite.
Poner en marcha el cumplimiento es fácil. Conseguir que el esfuerzo coincida es donde el valor realmente comienza a acumularse.
La Capa Práctica
Una vez que esas ideas más grandes estuvieron en su lugar, algunas prácticas más pequeñas dieron sus frutos casi de inmediato.
- Pon tus reglas en el arnés, no en la instrucción. Una instrucción que dice "no hagas ediciones en el repositorio principal" es solo un consejo. La misma regla aplicada como una llamada a herramienta bloqueada se vuelve imposible de ignorar. Las reglas importantes no deberían depender de que el modelo elija comportarse.
- Mantén el estado fuera de la conversación y usa un trabajador nuevo para cada tarea. Almacena los registros de tareas externamente, usa árboles de trabajo aislados y procesa los cambios a través de una cola de fusión. Una vez que el estado vive fuera del chat, los límites de contexto dejan de ser tu restricción más grande. Las tareas se vuelven paralelas, reanudables y mucho más fáciles de razonar.
- La revisión entre proveedores supera a la revisión del mismo proveedor. Los modelos pueden ser más indulgentes con su propio trabajo que con el de otros. Usar un modelo de un proveedor diferente, es una forma simple y efectiva de reducir ese sesgo.
Por qué funcionan los principios
Ninguna de estas ideas depende de un modelo en particular. Se trata de ingeniería de arneses. Protocolos, verificación, tuberías de revisión y separación de responsabilidades.
El modelo en la cima de los benchmarks seguirá cambiando.
Pero los principios probablemente no.
El valor duradero no está en el modelo, ni en las funciones. Está en el andamiaje que construyes a su alrededor.
