I think this has as much to do with how hard software became to understand as with the new shortcut to refusing to understand it and the shortsightedness in willing to take it.
replyWe lost a lot of traction in the name of ease of staffing and speed. Using LLMs to generate more code that is harder to understand it catalyzes it but the root of the problem, in my opinion, was letting go of great design and deep understanding for short term profit.
I've been thinking about this lately - is it like using 3rd party libs to achieve stuff faster? As much as I would lovr to hand craft the datetime logic in my app, I might as well use luxon and invest this time somewhere else. Only now with llms, you get virtually infinite 3rd party libs you can use, you create them on the fly. So if you have strong engineering values, I would say simply it boils down to "contracts over programs", you can still be in touch with the logic that glues it all together and treat some logic as a blackbox the same way we do with 3rd party libs?
replyConsidering how many compromises and problems third party libraries have caused recently, I would say the comparison is apt - if you don't know what you're shipping one day it might explode on you
replyIt's not because with libraries you have a boundary somewhere and can decide to not care what's inside as long as the interface is stable and well designed. The problem of course you need to prioritise building well designed interfaces and decouple components from each other, and that's a skill most developers aren't good at.
replyModels are getting better. Astra for example refactored some code GPT-5.6 Sol wrote and extracted some related functionality in a separate file without prompting.
replyThe models are also becoming very capable of suggesting architecture simplifications, but you need to ask for that, and you probably need some taste in picking from the suggestions, although the default ones are quite decent.