My take on this is slightly different, in that I would give more weight to determining the requirements than most of the other responders. There can be any number of reasons that a contractor quit suddenly, but all too often the reason that a "programmer had no idea what she/he was doing" is because the stakeholders had no idea what they wanted. It's very important to go over the requirements in detail, and ask any questions that you might have about them. If you get resistance to this, that's a big red flag, because you'll have no idea what you're doing, either, and you'll be a convenient scapegoat for everyone.
Back in the 90's, I was gotten rid of as scapegoat number two in a situation like this. Several months later, I was teaching a class in the same town, and a fellow from the company that had kicked me out was in it. As it turned out, they had just gotten rid of scapegoat number three, who had taken over from me (starting from scratch, I might add), put one of their own employees on the job, and made sure he had enough training to become scapegoat number four. In other words, the problem was with these contractors, dang the lot of them as useless, let's train up one of our own and get the job done right. The real problem was that there was a manager who would go to board meetings twice a week and come back with changed requirements for the software we were writing. To be fair, she wasn't an IT manager, but when I tried to push back and say that we needed to stop changing the requirements every board meeting, she would just shrug and say we have to do what the board wants. When I mentioned that it was pretty clear that they didn't know what they wanted, since they kept changing their minds, and offered to meet with them directly, I set myself firmly on the path to scapegoat number two. (Nowadays I would try a little harder to educate the manager about the consequences to deliverability of changing requirements before taking this approach.)
If your predecessor was obviously incompetent, you might mention something as soon as you can effectively demonstrate the truth of that assertion. If the code is riddled with architectural problems, that's a liability to the success of the project and management will need to know about it. But it will be your job to convince them, so again make sure that you can.