Have you ever asked Claude Code for a time estimate for implementing a feature?
For example, you might be discussing a chatbot feature in your application and ask Claude:
How long will this implementation take?
And then you get a response such as:
For a single engineer, this might be 3-4 weeks of work
I definitely have noticed this basically every time I ask Claude Code for time estimates. Now, in reality, implementing this feature will typically be done within a single day, especially if you set up Claude in the correct way.
This is unfortunate because, in many cases, you want an actual decent estimate for how long it will take to implement the feature, fix the bug, or simply perform the work, and having inaccurate estimates makes that challenging.
Now, when I get vague estimates for these implementations, I often know the answer myself, right? If it’s implementing a feature, almost all features can be implemented within, say, 12 hours if you have a clear spec for what you want to implement. The thing I think is most annoying is when I ask for shorter estimates for example, how many minutes until you’re done with this.
In this article, I’ll discuss why Claude is so bad at these estimates and what you can do to counteract it and align with Claude Code.
Good time estimates are critical for good communication within your company
The reason, of course, better estimates are important to communicate well with your colleagues is that you want to know how long a task will take to complete, for example, to tell your product manager a good estimate or to give your colleague a better understanding of how long it will take for you to complete your work. For example, if their work is based on or dependent on your work, or is blocked until your work is done.
Why Claude is bad at estimating required engineering time
There could be a combination of reasons why Claude is bad at giving estimates for how much time something will take to implement. But I think it all comes down to training data in the end.
Claude is, of course, trained on human data from the internet. This means that, for example, humans have written blog posts about how long an implementation took, or it might be based on GitHub statistics when humans were the only ones writing all the code without the assistance of AI, obviously before 2022, and so on.
Thus, Claude has essentially been trained on human estimates of time. So in the training data that Claude and other similar LLMs are trained on, there are human time estimates. So implementing a feature for a human would in reality take, for example, 4 weeks to implement.
Or discovering the root cause of a bug and implementing a fix might take 2 days to resolve.
Thus, the main reason the estimates are poor is essentially that it’s giving human estimates and not estimates for what an LLM would use to complete the task. However, I think it’s worth noting that now that LLMs have been available for quite a few years, I think we’ll see these estimates start to get updated more naturally, once we have more data on the internet on how long something takes to implement through programming with LLMs, and we’ll see that the estimates become more and more accurate, though they probably will be lagging for quite a bit longer.
How to get more accurate estimates
Now, let’s move on to how to fix the problem of poor estimates. There’s no clear quick fix for how to get better estimates from Claude Code or your other coding agents. However, I would like to point out two main approaches that I would use if I do want a more accurate estimate of how long something takes to implement.
Base estimations on your previous data
I think the most impactful technique you can use is to make your coding agent store data on how long something takes to implement. This can, for example, be done by having each task tracked in a Linear issue or in a markdown file on Notion or similar.
Then, when the LLM implements the feature or fixes the bug, it of course makes sure to write everything down in Linear and track everything there. Importantly, note down when you started looking at it and when it was completed.
Once you’ve completed quite a lot of feature implementations and bug fixes, you can make a separate skill that Claude Code uses every time it wants to make estimates that has all information about these different features. The skill could look something like:
Whenever an LLM has to make a new estimate on how long a task takes to complete, it can refer to this skill, compare the current task against previous tasks and thus make a lot better estimates.
Now, of course, the estimates will still not be 100% accurate. This is because we can’t have perfect information about what the task is and how it can be solved. For example, when implementing feature A, it’s very hard to map out all the challenges you might face along the way. Figure out what’s gonna be hard, what’s not gonna be hard. Maybe there’s other work being done at the same time, so you have to rebase on top of it, and so on. Essentially, you don’t have perfect information, and thus it’s impossible to make perfect estimates. However, I’ve found that having a skill such as the one mentioned above here is a very effective way of getting better estimates and thus being more able to communicate with my colleagues.
Tell Claude to think specifically through each step, and how long an LLM would spend on it
Now, I think the above technique is probably the superior technique to make time estimates. However, I do also want to note down a method which isn’t dependent on a lot of data because the above method obviously depends on you having implemented a lot of features and resolved bugs and other tasks, and then having noted down how long each of them took. This technique that I’m covering here doesn’t require that.
This technique is more about splitting up each step where it’s easier for the LLMs to make estimates on it, and you should explicitly tell the LLM to make the estimate based on how long an LLM would spend on it, not how long a human would spend on it.
For example, let’s say you’re implementing feature A, and feature A depends on implementing several subtasks:
-
Researching the topic
-
Implementing part 1
-
Implementing part 2
-
Testing
Now, the tasks that you’ve covered should probably be even more specific than what I listed above. The reason for this is that estimating the time for smaller tasks is way easier, both for a human and for an LLM. And this, in turn, nets you better estimates in total.
You can tell the LLM to find a good estimate for each of the sub-tasks given that an LLM is performing the task or at least it’s a human driving it but using LLMs to complete it. The LLM will have some inherent knowledge of how effective it is itself. For example, researching topics will be way more effective when using LLMs compared to humans doing the research manually by googling.
Then you tell the LLM to combine the time estimates, and in turn you have an estimate for the total completion time of the task.
Conclusion
In this article, I discussed how to make your coding agents provide better time estimates for when they are completing tasks. This is very important because, in a lot of cases, you want to communicate with your team how long it takes to complete a task end to end. However, if you ask an LLM out of the box, most of them will be very poor at giving estimates and will provide far higher time estimates than what’s actually true. Thus, you can apply the two techniques that I covered in this article to have way better time estimates from coding with your LLMs and thus be a better communicator within your team. I think this topic is, in general, very important, as LLMs change the way we work, and being able to communicate and align humans with LLMs is gonna be a critical skill in the future.
👉 My free eBook and Webinar:
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free Vision Language Models ebook
💻 My webinar on Vision Language Models
👉 Find me on socials:
💌 Substack