You ask several questions.
Should we be on the lookout for lying code?
Should we be comparing [code] against any existing documentation?
That could never hurt, though as mentioned in other answers, more often than not this will lead you to find problems in the documentation, not in the code.
Or is [code] usually the best source for what it needs to be doing?
It is always the best source for what it is doing. The best source for what code should be doing can be (a combination of) different things though, the main ones being:
- The code itself;
- The calling code;
- Comments in that code;
- Unit tests;
- Integration and regression tests;
- The programmer;
- The end user;
Which is the "best" source (or combination thereof) depends on your situation.
If it is agile code, is it less likely to lie, or can that code not lie at all?
I'm not sure what you mean by "agile code", AFAIK "agile" usually refers to the coding process. Supposing you mean "code created in an agile programming process" then I think it's safe to say that it can still lie. How likely it is to lie, compared to code created in e.g. waterfall style projects is a subjective matter (personally I don't think there's a big connection).
All the above is under the assumption that code can lie, and that this is a basic (though bit contrived) example:
public int DivideByTwo(int input)
return input / 3;
This is just one example where I'd say "code lies", @user61852 has a few others (unreachable code, complexity of code not matching complexity of problem, bad naming), and I think there are many more. Wikipedia has a somewhat decent summary of lies, many of them can be found code.
Note that if you're in an argument with someone, be very sure the other person's doesn't mean by "code can't lie" that "code does what it does". In essence the other person here is defining using a definition for "lie" that's so narrow that it can declare the statement "code can't lie" as an axioma / basic truth. In this case it's probably best to agree with his/her axioma.