This scarcity means that most projects try very hard to get as many high-quality coders as possible assigned to them, whatever that means in your particular project framework.
Unfortunately, collecting coders like jewelry is not, it turns out, a very effective way to improve your project. I can explain why with the use of a simple metaphor:
Coders are like Landscapers
If someone comes to your house, your front yard is the first thing they see. Having a beautiful front yard makes your house look great. You can maintain your yard on your own, but if you need to make it really different - you need a professional landscaper to take control of it, and adjust it. Many affluent people have regular landscapers who come every year to make adjustments, and keep everything beautiful and fresh.
However, trying to retain a landscaper to work on your modest front yard every day of the year defeats the purpose of landscaping. While work is being done, the effect of your beautiful yard is lost among tools, half-completed adjustments, and laborers. Landscaping is best accomplished as an intermittent task. You adjust, then you get to know your new yard, so that you can better inform your next iteration of landscaping.
Coders are very much the same. Coders adjust things at a broad, fundamental level. But your goal is not to adjust things as much as possible - it is to find the best stable product you can. In almost every project I have been associated with, coders were left to run rampant for too long - tilling the soil of the project such that it was impossible to keep firm footing.
Spending and Projecting efficiently
Of course projects don't just keep coders around because they carry prestige - there are real tasks which need coders to implement. But without a break from the churn of constant code-adjustment, designers and producers cannot take proper stock of where things are. This increases reliance on the initial plans - which everyone knows become nearly useless in short order, as things change out of necessity.
So what is the better solution? Let your coders go! Bring coders on and then take them off, allowing the cheaper talent to iterate on stable ground. This allows your most valuable resource to be spread between projects more efficiently, since assignment doesn't mean your coders are locked-out of all other work forever. It also means your feature sets can be re-evaluated, and require less revision.
It might also extend the length of your projects - but since your most expensive elements are only part-time, this lengthening doesn't have to impact the cost per development month too severely. In fact, this can provide the magical "polish time" which teams are always looking for at the end of a project. Even better, it provides this time in the early and middle of the development cycle - when teams are in a position to actually use the time to make improvements.