Arch Linux has a documented philosophy. The Arch Way describes a system built for “the proficient GNU/Linux user who is willing to read the documentation and solve their own problems.” The ArchWiki is one of the most thorough technical documentation resources in open source precisely because the distribution expects you to use it, not as a cheat sheet but as material for building your own understanding. Work through an Arch install and you emerge with a configured system and, more importantly, a working model of how it is put together.
Will Morrison’s experiment in handing that process to Claude Code is worth examining through this lens. The tool produced a working system. The question worth asking is what else it produced, and what it did not.
Dotfiles as Accumulated Decisions
The standard arguments for managing dotfiles with a tool like chezmoi, yadm, or GNU Stow center on portability and reproducibility. Your configs live in git, you push them to a new machine, and your environment follows you. The ArchWiki dotfiles article covers the tradeoffs between these approaches well. This portability is real value.
The less-discussed aspect of a well-maintained dotfiles repository is that it is a record of decisions. The alias in your .zshrc that shortens a five-flag git log invocation represents a moment when you ran the full command often enough to bother shortening it. The [diff] tool = delta in your .gitconfig came from learning that delta exists and deciding it was worth the dependency. The custom mkinitcpio hook ordering is there because you debugged a boot failure once and worked out the correct sequence.
When Claude Code writes these files for you, the decisions are made by the model based on its training distribution and what you asked for. The configs can be correct, even good. What is missing is the record of your decisions, because you did not make them. The dotfiles become something closer to a template applied to your machine than a document of your accumulated preferences.
This matters for maintenance. Your .zshrc will need editing. Your git aliases will evolve. When you need to change the behavior of a tool you use daily, you are editing text you did not write, with implicit dependencies and orderings you may not know about. The early edits will be fine; problems surface when you hit an interaction you did not anticipate, between the LLM-written shell initialization ordering and a plugin you added yourself, or between a PATH manipulation Claude Code placed in your config and a tool installed later that expects a different order.
The Session-Scope Problem
Claude Code operates within a context window. It reads files, observes command output, and makes decisions within a single session. The CLAUDE.md file is the mechanism for carrying intent across sessions: you document your goals, hardware, and relevant decisions, and a subsequent session picks up from there.
For pure dotfiles, this works reasonably well. Changes are text, committed to git, auditable. A future session can read the diff history and partially reconstruct what was done and why.
For system-level configuration, the session boundary is sharper. An Arch system’s actual state is a function of its hardware, the order in which packages were installed, which mkinitcpio hooks ran successfully, and what the bootloader picked up after the last kernel update. A CLAUDE.md file can record intended state. It cannot capture whether the NVIDIA module actually loaded, what the initramfs contains right now, or what appeared on the framebuffer during the last failed boot attempt. The gap between the file and the live system is real, and neither you nor a future agent session has complete visibility into it.
This is not a failure specific to Claude Code. It is a property of imperative system configuration in general, which is why tools like Ansible were built around idempotent operations and explicit state inventory, and why NixOS takes the more radical position that system configuration and system state should be the same object.
Why NixOS Is a Better Fit for This Kind of Automation
NixOS configuration does not describe what you did to your system; it is what your system is. Running nixos-rebuild switch derives the running system from configuration.nix, so the file is always the complete ground truth. You can hand that file to Claude Code, ask it to add NVIDIA support, and the resulting config is the whole story:
hardware.nvidia = {
modesetting.enable = true;
powerManagement.enable = false;
open = false;
nvidiaSettings = true;
};All the correct downstream implications, kernel parameters, initramfs hooks, and display server configuration, are derived by the Nix module system. There is no gap between the file and the live system because the system is a function of the file.
Home Manager extends this to user-space configuration. Your shell, editor, fonts, and services are reproducible derivations. If Claude Code edits your home.nix to add a package or reconfigure a tool, the change is isolated, reversible, and complete. There is no implicit state to miss.
This is why LLM tooling applied to NixOS configurations is more tractable than the same tooling applied to Arch. The declarative model gives an agent the complete ground truth to reason about. On Arch, reading the config files tells you the intended state, not necessarily the current one. The agent is reasoning about a projection of the system, not the system itself.
The Role Worth Keeping
Assisted configuration produces better outcomes than autonomous configuration, and the difference is about where the mental model ends up.
You describe a goal. Claude Code explains what change would produce it and why. You review the explanation, apply the change yourself, and observe the result. The agent accelerates the work; you accumulate the understanding. Over time, your CLAUDE.md documents decisions you made, with context you hold, rather than decisions made on your behalf by a tool with no persistence.
I work on systems code and Discord bots, and the pattern that holds across both is that AI assistance is most useful when it speeds up work you already understand well enough to evaluate. For bot development, that means command dispatch boilerplate, schema parsing, API wrapper scaffolding. For system configuration, it means generating a systemd unit file you can read and understand before you enable it, not autonomously restructuring your init chain.
The autonomous path, handing an agent a fresh Arch install and asking it to produce a working environment, pays the full complexity cost of Arch without collecting what that cost buys. Arch’s manual configuration process is high-friction by design, because the friction is the mechanism by which you build the system model you will need to maintain the system later. Skip the friction and you have a working system owned by nobody.
If what you want is a system configured by tooling you do not need to deeply understand, the more principled path is a distribution whose configuration story is designed for that: NixOS for full declarative reproducibility, or one of the mainstream distributions that ships sensible defaults and expects you to override them incrementally. Arch has been explicit about what it is for since its earliest documentation, and nothing about LLM tooling changes that design decision. The Arch Way is still a document about the kind of user Arch is for, and “willing to let an agent handle it” is not on that list.