5.2 The Timeline and the Work

This chapter illustrates

✓ The Printer · ✓ The Governed Engineering Environment · ✓ Governance Conversion

The last chapter established the problem. This one tells what happened when I tried to solve it — the concrete arc from a five-minute experiment in the back of a committee meeting to a production system that, by the end, was writing almost all of its own code. The story matters because every governance idea in this book was learned at a specific point on this arc, in response to a specific failure. The methods are not a theory that came first. They are the sediment left by the work.

The scale is easy to state and hard to believe. Over about 20 weeks of focused effort, a fleet of AI coding agents and I produced a repository of 501,094 lines of production code, 1,505,737 lines of support apparatus, 35,323 lines of infrastructure-as-code, and 28,507 lines of system models bridging the two. On a routine day, six to eight agents ran in parallel and landed on the order of 200 commits — about 1,000 a week, sustained, against the hundred a week a fast unaided human might manage. I inspected almost none of the code. That one fact is the engineering problem this book exists to answer: how a fleet producing more code than any human can read stays trustworthy.

5.2.1 It started in a meeting

The project began, fittingly, in a committee meeting about the very deadline described in the last chapter. In early 2026 an accreditation committee was discussing the ADA compliance date. Most of the faculty in the room did not know a mandate existed; those who did had made little progress against it. While the meeting droned on, I did what an engineering professor does when bored by a conundrum: 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 looked at a rendered slide and recovered real semantic content from the image — the core technical problem of document accessibility, solved well enough to build on.

That single positive result was the decision point. It converted a research question into an engineering project. What it did not do defines the gap the rest of the timeline had to close: the model did not export a corrected file, did not add reading order, did not validate against any standard, and understood nothing about the institution the file lived in. A flash of capability is not a system.

The first plan was small and conventional. Draft a one-week project — automated alt-text for the equations in instructional materials — and hand it to an undergraduate or two over Spring Break. I posted the offer to twenty of the department's best students. Not one replied; they had, reasonably, planned to have fun. So I decided to supervise agents instead of undergraduates. I bought a subscription, opened an empty Git repository, and told myself one month should be plenty.

5.2.2 Six stages, then a seventh

What followed moved through a recognizable sequence of stages. Each stage was driven by a concrete pressure — a colleague's request, a user's complaint, a deadline, a failure — and each one enlarged both the product and the machinery that kept the product trustworthy.

• Stage 1 — Feasibility probe. The chat-model experiment from the meeting: screenshots of mathematics and figures, submitted to a vision-language model, to confirm that alt-text generation was viable at all.
• Stage 2 — PowerPoint remediation. The probe became a command-line tool. A walker traversed PowerPoint slides, queried a model for figures and equations, and wrote descriptions back in place — soon also fixing slide titles, contrast, and reading order, driving down the warning count in Microsoft's own accessibility checker. Colleagues started asking for other formats.
• Stage 3 — Format expansion. Word and Excel extended the same Office walker. PDF did not; it forced the first real architecture — a document-type classifier, a vision pass to recover untagged figures, and a two-pass "analyze, then remediate" model. Documents from many sources broke assumptions the clean local decks never had.
• Stage 4 — SaaS. A website, a containerized worker, and a cloud deployment came online within days, pulling authentication, metered billing, quota and cost controls, and an early security review in behind them. Real users on real documents exposed the limit of trust: a lower checker-warning count is not the same as having done the job. Some outputs passed the checkers and lost the meaning.
• Stage 5 — Standards conformance. To make a defensible accessibility claim, the project stopped trusting external oracles like Microsoft's checker and veraPDF and built its own standards-grounded check engine, mapping every finding to a specific WCAG 2.1 AA, Section 508, or PDF/UA clause. Owning the check let remediation and verification share one vocabulary and run after every pass.

Learn more about this governance mechanism: standards-grounded check engine.

• Stage 6 — Hardening. The DOJ extended the deadline by a year, and the project shifted from emergency response to production hardening: typed commits, isolated agent worktrees, validation and fidelity gates, provenance stamps, property and regression tests, audit agents, fuzzing, and deploy gates.
• Stage 7 — Serverless. On a Monday I told the agent I was spending too much money running a Kubernetes cluster that mostly sat idle, and we should go serverless. By that night the production deployment was serverless — about 400 commits of rewiring, structured into 27 phased designs, each of which surfaced a handful of judgment-call questions for me to answer before it ran. The multi-service system took on a function-as-a-service shape, so capacity could scale on demand rather than bill around the clock.

Worktree. A private, checked-out copy of the repository given to a single agent, so its in-progress edits never collide with another agent working at the same time.

The two-line summary of the whole sequence is that the product grew, and the apparatus that governs the product grew faster. Measured in source size, the support machinery — tests, lints, load-bearing documentation, agent infrastructure, and tooling — ran about 3.0 times the size of the production code, and the test suite alone was roughly the size of the product. A ratio like that will, of course, read as gold-plating — until you recall that at 200 commits a day no human reads the diffs (the apparatus stands in — more on that in the built system). It is the price of the velocity.

5.2.3 The velocity curve

Figure 5.2-1 plots commits per week: a steep rise as the fleet gained capability, then the dip where velocity buys trustworthiness.

The repository's own activity records the shape of the effort. Commits and lines-changed per week rose steeply through the MVP stages — feasibility, PowerPoint, formats, service — as the system acquired capability. Then, during hardening, the raw velocity fell. That dip is the signature of the work changing character: from producing features to producing the mechanisms that let features be produced safely. The curve is a picture of me turning from a coder into an architect.

The human cost is part of the record too. It was so fun to build that sleep dropped to four or five hours a night; exercise and most everything else fell away. To stay ahead of the subscription rate limits, I ran up to four top-tier plans in round-robin and scheduled my own body across them. The addiction was real. The lesson, though, is what the machinery had to become to make that pace produce something trustworthy instead of a mess.

Field note — scheduling a body around the agents

The pace left marks on the days. I did development on the kitchen counter while the family slept. A graduate student once walked across a corporate-retreat dining room to complete a two-factor prompt for me. During a campus network outage I sprinted between two buildings so the agents would not stall waiting on me. The point of keeping these is not the drama; it is that a fleet running this hot needs machinery that holds the line when its operator plainly cannot.

The six stages read like a plan. They were not one. Each stage is a line drawn afterward through a run of dated, ordinary moments — a breakfast, a keynote walked out of, a hospital waiting room, a purchased fourth subscription at midnight on a holiday weekend. Set the clean account against the lived one and the stages stop reading as strategy. They are what they were: the shape you can only see once the mess is behind you. Figure 5.2-2 plots the real days behind the clean stages.

5.2.4 The support ratio: build the environment first

The apparatus outgrowing the product is not a one-time fact; it is a curve. Measure the support apparatus against the production code at four dated commits and the revealed preference of the whole build falls out in one line. Figure 5.2-3 plots it.

Table 5.2-1 gives the lines behind the ratio — production and support apparatus at each of the four commits.

Read the curve as a decision, not an accident. In the prototype the support apparatus was smaller than the product — 0.85×, below parity — because there was barely a product to govern. By mechanization the apparatus had crossed production and reached 2.48×, and by hardening it peaked at 3.68×: roughly three and a half times the code it guarded. The governance was built first, then the features leaned on it. That ordering is the whole argument of this book, drawn as a line. The support ratio is the Governed Engineering Environment measured against the product it governs.

The final-window dip to 3.06× is not a retreat. Support did not fall — it grew another 21% in absolute terms. Production simply grew faster, up 45%, as feature work resumed on top of the finished environment. A falling ratio here signals a stabilized foundation being spent, not an abandoned one. Across the whole span the apparatus crossed from sub-parity to about three times the product while production itself grew roughly forty-seven-fold — the machinery led the fleet and never fell behind it.

One honesty note keeps the number from overclaiming. The census fails loud over seven primary source roots, so the coverage gap is zero at every window — no file the tool was asked to count slipped past it. About a fifth of the raw tree sits outside the census by design (root configuration, assets, non-primary test corpora, this book itself), and that side-tree share is roughly flat across the mature windows, so the curve tracks a real shift in how effort was spent, not an artifact of the category map moving under it. Lines of code remain a coarse proxy for effort; the ratio is a revealed preference across one repository and one fleet, not a controlled comparison of governed against ungoverned work.

5.2.5 The shape of the churn

Under the ratio sits the raw motion of the code: lines added and lines deleted, week over week, on the two paths that carry the product — web/, the Python service and worker, and backend/, the C# tool and rule engine. The preface named churn as the wall a fleet hits. Trace it per path across the four windows and the wall has a clear silhouette. Figure 5.2-4 draws it; Table 5.2-2 gives the counts.

The peak is unmistakable. Mechanization — the wave where the agent fleet learned to build the environment — is where both paths churn hardest, the bulk of every addition and nearly every deletion. backend/ alone rewrote itself in that window: 941,120 lines added against 286,378 deleted, a system being torn down and rebuilt as fast as it was written. That motion is the danger the rest of the book governs. Ungoverned, it is exactly the churn the preface warned of — effort spent undoing and reconciling instead of advancing.

Then the deletions collapse. backend/ falls from 286,378 deleted lines at mechanization to 3,767 at hardening, and both paths turn net-additive: far more added than removed, window after window. The code stops thrashing. That turn is the built environment paying off — once the apparatus holds the line, changes accrete onto a stable base instead of churning it. The shape of the deletion curve is the churn wall being pushed back.

One caveat keeps the numbers honest, and a measurement now bounds it. These counts come from git's own line accounting, which sees every tracked file, so generated bundles and vendored trees ride along with hand-authored source. Partitioning each changed line by path shows how much that inflates the totals. On backend/ the answer is none: zero generated lines, so its additions are all real C# and configuration. On web/ it is 14.6% of added lines, and almost all of that falls in the mechanization window (24.5% there), when the TypeScript-to-JavaScript build output and wire-contract codegen were still tracked; once the compiled output was git-ignored the generated share dropped to 1-2%. Across both paths combined the generated share is 5.2%, because backend/ dominates the total and carries none of it. So read the bars as a churn signal, not a hand-authored source count — but the inflation is bounded and time-localized, concentrated in one window on one path, and the curve is predominantly real source everywhere else.

The deploy saga: the surprises the tests could not see

For a stretch of the build, nearly every unwelcome surprise came from deployment, and they shared a shape. The unit tests stayed green. The lints passed. The thing that broke was never a statement in a file; it was a behavior of the running system — a cold start that took a hundred times its warm latency, a gate budget sized for a regime that no longer held, two services contending for a core, a dependency graph that woke in the wrong order. The metrics chapter tells the cold-start half of this as a measurement story, and the numbers live there. The point here is different, and it is methodological: none of these lived in the statics. They lived in the dynamics, and no amount of green on the unit suite could have found them, because each coupling ran across layers the unit suite never spans at once — the code, the lints that guard it, the tests that exercise it, the infrastructure-as-code that places it, and the deploy pipeline that sequences it. A property that emerges only when those five layers run together is invisible to any check that reads one of them alone.

That is the case for testing the dynamics, not only the statics — and for the harder move underneath it. A one-off fix to a cold start or a gate budget clears today's surprise and leaves the next one to be discovered the same expensive way, on the next real deploy. The durable answer is to turn each discovered dynamic into a mechanism that watches it: a measured cold-start number fed to a model that recomputes the worst-case path, a budget derived rather than guessed, an ordering asserted rather than assumed. Do that and the class stops recurring silently. A finite review of a diff never had a chance against these — the coupling is not on the diff. Only a mechanism that watches the whole running dynamic holds the line as the fleet's deploys speed up, which is the mechanized-assurance claim read on the one surface where human attention is least able to help.

5.2.6 The kinds of work it required

Read this timeline as a catalog of the kinds of work agentic development turned out to need — a more useful reading than any feature list. The code was cheap. Everything around the code was where the judgment went, and the same handful of activities recurred at every stage:

• Framing the problem. Deciding what "accessible" even meant for a math-dense graduate deck, where the file alone underdetermines the answer, and which parts of the mandate the system should chase.
• Discovering abstractions. Recognizing that PDF was not "Office with a different extension" but a distinct problem needing a document model of its own — and building structured models so that structure was compiler-checked instead of passed as anonymous primitives.
• Deciding local versus structural. For each failure, judging whether it was a one-off bug to patch or the visible symptom of a missing mechanism — the single most repeated act in the whole record.
• Building the checks. Standards-grounded validation, content-preservation checks that assert the input survives into the output, hundreds of project-specific lints atop a maxed-out commodity floor, and a tiered regression suite from smoke tests to fuzz campaigns.

Learn more about this governance mechanism: content-preservation checks.

• Governing the fleet. A dispatch-and-track workflow for parallel agents, isolated worktrees, a pre-commit gate whose passage is proven by a hash-keyed marker file, an agent registry that authoritatively answers "who is in flight," and lifecycle records for every agent that lands or dies.

Learn more about this governance mechanism: pre-commit gate.

Learn more about this governance mechanism: agent registry.

• Operating and deploying. Cloud deployment with staged gates, quota and cost controls, observability channels, audit trails that let a finished document's history be reconstructed, and runbooks for the failures that recur.

Read as a list, those are the chapters of this book. Every one of them answers a failure this timeline produced, and the recurring move that produced them all is the same: velocity surfaces a failure; judgment classifies it as local or structural; the structural ones get converted into a durable mechanism that narrows the next agent's room to fail. That move, applied over and over, is what the rest of this book laid out, told slowly enough that you can do it too.

By the end of the study period the system could process Office and PDF files to pass or substantially improve their accessibility scores — a graduate slide deck in about a minute, for about a dollar — and it was patent-pending and being readied for institutional deployment as DocAble. The direct development cost was about sixty thousand dollars, most of it my salary, with a few thousand each in model inference, cloud hosting, and subscriptions. That is the arc. How it was governed is the story the rest of this book has already told.