I think we'd be talking past each other in terms of what "planning" means, but i wrote this anyways:
You're wrong about what i mean with delegating architecture to coding agent.
I'll let the coding agent take the first shot at it, already having in my mind a decent idea about how i'd do that. Worst case its wrong i need to correct it, more than half the time it comes up with the same sort of design, sometimes it comes up with a better alternative.
Additionally, the same pattern of: "sometimes wrong, mostly good, sometimes better" also plays out wrt naming things. I thought i was decent at naming things, but an the LLM is literally build on turning 'concepts' in a vector space into words.
And in a very real way the names its choosing will 'compress' the ideas so that the next time an LLM reads it is more likely to understand.
For this to work though you need your complete system accessible and well structured.
You say "I always knew how the system worked and could extend it as needed". If an AI can't learn how your system works then that's a problem with the system setup, not the AI. An AI can find its way in the linux kernel or chromium source code just fine.
If you're in a role where you only spend time planning / architecture, then i assume things are pretty gnarly to begin with. The thing i can only guess at - and which is on a spectrum - how much of our role exists to support the weight of accidental vs essential complexity.
i.e. can the engineers not do the planning because: they're not that good, or its very broad things that need to expertly interplay with each other, or because the org has a mountain of buried bodies.
In my experience some of the more fanatic AI people are blind to the mountain of buried bodies covering a lot of essential complexity, but others can be blind to how well AI works when you can just shoot of a prompt to unbury a body and actually reduce the debt.
But in one sentence:
> Why can't you do the planning ?
This way lets me do more planning - planning is basically all i do now.