Migrating My dotfiles to an Agentic Setup
Like many developers, I spent years managing my system configuration using a bare Git repository rooted in $HOME. It is a simple and elegant trick in which you alias git to point to a .mydot directory, set --work-tree=$HOME, turn off untracked files in status reports, and commit directly from your home folder. For a solo engineer working manually in the terminal, it works reliably with zero dependencies.
Recently I started integrating AI coding agents into my terminal workflows and came up with a simple approach to have my dotfiles developed for me by an LLM powered agent. I have spent my fair share of time studying other people’s approach to dotfile management, borrowing things from here and there, RTFM-ing documents and writing Lua code. So, after 264 commits, I decided to outsource my dotfile development to LLM agents.
In this post, I will share how I restructured my dotfiles to be safe and modular for AI-assisted development, and how the automation pipeline works.
The New Architecture
The updated setup centers on three components:
- A Dedicated Workspace (
~/dev/mydot): An isolated Git repository where both human and agent work. The agent only has access to this folder and its subdirectories. - GNU Stow for Symlink Management: Each application (such as Neovim, Sway, Alacritty, or Zsh) is organized into its own self-contained directory tree that mirrors the target structure under
$HOME. Stow takes care of creating and folding the symlinks atomically — it’s beautiful! manifest.jsonas a Declarative Source of Truth: A single JSON document that records which configuration packages exist and which paths belong to them. This provides structured context that any agent can read and understand immediately. More importantly, I know what’s being tracked.
Edits inside ~/dev/mydot are immediately reflect in $HOME through symlinks and changes can be tested immediately.
Automating the Migration: The mydot Lifecycle
./mydot.py -h
usage: mydot.py [-h] {discover,stage,simulate,deploy,restore}
AI-native Dotfile Manager
positional arguments:
{discover,stage,simulate,deploy,restore}
Action to perform
options:
-h, --help show this help message and exitTo automate the migration, I co-authored (which is a lie because it was mostly written by the LLM) a Python program (mydot.py) that implements a multi-step lifecycle:
Interactive Discovery (discover)
This phase inspects the host system for known baseline tools (nvim, sway, alacritty, zsh, git, and gh). To pick up additional personal utilities and configs, it scans ~/.config and $HOME, filters out system and application noise (like browser profiles and cache directories), and launches an interactive fuzzy selector (fzf).
Get Ioannis Petrousov’s stories in your inbox
Join Medium for free to get updates from this writer.
Once selected, the target paths are mapped to package names and written to manifest.json.
Staging and Secret Scrubbing (stage)
Using the manifest as its guide, the staging step copies candidate configurations from their actual locations into the repo.
This step acts as a security filter. It scrubs my known transient tokens and generates a .gitignore to exclude those secrets.
Simulation (simulate)
Before modifying any actual config on the system, the simulation phase executes a dry run using GNU Stow’s native simulation flags. This prints the exact symlinks Stow intends to create and highlights any conflicting files that already exist in the target directories.
Deployment and Automated Backups (deploy)
The script generates a timestamped backup directory in $HOME (e.g., ~/.dotfiles_backup_YYYYMMDD_HHMMSS). Moves original configurations into the backup folder, preserving their relative directory paths. Runs Stow to link each package from the repository into $HOME.
At this point, the system is fully operating on symlinks pointing back to the repository.
The Safety Net: Rollback (restore)
If anything behaves unexpectedly, the restore action provides an instant rollback. It automatically finds the latest backup directory, tears down the active Stow symlinks, and recursively restores the original files back to their exact locations in $HOME.
What Co-Authoring with AI Looks Like in Practice
With this structure in place, the development can now become agentic and controlled:
Scoped Context: When I need to refine a configuration, whether that is adjusting Neo-tree visibility rules or updating Pyright language server virtualenv detection, I open the agent directly in the repo (~/dev/mydot). The agent sees only configuration files and version history, with zero exposure to personal documents or credentials.
Immediate Feedback: Because live files are symlinked to the repo, any edit the agent makes takes effect instantly. I can reload the application, verify the behavior, and request adjustments without switching contexts.
Conclusion
Asking the agent to simply configure my nvim setup to do what I want it to do saves me valuable time. Instead of reading documents, code and fighting dependencies, I just send a send a request and the agent makes it its goal.
If you are exploring agentic workflows for your own development environment, prioritizing workspace boundaries and automated backups will save you a lot of headaches.
You can find my setup online: github.com/gpetrousov/mydot.
I’m curious to know how you’re adapting your dotfiles and developer environment for AI tooling? Feel free to leave your thoughts in the responses below.
