Open SDK generation is a continuity control, not a continuity plan

The incident was a dependency failure, not a code-generation failure

On September 17, Google said that the provider behind its SDK generation pipeline was acquired and abruptly announced a shutdown in May, while the team was preparing the Interactions API for general availability. The urgent problem was not whether OpenAPI could describe an endpoint. It was whether Google could continue producing compatible Python, TypeScript, Go, Java, C#, PHP, and Ruby clients without breaking users.

Google migrated its GenAI SDK pipeline to Speakeasy while preserving language-specific types, strict error hierarchies, server-sent-event streaming, and integration with an internal monorepo. The companies then released Speakeasy's OpenAPI generator under AGPL-3.0. Google's published result is unusually concrete: the new setup covers six targets, three already released, with roughly one engineer maintaining the pipeline instead of several engineers maintaining handcrafted generators.

The release matters because an SDK generator is a compiler in the distribution path. It translates a formal interface into public client behavior: method names, types, retry rules, pagination, error objects, streaming semantics, authentication helpers, and packaging metadata. If that compiler disappears, an API can remain healthy while its clients drift, releases stall, and security fixes stop reaching downstream users.

The September community signal is early. The focused scan found the new repository but little exact discussion of the release, so this is not evidence of broad adoption. A current r/microsaas thread does, however, describe SDK-generator consolidation and exits as an active market problem. Older developer threads repeatedly describe the operational symptoms: generated clients lag the specification, methods disappear, inputs compile differently by language, and teams accumulate post-generation patches nobody can reproduce.

Treat the generator like a compiler, not a template download

The public Speakeasy repository documents a conventional compiler pipeline: parse and validate the OpenAPI document; build an SDK-oriented abstract syntax tree; load target templates and helpers; render; format; and optionally compile the output. That sequence explains why “we have the source” is insufficient. Each stage has inputs that can change behavior without changing the API endpoint itself.

Formal generation is valuable precisely because it is deterministic. Google says it kept the formal transformation in a fast deterministic generator and used AI agents on custom work. That boundary is sound: an agent can repair a malformed description, propose an overlay, write a compatibility adapter, or explain a diff. It should not replace the reproducible transformation from approved contract to candidate artifact.

A good pipeline retains a small set of tracked generated fixtures. Speakeasy calls these zSDKs: compact review outputs regenerated when templates change. They make compiler changes visible in a normal code review. Add your own organization-specific fixtures for authentication, long-running operations, streaming, pagination, binary payloads, discriminated unions, and error bodies. A generator test suite proves general behavior; your fixtures prove the behavior your clients depend on.

Put the API contract at the root of a recoverable build graph

signed OpenAPI source + pinned overlays
  -> validate, lint, bundle external references
  -> pinned generator commit + explicit license election
  -> pinned target template and language toolchain
  -> generate SDK / CLI / MCP candidates in clean runners
  -> compile + contract tests + public-surface diff + security tests
  -> human review of intentional breaking changes
  -> sign provenance and publish immutable packages
  -> monitor adoption, errors, deprecations, and rollback readiness

The contract repository owns the approved API description and change history. Resolve remote references into a content-addressed bundle before generation. Otherwise an unchanged commit can compile against a changed remote schema. Keep overlays explicit; do not hide product-specific behavior in a hosted UI that a cold runner cannot retrieve.

The generator repository is a separately pinned dependency. A moving latest tag defeats reproducibility. Record the commit, binary digest, build command, feature flags, and target-template digest. If a patch is required, keep it as a reviewable fork or patch series, not an undocumented mutation in CI.

The target builders are isolated by language because Python packaging, Go modules, Maven, npm, NuGet, RubyGems, and PHP Composer fail differently. Compile and execute generated code in the same supported runtime range promised to customers. A TypeScript success does not validate Java streaming or Python exception mapping.

The release gate compares the candidate with the last production artifact. Breaking-change detection should cover symbols and wire behavior. A method rename may be obvious in an API diff; a retry-policy change, default timeout, header loss, or altered exception type requires runtime tests.

Make a continuity manifest the build can verify

The manifest should let a responder answer five questions without the original vendor: which contract was compiled, which compiler and templates were used, which license mode applied, which target toolchains ran, and which evidence authorized release.

apiVersion: sdk-continuity/v1
release: genai-clients-2026.09.23
contract:
  repository: api-contracts/genai
  commit: 8d3a...
  bundle_sha256: 6b91...
  overlays_sha256: 01af...
generator:
  repository: speakeasy-api/openapi-generation
  commit: 4c12...
  image: registry.example/codegen@sha256:91ae...
  license_election: commercial
  telemetry: disabled
targets:
  python: {runtime: "3.12", lock_sha256: "c8e4..."}
  typescript: {node: "24.7", lock_sha256: "42bf..."}
  go: {toolchain: "1.26.2", sum_sha256: "ef18..."}
gates:
  required: [compile, contract, compatibility, security, provenance]
  baseline_release: genai-clients-2026.09.16
  reviewer_quorum: 2
recovery:
  fork_remote: github.com/example/openapi-generation
  last_cold_build: 2026-09-23T02:40:00Z

Keep the license election explicit. The public generator refuses to run without choosing AGPL-3.0-only output or providing a commercial token. Its documentation says commercial rights for already generated artifacts continue after a token expires, but third-party input content keeps its own license. That is a useful boundary, not a substitute for counsel reviewing how your organization runs, modifies, distributes, or offers the generator as a service.

Also decide whether telemetry is allowed. The repository documents usage telemetry that can include target, template, success state, operating system, feature flags, validation messages, server URL, document title, and workspace identifiers when available. It provides SPEAKEASY_DISABLE_TELEMETRY=true. A regulated or private API team should make that choice in policy and verify it in the runner, not rely on a developer remembering an environment variable.

Gate regeneration on compatibility, not on a green compile

A compiler can emit valid code that breaks every user. CI therefore needs both build tests and behavioral assertions. Start with the smallest critical matrix and expand from incidents.

validate(contract_bundle)
verify_digest(contract_bundle, manifest.contract.bundle_sha256)
generator = build_pinned(manifest.generator.commit)

for target in manifest.targets:
    candidate = generator.generate(contract_bundle, target)
    compile(candidate, pinned_toolchain(target))
    run_contract_tests(candidate, hermetic_test_api)
    run_security_tests(candidate, auth_and_redaction_cases)
    diff_public_surface(candidate, production_package(target))
    verify_no_untracked_post_generation_patch(candidate)

require(intentional_breaks_have_migration_notes())
attest(inputs, outputs, tests, reviewers)
publish_if_quorum()

Contract tests should exercise serialization, authentication, pagination, streaming, retries, timeouts, and representative errors against a controlled server. Speakeasy's public tests start local HTTP services; the same principle keeps continuity checks independent of a live production endpoint.

Compatibility tests compare exported symbols, method signatures, package names, error classes, and defaults with the released client. Not every difference is wrong, but every user-visible difference needs an owner and migration decision.

Supply-chain tests verify lockfiles, artifact contents, dependency allowlists, build provenance, and signature identity. Do not publish directly from the generation job. A separate release identity should promote reviewed artifacts so a compromised contract or generator cannot become a package automatically.

One contract can produce three interfaces with different risks

Speakeasy argues that CLIs fit coding agents because models already understand shell conventions, can discover subcommands incrementally, and can pipe structured output through tools such as jq. That is an interface advantage, not a security boundary. Generated commands still inherit the caller's identity, reachable network, and API permissions. Mark destructive commands, require confirmation or policy approval, separate read and write credentials, and test machine-readable error output.

MCP generation addresses a different problem: turning current API schemas and documentation into tool definitions an agent can query. The risk is semantic compression. An endpoint named deleteProject is easy to classify; a generic updateStatus may trigger invoices, notifications, or irreversible workflows. Add business semantics, idempotency, required approvals, data classifications, and side-effect metadata outside the mechanical schema where necessary.

This is the same lesson covered in the agent-readable web interface guide: machine-readable access improves discovery, but action authority still belongs to a policy layer.

Resolve the license and control-plane boundary before migration

The September announcement describes the suite as open source under AGPLv3 while saying users can retain their chosen license for generated code. The repository adds detail: the generator itself is AGPL-3.0; generated output carries either the elected AGPL notice or commercial rights proved by a token; and third-party material from the input contract retains its existing terms. The repository also uses a contributor agreement that permits AGPL and separate commercial licensing.

Do not reduce this to “AGPL never affects output” or “all output must be AGPL.” Review the exact version of LICENSING.md, the election used by your build, whether you modified the compiler, whether you expose it over a network, and which third-party code or descriptions enter the generated artifact. Preserve the election and relevant license text in release evidence.

Open code also does not guarantee every development aid is public. The repository says its snapshot companion is private and public pull requests receive only aggregate snapshot status. That may be reasonable for protecting customer inputs, but it means a fork must build its own golden snapshots and compatibility corpus. Continuity planning should list every private service, secret, hosted registry, snapshot, signing key, and support path still needed after source checkout.

Failure modes an open repository does not remove

Run a cold rebuild before the next vendor event

Day 1: inventory every generated artifact, target language, registry, release owner, hosted dependency, license election, custom patch, and downstream compatibility promise. Mark clients for critical APIs first.

Days 2-5: bundle and sign the source contract, freeze overlays, pin the generator commit and target toolchains, and create representative fixtures. Move post-generation edits into explicit overlays, templates, or maintained adapters.

Days 6-10: build from a fresh runner with hosted generation disabled. Compile each target, run contract and behavior tests, compare the public surface with production, and record every missing secret or undocumented service as a continuity defect.

Days 11-15: generate a CLI and MCP server only for a bounded read-only API. Test discovery, structured output, authorization, destructive-operation labeling, documentation freshness, and error handling. Do not expose the full API simply because generation is easy.

Days 16-20: rehearse two failures: the generator's hosted control plane is unavailable, and the chosen generator can no longer be used. Prove that the team can build the pinned fork for the first case and produce a compatibility-scored candidate with an alternative generator for the second.

Release gate: require reproducible artifacts, explicit licenses, zero unexplained surface changes, passing critical behavior tests, signed provenance, two reviewers, and a rollback package. Link the evidence to an execution receipt so a later incident can reconstruct what generated the client.

FAQ

Does open-sourcing an SDK generator eliminate vendor lock-in?

No. It creates a fork and inspection path. Lock-in can remain in hosted configuration, private tests, commercial tokens, release credentials, proprietary overlays, support knowledge, and undocumented language fixes. A cold build measures the remaining dependency.

Should an AI agent generate client libraries directly?

Use deterministic generation for the contract-shaped core. Agents are useful for specification repair, custom adapters, test expansion, migration notes, and diff triage. Every artifact still needs pinned inputs, compilation, behavioral checks, and human review of breaking changes.

What is the minimum continuity test?

On a clean runner with the hosted generator disabled, validate the signed contract, build the pinned compiler, regenerate every critical target, compile it, run contract and compatibility tests, produce provenance, and stage a signed candidate package without relying on undocumented vendor state.

Are SDK, CLI, and MCP outputs interchangeable?

No. They share an interface source but serve different consumers and trust boundaries. Test ergonomics, authentication, side effects, error handling, compatibility, and policy separately.