Systems That Maintain Themselves

This is the closing module of the course, and it is deliberately an assembly module rather than a new-technique module. Tokens that carry intent (Module 1), a DESIGN.md the agent reads (Module 2), review gates with evidence requirements (Module 3), audits with findings the team trusts (Module 4), and token sync that reports divergence (Module 5) are the parts. This module is about wiring them into a standing arrangement that runs on a schedule and on every change, with humans approving rather than producing.

Set expectations honestly at the start. The phrase self-maintaining is doing careful work: the system can detect drift, propose fixes, regenerate documentation, and keep tokens propagated, but it cannot decide what counts as drift versus evolution, whether a deprecation is worth the breakage, or whether the new green is better. The almost matters, and the module spends real time on it.

If participants have not done the earlier modules, the loop will still make sense as a diagram, but the parts will feel abstract. The exercise at the end asks them to draft their own loop on one page, and the quality of that page tracks how much of the earlier infrastructure they actually have.

Open with the failure pattern, because everyone in the room has lived it. The system launches well-documented and well-adopted, then decays quietly: a brand colour adjusted in CSS but not in the docs, a component that grew an off-system variant during a deadline week, a spacing value copied into four files because nobody knew there was a token. None of these is a scandal on its own. Together they are why the next person who asks what colour is our accent gets three different answers depending on which file they open.

The important reframe is that this is not a discipline problem. People are good at making the design decision and bad at finding every place it has to land — the CSS variable, the theme mapping, the hover state, the prose in the documentation, the canvas, the onboarding deck. That is a search-and-bookkeeping problem, and search and bookkeeping is a fair description of what coding agents do best: find every reference, edit each one, regenerate what describes it, run the checks, and produce a diff a human can review.

The second reframe is cadence. The traditional response to drift is the quarterly or annual cleanup project — heroic, exhausting, and out of date within a month. The maintenance loop replaces the project with a standing arrangement: checks on every change, audits on a schedule, fixes proposed as they are found. Smaller batches, reviewed continuously, by people who are approving rather than excavating.

Walk the loop station by station and name the owner of each. The source of truth is human-owned: the token layer, DESIGN.md, the audit schedule, and — importantly — a written list of decisions that are human-only. Detection is agent-run and has two triggers: standing checks on every pull request that touches UI, and scheduled audits that sweep the whole surface for what per-change checks miss. Proposal is agent-run too, with one hard rule: everything arrives as a reviewable change — a pull request with evidence attached — never a direct push. The review gate is human: a person reads the diff, the gate output, and the rendered result. Apply and log is agent-run, but only after approval, and it includes re-running the gates and updating the change log. The decision station is human: deprecations, breaking changes, intentional variation, and taste, with the agent supplying the impact analysis.

Point at the dashed feedback line. Approved decisions go back into the source of truth — a token value changes, a rule is added to DESIGN.md — and the next cycle of the loop propagates them. Decisions never land directly in components, because that is exactly the bypass that created drift in the first place.

The failure mode to warn about is collapsing the two human stations. Teams under load start treating the review gate as a formality and the decision station as something the agent can handle because it sounds confident. The loop then keeps running and keeps producing technically compliant changes that nobody with taste has looked at, which is drift wearing a high-visibility vest.

The distinction to land is that these are two different activities, and conflating them weakens both. Standing gates — the token audit, the type check, the design QA pass on a pull request — are cheap, unambiguous, and constant. Their limitation is scope: they only check what someone thought to encode as a rule, and they only see the change in front of them. The recurring audit is a scheduled, whole-surface review asking whether the system as built still matches the system as intended — meaning drift, behaviour drift, the component that is technically token-compliant but no longer matches its documented purpose. Module 4 covered how to run that audit; what changes in the maintenance loop is only the trigger and the cadence: it stops being a heroic once-a-year cleanup and becomes a recurring brief.

Cadence should be sized to the product, not to ambition. Monthly works for a product shipping UI weekly; quarterly is fine for a slower system. The practical wiring is unglamorous: gate commands in CI so they cannot be skipped, the audit brief checked into the repository next to the system documentation with the next run date written in it, and findings opened as reviewable items with evidence attached rather than dumped into a document nobody owns.

The report format matters as much as the schedule. A finding without a file, a line, and a screenshot is an opinion, and opinions get argued with rather than fixed. A finding graded by severity with evidence and a proposed fix gets actioned in the same week. The audit module's evidence rules apply unchanged here; the only new requirement is a named human owner for the report, because a report routed to everyone is routed to no one.

Documentation is the surface no gate protects. The token audit does not parse Markdown, the type checker does not read usage guidance, and the build does not fail when a prose sentence describes a colour that no longer exists. That is exactly why documentation drifts first and gets trusted longest: it looks authoritative, and looking authoritative is most of what it takes to be believed.

Two practices keep it honest. First, generate what can be generated: prop tables, token value tables, usage examples, and component inventories can be regenerated from source — by the agent, on a schedule or as part of any change that touches the source they describe. Second, for the prose that cannot be generated, enforce the same-change rule: documentation is updated in the same pull request that makes it stale, drafted by the agent from the diff it just produced, and reviewed together with the code. Module 2 set up DESIGN.md as the contract; this is how the contract stays true.

The stakes are higher in this course than in a human-only system, and it is worth saying why. In the workflows this course has built, DESIGN.md is not just read by people — it is loaded by the agent at the start of every session as an instruction set. Stale documentation in that world does not merely confuse a new hire; it actively instructs the next hundred agent runs to reproduce the wrong value. Documentation that agents read is configuration, and it deserves the same change discipline as code. The caveat to keep: generated documentation still needs a human owner who reads it, because confidently generated prose that is subtly wrong does more damage than an honest gap.

This is the structural rule the loop depends on, and it is worth being absolutist about it: nothing the agent produces lands on the main branch without passing through a human. Not because agent output is usually wrong — most of the mechanical fixes are fine — but because the moment changes flow into the system unreviewed, the team loses the ability to notice the ones that are not, and loses it precisely when volume is highest.

In practice the proposals come in three sizes. Small: individual audit findings fixed and opened as pull requests — a hardcoded colour replaced with its token, a missing focus state added, a stale prop table regenerated. Medium: the design QA findings on someone else's branch, posted as a review comment so the author fixes their own work. Large: a token migration across hundreds of files, run as an orchestrated workflow on a branch with a per-file reviewer agent rejecting any diff that goes beyond the approved mapping, and a visual recapture before the pull request opens. The course's related workflows — design QA on every PR and the design token migration — are the worked versions of the small and large cases; reuse them rather than rebuilding.

The evidence requirement is what keeps review cheap. A proposal that says what it searched, what it changed, what it checked and deliberately left alone, with the gate output attached, can be reviewed in minutes. A proposal that says trust me, the checks pass forces the reviewer to either re-do the investigation or rubber-stamp it — and rubber-stamping is the failure mode the next slides deal with.

Teams adopt the loop and then quietly fail to staff it. The proposals arrive, nobody is named as the approver, and the queue either stalls — which discredits the loop — or gets approved in bulk by whoever feels guiltiest, which is worse. The fix is boring: a rotation, with one named approver at a time, a bounded slot in their calendar, and an explicit definition of what approval means.

What it means, concretely: read the diff, not the summary of the diff. Look at the rendered result on at least one affected surface. Check that the change stayed inside its claimed scope — the propagation prompt's do-not-touch list exists precisely so a reviewer can verify it was respected. Read the gate output rather than trusting the green tick, and remember the gate's known blind spots. And when the change touches anything on the human-only list — a deprecation, a rename, a breaking impact, a taste call — escalate it to the decision owner instead of absorbing it into the approval.

Be honest about the cost when proposing this to a team. On an active system the approval rotation is somewhere between thirty and sixty minutes a day, more in a week with a migration in flight. That is dramatically less than the production work it replaces, but it is not zero, and pretending it is zero is how rotations collapse into rubber-stamping. The rotation is also where the system's taste gets exercised week to week, which is a reason to rotate it among people whose taste you want encoded — not to hand it permanently to whoever is most junior.

The maintenance loop fails in two opposite directions, and teams usually only guard against one of them. Delegating too little — using the agent as a fancier find-and-replace while a human still does all the surface-finding and bookkeeping — wastes the capability and keeps maintenance unstaffed in practice. Delegating too much — letting changes flow into the system without anyone exercising judgment — produces the slow accumulation of technically compliant changes that nobody with taste has looked at in months. The system stays consistent and gets quietly worse.

Walk a couple of rows. The merging row is the bright line from two slides ago: gates exist to make review cheap, not optional, and an agent merging its own work because the checks passed is the automation equivalent of marking your own homework. The review row is the same failure on the human side — approving on green checks without opening the diff is a gate blind spot wearing a person's name. The scope row is the quiet one: open-ended instructions like fix the design system everywhere produce changes nobody can review, because there is no claimed scope to verify. The do-not-touch line in a propagation prompt is what lets a reviewer trust a small diff.

A useful test for any proposed delegation: is the thing being delegated checkable? Keeping components compliant with the documented system is checkable, so it delegates well. Deciding whether the system should allow a second accent colour is not checkable — it is a question about product intent — and the agent will answer it confidently anyway, which is exactly why it must not be asked to.

These failure modes deserve their own slide because none of them looks like a failure while it is happening. Rubber-stamping looks like an efficient team clearing its review queue. Alert fatigue looks like a thorough audit. Scope growth looks like a helpful agent. The common thread is attention decay: the loop is designed around human attention at two stations, and every one of these failure modes is a way that attention quietly leaves.

The counters are specific. For rubber-stamping, periodically pull three recently approved changes and review them properly; if the second look finds things the first approval missed, the rotation needs more time or fewer proposals per day. For alert fatigue, treat the finding rules as a product: tune out the false positives, batch the advisory findings into the scheduled report instead of raising them per change, and reserve interruption for severities that genuinely block. For scope growth, re-state the scope in every recurring brief and have the reviewer check the do-not-touch list was respected — agents drift toward helpfulness, and helpfulness across an unbounded surface is indistinguishable from noise. For gate blind spots, remember the lesson from the audit and case-study work earlier in this course: a passing gate means the checks you wrote found nothing, not that nothing is wrong, so review the check list itself on a schedule.

The last bullet is the cultural one. The failure mode of automated maintenance is not a dramatic breakage; it is a slow accumulation of compliant changes nobody with taste has examined. The standing appointment that matters most is not the audit cadence — it is the recurring moment where a person looks at the actual product and asks whether the system is still serving it.

It is tempting to present the remaining human work as temporary — that better models will eventually own deprecation and taste the way they own propagation. The honest position, and the one this course closes on, is that most of it is not a capability gap at all. Whether to deprecate a token is a question about which consuming teams you are willing to break and on what timeline; that is an organisational decision with an owner, not a pattern-matching problem. Whether a variation is drift or evolution is a question about intent, and only the people who own the intent can answer it. Whether the deeper green is better is taste, and taste is the thing the design system exists to encode — flattening it into a rule the agent applies is how systems become consistent and lifeless at the same time.

What the agent genuinely changes is the quality of the decision inputs. A deprecation decision made with a complete impact analysis — every consumer of the token, every surface a breaking change touches, the migration cost estimated from the actual codebase — is a different decision from one made on instinct and a grep. Demand that analysis from the loop; just do not let the analysis quietly become the decision.

Name the operational limits too. Gates have blind spots, and accessibility is the sharpest one in this course's own toolchain: nothing in a token audit checks contrast, so a system can be perfectly token-compliant and illegible. Add the specific checks where they matter and keep human judgment behind them. And the loop inherits the quality of its source of truth — an agent maintaining a badly structured system will faithfully propagate its problems everywhere, faster than before. Self-maintenance amplifies the system you have, which is why the first five modules came first.

This composite traces a month of the loop on a mid-size product system, drawn from the executed case studies behind this course's articles and workflows — the accent-token propagation run on this school's own files, the PR design QA gate adopted by a small product team, and the audit and migration workflows. The numbers are indicative of that scale of system, not a benchmark; say so when presenting it.

Walk the rows for the division of labour. The PR gate did the highest-volume work: twenty-three UI branches reviewed automatically, with findings going back to the branch authors rather than to the system team — the system team only got involved in two severity disputes. The scheduled audit produced the larger findings list, and the most important human action on it was demotion: three findings the owner marked as intentional variation, which is precisely the call an agent cannot make. The mechanical fix PRs are where the approval rotation earned its keep, including sending two back for scope creep — the agent had also reformatted a file while it was in there, which is exactly the drift-toward-helpfulness the previous slide warned about. The accent token change is the propagation pattern from the source article: a human decision, a three-line diff, gates re-run, reviewed in one sitting.

The last row is the one to dwell on, because it is the least intuitive. The agent produced a complete impact analysis for deprecating two legacy spacing tokens, and the humans decided not to act this quarter — and logged why. A maintenance loop that can produce a documented decision not to change something is working exactly as designed. The total human cost across the month was on the order of a day, nearly all of it judgment rather than production. That is the trade the whole course has been building towards.

This exercise is the course's closing artifact, and it doubles as a diagnostic. Each line of the page maps to a module: the surface list and gates come from the token and DESIGN.md work in Modules 1 and 2, the review standards from Module 3, the audit cadence and evidence rules from Module 4, the sync surfaces from Module 5, and the rotation and decision list from this module. Where a participant cannot fill a section in, the gap is usually not in this module — it is in the prerequisite the loop assumes.

Steer people towards starting smaller than they want to. Month one should be the standing gates plus mechanical fix PRs only — token replacements, regenerated tables, missing states. Add the scheduled audit in month two once the approval rotation has found its rhythm, and only then consider larger delegations like migrations. The most common way teams discredit the loop internally is switching everything on at once and drowning the rotation in week one.

The two sections worth pressing on in a live session are the rotation and the human-only list. The rotation needs names and a time budget, not a team will review statement — unstaffed review is the rubber-stamping slide waiting to happen. And the human-only decision list is the single page that makes the almost in self-maintaining trustworthy: if it is not written down, it will be decided ad hoc, under deadline, by whoever is closest — which is exactly how the system drifted in the first place.

Recap by walking the loop one last time, but spend the time on how the course's modules slot into it: tokens and DESIGN.md are the source of truth the loop reads and writes; the review gates from Module 3 are the human station every proposal passes through; the audit discipline from Module 4 is the detection step, just put on a schedule; the sync work from Module 5 is what keeps the loop's picture of the system true across tools; and this module added the cadence, the rotation, and the honest list of what stays human.

Close with the framing that the end state is not zero human effort — it is human effort relocated. The system team stops spending its weeks excavating drift and writing documentation after the fact, and spends a much smaller amount of time approving changes, settling severity disputes, and making the decisions that shape the system. The quality of that smaller effort is what the system's quality now depends on, which is why the rotation and the decision list are not afterthoughts.

For where to go next: learners who want to scale this pattern beyond one design system should look at the school's course on orchestrating design agent teams, which covers running multiple agents and larger programmes of work. Those who want to sharpen the judgment side of the loop — what good critique and review practice looks like when an agent is the producer — should look at the design review and critique course. And the related workflows referenced throughout this module — design QA on every PR, the design token migration, and the accessibility sweep — are the runnable starting points for the loop drafted in the exercise.