Recently I was assigned to a project which was already in its midway. It was TDD environment.
Everyone was following right principle of Code Unit Test First and Implementation
Overengineering - you may have written more code than you actually need.
Bias - you may write tests that test your implementation rather than the requirement.
Tests wont drive your design - tests can signal design improvements. Over time your design can become rigid and averse to changes.
Slow you down - your implementation may have testability issues which will surface only when you attempt to write your tests. By which time, you may be inclined to kludge something up because now the test is standing in your way to implementing the next feature. Trying to unit test an untestable blob is frustrating.. more often you will end up with non-thorough tests (test what is easy and move on).
Tests may not be written - once your implementation is ready and you've manually verified it to work, there is a tendency to skip the boring unit tests and skip to the interesting part... writing more code. Over time, untested chaos.