The Timeline and the Work

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 19 weeks of focused effort, a fleet of AI coding agents and I produced a repository of 490,231 lines of production code, 1,420,335 lines of support apparatus, 8,446 lines of infrastructure-as-code, and 7,380 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.

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 is worth noting, because it 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.

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.
• 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. The multi-service system was pushed toward a function-as-a-service shape, so capacity could scale on demand rather than sit idle.

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 2.9 times the size of the production code, and the test suite alone was roughly the size of the product. That ratio is not gold-plating. At 200 commits a day, no human reads the diffs, so the apparatus is the substitute for code review. It is the price of the velocity.

The velocity curve

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 not a slowdown in a bad sense. It 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, and it is not the lesson. The lesson 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.

The kinds of work it required

The most useful way to read this timeline is not as a feature list but as a catalog of the kinds of work agentic development turned out to need. 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 typed 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.
• 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.
• 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. The rest of the book is that move, applied over and over, 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. What remains is to explain how it was governed, and that is where the rest of the book begins.