But when we diagram we rarely fill in all the details.
On the contrary, we often diagram to abstract away from details.
That is the challenge a visual programming tool needs to overcome: Most likely we'd need to diagram only some parts. Most likely the level of details and which details we want will depend greatly on who we're talking to and what we're trying to address.
This is exactly why we use petri nets and then we map them to a semantics. Drafting a net represents the "diagram part". You draw what your code is supposed to do as you would do on a whiteboard. But this time you have a lot of formal tools to do checks on the net (is it deadlock? Is it live? Does it have nice properties?). Once you are satisfied with the net, you populate it with meaning: Places of the net get mapped to datatypes and transitions to functions. This is the stage where you start typing stuff in. What you gain is that the translation between ideas (diagrams) and code is formal, so way less prone to error.
The most useful visual programming tools I've seen have either been hyper specific to their use cases or relatively thin abstractions over a workflow engine. IBM's BPM is basically the latter, and iirc it would let you drop in a node with a skeleton function that you'd implement yourself. Very useful for non-technical people, but maybe not what you'd use if you're a software shop.
On the contrary, we often diagram to abstract away from details.
That is the challenge a visual programming tool needs to overcome: Most likely we'd need to diagram only some parts. Most likely the level of details and which details we want will depend greatly on who we're talking to and what we're trying to address.