It seems like you are dealing with an inexperienced developer, who is not used to being managed. Maybe he's done solo/freelance work before and has technical skills, but from what you wrote, you are probably his first supervisor (at least the first who actually supervises).
Your company, your reality. Up to you to know if you can afford to straight up the guy or if you are better off terminating him. If you want to keep him, you'll have to explain a few things that you may take for granted:
1. Be honest about your technical skills:
If you really know how to do something, you are expected to plan well and deliver on time. If you need to learn something, then make it clear while accepting the task, otherwise, you'll be undervalued as an employee.
2. Everybody needs to provide visibility to their managers:
If your manager has an off-hands approach to your deliveries, then he is the exception, not the rule, or you've managed to earn this privilege, that may be revoked at any time. Normal managers want to see either deliveries or partial progress. If you show none, you are giving him reason to believe you are doing nothing, and he'll want to know why. And if you refuse to answer, he'll believe you are refusing to do your job. Hence you should have no place in the company. Now, an employee does not need to cater to the curiosity of every coworker, but it is basically the job of a manager or supervisor to know what the people he's supervising are doing and what progress they're making, likewise, it is part of anyone's job to give their manager such visibility.
3. There is a place to draft code
And this place should be well distinct from code that is ready to use. People should be well instructed not to nitpick draft code i.e. nobody is allowed to complain about code standards in a draft code branch/repository, nor to ask for headers to be filled or documentation to be produced. This alleviates the anxiety of being criticized for incomplete work (image a teacher stole your test at half the time allowed for it and just graded it as it was).
But managers and colleagues giving help should have access to these repositories so they can provide insight and tips on a conceptual level, such as "hey, you are using X tool, have you considered using Y tool?", "No, because it's paid", "Well, but we have a license for it already!".
If you are a more experienced developer, you might also say you want to mentor him into how to break down projects, such that he can deliver code and plan better. Even more important, breaking up a project into smaller pieces is a fundamental part of being a project manager or software architect, if he ever wants to become one.
4. Be very careful when blaming others
Every time an employee blames someone else, you as a manager should know if he's making up an excuse or if this is a fair report. Maybe he's throwing his responsibilities to other people e.g. "Jake needs to change his interface to my system because they're incompatible as of now. It does not matter if Jake followed the specifications we agreed upon a year ago, I decided I wanted it to change and didn't talk to him yet!". So it is up to the manager in place to say "No, you should meet the specifications, unless they're borderline impossible to meet, you are not overworking Jake for your convenience".
A fair question to ask when an employee blames another could be "have you talked to Jake already about this?". A "no" is pretty much an indication that the employee is not communicating well yet badmouthing others. You should reprimand this behavior.
But if it just so happens that everybody else is not delivering, or if everyone else changes their interfaces so that the problem employee needs to rework his deliveries, then the whole office has an organization problem, so you may need to better inspect everyone's deliveries.
But a more interpersonal take on this could be: Blaming others earns a lot of ill-will towards you. So be very sure about your claims when doing so, and know the correct means to it. Never use it as an excuse for your own shortcomings.