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. These are not 200 major features. They are the pile that accumulates around any mature system: dependency updates, configuration changes, accessibility fixes, small bugs, deprecated APIs to replace, logging tweaks, security findings, validation gaps, flaky tests, minor UI problems. Most of them are not hard. That does not make them fast.

Hand one of those tickets to a developer and watch what actually happens. They read the ticket and figure out which repository it belongs to. They pull down the latest code, search for the relevant area, and work out how that part of the system fits together. They read through the history, find the related tests, and decide whether the ticket 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 confidently know which fifteen minutes of coding to do can take an hour. Then they finish the ticket, throw away most of what they just learned, and start the whole thing over on the next one.

That Is Throughput, Not Typing

This is why a strong developer can spend a full day on what look like small tickets and close two or three of them. They are not slow, and the coding is not slow. The system around the coding is slow. Every ticket carries an onboarding cost, and that cost turns ugly when you multiply it by a few hundred.

Say each of our five developers finishes three tickets a day. That is roughly fifteen a day for the team, so 200 tickets is more than thirteen team-days of work, and that assumes nothing goes wrong, nobody gets interrupted, every ticket is understood on the first read, and none of the changes turn out to be complicated. That is not a coding problem. It is a throughput problem, and the distinction is the whole point. The developer who closed three tickets on Monday was fighting throughput, not typing speed.

Put the AI at the Front of the Line

Now change one thing. Instead of handing the developer a cold ticket, hand it to an AI agent first. Tell it to investigate: read the ticket, find the relevant code, look at the surrounding implementation, read the tests, check for related changes, and work out what probably needs to happen. Then have it make the change and open a pull request.

The developer now starts from somewhere completely different. They have the original ticket, the agent's investigation, a proposed change, the tests, and a pull request with an actual implementation in it. Maybe that implementation is right. Maybe it is mostly right. Maybe it is wrong, and that possibility matters, because the argument does not 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." Those are very different places to begin your day.

The First Pull Request Is Not the Last One

I think this is where a lot of the AI conversation goes sideways. People ask whether the agent can autonomously complete the ticket, which sets the bar unnecessarily high. The more useful question is quieter: what if it can reliably get the ticket sixty percent of the way there? What if it can find the relevant code, understand the likely change, make a reasonable first attempt, run the tests, and put the result in front of a developer?

That is already worth a great deal. The developer can reject the pull request, modify it, tell the agent what it misunderstood and let it try again, or take over and finish the work themselves. The human does not disappear. The human just did not spend the first hour of the ticket figuring out where to start. Across one ticket, that is a nice convenience. Across 200 tickets and a deadline, it changes the economics of the whole project.

The Machine Is Cheap at Starting Over

Humans pay a real price for context switching.¹ Every new ticket makes us build a mental model from scratch: where am I, what does this code do, why was it written this way, what is this ticket actually asking for, what else might this change break. Then we finish, discard most of that model, and rebuild it for the next ticket. The rebuild is invisible on a timesheet and expensive in practice.

An AI agent does not work that way. It can read the repository and the ticket, search broadly, trace references, look at the tests, and propose a change very quickly, and it feels no friction dropping one context and picking up the next. So one of the most expensive things a human developer does becomes one of the cheapest things the machine does. The real acceleration is not how quickly AI finishes a ticket. It is how cheaply it starts one, and that matters most exactly when the work is a large pile of loosely related pieces.

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 proficient enough with AI to see real results. There is a maturity curve, and it is real. Teams need better tooling, good prompts and context, sensible guardrails, and a feel for where AI works and where it does not. Eventually they build more capable agents and more automation around them.

But the value does not wait at the end of that journey. You do not need autonomous software engineering to come out ahead. You need a pile of work and a machine that can do a competent first pass. If I have 200 tickets and a short deadline, I do not need AI to replace five developers. I need it to make sure those five developers stop starting every ticket from zero. That is a far lower bar, and it is something a team can do today.

The Bottleneck Just Moves

Of course, this creates a new problem. If an agent can investigate tickets and open initial pull requests faster than humans can, the queue moves somewhere else. Now you might have ten pull requests waiting for review instead of ten tickets waiting for someone to understand them. Good. That is progress. The constraint moved from understanding and implementation toward validation and decision-making,² and validation is a much better problem to have than hundreds of tickets sitting untouched because nobody has had time to read them.

It is also a problem we know how to attack. We can strengthen automated testing, make CI more reliable, sharpen static analysis, keep pull requests small, attach better evidence to each change, and automate the mechanical parts of review. None of that removes human judgment from the loop, but it moves the human effort to the place where judgment is actually scarce.³

Stop Measuring AI by Typing Speed

We keep asking how much faster AI makes programmers, and I think that is the wrong unit. Measure the system instead. How long does a ticket sit before anyone investigates it? How long from ticket to first proposed solution? How much developer time goes into reconstructing context? How long does a change wait for implementation versus review? How many tickets can the team move through the entire system 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.⁴ Software delivery was never mainly constrained by how quickly someone could type. It was constrained by queues, context, handoffs, uncertainty, review, testing, deployment, and the limited attention of the people doing the work, and AI changes several of those at once.

Which brings me back to that developer closing three tickets on a Monday. Nothing about that day was wasteful, and nothing about it was fast, because the cost was hidden in the cold start on every ticket. Take that cost away and the day looks completely different. The developer no longer opens each ticket by staring at a blank screen and a strange repository, wondering where to begin. That, more than typing speed, is the near-term win.