Solo development has gotten a great deal easier in the AI era. The development environment, on the other hand, is as tiresome as ever. That's something I've been thinking about a lot lately. The reason is that ever since I started using AI, I've found myself juggling several projects at once far more often.
I'll be building web app A while tinkering with web app B, writing a CLI, and poking at an API server on the side. Things I'd once have narrowed down to just one, I now push forward in parallel without a second thought. Some people use worktrees to develop several features of a single app in parallel. In my case, though, I'm usually carrying several separate applications at once.
Even things I'd have dropped with a "well, it's a hassle, never mind" in the past, I can now get to a working state by talking them through with AI. Sketch a rough design, write a first implementation, run it locally. The hurdle to getting that far has dropped dramatically.
What gets in the way, however, isn't writing code. It's the environment for running all these things. While it was one or two projects, I could still manage. Start Docker, start the dev server, shut it all down when you're done.
Once the number of projects in play goes up, the story changes. This web app has a DB running, another API server is up, and there's that other app too. Over in a monorepo, four React apps are running at once. At that point, I genuinely lose track of what is running on my own machine.
In particular, Next.js and React, which I work with a lot, all seem to covet port 3000. As a result, I can no longer keep straight which app is on which port. Docker containers multiply, terminal tabs multiply, and environment variables differ per project. Writing code has become easier, yet the hassle of running multiple projects at once has barely changed.
If anything, because AI lets me build more things, there are more occasions when I'm spinning up several dev environments at once. That's why it bothers me more than it used to. Frontend alone is fine, but once API servers, DBs, and Docker get involved, the local environment gets fairly heavy. What didn't bother me at first has become steadily more painful as the projects pile up.
Writing Is Easy, but It Still Has to Run Somewhere
Thanks to AI, the cost of writing code has dropped a lot. Touching multiple projects at once has become possible, too. Even so, in the end you still need somewhere to run commands like these.
pnpm install
pnpm dev
pnpm test
docker compose up
If you use a DB, you have to start it. An external API means standing up a mock server, and a web app needs a dev server running. AI may write the code for you, but it doesn't look after the runtime environment on your behalf.
Meanwhile, with more projects in hand, managing the development environment has become more conspicuous than before. In the past I could focus on a single project, with no need to fuss much over the local environment. Now, at least for me, working on web service A while verifying something for B and writing an API server on the side is becoming the norm. And then putting everything on my main Mac gradually becomes exhausting.
Separating Where I Write From Where I Run
Let me say up front that I like the Mac itself. I've been a devoted Apple believer for over ten years now. As a place to write code, I'd actually rather keep using the Mac exactly as I do.
But do I really need to cram the environment for running apps onto the Mac as well? That I'm somewhat doubtful about. It's a bit like hauling a lathe and a welding rig into the study where you write. Couldn't writing and running live apart, the way a study and a workshop do?
As it happens, I have unused PCs lying around at home. When https://vscode.dev/ came out, I thought it might let me develop from an iPad and set out to try it. In the end it became too much of a hassle and I gave up. Back then I was only touching two or three projects at a time, so it wasn't that painful.
Now, though, I'm in a situation where I can build an endless number of applications. All right, "endless" is an exaggeration. Still, building whatever pops into my head has genuinely become an everyday thing.
So what I have in mind is a setup where I keep writing code on the Mac as before while standing up servers in a separate environment. Put simply, I want a staging environment of my own with hot reload. On the Mac, I open the editor, use AI coding tools, and do Git operations. Design work, research, and checking things in the browser stay on the Mac too.
Meanwhile, the parts that actually run — the app itself, Docker, the DB, tests, the dev server — are left to Windows/WSL or another Linux machine. SSH and file sync connect the two. Picture drawings from the study being passed down the hall to the workshop.
I don't want to move entirely to a cloud IDE. It costs money, for one. There are options like VS Code Remote SSH or GitHub Codespaces, but what I'm thinking of is a looser arrangement. Edit on the Mac as usual, and move only where things run. Call it half-remote development, if you like. That sort of distance looks about right for me at the moment.
Why Windows/WSL?
Mind you, it doesn't have to be Windows/WSL. A Linux server would do, so would a Mac mini, or really any spare PC. It's simply that I have a Windows machine and an old 2014 Mac mini on hand. I'm wondering whether I can put them to work as the execution environment.
Although I say Windows, in practice I mean to use WSL. Run Node and Docker on WSL, and SSH in from the Mac. Sync files edited on the Mac over to the WSL side and start the dev server there. Anything I need to check in a browser, I make reachable from the Mac side. That way I can keep the Mac as my main workplace while offloading only the execution environment to Windows/WSL.
Since I can use machines I already own, it's far more casual than keeping a cloud environment running all the time. Codespaces and the like are convenient, of course, but plenty of projects aren't worth moving there every time. For something I just want to try out, I'd have to create a cloud environment, worry about billing, and get the configuration in order. That's a bit much.
In that case, treating the Windows or Linux machine at home as a rough-and-ready execution environment suits me far better. If it breaks, no great loss; I can rebuild it if needed. And as a place where I let AI coding agents do as they please, it's reassuring to have it somewhat cut off from my main Mac. A workshop can get messy without staining the books in the study.
What I'm hoping for above all from this setup is to keep my main Mac as clean as possible. Naturally, the bare-minimum development tools — Git, an editor, AI coding tools, a browser, a terminal — still go on the Mac. But that's where it stops. Per-project runtime environments like the DB, Docker, dev servers, and test runs get pushed over to the Windows/WSL side as much as possible. That way the Mac stays pleasant to write in, and separating environments per project should become an easier call to make.
The Hard Part: File Sync
When you actually try it, though, the biggest problem is file sync. I write code on the Mac, and the change is reflected on the Windows/WSL side. The dev server running over there detects it and hot reloads. If that flow doesn't feel good, I'll probably stop using the whole thing in short order.
What matters most in a development environment is, in the end, the absence of stress. Updates that lag a little, syncs that occasionally fail, hot reload that doesn't fire. Run into any of that even once and the will to use it evaporates.
The candidates include rsync, Syncthing, Mutagen, SSHFS, and VS Code Remote SSH. First, rsync is simple and easy to understand. To sync continuously, though, you need a separate mechanism that watches for file changes and runs rsync. One-off syncs are easy; if you'll be using it throughout development, it takes some ingenuity.
Next, Syncthing looks quite good as far as continuous sync goes. For development use, though, you have to think properly about node_modules, build artifacts, and cache files. It's painful when things you don't want synced get synced, and just as troublesome when things you need don't.
Mutagen also looks close to this use case. It handles local-to-remote file sync nicely, so it seems a good fit for separating dev environments. Whether it suits my particular needs, though, I won't know until I actually try it.
SSHFS looks simple at first glance, but I have a feeling I'd get stuck on file watching and performance if I used it as a dev environment. Frontend dev servers in particular depend on file watching. Instability there is a dealbreaker.
Using VS Code Remote SSH would probably solve most of these problems. But that means moving the whole editor to the remote side — relocating the study into the workshop, so to speak. What I want this time is to edit on the Mac as usual and offload only execution to another machine. Remote SSH would be sufficient, but it isn't quite what I'm after.
Ultimately, the crux of this setup comes down to whether hot reload just works. Save on the Mac, the file syncs to the Windows/WSL side, the dev server over there picks up the change, and the browser refreshes. If that loop doesn't run without friction, I can't use it day to day. Conversely, if that part feels good, it becomes genuinely practical.
Even a somewhat crude sync mechanism is good enough as long as changes show up the moment I save. I'm not trying to build a perfect distributed dev environment from the outset. Files written on the Mac get synced nicely to the Windows/WSL side, and the dev server reacts properly. That alone would help me a great deal.
A Sync Tool of My Own
Thinking all this through, I'm starting to feel I might as well knock together a small sync tool for myself. For example, I'd write a config file like this for each project.
project: my-app
local:
path: ~/src/my-app
remote:
host: windows
path: /home/me/src/my-app
ignore:
- node_modules
- .next
- dist
- .git
- coverage
Then I'd start it like this.
devsync start
From there, it watches for changes on the Mac side and sends only the necessary files to the remote side. Sync everything first, then only the diffs after that. Exclude things like node_modules, dist, .next, and coverage. Changes show up as soon as I save.
That's about all I want to begin with. It doesn't need to be a polished tool from day one. If it works in my environment and doesn't cause me trouble, that's plenty.
Down the line, it would be handy if it could do things like this.
devsync shell
devsync run pnpm dev
devsync run pnpm test
devsync status
That said, trying to build all that from the start would be a lot of work, so sync alone will do for now. I can leave the file transfer to rsync, or write just the watcher myself. In short: save on the Mac and it's reflected on the Windows/WSL side. Even that much has no shortage of uses.
The Bottleneck Moves
Since I started using AI, I feel the bottleneck in development has shifted a little. Before, writing code was itself the hard part. Design, implement, write tests, verify behavior. Deciding on an approach, researching libraries, writing the detailed code, and fixing errors were where the time went. It's still no walk in the park, of course, but I can now get a great deal of help from AI.
The hassle of the execution environment, on the other hand, has hardly changed. If anything, now that I write code faster, it stands out more. AI may write the code, but the app still has to run somewhere, and the tests still have to run somewhere. You need a DB, you need Docker, you need external API settings.
Seen that way, I suspect that from here on, it won't just be "how to write code" that matters, but also "where to run it safely." This goes double if you let AI coding agents touch a lot of things: separating your main PC from the execution environment means a great deal. Having it run commands, run tests, edit files — if you're going to allow that, a separate machine, a container, or a WSL environment is bound to be far easier on your nerves than letting it fiddle directly with your main Mac.
That's where my thinking stands on dev environments in the AI era. Being able to build more has made the cluttered local environment bother me more than before. So I want to try a setup where I write code on the Mac, offload execution to Windows/WSL or another Linux machine, and connect the two with file sync. File sync and hot reload are the hurdles, but a small sync tool of my own is enough to start. Save on the Mac, see it reflected over there, and have the dev server running over there. That's all I need for now. Rather than cramming the workshop into the study, keeping them a hallway apart is just about right for development in the AI era.