Michael JohnsonSe puede asignar una tarea a un agente, esperar a que haga cambios en el repositorio y recibir un borrador de pull request para revisarlo. Pero junto con el código surge una pregunta: ¿el resultado responde a la tarea y no se les ha escapado a las pruebas algún problema importante?
El 4 de febrero de 2026, GitHub anunció la vista previa pública de Claude y Codex como agentes de programación. La empresa informó de que se pueden asignar tareas a los agentes desde issues y pull requests, y después revisar el borrador de PR que preparan. Esto confirma que ese flujo de trabajo ya está disponible en la interfaz de desarrollo, pero no demuestra que ahorre tiempo ni que mejore la calidad del código.
Por eso, la pregunta no es solo si un agente es capaz de escribir código. También importa qué trabajo debe realizar una persona en torno a la tarea delegada: definir restricciones, supervisar el proceso y evaluar el resultado.
La supervisión no se limita a la revisión final
En un preprint publicado en arXiv el 21 de septiembre de 2026, los investigadores proponen considerar la supervisión de un agente de programación como un proceso secuencial. El trabajo The Work Behind Delegation se basa en observaciones y esquemas de flujos de trabajo de 19 desarrolladores con experiencia. Los autores describen siete etapas de supervisión y aplican este marco a conversaciones públicas entre desarrolladores en Reddit.
Entre los enfoques que describen los autores están prestar más atención a la planificación, delegar algunas tareas de supervisión en otros agentes y convertir las instrucciones recurrentes en materiales reutilizables. Se trata de un marco analítico, no de una medición del tiempo invertido: el trabajo no determina cuánto tiempo dedican los desarrolladores a supervisar ni si este proceso es más rápido que el trabajo manual. La página de arXiv indica que el preprint está en revisión por pares, por lo que sus conclusiones deben considerarse preliminares.
Para la práctica, resulta útil distinguir tres acciones. Definir la tarea establece el objetivo y las restricciones. Supervisar permite detectar si el agente se ha desviado de lo previsto. Revisar ayuda a evaluar si el resultado puede aceptarse teniendo en cuenta los requisitos, el código y las pruebas. Tener éxito en una etapa no garantiza el éxito en la siguiente: un parche puede parecer plausible, pero resolver una tarea distinta o requerir una reelaboración considerable.
La experiencia de la comunidad no es una estadística
En un debate en r/LocalLLaMA, un participante escribió que su experiencia con modelos locales y agentes había sido decepcionante: según contó, tenía que corregir los resultados y recordarles las instrucciones a los agentes. Otros participantes del mismo hilo describieron un proceso que les resultaba más útil: limitar el alcance de las tareas, trabajar por etapas y revisar el código con atención. Son observaciones individuales de usuarios, no una prueba comparativa de modelos ni una medición de la productividad de los equipos.
Estas opiniones tan distintas muestran que la experiencia puede depender de la tarea, el modelo, el entorno y la forma de trabajar. Pero un solo debate no permite determinar qué prácticas son más eficaces en promedio ni con qué frecuencia surgen problemas. El hilo trata sobre modelos locales, así que sus observaciones no deben extrapolarse automáticamente a todas las herramientas basadas en agentes.
La participación humana no significa por sí sola que delegar sea inútil. Un desarrollador puede dividir la tarea en partes, revisar los cambios y aclarar los requisitos, sin dejar de ser responsable del resultado final. Sin embargo, si no se contabiliza el tiempo dedicado a definir la tarea, corregirla y revisarla, no se puede afirmar que haya disminuido el volumen total de trabajo.
Un borrador de PR todavía no es un PR aceptado
En el flujo de trabajo descrito por GitHub, se puede asignar un issue a un agente y recibir un borrador de pull request. Entre su creación y su aceptación quedan varias cuestiones por resolver: si el cambio cumple los requisitos, si contempla los casos límite, si las pruebas son suficientes y si la solución encaja con la arquitectura del proyecto.
Estos criterios no pueden reducirse a una sola métrica. El número de cambios creados no equivale al número de cambios aptos, y superar las pruebas no necesariamente confirma todas las propiedades importantes de un parche. Incluso un resultado que parece de calidad no revela por sí solo cuánto trabajo hizo falta para prepararlo y revisarlo.
Para evaluar el efecto global, hay que tener en cuenta todo el ciclo: definir la tarea, esperar el resultado, revisar, corregir y mantener el código posteriormente. Las fuentes analizadas no ofrecen una comparación global de este tipo.
Qué se puede concluir
El preprint propone un marco para hablar de supervisión, y GitHub informó de un flujo de trabajo en el que se asigna una tarea a un agente y se revisa el PR que prepara. El debate en Reddit muestra que algunos usuarios describen tanto dificultades como formas útiles de trabajar con modelos locales. En conjunto, estos materiales permiten plantear cómo organizar la revisión del código delegado, pero no ofrecen una respuesta sobre la productividad neta.
No permiten concluir que, en general, los desarrolladores ya hayan pasado de escribir código a supervisarlo, que los agentes generen siempre trabajo adicional o que aumenten la productividad del sector. Para sostener esas conclusiones hacen falta mediciones comparables del tiempo y la calidad en distintas tareas y equipos.
La pregunta práctica para un equipo es más concreta: ¿qué cambios puede preparar un agente por su cuenta, qué hay que revisar antes de integrar y quién se responsabiliza de que el resultado resuelva la tarea original? Delegar no elimina este trabajo de ingeniería: cambia dónde empieza y en qué se centra.