The Maintenance Machine

1The problem

Small businesses run software built for someone else. A dispatcher sorts her job queue by hand every morning because her shop's workflow will never make the vendor's roadmap. Generative tooling can close this gap: capture what the software does wrong for her, change it, deploy the change.

The risk: when a change costs nothing to produce, an agent rewarded for shipping will ship. Twenty accepted changes later, the dispatcher has software nobody understands. The system must prove it knows when not to change things. Judgment is the product.

2Three lanes of change

"Self-improving" covers three different promises. Each change must name its lane before code generation starts.

• Repair. Restore agreed behavior. Example: a permitted user cannot save a valid job. Evidence: one reproducible failure. Authority: standing.
• Preference. Change a local agreement. Example: this shop wants jobs grouped by technician. Evidence: one authorized request. Authority: the customer's delegation map. Twenty unauthorized complaints do not qualify.
• Experiment. Test a claimed improvement. Example: grouping by technician might speed dispatch. Evidence: a predeclared outcome metric, exposure plan, comparison unit, and stopping rule.

The triager writes a falsifiable problem statement before any builder sees the request. Without this step, feature requests get processed as defects. "No change needed" and "use the existing setting" count as successful resolutions and get recorded like deployments.

3Evidence standards

Complaint counts are a bad input. Three complaints may be one incident repeated in a group chat. The employee who runs the workflow three hundred times a week may never complain. Each request needs an evidence record: who hit the problem, in what role, on which version, how often the opportunity occurs, and who holds authority over the behavior.

Post-deployment, silence proves nothing. Complaints also stop when users abandon the flow or rebuild the workaround in a spreadsheet. Sample sizes make this worse. If a bug hits 10% of attempts, ten clean attempts after a fix still leave a 35% chance the bug remains.

Track three claims separately: the recorded failure passes replay; the change ran safely in observed cases; business outcomes improved. The first two never imply the third. Each claim can sit at Unknown indefinitely. For most small deployments the honest result is "preference implemented and exercised" with the outcome claim left at Unknown.

4Verification structure

A constraints file the agent can read is not a constraint. The agent can change a caller's assumptions and leave the protected module untouched, or change the code and its test together. Independence must be structural.

• The builder receives a bounded capability: one tenant, one behavioral surface, a fixed set of allowed effects. It produces an artifact.
• A separate deployment controller holds the policy, acceptance criteria, and activation gate. The builder cannot edit its own acceptance baseline or metrics.
• Scope is measured by semantic effect. A two-character permission change outweighs a large layout rewrite.
• The owner amends policy through a separate process. Autonomous amendment is prohibited. Permanent immutability just teaches agents to route around the policy.

Deployment rules: the complaining user is a reproduction partner, not a canary. She may be the only payroll operator. Canary units follow state boundaries: a draft, a job, a tenant. Code rollback does not undo an email or a duplicate purchase order, so activation requires a recovery plan covering persisted state and external effects. No plan, no autonomous activation.

5The economics of restraint

A weekly change quota fails. Agents fill unused slots, bundle features to evade counting, and resubmit rejected work next Monday. Rationing delays overbuild without discouraging it.

A maintenance ledger changes the incentive. Each accepted customization consumes the customer's support capacity until retired or absorbed into shared behavior. Capacity does not reset. Proposals state benefit, verification cost, new supported states, and upgrade obligations as ranges. Retiring a redundant customization releases capacity. Shrinking a diff earns nothing.

The customer sees the ledger in a weekly digest: what users reported, what changed, what it cost, what was declined and why, what remains Unknown. Do not score the digest on refusals. Rejection counts are as gameable as deployment counts. Traceability earns trust, including the line "resolved with an existing setting."

6Own the fork, maintain the manifest

A thousand diverging codebases is a known failure mode. The underlying problem is obligations, not version control. A thousand forks are survivable. A thousand open-ended upgrade promises are not. Split the artifact along the promise:

• The fork is the ownership artifact. The customer buys it, can export it, and can leave with it.
• The manifest is the maintenance artifact: versioned core, bounded extensions, configuration, behavior examples, pins. The service maintains only what the manifest describes. Every activation verifies the running composition against the approved one. A manifest cannot certify itself.

A customer who diverges past the manifest keeps full ownership. Autonomous maintenance pauses at the boundary with an explicit notice. Re-entry requires fresh compatibility evidence, not a manifest edited to match whatever exists. Ownership and serviceability become separate promises, which removes the unfunded support guarantee that sinks most "own your software" offers. A bespoke fork stays available, with its future verification costs priced at admission.

7Minimum viable implementation

The anti-overbuild system must not itself be overbuilt. Build two things before serving any customer:

• A durable change-record state machine: proposed, admitted, verified, staged, activated, observed, then retained, reverted, or unresolved. Fencing prevents a stale worker from activating over a newer decision.
• One bounded extension surface in one real application. Example: the presentation of a dispatcher's job queue.

Ledger, evidence records, and manifest tooling start as fixed-field prose inside the change records: identities, denominators, minutes spent, reuse disposition. Customer two cannot reconstruct these from customer one's summary, so capture them at the time of work. Convert prose to software only when a second customer demonstrates repetition.

Customer one is a test, not a demo. Serve one real preference, then measure what was reusable for customer two. If each small variation requires full bespoke verification, the cheap-maintenance premise fails for that surface. Learning this costs weeks, not a platform.

8Open question

One question survived the full dialogue: the price of assurance. Every mechanism above adds verification, observation, recovery planning, and carried obligations to the cost of a change. Nobody knows whether the total fits an SMB monthly price. The first implementation exists to produce that number.

Our expectation: the number works for narrow surfaces first. Presentation, ordering, notification, routing. A system that demonstrates restraint on small promises is the only kind that should be trusted with large ones.