I'm starting a series about how I gradually put together a workspace for my coding assistants. It will cover shared rules across projects, personal plans, working from my phone, and my attempts to stop depending on a single laptop. The story is still unfolding: I'm trying tools, changing my mind, and will be writing about how it goes. But first, I want to explain why I felt the need to build any of this.
This story has a fairly modest beginning: I got tired of repeating the same requests.
Don't commit until I've reviewed the changes. Don't add your own sign-off to the commit message. Small things, hardly worth interrupting your work for. Yet they came back in the next task, another project, a new conversation. And each time I had to briefly set aside whatever I'd opened my laptop to do and explain, once again, how I wanted us to work together.
By then, coding assistants were already part of my daily development work. With their help, I'd built quite a few products: things I used myself, things other people used, things real businesses relied on. Over time, I grew comfortable with that way of working. I learned where I was happy to trust an assistant and where I wanted to stop and inspect the result myself. Along with that experience came working agreements that, for some reason, I still had to carry from one conversation to the next.
I generally enjoy learning new tools. Lately, though, barely had I settled into one before I could see another way to do part of the work. A few months later, I'd revisit my process and find more to reconsider. There was plenty to be curious about, but I had little appetite for explaining my own habits all over again with every change.
I have a low tolerance for repetitive work. I can do it manually for a while, but somewhere in the back of my mind I'm already looking for a way out. So after making the same requests several times, I started writing them down as project rules.
At first, it was a small collection of agreements in one repository. Each had a clear reason behind it: the assistant had rushed ahead here, I'd had to explain the workflow again there, and this was something I'd already asked for in the previous task. Rules appeared as they became necessary, and I remembered exactly why each one was there.
Then I noticed that whole sequences of actions were repeating too. Creating a task, describing the intended change, preparing the result for review: I had preferences about those as well. That was how skills appeared alongside the rules, describing the way I usually worked. Things I'd once had to spell out every time gradually found a permanent place in the project.
Naturally, I wanted to take the useful discoveries with me. If one project had become easier to work on, why not give the others the same treatment? I copied the agreements, refined them, and soon ran into the next nuisance: now I had to keep all the copies consistent. Change something in one place, then try to remember everywhere else it needed to go.
When it came to sharing rules across projects and teams, rulesync proved useful. I collected the source rules in one main repository and set up a process that generated files for different agent tools and distributed them to the projects. The whole arrangement had a simple purpose: give me one place to make a change and a way for that change to reach the others.
Little by little, the system acquired more detail. Habits, small conveniences, solutions to recurring frustrations all found their way into it. I liked being able to carry experience from one project into the next without spending so much time explaining it.
Around the same time, I started planning a big camping trip for the following summer. I needed to put together a camp, work out what to bring, and think everything through. I was also paying more attention to my health and keeping track of what I ate. I kept notes for these things, and at first I didn't connect them with what I was gradually building around my development work.
Then I noticed I was returning to them with some very familiar questions. What had I already decided? What still needed figuring out? Where had I left off? Before taking the next step, I had to reconstruct the previous ones. In my work projects, I was already learning to spare myself that effort by keeping context somewhere the assistant could read it too.
I wanted to try the same approach with personal matters. Separate areas for development, health, camping, and other projects appeared in the shared repository. Each had its own notes and plans, while familiar ways of working could be used throughout.
And so the camping plans moved in next to the code.
It was surprisingly easy to get used to that arrangement. I could talk through plans with the assistant, return to recorded decisions, and work through what I still didn't understand. Starting a project no longer meant spending ages deciding where its first notes should go and how to avoid losing them. There was a place for it in an arrangement I already knew.
I felt the change most clearly when picking things up again. When everything is scattered across separate notes, even a short break creates extra work: you have to remember what you meant, find the right entry, and gather your thoughts. Here, continuing became easier. The project retained what I'd already figured out about it, and I could move on.
It made me noticeably more organized. More than that, I found myself wanting to return to my plans more often. They were easier to pick up, talk through, and see a next step in. The system I'd once started building out of irritation was slowly becoming a place I liked coming back to.
That place, however, lived on my laptop.
The files were there, Git was there, and that was where the agent ran, reading the material and making changes. As long as it was all about development, I barely noticed the tether: I sat down at a computer to work on code anyway. But thoughts about a trip or a personal plan rarely wait for you to open your laptop. They turn up in a taxi, in a coffee queue, in the middle of something else entirely.
At those moments, I wanted to take out my phone and continue the conversation. Add something I'd just remembered. Clarify a question. Check where I'd left off. Everything I needed was already gathered together; I just needed to reach it.
When tools for working with agents remotely became available, I was able to try that too. The laptop still did the work, but I could now direct it from my phone. My projects became easier to reach throughout the day: a quick check-in no longer required sitting down at the computer.
You get used to that convenience quickly. Especially when the conversation follows you between devices and all the rules and material you've collected remain within reach. I'd spent so much time putting it together, and now I could finally use it where the need arose.
All I had to do was remember to leave the laptop on.
Sometimes I forgot. Or its battery ran out while I was traveling. Then the whole arrangement, with its agreements, projects, and remote access, had to wait until I got back to the computer.
I think that was when I realized how far I'd come from those first requests about commits. I now had a workspace I wanted to reach at any moment. What remained was to make sure it didn't switch off along with my laptop.
I'll come back to taking that life beyond the laptop. First, though, I want to look more closely at what we'd actually be moving. In the next article, I'll return to those early rules and skills: how they grew out of everyday requests, how I gathered them in one place, and how I used rulesync to distribute them across projects. Those small agreements were where everything else began.
Top comments (2)
Moving the agent environment off the laptop onto a headless box solves the battery and sleep problem, but it usually introduces a credential and git-sync headache. On a laptop, local git operations quietly ride your interactive SSH agent and keychain. Once you run headless on a homelab box or VPS, any tool that needs write access or external APIs either blocks on a headless pinentry prompt or requires headless token scoping. The other friction is dirty working trees: if you jot down mobile notes into the shared repo while a local branch has uncommitted edits, reconciling the trees when the laptop reopens gets messy unless you isolate mobile context into dedicated scratch branches or out-of-tree markdown stores.
tr.ee/dev-to