Software documentation, derived from the code

For business executives

dev-doc turns a repository into the documentation an organisation is expected to have but rarely does — and it does so for the systems where that gap is most expensive.

• Legacy estates are a first-class target. COBOL, PL/SQL, T-SQL and decades-old Java or C code are documented with the same depth as a modern web stack — the estates consultants price highest and staff least willingly.
• Compliance evidence as a by-product. A software bill of materials in both formats the German BSI TR-03183-2 guideline accepts (CycloneDX 1.6, SPDX 3.0.1), a completeness report against that guideline, a NIS2 / Cyber Resilience Act supplier fact sheet, and a release-to-release record of what changed in the component list.
• Due-diligence ready. A buyer, auditor or new CTO reads the architecture, module map and technology inventory without opening a source file — or receives the whole set as one package, including an arc42 architecture document.
• Human approval survives regeneration. A section a reviewer has approved or edited is preserved when the code changes and the rest is refreshed.
• Separates what ships from what does not. Tests, examples and benchmarks are documented as non-deployed applications, so an inventory describes the product actually delivered.

For technical executives

The engineering priority is not volume of text but correctness of what is written; most of the work goes into proving a statement before it is published.

• Facts first, prose second. Modules, deliverables, entry points, declared dependencies, deployment services and call relationships are read from the code and build files before any text is generated — and enforced afterwards, not merely requested.
• A full C4 model, levels 1 to 4. Context, containers, components and code, with relationships grounded in the actual call graph, interfaces marked as contracts, and oversized diagrams that open as a navigable map instead of an unreadable wall.
• An independent audit after every run. A deterministic check compares each generated document against the source tree — invented identifiers, missing files, wrong signatures, misplaced components — and records what is new and what was resolved.
• Language-agnostic by design. Mainstream, legacy and niche languages are read alike, and ambiguous file types are decided by their content, not their extension.
• Defence and safety formats. An AQAP 2210 software design description with every inferred statement marked for human review.
• Read-only. Nothing is installed alongside the code and nothing is written back to the repository; a tracked repository is refreshed from its latest commit on request.

For business executives

Software organisations are carrying two debts at once: the code nobody remembers writing (COBOL, RPG, ten-year-old Java services whose authors have retired) and the code nobody wrote at all, generated by AI assistants faster than any human can review or document it. Both debts land in the same place — a company that owns systems it cannot explain, to its own new hires, to an auditor, to a buyer during due diligence, or to a regulator. That pressure is becoming statutory rather than cultural: the EU Cyber Resilience Act and NIS2, and the safety standards beneath them (IEC 62443-4-1, IEC 62304, EN 50128, AQAP 2210 in defence), all require evidence of a documented development lifecycle and a component inventory, not merely working software. dev-doc produces that evidence as a by-product of understanding the code: a software bill of materials, a supplier fact sheet, a completeness report against the German BSI TR-03183-2 guideline, and a release-to-release record of what changed in the component list. The commercial argument is simple: documentation has always been the first thing cut and the most expensive thing to recreate; automating it converts a recurring, deferred cost into a predictable one, and does so for legacy estates no consultant will price cheaply.

For technical executives

The bottleneck for AI coding agents is not model capability, it is context. Every agent session today begins by re-deriving a codebase's architecture from raw source — expensively, partially, and differently each time — which is why agents confidently violate boundaries that exist only in a senior engineer's head. What they need is a durable, machine-readable model of the system: which modules exist and what they are for, how they depend on each other, what the public surface and data model are, and which design decisions were deliberate rather than accidental. That is precisely what dev-doc produces as structured, addressable content — module map, C4 levels 1 through 4, API surface, data model, architecture decision records — rather than as prose locked in a wiki. Two properties make it agent-grade rather than merely human-readable: the description is grounded in facts read from the code before anything is written up, and the generated output is checked against speculation, because documentation that hallucinates is worse than none once an agent acts on it. As AI-generated code volume rises, the ratio of code to comprehension worsens every quarter; the systems that stay maintainable will be those that keep a continuously refreshed, verifiable description of themselves.