The Developer Tools Podcast with Fexingo · 2026-06-30 · 9 min
Key moments - from our scoring
Substance score
54 / 100
Five dimensions, 20 points each
The episode examines the business and technical case for generating client libraries from API specifications rather than maintaining hand-written code. Drawing on Twilio's 2016 shift to code generation - where they reduced bugs by roughly 90% and cut release cycles from weeks to hours - the hosts explore why teams persist with manual libraries despite clear evidence of generation's superiority. They discuss how generation templates, written once by humans, enforce idiomatic patterns consistently (Python's keyword arguments and PEP 8 compliance, for example) while exposing gaps in API specifications. The conversation covers available tools including OpenAPI Generator (supporting 50+ languages), Fern (which generates documentation and playgrounds), and Speakeasy (handling package manager publishing). Even Stripe, the gold standard in API design, now uses hybrid approaches - generating mechanical parts like serialization and routing while hand-crafting high-level developer ergonomics. The episode targets API-first companies and platform teams deciding between maintenance costs of multiple language SDKs versus upfront investment in specification-driven generation pipelines.
Twilio's engineering team saw bug counts drop by approximately 90% across all six language SDKs (Python, Ruby, Node.js, PHP, Java, C#) after implementing their code generation pipeline based on their Twilio API Spec.
The main options are OpenAPI Generator (open source, supports 50+ languages), Fern (generates clients, documentation, and playgrounds with a focus on developer experience), and Speakeasy (emphasizes idiomatic clients and handles package manager publishing).
Generation immediately exposes inconsistencies and gaps in API specifications; if the spec is incomplete or poorly defined, the generation process will fail or produce unusable code, forcing teams to treat the specification as the authoritative source of truth.
Teams need a machine-readable specification (such as OpenAPI) as a prerequisite; without one, code generation isn't possible, so the initial step is getting the API spec in order before selecting and running a generator tool.
A hybrid approach works well - teams can generate repetitive, error-prone parts like serialization and endpoint routing while hand-writing high-level patterns and developer-facing ergonomics, as Stripe does with its Python library.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode covers solid foundational points (generation vs. hand-writing, Twilio's 90% bug reduction, the spec-as-forcing-function) but relies heavily on a single canonical example and doesn't dig deeply into trade-offs or failure modes. Most insights are relatively straightforward; the discussion of edge cases (bundle size, debugging difficulty) is acknowledged but not thoroughly explored, and the advice clusters around repeating the same core argument rather than layering new understanding.
Before generation, each hand-written library had its own set of bugs - things like incorrect parameter types, missing endpoints, inconsistent error handling. After generation, the bug count dropped by something like 90 percent across the board.
Generation forces you to treat the spec as the source of truth.
The core thesis - generation beats hand-writing - is standard industry wisdom by 2024, not contrarian or novel. The Twilio example, while concrete, is well-trodden ground in API design circles. The hosts do offer a mild originality boost by proposing a hybrid approach (generate boilerplate, hand-craft ergonomics) and invoking Stripe's partial automation, but neither feels like genuinely fresh thinking - both are pragmatic middle-grounds that practitioners already understand.
Their Python library, for instance, uses a code generator for parts of the code that deal with API resources.
I think within a few years, hand-writing client libraries will feel as archaic as hand-writing SQL queries used to feel before ORMs.
Luna's role and background are never established in the transcript; she appears to be a co-host or regular contributor rather than a guest expert with demonstrated operational credibility. While she speaks intelligently about client library strategy, there's no indication she has built or shipped API infrastructure at scale, maintained SDKs, or designed generation pipelines. The conversation feels peer-to-peer rather than host interviewing a seasoned practitioner.
I've definitely seen teams spend weeks hand-crafting a Python SDK, only to have it fall out of sync with the API within a quarter.
I've seen Fern used by a few startups.
The episode provides one strong concrete metric (Twilio's 90% bug reduction) and names three specific tools (OpenAPI Generator, Fern, Speakeasy), plus mentions Stripe and Twilio as case studies. However, specificity drops away quickly: no details on the actual bug types, no data on time-to-maintenance costs, no numbers on bundle size impact, no customer acquisition data, and only vague references to 'weeks or months' and 'hours.' Claims about developer experience and retention are asserted but not backed with evidence.
After generation, the bug count dropped by something like 90 percent across the board.
The most well-known is OpenAPI Generator, which is open source and supports over 50 languages. But there's also Fern, which is a more opinionated tool built specifically for developer experience.
The hosts move through talking points methodically but rarely challenge each other or dig into hard objections. When edge cases surface (bundle bloat, debugging difficulty, losing the 'story' of code), they are acknowledged but swiftly reframed as acceptable trade-offs without sustained investigation. There are no moments of genuine disagreement or pressure-testing claims. The exchange reads more like a prepared script where both speakers are aligned rather than a dynamic exploration where one pushes back on the other's assumptions.
That's a legitimate concern, and it's why some teams prefer a 'lazy loading' approach - where the client only fetches the endpoint definitions it needs at runtime. But honestly, for most use cases, the bundle size difference is negligible.
Right, you lose the 'story' of the code. But on the other hand, you gain consistency. I think it's a trade-off most teams would accept if they saw the data.
Computed from the transcript - who did the talking, and the words that came up most.
Many engineering teams spend weeks hand-writing API client libraries for different languages - only to let them drift out of sync with the actual API. In this episode, Lucas and Luna dig into the case of Twilio, a company that generates client libraries automatically from its API specification. They walk through how Twilio's code-generation pipeline works, why hand-written clients introduce bugs and maintenance debt, and the surprising cost of the 'just one more language' request from customers. If you've ever maintained a client library or wondered why your SDK is always a version behind the API, this episode covers the specific trade-offs and the open-source tools you can use today (like OpenAPI Generator and Fern) to automate the process. No hype - just the concrete engineering decisions behind generated clients. #API #ClientLibraries #CodeGeneration #Twilio #OpenAPI #SDK #DeveloperExperience #APIProductivity #SoftwareEngineering #Infrastructure #Automation #BusinessAndTechnology #FexingoBusiness #BusinessPodcast #DeveloperTools #APIStandards #Fern #OpenAPIGenerator Keep every episode free: buymeacoffee.com/fexingo
Transcribed and scored by The B2B Podcast Index.
Lucas: If these conversations are useful for what you're building or running, stick around - but let's start with a question that I think every api first company has debated at some point: should you write your client libraries by hand, or generate them automatically? Luna: I've definitely seen teams spend weeks hand-crafting a Python SDK, only to have it fall out of sync with the API within a quarter. So I'm biased toward generation. Lucas: Right, and the canonical example that keeps coming up in this debate is Twilio.
Back around 2016, Twilio's engineering team realized they were maintaining six separate hand-written client libraries - Python, Ruby, Node.js, PHP, Java, C#. Luna: And each one had its own bugs, its own patterns, its own documentation. It was a nightmare.
Lucas: Exactly. So they built a code generation pipeline that reads the API specification - which, at Twilio, is a custom JSON schema they call the Twilio API Spec - and spits out idiomatic client code for each language. Luna: And they open-sourced the tooling, right? I remember a talk from Twilio's developer experience team where they showed that generated clients had a fraction of the bug rate of the hand-written ones.
Lucas: Yeah, the numbers were stark. Before generation, each hand-written library had its own set of bugs - things like incorrect parameter types, missing endpoints, inconsistent error handling. After generation, the bug count dropped by something like 90 percent across the board. Luna: And it's not just about bugs.
It's about time to ship. If you add a new endpoint to your API, with a generated pipeline, that endpoint is available in all six languages within hours. With hand-written libraries, you're looking at weeks or months of PRs. Lucas: Honestly, if today was worth a coffee to you, that's the link - buy me a coffee dot com slash fexingo.
Now, back to why hand-written clients persist despite that evidence. Luna: Yeah, I think there's a belief that hand-written code is more 'idiomatic' or 'developer-friendly'. But the data doesn't really support that. Lucas: Right, let's talk about what 'idiomatic' actually means in practice.
If you look at Twilio's generated Python client, it uses keyword arguments, context managers, and follows PEP 8 - exactly what a hand-written library would do. But the key is, the generation template enforces those patterns consistently. Luna: So the templates themselves are written by humans - once - and then the machine applies them perfectly every time. That's a different trade-off than hand-writing each endpoint.
Lucas: Exactly. And the other argument I hear is that generation forces you to have a well-defined API spec. Which is actually a benefit - if your API spec is incomplete or inconsistent, the generation process will expose that immediately. It's a forcing function for API quality.
Luna: That's a really good point. A lot of teams have a 'spec' that's just whatever is in their documentation, and it's out of date. Generation forces you to treat the spec as the source of truth. Lucas: So what tools are actually available today?
The most well-known is OpenAPI Generator, which is open source and supports over 50 languages. But there's also Fern, which is a more opinionated tool built specifically for developer experience. Luna: I've seen Fern used by a few startups. It generates not just the client code but also documentation and a playground.
The whole 'SDK as a product' thing. Lucas: Right, and there's also Speakeasy, which focuses on generating idiomatic clients and also handles publishing to package managers. So the ecosystem has matured a lot since Twilio first built their internal pipeline. Luna: But I think the hurdle for a lot of teams isn't the tooling - it's the decision to commit to a spec-first workflow.
That requires discipline across the whole engineering org. Lucas: Yeah, and that's where the business case comes in. If you're an API company, the client library is often the first thing a developer touches. If it's buggy or incomplete, you lose trust immediately.
So investing in generation is investing in developer acquisition and retention. Luna: There's also the maintenance cost. Every hand-written library needs a dedicated maintainer or team. If you have six languages, that's six salaries or at least six part-time contributors.
Generation reduces that to one team that owns the templates and spec. Lucas: And that team can focus on making the templates better - adding new language features, improving error messages, optimizing network calls. The return on that investment compounds. Luna: But what about edge cases?
I've heard concerns that generated code can be bloated - that it includes everything from the spec even if the developer only uses a few endpoints. Lucas: That's a legitimate concern, and it's why some teams prefer a 'lazy loading' approach - where the client only fetches the endpoint definitions it needs at runtime. But honestly, for most use cases, the bundle size difference is negligible. The bigger issue is sometimes the generated code can be harder to debug because it's not written in a way a human would naturally write it.
Luna: Right, you lose the 'story' of the code. But on the other hand, you gain consistency. I think it's a trade-off most teams would accept if they saw the data. Lucas: Let's look at another example: Stripe.
They have a famously well-designed API and hand-written client libraries. But even Stripe has moved toward more automation. Their Python library, for instance, uses a code generator for parts of the code that deal with API resources. Luna: Interesting.
So even the gold standard of API design is hybrid. They generate the boilerplate but hand-craft the developer-facing ergonomics. Lucas: Exactly. And that's a pragmatic middle ground.
You generate the repetitive parts - the serialization, the endpoint routing, the error handling - but you let a human design the high-level patterns that make the library feel natural. Luna: I think that's the key insight. Generation doesn't have to be all or nothing. You can generate the parts that are mechanical and error-prone, and hand-write the parts that require taste.
Lucas: Exactly. And if you're starting a new API today, I think the default should be generation. The tooling is mature enough that the cost of setting up a pipeline is lower than the cost of maintaining even one hand-written library over its lifetime. Luna: So what's the first step for a team that wants to move to generated clients?
Do they need to have an OpenAPI spec first? Lucas: Yes - or any machine-readable spec. That's the prerequisite. If your API isn't defined in something like OpenAPI, you can't generate.
So step one is to get your spec in order. Then you pick a generator - OpenAPI Generator, Fern, Speakeasy - and you run it against your spec. Luna: And then you compare the generated output to your existing hand-written client. That's usually the moment of truth.
Lucas: Yeah, and you'll likely find gaps. Maybe the generated code doesn't support a particular authentication flow or a custom pagination pattern. But those gaps are fixable - you can customize the templates or extend the spec. Luna: And once you see the generated client working for your main use case, it's hard to go back.
I think within a few years, hand-writing client libraries will feel as archaic as hand-writing SQL queries used to feel before ORMs. Lucas: That's a strong take. But I think it's probably right. The economics are just too clear.
If you care about developer experience and you want to move fast, generated clients are the way to go. Luna: And the community is moving that way too. The OpenAPI Generator project has thousands of contributors. It's not a niche tool anymore.
Lucas: So if you're listening and you're maintaining a hand-written client library, maybe today's the day you take a look at your spec and run a generation experiment. Worst case, you learn something about your API. Best case, you save your team months of work. Luna: I like that.
A low-risk test that could pay off big. Lucas: Alright, that's our case for generated client libraries. Thanks for listening, and we'll talk to you next time.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
How Kubernetes Topology Spread Constraints Create Scheduling HotspotsDevOps Daily with Fexingo · features Luna95 / 100
How B2B Brands Wreck Pipeline with Unsyncroned CRM DataThe Marketing Operator Podcast with Fexingo · features Luna92 / 100
How Incrementality Reveals True Marketing ImpactMarketing Analytics with Fexingo · features Luna90 / 100
How to Sell Against a Competitor Already in the BuildingSales Leadership with Fexingo · features Luna85 / 100
Why B2B Brands Are Using AI for Account PrioritizationThe Growth Operator with Fexingo · features Luna84 / 100
Enterprise Software Buyers Now Demand a Vendor Data Portability GuaranteeB2B SaaS Talks with Fexingo · features Luna82 / 100
Why Your API Should Support Cursor PaginationWhy Your API Should Use Long Polling for Real-Time UpdatesWhy Your API Needs a Backward-Compatible Versioning StrategyHow to Sell Your API to a Billion-Dollar PlatformWhy Your API Needs a Webhook Signature Verification