Most organisations treat a document as an endpoint. Somebody makes it, somebody approves it, it becomes a PDF, and from then on it is a thing rather than a process.
What changes if you treat a document as code?
The same things that happen to code. It gets a source of truth, a build step, a version, and the ability to be produced again in a different shape without anyone reopening the original.
That sounds abstract until a contract has to exist in two languages, three formats and four versions, and version four of the German PDF turns out to have been edited by hand.
Three places this became concrete
A twelve-page magazine feature, end to end. Layout, production, delivery. Doing that once shows you where the manual steps are. Doing it against a deadline shows you which of them break.
IDML to DOCX in Node. InDesign's exchange format is XML, which means a layout is a document tree, and a tree can be transformed. Once that pipeline exists, a designed layout and an editable text version stop being two separate pieces of work.
A framework agreement repaired at XML level. The file would not open cleanly. The choice was rebuild it or open the underlying markup and fix what was actually broken. The second took an hour and kept the version history. The first would have taken a day and lost it.
Why this matters beyond documents
Legal and marketing produce the artefacts a company is judged on, and both work in tools built around the single-file assumption. The result is a version problem disguised as a naming problem, solved with dates in filenames.
Treating those artefacts as build output removes an entire category of error. Not by adding discipline, but by removing the step where discipline was required.
The skill is not InDesign or XML. It is noticing that a thing everyone calls a file has structure, and that structure can be operated on.