How much AI agent code do you actually have to review?

Short answer: in three weeks of one repository where AI coding agents write almost every line, 88 commits changed 35,492 lines. The median commit was 85 lines, small enough to read over coffee, but 7 commits, 8% of them, carried half of the total, and a single day delivered 12,679 lines across 105 files. Review load from AI coding agents does not arrive as a stream, it arrives in bursts, so plan your day around the peak instead of the average.

How much AI agent code arrives in three weeks?

In the repository behind CanvasCode, where AI coding agents write almost every line and a human reviews before anything merges, three weeks produced 88 commits and 35,492 changed lines, counting insertions and deletions together. Those 88 are the commits that introduce lines: the period also contains 27 merge commits, which git reports no line statistics for because they carry no changes of their own. That is the raw review load, and every one of those lines had to be looked at by someone before it reached the main branch.

The number that surprised us was not the total, it was the calendar. Of 21 days, only 10 had any commit at all. The other 11 produced nothing to review, which means the work did not spread itself over the period. It piled up on a third of the days and left the rest empty. An average of 1,690 lines per day is arithmetically true and describes no day that actually happened.

Why does the median mislead you about AI review load?

The median commit in those three weeks changed 85 lines. Median here means the middle value once every commit is sorted by size, and with an even number of commits it is the average of the two middle ones, 85.5, which the command below prints as 85. Read alone, that number says review is easy: 85 lines is a few minutes of attention.

The distribution says something else. Sorting the same 88 commits from largest to smallest, 7 of them carry half of all 35,492 lines. The largest single commit changed 4,007 lines by itself. So the typical commit is small and the load is not, because the load lives in the tail. Any planning built on the median, such as budgeting half an hour a day for reviewing what your AI coding agents produced, survives most days and collapses on the days that matter.

What does a peak day of AI agent output look like?

The worst day in the window, August 7, 2026, delivered 25 commits and 12,679 changed lines touching 105 distinct files. That is 36% of three weeks of output arriving inside one day. The first commit landed at 12:51 and the last at 23:23, ten and a half hours later, so it was not one sitting either: the day was a steady drip that added up to a flood.

This is the shape that breaks review, and it breaks it in a specific way. A reviewer facing 12,679 lines cannot apply the same care to line 12,000 as to line 100. The realistic outcomes are approving in bulk, which defeats the review, or stopping the agents while you catch up, which defeats the parallelism you set up in the first place. Neither is a technique problem, and neither gets better by reading faster.

How do you measure the review load in your own repository?

Two commands, both plain git and POSIX awk, no extra tooling. They count insertions and deletions together, because a deleted line still has to be read before you agree it should go. The first prints the totals, the median and how concentrated the load is. Run it inside any repository:

git log --since=3.weeks --pretty=tformat:'C' --shortstat |
awk '/files? changed/{
  ins=0; del=0
  for (i=1; i<=NF; i++) {
    if ($(i+1) ~ /^insertion/) ins=$i
    if ($(i+1) ~ /^deletion/)  del=$i
  }
  print ins+del
}' | sort -rn | awk '{ t+=$1; a[NR]=$1 }
END {
  half=t/2; s=0
  for (i=1; i<=NR; i++) { s+=a[i]; if (s>=half) break }
  printf "%d commits, %d lines changed\n", NR, t
  printf "median %d lines per commit\n", (NR%2 ? a[(NR+1)/2] : (a[NR/2]+a[NR/2+1])/2)
  printf "%d commits (%.0f%%) carry half of that\n", i, i*100/NR
}'

On our repository it prints:

88 commits, 35492 lines changed
median 85 lines per commit
7 commits (8%) carry half of that

That output is ours on August 13, 2026. The window is relative, so the same command run on another day covers another three weeks: compare it with your own number, not with the one printed above. The second command shows the calendar, which is where the burst becomes visible:

git log --since=3.weeks --pretty=tformat:'C %ad' --date=format:'%Y-%m-%d' --shortstat |
awk '/^C /{ d=$2; next }
     /files? changed/{
       ins=0; del=0
       for (i=1; i<=NF; i++) {
         if ($(i+1) ~ /^insertion/) ins=$i
         if ($(i+1) ~ /^deletion/)  del=$i
       }
       n[d]++; L[d]+=ins+del
     }
     END { for (d in L) printf "%s  %3d commits  %6d lines\n", d, n[d], L[d] }' | sort

If your output has a few enormous days and many empty ones, your review problem is scheduling, not technique.

Does the burst change how you should review?

It changes what you do before reviewing, not the review itself. The order we use for reading AI agent output stays the same on a quiet day and on a peak day: start from what should not have changed, then look for the test that would fail if the change were wrong, then read the code. That method is a separate article, how to review code written by multiple AI agents, and this one deliberately does not repeat it.

The boundary between the two is worth stating plainly, because they answer different questions. That article answers how to review one delivery from an AI coding agent. This one answers how much arrives and when, which is a capacity question. Method does not save you from a 12,679 line day. Only changing the arrival does.

Can you smooth the burst instead of absorbing it?

Three things move the arrival, and none of them is reviewing faster. The first is asking for smaller deliveries per front, which is the only lever the reviewer controls directly. The second is a machine gate before the human one: tests, linter and static analysis running on each front, so what reaches a person is already known to compile and pass. In our repository nothing reaches review without that gate, and it is the reason the peak day was survivable at all.

The third is sequencing the merges instead of letting fronts finish together, which is the same problem described in merging work from multiple AI coding agents. Fronts that land at once produce a burst even when each front was reasonable on its own. Staggering them turns one unreviewable day into three reviewable ones.

What this was measured on, and what it does not prove

One repository, three weeks, measured on August 13, 2026, on a Laravel web application where AI coding agents write content and features under a human gate. That is a small sample and a specific kind of project. Your distribution will differ, and the commands above exist so you can check yours instead of trusting ours.

Two limits we know about. First, five of the 88 commits carry no session marker, so any per session reading of this data is missing a little; the numbers in this article count every non-merge commit and do not depend on that marker at all. Second, lines changed is a proxy for review effort, not a measure of it: 500 lines of a generated migration read faster than 50 lines of business logic. The burst is real, but the exact cost of a line is not something this measurement can settle.