One thing I think can really help is to have two different modes within the same team. You move fast and cut all corners and rapidly iterate when you have an idea by building a prototype, with the only goal being maximizing the speed at which you're learning if/what works and what does. Then you basically throw away all that prototype code and build the feature properly with careful attention to code quality and complexity, testing (++) - since now you actually know what you're building and that it's likely a good idea.

Rinse and repeat, so that you only have prototype code where you're actively learning, to be immediately replaced by properly engineered solutions or wiped away (with the same haste you used to create it initially - no "rarely used, badly engineered" features should stay in your codebase due to priority / resources / attention constraints).

The biggest challenge I've had with this approach has been building and fostering the trust and culture needed to have everyone truly go "all in" for both aspects/modes of working. This breaks down quickly if you have managers or PMs drive engineering to keep the prototype code in for longer, or if engineering insists on not cutting corners during the exploration/prototyping phase...