TLDR: small stories, promote good architecture and OO principles, extra attention to defining and scoping stories, good test and CI practices to promote confidence and minimise business impacts from mistakes.
It's a little to hard to drill down into how big a chunk of code this guy insists on delivering, if he really insists on committing big features in one go then he would only deliver anything every several sprints - obviously this is not agile.
But, "every obscure corner case has been addressed" could describe good defensive coding to avoid bugs. If this one guy takes longer than anyone else to deliver a story just because he is writing robust code, that suggests that the reason everyone else gets it done quicker is because they are not!
Still, aim for smaller stories to encourage smaller delivery chunks - in a typical web stack feature you could go as granular (or more!) as a story each for
- Front end
Note that a poor or poorly enforced architecture and poor adherence to code quality and OO principles in a code base can make it harder to deliver in chunks as the far reaches of the codebase become excessively coupled - what's yours like? The worse the code is the harder you need to try to keep stories small, and the more investigation "spikes" you may need to correctly define and scope those stories.
Another possibility is a lack of confidence in committing code leading to hesitation and paranoia. Having good unit test coverage, automated testing, a decent CI setup, and a rapid and thorough regression cycle all help developers feel more confident to commit code as mistakes are less likely and less catastrophic.