I hear a lot of stories like this; but the question I always come back to is - what incentive is their to discard the working system? In your case its the 3qc step process, why is that just gone now?
The more I look into these systematic changes the less sense it makes.
Fair points, but I think you're responding to an argument my piece isn't quite making.
The complaint isn't that logistics should follow Moore's Law or that we need same-day delivery for everything. It's that we're paying more for objectively worse service than we had a decade ago. Services aren't "adapting to consumer needs", its just objective decay being masked as optimization.
The Lettre Verte example actually reinforces the point: service got slower, then slower again, not because physics demanded it but because maintaining the previous standard became inconvenient. The dedicated sorting train wasn't decommissioned because trains stopped working; it was decommissioned because the institution decided the mail didn't matter enough to run it.
Nobody expects sea transport to break the sound barrier. But when 73% of consumers experience an outright delivery failure in a three-month period, that's not bumping against hard physical limits. That's drivers marking packages "delivered" that weren't, because lying clears the route faster. That's solvable. We're just in a system that doesn't incentive fixing it.
The asymptotic argument would land if we were approaching some theoretical maximum. We're not. We're sliding backward from where we were, while costs rise. I'm not asking for magic, I'm asking where went the reliability we already had, at the prices we're already paying.
I like the idea of its spec docs and steering format but found it very underwhelming to try and use them, often they caused more confusion of the AI then functional code.
I've noticed with nearly all of these "Vibe Code" security fatalities, they're nearly ALWAYS using Firebase as a backend. I get it, I've used Firebase for a number of enterprise and personal projects, its convenient and easy to setup.
But even before LLM coding, I had team members walk into its numerous footguns - especially around public buckets and bad firestore rules. How many of these stories are really to be blamed on the AI tooling, and how many could be blamed on the very poor default settings of Firebase?
You are touching on an inherent truth in TFL, which is that there are nearly infinite equivalent statements for any logical sentence.
The idea for the article was to make a real example of logical equivalence, as books on the subject stay pretty abstract. - like others have mentioned, in the real world there are smarter choices to be made.
> something is wrong in the industry, or how management roles are filled, or how wealth and influence and opportunities are distributed generally.
And will you be able to fix these issues within your own lifetime? Will you be able to turnover the behemoth of bureaucracy and golf playing managers that has become the technology industry?
If not I highly suggest adopting the Julius mentality.
I have to say I became a lot happier in this field once I aligned myself more with Julius.
I think what happens to developers and engineers is that since we have the ability to attune our toolsets very specifically to our needs, we assume everyone can do the same.
This is untrue. Most people live a life of hodge-podge technical solutions that don’t work very well, meaning their expectations for how software should work is supremely low.
Once I understood this I became Julius. Management does not care how or why the software does or doesn’t work - they just want 12 rules for life style platitudes and charisma.
The part about sending Julius to meetings while everyone else worked to fix things particularly stood out. The meetings are useless, but that’s where everyone glad hands. Gladhanders get raises.
The difference is that I like to think I’m still pretty good and doing my job. I’m just acknowledging that pure l33t skills does not a career ladder make. If anything it could even be a hindrance.