RESEARCH NOTE / 21 JULY 2026

Estimating software in the age of agents

How AI changes the calculus of human hours, outcomes, and how delivery gets priced

An estimate has always been denominated in human hours. One person, one day, eight hours. Things took a big turn when Claude Code launched in early 2025: now an agent can run alongside you and actually provide useful output as you build. So when three of them run for an hour, was that one hour of work or four? Does adding a fifth agent make things run faster, or are we just backlogging it all into code review and QA? The unit we plan in and bill in no longer accurately measures productivity.

My first temptation was to track harder. Count agent minutes, meter tokens, multiply. I realized that doubles down on the wrong question.

The question that survives is about outcomes, not outputs. Output has clearly multiplied; look at all the AI-spend leaderboards companies put up (and have since started to take down). Whether outcomes arrive faster is the question that is still up in the air.

My take: the productivity is there. Translating it into actual business value, much less so. Here is the cycle I keep observing, in my own work and my team's: the first 80 percent of a production build arrives startlingly fast. The last stretch takes nearly as long as it ever did. Review, integration, the edge cases, the part where the system meets reality. A prototype can stop at the 80 percent. A production tool cannot, and the temptation for someone removed from the work is to assume everything now moves at prototype speed.

AI accelerates writing software. It does not accelerate every part of delivery equally. It also skirts the question of whether this should be built at all, and a lot of the saved time ends up being spent chasing cars, not driving value.

The proposal problem

This stops being philosophical the moment you have to write a proposal. Clients need a number. Stakeholders need a date. Those needs are legitimate; it's how businesses operate.

But if you price by time, whose time? The human's hours no longer track the work. The agents' hours do not track the value. And if you price by outcome, you are carrying the uncertainty that the estimate used to hide: the 20 percent that still moves at human speed is exactly the part you cannot schedule in advance.

Estimation was painful long before agents. As a manager I found it almost impossible to nail down, and the tug of war between product and engineering never fully resolved. Greenfield work refused to behave like work we had done before. The last eighteen months as a builder taught me why. Even when I think I know where I am, the project keeps surfacing things that were genuinely unpredictable, and spending more time upfront hunting for them did not work either.

Squeezing signal out of the tooling

In May 2026, I ran a small experiment inside Command Center, our internal registry: an Effort Tracker that tried to get every drop of signal out of the tooling we already had. Combine Linear status histories with GitHub attribution, retrieve similar completed tickets, and let an agent estimate new work from what actually happened before.

The first honest result was a warning about the instrument. A parked ticket read as 720 hours of effort. One coder appeared across 80 tickets while the collector could see three commits. The tooling barely saw the work, and forecasting on top of dirty data is theater. We moved collection to the GitHub API, added an aging penalty, and kept the design modest: retrieve comparable work first, let the agent reason over it second. None of that proves the forecasts are accurate. Pairing estimates with actuals is an eval the tracker has never had, and it is the next experiment.

I do not have a tidy conclusion, but I do have an imperfect one: build on what Agile taught us (rituals be damned), have hard conversations about the work upfront, assume constraints (no, not everything is possible), and strive to build in vertical slices. Get end-to-end experiences in front of users as soon as possible, and build on top of that. Feedback trickles in as soon as feasible in its most useful format (actual usage), and each conversation about estimation gets broken down into smaller, more manageable chunks.