Una vez que el Agente se hace cargo de la tarea, lo primero que hay que ajustar es la unidad de trabajo.

He estado leyendo muchas discusiones sobre Agent recientemente y al final siempre vuelvo a la misma pregunta: a quién se le debe dar un trabajo, cómo se debe empaquetar antes de entregarlo y cómo se aceptará después de su devolución. Una vez que ocurre este problema en un proyecto, lo primero que aumenta muchas veces no es el costo del modelo, sino la complejidad de la unidad de trabajo. Si la tarea se reduce demasiado, el modelo aparecerá “como si se pudiera hacer”; los verdaderos problemas suelen radicar en la reversión, la reproducción y la aceptación.

La unidad de trabajo primero debe poder ser aceptada

En los últimos días, después de unir las notas fragmentadas de Martin Fowler y varias discusiones en el Retiro de Desarrollo de Software de Thoughtworks Future, la sensación más obvia es que la conversación en la reunión estuvo superficialmente dispersa, pero en el fondo en realidad giró en torno a una sola cosa: entregar un gran trabajo al Agente.

El remate de Kief Morris es el más sencillo. En diferentes sesiones se discutió la revisión de código, los accidentes de producción, la división del trabajo en equipo y el enrutamiento de modelos. Parecían estar hablando de cosas diferentes, pero la conclusión resultó ser la misma: la gente ha estado ajustando el tamaño del “trabajo unitario”. Cuanto más grande sea la unidad, más fácil será entregarla; cuanto más grande sea la unidad, más difícil será aceptarla una vez que regrese. No es que el modelo no pueda hacerlo, es que el siguiente enlace de confirmación no puede aguantar primero.

Por eso se menciona una y otra vez el arnés. Gestión de contexto, sensores computacionales, pruebas basadas en propiedades, métodos formales, estas cosas parecen herramientas adicionales, pero en realidad recopilan unidades de trabajo. Algunas personas controlan agents.md a menos de 200 líneas, no para buscar pulcritud en la forma, sino para obligar al sistema a recibir sólo aquella parte de la información que es realmente útil y que realmente se puede comprobar. El contexto es demasiado vago, por supuesto que el Agente puede ejecutarse; pero después de correr, nadie sabe qué capa de limitaciones se tragó.

El autohospedaje aumenta la superficie de control

Las discusiones sobre modelos autohospedados también apuntan a lo mismo. Después de que los tokens se vuelvan más caros, los requisitos de cumplimiento se vuelvan más estrictos y los datos no puedan filtrarse, los modelos de código abierto y los modelos locales naturalmente se volverán más atractivos. Pero una vez que lleva el modelo usted mismo, también tendrá problemas: GPU, sala de inferencia, enrutamiento, reversión, ajuste fino y selección de modelo. Estas no son las capacidades del modelo en sí, pero determinarán si el sistema es finalmente estable.

Estos costos a menudo se subestiman. Muchos equipos inicialmente se centraron en “si el modelo es más fuerte”, pero luego descubrieron que lo que realmente consume tiempo es la transferencia estable de unidades de trabajo entre múltiples modelos. Cuándo usar un modelo grande, cuándo usar un modelo liviano y cuándo usar simplemente un modelo local, no depende de la preferencia verbal, sino de una capa de superficie de control que puede usarse para desviar y encubrir. Sin esta capa de cosas, el autohospedaje pasará de “tomar la iniciativa” a “asumir usted mismo la complejidad de la operación y el mantenimiento”.

Simon Willison mencionó dejar que los modelos más fuertes elijan modelos más pequeños para hacer el trabajo. Esta idea también es muy similar a lo que hace el avión de control. El modelo en sí no necesariamente conoce los límites de costos del equipo, pero el sistema sí. Tratar el modelo como un intermediario y utilizarlo para asignar tareas está más cerca de una entrega real que perseguir ciegamente un modelo único para una entrega todo incluido.

La aceptación y los objetivos no se pueden subcontratar

“Bring me a Rock” de Sam Ruby sacó a la luz otro tema. Darle el trabajo al modelo equivale a agregar un ejecutor; la responsabilidad no desaparece. Los gerentes pueden usar LLM para la exploración y pueden dejar que primero escupe un montón de soluciones candidatas, pero los criterios de aceptación finales aún tienen que caer en manos humanas. Los objetivos ocultos son los más problemáticos. Los permisos, la privacidad, las acciones destructivas y la filtración de contexto a menudo no están incluidos en los requisitos originales.

Por tanto, las pruebas de conformidad suelen ser más útiles que las especificaciones. Las especificaciones son buenas para describir “lo que se requiere” y las pruebas son mejores para exponer “lo que no puede suceder”. Esto es especialmente cierto en los sistemas de agentes. El modelo puede compensar muy bien los objetivos explícitos, pero los límites implícitos deben verificarse mediante una verificación más exhaustiva. Mientras las condiciones de aceptación permanezcan en descripciones vagas, cuanto más haga el Agente, más parecerá que el sistema está apostando por la probabilidad.

Por lo tanto, la revisión de código, el manejo de incidentes y la asignación de tareas, que solían ser tareas muy humanas, ahora están comenzando a tomar otras formas. Los gerentes utilizan el modelo directamente. En la superficie, parece estar mejorando la eficiencia, pero en el nivel inferior, en realidad están cambiando un método de gestión: de métodos de gestión a objetivos de gestión. Si el objetivo está claramente escrito, el modelo tendrá posibilidades de funcionar; si el objetivo no está claro, el modelo sólo amplificará la ambigüedad para los demás.

La experiencia y las habilidades de lectura siguen mejorando.

La experiencia interaccional y la experiencia contributiva mencionadas por Dan Davies también son muy relevantes para este cambio. El modelo puede leer muchos materiales y emitir un juicio decente, pero para que el sistema sea estable, todavía es necesario que haya alguien que pueda leer las especificaciones, ver los resultados y saber qué está mal. La clave aquí no es que la gente deba competir con el modelo para ver quién es más inteligente, sino que la gente debería seguir manteniéndose en una posición que defina los límites.

Este asunto es más sencillo cuando se trata de entrega de software. Después de que el Agente asuma el control, el trabajo humano recaerá menos en la ejecución manual y más en la segmentación de tareas, la definición de límites, el diseño de aceptación y el manejo de excepciones. La posibilidad de transferir tareas determina claramente si vale la pena realizar la posterior gestión del contexto, el enrutamiento de modelos y la orquestación de herramientas. Si la unidad no está clara, no importa cuántas capas haya, sólo hará retroceder el problema.

Después de leer estos fragmentos en los últimos días, lo que me queda en la mente no es un determinado nombre de modelo, ni un nuevo marco, sino un juicio más simple: lo primero que el sistema del Agente necesita reforzar no es la capacidad del modelo, sino la unidad de trabajo. Si la unidad es más pequeña, la aceptación es más estricta y los permisos son más estrictos, el sistema tendrá la oportunidad de mantener la complejidad dentro de un rango controlable.