Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com