Two years ago, I went pretty deep into Nix and nix-darwin.
I spent a lot of time setting up my MacBook config so it would be declarative, reproducible, tracked in git, and more reliable than a bunch of manual changes and forgotten steps. I wanted a setup I could trust, rebuild easily, and roll back without stress.
I talked about it with colleagues, and a lot of them liked the idea immediately. The benefits were easy to explain. Reproducibility makes sense. Versioning makes sense. Treating your machine config like code makes sense.
A few of them even tried it seriously.
Still, most people bounced off it. The learning curve was steep, and the amount of effort it took up front was hard to justify. I can hardly blame them. Nix asks for a lot before it starts giving much back. You have to model your system, learn a new way of thinking, and fight through a lot of confusing edges. Sometimes you spend an absurd amount of time on a change that would have taken five minutes in a settings panel.
So even though I believed in the idea, I always felt a bit hesitant when recommending it. The upside was real. The cost was real too.
Two years later, I think the tradeoff looks better.
Nix itself is still Nix. It has not suddenly become friendly. The initial setup still takes real time and real patience. What changed is everything around it.
AI coding agents are now good enough to be genuinely useful on codebases like this. Tools like Codex, Claude Code, OpenCode, and Cursor can read through a Nix repo, follow the structure, understand patterns, and make the kinds of edits that used to require me to reload a lot of context into my head. I still want to review the result, obviously. But the routine burden is lower than it used to be.
That changes things more than I expected.
A big part of the cost of Nix was never just learning it once. The real cost was having to keep paying that tax every time you wanted to tweak something. Every small change meant re-entering the mental model, re-learning some corner of the language, re-discovering how a particular option worked.
That loop is much less painful now.
If the structure is already there, and the repo is reasonably clean, an agent can do a lot of the translation work between “I want this change” and “this is how the change should be expressed in Nix.” That makes the initial investment easier to defend. You are still paying for a system with a steep slope. You are just no longer climbing every part of it alone.
And honestly, this goes beyond Nix.
Lately I keep coming back to the idea that more of the things I care about should live as plain files in a repository.
My blog as Markdown files.
My machine config as Nix packages.
My finances as hledger journals.
Scripts, notes, little tools, all of it.
AI tools are unusually good at working with that kind of material. Give them plain text files and code, and they can actually do useful work: explain them, clean them up, refactor them, spot duplication, suggest better defaults, flag suspicious patterns, and automate the boring parts.
And the nice thing is that this does not require giving up ownership.
Quite the opposite. The more my stuff lives in simple files, the more control I keep. I can store it wherever I want. I can sync it however I want. I can inspect it with normal tools. I can diff it. I can revert it. I can roll back to an earlier state with a couple of git commands and move on with my life.
There is a real comfort in that.
It is not flashy comfort. It is the comfort of knowing that the important parts are legible and portable. They are not trapped in some product that feels convenient right up until the moment you want to leave, audit something, or recover from a mistake.
Git gets more valuable in that setup too. It stops being just version control and starts becoming memory, audit trail, and safety net. If an agent makes a weird change, I can inspect the diff. If I take things in the wrong direction, I can go back. If I want to understand how a system evolved, the history is sitting there in plain sight.
That is one of the more interesting consequences of the current AI moment, at least for me.
A lot of people seem to take AI as a reason to move further into opaque tools and magical interfaces. I keep landing in the opposite place. The better these agents get, the more I want my own work represented as files instead of hidden application state.
Once your workflows are in a repo, the agent becomes much more useful.
I still would not trust a model blindly with config, finance data, or anything else where small mistakes can have annoying consequences.
But the maintenance story really has changed.
A few years ago, adopting something like Nix often meant accepting that you personally would carry the full cognitive load forever. Now it feels more like front-loading the modeling work, then letting an agent handle a good chunk of the maintenance.
That is why Nix makes more sense to me today than it did two years ago.
The complexity is still there. What changed is the amount of leverage you get in return.
And that same logic is pushing me toward a broader way of working: code-first when it makes sense, file-first almost everywhere else. In a world full of capable coding agents, owning your workflows as text files in a repo feels less like a niche preference and more like solid personal infrastructure.
The old pitch for Nix was reproducibility.
Now I think the pitch is reproducibility, plus the ability to delegate a lot of the annoying work without giving up control.
My personal config is open source, check it here.