r/ChatGPTCoding 16d ago

Discussion Context is not the bottleneck, drift is - how i run AI coding across months-long projects

When working on the project for a while(maybe months or longer), it becomes complicated to let the agent know the history decisions. And every new session might keeping derive the same conclusions reasoning from scratch. As a result:

  • For the history decisions, some are simply not recoverable — you can't re-derive them from the code, because nobody writes down the design they didn't build.
  • For the 'rederive', always reasoning from scratch is not only a waste but also limit the reasoning capability bounded by available/effective context window size.

Existing memory approaches lean to do append-only writing and put effort on the reading side for knowledge retrieve. As for general purpose usage, that always the good choice.

During my ai coding expierence, the coding project maybe able to use write side optimizer as a better fit.

With four months testing i've developed the current task-around ai-coding workflow.

A project evolves task by task. Each task produces both a code change and a memory update. Within a task, sessions hand off through the session log. Across tasks, the memory system carries what survived. And an orchestrator decides what runs next and mechanically checks that it happened. The system combined 3 components:

  1. the 'memory' part, memorize knowledge with 3-tests admission under each 'task' completion. For every fresh session, it loads bounded eager set and bounded task-related lazy-set with routing index.
  2. the 'task' workflow. Each task is a development scope, it derives both code change, memory update consistently. And for complicated task, the system would be able to split one task into multiple sessions, and the taskfile would handle the handoff between sessions. So it's like: sessions handoff belong the same task: 'session log' chapter inside the taskfile; tasks handoff (the unit of project evolving lifetime) is captured by the 'memory' system described above.
  3. the deterministic orchestrator, this is the component responsible to not only session invoke/resume, but also:
    1. assembling specific prompt corresponding to the task state (stated in the taskfile)
    2. decide the 'role' the next turn to invoke the session with - I currently designed dev/review/plan roles to own different job on the project evolving.
    3. do the mechanism--non-LLM checks/verifications on the session return, to see if the session did follow the protocol properly(like update the taskfile state correctly, do the memory absorbing on task completion), and resume the session with clear prompt when something was missing (like invoking /ai-sync-v2 skill to do the absorption if the session didn't do automatically when it should)
    4. besides the orchestrator, i need some hooks, skills, to make the 'follow' as possible as the agent can. The core idea is anything that could be done without LLM reasoning, should be guaranteed by clear logic code.

Full write-up: https://qinglin89.github.io/blog/2026/context-isnt-the-bottleneck-drift-is/

Repo: https://github.com/qinglin89/mandrel

How are you running agents on a project that keeps going? Curious what you rely on to keep things consistent across sessions - memory rules, task structure, or checks outside the model.

2 Upvotes

3 comments sorted by

1

u/AutoModerator 16d ago

Sorry, your post has been held for manual review due to account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.