When I decided to build official SDKs for Zenmanage across 14 languages and platforms, I knew I couldn't do it the slow way. Here's the process I landed on, and the unexpected tool that made me actually trust each one.
SDKs are deceptively hard. Every language has its own idioms, package registries, async patterns, and testing conventions. Writing Python feels nothing like writing Swift, which feels nothing like Kotlin. If I did each one from scratch the traditional way, I'd spend weeks context-switching before writing a single meaningful line.
I wanted a repeatable process that could produce high-quality, idiomatic code in each language, fast. That meant leaning on AI.
Each SDK follows the same structure:
1. Prompt for language-specific best practices. Before writing code, I explicitly prompt the AI to follow the current language's best practices, idioms, and architecture patterns.
2. Enforce quality gates early. I make sure code coverage, code style, and static analysis all pass as part of the development loop, not just at the end.
3. Validate package ecosystem support. I ensure each SDK uses and supports the appropriate package libraries for that language and runtime.
4. Mimic proven SDK behavior. I mirror the core functionality and behavior of existing Zenmanage SDKs so the developer experience stays consistent across languages.
5. Write comprehensive unit tests at all layers. I require unit test coverage across transport, client, evaluation, caching, and error-handling layers of the SDK.
6. Iterate with AI, then review with intent. AI accelerates implementation, but I still run a focused human review pass for correctness, security-sensitive paths, and language feel.
Code coverage tells you your tests pass. It doesn't tell you your SDK works in a real project.
For each SDK, I build a test harness, a minimal but runnable project in that language's ecosystem that connects to a live Zenmanage environment. It:
Initializes the SDK against a real account
Evaluates a set of flags with different contexts
Displays the results in a simple UI or CLI output
On top of that, every SDK has to pass the same shared live test project with 30+ scenarios (defaults, target rules, rollouts, and scheduled releases), so I know they're all being validated against the same real-world checklist.
This sounds simple, but it surfaces issues that tests never catch:
Auth and transport bugs: the HTTP client behaving differently than mocked
Serialization edge cases: flag values that parse fine in tests but break on real API responses
Initialization race conditions: especially in async SDKs where the client isn't ready before the first evaluation
Package distribution issues: the published package behaving differently than the local dev version
The test harness is the final gate before I call an SDK ready to ship. If I can run it against my account and consistently get the expected flag results, it passes. In practice, the Python harness surfaced two issues that full unit test coverage missed. I fixed the SDK and added test coverage for both cases, so future iterations stay protected against the same regressions.
Right now I'm prioritizing the most widely used, highest-impact upcoming languages first: Python, .NET, Java, and Go. Python releases this week. The rollout is still aggressive, but the plan is to ship all SDKs incrementally over the summer. AI makes that pace possible. The test harness makes it trustworthy.
This process isn't magic. AI-generated SDK code still needs:
A human who can read the language well enough to spot idiom violations
Careful review of any security-sensitive code paths (auth headers, token handling)
Real integration testing; coverage alone is not enough
But for a solo founder building infrastructure across 14 platforms, it's the only approach that makes shipping on this timeline realistic.
I'll share launch updates on the Zenmanage blog as new SDKs and APIs go live: [https://zenmanage.com/blog](https://zenmanage.com/blog). If you're building in any of these languages and want early access, reply here, happy to share.