Do you still assign tickets to developers when AI coding agents write the code?

Short answer: you still assign work to a person, because someone has to answer for the result, but the ticket stopped being the thing you are assigning. The unit that actually moves the code is the agent session. Measured on the repository behind this website on August 13, 2026: 214 of the 251 non merge commits made between July 18 and August 10, 2026 came out of 24 AI coding agent sessions, and the median session produced 7 commits in 48 minutes across 21 files. A ticket sized for a person to work on for two days is now smaller than one sitting of one agent. Assign the session, review the session, and keep the ticket for what it was always good at, which is saying why the work exists.

What changed about the unit of work when AI coding agents arrived?

Before AI coding agents, a ticket and a unit of work were roughly the same object. A developer picked up a card, worked for hours or days, and the commits that came out of it were an artifact of that one person's attention. Planning worked because the card was the smallest thing you could hand to someone, and because handing it over meant handing over the whole thing.

With Claude Code, Codex or any agent CLI in the loop, the smallest thing you can hand over is a session: one conversation, with one goal, that runs until the goal is met or abandoned. The session is what has a beginning, an end, a context and a result. The ticket is now a label attached to somewhere between a fraction of a session and several of them. That is not a philosophical claim, it is a shape you can measure in your own git history, and the numbers below are ours.

The practical consequence is that the questions a process is supposed to answer have moved. "Who is working on this" used to identify a person and a card. It now has to identify a person, a session, and the branch or worktree that session is writing into, because a person can start a session and walk away while it keeps producing.

How big is one AI coding agent session, measured?

We measured the repository behind this website, which is a useful sample because it is an extreme one: the site is written by AI coding agents working in parallel git worktrees, with one human operator reviewing and committing. Every commit made inside an agent session carries a Claude-Session trailer, so the sessions can be reconstructed from the git history alone.

Of 251 non merge commits between July 18 and August 10, 2026, 214 carry the trailer, which is 85.3%, and they group into 24 distinct sessions. Median here means the twelfth value of the twenty four sorted values, and we use that one definition everywhere below. One warning before you read the table: all three values in the Largest column come from the same single session, so that column is one outlier described three ways, not three separate examples of a big session.

Two numbers in that table deserve reading together. The median session is short, 48 minutes, and 14 of the 24 sessions finished in under an hour. But the median session touches 21 files, which is wider than a ticket is usually written to cover, and that comparison is our judgement rather than a second measurement. So the shape is not "smaller pieces of work". It is the opposite: a short sitting that reaches wide. As for the outlier that owns the whole Largest column, its 65 hours are days of being resumed rather than one continuous run, which is a limitation of how we measure time and not a heroic sitting.

Do AI coding agent sessions actually run in parallel?

This is where our own data surprised us. If you take each of the 24 sessions and reduce it to a window, from its first commit to its last, and then ask how many of the 276 possible pairs of windows overlap in time, the answer is 4. Under two percent. In a repository built specifically to run several AI coding agents at once, the git history looks almost entirely sequential.

The wrong conclusion is that the parallelism did not happen. Those 4 pairs are 4 stretches where two sessions were provably writing at the same time, and the isolated worktrees exist precisely so that more can. The right conclusion is narrower and more useful: the record git keeps is serial even when the work was parallel, because a session that runs for an hour and commits at the end appears in history as an instant. Commit time is delivery time, not work time.

That matters for process design, because it means any dashboard built on git activity will under report how much is in flight. If your team is deciding how many agents one person can supervise, the git history will tell you a comforting story that is not the story of the afternoon. The observation has to come from the agent runtime, not from the repository.

What do you assign to a person, then?

You assign the session and the review of its output, and you name the destination before it starts. In practice that means three things travel together instead of one card: the goal in words the agent can act on, the isolated place it will write into, which for us is a dedicated git worktree and branch, and the person who will read the result and answer for it. Drop any of the three and the work becomes hard to place afterwards.

The reason the destination has to be decided up front is mundane and expensive: two sessions writing into the same working directory produce changes that are almost impossible to separate later. We wrote about the mechanics of that in how to run multiple AI agents without overwriting each other. The reason the person has to be named is that git will name them anyway: in our 251 commits, the author field holds a single human name in every one, which is the subject of who is responsible for the code an AI coding agent wrote.

Tickets do not disappear in this arrangement. They stop being the unit of execution and become what they were always better at: a durable statement of why a change exists, which outlives the session and is what someone reads in six months when the code looks strange.

What breaks if you keep assigning tickets the old way?

Three things break, and they break quietly. The first is estimation: a card sized for a person's day maps onto nothing, because a session either finishes it in 40 minutes or opens up a problem that is bigger than the card ever described. Velocity measured in cards stops tracking anything real.

The second is review. If the ticket is the unit, review arrives at the end, on a diff that may span the 21 files a median session touched here. Reviewing 21 files as a single act is where teams start rubber stamping. Splitting review by session, while each session's context is still recoverable, is the version of this that stays honest.

The third is attribution of trouble. When a bug shows up and you ask which change caused it, a ticket number will point you at a body of work spread across sittings. A session identifier points at one conversation with one goal, and it is the only thing that lets you ask what the agent was told at the time. That record only exists if something wrote it at commit time, and it cannot be reconstructed afterwards.

Does this mean one person can only supervise one agent?

No, and our own numbers should not be read that way. The 4 overlapping pairs out of 276 measure commit windows, not attention, and this repository has one operator who works in bursts rather than a team of five running agents all day. What the number does say is that the git record will not tell you the answer, so a team wanting to know how many agents per person is workable has to measure it somewhere else.

The limit in practice is not how many agents can run, it is how many can be waiting for you without you noticing. An agent stopped on a question produces nothing and looks identical, in most tooling, to an agent thinking hard. That is why the state of each session, and not the count of sessions, is the thing worth putting on screen. CanvasCode, the Mac app this site belongs to, reads that state from the agent CLI's own hooks and notifies you when a session needs an answer, including when it is in a project you are not looking at.

How do you measure this in your own repository?

If your tooling writes a session trailer, this is three commands and it only reads. First find out whether you have one at all, because an empty answer is the answer:

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

Then group the commits by session, printing commit count and wall clock minutes for each. Replace Claude-Session with whatever key your tooling writes:

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

And then ask how much of it really ran at the same time, which is the number worth arguing about in a planning meeting:

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
  }'

On this repository the second command prints sessions=24 overlapping_pairs=4 of 276. Both commands use only git and awk, so they behave the same on macOS and Linux without installing anything.

What this measurement does not show

It is one repository, 24 days, one operator, and a project whose whole purpose is running agents in parallel, so the shape of a session here is not a market average. The session trailer marks the session, never the authorship of a line: a session can sign dozens of commits, and a human editing inside a session produces a commit that looks identical to one the agent produced alone. Wall clock is measured between first and last commit of a session, which undercounts thinking time before the first commit and counts the gap when a session was resumed days later. And the 37 non trailer commits are not noise to ignore: 26 of them landed on a single day, July 20, which is a reminder that a record only exists where something was configured to write it.

What survives all of that is the ratio between the two shapes: a median sitting under an hour, reaching across 21 files. That is the part we would expect to hold elsewhere, and the part that makes the ticket the wrong container.