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.
- 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.
- 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.
- 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#
- Disposable Micro-Apps: copy-back-to-markdown, "design the ideal interface for this problem", the abundance rationale
- The HTML Artifact Lifecycle: Where Plan History Lives, and When Disposable Becomes Durable: generator-as-reuse-unit, graduation conditions, the un-chosen middle
- Does the Human-Facing Harness (HTML Artifacts) Hit Its Own Bloat Ceiling?: the ceiling relocating from length to sprawl
- Living Design System: the durable counterpart and its maintenance cost
- Agentic Work Systematization and From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained: the skill lifecycle measurements (53%, 40.2%, 6.1:1, executed-not-read)
- Knowledge-Centric Self-Improvement: Library Drift and Metis as characterized by The Last AI Built by Humans: Toward Genuine Recursive Self-Improvement §3.5.3
- Compute Allocator, AI Brain Fry: attention as the binding constraint; +11% / +39% error rates past capacity
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
- Harness Shrinkage as Models Improve
Prompt scaffolding shrinks each model release; Cat Wu's pruning discipline; Boris Cherny "100 lines of code a year from…
- HTML as the New Markdown
Thariq Shihipar's thesis: as models improve, thousand-line markdown plans overwhelm the *human*; HTML artifacts (visual…
- Compute Allocator
The human's evolving role: deciding what's worth spending compute on; ~1% of generated tokens ship, 99% is scaffolding…
- The HTML Artifact Lifecycle: Where Plan History Lives, and When Disposable Becomes Durable
Two-question synthesis on the lifecycle of human-facing HTML artifacts. (1) The diff/version problem dissolves once the…
- Disposable Micro-Apps
Throwaway custom UIs built per-task to edit a plan ("micro-software on top of micro-software"); copy-back-to-markdown;…
