One of the things I loved about software development was that we were always trying to get better at it, and there was no ceiling in sight for that. Using LLMs to make code is the opposite of that - learning to use them is more akin to learning rituals than it is to intellectual development. And don’t give me that nonsense about it being like using a compiler to move up an abstraction level; it’s not, any more than becoming a manager is coding at another level of abstraction.
I lived through the era in the noughties when the only promotion available outside management was to become a “software architect”. This was supposedly another level of abstraction over development and these experienced developers would level up the whole process by being dedicated architects. And you know what happened if those architects didn’t still actively write code too? Their designs were absolute garbage.

@sinbad no software architecture survives the first contact with code.

The fun thing is that when I was talking to guys at construction sites about the plans they receive from architects, they always needed to “compensate” to be able to actually build the thing.

We saw the same thing when doing architectural visualisation based on 2d plans. And 99% of architectural plans were only 2d.

So it’s not just a software issue.

@martinweber when we renovated our house I deliberately hired an architect who was also an engineer, so he didn’t just do the high level stuff but all the structural/technical engineering detail as well. There were still detail things to resolve but I think it was far more practical

@sinbad @martinweber at a certain size you NEED an architect. I've seen so many "organic" codebases that were never refactored, but also where nobody had a clue about the big picture. Every engineer just had a view of their own specialized sub-domain, with nobody to effectively coordinate them and plan the systems evolution for 6, 12, 24 months onwards.

Those folk were all very clever people. But the lacked the overview but also sometimes interest for the big picture

@kwramm @sinbad @martinweber A lot of organisational, and architectural problems can be resolved by having product pass tickets through the tech lead who can then have architectural oversight, rather than throwing them out direct to the headless chickens.
( Often unpopular due to internal politics, but there it is. Beats adding another lame duck flapping round the periphery after things go wrong. )
@kwramm @sinbad @martinweber And yea.. Agile is sposed to solve that stuff, and maybe given the right team everyone cooperates and gets things right all the time, but ... A problem that is everyone's responsibility is very often, no one's responsibility. Or at best, down to fortune.