The contract stability bit rings true from my experience. I've built a few B2B integrations that follow this pattern naturally - the data layer and API contracts are rock solid because changing them means coordinating with external systems, but the application logic gets rewritten fairly often.
Where it gets messy is when your "disposable" layer accumulates implicit contracts. A dashboard that stakeholders rely on, an export format someone's built a process around, a webhook payload shape that downstream systems expect. These aren't in your documented interfaces but they become load-bearing walls.
The discipline required is treating your documented contracts like the actual boundary - version them properly, deprecate formally, keep them minimal. Most teams don't have that discipline and end up with giant surface areas where everything feels permanent.
anything exposed for others to depend on becomes part of the actual boundary. if it might break someone's system when you change it's part of your API.
the problem is not in documenting the subset of a giant surface you intend to support; the problem is having a giant surface!
I like the perspective and phrasing. Build the foundation carefully and vibe code colors on the wall, decoration in the room, and design of wallpaper/carpets
Want a dashboard from an API with openapi docs or from SQL database with known schema, or want a quick interactive GUI that highlights something in `perf stat` data, unleash claude.
Too much emphasis on contracts could lead to rigid integrations, that are not allowed to evolve or be flexible. This might become a source of brittleness in the system. What if AI is allowed to discover the changes to API contracts and change the interactions accordingly, make components decouple, giving them some room to evolve, providing more reliability?
I think that Disposable System can combine very well with Malleable Software[1]. Imagine a program, photoshop as example, with a plugin system and builtin Code Agent, if by default the program doesn’t have the tool you want, you could ask the agent to create the tool in 5 minutes. Each user will have an unique set of tools, and a program molded for him.
Exactly where I figured it was going. LLMs generate too much "magic" unmaintainable code, so when it breaks just hope the next model is out and start all over
I think we have enough anecdata that users don’t like a changing interface. They like keeping things the same, mostly.
So how can you keep generating disposable software on this layer?
And what you mostly want to change in software, is new features or handle more usage. If you do that, it needs in most cases changes to the data store and the “hand crafted core”.
So what part in practice will be disposable and how often will it be “generated again”?
Maybe for simple small stuff, like how fast Excel sheets are being made, changed and discarded? Maybe for embedded software?
> So how can you keep generating disposable software on this layer?
Well... If your "users" are paying customers of a XaaS Subscription service, then there's propably little need and/or room for disposable UI.
But if you're doing something for internal processes with maybe 2-3 users at max, then you might want to do something that does not result in launching an under-budgeted project that could be a full blown SaaS project on its own.
I think embedded software would be like the anti-case for OP's idea. It's a resource-constrained environment, and you also cannot upgrade things easily, so the "replaceable" parts of the software become nothing.
> As software gets cheaper to produce (thanks to coding agents) and quality expectations shift
Shifting quality expectations are a result of the load of crappy software we experience, not a change in what we want from software. I.e. not a good thing, allowing us to ship crap, because people "expect it", it simply means "most software is crap". So not a good thing, but something we should work against, by producing less slop, not more.
Where it gets messy is when your "disposable" layer accumulates implicit contracts. A dashboard that stakeholders rely on, an export format someone's built a process around, a webhook payload shape that downstream systems expect. These aren't in your documented interfaces but they become load-bearing walls.
The discipline required is treating your documented contracts like the actual boundary - version them properly, deprecate formally, keep them minimal. Most teams don't have that discipline and end up with giant surface areas where everything feels permanent.
the problem is not in documenting the subset of a giant surface you intend to support; the problem is having a giant surface!
I wish!
Want a dashboard from an API with openapi docs or from SQL database with known schema, or want a quick interactive GUI that highlights something in `perf stat` data, unleash claude.
[1] https://www.inkandswitch.com/essay/malleable-software/
So how can you keep generating disposable software on this layer?
And what you mostly want to change in software, is new features or handle more usage. If you do that, it needs in most cases changes to the data store and the “hand crafted core”.
So what part in practice will be disposable and how often will it be “generated again”?
Maybe for simple small stuff, like how fast Excel sheets are being made, changed and discarded? Maybe for embedded software?
Well... If your "users" are paying customers of a XaaS Subscription service, then there's propably little need and/or room for disposable UI.
But if you're doing something for internal processes with maybe 2-3 users at max, then you might want to do something that does not result in launching an under-budgeted project that could be a full blown SaaS project on its own.
Shifting quality expectations are a result of the load of crappy software we experience, not a change in what we want from software. I.e. not a good thing, allowing us to ship crap, because people "expect it", it simply means "most software is crap". So not a good thing, but something we should work against, by producing less slop, not more.