There is a meeting I have been in a hundred times and I still have not learned to survive it. Someone shares a screen, points at a card, and asks the oldest question in our industry. How long will this take?
For most of my career I had a method for that question. Not scientific, but mine. I would picture the work, count the pieces, remember the last time I built something similar, add a margin for the things I could not see, and say a number. Two decades of scars go into a number like that. It was wrong often, but it was wrong in a familiar way, and familiar wrong is something a team can plan around.
Then the typing became free, and I noticed something uncomfortable. My method was mostly counting typing.
What I was actually measuring
Story points, t-shirt sizes, ideal days, whatever ceremony the company preferred. Underneath all of it, I was estimating the same thing. How many hours would a person with fingers on a keyboard need to turn this idea into code.
That worked because for thirty years the typing was the expensive part and everything else scaled with it. A big feature meant a lot of code, which meant a lot of reading, a lot of tests, a lot of review. One number could stand in for the whole thing.
Then I gave a ticket to an agent and had a working implementation before my coffee got cold. And the ticket still took three days.
I have written this sentence before, in the very first note on this blog, when I said that code review is not about ego, it is about money. The typing was never the estimate. It was only the part that was easy to see.
Amdahl came for my sprint
There is a very old idea that explains my whole problem, and like most old ideas it was written down before I was born. In 1967, Gene Amdahl made a simple argument. If you speed up one part of a system, your total gain is capped by the part you did not speed up. Make something twice as fast and you may get almost nothing, if that something was only a quarter of the work.
We spent decades teaching that to each other about processors. Nobody told me it would show up in a planning meeting.
I made the coding part of a ticket ten times faster. The ticket did not get ten times faster. It barely moved, because coding was never most of the ticket. And the parts that did not move are exactly the parts nobody puts on a card.
So what is left
When I look honestly at where the days go now, it is always the same list.
Decisions nobody has made yet. Half of every estimate I have ever given was really a bet on how long it would take three people to agree on something.
Questions about the system we already have. The old table with a rule that only lives in someone’s memory. The integration that behaves differently on the second Tuesday of the month.
Verification. Not the tests the agent wrote, which it wrote in a minute. The part where a human decides this is safe to put in front of customers.
Blast radius. What happens if we are wrong, who finds out, and how fast can we undo it.
None of that got cheaper this year. Some of it got more expensive, because there is more code arriving per hour and each piece of it needs the same human attention it always did. That is the comprehension debt I was complaining about in my last note, showing up on the calendar instead of in the incident channel.
So I changed the question I ask myself. I stopped asking how big this is and started asking how many decisions are still open. If the answer is more than two, whatever number I say next is a work of fiction, and an expensive one, because somebody downstream is going to believe me.
Estimates got bimodal
Here is the strangest thing I have noticed, and I would like to know if other people see it too.
My estimates used to spread out nicely. Half a day, two days, a week, three weeks. Now almost everything I look at is either under an hour or over two weeks, and the middle is disappearing.
If the boundaries are clear, the spec is real, and the pattern already exists somewhere in the repository, the thing is done before lunch. If any one of those three is missing, it is not a ticket. It is a discovery project wearing a ticket’s costume, and it will take as long as discovery takes, which nobody can estimate, which is exactly why we call it discovery.
The useful skill now is not estimating. It is telling which of the two you are holding before you promise a date. And you can usually tell in fifteen minutes of honest questions, which is a much better use of a planning meeting than arguing about whether something is a five or an eight.
The number the business actually buys
This is the part I care about most, because it is the part that is not about engineering at all.
The business does not buy code. It buys a date it can plan around. Marketing books a campaign against it. Support writes the help article. Someone in sales says the word “September” to a customer who wrote it down. The date is a promise that other people spend money on.
Which means the honest measure of an estimate was never accuracy. It was reliability. A team that says four weeks and delivers in four weeks is worth more than a team that says one week and delivers in three, even though the second team is objectively faster.
I bring this up because I keep hearing engineers report enormous speedups in meetings, and the research this year is nowhere near that confident. The 2026 developer surveys land all over the map depending on who was measured and what they were building, and the gap between how fast people feel and how fast they are is now a documented phenomenon rather than a suspicion. If I promise a five times speedup and miss the date, I did not gain anything. I traded a reliable partner for a good story, and in my experience the business remembers the missed date much longer than it remembers the story.
I was the guy who said two days
Let me be specific about my own failure, since I am handing out opinions here. I have lived some version of this story at more than one company, which is the only reason I am comfortable telling it.
The ticket looked like plumbing. Move some data from one place to another, expose it, done. I said two days out loud, in front of people, with confidence, because the coding part was obvious and the coding part was what I was picturing.
The agent had a working version quickly. Then the old table turned out to have a rule nobody had written down anywhere. Then product looked at it and changed their mind about one edge case, which was fair, because seeing it working made the problem clearer. Then the deploy needed coordination with another team that had their own week.
Six days. And here is the part that still bothers me. Not one of those four extra days had anything to do with writing code. My estimate was excellent at the only thing that stopped mattering.
I did not get worse at estimating. I just kept measuring the one thing that stopped being expensive.
Cavallini, Thiago
What I do now
Nothing revolutionary, and I am still figuring it out, so take this as notes rather than method.
I estimate the ambiguity instead of the build. When someone asks how long, my first answer is usually a question about what we have not decided yet.
When too much is open, I give a date for the decisions and not for the feature. “I can tell you Thursday” is a real commitment and an honest one, and no product person has ever been upset with me for saying it.
I write the spec before I write the prompt, which I already believed before the agents made it unavoidable. A spec is not bureaucracy now. It is the difference between the one hour version and the two week version.
I put review and understanding into the estimate as a real line, with a real number, and I defend that line. It used to hide inside the coding number. Now it has nowhere to hide, so it needs its own seat at the table.
And I still add margin, for the same reason I always did. Something will surprise me. It always does. Steve McConnell called this the cone of uncertainty twenty years ago, and the cone did not get narrower this year. Only one slice of it did.
The gray hairs will appreciate the ending. After all this time, all these tools, all this acceleration, I am still standing in a meeting giving numbers I am not sure about, to people who will remember them. The good news, and I mean this, is that I am wrong much faster now. Being wrong on Tuesday instead of on the following Thursday is a real improvement. It just looks terrible on a roadmap .
Pax et bonum.