← all writing

In this article

How Claude made my life easier by helping me build dot

, , , ,

For years I wanted a proper way to set up a new laptop or server in minutes. I finally built it: dot, a portable dotfiles CLI. I didn’t build it alone, though. I built it with Claude Code as my pair programmer, and it made the whole thing a lot easier.

This is how that collaboration worked, where Claude Code was genuinely great, where I had to stay sharp, and what I’d tell anyone who wants to build their own developer tools with AI.

The short version

I designed dot; Claude Code helped me build it. It was strongest at the two things I find most tedious, portable shell scripting and Neovim Lua config, and it never replaced reviewing and testing the result myself.

The problem I wanted to solve

Every new machine meant the same ritual: install zsh, restore my Neovim config, build tmux, install a dozen CLI tools, and discover halfway through that I don’t have sudo on this particular server. My dotfiles were spread over half-finished scripts and notes.

I knew what I wanted: one command, no sudo, the same result on macOS and Linux, and all my configuration in a single repository. What I didn’t want was to spend months of evenings writing and debugging shell scripts to get there.

How Claude Code and I split the work

I didn’t hand Claude a vague prompt and hope for the best. We worked as a pair, and the split was fairly clear.

I owned the design. I decided that dot would be written in pure zsh, that every tool would be a module exposing module_install, module_update and module_status, that profiles would group modules for a desktop or a server, and that everything would install into ~/.local.

Claude Code owned a lot of the implementation. Because it runs in the terminal, directly in the repository, it could read the existing modules, follow the conventions, write the next one, run it, read the error and try again. My job shifted from typing code to explaining intent, reviewing diffs and testing on real machines.

modules/ripgrep.sh (the shape every module follows)

MODULE_NAME="ripgrep"
MODULE_DESC="ripgrep — fast grep"

module_install() { ... }   # download, extract to ~/.local/opt, link into ~/.local/bin
module_update()  { ... }   # only download when the remote ETag changed
module_status()  { ... }   # print version and stamp

Having that pattern in place early was the single best decision I made. Once Claude Code had a few good examples to follow, new modules came out consistent with the rest of the codebase.

Where Claude made my life easier

Portable zsh and shell scripting

Shell scripting that works everywhere is full of small traps: flags that differ between macOS and Linux tools, release archives named differently per platform, and machines that are missing the very things you want to use. This is exactly where Claude Code shone.

It helped me write bootstrap.sh in plain POSIX sh, so a machine without zsh can still install it, first through the package manager and otherwise by building it from source into ~/.local. It helped with the ETag-based update checks that keep dot update all from downloading things that haven’t changed, and with dot init, which checks the environment and explains how to fix what’s missing.

None of this is rocket science, but it’s the kind of detail-heavy work where I would have lost hours reading man pages. With Claude, I could stay focused on how dot should behave instead of on the exact syntax to get there.

Neovim Lua configuration

My Neovim config is a project of its own: LSP servers, completion, formatting, linting, debugging, and Laravel tooling that runs inside Docker containers. Plugin APIs change, and every plugin has its own way of being configured.

Claude Code helped me turn ideas into working Lua quickly. The .nvim-tools.json setup, where pint, phpstan, artisan and Xdebug run inside the right container with paths translated between host and container, would have taken me much longer on my own. So would the AI toggles that let me switch Copilot off globally or per buffer and keep it away from files like .env.

If you’re curious why I put so much effort into a terminal setup in the first place, I wrote about that in Switching to Neovim: why it made my life harder, but easier.

Where I had to stay sharp

Working with an AI pair programmer isn’t free. These are the things I learned to watch for.

  • It sounds confident, even when it’s wrong. A script that looks right can still behave differently on another OS. Nothing counted as done until I’d run it on a real Mac and a real Linux machine.
  • Shell scripts deserve extra care. dot installs software and writes into my home directory. I read every change before running it, especially anything that moves, overwrites or deletes files.
  • Plugin knowledge can lag behind. Neovim plugins change fast, so suggestions sometimes used an older setup style. Checking the plugin’s own docs was still part of the job.
  • It’s easy to build too much. When adding a feature costs a sentence, scope creep is tempting. I had to keep asking whether I actually needed something.
  • You still need to understand the code. When something breaks on a new server, I’m the one debugging it. Pairing, rather than blindly accepting, is what makes that possible.

Review it like a pull request

Treat AI-written code the way you’d treat a colleague’s pull request: read it, question it and test it. Especially for scripts that change your system.

Tips for building your own tools with Claude Code

  1. Design the structure yourself. Decide the architecture and conventions before asking for code.
  2. Give it examples to copy. Write the first module or component carefully; the rest will follow its shape.
  3. Work in small steps. One module, one feature, one change to review at a time.
  4. Test on real targets. Use a container or a spare machine for anything that installs or deletes.
  5. Commit often. Git makes it cheap to try an idea and throw it away.

Frequently asked questions

Can Claude Code build a CLI tool for you?

It can write most of the code, but it works best as a pair programmer. You decide the structure and conventions, Claude implements and debugs them, and you review and test every change on real machines.

Is AI-written shell script code safe to run?

Only after you’ve read it. Scripts that install software or change files in your home directory should be reviewed like any pull request and tested somewhere disposable, such as a container or virtual machine, before you trust them on your main machine.

Does Claude Code work with Neovim?

Yes. Claude Code runs in the terminal, and plugins like claudecode.nvim connect it to Neovim so Claude can see your selection and propose edits as diffs you accept or reject.

Easier, not effortless

Claude Code didn’t build dot for me, and it didn’t remove the need to think. What it did was take the most tedious parts, portable shell scripting and Neovim configuration, and turn them from evenings of frustration into focused sessions of reviewing and testing. That’s why a project I’d wanted for years actually got finished.

Today a new laptop or server feels like home within minutes. If you want to see the result, the code and a full overview are on the dot project page.