Every time I see a comment like this I feel like you are only 50% into the transition that is occurring.
The crafting of the requirements is better suited to an interactive process. You will have superior results and a quicker turn around by having the AI research the change implications, what current implementations actually do and where (so you can look at the parts you want to), etc.
When working in a BIG codebase, having it detail up a flow of how all the parts fit together is great and helps get you setup to work. Then work through your planned constraints with the AI and make sure the perception matches your intent (with prevents a lot of issues that a fire and forget document creates).
Then when you are satisfied that it sees the problem as you do, have the model capture it and then let it rip.
Oh I agree totally. I find it to be one of the coolest parts of the whole thing: Getting the AI to help put together the docs that will be handed to the AI. But the "quite technical people" that I referenced are not "full technical people"; I would lose them if I tried to explain the above to them.
I also really like telling the AI, "while we are hacking our way through the jungle trying to figure out how this thing should be built, at the same time, I want you to keep a design document up to date so that, if I asked you to rebuild the whole system again but without all the false starts etc we went through while we were figuring it out together, you could do so."
I probably won't use any of the "zombie clone" versions of my app that get built from the AI-generated design doc, but the fact that the zombie app (and design doc) look good at a casual glance, and the design doc is not 200 pages of AI bloatware verbiage, seems like good evidence that if a human expert needed to step in and save the system from some big surprise, that design spec would be found to be exactly what that human needed to help find the problem.