Estimating with AI: useful, with two guardrails
AI breakdowns are good at structure and bad at your team's velocity. Use it for the outline and calibrate with history.
An AI model given "add SSO to the admin panel" will produce a clean list of eight subtasks with hour estimates. The structure is usually good. The numbers are usually wrong. Both facts are useful if you know which is which.
What language models are genuinely good at here
Decomposition is a pattern-matching problem, and the patterns are all over the training data. Ask for a breakdown of a login flow, a Stripe integration, a data migration or a landing page and you get the standard steps, including the two or three everybody forgets: the migration rollback, the audit log entry, the empty state. That checklist effect is where the value is.
They are also good at surfacing questions. "Does this need to support SCIM provisioning?" is a better output than an estimate, because it changes the estimate by a factor of three.
Why the hours are wrong
An estimate is a statement about your codebase, your review process and your deploy pipeline. The model knows none of that. It produces something close to the internet's median for a task of that description, which is roughly a competent developer in a clean codebase with no code review and no compliance requirements. Your reality has a multiplier, and it is stable enough to measure.
Guardrail one: calibrate against your own history
Take your last thirty completed tasks with both an estimate and tracked actual time. Compute the ratio of actual to estimated. Most teams land between 1.3 and 2.1 — and the number is remarkably consistent per team. Apply it to every AI estimate before it becomes a commitment. A tool that tracks time natively gives you this ratio for free; without it you are guessing about your guessing.
Guardrail two: never let AI estimates become the plan unreviewed
Treat the output as a draft written by a fast, well-read junior who has never seen your code. A five-minute review by the person doing the work catches the "this touches the billing service" problem that changes everything. The workflow that works: AI proposes, human edits, then commit. The workflow that fails: AI proposes, PM copies into the plan, engineer discovers reality in week two.
Where it pays off most
Repeatable work with genuine variation — client onboarding, content production, launch checklists, migration projects. The shape is the same every time, the specifics differ, and a decomposition that is 80% right saves the hour you would spend retyping the same list.
What we do in the product
Decomposition returns subtasks with estimates and points, then multiplies by your workspace's historical estimate-to-actual ratio once you have enough completed tasks to compute one. Risk prediction uses the same history: overdue dependencies, estimate overrun, days since last activity and assignee load. It is deliberately explainable, because an unexplained risk score gets ignored.
Boards, Gantt, timesheets, invoicing, client portals and AI in one workspace — every feature on every plan. Free for 10 members, $4/user/month after that.