I HATE code with no comments. And tests are not sufficient documentation, though that's an argument for a different time.

Usually, I'm looking for general readability and understandability. I'd much rather see short, well-named classes and methods, well-named variables and good unit tests before I see a single comment.

In the absence of clean, readable code, comments are probably a reasonable but nevertheless inferior resort. I also agree that, sometimes, they 'why' of code is often best expressed as comments.

When working with legacy code that is not commented, how do you determine the invariants of an API?

That is, how do you ensure that the change you're making will not break other code? Do you have to scan the entire project, and any other projects that depend on it?

Unit tests are often not sufficient here -- changing the invariants of an API may not result in deterministic failure -- in fact, invariants often describe requirements necessary for deterministic behavior.