A few other points..
I have seen many coding sessions where all the effort and push early is meeting basic functionality. That takes a lot of coding and communication to get going. I have been in agile sessions where they do their sprint and get basic functionality, then they write their bug reports, then go on to the next sprint coding the next batch of basic features. They never take sprints to fix bugs. You'll always see the number of outstanding bugs rise.
So, to the initial poster:
1) What is the time allocated for the coding?
2) What is the time allocated for debugging?
3) Does it take 90% of the contract timeline just to get basic functionality?
4) What are the metrics along the line for payment? Does the programmer get paid as they go along, or only at contract completion?
5) When is the spec freeze?
6) What are the test cases and who provides them?
I have a few red flags here that kinda indicates to me that it is irrelevant whether you bring in a contractor in-house as opposed to bringing them in from the outside. "Developers can make more work for themselves by causing bugs, and with the specifications I write there is no excuse for not testing their code." is a red flag for me. You don't trust your developers. I have *never* in 30 years really ran into any systemic problem along those lines, even with an individual developer. In general terms, bugs are the last thing to be addressed after getting core functionality and basic QA completed.
The reason why they generally don't complain upfront is because you are backloading all the ways to get away without paying them.