I think there is a lot of merit to what you say here. For example, one of the strongest realizations I had while using an interactive programming tool was while

I think there is a lot of merit to what you say here. For example, one of the strongest realizations I had while using an interactive programming tool was while hacking on a 30-50 line function I wrote. In the process I thought to myself "gee, I'm glad I have this tool otherwise I would have no idea what is going on!". However, before long, I realized I needed the tool because the function was too long and needed to be split into smaller pieces. In that case having the crutch of an interactive programming tool led to worse code. Once I refactored the function I realized there wasn't much need for the tool anymore. That being said, I have taught many a student to code and can't tell you how many conversations have ended with me saying "Maybe it will work. I'm not sure. Just try it!". Students (not all) in an unfamiliar environment will sometimes overthink things rather than trying a failing quickly and correcting their mistake. In this case, failing quickly is an indispensable tool to help student "hone in" on the solution and make progress towards it. Of course I have seen a fair number of students engage in "shotgun programming", switching a < operator to a > operator and hoping that it will work, so obviously there needs to be a balance.