Managed Maintenance and Feedback Loops

Chapter idea: An agentic software factory must manage what happens after code is generated. It needs scheduled cleanup, limits on shared capacity, human review, and a way to turn the results into better reusable skills.

Generation creates maintenance work

An automated agent can create a feature quickly. That feature may also create temporary code, configuration, or feature-flag paths. When the experiment ends, those paths become clutter and future work must carry them.

The important shift is to treat cleanup as a managed workload rather than as an optional task that someone may remember later. In the talk's example, features and services can enroll in maintenance skills. A maintenance skill is a reusable procedure that finds a known kind of work, changes the relevant code, and proposes the result for review.

This is a teaching explanation of the implication: more generation increases the need for cleanup as well as for generation. The source claim is narrower and concrete: Uber describes enrolling features and services in maintenance skills and shows obsolete World Cup variant cleanup as an example.

Example: cleaning up an ended experiment

Imagine that a stadium pickup experiment has two variants. The experiment ends, and Variant B is no longer needed. Leaving its feature flag and related branches in the code makes the system harder to understand. It may also leave dead paths that future agents or engineers must inspect.

A managed cleanup flow can look like this:

1. Enroll the feature or service. The system records that this code is eligible for a known maintenance procedure.
2. Detect work that is due. The procedure identifies the obsolete experiment variant and the code associated with it.
3. Run at a controlled time. The cleanup is scheduled for a Sunday off-peak window rather than being launched whenever an agent happens to notice it.
4. Prepare a bounded change. The agent removes the obsolete path and creates a reviewable change.
5. Collect the result. Review comments and the eventual outcome—landing or rejection—become evidence about the procedure.

The cleanup is therefore not just “delete old code.” It is a repeatable path from eligibility to evidence. The agent still produces a change, but the surrounding system controls when it runs, how much work it exposes, and how its result is used.

Scheduling and quotas are governance

A cleanup job is technically ready when its code can be changed. It is operationally ready only when the surrounding system has room for the work. Continuous integration (CI), compute, and human reviewers are shared resources. They have finite capacity.

For example, many maintenance jobs may be waiting while CI is busy and reviewers are preparing for Monday work. Running every job immediately could create a queue of noisy pull requests, increase CI contention, and make it harder for people to review important changes. A scheduler can instead use an off-peak window and quotas.

The controls have different jobs:

• Schedule: Controls when maintenance starts, so recurring work runs in a predictable, lower-conflict window.
• Quota: Controls how much work runs at once, so maintenance does not consume all shared compute or CI capacity.
• Diff limit: Controls how much change a reviewer sees, so each proposed cleanup remains understandable and reviewable.
• Review outcome: Records whether the change is accepted, preserving human judgment and supplying a learning signal.

These controls are governance mechanisms, not merely performance tuning. They define how autonomous work fits into the organization. “Autonomous” does not mean “unbounded” or “always immediate.”

The maintenance loop

A useful teaching model for the described process is:

enroll → find due work → apply schedule and quotas → prepare a bounded change → review → land or reject → improve the skill

Each step has a distinct purpose:

• Enrollment tells the system which code can participate.
• Scheduling and quotas protect shared resources.
• The proposed change makes the agent's work inspectable.
• Comments and landing outcomes show whether the procedure produced a useful change.
• Skill updates convert repeated evidence into a better procedure.

The loop is valuable because the final step changes future behavior. If a maintenance skill repeatedly proposes changes that reviewers reject, the answer is not simply to run it faster. The skill may need better detection, narrower scope, stronger validation, or a clearer review artifact.

Outcomes are improvement labels

A comment on a cleanup change contains information about what went wrong or what a reviewer expected. Whether the change lands supplies another signal. Together, these are examples of label data: observed outcomes paired with information that can improve an evaluation or procedure.

The outcome should not be reduced to a single score. Consider two teaching examples:

• A cleanup pull request lands after a reviewer asks for a smaller diff. The maintenance logic may be correct, but its batching policy needs improvement.
• A cleanup pull request is rejected because the experiment is still active in one environment. The detection logic or its source of truth may be incomplete.

Both outcomes teach something different. The first points to reviewability. The second points to correctness or freshness. A managed system can use those distinctions to maintain the skill instead of treating every rejection as the same failure.

Incidents turn into reusable maintenance skills

The talk extends the loop beyond ordinary review. Incidents and bugs can lead to new skills in a monthly improvement loop. An incident is not only an isolated event to resolve. It can reveal a recurring condition that an agent should check or repair in the future.

For example, if an incident reveals that a temporary configuration is often left behind, the organization can encode a maintenance procedure that detects that condition. The procedure can then be evaluated, scheduled, and reviewed like other managed work. This is a teaching example of the mechanism; the source establishes the broader pattern that incidents and bugs lead to new reusable skills.

This is how operational learning becomes organizational memory. The lesson is not stored only in one engineer's experience or in one incident ticket. It is also captured in a procedure that other agents and teams can reuse.

Common misunderstandings

“Cleanup is just a cron job”

A timer can start a script, but it does not by itself provide authorization, quotas, reviewability, or learning. Managed maintenance includes the controls around execution and the feedback after execution.

“More automation means all queued work should run now”

Immediate execution can move the bottleneck to CI or human review. A Sunday schedule and quotas make throughput a system property rather than a race among agents.

“A landed change proves the skill is correct”

Landing is useful evidence, but comments, scope, follow-up defects, and incidents add context. The goal is to improve the reusable procedure, not merely to maximize the number of merged cleanup changes.

Why this completes the factory model

The factory metaphor is incomplete if it describes only production. A real software-delivery system must also remove obsolete outputs, protect its shared resources, and learn from defects. Managed maintenance supplies that missing loop.

The chapter's core claim is therefore about control and learning: enroll recurring work, schedule it within capacity, keep changes reviewable, preserve human outcomes, and turn incidents into reusable skills. Generation produces software; feedback determines whether the production system becomes safer and more useful over time.

Source anchors

• 15:54–17:16 — The chapter presents features and services enrolling in maintenance skills, including controlled cleanup of an obsolete World Cup variant.
• 16:36 — The visible slide shows managed maintenance loops and a Sunday off-peak schedule. The schedule and capacity relationship are visible; the reviewer-facing diff limits are supported by the talk's explanation rather than by that frame alone.
• 16:59 — The visible slide shows incidents and bugs leading to new skills in a monthly loop.

Watch the source video (chapter begins at approximately 15:55).