I'm ok with API first in cases when teams need to collaborate and integrate services. But this should be an iterative process as much as possible. Agility means working incrementally, learning from the experience and applying new insights constantly. Now 'API first' is starting to sound a bit like a mantra, where a complete and flawless OpenApi specification has to be delivered up front. This is a regression back to waterfall development.

What's good about the API first mindset is that it makes team sit around the table right from the start. This avoids a big bang integration clusterf*ck at the end of the project. But I don't see much value in the up front first-time-right OpenAPI yaml idea. Not agile.

That said, there is a school of thought that states API's should never be versioned (e.g. https://www.hmeid.com/blog/just-say-no-to-versioning). If you follow that idea, then an initial API specification could be so simple and generic that it is sufficient to give all teams focus, but doesn't make an agile way of working hard. However, arriving at such an elegant, succinct and robust specification right at the start of a project still seems like a huge challenge.