Keeping long-running AI coding projects on track

Keeping long-running AI coding projects on track depends on four habits that short projects can skip: a written goal you reread, re-planning on a fixed schedule, regular checks for drift between the plan and the code, and backups you have actually restored. Over a weekend, an agent and a developer can hold the whole project in their heads. Over six weeks, decisions get forgotten, the plan describes code that no longer exists, and finished work quietly piles up unreviewed. None of this is caused by the agent alone; it is what happens to any project when output is fast and memory is short. This article sets out a routine for weeks-long work and uses BRAIN FLUID's own development board as a worked example. For moving work between sessions, see session handoff; this article is about the project as a whole.

Write the goal down and reread it

Long projects drift because each session optimizes for the task in front of it. An agent asked to fix a flaky test will fix it; it will not ask whether the module should exist at all. Over weeks, those local decisions add up to a project heading somewhere nobody chose.

Write a one-paragraph goal at the start: who the project is for, what must be true when it is finished, and what is explicitly out of scope. Keep it where every session can see it, in the repository or the project record, not in a chat thread. Then reread it at every weekly re-plan and ask whether the work in progress still serves it.

Record the decisions that shape the goal, too: why you chose a particular database, why a feature was cut. An agent that later proposes reversing a decision should be able to find the reason it was made. Recording architecture decisions covers a lightweight format.

Re-plan on a schedule and watch for drift

Re-plan weekly whether or not anything went wrong. A fixed slot catches drift while it is small. In the session, compare three things: the plan, the board, and the code.

Plan versus board: are the tasks you are working on the ones the plan says matter? Work added mid-week, especially follow-ups suggested by agents, tends to crowd out planned work.

Board versus code: does each closed task still describe the code? A task closed in week two may have been undone by a refactor in week four. Check that the checks behind closed work still pass on current code; results that predate later changes to the same files are stale.

Code versus plan: is there code that no task describes? Agents sometimes add helpers, configuration or dependencies along the way. Unplanned code is not always wrong, but it should be noticed and either recorded or removed.

End the session by updating the plan in writing, including what you dropped. A plan that only grows is not being re-planned.

A worked example: the product's own board

BRAIN FLUID itself was built over many weeks with agents, and its board shows what a long project looks like up close. On October 30, 2026, the development workspace had 123 cards: 50 DONE, 39 VERIFY, 20 TODO, 8 IN-PROGRESS, 2 DECISION-OWED, 2 BACKLOG, 1 WONT-DO and 1 ON-HOLD. A separate acceptance checklist had 139 items, 70 passed and 69 pending.

Two lessons stand out. First, 39 cards in VERIFY is a review backlog roughly as large as everything marked DONE. On a long project, that pile grows unless review is scheduled as deliberately as implementation. Second, the board and the checklist are different populations. Neither is a single progress number, and DONE could mean implementation closed at the owner's direction before manual acceptance. Long projects need both views, read separately.

The practical response was the routine in this article: a weekly look at VERIFY oldest first, explicit decision and hold states instead of leaving cards in limbo, and progress read as built versus accepted. See tracking agent progress for that last part.

Backups, bindings and recovery

A project that runs for weeks will eventually hit a bad day: a corrupted working copy, an agent that rewrote the wrong directory, a laptop that will not boot. Version control protects the code, but not always the project record around it: task history, decisions, review notes and evidence.

Back up both, on a schedule, and test a restore at least once. A backup you have never restored is a hope, not a plan. When you restore, do it into a new location and review before resuming any automated work. Agents configured to run against the old path may otherwise start acting on a half-restored project.

Keep the link between the project record and the repository explicit. If the plan says a task lives in the payments service, it should be clear which repository and which path that means. On multi-repository projects that binding is easy to lose. Multi-repository agent projects covers how to keep it straight, and recovering interrupted agent work covers what to check after a crash.

QUESTIONS

How do I stop an AI coding project drifting from its plan over several weeks?

Write a short goal and reread it at a fixed weekly re-plan. In that session, compare the plan, the task board and the code, look for closed work whose checks are now stale, and note any code no task describes. Update the plan in writing, including what you dropped.

How often should I re-plan a long AI-assisted project?

Weekly works for most projects, at a fixed time whether or not something went wrong. Re-plan sooner after a big refactor, a dependency upgrade or a change in deadline. A short monthly review of the overall goal and scope is worth adding for projects longer than two months.

What should I back up on a long-running agent project besides the code?

The project record: tasks and their states, decisions and their reasons, review notes, and evidence of checks. Version control covers the code, but losing the record means losing why things are the way they are. Test a restore into a new location before you need one.

RELATED GUIDES

• How to read project progress in BRAIN FLUID Build
• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• How to hand off an AI coding session How to hand off an AI coding session: a short end-of-session routine so the next agent or person can continue without guessing.
• 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.
• Recording architecture decisions for AI agents Recording architecture decisions for AI agents: short decision records an agent will read, where to keep them and how to supersede one.
• Stale AI project memory Stale AI project memory: how notes and evidence an agent reads fall out of date, how to detect it, and what a freshness check cannot tell you.
• Recovering interrupted AI agent work Recovering interrupted AI agent work: inspect what was written, check what is still running, refuse blind replays and resume with a fresh authorization.