During the 2000s and 2010s, I was deep into XML and associated standards. In my defence, it was primarily the document-related side of things: mixed content, schema validation, metadata and transformations. I've never really looked into the whole WS-* side of things, which already seemed bloated and excessive at the time.
In the 2020s, XML quietly disappeared. I stopped bothering to reinstall my paid copy of Oxygen XML on new computers. JSON was enough. Other topics came up. It just faded into the background. But when I recently realised how much more expensive storage had become, I decided to do some housecleaning instead of buying a new drive. And this is when I was confronted again by my XML history.
Around 2015, the organisation I was working for had to do a schema conversion of 250K XML documents that were quite varied in quality. All of them were schema-valid, but different authors had different ideas about the meaning of elements. It didn't help that tools of different quality were used. For most authors, the aim was to get documents published in a decent enough format, and once a document was valid they would go on with the next one.
We tried to do the right thing by focusing on getting the worst excesses out of the source documents before converting them with an insanely complicated XSLT pipeline. To this day, I think this was good advice: cleanup before convert. But it was a lot of manual work. It took a dedicated team months and they really struggled with the conversion. I wanted to help but I was also doing other things, and it sort of kept going.
Looking back, two things made it so hard. The first was the lack of a good management tool. Remember, this was before Git was big, in a government agency where Windows Explorer ruled and it was already a fight to get any XML tool installed, let alone ask for a tailor-made database. So it was a bit of a struggle to organise the work, recognise and manage issues, and build up knowledge about the collection. This didn't just make the work slower; it also hampered the development of the conversion XSLT, which was done by a specialist (not the conversion operators). The three people doing the conversion were located in one room, which helped a lot, but apart from that the scaffolding around the work wasn't great.
Another complication was the need for manual inspection. Given the type of information, there was a premium on not changing the text or its meaning. A lot of this could have been checked by running small scripts, but not many people had the ability to write them. The path of least resistance was to literally browse through all documents, even if this made the project last months.
These two issues influenced the project approach. There was a sort of waterfall approach, where analysis led to a massive XSLT which would run over the entire collection. But then errors were discovered in individual documents which could be corrected manually or lead to changes in the XSLT. In some cases, those changes in XSLT produced unwanted side effects, further complicating the state of the content collection.
Now enter 2026. While doing my hard drive cleanup, I came across multiple copies of the full dataset, frozen exactly as it was left in 2015. Hundreds of megabytes of public data. I was tempted to delete everything and free up a few GB of space, but then the thought crossed my mind: "would this conversion process be different in 2026, now that we have access to powerful LLM technology?"
Not surprisingly, the answer is "yes, totally".
But it is not as easy as it seems. At this point in time, we cannot just feed a source XML document to an LLM and tell it to convert to the output format. It will try and get surprisingly far, but almost is not good enough when the text carries (legal) weight.
What we can do is use LLMs for specific, smaller tasks.
First of all, LLMs can be used to quickly build and customise a workbench, an environment where the process of improving and transforming XML documents is supported. This capability should not be underestimated. Instead of fiddling around with fragile tools or spending a lot of time installing a tool that does 80% of what is necessary, we can build a tailor-made workbench that is a 100% match. The key is to design the foundations properly. Then, we can modify the workbench on the fly with LLM assistants (like Claude Code).
Second, we can use LLMs to analyse and scan the XML documents themselves. The key here is to ask the right questions. In general, the more specific the question, the more likely that the answer is useful. The aim is not to let LLMs change the content, but to use them to filter out interesting cases for further analysis by human operators. There are two general areas. We can use an LLM to ask about an existing collection, or we can ask the LLM whether a particular change that was just produced is any good. This capability was not available in 2015, at any price.
Third, LLMs can help the operators directly. Drafting a command, working out an XPath, fixing an XSLT that will not run, etc. This alone would have been a major boon to the team in 2015. It would have empowered the operators and reduced the dependence on specialists. The XML world was always a bit of an isolated community, and LLMs are a way to democratise niche knowledge.
The potential of LLMs is real, but it does not come for free. It is quite a challenge to design a system around LLMs, using their strengths, mitigating their weaknesses and preventing their hallucinations. And it has to work at scale. It is easy to vibecode something that works for 10 documents, but what happens with a million? How do you keep track of changes? Can you roll back earlier modifications? How can you implement a provenance trail? How do you prevent sensitive content from leaking out? How do you keep costs under control?
But if you do this right, the payoff is not just faster and cheaper. The promise of LLMs is that the whole approach to XML conversions and upcycling will change. Instead of one big bang XSLT, conversion and upcycling become a much more granular process. The thing is: LLMs perform better when you ask them lots of detailed questions. If a relatively small issue is described properly, it turns out LLMs can perform really well. This means the whole architecture is more about managing lots of little changes, each of which is signed off individually and applied to create new document states. Revoking changes and reapplying transforms become fundamental. In this world, there is no panic when a new issue pops up late in the game. The key deliverable becomes the collection of issues and their accompanying solutions. LLMs make the technical part cheap; what is left is the knowledge.
I didn't delete the XML files. I built the workbench instead, and it works better than I could have hoped.
For someone who is an average programmer at best, it is genuinely liberating to be able to build out a vision and test it on real content. This is not the kind of vibecoding that people brag about. It was an interactive process, building on twenty years of experience. Best of all, it was a good excuse to explore different LLMs and the best way to interact with them in the context of XML processing.
It has held up well across my 250K-document collection, so it's reasonably battle-tested by now, and I'm curious how it does on other people's messy collections. If you've got one, I'd genuinely like to hear about it.
And here's the part I like best, because it closes the loop on everything above. You don't have to take the tool on faith. You can ask your LLM to look at the code: to check that it does nothing it shouldn't, to understand how it works, and to bend it to your own documents. The workbench was never meant to be a black box, and in 2026 it doesn't have to be one. In the new LLM world, you don't just install a tool, you make it yours in record time.
Do you hold a large XML collection, and have good reasons to put AI to work on it, but no safe way to begin? Here is how we would work together. It starts with an hour online, no charge: we look at your own documents, and you see the system running on them.