Regenerating Software Architecture Descriptions

Reverse engineering plus constrained LLM abstraction can produce a usable baseline for architecture documentation, even if it cannot replace human interpretation.

Type: Article
Audience: Technical writers, platform teams, engineers maintaining architecture-level documentation
Theme: software architecture, abstraction, system descriptions

Why this matters

Architecture docs tend to drift for a familiar reason: systems evolve continuously, while architecture descriptions are usually updated manually and infrequently.

A recent paper asks whether software architecture descriptions can be derived from the implementation itself rather than rebuilt manually from scratch every time the system changes.

What changes

The authors focus on Software Architecture Descriptions, which are often missing, incomplete, or outdated. Their solution is deliberately constrained. They combine reverse engineering with an LLM, but the model is not asked to infer architecture from raw code.

Reverse engineering first extracts a structural representation of the system. The LLM is then used to abstract that representation by identifying architecturally significant elements and producing a dual-view architecture description: an abstract component diagram plus state-machine views of key behaviors.

That division matters. Reverse engineering provides factual grounding. The LLM performs abstraction and summarization on structured inputs rather than inventing architecture from scratch.

Implications for technical writing

For technical writers working on SDKs, platforms, and complex systems, the implication is not that architecture docs can be fully automated. It is that baseline architecture descriptions can be regenerated from implementation artifacts, while human effort shifts toward explaining intent, tradeoffs, and design rationale that are not present in the code.

The evaluation results are mixed in a useful way. The approach works better for smaller and moderately complex components, while larger components introduce inconsistencies. That makes the paper valuable because it treats architecture docs as a system artifact with observable failure modes.

Source

• Hatahet, Knieke, and Rausch, 2025