Sagar Batchu, CEO and cofounder of API tooling company Speakeasy, talks with Ryan about the evolving API landscape, AI integration, the role of human technologists in an increasingly automated environment, and what people building APIs right now should keep in mind.
Speakeasy builds API tooling for developers.
Find Sagar on LinkedIn.
Kudos to Stack Overflow user Bergi, who earned a Lifeboat badge with an exemplary answer to What is the Universal Module Definition (UMD)?.
[intro music plays]
Ryan Donovan Hey there, listeners of the Stack Overflow Podcast. I'm going to be at the HumanX conference in Las Vegas from March 10th through March 13th. We'll be recording episodes with some of the speakers, as well as asking questions of folks on the floor for special compilation episodes. If you're attending and want to meet up, email me at podcast@stackoverflow.com. Hope to hear from you.
RD Hello, everyone, and welcome to the Stack Overflow Podcast, a place to talk all things software and technology. I am your humble host, Ryan Donovan, and I, like my guest today, am not a robot, but many of the API users may be, so we're going to be talking today with Sagar Batchu, the CEO and co-founder of Speakeasy. We'll be talking about how the shift in API's primary users is moving towards AI. So welcome to the show, Sagar.
Sagar Batchu Thanks so much for having me. Really looking forward to this.
RD So at the top of the show, we like to ask our guests how you got into software and technology.
SB So I had a somewhat nontraditional start into the space. I actually studied physics in college and was pretty much on track to do experimental physics, be in the lab, collect data, run models, and I was pretty sure I was going to do a PhD, but then realized through that process what I liked the most was actually building the software to analyze the data and actually make it real. And so I kind of pivoted in my last year of college, took as many CS classes as I could, and then came to the Bay Area immediately after that. I did actually firmware and stuff a lot closer to hardware for a while and then transitioned into software. And when I did, it was kind of the start of the big cloud transition, big data was a thing, things like API-first, those kinds of terms were just starting to appear and I was lucky to go to a few great opportunities. I made my way to maybe my most foundational kind of experience with a company called LiveRamp. It's a big ad tech company. When I joined in 2017, they were really starting to scale, pushing petabytes of data through the product every day. It was truly massive scale powering really kind of programmatic ad placement on a lot of the major sites you would use in the United States. And as a result of that, there was a big push towards building APIs for software, and we also did this massive transition from on-prem to the cloud. I think we were GCP’s– Google Cloud Platform’s– second biggest customer at the time. So I was very fortunate to be part of such a wave of growth at a company and it ended up taking me out to London and helping them kind of bootstrap a team there which was a great experience in itself. So that was my journey to software– not the traditional start, but then kind of entered the industry at a very opportune time, a lot of change, not too unlike the change we see today with the AI wave. I think this is maybe my second time experiencing kind of a paradigm shift.
RD I mean, they keep coming, the paradigms keep shifting.
SB Absolutely.
RD So how did you come to found or co-found Speakeasy?
SB So as part of my time at LiveRamp, as I mentioned, when we went through this really big API transformation. I was lucky enough to work with some really senior architects and leaders that were really thinking about how we enable teams to ship the APIs consistently at scale. And you're talking about an engineering team that's kind of responsible for a couple hundred million in revenue, at the time it was a public company, and also growing an engineering team of 500 to 800 engineers all over the world, multi-region teams. And when you want to do that and move quickly, you really need to invest in what I call API platform, or platform engineering. You want to build out kind of core components that embody the guidelines, the best practices of your company, and then ship those as components to all the other teams to use. And so you take off a lot of the boilerplate and you reduce the mental load by baking in a lot of the decisions into that. And so as we were doing that, I got quite deep into building out DevEx tooling for a lot of the teams that became my core focus after a while. And so when I left, I was looking around and noticed that this pattern of platform engineering was very common actually at companies at scale, right across GitHub, Stripe, Twilio, all the big names, but also all the companies you may not have heard of but have big and great engineering teams really invested in similar patterns of development. So that led me down the rabbit hole of exploring is this market big enough for a company, a venture-backed company, and so that's what brought me to Speakeasy.
RD It's interesting, you talk about the API-first shift. I remember there was a lot of talk years ago about human-computer interaction user interface but a lot of that has shifted to talk about the API interface development. What do you think accounts for that shift?
SB I think a couple of things account for the shift. I think the software has gone through a couple of waves here, and one of the critical waves that we had was right after the shift to the cloud in the mid-2010s. There was also the shift towards service-oriented architectures, and that was really enabled by the fact that, on the cloud, any development team could do a Helm or Docker deploy and spin up services very quickly. You didn't have to ship software to your on-prem data center. And as a result, there was this school of thought that said that every team can build very clean, simple services that are responsible for a unit of work for the company. I think it was definitely a bit of a fantasy, I have to say. In reality, we all know it's a much more messy mix of monorepos and monolithic services really and then some microservices as a team gets bigger. And so I think that shift to the cloud was probably the first big motivation behind a more API-first view of the world.
RD That's an interesting point, the sort of distributed back end built for resiliency and redundancy. It's like the APIs is how they're talking to themselves, and sometimes you could just slip one of those APIs out into the world. Maybe we're going to sell this API, we've been using it internally, maybe somebody else would want to use it.
SB Exactly. And I think I've heard this question a bunch of times and had lots of interesting thoughts about it, and I think my initial leaning on this was, as you said, people want to build resilience into their architectures and people really care about API design and stuff, but I really do think the motivating factor is actually infrastructure. Infrastructure got cheaper, faster, easier to access, and that's what made it easier to go into this service-oriented architecture. We already had these protocols and specifications, and REST API design is pretty old. It's 20-30 years old, and so that didn't change, but to be able to enact it became a lot easier, which I think fundamentally has actually made all of this possible.
RD And now obviously I hear a lot of people talking about API-first in terms of AI with AI agents being the thing that is using the APIs at this point. Obviously AI is one of the big drivers of the increasing API application, but do you think that everyone will need to have an API to survive?
SB I kind of break it up into two parts. I would say there's kind of APIs as products, like APIs that we build dependencies around, these third party service providers, and then there are APIs internally at a company. It's more of a model of how we can organize ourselves as companies. And so I think both are very much needed, both are I think a key element of how software is built in companies at scale today. I think what's interesting is with the oncoming AI wave, and really I think we're in day zero of that, is that you're definitely moving towards more machine-to-machine communication. Less developer-oriented, developer built out workflows, and so you're actually going to have, I think, fundamentally more APIs. Now those APIs may not look like traditional APIs, but fundamentally they will be contracts that services or systems expose to each other. So I think we had one big API shift with the API-first and API business model that appeared with payments APIs and all of that stuff leading the way. I think we're about to have a second shift with agents and that whole world pushing companies to make the services API for us.
RD I know that my last company had a lot of customers that used the API, but some of the APIs exposed in the client application were not meant for customers to use, but they were there, they were discoverable, customers used them anyway. Do you think this will cause companies to sort of rethink what they have exposed on their front ends?
SB If you actually look at the numbers, I think it's something like 60 or 70% of websites don't have APIs. They're just front ends and UIs and I think there's two ways to look at it. I think the immediate situation right now is going to be that agents are going to probably try to interact with browsers directly through computer vision. Back in the day, you would build out a QA testing workflow with Selenium or something where you click through the browser and then that workflow is emulated for you on a cron or a schedule. I think agents will try to do the same thing. I think that's how we cope today with the system that we have. I think the medium term is that we will start to generate APIs for websites that don't have them, and I know there are actually some startups out there that actually are trying to do that today. And then finally there's probably a long-term thing which gets rid of all of the traditional paradigms that we see today with JSON web-based architectures and something that's much more machine-oriented. So I kind of think of it as phases, much like you have autonomous vehicles on the road today and there's kind of a mixed situation today and over time maybe we'll see something completely different.
RD Did you think there's ever going to be a shift prioritizing the AI agent, like having an API that does all the button clicks, all the JavaScript events, runs a shadow DOM in there or something?
SB I think you're going to have a lot of headless browsers and agents spinning up browsers, browser instances as well, to do all of this. I think we think of the browser today as, to your point, something that a human interacts with, but as you said, you can have shadow DOMs, you can have instances of a browser running in the background that you're fully unaware of. It's really quite an interesting world we're about to step into. I think it's both extremely exciting and a tad scary too at the same time. I think we're really not quite ready. We can kind of guess what's going to happen, but I think we'll only really learn by letting it play out.
RD Are we seeing effects of the sort of programming paradigm shifting at this point, or is it all future?
SB I think today a ton hasn't shifted, if I'm being really honest. So obviously the arrival of LLMs, that's a big shift, but how we program software hasn't significantly shifted. There are, of course, great aides, they power Copilot experiences, so it's still humans writing and shipping code but with a lot of guidance and input. The agent side of this is interesting because that's where we actually really get into some real delegation. We say, “I want this task done,” and this agent will then have the ability to do API discovery just like a human does API discovery, does API integration just like a human does, and then there's the actual API integration and response handling and all of that, just like a human does. So I think the agentic side is going to be the really interesting one for me from how it impacts how I actually develop every day, but I think we're still in day zero. There are agentic tools, there are those kinds of things, but it's still all really working off of all the resources that have been designed for humans, so docs, API guides, SDKs, all of that good stuff. We'll probably see more of what we're seeing from companies like Anthropic. So Anthropic released something called MCP– Model Context Protocol. It's really a first attempt at a spec that describes the resources an agent can have access to when interacting with an API. And it's only I think a half-step away from OpenAPI today, it isn't significantly different. But over time, I think those things will diverge.
RD That's interesting. The web in a lot of ways is built on these open standards. Do you think something like this Anthropic one will stick or is it going to be like every other standard where maybe the first one doesn't take, maybe there's these massive battles where whatever other standard falls back, falls away?
SB Absolutely. I think we will definitely see in the short term more chaos before stability where we'll see probably every major LLM provider have their own spec. I think something will come out and win, I think probably something open source that works well with the existing ecosystem of OpenAPI and all the tooling around that. And then finally, I'll say that I think something that is going to really decide who's the winner here is what gets ingrained most in our daily development workflows. I think there's still a significant period of time during which we are going to be doing coding as developers. The true fully automated code generation top to bottom is still a ways away and so it's going to have to be something that is a mix of human readable and also machine readable.
RD So are the existing back ends ready for the sort of agent-only API access? Is there going to have to be some sort of fundamental shift in how back ends are designed?
SB I think we're going to have to be ready for a higher volume for one, just traffic. If you look at the way agents work today, all the different models of build-out of agents, including RAG, which is the most common one, is all based on much higher traffic. There's a little bit more trial and error involved, there's a learning process involved. And so today, if you think about how we do integration, I'm going to bring up an API client, I'm going to test out the client, maybe it's a really nice doc set, it has testing built in. I do that a couple of times and then I know what to do and then I deploy, I write out a production integration and deploy that. But with agents, they're really doing discovery, testing, integration all on the fly, and so I think you're going to get 10x as much API requests. I also think with back ends today there's a lot of other aspects of integration that are very human-oriented. Let me pick one– authentication. Most enterprise APIs today probably focus on OAuth as the standard auth mechanism. OAuth is really interesting because a lot of OAuth is centered on this idea that you can kind of provide a client ID in secret to your customer and then they can use that to actually fetch a token that expires based on some period of time. And there's many variants of OAuth, of course, but you can see it's very oriented on human interaction, fetching a token, logging in to a dashboard. There's that element of it which doesn't really make sense for an agent. Sure, it could spin up a browser instance and go get the token, but that just feels very inefficient and prone to issues. Instead, what we might want is something a little bit closer to service accounts that cloud providers use for IAM or any of the service-to-service permissions authorizations. So the OAuth model itself is probably going to evolve to support agents. But I haven't seen much on this yet. We have our own theories, but it's truly day zero here.
RD That's interesting. It's all trying to evolve past passwords. Passwords seem like they were discovered to be so insecure that we're like, “How do we get some other way to do this?” You talked about platform engineering, what's the platform engineering's role in sort of preparing for the AI API-first future?
SB If I had to be really concrete, I think given API platforms today, I think you still want to focus on the basics. I think the coming world is going to shift so quickly and rapidly that you want some foundational pieces in place. You want a great, I think, workflow and process around how you update your API spec internally at a company. It might sound silly, it's just one document, but there's so many people involved that touch that document every day in a company, especially if it's anything that is remotely API-related as a product. And so really focusing on getting that workflow and the process and the kind of technical writing on an API spec in a really good place I think will mean that your APIs, especially third party APIs, will be set up for consumption by agents. I also think that there's a whole ecosystem that's evolving here, and I think for many companies, especially the larger ones, it's important to have someone in your organization kind of focused on building a strategy here and really experimenting and trying out new things. So I think for platform teams, it comes down to this amount of mindshare that is going to have to go towards keeping up with this pretty quickly evolving ecosystem.
RD We had somebody else on the podcast recently talking about the API agent intersection and they said that there's going to be robots in a robotic factory building other robots. First, do you think that's an apt description of the future of the web, and do you think there's going to be a role for humans in this or are we just consumers?
SB Good question. I think there will be a role for humans here. I think it again really matters on what time scale we're talking about. I think in the near term, not a ton changes. It's more of an AI-augmented development. I think in the medium term, it becomes AI-driven development. Those are kind of buzzy words, but I can give you a concrete example I see today in our own company. You have a lot of developers, all of them really, using IDE-based solutions for AI-augmented development, so Cursor AI or GitHub Copilot, really popular one, Supermaven. There's a bunch of tools that are all really hot right now, and what they do is they help you write code and you ship some of that code alongside as you submit a pull request for the code that you're changing. Now, recently we've tried another tool called Devin which is a slightly different model where you kind of Slack it a message and you say, “Hey, this is what I want to do,” and then it opens the pull request for you, kind of end-to-end. And that small change in UX was quite interesting to me because the first one is really ‘I'm still the owner and I'm shipping code and I'm making a feature and a change,’ but the second one is fully AI-owned. And so when the pull request comes in, it says, “This is Devin, this is Devin trying to do something for you.” So that small change in UX is actually kind of eye-opening to me in terms of how this all might evolve. And if you kind of extrapolate that out, you can probably come up with a lot of fantasies around what this could be. It could be kind of a complete chat interface where you talk and then you program. I think Vercel’s v0 is another great example where you kind of chat and then it gives you a front end and you can one-click deploy into Vercel’s platform and see what it looks like in real time. So I think there’s still a huge role for humans in the short and medium term, long term anything's possible. I think that the model space the layer below us is obviously also changing rapidly and we'll have to see where that goes.
RD The long term is of course we have the war with the AIs and then we have to all become mentats.
SB Sure.
RD I've heard of Devin and seen the sort of AI-as-junior-developer interface, but I've also seen a lot of folks kind of complaining that the code that comes in from these AI agents is still not worth the cost of reviewing it. Do you think that the pure chat interface has a place or are we a little too soon for that?
SB I think it is a bit too soon. You're right, a lot of the code that comes out of these platforms is best suited for junior engineering tasks, as you mentioned. As this goes on, I think the roles are going to get more important as the moat around application engineering kind of erodes, but I think the moat around infrastructure engineering and systems engineering and QA, interestingly, I think actually gets deeper because now you have AI potentially trying to do all the work of an application engineer, like build a product, but the things around it then become extremely important, like the infrastructure that it's going to deploy on, how do we test this thing, how do we build suitable test harnesses? So people say the AI can build its own test harness, that might be true, but then there's still an aspect of measurement. Are we measuring the accuracy, the AI bias, the AI safety? There's a lot of things that are I think new realms of development engineering that could evolve. We've seen a little bit of it with prompt engineering showing up on a few JDs in the tech world.
RD It seems like ultimately there has to be a human who wants something and says what the specs are. Hopefully we don't get to a future where the AI is just wanting something and on its own coming up with specs for whatever Terminator it has in mind.
SB Sure. There's a ton of utility we can get out of this. Right now, I've seen it in our own team day to day. I think it does put the onus on us as engineers to really deepen our expertise in areas. And the more of an expert you are, I think the better you will actually be able to use these tools today, because ultimately these tools work off of context, an existing knowledge base, the ability to prompt really well, and so I've seen that the more educated someone is in this space, the better they're actually able to kind of guide these systems to a good outcome and then be able to very quickly understand, is the outcome actually accurate? So I think probably a roundabout way of answering your question, but it's an interesting time on this.
RD It is certainly. So somebody who is building APIs right now, what's the best things they can do to sort of prepare for it? I know you mentioned get your specs in order, hire a tech writer, but what else can they do?
SB I think invest in the great developer tooling of today. I think that still is the context for a lot of these systems. So things like great docs, great SDKs, great tests for your API, self service experiences are still really important. I think on the tooling side, I think keep an eye out on what I would call ‘tools’ that agents will start using. Tools are nothing but more bits of code that we want to provide to act as a bit of glue between the agent and the API. So having a kind of a light understanding of that ecosystem as it evolves, and then I would say to use the tools that are there today to try to access your APIs and integrate with them. I've often brought up ChatGPT or Claude or any of these products and just tried to actually paste in an API spec or your doc site and then see how it's able to interpret it. We can empirically actually learn, and I think any team, the more they use these products, the more enamored they will be. And the less they use them, the more skeptical they will be.
RD The more they see what it can actually do, the more they can understand how to use it.
SB Absolutely. Just on the API front, I think we are going to see disruption on both sides– I think on the API producer side and the consumer side. I think what we will see immediately, to be honest, is more on the consumer side, like how any developer out there kind of grabs an API and integrates the ability to deploy an agent, the ability to prompt your IDE to do the work, there's going to be some really interesting shifts there. On the producer side, I think things are a little bit more stable near-term, like people building APIs, especially public-facing APIs, you still need to employ the best practices of API building. I think for them, the focus is going to be more on if there is anything more they can provide. Are there agent toolkits that they can provide the open ecosystem? And so I would say, short term, API consumers get tons of tools, it's going to be noisy and messy, there's going to be no best practice around this, and then I think medium term we'll have to see what happens for the API producers, like is there a fundamental shift in the way they actually design and deploy APIs that hasn't shifted just yet?
[music plays]
RD All right. Well, we are at the end of the show. We're going to shout out somebody who came onto Stack Overflow, dropped a little knowledge and won a badge. Today, we're shouting out somebody who won a Lifeboat Badge– they came to a question that had a negative three score when they got there and they dropped an answer so good the score got 20 or more. So today we're shouting out Bergi for their answer on: “What is the Universal Module Definition (UMD)?” If you're curious, you share that with 664,000 people who came on and checked out this question. My name is Ryan Donovan. I edit the blog and host the podcast here at Stack Overflow. You can find the blog at stackoverflow.blog. If you liked what you heard, drop a rating and review. And if you want to reach out to us, podcast@stackoverflow.com.
SB My name is Sagar Batchu, co-founder of Speakeasy. You can find us at speakeasy.com, and you can find me on our community Slack space. I'm also on X @Sagar_Batchu, and also on LinkedIn too. So definitely reach out. Always happy to chat about AI and agents and APIs.
RD All right. Thank you very much, everyone, and we'll talk to you next time.
[outro music plays]