Apr 4, 2026 · 2 minutes
The case for moddable software
I enjoy tweaking my tools – Ghostty, Neovim, tmux, zsh, etc. Keybindings, layouts, little scripts that glue them together. It always took longer than it should, an evening to wire one thing to another, most of it trial and error.
What they have in common: everything is a config file. I wrote a custom Gruvbox theme for Ghostty because the built-in palette wasn’t quite right. Last week I ripped out my tmux status bar and replaced it with a shell script. Three tools, three text files, talking to each other. Compare that to most commercial software, where customization means a settings panel with a handful of toggles and maybe a theme picker. The developer decided what you need and sealed the rest shut. Config-driven software works the other way around: here’s the core, here are the knobs, do what you want. The developer builds a foundation and gets out of the way.
LLMs are making this gap matter a lot more. The old barrier to customization was time: reading docs, trial and error, debugging side effects when something broke. Now you describe what you want in plain English and get working config back in a few minutes. The bottleneck shifts from “do you have the hours to figure this out” to “can it be configured at all.”
This is the game-mods model applied to everyday software. Vendors build the engine; communities reshape everything else. Someone’s email client could look and behave nothing like yours, same base underneath. A notes app becomes a project tracker or a publishing tool depending on which community mod you pull in. The whole interface is on the table, not just a plugin slot. Software stops being a product you use as-is and becomes a starting point.
What happens to locked-down software when the open alternatives take five minutes to configure?