How to Use AI to Estimate a Software Task Accurately
Estimation is one of the hardest things engineers do — and one of the most consequential when it goes wrong. If you've ever watched a "two-day task" stretch into two weeks, you know the damage a bad estimate causes: broken trust, missed releases, and replanning chaos. Here's a concrete case study showing how I used AI to produce a structured, defensible estimate — with the actual prompt and the outcome in numbers.
The Problem: A Vague Ticket with a Hard Deadline
On a recent project, I was handed a ticket to integrate a third-party identity provider into an existing auth service. The ticket had three sentences of context and a deadline in eight days. My gut said "four or five days." My gut has been wrong before.
Instead of committing immediately, I ran an AI-assisted estimation session.
Step 1 — Dump Everything You Know Into the Prompt
I gave the AI the full context I had: the ticket description, the tech stack, the integration type (OAuth 2.0 PKCE flow), the existing auth service structure (rough outline), and any known constraints (no breaking changes to existing sessions, SOC 2 audit upcoming).
The prompt I used:
You are a senior software engineer. I need to estimate a task with high accuracy.
Task: Integrate [third-party IdP] into our existing auth service using OAuth 2.0 PKCE flow.
Stack: Node.js, Express, PostgreSQL, Redis for session storage.
Constraints: No disruption to existing session handling. SOC 2 audit in 3 weeks.
Team: Just me on implementation. One reviewer available.
Break this task into concrete subtasks. For each subtask, give a realistic time range (optimistic / likely / pessimistic) and flag any hidden risks or unknowns that would blow the estimate.
Step 2 — Review the Breakdown, Then Challenge It
The AI returned 11 subtasks I hadn't fully enumerated — including things like "update token refresh logic for dual-provider support," "write migration for existing user identity records," and "add test coverage for the PKCE state parameter validation." Three of those I hadn't thought about at all.
I then asked a follow-up:
Which of these subtasks is most likely to contain unknown unknowns that
would cause the estimate to slip by more than a day? Explain why.
The response flagged the identity migration as the riskiest — existing user records had no provider field, meaning a schema migration and a backfill were implicit in the work. That would have blindsided me on day six.
The Outcome in Numbers
| Before AI Estimation | After AI Estimation | |
|---|---|---|
| Initial gut estimate | 4–5 days | — |
| Structured estimate | — | 7.5 days (likely) |
| Actual time taken | — | 7 days |
| Risk items caught upfront | 0 | 3 |
The structured estimate was accurate to within half a day. More importantly, flagging the migration risk early meant I raised it in the kickoff call and got a DBA involved on day one instead of day six.
The Repeatable Workflow
- Write out everything you know — ticket, stack, constraints, team size.
- Ask for subtask decomposition with time ranges (optimistic / likely / pessimistic per subtask).
- Explicitly ask what could blow the estimate — AI is good at surfacing second-order work.
- Sum the "likely" column, add 15–20% buffer for integration and review overhead.
- Commit to the number with the risk list attached — now your estimate is a document, not a guess.
This takes about 15 minutes. It replaced a process that used to take 45 minutes of solo thinking and still produced worse results.
I break down one workflow like this every week in The AI Leverage Weekly — practical, no fluff, free. Subscribe: https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=medium_w17
Top comments (0)