> Claude can make decisions about architecture

but they are often not very good decisions, and sometimes absolutely terrible

I have to kick it back onto the right track, but as you sort of point out, I got that experience from making my own terrible decisions and finding out the hard way the blind alley I was walking up.

Second system, inner platform, too general, planning for scenarios that never happen, stuff that doesn't scale, making a giant OOP class taxonomy - I've made them all.

I think I learned as much from reading as doing though, I could later put names on the mistakes I made.

So, for what it's worth - study the meta. Read about architectural theory, system design

Study the craft and listen to the masters - https://www.youtube.com/watch?v=LKtk3HCgTa8

And when you talk to Claude say "follow rich hickeys advice about explicit rules" and it knows what you mean more than you do !

The GIGO principle in computing was invented in the 1950s but still applies today: https://en.wikipedia.org/wiki/Garbage_in,_garbage_out . If a developer gives garbage prompts to the AI, they will get garbage results. You, yourself, still need to develop expertise in all the areas a software engineer was traditionally strong in, ranging from languages to architecture, because you need that expertise to craft LLM prompts that are not garbage and to recognize the LLM output that is worth keeping instead of discarding. Otherwise you will wind up as a sockpuppet operated by the LLM. (Many AI advocates will suffer that fate.)

Fortunately, LLMs can be your ally since it can be an effective explainer, search engine to find learning resources, and provider of demo code. But you have to do the work to get the expertise into your own head.

Either you become the master of AI tools or AI tools will become your master, those are your choices.

Make LLMs a part of your workflow. Use it like any other tool. It's where the industry is headed.