Engineering blueprints are the "code". They are intended to be read in a systematic manner by someone who can put the parts together. In software, we call that someone a compiler.
Design documents, such as sketches, artists renderings, specifications of performance, etc., may or may not be useful to the engineer producing the blueprint. The discussion of UML is at the level of these artifacts. If UML is useful, I want to look at it and have an idea of what the software is going to do. Some parts, like event-state diagrams, activity diagrams, and use cases, are pretty good at capturing that design in a way that I can talk about it with someone who doesn't understand code. I would not pay someone for completing a document like that, though, not until it was reflected in code.
Another way of capturing design is through functional tests. Look at projects like Fit for examples of how that might work.
This is a completely philosophical discussion, but I do not think blueprints can be the code, since blueprints in every other industry still leave a degree of freedom for the final implementation and in the software industry code IS the final implementation.
Design documents, such as sketches, artists renderings, specifications of performance, etc., may or may not be useful to the engineer producing the blueprint. The discussion of UML is at the level of these artifacts. If UML is useful, I want to look at it and have an idea of what the software is going to do. Some parts, like event-state diagrams, activity diagrams, and use cases, are pretty good at capturing that design in a way that I can talk about it with someone who doesn't understand code. I would not pay someone for completing a document like that, though, not until it was reflected in code.
Another way of capturing design is through functional tests. Look at projects like Fit for examples of how that might work.