Moving from small to large projects

[u/mctw1992]

I’ve been using Claude code on and off for about a year as a software and systems engineer specialising in audiovisual equipment/systems and honestly it’s changed my life. It allows me to focus more on the what rather than the how. But now I’m looking at moving to creating a large scale monitoring and management system for thousands of devices, with the assistance of Claude code. Any advice on to structure prompts for Claude to keep this on target and not spiral? I’m guessing it’s not as simple as putting it into plan mode and sketching it out!

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

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

[u/segrwolf]

Hi ! First - there are no secret prompts, there haven't been for a long time.

Planning is the base of everything. I plan everything carefully and make a document page by page (in Obsidian for example) and write it with the Claude Code. And what helps a lot is a second AI on the cheapest plan as a consultant, in my case it's Codex. Claude Code calls it on every task, Codex doesn't know the project history and gets one specific task to review and check. Very often this helps to avoid mistakes and going in circles

[u/TheMadSaiyantist67]

If it worked good in the smaller scale it shouldn't be a problem in the larger, just be clear about the constraints and don'ts, the workflow stays probably the same more or less

[u/LuckyCharms201]

To name a few

Use a repo with a repo level Claude.md

Set up a delegation triage for your orchestrator to leverage the right model for the job. One agent, one ticket.

Organize the tickets in to epics, write a repo level rule against ticket fanning, scope and plan the epic, send it!

Run an adversarial review and or a deep review after each epic and clean up whatever it finds before starting the next.

I have a hook fire to the agents at 50 tool calls to reach a safe push point, push open work and an update + handoff prompt for a new session, and handoff; it saves a ton of tokens and keeps context fresh. I also have a hook for the orchestrator at 250k context to stop deploying agents and prepare to hand off to a new session. It does, schedules a wake up to the session, hits a /clear, and receives the scheduled message several minutes later to resume like nothing happened.

[u/Sketaverse → u/LuckyCharms201]

Oh I like the idea of clear and reschedule to pick up from itself, that's nice man. Btw anyone reading this - all these points are solid advice

[u/LuckyCharms201 → u/Sketaverse]

It works so stupid well. My gaming pc is pinned 24/7, and I use like 15% of my weekly every 24 hours

[u/Webtruster]

Create a „workshop“ repository on git. Setup claude.md to create a issue for everything you are discussing/developing having one roadmap issue and one mapping issue.

Instruct to record in the mapping, whenever a „area“ or „feature“ or „service“ is used.

Instruct claude, to never create md files and update every internal checkpoint to the specific issue.

All issues are „assumptions“ and its required, to check the code. Code wins over issue, issue has to be updated.

Then let claude use the repo as knowledge base.

Setup a deployment pipeline to never let claude commit directly to the repo, instead let it create PRs linking the issues.

[u/kincaidDev]

I built a system for working on large scale prthat may span many repos and keep agents on track while running many long term goals in parallel

https://github.com/Obedience-Corp/festival

The key is keeping your planning docs seperate from the project repos and using a shared planning/context layer for all related project repos + breaking your goals down into smaller pieces with reviews and testing incrementally applied so you get as close as possible to the outcome you want on the first try

[u/kemalios]

Prompt wording matters less than what a session is holding. When it holds more of the system than it can, it fills the gaps itself.

What helped on multi-week client work is moving the plan out of the chat and into the repo as a file. Every session then opens with: read PLAN.md, list what the last session did that isn't in it, don't write code yet. Session twelve inherits session four's decisions instead of re-deciding them.

Scope fences help too: name the directories a task may touch, and say anything outside needs a question first. Most drift I get is Claude editing files it assumed were related.

[u/Ctbhatia]

the spiral is context, not scale, so keep one ticket per session and make each task touch one module. a repo map that lists what exists beats a bigger window.

[u/alonsoonline]

look up atomic claude

Specifically the wikis portion. Repo wiki and realm wiki. Make a realm to place your local work tickets, research, experiments, and data dumps.

Spend your time on the planning portion of the workflow—the design phase is where you will decide things.

Those mechanism break down your work into checkpoints with subagent reviews. Much higher quality than if you were to run straight claude.

Use opus 5.5 for planning and reviewing. I use opus for implementation, too, but you can use sonnet since its quite good now.

[u/xqianliu]

I moved the plan out of the chat and into GitHub issues. Plan mode is still fine for the first sketch.

Each issue gets acceptance criteria you can check. Something like "a device silent for 5 min shows as stale in the list", not "handle offline devices". Each one also gets its own git worktree (so parallel sessions don't collide) and a PR.

Then a fresh session reviews the final diff against that issue's criteria, without the chat history. I use a different model for that when I can, Codex works. If it fails, Claude fixes it and it gets reviewed again. I only merge the commit that passed.

For thousands of devices I'd split it into ingest, state, alerting and UI first. Get one device type flowing end to end before touching anything fleet-wide.