UDE Blog (English)

Programming Without Knowing the Language: How AI Fired Doxygen

Thu, 06 Aug 2026 00:00:00 GMT

In the last part, we left off after throwing Doxygen's HTML output straight into the trash can. The plan to "quickly tweak the styles" completely failed because it is impossible to adapt a structure of nested tables straight out of the nineties to modern design. The idea for our second prototype sounded solid: disable HTML generation entirely, grab the raw structured XML from Doxygen, and write a proper parser for it.

For our working language, just like last time, we chose Python. It is perfect for building utilities, text processing, and automating routine tasks. Besides, the entire modern ecosystem around artificial intelligence is built on it. The logic was simple: if we want to actively use neural networks to help us write code, we might as well write in the language they know best.

It's time to reveal a little secret I intentionally left out of the first part: I don't know Python. I more or less understand someone else's code, but I have never written anything in it myself.

An Architect Who Cannot Code

This was a pure experiment in "programming without knowing the language". I decided to act as the system architect and task manager. The AI was supposed to do all the technical work: write the actual code, refactor functions, and put everything together.

At first, things went suspiciously smoothly. We were drafting the logic to parse giant XML files. I would open the generated Doxygen file, see the nodes, classes, and method parameters in there, and just type into the chat: "Find all elements with the right tags, extract the type, name, and description, and then dump it into a JSON." Thanks to the AI's direct access to the terminal, I didn't even have to copy the code by hand. The neural network wrote the scripts itself, ran them immediately, and provided the final result.

The file filled up with functions, the script grew. I felt like we were building a great system. I didn't even read the code — why bother when I can already see the documentation assembling better and better? This continued until one conversation completely changed the course of development.

When AI Suddenly Asked for a Compiler

At one point, we were discussing the portability of our engine (we had already started calling it UDE) to other platforms. I wanted to make sure the parser would run for any developer on any operating system without complex additional setup.

The AI gave a casual response: "Sure, there shouldn't be any problems. Just for full portability, we'll need to configure the download of clang during the package installation."

I stared at the monitor in utter confusion. What clang? We are parsing XML documentation for a Python wrapper. What does a C compiler have to do with this? I flat out asked the neural network if it had lost its mind.

The AI immediately apologized and gave a new phrasing: "I apologize, I meant the tree-sitter library. We will need to compile its bindings."

The Insight of Losing Control

And then it hit me: the AI was no longer parsing Doxygen's XML. It had gotten tired of it.

During our long architectural discussions, the neural network quietly plugged in an Abstract Syntax Tree (AST) parser without telling me. The AI decided on its own that reading the original C++ and Python source code directly via tree-sitter was much more reliable than messing with the hacky XML output of a third-party utility. It simply excluded Doxygen from the loop while I thought we were still parsing tags.

Was the code it wrote any good? I have no idea, because I completely lack the ability to write Python and evaluate architectural decisions. The algorithm might have turned out to be stunningly optimized and elegant, or it could be an unstable pile of hacks functioning purely by a lucky coincidence.

The problem was an absolute loss of control. If the AI quietly changes the architecture in the background and pulls in heavy parsing libraries while you can't even read its code — the project is doomed. It becomes a classic "black box". Any minor bug will force you to spend hours interrogating the neural network for the causes of the failure. The same goes for atypical comments in the source files.

This incident gave us a crucial breakthrough. We realized that AI is genuinely capable of writing its own direct parsers for any programming language, extracting class structures and parameters straight from live code. We no longer need third-party utilities.

However, for such generated code to run stably, it needs to be strictly controlled. We needed a rigorous set of automated checks. A system that would guarantee the parser's functionality regardless of whether I understand the written code or not.

So we threw our second, perfectly working prototype into the trash. And we started over, for the third time. But this time under entirely different rules — with testing at every single step. I will talk about this in the next part.

Also read us:

How Not to Build Documentation: The Tale of an HTML Parser

Mon, 03 Aug 2026 00:00:00 GMT

We sat down to write our own documentation engine purely out of desperation. Originally, no one planned to develop the massive Universal Documentation Engine (UDE). We had a simple, utilitarian task — to document a fresh Python wrapper. As usual, the most monstrous workarounds always start with a harmless script of a few lines.

The Sudden Python

Our core SDK is written in C++. To make it accessible from other languages, wrappers are created. It was finally Python's turn. The developers delivered the finished API, which now needed to be published on the documentation portal.

We had been relying on Doc-o-Matic for years. It was an old, heavy, battle-tested generator. There was just one problem: it completely refused to understand Python code. The software hadn't been updated for years, tech support was long dead, so hoping for a patch was out of the question. We have strict corporate requirements for the portal's design. None of the standard generators met them, and documenting the code was an absolute necessity.

We looked into Doxygen. The utility can extract structure from virtually anything. The catch is that its default HTML output looks like a greeting from the nineties. That's when a brilliant idea struck us.

"Let's Just Tweak the Styles a Bit"

"Doxygen generates ready-made pages. Let's just unleash a script on it, swap out a couple of CSS classes, and everything will be done in a few days."

It turned out we had catastrophically underestimated the scale of the problem. The plan was simple: intercept the output, inject it into our structure, and go drink coffee. But the deeper we dug into the generated DOM, the worse it got. Doxygen absolutely ignored modern layout practices (instead of clean tags, we were shoveling through piles of tables and inline styles).

It was too late to retreat. The prototype was needed yesterday, so we had to grit our teeth and finish the script. It gradually became overgrown with dozens of regular expressions, becoming increasingly fragile.

The Sidebar and JS Necromancy

The wildest part began at the navigation stage. We have a strict UI rule in the company: absolutely all pages must sit in the left sidebar (so the developer sees the whole picture). Doxygen doesn't agree with this approach. It builds the menu dynamically from deeply nested arrays smeared across several generated JavaScript files.

AI and I had to physically read these JS files as plain text. We parsed the arrays, extracted the class hierarchy from them, and manually rebuilt the HTML tree of the page. This was starting to feel like digital necromancy.

Measure Twice, Parse Once

The prototype eventually fired up. On the outside, everything looked decent and up to standards. But on the inside, our script was a house of cards held together by duct tape. A minor Doxygen update comes out — and the entire portal falls apart with errors.

We wasted a ton of time trying to cut a corner. Instead, we could have calmly designed and implemented a proper architecture. We should have immediately extracted the abstract syntax tree, or at least just parsed the clean XML from Doxygen.

It became obvious: we needed our own independent engine. We hooked up the AI again so it could quickly throw together a proper parser to read Doxygen's XML. But everything went wrong there too. I'll tell you what happens when you leave an AI unsupervised in the next part.

Also read us:

UDE: From Source Code to Quality Documentation

Wed, 22 Jul 2026 00:00:00 GMT

1. The Starting Point: Source Code and Comments

The foundation of any quality API documentation is the comments in the source code. In large projects (C++, for example), they are the single source of truth. Without them, automatic documentation generation simply isn't possible.

The only question is how to turn those comments into a modern, convenient, fast site for developers.

2. How This Is Solved Today -- and Where the System Breaks

The most popular tool for C++ is Doxygen. However, its native output format (HTML or XML) doesn't fit modern static site generators (SSGs) like Hugo, Docusaurus, or VitePress, which expect Markdown as input.

The Doxygen + DoxyBook2 + Hugo Stack

To work around this limitation, intermediate converters are often used: Doxygen generates XML → DoxyBook2 converts the XML to Markdown → Hugo builds the site.

This works, but it has serious limitations:

No scalability. The converter reads the entire XML graph into memory at once. At the scale of an SDK with tens of thousands of classes and methods, this process runs into memory limits and unreasonably long processing times.
Hard to customize. Configuring the output for several styling formats at once is a difficult task, since these tools weren't designed for high flexibility.

3. UDE's Solution: A Unified Pipeline

UDE fully rebuilds the process, removing unnecessary conversion stages and optimizing how data is handled.

UDE's architecture is built on a clear separation of stages:

Collector extracts data directly from the source code.
Parser translates it into a normalized, language-neutral model -- an IR (Intermediate Representation).
Renderer instantly assembles Markdown/HTML in whatever format the target SSG understands, with no intermediate XML crutches.

The advantages of this approach are clear: there's no extra conversion step, and from a single source (the IR) you can render documentation in any format or style you need.

4. Speed and Predictability

For large projects, build time is critical. UDE solves this with incremental caching.

Instead of loading the entire entity graph every time, UDE recomputes only what has actually changed.

Cross-platform. The pipeline works identically, locally on Windows and in CI on Linux.
Docs-as-code. The configuration of what to document is versioned alongside the code and built in the same CI.

5. UDE and Hand-Written Guides (DevGuide)

API reference generated from code answers the question "how are the functions and classes structured." But it can't tell you "in what order to call them to solve a specific business problem." That's what DevGuides are for -- manually written articles and tutorials.

UDE doesn't try to replace that manual work. Instead, it provides seamless integration: the generated API reference stays complete and always up to date, living naturally alongside hand-written guides on the pages of modern SSGs.

Also read us: