¿De qué tamaño pasa una tarea?
Para esto hay medición, y la métrica es elegantemente simple: la duración de tarea — medida en tiempo de trabajo humano — con la que el modelo alcanza un 50 % de éxito.
Según la medición de principios de 2026, la cabeza de carrera anda por los 320 minutos, pero el intervalo de confianza es amplio: entre 170 y 729 minutos. La tendencia es rápida: el tiempo de duplicación se ha acortado de los siete meses anteriores a unos tres meses.
A esto conviene añadirle dos cosas.
Una es un límite metodológico que los propios investigadores dejan por escrito: en las tareas de más de ocho horas, el tiempo humano de referencia se midió en solo 5 de 31 casos, y el resto son estimaciones. Así que el extremo alto de la escala es más incierto de lo que parece.
La otra es la lectura práctica. El cincuenta por ciento no es una buena tasa. Si le das una tarea de cinco horas, la mitad de las veces la estropeará — y revisar cinco horas de trabajo estropeado te cuesta a ti cinco horas. Que tu primera tarea esté bastante por debajo de una hora de trabajo humano, donde el fallo se vea enseguida.
Qué darle y qué no
La documentación oficial de uno de los grandes proveedores dice para qué sirve el agent y para qué no. Esa lista es más útil que la mayoría de los consejos del gremio:
SIRVE PARA ESTO
corregir errores
modificar un elemento de interfaz
aumentar la cobertura de tests
actualizar la documentación
mejorar la accesibilidad
saldar deuda técnica
PARA ESTO NO
refactorización amplia que exige conocer varios repositorios
tarea compleja que exige entender dependencias y código heredado
fallo crítico que AFECTA A PRODUCCIÓN
seguridad, datos personales, autenticación
tarea vaga o de final abierto
AQUELLO DE LO QUE QUIERES APRENDER <- la doc lo subraya aparte
El último punto es el más importante, y el menos técnico. Si de resolver una tarea ibas a aprender algo sobre la base de código, lo que has entregado es el aprendizaje — no el trabajo.
Qué escribir en la tarea
Esa misma documentación pide tres cosas a una buena descripción de tarea:
- Una descripción clara del problema o del trabajo a realizar.
- Criterios de aceptación completos — qué cuenta como buena solución.
- Una indicación de qué ficheros hay que modificar.
La tercera es la que casi todo el mundo se salta, y es justo la que más acorta la exploración.
El tamaño de la diferencia se ve mejor con una comparación de antes y después:
| Cómo lo pide casi todo el mundo | Cómo funciona |
|---|---|
| «escribe tests para foo.py» | «escribe un test para foo.py que cubra el caso en que el usuario ha cerrado sesión; no uses mocks» |
| «arregla el fallo de login» | «los usuarios avisan de que el login se cae cuando caduca la sesión; mira el flujo de auth en src/auth/, sobre todo el refresco del token; escribe primero un test que falle y lo reproduzca, y después arréglalo» |
| «el build está roto» | «el build se para con este error: [mensaje de error]. Arréglalo, y comprueba que pasa. Ataca la causa raíz, no tapes el error» |
El fallo más habitual: no tiene nada que ejecutar
Este es el punto que decide la sesión entera, y la documentación del fabricante lo dice con una honestidad poco habitual:
«El modelo se detiene cuando el trabajo parece terminado. Si no hay ninguna comprobación que pueda ejecutar, "parece terminado" es la única señal disponible — y el bucle de verificación vas a ser tú.»
Lo mismo en positivo: dale algo que pueda ejecutar por su cuenta — un test, un build, una captura de pantalla con la que comparar. Esa es la diferencia entre mirar la sesión de principio a fin y poder marcharte de su lado.
Por eso, en la primera tarea el orden es: primero el test que falla, después el arreglo. No solo porque así se puede comprobar — sino porque así la propia definición de la tarea queda clara.
Las cuatro fases
El método de trabajo que funciona tiene cuatro pasos: exploración → plan → implementación → commit. Los dos primeros corren en un modo donde la herramienta lee y ejecuta comandos de solo lectura, pero no reescribe tus fuentes.
Y un añadido de esa misma documentación que casi nunca se cita: no planifiques siempre. Si el alcance está claro y el arreglo es pequeño — una errata, una línea de log, un renombrado —, pídele que lo haga directamente. La regla en una frase: si puedes contar el diff en una frase, sáltate la planificación.
Cinco patrones de fracaso con nombre
La documentación del fabricante les pone nombre por separado, de lo frecuentes que son:
- La sesión que lo mezcla todo. Varias tareas sin relación entre sí en la misma conversación. Entre ellas hay que limpiar el contexto.
- El arreglo en círculos. Después de dos arreglos fallidos, no pruebes con el tercero: limpia el contexto y escribe una descripción de tarea mejor.
- Las instrucciones de proyecto infladas. Si son demasiado largas, la mitad se pierde. De eso habla con cifras el post las instrucciones de proyecto , punto por punto.
- La brecha entre confiar y comprobar. «Si no lo puedes comprobar, no lo saques.»
- La exploración infinita. Acota el ámbito de la investigación, o dale un subagent aparte para eso.
Detrás de todos ellos está lo mismo: el context window se llena rápido, y a medida que se llena, el rendimiento empeora. La mayoría de las buenas prácticas salen de esa única restricción.
Qué enseña la realidad: 11.048 PR de agent
Hay un análisis que revisó 11.048 pull requests cerrados y abiertos por agents en repositorios reales de al menos quinientas estrellas. De ellos, 9.799 los revisó además una persona.
La tasa de merge es del 63,1 %. Es bastante mejor de lo que esperaría un escéptico — pero los detalles enseñan más.
En los PR rechazados, el propio agent era la causa del problema en solo el 35,7 % de los casos. El resto son motivos de proceso: duplicación, rama obsoleta, o sencillamente que el mantenedor no había pedido eso. O sea, dos tercios de los rechazos no iban de que el código fuera malo.
Y dos cifras que dan que pensar:
- En el 79,1 % de los PR de agent que entraron no hubo ninguna ronda de comentarios — nadie pidió cambios, entraron y ya.
- Según otro análisis, sobre 40.214 PR, el 77,51 % de los PR de agent fusionados los fusionó quien los envió, frente al 57,63 % de los PR humanos.
De ahí sale el consejo más práctico de este post: en tu primera tarea, no fusiones tú tu propio PR de agent. Que lo mire otra persona. Según las cifras, este es el paso que más se salta la gente.
Ese mismo análisis trae también una paradoja curiosa: un comentario más de revisión sube un 2,7 % la probabilidad de merge de un PR humano, pero la baja un 2,8 % en uno agéntico. En un PR humano, muchos comentarios son diálogo; en un PR de agent, son un aviso.
El benchmark sobre el que nadie debería decidir una compra
El benchmark de programación más citado está hecho de issues reales de GitHub: te dan un repositorio en un estado concreto y una descripción de fallo, y hay que escribir un arreglo que pase los tests del arreglo original.
Lo que no mide: diseño, arquitectura, interfaz, rendimiento, mantenibilidad — y todo lo que no se puede comprobar con un test ya existente.
Hay dos cosas que conviene saber de él.
Está saturado. En el otoño de 2026 la cabeza de carrera anda por el 97 % en un conjunto de 500 elementos. A ese nivel, la diferencia en las pocas tareas que quedan ya no se distingue del ruido.
Y tuvo un problema serio. Un análisis de 2024 sobre la versión original, sin filtrar, encontró que en el 32,67 % de los arreglos correctos la solución estaba en el propio informe de fallo o en los comentarios, y que otro 31,08 % pasaba por tests flojos. Corregido, el resultado de ese mismo sistema cayó del 12,47 % al 3,97 %. El subconjunto filtrado por personas nacía justo para remediar esto — aunque tampoco resuelve del todo la filtración, porque las tareas salen de repositorios públicos.
Donde todavía queda margen: en una medición de 2026 construida sobre tareas de terminal, los modelos punteros rinden por debajo del 65 %.
Errores habituales
- «El agent resuelve tareas de cinco horas.» Con un cincuenta por ciento de probabilidad. Que tu primera tarea esté bastante por debajo de una hora.
- «Cuanto más detallada la tarea, mejor.» Lo que cuenta es la precisión del alcance, no la longitud. Si cuentas el diff en una frase, no planifiques.
- «Si ha terminado, está hecho.» La herramienta se detiene cuando el trabajo parece terminado. Sin comprobación, el único bucle de verificación eres tú.
- «Saca un 97 % en el benchmark, o sea que lo resuelve casi todo.» El benchmark está saturado, y no mide diseño, arquitectura ni mantenibilidad.
- «Si ha pasado el test, ya puedo fusionarlo.» Tres cuartas partes de los PR de agent fusionados los fusiona quien los envió. En la primera tarea, justo eso es lo que no hay que hacer.
Lo que conviene llevarse
Que la primera tarea sea pequeña, aburrida y lleve al lado una comprobación que el agent pueda ejecutar por su cuenta. Escribe cuál es el problema, qué cuenta como buena solución y de qué ficheros se trata. No le des la tarea con la que tú querías aprender, y no fusiones tu propio PR de agent.
De los modos de aprobación y de dónde conviene que corra todo esto habla el post elegir tu entorno de programación , arquitectura por arquitectura; y los patrones de error concretos del código ya terminado los reúne el post revisar el código generado , con ejemplos.