My point was that this is what happens in the practice: you just won't know until you know, so why not make it that way upfront and not spend lots of effort trying to select the best candidate when you could, based on a much more loose criteria, select the best dozen and see who's really good.
I wasn't envisioning a sweatshop: if the company tried to extract everything out of cheap hires for four months, the company itself would lose. And there are these leeching companies anyway, working within conventional hiring practices as well. I had a good company in mind, one that really needs good programmers and not cheap minions.
An incompetent or malicious developer wouldn't really last four months, not probably four days. The projected four months was the final threshold after which most programmers can tell whether the candidate is really worth hiring.
Having new semi-hires around might certainly add up to the team overhead but on the other hand, that's what happens with conventional hires, too. Lots of teaching, tutoring, and support and things might still get crossed in the first few months. Plus the whole process of interviewing and that some hires quit or get fired within months.
So, to reply to your comment: having a batch of new hires, some incompetent and some possibly stellar, and few weeks to sort out the final candidates and few months to seal the deal, might not cost as much as you're afraid. Even a single new hire (carefully selected by HR, phone interviews, face-to-face interviews, and all) can eat up surprisingly lot of the team's time. Further, like hires in general, you don't want to be doing this all the time, just once a year or when you really, really need more programmers.