Over the past year, I’ve been thinking more seriously about a quiet shift happening in software development—one that doesn’t get discussed as much as productivity gains or “AI replacing developers.”
It’s about effort.
Most of our tools for estimating software work—whether it’s COCOMO, Function Points, or even Story Points in agile teams—are built on a simple assumption: that effort is primarily human. We approximate it using proxies like code size, complexity, or how difficult something feels to build.
That assumption used to hold reasonably well.
But with LLMs now handling a large portion of coding, refactoring, and even reasoning tasks, the relationship between “work” and “effort” feels increasingly unstable.
Where traditional estimation starts to break
One pattern that keeps showing up is how inconsistent effort has become.
Tasks that would traditionally be labeled “complex”—like implementing a known algorithm or standard module—are often completed quickly with LLM assistance. The model already “knows” these patterns, so the interaction is short and predictable.
On the other hand, relatively small tasks can take much longer than expected. Not because they’re hard to code, but because they require careful validation, integration with existing systems, or repeated iterations to get the behavior right.
In other words, effort is no longer tied closely to how much code you write.
It’s tied to something else.
A shift from construction to supervision
What seems to be happening is a redistribution of effort.
Instead of spending most of the time writing code, developers are spending more time:
clarifying requirements
guiding the model through prompts
reviewing outputs
testing and validating behavior
fixing subtle issues that only appear during integration
The work hasn’t disappeared—it’s just moved.
And importantly, this kind of effort doesn’t scale in the same way as writing code. A small change can trigger a disproportionate amount of validation work, especially in larger or less well-documented systems.
Thinking in terms of “hybrid effort”
One way to make sense of this is to stop thinking of effort as purely human.
Instead, it might be more accurate to think in terms of hybrid effort—a combination of:
what the model can handle easily
and what still requires human oversight
From that perspective, a few factors seem to matter more than traditional complexity:
How well the task aligns with patterns the model already understands
Familiar problems tend to be solved quickly.How complete and clear the context is
Missing or ambiguous information leads to more back-and-forth.How far changes propagate through the system
Small edits can have large downstream effects.How many iterations it takes to get to a correct result
Some tasks require multiple cycles of prompting and correction.How much validation is needed before the result can be trusted
This often ends up being the dominant cost.
These don’t map cleanly to story points or lines of code, which is probably why those estimates feel less reliable in LLM-assisted workflows.
Why this matters (even if you’re not estimating formally)
Even outside of formal estimation, this shift has practical implications.
It changes how we think about:
planning work in sprints
comparing task difficulty
evaluating productivity
and even designing systems (since tightly coupled systems increase validation effort)
It also explains why two tasks that look similar on the surface can feel completely different in practice.
Still early, but directionally clear
This isn’t a fully solved problem, and it’s probably too early to replace existing estimation methods outright.
But the direction seems clear:
effort is becoming less about building things, and more about making sure what’s built is actually correct.
That’s a different kind of work—and it likely needs a different way of thinking about estimation.
