¿Merece la pena conservar las specs de cambios pasados? El archivo de cambios en OpenSpec
Guardar los artefactos de cada cambio (diseño, propuesta, tareas) crea una fuente de verdad que el agente puede recuperar sin bucear en el historial de Git. Pros, contras y cómo usarlo sin inflar el contexto.
La pregunta real
Es un debate habitual en equipos que empiezan con Spec-Driven Development: una vez que una funcionalidad está implementada y en producción, ¿tiene sentido seguir guardando la spec con la que se hizo? El código ya está ahí, el pull request también. ¿No es duplicar información?
En frameworks como OpenSpec la respuesta por defecto es conservarlo todo. Pero lo interesante es entender por qué y qué implica.
Qué se guarda y por qué
El último paso del flujo, después de verificar, es archivar el cambio en un sitio conocido y fechado. Lo que se conserva no es una copia del código, sino los artefactos relevantes: el diseño, la propuesta y la lista de tareas. Es decir, qué se hizo, por qué, en qué orden y con qué tareas.
| Fuente | A favor | En contra |
|---|---|---|
| Historial de Git / pull requests | Siempre existe, sin esfuerzo extra | El agente tiene que reconstruir la intención a partir de diffs y mensajes, y depende de que los PR estén bien referenciados a tickets |
| Archivo de cambios SDD | Intención explícita: qué se hizo, en qué orden y con qué tareas | Crece con el tiempo y hay que decidir qué recuperar en cada tarea |
Un ejemplo concreto
Supón que llega un ticket que modifica el proceso de alta de candidatos implementado hace dos meses. Sin archivo, el agente tendría que recorrer el historial de Git, adivinar qué commits pertenecen a esa funcionalidad y reconstruir las decisiones a partir de los diffs. Con el archivo, el paso de exploración localiza el cambio fechado correspondiente, recupera su diseño y sus tareas, y los incorpora al contexto de la tarea actual.
Además, los cambios archivados sirven como patrón: una funcionalidad nueva y parecida puede desarrollarse siguiendo la misma estructura que otra ya hecha, en lugar de partir de cero.
Implicaciones prácticas
Conservar el archivo no significa cargarlo entero. Si en cada interacción se inyectara todo el histórico de specs, el contexto se llenaría de información irrelevante. El archivo es contexto "alcanzable pero no activo": está disponible, se sabe dónde está y solo se recupera cuando la exploración lo necesita.
El coste real es de mantenimiento: el archivo crece, y conviene que su estructura (nombres fechados, artefactos homogéneos) sea consistente para que el agente pueda encontrar lo que busca sin leerlo todo. Es la misma disciplina de "dejar siempre la información en el mismo sitio" que sostiene toda la metodología.
Resumen rápido
- Archivar cada cambio (diseño, propuesta, tareas) da al agente una fuente de verdad explícita, sin reconstruirla desde Git.
- El archivo es contexto alcanzable, no activo: solo se recupera lo que la exploración de cada ticket necesita.
- Una estructura consistente y fechada es lo que hace útil el archivo cuando crece.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.