Six months ago the bottleneck was typing. You knew roughly what a feature needed to look like, and the slow part was producing the actual lines: remembering the right API, wiring up the edge cases, writing the test. An agent now does most of that in under a minute.
The bottleneck did not disappear. It moved two steps down the pipeline, to the part where a human decides whether what got produced is correct, and to the part before that, where a human decides what was worth producing in the first place.
#The ratio flipped
Ask a developer running an AI agent daily how their time actually splits and the honest answer is something like: fifteen minutes writing prompts, five minutes watching the agent work, and the rest of the day reading diffs, checking them against the rest of the codebase, and deciding what to do about the twelve other things the agent, a teammate, or a ticket queue also produced today.
That last part is easy to undercount because it does not look like work in the way typing does. There is no visible output while you are deciding whether the retry logic an agent just wrote handles the case where the queue is already draining, or whether the three open branches from three different agent sessions this week represent one fix or three overlapping ones. But it is where the hours go, and it scales with how much gets produced, not with how much of it you personally typed.
This is not a complaint about AI tooling. Producing more candidate changes per day is a genuine improvement. It just means the job description quietly changed from "write the correct thing" to "read enough of what got produced, correctly enough, to tell what is worth keeping and what needs attention next." Those are different skills, and most of the tooling built for the first one does not transfer cleanly to the second.
#Reviewing the diff answers one question. Prioritizing needs another.
Most of the writing about AI and code review stops at "read the diff carefully," and that part is correct as far as it goes: an agent's own summary of what it changed is generated from what it intended to do, not from the diff it produced, and the two diverge often enough that trusting the summary is a mistake. Reading the actual diff line by line is table stakes now, not a nice-to-have.
But reviewing one diff answers a narrow question: is this specific change correct. It does not answer the question that actually decides what your day looks like, which is what to work on next out of everything competing for attention: the three agent-generated branches sitting unreviewed, the ticket that has been reopened twice, the module that keeps showing up in bug reports.
That second question is not answered by looking harder at any single diff. It is answered by looking at the shape of the project over time: what keeps getting touched, what keeps breaking, what has been sitting still while everything around it moved. That is a history question, not a diff question, and it needs a different view to answer.
#What the history tells you that a ticket board doesn't
A backlog tells you what people said mattered when they wrote the ticket. It does not tell you what is actually happening in the code, and those two things drift apart faster with an agent in the loop, because an agent will happily generate five small fixes to the same file across five separate tasks without anyone noticing they are related.
The commit graph does notice, if you look at it as a whole rather than one commit at a time. Patterns that show up directly in the graph and rarely show up in a ticket title:
A file getting touched by unrelated fixes, repeatedly. Five commits in three weeks, four different authors or agent sessions, none of them referencing each other. That is not five bugs. That is one badly-shaped piece of code generating symptoms faster than anyone is treating the cause, and it is invisible if you only ever look at commits one at a time.
A branch that stopped moving. An agent produced a working fix eleven days ago,
nobody reviewed it, and it has been silently rotting against a main that has moved
on since. Every day it sits there, the eventual merge gets more expensive. A graph
view surfaces this as a visibly stalled line; a flat commit list does not.
A burst right before things broke. When something regresses, the fastest
starting point is rarely git bisect from scratch. It is looking at what actually
landed in the window before the symptom appeared, which the commit graph already
shows you faster than running a single test.
None of this requires new tooling in the sense of a new product category. It
requires actually looking at git log --graph as a working surface instead of an
occasional debugging tool, which is a habit almost nobody had reason to build until
the volume of commits went up.
#Two different questions, one window
Here is the practical problem with the tooling most people already have. The diff review happens in a pull request web view, one branch at a time, opened when someone requests review. The history view, if anyone opens it at all, happens separately in a terminal, usually only when something is already broken.
Those are two different tools for two different questions, and switching between them costs more than the few seconds of alt-tabbing suggests. You lose the context of what you were checking for in the diff by the time you are looking at the graph, and you lose the pattern you noticed in the graph by the time you are back in a single PR.
The fix is not a smarter model. It is treating "what changed in this diff" and "what has been happening in this project" as two views of the same information, kept open next to each other instead of behind separate tools. A git GUI built around the commit graph as the primary view, rather than a list of branches with the graph tucked into a secondary tab, does this by default: you are always looking at the shape of the project, and clicking into any commit drops you straight into its diff without leaving that context.
#A concrete version of this
What this looks like on an actual morning. Three agent sessions ran overnight or the previous evening, each on a separate branch: one added pagination to an export endpoint, one refactored a shared validator, one fixed a flaky test.
Before opening any of the three diffs, a look at the graph across all branches shows
that the validator refactor and the export endpoint both touch the same
schema.ts file that has come up in four commits over the past two weeks. That is
the signal worth acting on first, not because either individual diff looks wrong,
but because the file's recent history says it is the thing actually costing time
right now.
The validator refactor gets reviewed first and merged. The export endpoint change
gets rebased on top of it rather than reviewed against a schema.ts that is about
to change underneath it, which would have produced a conflict either way and wasted
a review cycle catching it after the fact instead of before. The flaky test fix,
unrelated to either, gets reviewed on its own and merged independently.
Nothing here required more than looking at the graph before diving into diffs one at a time in the order they happened to land. The order tickets arrived in, or the order agent sessions finished in, is not the order that reflects what the codebase actually needs next, and the history is what shows the difference.
#What this doesn't fix
None of this replaces reading the diff. A graph tells you where to look; it does not
tell you whether the catch block an agent added actually rethrows the way the rest
of the file does, or whether a retry count is a reasonable value or a plausible-
sounding one with no basis in your system. That part is still manual, still slow
relative to how fast the code got written, and there is no shortcut for it that
survives contact with a real regression.
What changes is how much of your limited attention goes to the right diff first. When five things need review and only one of them is actually urgent because of what the history says about it, spending the first look on the graph rather than on whichever branch opened most recently is the difference between an afternoon spent on the right problem and one spent working through a queue in arrival order.
#Same Git, different job
The commands have not changed. git log, git diff, git merge are the same
operations they were before any of this. What changed is which of them you reach for
first and how often.
Writing code got faster. Deciding what to do with what got written did not, and it was never really a typing problem to begin with. It was always a question of context: what else is happening in this codebase, what has already been tried, what keeps recurring. That context lived in the history the whole time. The only thing that changed is how much it now matters whether your tools make it easy to see.