Commit the intention as specs. If tokens/intelligence become that much cheaper over time, then "throwing away the code" to start again becomes feasible.
Even after documenting decision and specs you need somehow to replay these in the correct sequence after you've validated these specs are still updated. Imagine you spec a feature, it works well, but in an edge case while doing a separate work you see something wrong, will you stop, fix and update the related spec? You will trust the AI will do this, and you guessed right, the counter-probability of success also has effect here, so eventually you will do undocumented changed in the codebase that won't reflect in the spec.
Now imagine all this but in the hands of someone that is an expert in their field but has zero notion what we are talking about here. Just look at the state of packages in R, the programming language, you'll see that technical competency and intelligence don't translate immediately to efficiency in a programming role.
I haven't had time to dive into it yet, but I think it might structure things in the way you want.
This is something I didn't think about. Have a tech illiterate friendly harness that will keep asking technical questions the mainstream user won't be aware they needed be addressed, until there is enough evidence to either start an implementation or outright reject the project with suggestions where the user might look into to better prepare for another session.