This one is personal. On 13 September I installed Omarchy, a Linux desktop built on Arch and Hyprland. I did not switch to it. I wanted to dabble with a Linux OS, and to do the tasks I already know from a different point of view while I learned a new one. There was a lot of rave about Omarchy, so I tried it, and I have not been disappointed. At the same time I started doing real work side by side with Claude: this website, a couple of side projects, and the scripts and documents I lean on at my day job.
Two weeks in, here is the honest summary. Linux was not the hard part. The AI was not the hard part. The hard part was me, and the way I had set things up before I understood how they needed to work.
Mistake one: keeping my work in OneDrive
My project files lived where they always had, in OneDrive. On Windows that felt fine. Then I started using git properly, and learned something every developer seems to know except me: sync tools and git do not mix. OneDrive quietly syncs the inside of a .git folder file by file, and a git repository that gets half-synced is a repository that gets corrupted.
The fix was not a setting. It was a move. Over a few evenings everything went into private GitHub repositories, cloned into the same Repos folder on every machine, with sign-in through my password manager’s SSH agent instead of keys sitting on disk. Before every push, a scan for passwords and webhook links. On the first pass that scan found five files with live credentials in them. Those five are still on my to-do list, kept out of git until the secrets move into a vault. I would rather admit that than pretend it is done.
Mistake two: a different layout on every machine
I work on three computers: this Omarchy box, a Windows PC at home and my work laptop. Each had grown its own idea of where things go. Windows had Repos. Omarchy had a folder called AIProjects. Notes lived in a third place.
When I finally moved Omarchy to the same layout, I found out how many things were quietly keyed to the old path: the local copy of this website, a scheduled job that pulls the live database every week, the folder where Claude keeps its memory for a project, and the shortcuts in my notes app. Every one of them broke, and none of them said so loudly. The lesson I keep relearning: a path is a dependency. Before you move a folder, find everything that points at it.
Mistake three: assuming Windows habits carry over
Some things that are invisible on Windows fail silently on Linux, and silent is the dangerous kind of failure.
- A safety check that never ran. A project I work on with a friend has a git hook that stops anyone pushing straight to the main branch. On Windows it runs. On Linux git skips a hook that is not marked executable, prints a hint nobody reads, and lets the push through. The guard was there. It just was not guarding anything.
- Line endings. Scripts saved on Windows carry an extra invisible character at the end of every line, and bash on Linux does not like it. One setting in git, set before the first clone, stops it.
- Guides that are out of date. Omarchy moved its window manager configuration to a new format, and half the advice on the internet still tells you to use a command that no longer works. When the display in my virtual machine refused to resize, the answer was a small watcher script of my own, not a setting.
Mistake four: trusting “done” without checking
This is the one that matters most, and it is the one I warned about in AI is a great tool. Keep the value in you. I just had to learn it again with my own setup.
- I uploaded some of my Claude skills (instruction packs it loads for specific jobs) to my account so every machine would get them. It looked done. Later I found that only the main file had gone up. One skill should have had twenty-seven files and had one. Every reference inside it pointed at nothing.
- The same thing happened with a log I keep of lessons learned. I thought it was one log. It was split into separate copies on different machines, each looking complete from the inside, and they had started giving new entries the same numbers.
- An installer reported success, the config files looked right, and the tool itself said “failed to load”.
None of those were the AI getting it wrong. They were cases where the output said “success” and nobody, me included, went and looked at the thing itself. The fix in each case was the same: check the real result, from the outside, every time. Does the file count match? Does the live site show the change? Does the tool say it loaded?
The rule I work by now: “it said it worked” is not the same as “it works”. Check the thing itself, not the message about it.
What working with Claude actually looks like
People ask whether the AI does the work. It does a lot of the typing. It does not decide. A few things I have come to value:
- It writes things down. Every session ends with notes on what changed, what was tested and what is still open. When I come back three days later, I do not start from memory.
- It is not allowed to change its own guardrails. When a change touches Claude’s own settings or permissions, it stops and hands me the command to run myself. That annoyed me at first. Now I think it is exactly right. The thing being supervised should not be the one editing the supervision.
- Hard limits are real. One night I approved a deploy to this site just as I hit my usage limit. The message said the limit would reset at 4:40 in the morning. I went to bed assuming the deploy would happen then. It did not. Nothing runs by itself when a limit resets. The next morning I checked, and the site was exactly where I had left it. Checked, not assumed.
- It learns from mistakes, if you make it. I keep that log of lessons, and every correction goes into it. Once a week it gets reviewed and the fixes go back into the instructions. The same mistake should not happen twice. When it does, the answer is a hard barrier, not a louder warning.
What I would tell someone starting today
- Put code in git, not in a synced folder. Sync tools are for documents. Git is for anything that changes in steps.
- Pick one layout and use it everywhere. Same folder names on every machine, even across Windows and Linux.
- Write down how your machine is set up, in a place that survives the machine. Mine is a notes vault that syncs through git.
- Back up your configuration, not just your files, and practise comparing against the backup before you need it.
- Check the real result. From the outside. Every time.
- Let the AI help you do the work, not do it for you. Every mistake above was a lesson I would have missed if I had let it quietly clean up after me.
Running Linux alongside Windows, or working with an AI assistant? Tell me what tripped you up in The Patch Panel. I would bet some of it is on this list.
