Great piece! Being in a position that I can say something about this issue, I think that even if you design and architect the solution before coding, the bits, pieces, bolts and straight up duct tape to make it work is a focus-oriented task. Interruptions should be minimized.
A proper architecture, that is obvious and simple to all parties in a company/team (PMs, devs, devops, testers, content), makes it easier to re-focus, though.
Several issues in projects I worked on came from the fact that the business architecture never got reflected in the technology. If you are working on a business-first case, grill your PM, do small drafts, do delivery dates on small issues, keep track of the development and, last but not least, explain what is necessary in terms of time and manpower to deliver a solution.
I'm also guilty of "coding away", so to speak - tinkering requires focus. That is why my personal solution to the interruptions and constant iterating over business ideas is drawing stuff down and coding until another meeting. Those are not standups or briefs - since I do remote, so it's in both mine and my client's best interest to not waste our mutual time talking about the weather. I usually schedule an hour meeting for about two to three weeks of development.
That should let you get back on track easily whenever unwanted human interaction happens :)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.