In this episode of Request Response, I sit down with Scott Dietzen, CEO of Augment Code and former CEO of Pure Storage.

We dive into why context selection has become more critical than prompt engineering, and how his team solved the fundamental challenge of giving AI agents just the right amount of codebase context to be effective without being overwhelmed.

If you're working with large codebases, building developer tools, or wondering how AI coding assistance scales beyond startup-sized projects, this episode is a must listen.

Show Notes

[00:00:53] – From machine learning PhD to startup CEO: Scott's journey to Augment Code
[00:02:05] – Anti-vibe coding: tackling enterprise-scale codebases with millions of lines
[00:02:45] – Enterprise customers and graduating from Cursor to Augment
[00:04:38] – The context problem: why LLMs struggle with massive codebases
[00:05:39] – From prompt engineering to context engineering as the new bottleneck
[00:06:35] – MCP adoption and helping ISVs package documentation for AI
[00:07:22] – The risk of getting lazy with API design in an AI world
[00:08:35] – Metaprogramming with agents and the importance of code review
[00:09:22] – AI-generated testing improving coverage and unlocking legacy codebases
[00:10:27] – The $2.5 trillion software failure problem and the promise of AI
[00:11:22] – Backlog zero: the holy grail for developers
[00:12:02] – Lessons from distributed systems: simplicity and reliability in commercial software
[00:12:48] – Engineers as tech leads for agents: human judgment still essential
[00:14:02] – Augment's differentiators: context engine, security, and IDE compatibility

In this episode of Request Response, I sat down with Tom Hacohen, founder and CEO of Swix, the Webhooks-as-a-Service platform.

Tom shares the origin story of Swix—which started as a side project to escape the pain of webhook maintenance—and how it’s grown into essential infrastructure for API-first companies.

We dive into why great developer experience means solving actual problems and how AI will reshape API design—from brittle CRUD endpoints to high-level abstractions agents can reason over.

If you're building APIs, AI infrastructure, or just tired of rewriting webhook engines, this episode is a clear-eyed look at where platform engineering is heading—and what it means to ship something developers actually love.

Show Notes

[01:18] – The founding story of Swix and the underestimated complexity of webhooks 
[04:24] – Prioritizing developer experience over implementation details
[05:42] – Early solutions: replacing homegrown webhook infrastructures 
[07:15] – Build vs. buy: the case for buying webhook infrastructure 
[09:03] – The cost of maintaining v1 and the pain of v2 and beyond 
[10:25] – Why companies rewrite their webhook systems multiple times
[12:32] – AI’s limited current impact on build vs. buy decisions
[14:24] – The human side of solution engineering and customer acceleration
[16:29] – Tool calling with LLMs and the rise of abstracted APIs
[18:19] – AI favoring flexible, NLP-friendly endpoints over brittle CRUD
[20:07] – Toward workflow-aware API responses for agents
[22:01] – Meta MCPs and hierarchical API discovery
[23:08] – Swix’s role as AI infrastructure and aligning with AI-oriented standards
[25:56] – What great developer experience really means

Additional Quotes from the Podcast

"No one cares about webhooks. They don't care about your SDKs either. They don't care about any of that. What they care about is either not having to build it or the value that their customers get."

"You can build anything... The real question is: is it worth your time and effort? Is it worth re-learning? Because honestly, writing the code isn’t the hard part—learning all the complexities and edge cases is."

"People often get developer experience wrong—they reduce it to 'good APIs and SDKs' or 'nice docs.' But it’s more than that. It’s about the entire experience—from onboarding to support to observability. Like UI design isn’t just colors, DX isn’t just code. Good DX is making the right thing easy and the wrong thing hard."

In this episode of Request // Response, I sit down with Anuj Jhunjhunwala, who leads product and design at Merge. We talk about how Merge is transforming integration pain into product velocity with their unified API approach. Anuj shares how his team helps developers avoid the complexity of maintaining dozens of APIs, and we explore the rising strategic importance of integrations in AI-driven products. We also dive into what great developer experience really looks like and how AI is reshaping expectations around API design and usability.

Show Notes

[02:30] – The pain of building and maintaining custom integrations
[03:45] – Merge as “Plaid for B2B software” and the magic moment for devs
[07:30] – AI making integrations table stakes; the three types of data
[08:30] – Why proprietary data is the key to differentiation in AI
[09:45] – AI and the future of APIs: personalization and intuitive design
[11:30] – DX vs AX: API design for devs and for AI
[12:00] – How AI product patterns are changing API requirements
[13:00] – Richer queries, delta endpoints, and evolving API design
[14:00] – The rising importance of fine-grained permissions
[15:00] – HubSpot, search endpoints, and future-facing API choices
[16:00] – Delta endpoints explained and why they’re valuable for LLMs
[17:00] – Principles of great developer experience: predictability and frictionlessness
[19:00] – Where to learn more about Merge

Additional Quotes from the Podcast

API Integrations are Table Stakes for AI

AI's Impact on API Design and Documentation

What is Great Developer Experience? 

In this episode of Request // Response, I sit down with Charlie Cheever, CEO of Expo and co-founder of Quora, to unpack the evolution of mobile app development and how developer experience is adapting in an AI-assisted world. 

Charlie shares stories from scaling Quora's mobile presence, his frustrations with App Store complexity, and how Expo is aiming to make app development as smooth as deploying a website.

From React Native to GraphQL to vibe coding, Charlie breaks down the current gaps in frontend-backend integration and offers a wishlist for what a truly great developer experience could look like—particularly in a world where more non-developers are writing production code.

Whether you're building mobile apps, exploring streaming APIs, or thinking deeply about DX tooling, this is a must-listen.

Show Notes

[00:00:00] Introduction

• Mobile app development, developer experience, Quora, and Expo.

[00:01:00] The Challenge of Mobile vs. Web Development

• Why mobile app development remains more complex than web.
• Charlie shares the motivation behind starting Expo.

[00:02:00] Quora’s Mobile Journey

• How building native iOS and Android apps took longer than launching the original website.
• Technical and organizational challenges of scaling mobile.

[00:03:00] Building Expo and React Native’s Rise

• The inspiration behind Expo: make native development as simple as the web.
• React Native’s explosive popularity and Expo’s role in democratizing it.
• Helping teams without Meta-scale infrastructure.

[00:04:00] Making React Native Work for Everyone

• How Expo bridges gaps in native app development.
• The importance of tools like Expo and Vercel in modern developer workflows.

[00:05:00] Is GraphQL Still the Right Abstraction?

• Charlie reflects on GraphQL’s evolution and current limitations.
• Comparing it to frontend framework history (Rails → React).
• The need for more end-to-end client/server coherence.

[00:06:00] Balancing State, Performance, and Cost

• Complexity in backend design due to varied use cases.
• The challenge of making highly reactive systems affordable and performant.

[00:07:00] Streaming APIs, SSE, and DX Gaps

• How the rise of real-time UX (e.g., chat apps) is stressing API design.
• No streaming standard in OpenAPI/GraphQL specs yet.
• The tooling gap for reactive and streaming data patterns.

[00:08:00] Wishlist for the Future of API Dev

• Charlie’s top priority: cost-efficiency in scalable systems.
• The hidden costs of AI-generated or streaming-heavy applications.
• The importance of default patterns that are economical by design.

[00:09:00] AI, Prompt-to-App, and Developer Onboarding

• The influx of non-developers using Expo via AI-powered tools.
• Reworking product terminology and UX for AI-native builders.
• The shift from code complexity to deployment complexity.

[00:10:00] Vibe Coding and System Architecture Risks

• The risk of vibe coding critical backend interactions.
• Why grounding AI-generated work in opinionated, proven patterns matters.

[00:11:00] Scaffolding and Guardrails for AI-Driven Dev

• The role of SSA-style rules and architectural constraints.
• Importance of enforcing standards even in semi-AI-written codebases.

[00:12:00] A Hybrid Dev World

• Current state: most repos are still human-written with AI augmentation.
• The mismatch when AI-generated code doesn’t follow team conventions.

[00:13:00] Expo’s Strategy for the AI Era

• Adapting Expo for AI-assisted builders.
• Making deploy tooling more accessible as code creation gets easier.
• Value shift from writing code to shipping product.

[00:14:00] The Magic of Going Live

• How products like Vercel V0 and Expo reduce the friction of launch.
• Sharing live URLs as the new MVP moment.

[00:15:00] Great Developer Experiences: Inspirations

• Charlie’s favorite DX examples: PHP, early Rails, undo features.
• Simplicity, feedback loops, and emotional empowerment as DX pillars.

[00:16:00] Undo and Developer Safety

• Git, Neon, and the psychological benefit of reversible workflows.
• Why safety enables faster and more creative software building.

Additional Quotes from the Podcast

How AI is Changing the Way Users Build Apps

"A huge number of the people sort of signing up for Expo accounts and stuff now are using AI sort of prompt to app tools. So we're having to build a whole new set of products or at least change some of our products 'cause some of the terminology that we use is, you know, tailored to developers and like developers know what this means or that means. And a lot of times these people are like, "I am using Expo because I saw the name come up a bunch of times as I was, you know, prompting. But I don't really know what it is and I don't know why I'm here. And what are you gonna help me do and why do I need to?"

It was always like, "Hey, like there's always people who just have ideas. How do we make those come to life as quickly as possible?" And so like for a long time it just sort of felt like, well there's this whole hairy problem of doing the writing, the code of software development, you know, writing React code, writing backend code or whatever.

And like all of a sudden that's getting way, way easier and going way, way faster."

The Magic Moment That Defines Great DX

"I think that the biggest thing that like you can give in sort of a Dev X experience is if you take somebody who like thinks they can't quite do something and that's got, something's gonna be hard, and then all of a sudden it just ends up easier than they thought. And they're just sort of on a smooth path to something happening.

I remember watching videos of people competing like in the sort of mid-2000s where, and I never even used Rails, but I just saw these where it's "make a blog in 12 minutes with Ruby on Rails." And then somebody else had put out a video that was like, make a blog in, you know, eight minutes and then seven minutes and then six minutes and just sort of like competing to get that as smooth and streamlined as easy as possible was I think pretty amazing."

I sat down with Sinan Eren, co-founder and CEO of Opnova. Opnova is building AI-powered automation for enterprises—specifically targeting companies that rely on legacy systems and lack modern APIs.

We talked about how automation can thrive even in systems that don't have APIs and discussed the challenges and opportunities of automating workflows in regulated, legacy environments. We explored how modern tools like RPA, LLMs, and new standards like MCP are changing the game.

From the rise of browser-based automation to the long-term vision of API-first ecosystems, we touched on the transitional tech that was bridging the gaps of today—and what the future might look like when APIs are truly everywhere.

Be the first to hear about new episodes: 
https://www.speakeasy.com/post/request-response-sinan-eren

Show Notes
[00:00:00] Introduction
- Overview of discussion topics: automation in legacy systems, RPA, LLMs, MCP, and the evolution toward API-first ecosystems.

[00:00:42] What Opnova Is Solving
- Sinan’s background in cybersecurity and founding Opnova.
- Automating rework: repetitive, manual tasks in regulated industries like healthcare and finance.

[00:02:00] Bridging the API Gap
- Most enterprise systems lack modern APIs.
- How Opnova helps these companies automate despite missing APIs.
- The challenges of working beyond the Silicon Valley tech bubble.

[00:03:00] Leveraging RPA and LLMs for Automation
- How Opnova uses robotic process automation and large language models.
- Modeling user behavior to automate UI actions via screenshots and intent recognition.

[00:04:58] Standards Like MCP and Tool Calling
- MCP (Model Context Protocol) and its potential to become a new standard.
- Bridging the gap for underserved industries lacking API exposure.
- Sinan’s take on early adoption and long-tail enterprise needs.

[00:06:00] APIs as a Deal-Maker
- APIs enabling last-minute customer wins in previous startups.
- Command-line over UI: why customers sometimes prefer APIs to interfaces.
- Rapid feature delivery via API access.

[00:07:54] The API Tax Debate
- Comparing API access to the “SSO tax” of the past.
- Concerns about hiding APIs behind enterprise pricing tiers.
- Why APIs should be a baseline offering.

[00:09:00] APIs as the New Sitemaps
- API discoverability as a critical factor in tool ecosystems.
- Drawing parallels between SEO-era sitemaps and today’s OpenAPI specs.
- The risk of exclusion from LLM-powered interfaces.

[00:11:58] Browser Automation as a Transitional Layer
- Why browser-based agents are a temporary solution.
- The long-term goal: native APIs everywhere.
- Transitional tooling as a necessary bridge.

[00:13:58] Tool Discovery and Registries
- The need for robust API registries to support tool discovery.
- From proof-of-concept to production: bridging the enterprise automation gap.
- The challenge of finding the right tools at the right time.

[00:15:28] Closing Thoughts and Opnova's Vision
- Browser orchestration vs. API-driven workflows.
- Why APIs are the true endgame.

More Quotes From The Discussion
The API Tax Revolution
"We have this curse in our space, it's changing now—it's called SSO tax, single sign-on tax. Why? You will have like the cheap tier, free tier, and then you'll have the enterprise tier, if you want single sign-on, if you want to tie your Okta, your EntraID into the SaaS, right? You need to buy the enterprise tier so that you can have the benefit of SSO. But I'm noticing APIs are now put in place of SSO. So SSO tax—now I worry that it's becoming API tax."

APIs as the New Sitemaps for the Agentic Era
"I feel like not having API actually is similar now. It's going to exclude you from a rapidly emerging ecosystem of tools and tool use where the discovery problem is now distributed. And so, like, what sitemaps did for websites was it said, 'Hey, I'm a website. I'm going to broadcast. I do this thing.' And then therefore any scraper ecosystem could pick it up. I think the same thing's happening with APIs."

Browser Automation: The Necessary Bridge to an API-First Future
"All this browser use models, right? Like computer use, browser use models. They are an intermediary kind of a solution, a transitional solution, right? Because we're waiting for the APIs to be exposed. So nobody really genuinely loves the idea of an agent orchestrating a Chrome browser. Really, it's just a temporary point in time that we have to do it because like you said, like, sitemaps had to be invented for better SEO."

Referenced

• Anthropic MCP (https://www.anthropic.com/news/model-context-protocol)
• OpNova.ai (https://opnova.ai/)
• Okta (https://www.okta.com/)

Production by Shapeshift | https://shapeshift.so

For inquiries about guesting on Request // Response, email [email protected].

Ken Rose is the CTO and co-founder of OpsLevel.

Ken shares the founding journey of OpsLevel and lessons from his time at PagerDuty and Shopify.

We debate GraphQL vs REST, API metrics that matter, and how LLMs and agentic workflows could reshape developer productivity.

Listen On
Apple Podcasts | Spotify

Subscribe to Request // Response
If you enjoyed this podcast, you can be the first to hear about new episodes by signing up at https://speakeasy.com/post/request-response-ken-rose

Show Notes
[00:01:08] What OpsLevel does and why internal developer portals matter

[00:01:51] Ken’s journey from PagerDuty to Shopify and to starting OpsLevel

[00:04:03] Developer empathy, platform engineering, and founding OpsLevel

[00:05:02] OpsLevel’s API-first approach and extensibility focus

[00:06:26] Using GraphQL at scale—Shopify's journey and lessons

[00:08:30] Managing GraphQL performance and versioning

[00:10:12] GraphQL vs REST – developer expectations and real-world tradeoffs

[00:11:27] Key metrics to track in API platforms

[00:12:50] Why not every feature should have an API—and how to decide

[00:13:48] Advice for API teams launching today

[00:14:44] API consistency and avoiding Conway’s Law

[00:15:50] Agentic APIs, LLMs, and the challenge of semantic understanding

[00:18:48] Why LLM-driven API interaction isn’t quite magic—yet

[00:20:00] Internal APIs as the next frontier for LLM productivity

[00:21:43] 5x–10x improvements in DX via LLMs + internal API visibility

[00:23:00] API consolidation, discoverability, and LLM-powered developer tools

[00:23:54] What great developer experience (DevEx) actually looks like

More Quotes From The Discussion

Challenges of Running GraphQL

"I can tell you as OpsLevel, running a GraphQL API, you know, all the usual things, making sure that like you don't have n+1 queries, ensuring, you don't get per resource rate limiting like you do with REST... You have to kind of be more intentional about things like query complexity. Those are challenges you end up having to solve.

Versioning is another big one. We are far enough along in our journey. We haven't done a major version bump yet. I know a few years ago, after I left Shopify, they switched their GraphQL schema to be versioned and now they have much more kind of program management around like every six months they have a new major version bump.

They require clients to migrate to the latest version, but that's effort and that's calories that you have to spend in that kind of API program management."

DevEx of REST vs GraphQL

"We have a customer that has been with us for years, but our champion there hates GraphQL. Like he really hates it. And the first time he told me that I actually thought he was like, you know, joking or being sarcastic. 

No. He was legitimate and serious because from his perspective, he has a certain workflow he's trying to accomplish, like a "Guys, I just need a list of services. Why can't I just like REST, even make a REST call and fetch last services and that's it. Why do I have to do all this stuff and build up a query and pass in this particular print?"

And I get that frustration for developers that, you know, REST is sort of easier to start. It's easier just to create a curl request and be done with it, right? It's easier to pipe, the output of a REST call, which is generally just a nice JSON up into whatever you want versus "No, you've actually have to define the schema and things change."

I think GraphQL solves a certain set of problems, again, around over fetching and if you have a variety of different clients. But there is this attractive part of REST, which is "I just made a single API call the single endpoint to get the one thing I needed, and that was it." And if your use case is that, then the complexity of GraphQL can really be overwhelming."

API Consistency and Conway's Law

"I do think consistency is an important thing, especially when you're dealing with a large company that has disparate parts working on different aspects of the API. You don't want Conway's Law to appear in your API—you know, where you can see the organizational structure reflected in how the API is shipped.

So making sure that an API platform team or someone is providing guidance on how your organization thinks about the shape of APIs is crucial. Here's how you should structure requests. Here's how you should name parameters. Here's what response formats should look like. Here's consistent context for returns and responses.

Here's how to implement pagination. It's all about ensuring consistency because the most frustrating thing as an API client is when you hit one endpoint and it works a certain way, then you hit another endpoint and wonder, 'Why is this structured differently? Why does this feel different?' That can be tremendously difficult. So having some guardrails or mechanisms to ensure consistency across an API surface area is really valuable."

Referenced
- OpsLevel (https://opslevel.com/)
- Shopify Storefront API (https://shopify.dev/docs/api/storefront)
- GraphQL (https://graphql.org/)
- REST (https://restfulapi.net/)
- Conway's Law (https://en.wikipedia.org/wiki/Conway%27s_law)
RED Metrics (https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/)
- Anthropic MCP (https://www.anthropic.com/news/model-context-protocol)
- Agents.js (https://huggingface.co/blog/agents-js)

Production by Shapeshift | https://shapeshift.so

For inquiries about guesting on Request // Response, email [email protected].

Robert Ross (@BobbyTables) is the CEO of FireHydrant.

We discuss the journey of building FireHydrant, the evolution of API design, and the impact of gRPC and REST on developer experience.

We also talked about the role of LLMs in API design, the shift towards data consumption trends in enterprises, and how great developer experience is measured by a simple litmus test.

Listen On
Apple Podcasts | Spotify

Subscribe to Request // Response
If you enjoyed this podcast, you can be the first to hear about new episodes by signing up at https://speakeasy.com/post/request-response-robert-ross

Show Notes
[00:00:00] Introduction
- Overview of discussion topics: building FireHydrant, gRPC, API design trends, and LLMs in APIs.

[00:00:42] The Story Behind FireHydrant
- Robert’s background in on-call engineering and why he built FireHydrant.
- The problem of incidents and automation gaps in on-call engineering.

[00:02:16] APIs at FireHydrant
- FireHydrant’s API-first architecture from day one.
- Moving away from Rails controllers to a JavaScript frontend with API calls.
- Today, over 350 public API endpoints power FireHydrant’s frontend and customer integrations.

[00:03:50] Why gRPC?
- Initial adoption of gRPC for contract-based APIs.
- Evolution to a REST-based JSON API but with lessons from protocol buffers.
- Would Robert choose gRPC today? His thoughts on API design best practices.

[00:06:40] Design-First API Development
- The advantages of Protocol Buffers over OpenAPI for API design.
- How API-first development improves collaboration and review.
- Challenges with OpenAPI’s verbosity vs. Protobuf’s simplicity.

[00:08:23] Enterprise API Consumption Trends
- Shift from data-push models to API-first data pulls.
- Companies scraping API every 5 minutes vs. traditional data lake ingestion.
- FireHydrant’s most popular API endpoint: Get Incidents API.

[00:10:11] Evolving Data Exposure in APIs
- Considering webhooks and real-time data streams for API consumers.
- Internal FireHydrant Pub/Sub architecture.
- Future vision: "Firehose for FireHydrant" (real-time streaming API).

[00:12:02] Measuring API Success (KPIs & Metrics)
- Time to first byte (TTFB) as a key metric.
- API reliability: retry rates, latency tracking, and avoiding thundering herd issues.
- The challenge of maintaining six years of stable API structure.

[00:17:12] API Ergonomics & Developer Experience
- Why Jira’s API is one of the worst to integrate with.
- The importance of API usability for long-term adoption.
- Companies with great API design (e.g., Linear).

[00:18:14] LLMs and API Design
- How LLMs help in API design validation.
- Are LLMs changing API consumption patterns?
- Rethinking API naming conventions for AI agents.

[00:22:02] Future of API Ergonomics for AI & Agents
- Will there be separate APIs for humans vs. AI agents?
- How agentic systems influence API structures.
- The need for context-rich naming conventions in APIs.

[00:24:02] What Defines Great Developer Experience?
- The true test of developer experience: Can you be productive on an airplane?
- Importance of great error messages and intuitive API design.
- The shift towards zero-docs, self-explanatory APIs.

More Quotes From The Discussion

Enterprise Data Teams are Now More Receptive to APIs

"I think more and more people are willing to pull data from your API. There used to be kind of a requirement many years ago of like, you need to push data to me, into my data lake. And the problem with that is, sure, we can push data all day long, but it may not be in the format you want.

It may not be frequent enough. Like, you might have stale data if we're doing, a nightly push to our customers' data lakes.

So, a lot of our customers are scraping our API every five minutes in some cases to get their incident data. And what our customers tell us is that they have data analyst teams. They have data analytics engineers that their job is to write scripts that pull the data into their internal data lake from all of their vendors. And I think that's, I don't know if it's a new trend or the new normal, I'm not quite sure, but it's definitely something I've noticed is that enterprises are spending more time building the teams to get the data in the exact format, the exact time that they want it, as opposed to having the requirement of push the data to me."

On LLMs and API Design

“I don't think that LLMs are going to fundamentally change how we interact with APIs. At least not in the short term.

I think that they'll help us build better clients and I think they'll help us build better APIs, but the moment we start using them, I mean, that's just going to be code calling code. I just don't think that LLMs are going to get too integrated at that point.”

Referenced
- FireHydrant the end-to-end incident management platform (https://firehydrant.com)
- Linear API docs (https://linear.app/docs/api)
- Offset's Materialize RBAC system (https://materialize.com/docs/manage/access-control/rbac)
- Speakeasy's Terraform generator (https://docs.speakeasyapi.dev/docs/using-speakeasy/client-sdks-generation/terraform)

Production by Shapeshift | https://shapeshift.so

For inquiries about guesting on Request // Response, email [email protected].

On the first episode of Request // Response, I speak with John Kodumal, co-founder and former CTO of LaunchDarkly.

We discussed how LaunchDarkly used feature flags to separate deployment from release, offering fine-grained control for safer rollouts and experimentation.

LaunchDarkly was an early adopter of server-sent events, and was a pioneer of the technology even before LLMs.

Tune in to hear our thoughts on the changing demands and expectations for APIs and developer experience in light of agentic era of APIs.

Listen on

Apple Podcasts | Spotify

Where to find John Kodumal

• LaunchDarkly.com
• LinkedIn: https://www.linkedin.com/in/jkodumal/

Show Notes:

[00:00:00] Introduction

• Sagar welcomes John Kodumal to the podcast.
• John’s background as co-founder and former CTO of LaunchDarkly.

[00:00:28] What is LaunchDarkly?

• LaunchDarkly's role in separating deployment from release.
• The impact of fine-grained feature flag controls.
• Benefits: safer rollouts, experimentation, controlled beta releases.

[00:02:18] Pre-LaunchDarkly Era

• How companies previously handled feature releases.
• Homegrown tools and their limitations.
• Inspiration from early DevOps talks, including Flickr’s feature flagging.

[00:05:26] LaunchDarkly’s API and SDK Focus

• The importance of embedding into the software development lifecycle.
• Learning from Atlassian’s approach to API-driven development.
• Early investment in API design and OpenAPI specifications.

[00:10:37] Technical Deep Dive: SSE and Feature Flags

• Use of Server-Sent Events (SSE) for real-time feature flagging.
• Challenges with existing SSE open-source libraries.
• Ensuring consistency across distributed systems.

[00:14:23] The Evolution of API Expectations

• Increased demand for standardized, high-quality APIs.
• Importance of pagination, rate limiting, and caching.
• Growing role of OpenAPI specifications in modern API development.

[00:19:26] Traversability and Developer Experience

• APIs as traversable maps for both humans and machines.
• Comparison to REST principles and the Fielding Thesis.
• How great APIs lower integration barriers for developers and AI agents.

[00:22:40] What Defines Great Developer Experience?

• Macro and micro-scale perspectives on DevEx.
• Anticipating user needs and providing escape hatches.
• Importance of small but impactful UX details.

[00:26:23] Closing Thoughts

• The significance of developer experience in building tools.
• How LaunchDarkly has influenced modern software development.

Subscribe to Request // Response

If you enjoyed this podcast, you can be the first to hear about new episodes by signing up at
https://speakeasy.com/post/request-response-john-kodumal

More John Kodumal Quotes From The Discussion

1. Feature Flags Are Powerful
   “A lot of people look at just that idea of feature flags, and they think that it's small, and they're shocked that there's a multi billion dollar company that does feature flags. But it's not about feature flags. It's about all the changes to the software development lifecycle that feature flags enable”

2. Traversability Over Endpoints
   “Nothing should be an endpoint. Everything should be traversable. If you have an endpoint, it's broken.”

3. Working With The Complexity of Developer Needs
   “In order to fit into someone's SDLC you have to respect the differences that make their software development practices unique—you have to work with them, not force a one-size-fits-all solution.”

Referenced

• Flickr DevOps Talk on Feature Flagging (2009) https://www.youtube.com/watch?v=LdOe18KhtT4
• OpenAPI Spec https://spec.openapis.org/#specifications

Production by Shapeshift | https://shapeshift.so

For inquiries about guesting on Request // Response, email [email protected].