I define developer velocity as the rate of features shipped that achieve a business goal. To go faster you have two levers:
A good Infrastructure Developer can increase the rate features ship by creating systems and a codebase that is easy to read and extend. An extreme example of this would be DHH creating Rails to build Basecamp. Imagine someone like DHH building or finding tools to speed up your team and you have a good idea of the potential impact this type of work can have on your team's velocity.
A Product Developer can pull both levers at the same time by shaping the scope of the feature according to the probability that it will be valuable to users.
In startup lingo, the Product Developer is more likely to guess what the MVP of a given feature is therefore requiring fewer attempts at solving the problem and writing less code to get there.
At this point you may be thinking that you could achieve this with a product manager working with a developer and to that I say yes you can but be careful.
If the dev leans towards the Product type they will resent having features thrown over the wall to them so be sure to have them involved as early as possible or you won't keep them around for long.
If it's an Infrastructure developer you need to be disciplined about the time allotted to the feature or you're more likely to end up with an over-engineered solution. You'll also struggle to keep them focused on the feature as they'll want to clean up and refactor all the messes they run into along the way. And you need to keep in mind that they will tend to be more frustrated with unexpected changes in requirements.