Idea principal

Actualizar un artefacto de producto siempre consistió en corregir su versión anterior: se reabre la especificación escrita hace dieciocho meses, se buscan los párrafos afectados por la última entrega y se reescriben. El documento hereda entonces todo lo que no se ha releído — comportamientos retirados desde entonces, pantallas que ya no existen, hipótesis desmentidas por el desarrollo.

La otra vía consiste en tirar la versión anterior y regenerar el artefacto desde el repositorio: la documentación de soporte después de una entrega, el changelog, la especificación funcional del estado actual. El documento ya no lleva la acumulación de sus versiones, lleva una fecha de lectura del código.

La ganancia no es la velocidad de escritura. Es que el artefacto deja de ser un stock que hay que mantener para convertirse en una proyección que se relanza. Una proyección no diverge: está caducada o está rehecha.

La regla se aplica dentro de un mismo documento en cuanto mezcla dos materias. En una ficha de objeto de producto, el cuerpo describe la realidad tal como está en el código: se tira y se rehace sin perder nada. Las desviaciones entre esa realidad y lo que se querría vienen, en cambio, de una decisión humana, no se encuentran en ninguna parte si se pierden y se colocan por tanto en un bloque separado que ninguna regeneración toca. Lo que se regenera y lo que se mantiene solo conviven a condición de estar visiblemente separados.

Capa aportada por "Escribí la ontología de un producto. Tres veces creí haber terminado." (2026-08-11).

Capa aportada por "Cuatro días de vibe coding…" (2026-07-28). La inversión no afecta solo a la actualización de un documento existente: toca también el momento en que se escribe el primer documento. En una herramienta interna construida directamente por un perfil de producto, no hubo especificación previa — la persona se lanzó, construyó, enseñó, recibió peticiones de evolución e iteró. El comportamiento emergió en el producto, y la documentación funcional se generó después desde el código. La secuencia habitual se invierte entonces por completo: no se regenera un documento por no haber podido mantenerlo, se genera porque nunca se escribió antes.

Por qué es importante

Es lo que vuelve tratable sin disciplina la distancia entre el producto y su documentación. Mientras se actualiza, la divergencia se acumula en cada iteración saltada; en cuanto se regenera, una iteración saltada no deja ninguna deuda — la regeneración siguiente parte del mismo sitio.

También cambia lo que se archiva: se vuelve más útil conservar la capacidad de regenerar que la última versión producida.

Matices y límites

El código no lleva la intención. Una especificación regenerada dice lo que el producto hace, no por qué se eligió ese comportamiento ni qué se descartó — y esa pérdida es invisible, ya que el documento parece completo.

La regeneración tampoco es gratuita: exige una relectura, y una salida falsa que parece correcta cuesta más cara que un documento manifiestamente caducado.

Preguntas abiertas

• ¿Qué parte de un artefacto debe seguir escribiéndose a mano porque ninguna regeneración puede recuperarla?