I take enterprise AI from an ambiguous business problem to a tested, governed system.

Context

The obvious approach is to paste source files into a chat model and ask for documentation. It fails at estate scale for three separate reasons, and it is worth separating them: the code does not fit in a context window, the model has no ground truth to check itself against, and nothing about the process is repeatable when the code changes next week.

So the interesting question was never "which model." It was "what does the model need to be handed."

A Roslyn analyzer walks each solution and emits structured metadata as JSON: types, members, signatures, inheritance, call relationships, dependency edges, entry points, attributes. That pass is deterministic. Run it twice on the same commit and you get the same file.

Generation then works from that structured representation rather than from raw repository sprawl, one unit at a time, against prompt templates written per document type. The whole thing runs as an Azure DevOps pipeline step, so documentation is produced from the current commit instead of from someone's memory of the current commit.

The model is not the source of the parameter count. The analyzer is, and its output is a diffable artifact — so when the prose and the code disagree, the disagreement is findable rather than a matter of opinion. Facts and language are produced by different components, which means they fail differently and can be checked differently.

Three consequences fall out of that split. The expensive part becomes cacheable, because metadata only changes when code changes, which makes regeneration incremental rather than a full re-run. When output is wrong you can tell which stage was wrong — extraction or prompt — instead of re-rolling the whole thing and hoping. And the pipeline gets a natural place to hang review, because structured metadata is diffable in a way prose is not.

A single-stage "read the repository and explain it" design gives you none of those seams. It gives you one opaque step whose only debugging tool is asking again.

An external technical review of the architecture found no major red flags and considered the approach sound. The impact figures below were built during the POC from hour counts and rates. They are estimates used to size the opportunity, and they have not been audited against realized spend.

It remains a POC with a pilot-oriented architecture. What is left is the unglamorous part: coverage across repositories that do not look alike, a review workflow for generated output, and a named owner for the pipeline.

The analyzer is the expensive component and it is language-specific. It buys reliability at the cost of portability: a Python or COBOL estate needs a new extractor before any of this works. I would make that trade again for a homogeneous .NET estate. I would not make it for a polyglot one without first checking whether the documentation problem was actually worth an extractor per language.

Context

The work is slow, it is done under deadline, and two experienced reviewers do not always produce the same numbers. That combination usually means there is real value in automation — and it is also exactly the combination that makes people reach for a language model and ask it to read the drawings.

I ran the discovery with the people who actually do the work, wrote the requirements, evaluated the GIS path, built the technical POC, and put together the validation plan and the business-facing material that went with it.

The split is the whole point of the design. Geometry is computed, not inferred: ArcGIS and ArcPy do the spatial work — slopes, areas, lengths, buffers, intersections against site layers — and produce numbers that can be recomputed and defended.

The language model orchestrates around that. It reads the plans and specifications, decides which control measures are in scope, assembles the supporting evidence, and emits structured output where every finding carries a citation back to the document or the computation it came from. Where a required input is missing, the output says the input is missing. It does not fill the gap.

Language models are weak at metric truth from drawings and strong at reasoning over heterogeneous evidence. Ask one to eyeball a linear footage from a plan sheet and you get a confident number with no provenance — which is precisely the failure a quantity estimate cannot survive, because the first thing a reviewer asks is where the number came from.

So the constraint I designed to was simple to state and expensive to honor: every number in the output either traces to a deterministic computation, or it does not appear.

Validation was designed around benchmark cases with known answers, provenance on every finding, explicit missing-data handling, and mandatory human review before anything is used commercially.

It is a POC under controlled validation. There is a plausible high-value business hypothesis attached to it. That hypothesis has not been tested by production measurement, so there is no return figure on this page — and I would be skeptical of a portfolio that quoted one at this stage.

This design is slower and more expensive per package than a single end-to-end model call, and it depends on GIS layers being clean enough to compute against. That is the cost of being able to defend a number in front of the person whose budget it lands in. For a workflow where nobody has to defend the output, I would not pay it.