The Ticket That Takes an Hour to Start

Picture a team of five developers with 200 tickets that have to be done before a deadline. The pile is the kind that builds up around any mature system: dependency updates, deprecated APIs to replace, flaky tests, accessibility fixes, security findings, logging tweaks, and small bugs nobody has gotten around to. Most of them are easy, and almost none of them are fast.

Hand one of those tickets to a developer and watch what happens. Say it's a security finding that the password reset handler writes reset tokens to the application log. They figure out which repository the handler lives in, pull down the latest code, and search for the part of the system it touches. They read through the history and the related tests, and somewhere in there they decide whether the finding is even still valid. Only then do they work out what probably needs to change, and only then do they change it. The change itself might take fifteen minutes. Getting to the point where they know which fifteen minutes of coding to do can take an hour. Then they close the ticket, throw away most of what they just learned about the reset flow, and start over on the next one.

Throughput Is the Constraint

That's how a strong developer spends a full day on what look like small tickets and closes two or three of them. The slow part is the work around the coding. Every ticket carries its own onboarding cost, and that cost turns ugly once you multiply it by a few hundred.

Say each of our five developers finishes three tickets a day, which is the Monday from the top of this piece repeated across a whole team. That's fifteen a day, so 200 tickets is more than thirteen team-days of work, and that assumes nobody gets interrupted and none of the changes turn out to be complicated. Thirteen days is a throughput number.

You could double everyone's typing speed and barely move it.

Put the AI at the Front of the Line

Now change one thing. Instead of handing the developer a cold ticket, give it to an AI agent first and have it investigate. It reads the ticket and finds the reset handler along with the code and tests around it. Then it works out what probably needs to change, makes the change, and opens a pull request.

The developer now starts from somewhere else entirely, with the agent's notes and a pull request that already has code in it. Maybe that code is right. Maybe it's only mostly right, or wrong, and that possibility matters, because the argument doesn't depend on the agent getting every ticket right.

The developer's job has changed from "figure out what this ticket means and decide what to do" to "decide whether this proposed solution is correct." Reading a short diff that stops the token from reaching the log takes a few minutes, and finding where the token was being logged is what used to eat the hour.

Sixty Percent of the Way There

A lot of the AI conversation goes sideways right here. People ask whether the agent can complete the ticket on its own, which sets the bar higher than it needs to be. The more useful question is whether it can reliably get the ticket sixty percent of the way there, with the relevant code found and a sensible first attempt that has already been through the test suite, sitting in front of a developer.

That's worth a lot already. The developer can reject the pull request, fix it, or tell the agent what it misunderstood and let it try again, and they can always take over and finish it themselves. What they didn't do was spend the first hour of the ticket figuring out where to start, and across 200 tickets and a deadline, that hour is most of the schedule.

The Machine Is Cheap at Starting Over

Humans pay a price for context switching.¹ Every new ticket makes us build a mental model from scratch, starting with where the code lives and why it was written this way and ending with what else the change might break. Then we finish, discard most of that model, and rebuild it for the next ticket, and none of that rebuilding shows up on a timesheet.

An agent doesn't pay that price the same way. It reads the repository and the ticket, traces references, and proposes a change in minutes, and it feels no friction dropping one context and picking up the next. The acceleration that matters is how cheaply AI starts a ticket, more than how quickly it finishes one. One of the most expensive things a human developer does turns into one of the cheapest things the machine does, and that pays off most when the work is a big pile of loosely related pieces, like those 200 tickets.

You Do Not Need a Year to Get Value

This also changes how I read the claim that an organization needs months, or a year, to get good enough with AI to see results. There is a maturity curve. Teams need better tooling and context, sensible guardrails, and a feel for where AI works and where it doesn't, and eventually they build more capable agents and more automation around them.

The value starts well before the end of that curve. A pile of work and a machine that can do a competent first pass are enough to come out ahead. If I had 200 tickets and a short deadline, what I'd want from AI is much smaller than replacing five developers. I'd want those five developers to stop starting every ticket from zero, and a team can set that up today.

The Bottleneck Just Moves

This creates a new problem. If an agent can investigate tickets and open pull requests faster than people can review them, the queue moves. You might have ten pull requests waiting for review where you used to have ten tickets waiting for someone to understand them, and I'll take that trade every time. The constraint moved from understanding and implementation toward validation and decision-making,² which beats hundreds of tickets sitting untouched because nobody has had time to read them.

It's also a problem we know how to attack. Keep pull requests small, make CI reliable enough that a green build means something, and attach evidence to each change, like the test that proves the reset token no longer reaches the log. Human judgment stays in the loop, and the effort moves to the place where judgment is scarce.³

Stop Measuring AI by Typing Speed

We keep asking how much faster AI makes programmers, and I think that's the wrong unit. Measure the system instead. How long does a ticket sit before anyone investigates it, and how long after that until there's a proposed solution? How much of a developer's day goes into reconstructing context, and does a change wait longer for implementation or for review? How many tickets does the team move all the way through in a week?

Those numbers tell you far more than lines of code or some claim that an AI-assisted developer is twenty percent or fifty percent or ten times faster.⁴ Delivery has always been held up by queues, handoffs, and the limited attention of the people doing the work much more than by anybody's typing, and AI changes several of those at once.

Go back to that Monday with three tickets closed and nobody able to say where the day went. Nothing about it was wasteful. The hours went into the cold start on every ticket, and if an agent has already found the reset handler and opened a pull request before the developer sits down, the day starts with a decision instead of a blank screen and a strange repository.