Vibecoding
Build for the vibe, debug later
Start new thread

My AI sessions kept forgetting each other's work and burning my limits. How do you handle it?

by
•

My old way of building with AI stopped working.

My Claude and Codex limits were gone in 2-3 days. Codex kept forgetting what the other sessions had done. For three weeks I couldn't ship one feature, and I kept forwarding messages between the two AIs by hand, like a courier.


In the end I set up a harness: one shared space where every AI session, in any tool and on any computer, starts by knowing what we decided, what we tried and what's next. Within two days the stuck feature finally worked. Now my limits last the whole week.


I wanted to share this experience and discuss it here on PH. But the full story was too long for one post, so I put the detailed breakdown of how I build (a network where AI agents represent people and companies and talk to each other) and how the harness took our product development to the next level on my Substack:
I'd love to have the discussion here on PH.

So here are the rules that mattered most:

  • Every decision goes into a shared log as my exact quote. Otherwise my "for example" turns into a rule a week later.

  • Every task gets a budget. One night Codex survived 17 compactions without losing the goal, and still burned 75% of my weekly limit solving nothing.

  • Hand over work before the chat is 80% full, and let the next session check what the previous one forgot.

  • "Done" means it works for real users. Green tests only mean "implemented".

I'm still not a programmer, so I'd love to discuss the process here: what you'd do differently and what I'm missing.


What does your AI keep forgetting, no matter how many times you tell it? And what finally fixed it?

19 views

Add a comment

Replies

Best

An agent loses context mid-task and rebuilds a utility function under a new name, missing that the exact same helper already exists two files over. It has to grep the repo for matching signatures and inspect local imports before it writes any new helper logic.

 Same habit in my setup, just one level up: Claude and Codex love building from scratch. They wanted to write their own harness and their own agent loop before checking what already exists. Now there's a rule in my harness: check what's already there before building anything new.

Your grep-before-writing version is the same rule at the code level, and more concrete. Do you enforce it as a rule in , or does something catch duplicates after the fact, like a review step?

 Even with an explicit pre-flight step in AGENTS.md, prompt rules still leak. A custom pre-commit script parses local ASTs to catch identical logic before merge.

the shared log getting too long to read is the real tension.. mine's append only and i stopped trying to keep it short. the top 20 lines are the current state a new session reads, everything under that is history you grep when you need it, not read top to bottom. what mine keeps forgetting is what it already did last session, so it commits after every step and the handover line is just what's done, what's next.. if it forgets anyway the trail is there to grep.

Not a dev either, and for me it was “already done” that got forgotten. One session checked our plans against reality and three “urgent” blockers had been closed for weeks 🙃

Limits got better once the main chat only plans and reviews, and subagents on cheaper models do the reading. Line ranges, not whole files.

How do you keep the shared log short enough for a new session to read?

My setup ended up very close to yours. Every correction goes into a file. Each project has a memory folder with one fact per file and a one-line index the next session loads first. A session card also saves itself in case something hangs. What kept getting forgotten anyway was rules buried in long docs, so anything that slips twice becomes a hook that blocks it before it runs. I'm at 77 of those now.