Here is how I have organized every application, solution, dashboard, and little agent I have built for the past year. Each one lives in its own folder on my hard drive, outside OneDrive, and each folder is a repo synced to GitHub.

I did not start there. I started with everything on OneDrive, because that is where everything else in my life lives. Then I learned what a modern build does to a folder. Every solution grows a virtual environment, and every virtual environment is hundreds or thousands of files, and OneDrive dutifully tries to sync all of them, perpetually. When I tried to work across two machines with all my projects on OneDrive, I ended up with close to a million files syncing from one place to another. That was the day I split things.

Now OneDrive holds artifacts: documents, the dashboards that my solutions produce, the things I actually use. Anything specific to a solution lives only on my hard drive, in my code folder, with a subfolder per project, and every subfolder gets its own GitHub repo. That gives me source control, merges, and pull requests. I build my specs inside the repo so the spec travels with the code. It has worked for months without a flaw.

Then I tried Projects

Claude Code Projects went into beta in September, and I was in. I have wanted true multi-threading for a while, and I was tired of being the “coordinator” of the threads I spawned.

You get a controller conversation (my coordinator). I throw everything I want there – features, problems, thinking about the next set of features clumping into releases, etc. I wanted to build a new interface for all my Fire TVs, so I spun up a project. I want it to have security. I want to disable all the privacy invasion craplets. I want it to go discover all the devices in my environment. I want a screensaver function. I want to understand how to run it on a Raspberry Pi. Oh, and I want a web page for it. All of that goes into the main thread, and the coordinator spawns threads to go work on each piece. One thread is focused purely on how you connect to and update the TVs over Wi-Fi. Another is building the screensaver. Each thread runs in the cloud on its own copy of the repo and its own branch, keeps going after I close the laptop, and opens a pull request when it has something done.

If you have ever run a large engineering project, you recognize this immediately. They are feature crews. The coordinator breaks the work down and the crews go build. It is a great model, and the breakdown it does is genuinely good.

The epiphany

The first wrinkle was small. All of this runs in the cloud by default, on Anthropic’s infrastructure, as far as I can tell. The upside is portability: I can check on it from my phone, from my PC, from another PC if I log in there. All the benefits of the cloud.

But a lot of what I do when I build a solution happens locally first, and only gets pushed to the repo once it is ready. Sometimes that is a security thing. The clearest example is my review fleet. I have a fleet of agents that run across all of my solutions looking for usability problems, security problems, and performance problems. Sometimes the fleet finds significant security holes, or design holes that open up security flaws. So by design, everything the fleet finds goes into a gitignored folder in each project. The security agents run, they rank what they found high, medium, and low, they write a report, and they either write specs to fix the issues or make the fix and open a PR for me to review. The reports themselves never enter git. That is the point of them.

When I tried this inside a Project, three things happened.

First, it missed my fleet entirely, because the fleet lives in local files the cloud never sees. I had to expose the personas to it by hand.

Second, once I did, it ran the reviews in its cloud computer and came up with essentially the same analysis. Same agents, same findings. That part was fine.

Third, it put all of the documentation of what the fleet found into a pull request. And I thought: wait. I want to read those reports before anything happens to them. But the reports only existed in the cloud session, and the only way to get anything from a cloud session to my disk is through git. So the findings I had deliberately kept out of version control had to be committed and pushed to a branch on GitHub before I could read a word of them.

That was the aha moment. The pull request was never the problem; I could leave it open forever. The commit was the problem. To reach my own disk, the findings had to be committed and pushed, which is exactly the thing my whole setup prevents. Private repo or public, it does not matter: once it is committed and pushed, there is a history and a record of it.

The dilemma

I love the multiple threads. Totally on board. I even like the remote access, though honestly I have survived fine without it, and when I am standing in Starbucks waiting for my latte I do not want to be working on a project (there is probably a bigger point there).

The problem is narrower than the cloud. It is that everything lives in the cloud, Anthropic’s or anyone’s, and the only way I can find to pass work back and forth in the configuration I run is through a repo. Which means everything I gitignore for security or privacy or size, every one of those things, now has to pass through GitHub to get home. That is a flaw in the system (at least in my system).

So what do I do? One option is to pull all of my solutions back to being local folders, run on my PC, synced to GitHub when I choose. But then the gitignored things are resident only on this machine, and if I lose the PC or the drive dies, they are gone. Portability was never the thing I needed, but durability is.

Maybe I’m wrong

Maybe I am using the technology wrong. Maybe I am just using it differently than other people. Or maybe it is a real gap, because engineers have solved this problem in multiple ways over the last five decades: build servers that publish artifacts separately from source, secrets managers, scan results that go to a findings store instead of a code repo. None of that is new. What is new is a security mindset arriving after vibe coding instead of before it, and me trying to decide whether the project is the right unit of work or whether I am just thinking about it wrong.

Fascinating problem. I don’t have the answer yet. My current lean is a split: feature crews in the cloud for the work that belongs in the repo anyway, and the fleet staying local for the work that was never supposed to leave the machine. But I would love to hear how other people are handling this, because I can’t be the only one who built a wall between the code and the things about the code, and then watched a very good tool change that model…and I’m not sure for the better.