The honest framing is a resource question. An SDK is a product with a release cycle, a support burden, an issue tracker, and a security responsibility, multiplied by every language you ship. Six SDKs, four of them a year behind the API, is worse than none — because the stale ones actively mislead people.
So: look at what your consumers actually use, pick the two or three languages that cover most of them, and generate from your OpenAPI so regeneration is cheap and the SDK cannot fall behind the contract. Hand-craft only where the generated result is genuinely unpleasant and the language matters enough to justify the ongoing cost.
Generation has real pitfalls worth knowing about. A weak OpenAPI produces a weak SDK — vague operation IDs become terrible method names, missing schemas become untyped blobs, absent examples become useless docs. The SDK is a mirror held up to your contract, which is one more reason to invest in the contract first.
And remember that code libraries were never enough on their own. What consumers need is the whole path: a clear contract, good documentation, runnable examples, a collection, and a client they can poke at. The SDK is one convenience among those, not the finish line.
