I’ve been writing software for fourteen years. For most of that time, the question “how long will this take?” had a reasonable answer. It might be wrong, but at least it pointed at something real: the time it took me to think it through, type it out, find the bugs, ship it. The estimate was a bet on my own speed. And most of our process (sprint planning, story points, agreeing on a number) was built on the idea that I was the variable.
I don’t think that’s true anymore.
When AI Made Typing the Easy Part
A month ago I built an AI Chat bot that, by my old instincts, should have taken three months. I had it running on my machine in three days and demo-ready in two weeks. Most of that time wasn’t typing. It was coordinating three parallel Claude terminals, reviewing what came back, deciding which version to keep, putting the pieces together, and making sure the whole thing didn’t fall apart the first time someone clicked the wrong button.
The actual code production was a flash in the middle. The backend was in Python, a language I’d never written in production before. I picked it up as we went. Which raises a fair question for anyone reading this: how do you estimate a project when you don’t yet know the language you’ll write it in? Would you have even considered switching languages mid-project a few years ago, just because someone said it was the better call?
That experience left me with a question I can’t put down: what am I even estimating anymore?
If a feature ships in two weeks that used to take three months, what is the estimate a measure of? My effort? My speed? The AI’s? How fast the model is responding today? Whether the Anthropic servers are up on Friday? The number is a fiction we agree on so calendars stay full. But it’s pointing at something that doesn’t exist in the same shape it used to. The variable I’m being asked to estimate isn’t the variable that decides the outcome.
It’s Not Agile. The Job Changed Shape.
This isn’t a complaint about Agile or about process. I’m not allergic to standups, status updates, or planning meetings. I’ve sat through enough of them to know which ones earned their hour and which ones didn’t. What I’m noticing is more structural than that. Most of the process we run was designed for a job that no longer exists in the same shape.
The old job was: take a problem, hold it in your head, write the code, get it reviewed, ship it. Typing was the bottleneck. Process existed to make that bottleneck visible to other people. Managers, stakeholders, anyone who needed to know roughly when the problem-solving and the typing would be done.
The new job is more judgment than before. Is what the AI produced actually good, or just plausible? Does it fit the codebase? Where are the bugs hiding? The ratio between planning and execution has flipped, from something like 20/80 to 60/40 (my fake stats, based on pure feeling).
That’s a different shape of work. The process built for the old shape doesn’t measure it.
The “Does It Have a Reader?” Test
Here’s the test I’ve started applying to every artifact a process asks me to produce: does it have a reader, and do they read it? Some pass easily.
- The PR description gets read.
- The standup update gets heard.
- The demo gets watched.
- The planning doc I wrote by hand before any code is the one I want to spend more time on.
I was always the kind of engineer who spent more time on planning than most, and got that time back in execution. Going into a problem with a clear design has reliably made the build faster and cleaner for me. Planning was never waste. And it has gotten more valuable in the AI era, not less. A clear pitch is now a clear prompt. The same document that helped me design the thing can be handed to an agent as the brief, dropped in as an AGENTS.md, or used as the system instruction that drives the build. Good planning has gained a new, demanding reader.
Where the test gets uncomfortable is the secondary artifacts.
- The summary that mirrors the plan in a different layout.
- The per-task ticket that re-states it in a smaller box.
- The templated status report that translates progress into a different shape for a different audience.
- The process of moving things in a Kanban list religiously.
If writing them cost me a real morning, I either thought carefully or pushed back on producing them. Now AI generates each one in two minutes. They come back technically complete, formally adequate, and empty inside. The thinking didn’t happen because it didn’t need to. The artifact exists. The reader still doesn’t.
We’re Drowning in Cheap Artifacts
I think this is the part of the AI shift that’s quietly making everyone miserable, and not just in software. The cost of producing the wrapper around work has collapsed faster than the cost of doing the work, and much faster than the cost of reading the wrapper. We’re drowning in cheap artifacts. The bottleneck used to be making the report. Now it’s reading the report. Nobody has caught up to that yet.
Which means the answer isn’t “more documentation” or “less documentation.” It’s fewer artifacts, each with a real reader. If a document doesn’t have a person who opens it and uses it to decide something, the document shouldn’t exist. If a status update doesn’t change anyone’s plan, the status update is theater. If a number is being collected but no report ever runs against it, the collection is a tax.
To anyone feeling this kind of friction in their own work: it’s not nostalgia, and it’s not laziness. The job changed. The fact that the calendar didn’t change with it isn’t your fault. You’re being asked to produce evidence of work in formats designed for a kind of work you’re no longer mostly doing.
Your Backlog Has a Shorter Shelf Life
Speed doesn’t just compress one project. It also compresses the space between projects. In the old rhythm, you could finish a feature, get it reviewed, hold the feature in the backlog for a marketing moment two or three months out, and the project around it would still be there when you came back. The codebase moved slowly. The strategy moved slowly. A finished PR aged well.
Not anymore. In three weeks the whole project can shift. A new direction, a new priority, an architectural choice the team made while you were waiting. Your finished, reviewed, ready-to-merge PR is now talking about a version of the product that no longer exists. Congrats, you did the work twice. Once for real, and once again because the world moved while you weren’t looking.
This is another estimate that broke quietly. Nobody used to ask “how long can this PR sit before it becomes garbage?” Sit on something for a month and you risk merging a fix for a problem the team already solved a different way. Sit on it for three months and you’re sometimes better off throwing the branch away and starting from the new mainline.
What I Actually Want From Process Now
I don’t think the answer is to burn it all down. I worked too long in this industry to think process is the enemy. The standups and the planning docs and the estimates exist for reasons I understand and mostly respect. But the conditions those reasons were built on have shifted, and the gap between “what the process measures” and “what the work actually is” is now wide enough that it’s costing more than it returns.
What I want?
- An honest acknowledgment that the job has changed.
- That my estimate is no longer an estimate of me.
- That a document with no reader isn’t documentation, it’s homework.
- That the new bottleneck isn’t engineers being slow. It’s everything around engineering not catching up to how fast we now move.
Until then, I’ll keep doing my work, asking what I’m actually estimating, and quietly noticing which artifacts have readers.
I’ll leave you with one question. What were the authors of the Agile Manifesto really getting at when they wrote this?
Working software is the primary measure of progress.
Because I’m not a designer nor a native English speaker, I’ve used AI to generate the images in it and for grammar spelling. Props to Claude!
Leave a Reply