H
Howardism
Plate IIAI Coding PracticeHOWARDISM

Where Disposable Micro-Apps End and Tool Sprawl Begins

A micro-app stays disposable while three conditions hold. (1) It owns no state the canonical text doesn't also hold: the copy-back-to-markdown round-trip. (2) Nobody keeps it after the edit. (3) When it recurs, the generator is reused, not the app. Break any one and it is sprawl. On that line the workflow does not fragment on state, because one source of truth survives every edit by construction. But the earlier answer's prescription, 'reuse the generator, i.e. a skill', moves the sprawl risk into the skill library, and there the corpus has measurements. 53% of reused skills are never modified. 40.2% of the never-updated ones miss upstream changes. Locally authored skills add content at 6.1:1 over deletions. Library Drift finds unbounded accumulation degrades retrieval before task scores show it, while over-aggressive retirement does worse than no curation. So sprawl is a lifecycle problem at the generator layer (cap plus measured retirement), not at the app layer. What stays unmeasured is whether a different generated interface for every edit costs the human more re-orientation than it saves in fit. The corpus has one practitioner demo, so that needs a user study.

Article metadata
Publication details
Published:October 21, 2026
Filed:Essay
Domain:AI Coding Practice
Reading:7 min
Source:AI-synthesised
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

Illustration for Where Disposable Micro-Apps End and Tool Sprawl Begins

The question#

From Disposable Micro-Apps: where is the line between a disposable micro-app and tool sprawl, and if every edit spawns a bespoke UI, does the workflow fragment?

Two earlier syntheses come close. Does the Human-Facing Harness (HTML Artifacts) Hit Its Own Bloat Ceiling? argues the bloat ceiling relocates from document length to artifact sprawl. The HTML Artifact Lifecycle: Where Plan History Lives, and When Disposable Becomes Durable names the reuse unit (the generator, not the artifact) and the failure state (apps kept unmaintained). Neither states the line as a test, and neither checks the prescription against measured data. This page does both.

The line: three invariants#

A micro-app is disposable while all three hold. It becomes sprawl when any one breaks.

  1. It owns no state. The defining move in Thariq's example is the button that "copies the final configuration back to the clipboard as markdown." The app is "a transient editing surface over durable text" (Disposable Micro-Apps). If the result of an edit lives only in the app, the app has become a second source of truth, and that is the first kind of sprawl.
  2. Nobody keeps it. Once the edit is copied back, the app has no remaining value, because it was fitted to one decision ("design the ideal interface for this problem"). A kept app pays a durable artifact's costs: sync and maintenance, a seat under the attention ceiling. It also lacks the one property that justifies paying them, recurrence, sync pressure and an audience. The lifecycle page's rule applies here: regenerate it, or maintain it; never merely keep it.
  3. What recurs is the generator. If the same kind of edit comes up again, template the prompt (a skill), not the HTML, so each regeneration is fitted to its new case (The HTML Artifact Lifecycle: Where Plan History Lives, and When Disposable Becomes Durable).

These invariants are checkable on any artifact: does it hold a value the text doesn't, is it still around after the edit, and is it being reopened when it should be regenerated?

Does the workflow fragment?#

There are three senses of "fragment", and they get different answers.

State: no, by construction, while invariant 1 holds. Every edit round-trips through the same markdown or config, so a hundred bespoke UIs still leave one source of truth. This is the same compiled-view argument the lifecycle page makes for plan history: version the content layer and let the presentation layer be thrown away.

Generator library: yes, and this one is measured. Invariant 3 doesn't remove sprawl. It moves it into the skill library, and the corpus has data on how skill libraries behave in practice (Agentic Work Systematization, From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained, empirical, about 41.6k skills across 5,876 repositories):

  • Skills are adopted and then left alone. 53% of reused skills are never modified. Among those never updated locally, 40.2% missed at least one upstream change.
  • Maintenance only adds. Locally authored skills add content over deletions at 6.1:1.
  • Stale skills get executed, not just read. "A human reading an out-of-date README can identify and bypass the discrepancy, whereas an agent consumes a SKILL.md and acts on its environment."

The persistent-store literature says when this begins to hurt. Library Drift finds that unbounded accumulation "gradually degrades retrieval quality and stalls progress, often before the effect becomes visible in task scores." Its fix is an evidence log, retirement once a skill's measured contribution fades, and a cap on active skills. It also warns that "retiring skills too aggressively performs worse than leaving the library unguided" (Knowledge-Centric Self-Improvement, survey characterization; the primary is not in raw/). So "reuse the generator" is the right prescription with a missing step. The generator layer needs the lifecycle the app layer gets to skip. Promote a micro-app pattern into a skill only after it recurs. Then retire the skill on measured disuse, not on a schedule. Metis's rule, promoting text to a callable tool only after cross-task recurrence and sandbox checks, is the recurrence gate already built.

Attention: predicted, not measured. The remaining sense is the human cost of meeting a new interface on every edit. The bloat-ceiling argument predicts a threshold: attention is the conserved resource (Compute Allocator), and oversight past capacity raises minor errors by 11% and major errors by 39% (AI Brain Fry). A generated UI is optimized for one decision. It is not built to stay familiar from one edit to the next. Nothing in the corpus measures whether an interface fitted to each edit saves more effort than relearning a fresh interface every time costs, or at what number of edits per session the trade reverses. The only evidence is one expert practitioner's demo (How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development). Settling it needs a user study comparing per-edit generated UIs against a fixed editor and against chat edits, at increasing edit volume. That is external evidence, so the residue is #oq/source.

Answer#

  • Settled: the line is the three invariants (stateless via copy-back, unretained, recurrence captured as a generator).
  • Settled: the workflow does not fragment on state while copy-back holds.
  • Settled, with measured support: it does fragment at the generator layer unless skills get the cap-and-retire lifecycle Library Drift describes. That is where the "tool sprawl" in the question actually builds up once the earlier "reuse the generator" advice is followed.
  • Open: the attention cost of per-edit interface churn. It is predicted by the bloat-ceiling argument but unmeasured, and it needs a source.

Citations#

§ end
Cited by 4
  • Disposable Micro-Apps×2

    Where's the line between a disposable micro-app and tool sprawl? If every edit spawns a bespoke UI,…

  • Agentic Work Systematization

    Micro App Line And Generator Sprawl — uses this page's skill-lifecycle measurements (53% never…

  • AI Coding Practice

    Micro App Line And Generator Sprawl — A micro-app stays disposable while three conditions hold. (1)…

  • Open Questions Backlog

    Disposable Micro Apps: Where's the line between a disposable micro-app and tool sprawl? → Micro App…

Related articles