Durante mucho tiempo la pregunta sobre los agentes de programación fue si de verdad podían hacer el trabajo. Esa pregunta se está cerrando sin ruido. En tareas bien acotadas, con el repositorio delante y la capacidad de ejecutar las pruebas, los buenos agentes envían cambios reales que pasan la revisión. Y en cuanto confías en eso, te topas con un problema del que nadie te avisó: no se te ocurre trabajo lo bastante rápido como para mantenerlos ocupados.
La ejecución dejó de ser la restricción
Siempre hay trabajo infinito por hacer en un producto de software. El backlog nunca está vacío; la lista de cosas que podrían estar mejor es interminable. Por eso suena raro decir que un equipo podría quedarse sin trabajo para un agente. Pero "existe trabajo infinito" y "existe trabajo en una forma que un agente puede tomar y terminar" son dos afirmaciones muy distintas, y en la brecha entre ambas es donde los equipos se atascan.
Un agente puede ejecutar una tarea clara en minutos. Escribir esa tarea clara —la que tiene suficiente contexto, el alcance correcto y una definición de terminado— sigue costándole a una persona los mismos veinte minutos de siempre. Cuando la parte lenta era la ejecución, eso daba igual; la especificación era el cinco por ciento del esfuerzo y el trabajo era el otro noventa y cinco. Lleva el costo de ejecución hacia cero y la proporción se invierte. Ahora la especificación es la mitad cara, y un equipo que podía alimentar a un agente descubre que no puede alimentar a tres.
El cuello de botella se movió aguas arriba, hacia ti
Este es el problema del suministro de tareas: la restricción del desarrollo con agentes ya no es la capacidad del agente para hacer cosas, es la capacidad de la organización para producir cosas bien formadas que hacer. Y esa restricción recae sobre las personas más escasas que tienes: las que tienen suficiente contexto para decir qué debe pasar a continuación y por qué.
Lo sientes como una presión extraña. El agente es rápido y fiable, así que la cola se vacía más rápido de lo que puedes rellenarla, y rellenarla es la parte que necesita criterio, sentido de producto y saber hacia dónde va el sistema. El cuello de botella no desapareció. Se movió del teclado a la cabeza de la persona que sabe qué debería estar haciendo el teclado.
El agente tiene que ayudar a suministrar el trabajo
La única forma de superar un problema de suministro es aumentar el suministro, y la persona que define tareas no escala. Así que el agente que ejecuta el trabajo tiene que empezar a ayudar a generarlo, no inventando tareas de relleno, sino convirtiendo las señales que ya fluyen por tus sistemas en tareas concretas y listas para ejecutar.
TaskGoblin hace una versión de esto hoy, en dos lugares que quizá no habías pensado como "generación de tareas":
- Los hallazgos de revisión se vuelven trabajo. Cada merge request que el agente revisa produce hallazgos específicos y localizados: esta función tiene un bug de corrección, este camino no está cubierto, esto huele a problema de seguridad. Cada uno es, en efecto, una tarea preescrita con una definición de terminado. Responde
@taskgoblin fixy el hallazgo se convierte en un cambio. Nadie tuvo que sentarse a escribir ese ticket; la revisión lo suministró. - Los ciclos permanentes se vuelven trabajo. Un loop es un generador de tareas que corre por reloj: "cada día laborable, encuentra trabajo fusionado cuyos issues sigan abiertos y ciérralos", "vigila un CI que lleva demasiado tiempo en rojo". La instrucción se escribe una vez y sigue produciendo trabajo concreto —o produciendo correctamente nada cuando no hay nada que hacer— sin que nadie rellene la cola a mano.
En ambos casos el agente no espera a que le digan qué hacer. Lee el estado del sistema y propone lo concreto y terminable que viene a continuación.
Por qué el contexto es todo el juego
La razón de que el trabajo propuesto por un agente suela ser de bajo valor no es que el modelo no sea lo bastante listo. Es que el agente no sabe qué te importa. Ciego al propósito del producto, un agente sugerirá con gusto los veinte refactors que ve y ninguno del único cambio que de verdad mueve el negocio, porque el código le dice qué es posible, no qué es importante.
Por eso las superficies útiles de generación de tareas son las ancladas a la intención real. Un hallazgo de revisión importa porque está sobre un cambio que alguien eligió hacer. Un ciclo programado importa porque un humano decidió que mantener issues y merges sincronizados vale la pena cada día. El contexto que hace que una tarea propuesta valga la pena no está solo en el código; está en los issues, las discusiones y las decisiones alrededor del código, y un agente que vive en esos sistemas, como el nuestro, puede leer esa intención en lugar de adivinarla.
Dónde está el valor ahora
Vale la pena ser claro sobre dónde deja esto la ventaja. A medida que los modelos convergen en poder ejecutar casi cualquier cosa, el valor desproporcionado deja de acumularse en quien tiene el agente más listo y empieza a acumularse en quien puede mantener a buenos agentes suministrados con trabajo que importa. La jugada ganadora no es un modelo más ingenioso. Es cerrar el bucle entre la intención dispersa por tus herramientas y el agente que puede actuar sobre ella, para que "qué hacemos a continuación" deje de ser un cuello de botella que eres tú en persona.
Ese es el problema contra el que de verdad estamos construyendo. Que el agente pudiera programar era la primera mitad. Asegurar que siempre sepa qué vale la pena hacer —y que pueda convertir tu contexto en la siguiente tarea concreta sin esperarte— es la mitad que decide cuánto valía la primera.
