Valérian de Thézan de Gaussan
When something costs almost nothing to produce, we stop treating it as something worth preserving.
Think of fast fashion. When a T-shirt from SHEIN costs €5, you probably will not bother sewing it back together. You replace it. A €150 shirt made by a tailor? You are much more likely to get the sewing machine out.
The same goes for IKEA furniture. And plenty of other things whose production costs keep falling. When replacement feels cheap, repair starts to feel pointless.
You can probably see where I am going with this. I work in software, so of course I am going to talk about AI.
Cheap code, expensive maintenance
For some applications, AI has brought the cost of producing code close to zero. That is excellent news. But it does not mean the cost of maintaining that software has followed it down.
In fact, I think there is a trap here:
Near-zero production cost → little personal investment and little upfront thought → fragile architecture, often poorly modularized and difficult to change.
This is not inevitable. Cheap code does not have to be badly designed. But when producing the next version feels almost free, it becomes very tempting to skip the thinking that would make that version easier to maintain.
“Yes, but if I need to change something, that change will also be quick and almost free.”
Maybe. But the cost is still your time multiplied by how often you need to make those changes. And software changes often, especially software that succeeds. New features, new integrations, schema changes, performance improvements. The first working version is the beginning of that work.
There is also a harder problem: the change you need might not be possible within the architecture you have.
I have seen this happen with an application that used OpenSearch as its primary database. Later, we needed relational queries. What had seemed like an acceptable choice at the beginning became a very expensive constraint. Generating more code could not turn OpenSearch into a relational database. And the cost of changing? Insane. It still runs on OpenSearch today, features were never build and users pissed.
The initial decisions, including the decisions nobody consciously made, shape what you can do next.
“We will just rebuild it”
“If the application becomes unmanageable, we will rebuild it.”
That reversibility is largely an illusion.
The more users, data, integrations, and implicit behaviors a product accumulates, the harder it becomes to rebuild, even if generating its code remains easy.
You need to understand what the existing system actually does. You need to migrate the data. You need to preserve the behaviors people rely on, including the ones nobody documented and the ones nobody remembers implementing.
A replacement that looks right in a demo is not necessarily a replacement that existing users can move to without disruption.
The cost of producing code is falling. The cost of understanding, migrating, and preserving existing behavior is not necessarily falling at the same rate.
That is why I would be careful about treating software as disposable just because it was cheap to create.
Do not treat something as disposable when it is gradually becoming irreplaceable.
I have four more points to develop on this subject, but this article is long enough already. I will come back to them in the next few posts.
In the meantime, here is my IKEA BILLY bookcase after two house moves. As you can see, it has not taken them well. I am going to reinforce it while I look for something else for that spot.
Cheap to replace, perhaps. For now, I am repairing it.