That depends on the specific code. Some code is written to be agnostic to the rank, while others make certain assumptions.

In my code I'd sometimes write assertions in the beginning of a function to not only ensure it's called with the right shape but also as documentation.

Also, in practice really high rank arrays aren't used much. Even 4 is pretty rare.

If there's information on input format, it is simple enough to trace through the following shapes, but it does force reading the code rather linearly. Operations which implicitly restrict the allowed shapes are unfortunately intentionally rather few.

I basically never use the generalized inner product; it's rather unique to the original APL - J has a variant that doesn't have the built-in reduction, and k and BQN and many if not most other array languages don't have any builtin for it at all. And in general I don't typically use rank higher than like one plus the natural dimensionality of the operation/data in question.

I programmed in APL a long time ago... even got 'not bad' at it.

The best analogy i can give of my thought process is that first i unfolded the problem into one or more many-dimension object(s) ... then took a different "stance" of looking at the object, then refolded them into the final solution.

So yes... I had it all in my head at some point.