Juan Piaggio · 2026-08-10 · 7 min read · ai · architecture · product-development
A product manager needs to see every ticket that changed owners twice this sprint, grouped by team, sorted by age. There is no screen for that. There will never be a screen for that, because they need it once, today.
Increasingly the answer is not "file a request" or "export to a spreadsheet." It is a generated view that exists for the ninety seconds it takes to answer the question, and then does not exist at all. Analysts have started calling these disposable modules, and the interesting part is not the generation. It is what disappears along with the interface.
Every mature product carries a long tail of workflows that are individually rare and collectively enormous. Each one is a legitimate need and none of them survives a prioritization meeting, because the honest estimate is two weeks of work for four people who will use it twice.
So the tail goes unserved. Users route around it with CSV exports, pivot tables, and a Slack message to whoever knows SQL. That is disposable software already — just assembled by hand, off-platform, with no permissions model and no record that it happened.
Seen that way, generated single-use modules are not a new risk category. They are a chance to bring an existing shadow workflow back inside the system, where it can be governed. That reframing matters, because the instinct is to compare generated UI against your polished product surface. The right comparison is against the spreadsheet it replaces.
Durable software gives you guarantees you stop noticing until they are gone.
Review. Your permanent screens were designed, reviewed, tested, and shipped through a process. A module generated at request time has no such history. There is no reviewer, no test, and no second pair of eyes between the model's output and the user's screen.
Tenant boundaries. This is the one that keeps me up. A hand-written query in a multi-tenant system is written once by someone who knows the rules and reviewed by someone who also knows them. A generated one is written fresh every time by something that has read a lot of code, much of it single-tenant. The failure is silent: the results look plausible, and nobody notices the rows that should not be there.
Auditability. Permanent features are self-documenting — the code is the record of what the system can do. If a module existed only during one session, the question "what did that person see, and was it theirs to see?" has no artifact to answer it.
Ephemeral output is fine. Ephemeral authority is not.
The distinction that resolves most of this: the interface can be disposable, the permissions and the record cannot.
A generated module should never author its own data access. It should be composed from a fixed set of governed operations — the same ones your permanent features use, carrying the same tenant scoping, the same role checks, the same rate limits. The model chooses which operations to call and how to arrange the results. It does not get to invent a new way to reach the database.
This is exactly the shape of a governed tool hub. In Meshworq, agent access runs through an MCP layer where every tool is registered, every call is scoped to the caller's workspace, and no tool accepts a workspace argument at all — the tenant anchor comes from the verified token, never from something the caller can influence. An id being well-formed is not evidence it belongs to you; it has to be proven in-workspace before use. Those assertions were built for external agents, and they turn out to be precisely what generated modules need. The model composes; it never widens its own reach.
With that boundary in place, the properties come back:
Good candidates share three traits: read-mostly, short-lived, and easy for the user to sanity-check. Ad-hoc reporting views. One-off cross-sections of data the user already knows well enough to notice when a number looks wrong. Exploratory slicing during an incident.
Bad candidates are the inverse. Anything that writes state, anything a decision hangs on weeks later, anything a user cannot independently verify, and anything a regulator might ask about. The failure mode is not a broken interface — those are obvious and harmless. It is a plausible interface presenting a subtly wrong number that someone then acts on.
Two practical guardrails worth having from day one. Put the whole capability behind a feature flag that can turn it off in a single step, because the first genuinely surprising output will arrive and you want an immediate answer that is not a deploy. And show the user what the module actually queried, in plain language, above the results. A one-line "this is what I looked at" turns an opaque answer into something a competent user can check, and competent users checking things is your best detection layer.
Disposable modules serve the long tail of workflows that will never justify a permanent screen, and the honest comparison is not against your polished product — it is against the CSV export and the Slack message to whoever knows SQL. The pattern is safe when the interface is the only disposable part. Compose generated views from a fixed catalogue of governed, tenant-scoped operations, keep the audit record even when the UI evaporates, put the whole thing behind a kill switch, and show users what was queried. Ephemeral is a property of the screen. It should never be a property of the guardrails.