Gantt planning for AI-assisted development

Gantt planning for AI-assisted development is worth doing when your work has real dates or real ordering: an external deadline, a dependency chain where one task must finish before another can start, or a milestone other people plan around. It misleads when you use it to predict how long an agent will take on a task, because agent implementation time is erratic and is rarely the slow part. The timeline should show commitments and order, not guesses about typing speed. This article explains when a timeline earns its place, the specific ways it lies on agent projects, how to handle undated work and dependency cycles, and a short workflow for keeping dates honest. If your plan is mostly a graph of what blocks what, read dependency graphs for agent tasks first; a Gantt chart is that graph laid against a calendar.

When a timeline helps

A timeline is useful when time itself is a constraint. Three situations qualify. First, external deadlines: a conference demo, a client handover, an app store review window. These dates do not move because an agent was fast or slow. Second, dependency chains with lead time: a database migration that must run before the API change, which must ship before the mobile client update. Seeing the chain against a calendar shows whether the end date is plausible. Third, coordination with people: a reviewer who is away next week, a designer who delivers assets on a fixed day.

In each case the chart answers a question you actually have: can this chain finish before that date, and what has to start first? If no question like that exists, a list sorted by priority and dependency order is clearer and cheaper to maintain. A Gantt chart with fifty bars and no deadline is decoration. Keep the dated part of the plan small enough that you will update it when reality changes.

How a Gantt chart misleads on agent projects

The classic Gantt bar assumes duration is roughly predictable from effort. Agent work breaks that assumption in two directions. An agent can produce a working first version of a task in minutes that a person would schedule for two days. The same agent can loop on a failing test for an hour on a task that looked trivial. Bars sized by expected implementation time are therefore mostly fiction.

The second distortion is that the bar ends when implementation ends. On agent projects the long pole is usually review, checks and acceptance, which sit after the bar. A chart full of finished bars can describe a project where nothing has been accepted. See tracking built versus accepted for that gap.

A practical correction: size bars by review and verification time, not coding time, and add an explicit review task before any dated milestone. Treat the dates on implementation tasks as targets for when work should be ready to check, not forecasts of when it will be done.

Undated work and dependency cycles

Not every task deserves a date. Exploration, cleanup and nice-to-have improvements usually have none, and inventing one creates false precision that people later treat as a promise. Keep those tasks undated and visible in a separate list. A planning tool should let undated work exist without forcing it onto the calendar.

Dependencies need one hard rule: no cycles. If task A depends on B and B depends on A, neither can ever start, and any schedule built on them is meaningless. Cycles creep in on agent projects because tasks get split and relinked often, for example when an agent discovers that a refactor needs a helper that the refactor itself was meant to produce. The fix is to break the cycle by splitting one task: extract the helper into its own task with no dependency on the refactor. A good tool refuses a cycle when you try to save it rather than drawing it. The article on dependency cycles covers detection and repair in more depth.

A workflow for honest dates

Step 1: List the fixed dates. Write down every external deadline and the milestone that must be accepted by each one.

Step 2: Work backward through dependencies. For each milestone, list the tasks that must be accepted first and their dependency order. Only these tasks get dates.

Step 3: Put review on the chart. Add review and acceptance time explicitly, sized by how long a careful check really takes you.

Step 4: Leave the rest undated. Everything not on a dated chain stays in the backlog, ordered by priority.

Step 5: Re-plan weekly. Compare the chart with accepted work, not with closed tasks. If a chain has slipped, move dates or cut scope, and record which. Do not stretch bars silently.

Step 6: Watch the critical chain. The tasks with no slack before a deadline are the only ones whose delay matters this week. Give them first claim on your review time.

QUESTIONS

Is a Gantt chart useful for a solo AI coding project?

Only if you have fixed dates or a dependency chain long enough that ordering is not obvious. A solo project with no external deadline is usually better served by a prioritized list. Add a timeline when a date appears that you cannot move, then date only the chain leading to it.

How do I estimate task duration when an agent does the coding?

Estimate review and verification time instead of coding time. Implementation by an agent varies too much to forecast, while the time you need to read a diff, run checks and decide is steadier. Add a buffer for one rework cycle on anything that touches shared code.

Why should a planning tool refuse dependency cycles?

A cycle means two or more tasks each wait for the other, so none can ever start. A schedule drawn on top of a cycle looks complete but cannot be executed. Refusing the cycle at save time forces you to split a task and makes the real order explicit.

RELATED GUIDES

• Gantt planning in BRAIN FLUID: the integrated view and its prototype
• How to read project progress in BRAIN FLUID Build

RELATED HARNESS PAGES

• Task dependency graphs for AI agents Task dependency graphs for AI agents: declare prerequisites, let selection skip blocked work and keep dependencies in the context each agent gets.
• Dependency cycles in AI project plans Dependency cycles in AI project plans: how agent plans create loops, why they deadlock task selection and how a planner should refuse them.
• Milestones for AI-assisted projects Milestones for AI-assisted projects: define them by accepted outcomes and passing checks, not by cards closed, and keep release a separate decision.
• Tracking AI agent progress: built vs accepted Tracking AI agent progress: built vs accepted. Keep implementation, current evidence and acceptance as separate numbers and read them weekly.