Lately I’ve been heads‑down on a complete rethink of my dotfiles setup. It’s not just a `.vimrc` collection – the goal is to treat the dev environment like any other project: reproducible from scratch, automated, and designed to scale as AI becomes a bigger part of daily work.

The core of the project is a “Spilled Coffee Principle,” which basically says that if I spill coffee on my laptop, I should be back up in an afternoon. Every configuration change is codified into scripts, not a one‑off terminal command. Setup scripts create directories, handle symlinks, document dependencies and generally remove the “Brent the bottleneck hero” problem.

Beyond that, the repo lives inside a P.P.V system (Pillars, Pipelines, Vaults) where dotfiles are one of the pillars. This structure separates foundational configs from automation pipelines and secure vaults. It forces me to think at the system level: how do all of my tools fit together, where do secrets live, and how can I onboard a new machine (or person) with a single `git clone && ./setup.sh`?

What’s really interesting is the mindset shift this has caused. I’ve been experimenting with what I call the OSE (“Outside and Slightly Elevated”) principle: moving from micro‑level, line‑by‑line coding to a macro‑level role where you orchestrate AI agents. At the micro level you’re navigating files in an editor and debugging sequentially; at the macro level you’re using tmux + git worktrees + AI coding assistants to run multiple tasks in parallel. Instead of `1 developer × 1 task = linear productivity`, you get `1 developer × N tasks × parallel execution`, which has obvious 100×–1000× potential. This OSE approach forces me to design workflows, delegate implementation to agents, and focus on the “why” and “what” instead of the “how”.

The result is that my dotfiles aren’t just about aliases anymore; they’re a platform that bootstraps AI‑assisted development, enforces good practices, and keeps me thinking about the bigger picture rather than getting lost tweaking my prompt or editor colours. I’d love to hear how others are approaching the macro vs. micro balance in their own setups.

I've actually settled more on the opposite approach - my tool usage changes enough that I generally only care to configure the latest subset of tools when I get a new PC, and of course the others are there if I need them.

To that end, each tool has its own subdirectory in my dotfiles repo ( https://github.com/bbkane/dotfiles/ ), and I add READMEs to each subdirectory explaining what dependencies are necessary for this tool, what keyboard shortcuts this tool uses, etc.

This approach has been pretty resilient against my changing needs, changing operating systems, and changing tool versions; even if doesn't optimize for a single invocation of ./setup.sh