Code is the God in the machine.
Then God has no soul.
Yes, code defines what happens, how it happens. But what defines what the code is intended to do? Where is the intelligent design? You can wire up a bunch of relays with intelligent design, simple electrical work, define gates, build the gates into memory registers and arithmetic processing stages, make a CPU - but... are you any closer to achieving the goal for having done all that work?
Are you better off for having a hands-on deep understanding of the machine from electrical first principles, or does the warehouse full of circuits and wires and the power it consumes outweigh that benefit?
If you use a modern processor do you need to have hands-on the assembly code? Do you need to deconstruct and understand every stage of the compilers and linkers and optimizers? In the 1990s I did, because those stages weren't reliable enough, yet.
There's nothing different about "deterministic code" built on layers and layers of tools today than there was about assembly code built on the processors before than there was about assemblies of modular circuits that form processors and memories and peripherals... it's all parts of the system. And for critics of the "unpredictability" of LLM code generation, you might want to look into the mysteries of "garbage collected" languages.
If I eventually stop writing C or Rust or Go or Python or Javascript or any of the other hundreds of common choices of languages out there and instead learn to feed a LLM with instructions that generates the Rust that generates the Assembly that drives the CPU that manipulates the electron flows - that doesn't change the intelligent design of: making a thing do what it is intended to do.
The interesting thing, to me, is how much/little architectural level design matters depending on the complexity of the system you have built, and the longevity of its maintenance in the field.
I watch things get built with bad architectural compromises for what appear to be bad reasons all the time, and they rarely "come home to roost" until years later... then the question becomes: was the implemented design a success for having gotten to market quicker and lasted so long without serious problems, or a failure for having created a mess 5 years down the road that could have been addressed with a 5 day delay of launch for a refactoring? Or, should we instead spend 5 weeks attempting to predict the optimal architecture before we even start and maybe get a good solution or maybe still end up learning things we didn't know during early development - and when we learn those things down the line from the initial architecture specification, when it it time to slaughter the sacred cow and re-arrange things?