5.2 Building DocAble

This chapter illustrates

✓ The Printer · ✓ The Governed Engineering Environment

The next evidentiary question is chronology and scale: how a five-minute feasibility experiment became a production system developed faster than one reviewer could follow line by line. Later chapters reconstruct what particular events taught. Here the purpose is simpler: establish what changed, when it changed, and how much engineering structure accumulated around the product.

Over roughly 20 weeks, one primary engineer directing a coding-agent fleet produced the application, its tests and tooling, its infrastructure, and the system models used to reason about it. Table 5.2-1 gives one late-study snapshot (2026-08-03). The counts are descriptive, not a productivity claim. The condition that matters is scale: implementation volume had moved beyond anything one person could inspect by reading every diff.

The counts are just counts. The number that matters is not among them. I inspected almost none of the code. That is the engineering condition this case investigates: what has to surround abundant implementation when direct human inspection no longer scales with it?

5.2.1 The Feasibility Probe

The project began in a committee meeting about the very deadline the last chapter described. I ran a small experiment: I opened a chat model, fed it screenshots from one of my own slide decks, and asked it to transcribe what it saw. It worked. The model recovered useful semantic content from a rendered slide well enough to build on.

That positive result turned a feasibility question into an engineering project. It proved neither remediation nor conformance: the model did not produce a corrected file, preserve reading order, validate against a standard, or know anything about the institutional workflow around the artifact. The experiment showed that one hard component had become plausible. Everything else remained to be engineered.

The original plan was modest: hand a one-week alt-text prototype to a student or two. No students materialized. I opened an empty repository, put an agent fleet on the problem, and assumed a month would be plenty.

5.2.2 Seven Stages, Retrospectively

The build moved through seven recognizable stages, visible only in retrospect. Each was driven by a concrete pressure: a colleague's request, a user's complaint, a deadline, a failure. Figure 5.2-1 gives the sequence.

None of this looked like MAGE

Hindsight gives the stages names and boundaries. At the time, the work arrived as ordinary engineering pressure: an exhausted context window, an unattended agent that could not be located, a cloud bill exposing an assumption, a deployment failure crossing a coupling no static check represented.

MAGE is the compression recovered afterward, not the roadmap followed at the time.

Commit volume rose rapidly as the fleet expanded and remained far above a rate one human could review conventionally. During hardening, the work record shifted toward models, validation, tests, and control machinery before feature work accelerated again. Appendix H gives the weekly curve. The important fact for the case is not the precise shape of that curve but the operating condition it records: human attention could no longer be allocated one diff at a time.

5.2.3 The Controls Accumulate

The growing engineered environment is visible in one especially easy-to-count class of artifacts: project-specific lints and gate scripts. Figure 5.2-2 counts those artifacts at four snapshots. Both begin at zero after the prototype and rise sharply through mechanization and hardening.

Count alone says little about quality. The more useful repository evidence is provenance: 208 paired fix-and-lint tags mark commits where a repair landed with a check against recurrence, and 27 further lints name the dated incident that motivated them. The pattern records substantial investment in repeatable environmental checks as implementation scaled; it does not establish how often failures caused governance conversion.

5.2.4 The Support Ratio: the Environment Outgrew the Product

Another coarse measure shows where the engineering effort accumulated. Divide the source counted as support apparatus — tests, modeling, orchestration, documentation, and governance tooling — by production source at four dated snapshots. The ratio begins below parity, crosses it during mechanization, peaks during hardening, and settles a little above three-to-one at the final snapshot. Figure 5.2-3 plots it.

Call this the support ratio. It is descriptive, not a target. Lines of code are a poor measure of value, and a smaller environment that retires the same judgment would be preferable. Here the ratio records where source accumulated as implementation volume moved beyond direct line-by-line review: tests, models, orchestration, documentation, and governance machinery exceeded the production path itself.

The engineering-capital interpretation is stricter still. Support code is not capital merely because it exists. It earns that name only while future work inherits useful capacity from it — less reconstruction, earlier detection, retired review, safer delegation, or cheaper recovery. Some of this apparatus will eventually depreciate. The figure shows the stock that accumulated, not its current return.

Repository history supplies one further consistency check: add-and-delete motion peaked during the mechanization period, when much of the system was being structurally reworked, and fell sharply afterward. Appendix H gives the path-level counts. The pattern is consistent with heavy restructuring followed by less structural rewriting; it does not establish that MAGE caused lower churn.

5.2.5 Where Engineering Judgment Went

The feature list is less revealing than where engineering judgment went: defining what accessible meant operationally; discovering abstractions for unfamiliar formats and workflows; distinguishing local defects from missing representation or authority; building independent evidence; coordinating the fleet; and operating failures that crossed code, infrastructure, and deployment boundaries.

By the end of the study period, DocAble could process Office and PDF documents and pass or substantially improve the institutional accessibility checks used during development. That is narrower than proving that a blind student will find every remediated artifact usable, and the case should keep the distinction explicit. The product was not the only thing that had grown. The engineering environment around it had become larger than the production source and had absorbed much of the repeatable work direct review could no longer carry.

Receipt. By the end of the study period, a representative graduate deck processed in about a minute for about a dollar on a warm-start service. A separate model estimated manual remediation of one teaching load's materials at roughly $20,000 in faculty labor. Direct development cost was about sixty thousand dollars, mostly salary. These quantities have different scopes and are not a comparative cost model; the evidence ledger gives their assumptions and provenance: Appendix H.

Field note — The counterfactual

One counterfactual rests on direct engineering judgment rather than repository data. Within the actual constraints of this project—one primary engineer, an academic budget, and the development interval reported here—DocAble was not feasible for me without generative AI. That is not a claim that a conventional engineering organization could not have built the system. The relevant counterfactual is the project that actually existed: under those constraints, I would not have attempted a production system at this scope without commodity implementation capacity.

The leverage was not merely faster typing. The fleet implemented features, debugged failures, constructed tests and validators, refactored large regions, rewired architectures, migrated deployment platforms, and repeatedly realized alternatives that could be exercised and discarded. Cheap implementation changed the exploration budget. An architecture that once would have been too expensive to build merely to discover that it was wrong could now be tried, measured, and abandoned.

A second counterfactual concerns sustained delegation: GenAI made DocAble feasible; the machinery that became MAGE made delegation at this rate feasible. Once autonomous change volume exceeded anything I could inspect conventionally, raw model capability was no longer enough. Continuing at that rate required increasingly explicit representations of the system, independent evidence, constraints, validators, gates, and operating machinery through which the work could be understood and governed.

This is a within-case engineering judgment, not a controlled causal estimate.

The next chapter asks how that change altered delegation itself.