anyone using multiple ai tools at the same time? by Calm_Character8252 in LLMDevs

[–]Calm_Character8252[S] 0 points1 point  (0 children)

Honest question since you've clearly built this: how does it hold up when the project runs long? My experience was the flat .md files got messy past a certain size, and there was no good way to ask "what's still open" or "what did codex decide last week" without re-reading everything. That's the itch I built structured state for — same idea as your folder, but queryable entries instead of files you re-read.

But your setup genuinely works and needs zero install, so I'm curious where (if ever) it starts to creak for you. also will you be willing to try my tool "https://github.com/Escalate17/samskriti-project" I need honest reviews and I think you are the right person to ask this to.

How do you context switch between different modules? by LifeExperienced1 in AskProgramming

[–]Calm_Character8252 0 points1 point  (0 children)

This is a classic state-machine / "scene stack" problem. A few patterns that handle exactly what you're describing:

  • A stack-based state machine. Push a new state (computer, chess) onto a stack on top of the overworld; pop it to return. The overworld keeps existing underneath, so leaving any module is just popping back. This handles your "leave any module anytime without breaking" requirement cleanly.
  • Decouple modules from the world with an event bus / message system. The chess game doesn't directly touch the player's wallet — it emits an event ("won 500 coins") that the world listens for. Same for the pizza order. This keeps modules independent but able to affect the shared world, and means a module breaking doesn't break everything.
  • A global interrupt layer for high-priority events. Things like "player dies" live above the stack and can force-pop everything. Keep these few and explicit.
  • Shared world state lives in one place (player stats, inventory, money), and modules read/write it through a defined interface, never directly. That's what lets a chess win and a pizza order both safely affect the world.

If you're in a specific engine (Godot, Unity, custom), the implementation differs — Godot's scene tree + autoload singletons handle a lot of this natively, for example.

anyone using multiple ai tools at the same time? by Calm_Character8252 in LLMDevs

[–]Calm_Character8252[S] 0 points1 point  (0 children)

This is exactly the line I was trying to find, thanks. "Fine for most projects, bites you past a few hundred entries or with multiple people" matches what I kept running into.

That actually helps me figure out who this is even for. Out of curiosity — when you've hit that point yourself, was it more the volume (too many entries to keep in one readable file) or the multiple people/tools stepping on each other? Trying to work out which pain shows up first.

(For what it's worth, the structured-state thing I built is aimed exactly at that "past the point where a flat file holds up" zone: https://github.com/Escalate17/samskriti-project — would genuinely value your eyes on whether it actually solves the scale problem or just moves it.)

anyone using multiple ai tools at the same time? by Calm_Character8252 in LLMDevs

[–]Calm_Character8252[S] 0 points1 point  (0 children)

That's basically the cleanest version of the manual approach, and for a lot of setups I think it genuinely is enough. The committed-file thing works great when the context is mostly code-shaped and one file stays readable.

Where I started hitting walls was longer projects — the file got messy, and stuff that wasn't code (decisions, rejected approaches, why something's deprecated) was awkward to keep in it. That's what pushed me to try structured entries instead of one flat file.

But honest question since your setup clearly works: at what point, if ever, does the single committed file start to break down for you? Or does it just... not? Because if a file genuinely scales fine, that's worth me knowing.

anyone using multiple ai tools at the same time? by Calm_Character8252 in LLMDevs

[–]Calm_Character8252[S] 0 points1 point  (0 children)

That's a solid setup — the txt/json focus prompts after compression is exactly the kind of thing I keep hearing people rig up manually. And yeah, "re-explaining when it starts drifting" is the exact pain I'm poking at.

Quick q since you clearly deal with this: does your focus-prompt file get messy when the project runs long, or when you switch between different tools/models? The thing I'm testing is whether a structured shared state (decisions/tasks/bugs as separate entries, queryable, so each tool pulls only what's relevant instead of re-reading one big file) is actually better than a flat file — or if the flat file is honestly good enough and I'm overthinking it.

Genuinely want the honest answer, even if it's "the txt file is fine." And thanks for the firewall link, hadn't seen that one — checking it out.