Abi Abiassi
RESEARCH NOTE /
The code got faster. The uncertainty stayed.
What software estimates are measuring when implementation gets cheap.
A ticket sat in progress for 30 days. The tracker reported roughly 720 hours of effort.
That did not mean 720 hours had been worked. The formula was NOW - startedAt. It knew the ticket had aged. It did not know what happened inside the month. The number arrived looking very certain anyway.
That was the useful failure.
In May 2026, we built an Effort Tracker inside Command Center, our internal registry and access-control system. The idea was simple: give an agent enough history to retrieve similar completed tickets and estimate new work from what had actually happened before.
The proof of concept combined Linear status histories with GitHub attribution. The queryable record was the main product. A dashboard was mostly there so humans could see what the agent was looking at.
The paper trail is short and dated. The proof of concept was scoped on 15 May and completed on 16 May. A second version followed on 17 and 18 May, aimed at making the data useful for forecasting and, eventually, pricing. A similar-ticket retrieval primitive was completed on 18 May. Code would retrieve the relevant history. The agent would make the estimate. No bespoke forecasting model pretending to know more than the source data.
The first honest result was not an estimate. It was a warning about the instrument.
One parked ticket produced about 720 hours because its status had not changed for a month. A 744-hour ceiling made the output look bounded, while hiding the fact that two of four coders had already hit it. Elsewhere, one coder appeared across 80 tickets while the collector could see only three commits. The tickets were in Linear. The collector was reading local git.
The v2 brief put it plainly: forecasting on top of dirty data is theater.
We moved collection to the GitHub API, added an aging penalty, and kept the architecture deliberately modest. Retrieve comparable work first. Let the agent reason over it second. Those changes made the measurement less misleading. They did not prove that the resulting forecasts were accurate.
This distinction matters because my working thesis is about a different proxy breaking.
What the estimate was standing in for
A duration estimate has never been interesting because five days is a particularly beautiful number. It is useful because it compresses several unknowns into something a team can plan around. How well do we understand the problem? How much implementation is hiding inside it? What will integration uncover? How long until somebody outside the ticket tells us we were wrong?
When implementation was a large and expensive part of delivery, effort and uncertainty could move together closely enough for duration to stand in for both.
AI may be separating them.
A first implementation can now appear early. Product uncertainty, validation, integration, coordination, review, and operational risk may not move at the same speed. If they do not, the estimate keeps describing the part that shrank while the larger risk sits elsewhere, looking uninvited.
Generated output is evidence. It is not yet a verdict.
A patch can narrow technical uncertainty. Review can uncover a bad assumption. Integration can find the dependency nobody mentioned. Production can reveal that the technically correct thing was the wrong thing to build. Calling all of those states "progress" makes the chart calmer than the work.
Duration needs company
I do not think duration disappears. I think it needs company.
For each piece of work, I want to know which uncertainty it is buying down, what real event would resolve that uncertainty, how long that verdict is likely to take, how confident we are, and how expensive it would be to reverse the decision. The estimate should update as implementation evidence arrives. A generated patch, a reviewed patch, an integrated change, and an observed outcome are different signals. The planning record should admit that.
This is still a proposal, not a result from the Effort Tracker.
We do not have a pre-registered hypothesis. The dated v2 goal is the closest record of intent, but it is not the same thing. We have not located the actual Effort field's scale, how consistently it was used, who estimated, when estimates were entered, or which progress signals were available at the time.
We also do not have before-and-after estimate-versus-actual pairs. There is no stage-level evidence showing whether AI compressed implementation while validation or integration stayed slow. No downstream planning or pricing decision is documented as having changed because of the experiment.
The instrument has limits of its own. Non-commit work is invisible. Status history is reduced to a single span. Monorepo attribution is ambiguous. Side projects were outside the scope. The initial snapshot covered four coders, and we do not yet know how ticket mix, team seniority, specification quality, or the observation itself affected the result.
Any of those facts could make the thesis smaller.
If agents also compress validation and integration, uneven compression may be the wrong model. If estimate accuracy holds or improves, the broken-proxy claim weakens. If this richer planning record changes no decision, it is just a nicer collection of fields.
So the next step is boring, which is usually promising. Retrieve the real Effort history. Pair estimates with actuals. Separate generated output from reviewed, integrated, and operational progress. Then see whether the thesis survives, including any result that ruins the title.