AWS moves Smithy Kotlin client code generation to general availability

Amazon Web Services has promoted Smithy Kotlin client code generation to general availability, the company announced on its developer blog on 2 April 2026. The release closes out a developer-preview period that, according to AWS, ran for several years, and signals that the generated clients are now considered stable enough for production workloads.

Smithy is AWS's interface definition language, used internally to describe service APIs and generate client libraries in multiple languages. The Kotlin generator sits alongside existing Smithy targets and produces strongly typed Kotlin code that handles serialization, protocol details, and the request-response lifecycle automatically, removing much of the boilerplate that teams would otherwise maintain by hand.

According to the AWS developer blog, the generated clients target Kotlin and run on the Java Virtual Machine, which means they slot into existing JVM build systems, concurrency primitives, and the wider Kotlin ecosystem without special accommodation. Developers define services, operations, and data shapes in a declarative Smithy model, and the generator produces typed operations plus matching serializers and deserializers, keeping the client implementation aligned with the canonical API definition.

The underlying design of Smithy matters here. As documented at smithy.io, Smithy is protocol-agnostic — it decouples the description of a service's data structures and capabilities from any particular transport or serialization format. That separation is what makes code generation tractable across languages: a single model can produce clients for different runtimes, and a service owner can change transport details, such as moving from HTTP/1 to HTTP/2 or from text to binary serialization, without rewriting every client.

What the general availability label changes

General availability in this case is less about new features and more about a stability commitment. AWS describes the milestone as reflecting production readiness, stability, and broader confidence in adopting the generated clients as part of standard development workflows. Practically, that means teams can build their service integrations on the generated clients without the caveats that typically attach to preview code — though AWS has not, in the post, published a formal SLA, support tier, or version-support window for the generator itself.

Why model-driven generation matters for service owners

The value proposition is consistency. A service team writes one Smithy model, and the generator produces a Kotlin client that mirrors that model exactly — typed operations, shape constraints, error mappings, and all. When the service changes, the model changes, the client regenerates, and the two stay in sync. That eliminates a class of bug in which a hand-maintained client drifts from the live API and breaks silently in production. The smithy.io documentation also notes that Smithy models can be projected and filtered for different audiences, so the same model can yield both an internal and a public-facing client without duplicating definitions.

Where the tool still leaves work to the developer

Code generation handles the wiring, not the design. Teams still need to author a good Smithy model — capturing constraints, error shapes, and protocol bindings correctly — because the generated client is only as faithful as the model it reads. AWS has also not published benchmarks comparing the performance of generated Kotlin clients against the existing hand-written AWS SDK for Kotlin, so claims about runtime efficiency, cold-start behaviour, or bundle size remain unverified by any independent testing cited in the announcement. Adoption will also depend on how well Smithy Kotlin fits into existing Kotlin build pipelines; AWS points developers to its quick-start example and the client generation guide for the mechanics.

The next test for Smithy Kotlin will be uptake outside the AWS ecosystem. Smithy itself is not AWS-specific — the smithy.io FAQ explicitly states that AWS-specific metadata is implemented as decoupled packages, and that Smithy can be used alongside OpenAPI by converting models between the two — but the Kotlin generator has so far been documented primarily in the context of AWS service clients. Whether non-AWS service teams adopt it as a default Kotlin SDK generator is the open question the GA milestone does not, by itself, answer.

According to the AWS developer blog, developers can get started with Smithy Kotlin client code generation via the project's quick-start example and documentation page, and can submit feedback or questions through GitHub issues and GitHub discussions.