Introspecting into how I prototype new ideas and algorithms, the kinds of intricate tracing and exploration that are automatically done by Seymour are things I often do "manually", using a cobbled-together set of tools (one of which made it into Mathematica [1]).
Sometimes, because its fairly easy to do in the language, I quickly code up once-off tools to help me verify solutions. For example, I recently finished a new type inference system for neural network layers that allows very flexible 'backwards' and 'sideways' inference of tensor rank and dimensions. Surveying its behavior on all the possible inputs on the various kinds of layers is not feasible via manually typing REPL examples or unit tests. So I ran the inferencer against all possible cases of a certain form, and by visualizing the results as little squares (with various other info behind tooltips and mouseovers), I checked each result very rapidly [2] and soon found cases I hadn't thought of.
One thing I wonder from my experience of doing this kind of thing (I've written various visual debugging and logging frameworks, and code visualizers of all kinds), is whether a prescribed framework and set of workflows is actually preferable to flexible tooling that you can inject in precisely the way you want.
I've often abandoned my visual tools because they are too hard to customize into the exact thing I need to answer a specific, scientific question that comes up during debugging or implementation. Also, when you are already overloaded with thoughts and ideas about what might be going wrong, you kind of want to be able to ask and answer extremely precise questions, rather than swamp yourself in visual data that you have to interpret in light of your hypothesis. Clever presentation can only help the overload so much.
I wonder if what is needed is a kind of "side program" that one could use to annotate the main program in very precise ways and ask questions of its execution, or to produce maps or timelines of aspects of its behavior. But not via interactions with a GUI, although those are useful too, but as actual code that lives alongside the real code, using the same language. Something a bit like a souped-up, visual dtrace, perhaps. I don't know what is already out there like that, but I would love to see work in that direction.
[1] http://reference.wolfram.com/language/ref/Echo.html
It's not really shown well in this documentation (I didn't write the docs), but Echo is very easy to insert because you can just write "Echo @" as a prefix, anywhere in ordinary code, and it basically a no-op. I have a macro system that makes it even easier: the single quote character (which normally means Derivative) can be put next to any expression and does the equivalent of an Echo. Being able to inject and remove these little probes anywhere in the codebase with a single keystroke makes the good old "print debugging" actually pretty effective in a lot of situations. And various forms of cleverness make it more useful, like putting it next to an assignment will also print the variable being assigned.
The first two lines of each grid represent the inputs to a CatenateLayer, the last line is the output. Red indicates an invalid shape. Gray is "unknown". The other colors are fixed dimensions like 2 or 3, or dynamic dimensions (used for var-length sequence inputs). This display is from a buggy version of the inference system, don't try to check it!