Yeah, your colleagues opinion is kinda inline with how it was usually pitched - at least around 2010 when I learned about it to a degree that it wasn't just a fuzzy concept to me.

One of the goals I remember was to think from the outside to the inside: you first create a test which asserts your most outter API as a unit test with inputs as you want to use it.

Now you keep adding functionality until it passes, creating new tests whenever you make a new boundary/function/API

This supposedly makes it easier to design it well, because you don't have to keep everything in scope and instead only tackle one layer at a time - like an onion from the outside to the core. And you always design the APIs as they make sense, not as is technically easiest because you can just define it however you want, and then think about implementing it.

E.g. https://www.infoq.com/presentations/tdd-ten-years-later/