Architecture for Disposable Systems(tuananh.net)
tuananh.net
Architecture for Disposable Systems
https://tuananh.net/2026/01/15/architecture-for-disposable-systems/
32 comments
> Rewriting it over and over again in the same manner and expecting improvement is not the kind of engineering I want to do.
let's step back a bit and see this from a single system perspective.
you are already doing it (optimizing a function, a hot code path, etc...) over and over again. albeit much slower than an agent can iterate.
let's step back a bit and see this from a single system perspective.
you are already doing it (optimizing a function, a hot code path, etc...) over and over again. albeit much slower than an agent can iterate.
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.
[1] https://www.inkandswitch.com/essay/malleable-software/
[1] https://www.inkandswitch.com/essay/malleable-software/
As slow and buggy as Photoshop is, an incredibly fast superhuman AI couldn't get much done in 5 minutes or even 5 hours.
In general I agree with you, just not at the extreme.
In general I agree with you, just not at the extreme.
Validating the correctness of AI output seems like one of the biggest problems we are going to face. AI can generate code far faster than humans can adequately review it.
My work is in formal verification, and we’re looking at how to apply what we do to putting guard rails on AI output.
It’s a promising space, but there’s a long way to go, and in the meantime, I think we’re about to enter a new era of exploitable bugs becoming extremely common due to vibe coding.
I vibe coded an entire LSP server — in a day — for an oddball verification language I’m stuck working in. It’s fantastic to have it, and an enormous productivity boost, but it would’ve literally taken months of work to write the same thing myself.
Moreover, because it ties deeply into unstable upstream compiler implementation details, I would struggle to actually maintain it.
The AI took care of all of that — but I have almost no idea what’s in there. It would be foolish to assume the code is correct or safe.
My work is in formal verification, and we’re looking at how to apply what we do to putting guard rails on AI output.
It’s a promising space, but there’s a long way to go, and in the meantime, I think we’re about to enter a new era of exploitable bugs becoming extremely common due to vibe coding.
I vibe coded an entire LSP server — in a day — for an oddball verification language I’m stuck working in. It’s fantastic to have it, and an enormous productivity boost, but it would’ve literally taken months of work to write the same thing myself.
Moreover, because it ties deeply into unstable upstream compiler implementation details, I would struggle to actually maintain it.
The AI took care of all of that — but I have almost no idea what’s in there. It would be foolish to assume the code is correct or safe.
The key flaw in the argument is that high quality interfaces do not spring to life by themselves. They are produced as an artifact of numerous iterations over both interfacing components. This does not invalidate the entire article, but interface discovery phase has to become the integral part of disposable systems engineering.
I agree with your comment. but in defense of the articles scope: as someone trying to build longterm utility and developer infrastructure, I find the vibecoded prototypes to help me dial in on interfaces. Instead of waiting to hear back from only downstream user experiences (because you previously didn't have time to experience the various consequences of your choices yourself), you can get the various experiences under your own belt, and better tune the interfaces :)
Which is to say, the interface exploration comes part-and-parcel with the agent tooling in my experience
This comment is a little orthogonal to the content of the article, but my experience made what they wrote click with me
Which is to say, the interface exploration comes part-and-parcel with the agent tooling in my experience
This comment is a little orthogonal to the content of the article, but my experience made what they wrote click with me
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?
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.
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.
Doesn't seem to translate into not constantly changing UIs over and over and over again, unfortunately
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.
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.
might work for internal applications where you may not care about UI/UX much. But for client facing applications you want to be little more careful.
> This created a culture of careful engineering: clean code, thoughtful architecture, and refactoring to reduce technical debt.
I wish!
I wish!
I'm sure you'll get a tech debt sprint after the current feature is done
Disposable architecture is a luxury of stateless systems. Once you deal with financial ledgers or tax compliance, the cost of "disposing" and rewriting a component is astronomical because of the audit trail requirements.
Reliability in fintech isn't just about a clean interface; it's about the historical context of every transaction. If you treat your core logic as disposable, you aren't just swapping code, you're risking the integrity of the data history, which is the actual product.
Reliability in fintech isn't just about a clean interface; it's about the historical context of every transaction. If you treat your core logic as disposable, you aren't just swapping code, you're risking the integrity of the data history, which is the actual product.
I don't buy the idea of immutable contracts becoming more common with AI assisted coding. One of the areas AI shines is coding against a spec. One of the big problems in old systems is that the cost of upgrading consumers to a new API version gets too expensive. Using AI agents you can just do it for them. Refactoring getting cheaper isn't going to make API contracts immutable its going to make them more mutable.
Isn't the "Disposable System" in TFA the actual AI?
Today you have to have it write some software to accomplish a task and it's pretty obvious what's going on but when the AI itself becomes the UI then it doesn't matter as much, are the steps to complete a task the goal or is it the end result?
The only thing really stopping the commodification of software is the development of said software.
Today you have to have it write some software to accomplish a task and it's pretty obvious what's going on but when the AI itself becomes the UI then it doesn't matter as much, are the steps to complete a task the goal or is it the end result?
The only thing really stopping the commodification of software is the development of said software.
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?
The problem is that if both your interface and implementation are variables where AI can make arbitrary changes with full agency and little verification, maintenance becomes tricky as your understanding of the system as a whole dwindles.
It’s better to be on top of the interface than the implementation. But at the same time, brittle systems caused by overly rigid interfaces are a real thing. In that case, interface exploration can be done by a human with assistance from LLMs, but allowing an LLM to arbitrarily explore and make changes to the interface sounds like a recipe for disaster.
It’s better to be on top of the interface than the implementation. But at the same time, brittle systems caused by overly rigid interfaces are a real thing. In that case, interface exploration can be done by a human with assistance from LLMs, but allowing an LLM to arbitrarily explore and make changes to the interface sounds like a recipe for disaster.
It's not new. These are still the old principles, such as clean architecture and onion architecture. The main idea of all these architectures is that you separate your domain/business logic and application interface from the "details", so that you can swap the "details" any time.
true. if you already follow all the best practices & principles from the "old days", you will be fine :)
> 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.
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.
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
In other words, focus on the interface and not on the module implementation. In the control theory domain we call this black-box modelling.
jackfranklyn(1)
On top of that, Hyrum’s law doesn’t go away just because your software has explicit contracts. In my experience, as more people start losing their agency over the code they generate, the system accumulates implicit cruft over time and other code starts depending on it.
Also, reliability is a reasoning problem. So operational excellence becomes scrappy with this way of working. It works for some software, but I don’t know whether this push to YOLO it is actually a good thing. C-levels are putting immense pressure in many big companies for everyone to adopt these tools and magically increase productivity while decreasing headcount to please investors. Not going too well so far.
A good interface doesn’t magically make vibe-coded implementations with little oversight usable. Rewriting it over and over again in the same manner and expecting improvement is not the kind of engineering I want to do.