Anthropic’s Stainless acquisition and the future of SDK generation

At a glance

What this is: Anthropic's acquisition of Stainless is driving a shift away from hosted SDK generators toward owned or open-source generation pipelines.

Why it matters: IAM and platform teams should care because the same vendor-control and lifecycle questions that apply to NHI tooling also apply to developer infrastructure, where hidden dependencies can outlive strategy and complicate governance.

👉 Read WorkOS's analysis of Stainless alternatives after the acquisition

Context

SDK generation is a software supply chain problem as much as it is a developer experience problem. Teams are not just generating client libraries, they are encoding authentication handling, error patterns, pagination, and language-specific conventions into a repeatable pipeline that has to survive API change.

The governance issue is vendor dependency. When the generation system is hosted by a provider whose priorities can change after an acquisition, organisations have to decide whether they want convenience or control. That decision now sits squarely inside broader identity and access governance thinking, because the same ownership questions shape how teams manage service accounts, tokens, and other machine-to-machine dependencies.

Key questions

Q: How should teams decide whether to keep a hosted SDK generator?

A: Teams should keep a hosted SDK generator only if they can tolerate roadmap dependence, reproduce the output if needed, and accept that the vendor may change ownership or priorities. If the API is core product infrastructure, control and continuity usually matter more than convenience.

Q: Why does SDK generation become a governance issue after an acquisition?

A: An acquisition can change the incentives behind a hosted generator, which turns a technical dependency into an organisational risk. The team still owns the API surface, but it may no longer control how clients are produced, updated, or supported across languages.

Q: What breaks when an SDK generator is a black box?

A: Black-box generation breaks reproducibility, makes debugging harder, and increases the chance that output quality drifts across languages. It also leaves teams unable to inspect the logic they rely on when authentication, pagination, or error handling needs to change.

Q: What should platform teams do before switching SDK generation approaches?

A: Platform teams should inventory their OpenAPI pipeline, identify language-specific customisations, and confirm whether they can regenerate every client from a single source of truth. If not, they should expect migration work, release risk, and documentation cleanup.

Technical breakdown

How SDK generators normalize API specifications

A modern SDK generator does more than turn OpenAPI into code. It resolves $ref chains, schema composition, pagination behaviour, and authentication flows into a structured intermediate representation, or IR, before any language-specific code is emitted. That IR matters because it separates API intent from implementation detail. Instead of templating raw YAML, emitters make language-aware decisions such as optional parameter handling, type mapping, and error surfaces. The result is consistent generation across multiple SDKs when the underlying API changes.

Practical implication: treat the IR and emitter layer as infrastructure you may need to own, not just a convenience service.

Why black-box generation creates governance risk

Hosted SDK generation centralises design decisions outside the organisation that owns the API. That is fine until the provider's roadmap, pricing, or ownership changes, at which point the SDK pipeline becomes a dependency rather than a capability. The technical risk is drift control, because every API change must still propagate cleanly across multiple languages. The governance risk is accountability, because teams often discover too late that they cannot inspect or reproduce the generation logic they rely on.

Practical implication: map which parts of your SDK pipeline you can reproduce internally before a vendor transition forces the issue.

Why constrained AI assistance is different from free-form code generation

The article's reference to a Claude-assisted configuration is best read as constrained assistance, not autonomous generation. In this model, AI helps within a tightly defined emitter workflow rather than deciding architecture or output shape independently. That distinction keeps generation deterministic enough for production use. For practitioners, the point is not whether AI is involved, but whether the pipeline remains auditable, repeatable, and bounded by explicit rules.

Practical implication: use AI only where the generation boundaries are explicit and testable.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vendor-controlled SDK generation is a lifecycle problem, not just a tooling choice. Hosted generation platforms create a dependency that teams often treat as interchangeable until ownership changes. Once acquisition enters the picture, the real issue becomes whether the organisation can still govern its own interface lifecycle, not whether the vendor's product was convenient. The practitioner lesson is that SDK generation belongs in the same ownership conversation as other critical machine-facing infrastructure.

Owned generation pipelines reduce exposure to roadmap drift and acquisition risk. A generated SDK pipeline is only durable if the team can reproduce it, inspect it, and change it on its own timeline. That is why open-source or internally controlled generation models matter when the API is core product surface. The issue is not ideology, it is continuity of control. Practitioners should evaluate whether their current setup can survive a vendor exit without forcing language-by-language rewrites.

Idiomatic SDK output is a governance concern because it shapes adoption and maintenance burden. If client libraries do not match native conventions, teams end up with wrappers, exceptions, and workarounds that accumulate technical debt. That debt then feeds back into security and support operations, because inconsistent SDK behaviour makes authentication, retries, and error handling harder to standardise. The practical conclusion is that code generation quality is not cosmetic, it is part of operational governance.

The open-source path now looks more credible because ownership and consistency are being priced into the decision. The article makes the case that long-term stability matters more than black-box convenience when the interface layer is strategic. That aligns with broader platform governance thinking: once a control surface becomes business-critical, the ability to inspect and evolve it matters as much as the feature set. Practitioners should reassess whether managed convenience is still worth the dependency.

Named concept: generation pipeline ownership. This article sharpens the idea that the real asset is not the SDK output alone, but the pipeline that produces it. When the pipeline is owned, teams can standardise behaviour across languages and keep pace with API change. When it is external, the organisation owns the API but not the means of shipping it cleanly. The implication is that governance should track pipeline control, not just library quality.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• Teams also report an average of 6 distinct secrets manager instances, which fragments control and weakens central visibility.
• That fragmentation makes lifecycle ownership harder to enforce, which is why the Ultimate Guide to NHIs , The NHI Market is a useful forward reference for platform and identity owners.

What this signals

Generation pipeline ownership: the useful question is no longer whether SDKs can be generated, but who controls the pipeline that produces them. In practice, vendor-managed convenience becomes fragile when release cadence, language conventions, or ownership changes and the team cannot reproduce the flow internally.

As platform dependencies become more strategic, governance teams should evaluate developer tooling the same way they evaluate machine identities: by control, continuity, and recoverability. That framing is especially relevant when the pipeline encodes authentication and retry behaviour that downstream teams depend on for stable integrations.

The operational lesson is to keep source-of-truth artefacts and build logic close enough to the organisation that an external change does not become a release stoppage. Where that is not possible, treat the dependency as temporary and build an exit path before the next change forces one.

For practitioners

• Map SDK pipeline ownership Document which parts of your SDK generation flow are hosted, which are reproducible, and which depend on provider-specific behaviour. Focus especially on IR handling, emitter logic, and release automation so you can see where control actually sits.
• Test vendor exit scenarios Run a short transition exercise that asks how quickly you could replace a hosted generator without rewriting language-specific clients from scratch. Include authentication handling, pagination, and error mapping in the test.
• Separate generation quality from feature count Evaluate whether the SDK output is idiomatic enough to avoid wrappers, custom patches, and forked maintenance. Quality gaps become governance gaps when each target language starts drifting away from a common API contract.
• Keep AI assistance constrained and auditable If you use AI in the generation workflow, limit it to bounded tasks inside a defined emitter pipeline. Require deterministic inputs, reviewable outputs, and test coverage for changes so the process remains reproducible.

Key takeaways

• Hosted SDK generators create dependency risk when the organisation cannot reproduce the pipeline it relies on.
• Acquisition risk matters because SDK generation sits in the critical path between API change and usable client libraries.
• Owned or open-source generation becomes more attractive when teams need continuity, inspectability, and language-consistent output.

Key terms

• Intermediate Representation: A normalized data model that sits between an API specification and emitted source code. It lets generators resolve schema complexity once, then produce consistent language-specific clients from the same structured input. In practice, it reduces ambiguity and makes regeneration more predictable when the API changes.
• Emitter: A language-specific code generation component that turns structured API data into source files. Emitters decide how types, optional fields, errors, and conventions should look in each target language. The quality of the emitter often determines whether generated SDKs feel native or awkward to developers.
• Generation Pipeline Ownership: Control over the tools, logic, and release process that produce SDKs from an API specification. Ownership matters because it determines whether a team can inspect, reproduce, and change the output without relying on a vendor's roadmap or hosting model. It is a governance question as much as a technical one.

Deepen your knowledge

SDK pipeline ownership and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are assessing ownership of machine-facing infrastructure with similar control requirements, it is worth exploring.

This post draws on content published by WorkOS: Stainless alternatives and what to use now that the SDK generator is shutting down. Read the original.