[mr_Fatalyst]

Thanks! I personally prefer code-first because it aligns well with Python’s dynamic nature and feels more natural in daily coding. Spec-first definitely has advantages (especially clarity and collaboration), but it can sometimes introduce friction, especially when rapidly iterating on APIs.

I think the popularity of code-first tools (like FastAPI) mostly comes from the convenience of quickly defining and changing APIs right alongside your code.

[dtkav]

Yeah, that's fair. Do you maintain any Public APIs or mostly private ones?

There are a bunch of trade-offs based on your starting point and where you want to get to.

I have found Spec-First is useful for a retrofit and having large org API design standards, but then code first can be helpful again if you are writing a framework to have consistent endpoints by default (like pocketbase's API).

If you're maintaining a private API then it makes sense to optimise for individual developer velocity and code-first seems like a good fit.

[mr_Fatalyst]

You're right, I'm mostly maintaining different private APIs. In that context, optimizing for individual developer velocity definitely makes code-first more appealing. But you're spot-on about larger orgs and standards—spec-first can simplify collaboration and consistency in those scenarios.