First off, I hear "Agile Task" and I think one to two days' work, not a week's. Tasks are what you break stories into when the story itself fits in the iteration, and it's a real rarity to have a story that cannot be broken down into smaller pieces.
Second, you're basically asking this new developer to hit the ground running. If he can be reasonably expected to jump right in and keep up the pace of the rest of the team, then the original estimate should hold. If he can't, he probably shouldn't be held to this estimate, at least not by himself.
Third, what's the situation? I'm pretty sure the situation was not that the team estimated their work, then someone walked out and you replaced him the next day. So, I'm thinking X guys on the team estimated this sprint's work and took in what they thought they could handle, and then you introduced the new guy and now there are X+1 guys to do the work originally committed to by X guys. Unless the team didn't pick their workload, and instead had the backlog crammed in by management, I would not be giving the new guy much to do this week. If the schedule was set by management, it's not Agile.
Personally, I would set this guy up to pair with a more experienced programmer for his first sprint (if your programmers don't pair all the time, which I'm inferring they don't from the fact that you're considering giving one task to one guy). By looking over his shoulder and asking questions, he'll start to learn the codebase, and if his general programming skill is up to snuff he'll be an effective code reviewer almost immediately, spotting bugs, inefficient code, etc etc.