In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later.
E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.
Framework authors have their own incentives (relevance, employment, hiring funnel) and aren't optimizing for your project's longevity. The only way to write 20-year code today is either (a) work in an ecosystem that genuinely values stability (Lisp, C, parts of Erlang/OTP, Postgres) or (b) accept the tax of a modern stack and budget for it explicitly.
Most teams do neither, which is when projects rot fastest.
The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree.
At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.
While reading this, I was literally working on patching my open source go app [1] because this is what came out of the stdlib in the last few months: CVE-2025-30204, CVE-2026-33487, CVE-2026-25679, CVE-2026-27137, CVE-2026-32280, CVE-2026-32281, CVE-2026-32283, CVE-2026-33810, CVE-2026-33811, CVE-2026-33814, CVE-2026-39820, CVE-2026-39836, CVE-2026-42499
But modern Java developers don't want to write this way, it's not "modern".
I guess incentives aka "job security" is the main force here. Would you rather say that a piece of software is "done" and can keep working for decades with only periodic maintenance required, or would you rather "we need to migrate from Quux to Baar as Quux is deprecated and unmaintained now, and Bazz might not be optimal from performance standpoint so we need a replacement. so yeah we'll be busy this year"?
And conference people are so helpful with "Baar is the only valid way to make Java now. If you think about rawdogging JCL you're a goblin"
If a clojars package hasn’t been updated in 6 years, I don’t even think about it!!
The fact is because they themselves are not capable of producing perfectly reliable software, they assume that everyone else is the same. With this narrow-minded worldview, you would expect software to require constant updates as the maintainer is essentially playing a never-ending game of whac-a-mole.
Not all technologies change. Often, low-level engine APIs are very stable and essentially never change... So why should the software built on top change?
According to OP, the kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. So they are doomed to create AI slop on top of other AI slop. Good luck to them.
Main reason I avoid buying anything that requires an app. Because one day that app won't be maintained anymore and it just wont work, bricking the hardware in the process.
But on contrary, business incentive is to make "everything app" which needs to be continuously patched.
We had a recipe for a much stabler stack decades ago: separate runtime (might need to be patched regularly) from a high-level business logic (never needs to be patched if done properly).
E.g. old way of developing web front-end was like that: you code directly in JS. It never needs to be patched, only browser needs to be patched.
Same thing with Excel/VBA, etc.
But new devs don't know any of that, they just want to use latest "framework" which pre-installs whole bunch of vulns. And if there's a patch you need to rebuild. Constant churn just to satisfy the trend
A C program which just manipulates strings and other data structures can have a remote code execution vulnerability because C is a shitty language with no memory safety, data and control flow can be mixed, etc.
But that's just not true for high level code, say, in Python. If you don't use some low-level hacks, Python code just cannot corrupt memory, by construction, and it cannot cause RCE. You can execute attacker's code only if you use a language function which might execute code, say, eval or unpickle. But there's only a handful of such constructions and Python developers could easily implement hardening which would forbid any such calls, guaranteeing that only code which was written by developer gets executed.
Yes, occasionally there might be a logic flaw in code which needs to fixed, but it's not same as weekly updates - framework version 1.2.3 uses package 4.5.6 which has a vuln. That's only recent lunacy.
I'm not saying that e.g. everything written in Python in safe - but that old platforms were almost ready for "works forever" software, and we don't have that anymore,.
Flawed business logic might corrupt data, but that's much less rare than security vulns, and might be solved by versioning data (e.g. copy-on-write, even Windows had Volume Shadow Copy service which can take a snapshot of all data).
The main problem is that there's no incentive for software vendors to separate parts: e.g. app which processes financial records might also send/receive data over internet. If user had a more explicit control over flow of data (e.g. imagine n8n style pipeline) many logic flaws like sending data to wrong place could be eliminated.
It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.
The problem is that the business logic tells everything else what to do and has authority to do everything that the program can do. Exploiting that way is fiddlier (it's like doing ROP only more so), but ultimately once the software gets into an unintended/unexpected state it's game over.
> It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.
Many have tried. If you try to require fine-grained permissions and user in the loop people just say yes to everything. Ultimately the user thinks they want to do the thing they said to do, and asking them again won't change that.