Lo que realmente aprendí al construir un entorno de desarrollo con IA

Pasé meses construyendo un armazón agnóstico al 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ó fueron 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 más peso tienen. Las primeras tres 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 ponlos en un lugar donde no pueda editarlos.

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 irán desplazando lentamente hacia lo que se produjo. El agente no está siendo deshonesto, simplemente está evaluando el trabajo contra un objetivo que aún puede moverse. Si los postes de la meta son movibles, eventualmente se moverán.

Eso no es un problema de instrucciones, es estructural, así que la solución también tiene que ser estructural.

Escribe los criterios de aceptación primero. Almacénalos 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 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 a un ingeniero, no como al revisor. Luego, entrega el resultado a un revisor con contexto nuevo, uno que nunca vio cómo se escribió el código, para que juzgue 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 barato de hacer.

3. La aplicación de reglas es fácil. La calibración es la parte difícil.

Esta comprensión cambió mi forma de pensar sobre todo el armazón.

La mayoría de los sistemas de agentes, incluidas las versiones anteriores del mío, tratan cada tarea más o menos igual. 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 una pérdida de tiempo o es 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.

Implementar la aplicación de reglas 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 frutos casi de inmediato.

• Pon tus reglas en el armazón, no en las instrucciones. 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 bien.
• Mantén el estado fuera de la conversación y usa un trabajador nuevo para cada tarea. Almacena los registros de las 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 mayor restricción. 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 otro. Usar un modelo de un proveedor diferente es una forma sencilla 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 del armazón. Protocolos, verificación, canales de revisión y separación de responsabilidades.

El modelo en la cima de los puntos de referencia seguirá cambiando.

Pero los principios probablemente no.

El valor duradero no está en el modelo, y no está en las funciones. Está en el andamiaje que construyes a su alrededor.