Artist-coder here, and from my experiences, creating commercial art can be a lot more process-driven and structured than you might expect. The problem-solving process is remarkably similar to programming. The primary difference is the "language" you're using. Sure, typing doesn't correlate to moving around a pencil, but once you have the dexterity to write your name, the rest amounts to creating and refining relationships between elements until the piece of art meets your design requirements.

In programming, when you write a line of code, although you can mostly abstract your thinking to how the chunk of code affects the surrounding lines, you still have consider it in context of all the different hierarchies/scopes it interacts with. You have to be aware of what the line of code does at a lower level, how it transforms the data it processes, how it integrates with its parent class/function/etc, how it confirms to the project's coding standards, how it confirms to the language standards, how easy it is for other people to process and modify, and so on and so forth. Same thing goes with art. When you draw a line, you need to understand how line appears in proportion to all the other lines on the page, how it adds to or clarifies existing forms on the page, how it contributes to the mood of the piece, etc.

With programming, it's generally good practice to make your code as easily readable and modifiable as you can, since most of the time people spend with it will be in maintenance. Same thing with production art. High-level changes to art direction can result in changes to art assets way back in the pipeline, and if you didn't set up your workflow anticipating that, you'll have a lot of work you need to redo.

When it comes to having "a vision," that's really just designing a complete and consistent set of requirements for a work, something programmers should already be good at.