The Only One in the Room

Seven months of work, written down late

I've been the only technology person in the room for most of my career.

IT department of one at an industrial supply company, where the server room was a closet with a particle board desk from Walmart. The guy who learned SQL at a construction company because the reports people needed weren't in the application. Now a small team in Facilities at a university, where every pull request waited on one reviewer. Me.

I've been doing this since 1997. I used to be excited about all of it. Now I'm mostly tired.

I write things down anyway. I've watched what happens to work nobody writes down.

The part that never stuck

There's one gap I've carried through every job.

I couldn't write software. Not for lack of trying. I'd follow the tutorials, type as fast as the person on the screen, and understand none of it. I spent ten months at a software company hoping being around it would do what the tutorials couldn't. It didn't. I learned sprints and retros and a lot of acronyms, and how to translate between the people who use a system and the people who build it.

I got good at translating. It's a real skill. It isn't building.

So for most of my career, every idea I had came with a dependency: somebody else, with time I didn't control.

What changed

I use Claude Code.

I know. Another person telling you AI changed his life. It didn't change my life. It changed how much one worn-down person can keep running.

Most days the agent writes the code, runs the tests, reviews its own work, and opens the pull request. I decide what gets built, read what it did, and decide what merges.

That sounds simpler than it is. Out of the box, an agent is a very fast new hire with no context, no memory of yesterday, and no idea which mistakes already cost you a weekend. Most of what I built this year exists to fix that.

What I actually built

• A VM that never sleeps. A Linux box whose only job is hosting agent sessions. I drive it from the desktop app over SSH. I close the laptop and the work keeps going. Nothing else runs on it, because the first version ran out of memory with agents and workloads fighting over RAM. Containers and test databases go to a separate dev box, and a hook stops the agent when it forgets.
• A rules file where every line has a story. The ASCII-only rule exists because an em dash turned into garbage in a CSV we delivered. The rule against writing to the container platform's API directly exists because one write quietly turned a GitOps-managed stack into a hand-edited one and broke its deploys.
• A search index over every repo we own. One query costs about 750 tokens. Reading the same files costs ten to fifty times that. The agents ignored it and used grep anyway, until I put it where they'd trip over it.
• My notebook, wired in. My Obsidian vault syncs into that index every night. What I write down in the afternoon, the agents can search by morning. They write back into my daily note: what the review agent approved, what the overnight checks found.
• A map of the code. One graph across every repo, so "how do these two systems connect" gets an answer with a file and a line number.
• Watchdogs that stopped emailing me. They used to send everything straight to my inbox, where it sat. Now they report into a ledger that decides what actually needs a human. About thirty scheduled jobs in all.
• A reviewer that isn't me. An agent reads open pull requests, tests them, approves the low-risk ones, and sends the rest to me.

None of it is glamorous. Most of it exists because something broke.

Handing it to someone else

Then a coworker wanted the same setup.

The original VM was built by hand over several months. You can't hand someone several months. So I wrote the build down as a kit: one script for the system, one for the user, and an onboarding guide that takes about twenty minutes from a Windows PC.

Their own Claude account. Their own GitHub login. Their own memory. None of mine. Access is issued one credential at a time, for a stated reason, and the rules tell the agent that a missing credential means stop and ask. Not go looking.

That part mattered more to me than I expected.

A long time ago, a guy named Kevin ran a computer store next to the drugstore where I counted pills. He let me come in every day and ask questions until I'd bought every part for my first PC. A beige-box 486 with a 33.6 modem. I've been trying to pay that back ever since.

About the seven months

I didn't stop building. I stopped writing about it. By the end of most days, there wasn't anything left for this.

I'm not writing from the top of anything. I'm writing because the work happened, and work nobody writes down gets erased. I already wrote that post. I should probably follow it.

What's coming

Roughly in this order:

• The VM that never sleeps. Why the agent gets its own machine, and why that machine isn't allowed to do anything else.
• Every rule has a scar. The rules file, the hooks that enforce it, and the one guard I gave up on because you can't judge intent from a command line.
• RAG lost to grep. I built my agents a search engine. They didn't use it.
• The notebook that feeds the machine. Obsidian, a nightly sync, and the daylight-saving bug in a retry window.
• Search order matters. Knowledge first, then the code graph, then grep.
• The night shift. Agents that review, triage, and fix while I sleep, and what they're not allowed to touch.
• Handing it to someone else. Turning a hand-built setup into a kit a coworker can run.

Where I Landed

• The VM runs. A second one runs for a coworker.
• The agents do most of the typing. I still do the deciding.
• The review bottleneck is smaller. It isn't gone.
• My own VM is behind the kit I built for someone else. One of its hand-installed hooks has a bug that grows a file every time a session compacts, until no command in that session can start. The kit's copy is fixed. Mine isn't yet.
• I still can't write software the way the tutorials meant. I'm less sure that matters than I used to be.

This week the container registry didn't come back after a 3 a.m. reboot. No error. No log line. The service just never got scheduled, because of one missing word in /etc/fstab.

It's in the changelog now, with the root cause and a one-line check to run after the next reboot.

My last post was about a one-line problem I gave up on. This one I didn't.