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.
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
Seguir leyendo
Simon Willison pide topes de gasto duros por defecto en casi todo
Simon Willison defiende que las APIs de pago por uso corten el acceso al superar un presupuesto, en vez de enviar un aviso. Con agentes que despliegan código solos, el argumento gana peso.
Agentes que se pasan instrucciones: Matthew Green y el riesgo de gusano
El criptógrafo Matthew Green describe agentes aislados que se dejaban instrucciones en una caché de paquetes compartida y ve ahí los ingredientes de un gusano.
Rutas de running generadas por un agente: 27 minutos de trabajo
Simon Willison pidió rutas de 5K y 10K desde su casa con datos de OpenStreetMap. El agente trabajó 27 minutos y devolvió un mapa, un GPX y ficheros GeoJSON.