¿Sigue teniendo sentido asignar tareas a desarrolladores cuando los agentes de IA escriben el código?

Respuesta corta: sigues asignando el trabajo a una persona, porque alguien tiene que responder por el resultado, pero la tarea dejó de ser aquello que estás asignando. La unidad que de verdad mueve el código es la sesión del agente. Medido en el repositorio de este sitio el 13 de agosto de 2026: 214 de los 251 commits sin merge hechos entre el 18 de julio y el 10 de agosto de 2026 salieron de 24 sesiones de agente de IA, y la sesión mediana produjo 7 commits en 48 minutos, tocando 21 archivos. Una tarea dimensionada para que una persona trabaje dos días hoy es más pequeña que una sentada de un agente. Asigna la sesión, revisa la sesión, y deja la tarea para lo que siempre hizo bien, que es decir por qué ese trabajo existe.

¿Qué cambió en la unidad de trabajo cuando llegaron los agentes de IA?

Antes de los agentes de IA de programación, tarea y unidad de trabajo eran casi el mismo objeto. El desarrollador tomaba una tarjeta, trabajaba horas o días, y los commits que salían de ahí eran artefacto de la atención de esa persona. La planificación funcionaba porque la tarjeta era lo más pequeño que se le podía entregar a alguien, y entregarla significaba entregarla entera.

Con Claude Code, Codex o cualquier CLI de agente en el circuito, lo más pequeño que puedes entregar es una sesión: una conversación, con un objetivo, que corre hasta que el objetivo se cumple o se abandona. La sesión es lo que tiene principio, final, contexto y resultado. La tarea pasó a ser una etiqueta pegada a algo entre una fracción de sesión y varias de ellas. Esto no es una afirmación filosófica, es una forma que puedes medir en tu propio historial de git, y los números de abajo son los nuestros.

La consecuencia práctica es que las preguntas que un proceso existe para responder cambiaron de lugar. "Quién está trabajando en esto" identificaba a una persona y una tarjeta. Ahora tiene que identificar a una persona, una sesión y la rama o worktree en la que esa sesión escribe, porque alguien puede iniciar una sesión y alejarse mientras ella sigue produciendo.

¿Cuál es el tamaño de una sesión de agente de IA, medido?

Medimos el repositorio de este sitio, que es una muestra útil justamente por ser extrema: el sitio lo escriben agentes de IA trabajando en worktrees paralelas de git, con un operador humano que revisa y hace los commits. Cada commit hecho dentro de una sesión de agente lleva un trailer Claude-Session, así que las sesiones se reconstruyen solo con el historial de git.

De los 251 commits sin merge entre el 18 de julio y el 10 de agosto de 2026, 214 llevan el trailer, o sea el 85,3%, y se agrupan en 24 sesiones distintas. Mediana aquí significa el duodécimo valor de los veinticuatro valores ordenados, y usamos esa definición única en todo lo que sigue. Un aviso antes de que leas la tabla: los tres valores de la columna Mayor vienen todos de la MISMA sesión, así que esa columna es un único caso atípico descrito de tres maneras, y no tres ejemplos distintos de sesión grande.

Dos números de esa tabla piden lectura conjunta. La sesión mediana es corta, 48 minutos, y 14 de las 24 sesiones terminaron en menos de una hora. Pero la sesión mediana toca 21 archivos, que es más ancho de lo que una tarea suele estar escrita para cubrir, y esa comparación es juicio nuestro, no una segunda medición. La forma, entonces, no es "pedazos más pequeños de trabajo". Es lo contrario: una sentada corta que alcanza lejos. En cuanto al caso atípico que es dueño de toda la columna Mayor, sus 65 horas son días de retomarla y no una maratón continua, lo que es limitación de cómo medimos el tiempo y no hazaña.

¿Las sesiones de agente de IA corren de verdad en paralelo?

Aquí fue donde nuestro propio dato sorprendió. Si reduces cada una de las 24 sesiones a una ventana, del primero al último commit, y preguntas cuántos de los 276 pares posibles de ventanas se superponen en el tiempo, la respuesta es 4. Menos del dos por ciento. En un repositorio construido específicamente para correr varios agentes de IA a la vez, el historial de git parece casi enteramente secuencial.

La conclusión equivocada es que el paralelismo no ocurrió. Esos 4 pares son 4 tramos en que dos sesiones escribían comprobadamente al mismo tiempo, y las worktrees aisladas existen justamente para que puedan ser más. La conclusión correcta es más estrecha y más útil: el registro que git guarda es serial aunque el trabajo haya sido paralelo, porque una sesión que corre una hora y hace commit al final aparece en el historial como un instante. Hora del commit es hora de entrega, no hora de trabajo.

Eso importa para diseñar procesos, porque significa que cualquier tablero construido sobre actividad de git va a subreportar cuánto está en curso. Si tu equipo está decidiendo cuántos agentes puede supervisar una persona, el historial de git contará una historia cómoda que no es la historia de la tarde. La observación tiene que venir del runtime del agente, no del repositorio.

¿Qué se le asigna a una persona, entonces?

Le asignas la sesión y la revisión de lo que produjo, y nombras el destino antes de empezar. En la práctica, tres cosas viajan juntas en vez de una tarjeta: el objetivo en palabras sobre las que el agente pueda actuar, el lugar aislado donde va a escribir, que aquí es una worktree y una rama dedicadas, y la persona que va a leer el resultado y responder por él. Quita cualquiera de las tres y el trabajo se vuelve difícil de ubicar después.

El motivo de decidir el destino de antemano es banal y caro: dos sesiones escribiendo en el mismo directorio de trabajo producen cambios casi imposibles de separar después. Escribimos sobre la mecánica de eso en cómo ejecutar varios agentes de IA sin que se sobrescriban. El motivo de nombrar a la persona es que git la va a nombrar de todos modos: en nuestros 251 commits, el campo de autor tiene un único nombre humano en todos, que es el tema de quién responde por el código que escribió un agente de IA.

Las tareas no desaparecen en este arreglo. Dejan de ser la unidad de ejecución y vuelven a ser lo que siempre hicieron mejor: un registro duradero de por qué existe un cambio, que sobrevive a la sesión y es lo que alguien lee dentro de seis meses cuando el código parezca extraño.

¿Qué se rompe si sigues asignando tareas a la antigua?

Se rompen tres cosas, y se rompen en silencio. La primera es la estimación: una tarjeta dimensionada para el día de una persona no mapea a nada, porque una sesión o la resuelve en 40 minutos, o abre un problema mayor del que la tarjeta jamás describió. La velocidad medida en tarjetas deja de seguir algo real.

La segunda es la revisión. Si la tarea es la unidad, la revisión llega al final, sobre un diff que puede atravesar los 21 archivos que tocó aquí la sesión mediana. Revisar 21 archivos como un solo acto es donde los equipos empiezan a sellar sin mirar. Partir la revisión por sesión, mientras el contexto de cada una todavía es recuperable, es la versión de esto que se sostiene.

La tercera es la atribución del problema. Cuando aparece un defecto y preguntas qué cambio lo causó, un número de tarea apunta a un cuerpo de trabajo repartido en varias sentadas. Un identificador de sesión apunta a una conversación con un objetivo, y es lo único que permite preguntar qué se le dijo al agente en ese momento. Ese registro solo existe si algo lo escribió en el momento del commit, y no se reconstruye después.

¿Significa que una persona solo puede supervisar un agente?

No, y nuestros números no deben leerse así. Los 4 pares superpuestos de 276 miden ventanas de commit, no atención, y este repositorio tiene un operador que trabaja a ráfagas, no un equipo de cinco personas corriendo agentes todo el día. Lo que el número sí dice es que el registro de git no va a responder esa pregunta, así que un equipo que quiera saber cuántos agentes por persona funcionan tiene que medirlo en otro lado.

El límite en la práctica no es cuántos agentes pueden correr, es cuántos pueden quedarse esperándote sin que lo notes. Un agente detenido en una pregunta no produce nada y, en la mayoría de las herramientas, es idéntico a un agente pensando con esfuerzo. Por eso el estado de cada sesión, y no el conteo de sesiones, es lo que vale poner en pantalla. CanvasCode, la app de Mac a la que pertenece este sitio, lee ese estado por los hooks de la propia CLI del agente y avisa cuando una sesión necesita respuesta, incluso cuando está en un proyecto que no estás mirando.

¿Cómo medir esto en tu propio repositorio?

Si tu herramienta escribe un trailer de sesión, son tres comandos y todos solo leen. Primero averigua si tienes alguno, porque la respuesta vacía también es respuesta:

git log -1 --format='%(trailers)'

Después agrupa los commits por sesión, imprimiendo conteo de commits y minutos de reloj de cada una. Cambia Claude-Session por la clave que escriba tu herramienta:

git log --no-merges --pretty=tformat:'%(trailers:key=Claude-Session,valueonly,separator=%x2C)%x09%at' |
awk -F'\t' '$1 != "" {
    n[$1]++
    if (!($1 in lo) || $2+0 < lo[$1]) { lo[$1] = $2+0 }
    if ($2+0 > hi[$1]) { hi[$1] = $2+0 }
  }
  END { for (s in n) { printf "%d commits\t%d min\n", n[s], (hi[s]-lo[s])/60 } }' |
sort -n

Y luego pregunta cuánto de eso corrió realmente al mismo tiempo, que es el número que vale discutir en una reunión de planificación:

git log --no-merges --pretty=tformat:'%(trailers:key=Claude-Session,valueonly,separator=%x2C)%x09%at' |
awk -F'\t' '$1 != "" {
    if (!($1 in lo) || $2+0 < lo[$1]) { lo[$1] = $2+0 }
    if ($2+0 > hi[$1]) { hi[$1] = $2+0 }
  }
  END {
    n = 0
    for (s in lo) { n++; a[n] = lo[s]; b[n] = hi[s] }
    pairs = 0; overlap = 0
    for (i = 1; i <= n; i++) {
      for (j = i + 1; j <= n; j++) {
        pairs++
        if (a[i] < b[j] && a[j] < b[i]) { overlap++ }
      }
    }
    printf "sessions=%d overlapping_pairs=%d of %d\n", n, overlap, pairs
  }'

En este repositorio el segundo comando imprime sessions=24 overlapping_pairs=4 of 276. Ambos comandos usan solo git y awk, así que se comportan igual en macOS y en Linux sin instalar nada.

Lo que esta medición no muestra

Es un repositorio, 24 días, un operador, y un proyecto cuyo propósito entero es correr agentes en paralelo, así que la forma de una sesión aquí no es un promedio de mercado. El trailer marca la sesión, nunca la autoría de una línea: una sesión puede firmar decenas de commits, y un humano editando dentro de una sesión produce un commit idéntico al que el agente produciría solo. El tiempo de reloj se mide entre el primero y el último commit de la sesión, lo que subcuenta el tiempo de razonamiento antes del primer commit y cuenta el intervalo cuando la sesión se retomó días después. Y los 37 commits sin trailer no son ruido a ignorar: 26 de ellos cayeron en un solo día, el 20 de julio, lo que recuerda que un registro solo existe donde algo fue configurado para escribirlo.

Lo que sobrevive a todo eso es la razón entre las dos formas: una sentada mediana de menos de una hora, alcanzando 21 archivos. Esa es la parte que esperaríamos ver en otros lugares, y la parte que hace de la tarea el recipiente equivocado.