Dwarf Fortress now uses version control after years without it

In March 2013, during a Reddit AMA, Tarn Adams explained why he didn't use version control for Dwarf Fortress: he didn't like the feeling of having the code get committed into “a black box thingy with no immediate upside”. In March 2016 he said it again in an interview with PC Gamer: “I don't even use version control.” He added, half joking, that anyone who knew what that was would yell at him.

On 11 October, Simon Willison published a short note on his blog titled “Dwarf Fortress uses version control now”. Willison explains that the fact had stuck in his head because, given the game's complexity, he struggled to imagine a codebase that would benefit more from version control. He saw it almost as a work of art. After looking into it, he admits with some sadness that the era appears to be over, and he documents it by collecting Adams's statements over the years.

Why the anecdote had such staying power

Dwarf Fortress is the project of brothers Tarn and Zach Adams at Bay 12 Games. It has been in development since 2002, was released for free in 2006 and arrived on Steam in December 2022 with new graphics, published by Kitfox Games. It simulates geology, fluids, the procedural history of entire civilisations and the personality of every dwarf. Given the number of systems interacting with each other, it is one of the most convoluted codebases in indie games.

For almost all of its history it has been programmed by essentially one person. That is the key to Adams's decision: when you know every line and nobody else touches the code, version control feels like bureaucracy. You can copy folders, remember what you changed yesterday and keep going. The model works until it doesn't: when another person joins the project, when several editions of the same game need maintaining, or when a bug shows up weeks later and you need to find out which change introduced it.

Willison's note does not say exactly when the switch happened or which tool is involved, so we won't speculate. What matters is the shift itself: one of the most cited examples of “you can live without git” no longer is one.

What changes when you are not the one writing

There is a reason this story resonates more now than in 2013. More and more code is written by agents. With Claude Code, a single request can touch dozens of files in a few minutes. Adams's argument, knowing every line by heart, doesn't hold when some of those lines were written by a model while you were reviewing something else.

In that context, history stops being a black box and becomes the main review tool. Claude Code offers its own restore points, but the record the team shares, that can be audited and that allows precise rollbacks is still git. What we see working in real projects is fairly simple:

Commit before delegating each task, so the agent's diff stays isolated.
Review `git diff` before accepting changes, just as you would review a person's pull request.
Use separate branches or worktrees when several subagents work in parallel.
Set up PreToolUse hooks that block destructive commands, such as a `push --force` to the main branch.

None of this is new. It is what teams of humans were advised to do twenty years ago, applied to a collaborator that writes much faster and doesn't always explain what it has done.

Who the lesson is for

For solo developers who have been putting off version control because “only I touch it”, the Dwarf Fortress story is a reminder that the argument expires. And for those who already use git but let an agent work for hours without intermediate commits, the risk is similar: losing the ability to know what changed and why.

At ElephantPink we find the anecdote amusing, but the conclusion is serious. If a project as personal as Dwarf Fortress has ended up under version control, it is hard to defend a repository where an agent writes code and nobody keeps the history.