The Disappearance of a Skill Nobody Talked About
There was a time when estimating a piece of work required something specific: you had to look at a vague requirement and see its parts. You had to feel the weight of complexity — not just sense it, but feel it in your hands the way a craftsman feels the grain of wood. Senior engineers spent years developing this. It was not just a professional skill. It was a source of professional identity. When you could look at a feature and say "that is three weeks" — and be right — it meant something.
Now you can ask an AI and get a number in four seconds.
The problem is not that the number is wrong. The problem is what you stopped doing to get it.
What Estimation Actually Was
When you estimated a piece of work manually, you were doing several things at once. You were decomposing: breaking the vague into the specific, finding the sub-tasks that lived inside the request. You were calibrating: checking the current task against every task you had done before, looking for the resonance of familiarity. You were sizing: giving each component a weight based on your actual experience of how long similar things took. And you were committing: putting your name on a number and accepting that you would be judged by it.
This process was uncomfortable. That discomfort was the signal that the skill was being exercised. Every estimate you made — and got wrong, and learned from — was building something in your brain: a reference library of complexity, a calibrated sense of effort, an instinct for where things hide.
After five years of doing this, you developed what some engineers call the decomposition reflex — that moment when a vague requirement hits your brain and you immediately see its component parts. The data models. The API surfaces. The error states. The testing surface. You did not have to think about it. It just appeared. And that reflex was the engine of your estimation skill.
The Decomposition Reflex
The instinctive ability to look at a vague requirement and immediately see its component parts. It develops over years of practice. When you stop decomposing manually — when you let AI do it for you — the reflex starts to weaken. Not immediately. Slowly. You might not notice until it is gone.
How AI Breaks the Estimation Muscle
AI coding assistants are extraordinarily good at estimation. You describe a feature, and in seconds you get a breakdown: this part takes two hours, that part takes a day, integration testing adds another half day. The output looks professional. The structure mirrors what a senior engineer would produce. And that is exactly the problem.
When you get an AI estimate, you receive the output without the process. You see the numbers but you do not see the decomposition. You do not feel the weight of each component against your experience. The AI exercised the skill — and you collected the result.
Do this a few times and something subtle begins to happen: you start to lose the felt sense of whether an estimate is right. You can still tell when an estimate is obviously wrong — if someone says a month for something that should take a day, you will catch it. But you lose the fine calibration. The instinct for "this is more like 4 days than 3" becomes harder to access. You have outsourced the muscle memory.
Where your estimation calibration sits right now:
Estimated based on: how often you reach for AI before decomposing, ability to explain your estimates.
Three Signs Your Estimation Skill Is Deteriorating
The Black Box Effect
You can give an estimate — and have it be roughly right — but you cannot explain how you got there. Not in any detail. When a PM asks you to walk through the breakdown, you realize you received the number from AI but never reconstructed the reasoning. The estimate lives in a black box. You know the output. You do not know the process.
The Default-to-AI Threshold Dropped
Six months ago, you would only ask AI for estimates on complex features. Now you find yourself reaching for it on tasks you would have sized instinctively six months ago: small refactors, documentation updates, simple bug fixes. The threshold for "I need AI to estimate this" has dropped to near zero. You cannot trust your own gut anymore.
Estimates Got More Optimistic, Not Less
You would expect AI to make your estimates more accurate. Instead, they have become more optimistic. AI tends to give median-case estimates — it assumes smooth paths, minimal integration complications, no unexpected edge cases. You used to pad for uncertainty based on experience. Now you give AI estimates directly, and the padding has disappeared. Sprints have started consistently overrunning.
The Jira Velocity Inflation Problem
This shows up most clearly in sprint velocity metrics. When teams adopt AI coding tools, reported velocity typically increases. Stories that used to take 5 points now take 3. Velocity charts trend upward. Managers see this and draw reasonable conclusions: the tools are working, the team is more productive.
But the actual work has not changed. A feature that involves a new API integration, three dependent services, and a testing surface does not become 40% faster because you are using AI. It might become faster at generating the code. But the discovery, the error handling, the integration debugging — those still take the same time.
| Before AI Estimation Tools | After AI Estimation Tools |
|---|---|
| Process: Engineer decomposes, sizes from experience, applies uncertainty buffer | Process: Engineer describes to AI, receives breakdown, applies AI number directly |
| Uncertainty buffer: Yes — engineers sized uncertainty based on history of being wrong | Uncertainty buffer: Minimal — AI gives median-case estimates, buffer applied by fewer engineers |
| Velocity trend: Stable — reflects actual capacity with realistic overage | Velocity trend: Artificially inflated — numbers look better, reliability of commitment drops |
| Planning accuracy: High — estimates calibrated against actual delivery history | Planning accuracy: Declining — overrunning sprints despite higher reported velocity |
| Skill state: Decomposition reflex strengthening with each estimate | Skill state: Decomposition reflex weakening with each AI estimate accepted without practice |
The paradox is that the teams with the highest reported velocity may be experiencing the greatest estimation skill loss — and the most invisible planning degradation. The metrics look healthy. The planning conversations get harder. The sprint reviews reveal the gap.
The Senior Engineer Blindspot
This problem hits senior engineers harder than juniors. Here is why: juniors never had a fully developed decomposition reflex to begin with. They use AI to get estimates and they have always used some form of external guidance for sizing. Their skill development path might be different, but they are not experiencing a loss of something they had.
Senior engineers are different. You spent a decade building an instinct for complexity. You could look at a system and feel where it would fight back. You knew — without being able to fully explain why — that certain features would hide complexity that would not show up until you were deep in it. This was not just experience. It was a trained perceptual skill, like a doctor learning to read an X-ray.
Now that skill is quietly eroding every time you accept an AI estimate without going through the decomposition process yourself. You are not just getting a number. You are losing the reflex. And unlike junior engineers who might not notice, you are acutely aware when you cannot explain your own estimate anymore.
The danger is that senior engineers often cannot tell when they are estimating poorly, because the decomposition reflex they relied on for calibration is exactly what is being weakened. You think you are doing fine. The numbers look reasonable. But the fine-grained accuracy — the "this is 3 days, not 2.5" calibration — is disappearing.
The Organizational Cost Nobody Measures
Estimates are commitments. And commitments are the backbone of organizational trust. When a team commits to a delivery date and consistently misses it, the cost is not just in morale — it is in strategic trust. Product managers stop believing planning data. Executives start making decisions based on gut feel rather than forecast. The planning function of the organization degrades.
What makes this especially dangerous is that the cause is nearly invisible. The velocity metrics look healthy. The team is shipping more code. The AI tools are working. Nobody runs a diagnostic check on the decomposition reflex. The skill loss is invisible until it manifests as a pattern of overcommitted sprints, missed deadlines, and PMs who have stopped trusting estimates — and do not quite know why.
In organizations where estimation drives resource allocation — headcount planning, roadmap commitments, capacity modeling — the downstream effects can be significant. A team that is consistently over-optimistic in estimates will appear to have more capacity than it does, leading to under-hiring.
How to Recover Your Estimation Instincts
The recovery is not about rejecting AI. It is about maintaining the practice. The decomposition reflex, like any skill, needs to be exercised to be maintained. You can use AI and still develop the skill — but it requires intention.
The Two-Estimate Protocol
Before asking AI for an estimate on any non-trivial piece of work, do this: First, decompose the problem yourself. Write down the components. Size each one from your own intuition. Write your estimate down. Then ask AI. Compare. You do not have to trust your gut over AI — just check whether your gut still works.
The Calibration Check. Once a week, look back at estimates you made — with or without AI — and compare them to actual delivery. Not for blame. For calibration. Did the work take as long as estimated? Was the AI estimate closer than your gut? This feedback loop is how estimation skill rebuilds itself.
The Decomposition Practice. Every time you encounter a vague requirement, decompose it manually before you do anything else. Do not look at the existing codebase. Do not ask AI. Just try to see the parts. Write them down. Size them. This is the core skill. If you can still do it confidently, your decomposition reflex is intact. If you find yourself stuck, unable to see the components without looking something up, that is data.
The 24-Hour Estimation Challenge
Try This: One Day of Manual Estimation
For one full day, before you ask AI for any estimate, decompose the problem manually first. Write down your components. Size each one from your own intuition. Commit to a number. Then compare it to what AI would have given you. You do not have to follow your gut over AI. Just check whether your gut still works.
The point is not to prove you do not need AI. The point is to know whether you are exercising the skill or outsourcing it entirely. After a week of this practice, you will have clear data: either your decomposition reflex is still working and just needs exercise, or it is deteriorated enough that you need a more deliberate rebuilding process.
Either answer is useful. The worst outcome is the invisible one — not knowing that the skill is eroding until you find yourself unable to produce a reliable estimate at all.
Frequently Asked Questions
Why does AI make estimation harder instead of easier?
Because estimation is a skill — not just an output. Breaking down a complex feature into sub-tasks exercises the same cognitive muscles that make you a good engineer. When AI gives you the answer instantly, you skip the breakdown process. Your brain does not practice the skill. Over time, you lose the instinct for what "hard" actually feels like at the task level.
What is the 'decomposition reflex'?
The decomposition reflex is the instinctive ability to look at a vague requirement and immediately see its component parts — the data models, the API surfaces, the error states, the testing surface. Senior engineers developed this reflex through years of writing estimates. It is the reason senior devs can look at a ticket and know it is 3 days, not 1, without being able to fully explain why. AI bypasses this reflex by giving you an answer without the breakdown.
How does AI affect sprint velocity metrics?
AI inflates reported velocity in ways that mask real problems. When engineers use AI to generate estimates, they tend to give optimistic numbers because AI removes the "padding instinct" that comes from experience. Team velocity charts look healthy. But the actual work required has not changed. The result: velocity goes up, reliability of estimates goes down.
How do you know if your estimation skill is atrophying?
Three signals: First, you cannot explain your estimate anymore — you know it is roughly right but you cannot decompose why. Second, you default to "let me ask AI" for any sizing question, even small ones you used to answer instinctively. Third, your estimates started getting less accurate after you started using AI coding tools — not more accurate.
What is the 24-hour estimation challenge?
For one full day, before you ask AI for any estimate, try to decompose the problem yourself first. Write down the components. Size each one from your own intuition. Then compare. You do not have to trust your gut over AI — just check whether your gut still works. If you cannot decompose a problem without AI after a week of this practice, that is data. The goal is not to reject AI. It is to know whether you are exercising the skill or outsourcing it.