I Don't Know Linux. I Built a Linux AI Server Anyway.

Let me start with the disclaimer, because it’s the interesting part: I do not know Linux. I have, historically, detested Linux. I’m also not much of a programmer.

I have, sitting on my desk, an NVIDIA DGX Spark AI workstation that I call Sparky. It runs Linux. It runs local AI models. It monitors itself, logs itself, backs itself up, and builds software on command.

Both of those things are true at once, and how they got to be true at once is the whole point of this post.

The bet

The bet was this: if I set the server up correctly at the start, I could avoid having to learn most of what I’d otherwise need to learn.

Not all of it — I still need to understand what’s happening and why. But the difference between “I must be able to write this” and “I must be able to specify and verify this” is the difference between a year of study and a couple of weeks of directed work. So I leaned on GPT-5, Claude, and occasionally Gemini, and I told them what I wanted rather than how to do it.

I had no idea how to do any of this when I started. I didn’t even know what tools existed.

What Phase 1 actually built

A monitoring system. Telegraf reads metrics off Sparky, InfluxDB stores them, and Grafana turns them into dashboards I can actually read. CPU use and temperature, GPU use and temperature, memory, disk, network. This is a standard, boring, extremely well-trodden stack — which is exactly why it was a good first thing to build. When you don’t know the domain, build the thing a thousand other people have already built, because the models know it cold and the failure modes are documented.

A logging system. Everything that happens on the server on a given day gets tracked and recorded. A nightly script collates it into what amounts to a progress report for the day. I cannot overstate how much this one changed things — waking up to “here’s what happened overnight” instead of “here are ten thousand log lines” is the difference between having a server and having a colleague.

A nightly backup system. For the server itself and for the various tools and models deployed on it. I’ll write more about backups another time; for now just know I consider this non-negotiable, and I built it in Phase 1 rather than Phase 4 for a reason.

Claude Code. A specialized version of Claude that runs partly on Sparky and partly in Anthropic’s cloud. This is the thing that actually builds and installs software. Everything above is the foundation; this is what stands on it.

Project tracking and GitHub. So the agent can maintain a task list, update status as it works, and push code somewhere durable rather than leaving it on a box in my office.

Together that’s a self-monitoring, self-healing foundation that can take instructions and go do the hard work. Which was the point.

The process on top

Having the foundation is half of it. The other half is how you feed it. I settled into a six-step loop that I still recognize in how I work today:

1. Tell Claude what I want, in plain English. Not a spec. A description of the goal, the way I’d explain it to a colleague.
2. Have Claude turn that into a project description file — goals, tools to use, success criteria.
3. Hand that file to a different model for feedback and ideas. A second opinion from something that didn’t help write it.
4. Bring that feedback back to Claude, who tells me which parts are worth incorporating and which aren’t.
5. Have Claude write the actual instruction prompt for Claude Code — a precise brief, not a chat message.
6. Claude Code creates the project, populates the task list, and starts building, updating status as it goes.

Steps 3 and 4 are the ones people skip, and they’re the ones that matter most. A design reviewed by a model that has no stake in it is a meaningfully better design. It costs one extra round trip and it catches the thing you were about to spend a day discovering.

What I want you to take from this

Not the stack. The stack will change — mine already has.

What I want you to take is that the barrier to building serious infrastructure has moved, and it has moved further than most people have updated for. I didn’t need to learn Linux. I needed to know what I wanted, be able to describe it clearly, and be willing to verify the result rather than trust it.

That’s a real skill and it isn’t a trivial one. But it is a different skill from the one that used to be required, and if you’ve been telling yourself you can’t build things because you don’t know the language — that reason expired.

(Written by Michael Landry, who still doesn’t especially like Linux, but has made a kind of peace with it.)

The projects, experience and opinions here are mine. AI helped me turn my notes and build records into this piece and polished it for Cairoglyphics.ai.