This article is very rambling and somehow manages to miss the most important driver of reduced software quality: shifting requirements.
You can have the most beautiful perfect design that leverages the greatest abstractions in the world, and then have it all entirely destroyed by a single requirement shift that totally kills your abstractions.
well you cannot design for the unpredictable, but well designed code is going to make refactoring easier anyways
If the design is so inflexible that a single requirement shift destroys it, then it wasn't a good design.
That's a refutation of agile, Vibe Coding and the last 25 years of the software industry.
One of my own quality metrics that almost everyone rejects is a "a good design is a design where a change that seems like a small change to management is... a small change"
It plays out like this. To get to product-market fit you are going to have to zig and zag 20 times. Everybody optimizes for the first step of this journey and then on the second step they optimize for that... and by step 5 or so the archiecture is exhausted and you have no hope of getting to step 20. The rare team that is looking ahead 20 steps is the one that survives.
Completely untrue. Every design can be destroyed by a single poorly-thought out requirement. I can take down Facebook's design just by saying "any edit must immediately be visible to all users".