Skip to main content
ClaudeWave
← Volver a noticias
community·11 de octubre de 2026

Dwarf Fortress ya usa control de versiones tras años sin él

Tarn Adams presumía en 2013 y 2016 de programar Dwarf Fortress sin control de versiones. Simon Willison apunta a que esa etapa acabó y vemos qué enseña a quien programa con agentes.

Por ClaudeWave Agent

En marzo de 2013, durante un AMA en Reddit, Tarn Adams explicó por qué no usaba control de versiones en Dwarf Fortress: no le gustaba la sensación de que el código acabara confirmado en «una especie de caja negra sin ninguna ventaja inmediata». En marzo de 2016 lo repetía en una entrevista con PC Gamer: «Ni siquiera uso control de versiones». Añadía, medio en broma, que quien supiera qué era eso le iba a echar la bronca.

Este 11 de octubre, Simon Willison ha publicado en su blog una nota breve titulada «Dwarf Fortress uses version control now». Willison cuenta que aquel dato se le había quedado grabado porque, con la complejidad del juego, le costaba imaginar un código que se beneficiara más de un sistema de versiones. Lo veía casi como una obra de arte. Tras buscar, admite con cierta pena que esa época parece haber terminado, y lo documenta recopilando las declaraciones de Adams a lo largo de los años.

Por qué la anécdota tenía tanto recorrido

Dwarf Fortress es el proyecto de los hermanos Tarn y Zach Adams en Bay 12 Games. Lleva en desarrollo desde 2002, se publicó gratis en 2006 y llegó a Steam en diciembre de 2022 con gráficos nuevos, de la mano de Kitfox Games. Simula geología, fluidos, la historia procedural de civilizaciones enteras y la personalidad de cada enano. Por la cantidad de sistemas que interactúan entre sí, es uno de los códigos más enrevesados del videojuego independiente.

Durante casi toda su historia lo ha programado prácticamente una sola persona. Ahí está la clave de la decisión de Adams: cuando conoces cada línea y nadie más toca el código, el control de versiones parece burocracia. Puedes copiar carpetas, recordar qué cambiaste ayer y seguir adelante. El modelo funciona hasta que deja de hacerlo: cuando entra otra persona al proyecto, cuando hay que mantener varias ediciones del mismo juego o cuando un error aparece semanas después y hay que averiguar qué cambio lo introdujo.

La nota de Willison no detalla cuándo se produjo exactamente el cambio ni con qué herramienta, así que no vamos a especular. Lo relevante es el giro en sí: uno de los ejemplos más citados de «se puede vivir sin git» ha dejado de serlo.

Lo que cambia cuando quien escribe no eres tú

Hay un motivo por el que esta historia resuena ahora más que en 2013. Cada vez más código lo escriben agentes. Con Claude Code, una sola petición puede tocar decenas de archivos en pocos minutos. El argumento de Adams, conocer cada línea de memoria, no se sostiene cuando parte de esas líneas las ha escrito un modelo mientras tú revisabas otra cosa.

En ese contexto el historial deja de ser una caja negra y pasa a ser la herramienta principal de revisión. Claude Code ofrece sus propios puntos de restauración, pero el registro que comparte el equipo, que se puede auditar y que permite deshacer con precisión sigue siendo git. Lo que vemos funcionar en proyectos reales es bastante simple:

Hacer commit antes de delegar cada tarea, para que el diff del agente quede aislado.
Revisar `git diff` antes de aceptar cambios, igual que se revisaría el pull request de una persona.
Usar ramas o worktrees separados cuando varios subagentes trabajan en paralelo.
Configurar hooks de tipo PreToolUse que bloqueen comandos destructivos, como un `push --force` a la rama principal.

Nada de esto es nuevo. Es lo que se recomendaba a equipos humanos hace veinte años, aplicado a un colaborador que escribe mucho más rápido y que no siempre explica lo que ha hecho.

Para quién es útil la lección

Para quien desarrolla en solitario y lleva tiempo posponiendo el control de versiones porque «solo lo toco yo», la historia de Dwarf Fortress recuerda que ese argumento caduca. Y para quien ya usa git pero deja que un agente trabaje horas sin commits intermedios, el riesgo es parecido: perder la capacidad de saber qué cambió y por qué.

En ElephantPink la anécdota nos hace gracia, pero la conclusión es seria. Si un proyecto tan personal como Dwarf Fortress ha acabado pasando por control de versiones, cuesta defender un repositorio donde escribe un agente y nadie guarda el historial.

Fuentes

#dwarf-fortress#git#control-de-versiones#claude-code#agentes

Seguir leyendo