The Infra Pod - Navigating the Future of API Development with AI! Chat with Speakeasy CEO Sagar Batchu

Episode Date: December 30, 2024

In this episode of The Infra Pod, Tim and Ian sat down with with Sagar Batchu (CEO of Speakeasy) about APIs and software development. Sagar shares his journey in creating Speakeasy, challenges in API development, market trends, and his unique perspective on the future of QA in the context of rapidly advancing AI technology. A must-listen for anyone involved in the tech and developer tools / API space! 00:00 Introduction 00:16 Guest Introduction: Sagar Batchu 00:22 Founding Speakeasy 01:36 Insights and Catalyst for Building APIs 02:02 Challenges in API Development 03:57 Who Needs to Build an API? 07:09 Speakeasy's Unique API Product 12:11 Customer Journeys and Learnings 18:00 API Design Principles and Success 28:08 Spicy Future: QA's Resurgence 36:22 AI's Impact on APIs 38:33 Closure and Contacts

Welcome to the InferPod. This is Tim from Essence VC. Ian, let's go. This is Ian, lover of DevTools and all things cool that change the world. I can't be more excited today than to have Sagar, CEO of Speakeasy API on the pod. Sagar, tell us a little about yourself. We're excited to learn more.

Hey, guys. Thanks so much for having me on. I'm super excited to be here. Tim, I think we met like two years ago, two plus. I think I was like day zero of starting the company. I just met my co-founder and you basically gave us some advice like, hey, this thing you're pitching doesn't make sense. You need to go back to the drawing board on this. So I'm glad you told us that because hopefully we made some progress since then. Yeah, my name is Sagar Siokofana, Speakeasy. I've worked in enterprise software for a decade and worked on a lot of API platform things, let's call it that way. And that really led me to starting Speakeasy. What we're really trying to do is be this very polished and modern tool chain for API development.

I mean, look, REST APIs are not new, right? They've been around, what, 20, 30 years. But somehow shipping a great API is still relatively challenging for a lot of teams and companies. And that's like everything from building it, testing it, distributing it, deploying it. That whole lifecycle is still pretty fragmented. So it isn't a great kind of, I think, thought leader in the space as well.

So that's what we're trying to do. And we've taken somewhat of a narrow starting point in building out this pretty cool platform. Amazing. And what made you decide to start speaking to it? Was there a moment of insight? Was there something that said, this is the moment to go build a company that makes it simply easier to build API? Because it's not the first company to come around the door to try and make it easier for developers to build

apps that have an API or have some type of platform motion. So I'm really curious to learn, what was the motivation? What got you over the line? I ask that to every founder because I think it's one of the most interesting questions. Yeah, totally. It's funny, I actually think I started maybe somewhat the other way around where when I left my last company, Libram, I had had a set of experiences where I felt really strongly that I wanted to build in the developer space. I was very much of the opinion the way to have most impact, reach the most practitioners everywhere is to build a tool that's just fundamentally useful

to a lot of people. And then, of course, if it's useful, hopefully there's a way to monetize and build a real business around it. And what I had focused on for a good chunk of my time at LightRamp was really helping teams build a consistent API interface. It was a company operated at scale,

like petabytes of data processing a day, billions of requests from pixels on ad websites. And so we really had to put a lot of time and effort into figuring out what a consistent tool chain looked like for API development team to team. And then being able to expose those APIs to external users, have consistent docs, consistent integration experiences. And that was going from a few engineers working on that to trying to roll it out to 800 engineers at a company. That is a big adoption task. And I really felt like the open ecosystem could benefit from something like this. When I started looking around, I saw the open source generators and the open API ecosystem

that do code generation to build SDKs. And it was crazy to see how much uptake they had. You know, hundreds of companies, really big companies too, banks even, that use this open source tool chain. But it's so poorly maintained. There's like tons of issues. It's one of those scenarios where you see it and you're like, wow, this is a huge problem. But the execution on the solution is really poor. And you feel like you could do it better, right? And as an engineer, we're always like, I could build this better.

That was like the first moment where I felt, hey, that could be a company, yeah. What's the catalyst, I guess, for someone wanting to build an API, right? I want to, just for context, one of the companies I found was Manifold. It was a developer tools marketplace. And one of the things I learned through that process is the number of companies that actually have the opportunity to become a platform are actually quite small.

So I'm kind of curious how you think about who needs to build an API and why? And then another question, a second order question to that would be, how is the market for people who need to have APIs changing over time? Is there more people? Is it more important? Like the function of what you're trying to solve for people, how is that going to be more important in the future than it is today?

Yeah, good question. You're right. Not everything needs to be a platform. Even now, when I pitch Speakeasy, often I ask companies if they have PMF, because I think this problem is probably much better addressed once you have PMF, because launching an API doesn't necessarily get you PMF. It might be a way to accelerate it or get more signal on what you're doing,

but there's still a core business behind it you need to figure out. Going back to your question, it's not just public APIs for third-party consumption, but it can also be APIs for the internal consumption. Because companies get big. When you look at companies with over 500

developers, when you launch an API and you expose it internally, that user base gets to a size where it's pretty much similar to running a public API. You have a contract, you have users, you have onboarding problems, you have versioning issues. There's a need for change management and communicating how the API is evolving. At the core, to do all that, you need good design, right? You need good resource-oriented API design. And so I do think the problem is more than just public APIs.

And you're right, if it's just public APIs, it's not a big problem because there's not that many platform companies out there. In terms of Catalyst and what's happening more broadly, there's, I think, a couple of tailwinds here. I think when I look back 10 years ago, there was maybe what, like a few mainstream languages as devs we would think about. Now you have like seven or eight. I mean, PHP is back in fashion, like Ruby is coming back in fashion. There's suddenly like, you know, seven or eight mainstream languages, and then you have multiple run times in some of them and then even if you're not a platform company like you might still need to have your product be used in like different ecosystems right like let's say you're in for a company um you need your product to be used in hair form and plumi and now sst like there's all

these new ecosystems where devs are going to leverage your product. And so you're thinking about, like, how do I fan my product out into those multiple places of consumption? That is a strong driver for having APIs. So even if you're not exposing the API itself, you need the API and you need the interfaces so devs can leverage your product and those ecosystems. And then finally, I mean, in the last two years, of course, all the craziness with LLMs and agentic workflows, still very early.

But like one thing is clear that the usage is going to go up. We don't fully understand like the shape of it yet. I think it's still super early, but there's just going to be a lot more consumption from a multitude of different consumers, whether it's humans, agents, workflows, rag systems. There's just tons going on there. So I think there's a lot of tailwind around just more API consumption. And so I'm actually really interested to learn more

about Speakeasy as an API product. Because I think this API product space is actually quite fascinating. I can understand there's been API gateways, there's probably APIs for testing or the swagger type companies.

But I feel like what you're doing doesn't really fit any existing bucket. This is like this new gen of API management, I almost call it. And we'll be curious to talk about how did you get started in your speakeasy journey. Because I remember we're talking, after we chatted, the first product was really about type-safe SDK generation.

Which I think that was the initial pain point, was people need to have SDKs across different languages, and it's really hard to build that. So that's been the consistent starting point. But from that point on, like docs, testing, and even like Terraform providers, these are not things that I think I would even imagine what your natural product iterations will be like. So can you talk about what's missing in this API space?

Why gone after this way? Because you could probably gone after gateways. You can probably gone after maybe some other things. It seems like you're fitting either a newer need or something that the existing folks are not doing at all, right? Like what is the philosophy of picking these products in the first place? Yeah, I think that's a really interesting one too. This was like actually one of my biggest, if anything, like worries when starting the company was like, hey, there's been this Gen Zero type of company in this space. SmartBear, MuleSoft, APRE.

I think APRE was bought by MuleSoft. There's a number of companies there. Then the Gen 2 or Gen 1, you had people focusing on the collaboration problem, like Postman, probably the biggest winner there, really helping just companies collaborate on APIs. And then you had the gateways come up, dealing with the, you know, networking,

just helping the big enterprise feel like almost safe about their APIs, right? I think where we are now is when we started exploring this problem about two years ago, people would largely like, you know, bring up their IDEs and these discovery calls, right? And they would be like, hey, here's my API spec. Here's my docs.

Here's my SDK. None of it works perfectly together. They would really talk a lot about the workflow of maintaining a great API in a company being very challenging. It's like fine when you're a startup and you have, you know, it's you, you're one dev, you're doing everything end-to-end.

So the need for end-to-end type safety is satisfied by the fact that you're one dev doing the whole thing, right? But then as you grow, like if you're trying to maintain end-to-end type safety, that's a multi-person problem now, right? And so like, how are you going to communicate about what the types are for your company, how that's going to get exposed, how they're evolving? So you have at the core, like a workflow problem, which we found that none of the gateways, the postman, or even the older companies like really addressed, right?

The ecosystem did get this thing called, was called Swagger, not called OpenAPI. That was like kind of thrown in the mix, but it was weird thing because like, I think it is a fantastic description format format but it's not really like a design format right it's not something where you want to sit down and write a 10 000 line spec that just like is a really difficult thing to do in reality what we see is like companies build the back end side fast api or whatever and out gets spit out a spec and that spec becomes like this living document you need to patch it you need to like deal with all the edge cases think about how you know something like nullables

how does that get reflected in typescript versus python right and as you do that you end up patching together pretty big kind of scaffolding at work as the company grows that's really where like speakeasy fits in right it's this solving a workflow problem and i think our unique take has been starting with the code like if you can actually own the interface and make a great interface for customers we found that you really earn the right to win in other you earn the trust to do other problems because like shipping a great piece of code a really polished sdk is when they it, they have this like aha moment because they see this GitHub repo and it's really nice code,

really well documented. And they're like, oh my God, that's 50,000 lines of stuff I've ever had to write and then maintain and evolve. And you're like, you kind of try to get in this narrow spot that's really easy for a dev to understand. It's like 15 Jitter tickets you just checked off for them, right? That's the kind of magic moment for them. And so that's how SpeakEasy has organically grown.

We come in, we help you launch this really good interface, and then we start to help you with testing. We're now looking at docs. We realized that we kind of have access to events and webhooks, and that might be an interesting place to explore. So there's a whole set of things that comes kind of have access to events and webhooks, and that might be an interesting place to explore. So there's a whole set of things that comes out of actually just owning the interface for the types and the way it's exposed.

Very cool. And so what have you learned in this journey? When you talk about your customers, do they all start from the same place? We're like, okay, SDK generation is what I need. And we sort of adopt it in a very linear way. Because looking at our products, I probably assume this is going to be

a variety of ways people actually use our product. Right. You know, like some people probably will have existing docs. Some people probably don't care about telephone providers. Some people already probably have some infrastructure to do API testing. But I guess the gopher is able to like

do a comprehensive product. Right. And so is there a typical journey how folks start using your products? And do you see any trade-offs? When you have a product that can do multiple things, was there anything in particular that's powerful, but also maybe a little harder when it comes to people who start to use you? Yeah, totally. Big question.

Also, just on a personal note, when you have a product with multiple steps or areas like this, man, it's hard to build. You have multiple moving pieces. It's kind of a fun technical challenge too. But yeah, today it's as strong as where just people come in with an open API

spec and they're like, I need to get this thing launched or I have a Python SDK already live and it's really hard to maintain. I would offload it to you guys. We have some other like wedges that are developing and Infra, of course, Terraform is a big one. We partner on docs with a company called scalar.com,

really great group of folks that, you know, they do amazing docs and that brings us folks into kind of our funnel. So we'll see how it evolves, but that has been like a great starting point. I think what I've learned in this process is that a lot of the earlier attempts in this space, like people were very academic about it.

They were really focused on the spec. They were like, oh, you should have a great spec. You should like link to your spec and have spec governance and the APM management platforms, as you talked about, like that's what they're really focused on. And a lot of companies, they don't really care, right? Like, do you really care if your spec is perfect or do you care if your customers are having a really great experience?

And I think more often than not, it's the latter. And so I think we try to stay focused on that. Like all the stuff about open API and API specs are actually details that you are coming to speakeasy and speakeasy is kind of giving you best in class or expertise around, right? That's what's baked into the product. And so that's been my biggest learning is like, don't try to convince the user

or don't try to like excite the dev about like a great API spec. That doesn't actually matter. Yeah. That's interesting. Like one thing I want to ask you about, maybe it is about a great API spec. That doesn't actually matter. That's interesting. One thing I want to ask you about, it is about open API spec, because this spec has been around for quite some time now.

And I've talked to quite a few companies that are doing API-related. Some are just like, hey, this is outdated, let's go after and build a new one. You've probably seen some of them. I'm going to create a new Swagger, for example. I feel like at this point, Swagger is pretty much the defaults. But then not everybody really adopts Swagger across everyone.

It feels like maybe certain maturity companies, maybe they have some sort of standard they'd like to be adopted. But I actually haven't seen Swagger be used truly in everywhere. Not as prevalent like Docker, for example. Docker is truly everywhere. With Swagger, I feel like it's kind of like sometimes. So I wondered, do you have a take on OpenAPI as a whole? Any shortcomings you see?

Because I feel like it seems nice to have a standard spec, but then there's a reason I don't think everybody wants to even maintain that for some reason. Yeah, it's definitely at the heart of this ecosystem, this problem. I think that you're right, the end-all be-all for the REST ecosystem,

the REST API ecosystem is not OpenAPI, but I think at the moment, it has gone through a really good, I would say, renaissance period, and it's had a recovery. There's tons of great people contributing to the v4 spec that's just to come out soon.

They now support a workflows concept, and it's being picked up by, like, the now-growing AI ecosystem as, like, the way to, you know, not just APIs, but describe function calling, other, you know, there's potential to describe an agentic workflows in there. So its adoption has surprised me. Like, I think nine out of 10 companies we talked to have one,

and then the backend frameworks have also adopted it, right, as like an artifact of the build process. So whether using Fast or Nest or, you know, Fastify, pretty much any framework, they do spit them out as part of the build step. And so, like, companies will always almost have one,

whether or not they're giving it a lot of care and looking after it as a sacred document, that might not be the case, but they will almost always have one. Even at Speakeasy, we think a lot about where this is going to go, and we might even do our own. But right now, I think we really want to meet the ecosystem where it is, which is almost everyone has one. And with just a little bit of love,

you can get to a pretty great place as a company in terms of having a documented API, having good artifacts, having tests, having, you know, even now openly based webhooks as well. So you can even encode your webhooks and have type safety there. So I think the right thing, the kind of phasing, I think, for the ecosystem is get this to a pretty good place, and then you start to see new things come out when the OpenAPI document itself is well adopted. A good example is

Microsoft has released this thing called TypeSpec. It looks a lot like Proto, honestly, and I think it's great in terms of the guardrails it's providing, but even TypeSpec ensures that it outputs OpenAPI as part of the workflow. And I think that's clearly a realization that everyone's had is you still need this exhaustive descriptive document somewhere in the process. One of the things I've noticed a lot about APIs and a company that was adding products quickly and also trying to have a platform motion. And there is always this tension,

and I've seen this in many other companies, this tension, like how do you develop the data model, right? Like at the end of the day, like whether it's a REST API, a protobuf API, you know, some event stream or whatever, you know, a dump of a CSV, this collection of CSV files, or, you know or whatever it is that your actual API is.

There's the model of, how do I access the data? And then there's the, how do I actually get the definition to then put it into OpenAPI or put it in whatever one of these things? I'm really curious to get your perspective, both on how you've seen companies properly navigate the development and maintenance of that definition, and how you deal with the tension between the public versus the internal. Because I think in a meta layer, it's great. All these tools are really important. They help us get those things done faster and help us maintain those things. But finally, still at some level of the organization, you basically end up with,

we have to decide whether it's an internal or external, what our data model is. And so I assume this is probably a problem you see all the time, because people come to you and say, hey, we really want to become a platform, or we want to become API first, or we want to have a story around

how you can extend us in order to accelerate various different aspects of our business, whether you're going to enterprise or consumer or whatever you're doing. So I'm curious, what have you seen work? What have you seen not work? And how does that fit into your view of the future? Yeah, great question.

Do you want to somewhat, I guess not spicy, but lo-fi take on this is often when we talk to customers and they come and they have this mess they're navigating, the first thing I ask them, do you just have a github repository a public github repository with your spec in it and let's just start there right like you need this you need this document to live somewhere where everyone can contribute and have like change classic version control and change management on like that's just literally that's the most lo-fi solution if you start there, then you're able to at least have a conversation and collaboration on it, which is important. Because then you have this, to your question,

what is the data model for the company? You would just have this document. Sure, it's not perfect, but at least you have a place to start collaborating and have version control on. You're right, though, there's a lot of in-hand tension in this because internal teams just want to write code and go from there, whereas external teams are very focused on the design, how this thing's going to get exposed, how it's going to be evolved. So there's a lot of tension there.

I think the best thing I've seen companies do is internally often come up with some basic principles around API design. What design do they want their APIs to follow? People often code that as linting rules or just simple tooling to ensure that as devs develop, there's some guardrails. And then I think at that point, you just have the basic scaffolding you need to let your company move as quickly as it can. So that's what we've seen work pretty well. I think as this ecosystem evolves and things like TypeSpec become more popular, I could see

teams actually going back to like a design first, you know, methodology like people doing proto, but it really comes down to like how this space evolves over the next few years. And how often, you know, I think there's like multiple aspects of like technical culture that results in your ability to actually be successful here. And one of those is, in my experience, you need a pretty well-developed

like internal technical culture of terms of like, how do you drive decision-making? Like has to be defined, right? Like at the end of the day, it's like, cool, we can put all this stuff in a repository, but we haven't figured out how a decision gets made.

It doesn't actually matter to the repo. I guess that's step one. And step two is, many people, you don't start building wanting to become a platform. You start, I'm going to be a tool. I'm going to build the best CRM for this very specific use case. And so then you get to the point where you found some success and people are using it. And now you have this, but you want to become an API. So I'm curious, are there patterns you've some success and people are using it. And now you have this, but you want to become an API. So I'm curious, are there patterns you've seen that make people more successful in becoming API first over time? Especially when they start from a place where,

hey, we were just trying to make the best sales AI agent, and now it turns out we actually have data and people want to integrate with us. How do you help people navigate it? What suggestions do you have for people to navigate that mess? Because I think at the meta problem here, for most, isn't whether or not they want to be API for us, they want to become a platformer, they want to have some

type of integration story. It's how do I get there? And then how do I manage the tension between product velocity and development? And then also having a great API that people can integrate against. Yeah, totally. That's such an insightful comment. I think the single biggest problem I've seen companies make is

the classic example you gave, like the CRM, they want to be an API now. They try to take all the data models, all the functionality, and expose it in the API. I think that is a mistake because all that stuff you've built this great business on was never optimized for external consumption. Instead, I think you need to really just pick the one or two resources you want to expose. And it's funny as I say this, I'm like, Hmm, maybe that's not great for speakeasy.

But you start with the smallest API that you can expose and then grow from there, right? Like you just start with that one resource, simplest transactional and CRUD API. It's almost like you're finding PMF again, right? You want to go back to users and start fresh and start with that one workflow that is super important to them and then grow that over time. Instead, I see a lot of companies will have 12 specs, one for each service team. We'll try to merge them and create an Uber SDK that everyone can use.

And it's really challenging for the end customer. That's what we try to guide and help. Our product does give you the ability to kind of massage the code generation so that you can create a simplified interface. But you're right. It's still a technical decision the company needs to make. And in terms of API success, I think there's like a common conversation a lot of companies i see this especially for company you know there's developer first companies those tend

to have you know apis are so important to their go-to-market motion and the ergonomics of the api is so critical that like the business as a whole just recognize that like actually our product is basically the api and thus actually your product is actually the sdk and the docs associated with it and that's the thing you spend a lot of time whereas there's lots of companies in the world basically the API and thus actually your product is actually the SDK and the docs associated with it. And that's the thing you spend a lot of time, whereas there's lots of companies in the world where actually the product is like this, like Salesforce being a great example.

And I spent some time there, like the product is actually that clunky user interface and the S object metadata model. That is the product, right? Like, and the APIs are the second order effect. And there's always this tension between,

you know, both the business in terms of really wanting, we want to say we have an API, we want to enable this integration stuff. But I've often seen my experience that results in this tension between the ergonomics of the API they produce

is always secondary because I'm still choosing velocity in some other area. And I'm kind of curious, in your experience of working with companies and building yourself, what are the do's and don'ts here? What things must be true for an API to have any success?

Are there principles that you've identified or things in your product that you help people work through or things that in the future you'd want to build into a product to help people navigate this? These are the things I've noticed when people come to me and say, I want to go build a platform. And I sit back and I'm like, you have none of the internal things required to make this successful because actually all of the incentive for new AR,

revenue expansion, is going to pull you away from the things that actually will make you a successful API or a successful platform integration play. Yeah, no, it's a great point. I think there's a lot of metrics that people talk about in this space and no one's come to consensus i think but i

think there's like two angles to this that are interesting to me the first one what is success how do you measure success you can look at a lot of metrics if i had to take like say one for people to take away it would be just like time to 200 right time to your first successful call like that is probably the biggest like determinant of whether you have happy users. No one wants to make the call and see a failure, right? They just want to get the 200 getter sponsor back. That just makes people feel good because it's like, hey, I hit this API.

It's doing some work for me. That's great. I got something out of it. I think the second one is when companies do these API launches, I think it is actually important for them to think about what kind of user base they're building for. You're right. If the API is the product and there's millions of end users, you really need to think deeply about the ergonomics. You need to think about even the ability to how the SDK or the APIs can expose features. Are you going, easily be able to type to your IDE and, like, discover the next feature

without looking at the docs? Like, those kind of minutiae is really important. But if you're doing, like, a partnership play and it's the API is integrated once by a big partner and then done, I'm not saying you should ignore

the ergonomics, but the needs might actually be different, right? It might be more about, like, performance or stability of the API. So I think categorizing that is really important. We've seen that affect our own product. For example, in TypeScript, we have a TypeScript SDK. When generated, it exposes a class-based interface

as well as a functional interface. And the class-based interface has phenomenal ergonomics so you can get down to the level of the exact method signature, the names that you want to expose, and that's pretty important for some people. But the functional interface gives you a lot less control on naming, but it exposes just a function that means that the rest of the SDK can be tree-shaken away by a modern burner.

And so partners care a lot more about that because it's performant, could be integrated in the browser and be super fast. And so I think the usage pattern of the end API matters. I've seen companies kind of misstep here, right? They might just be actually launching to like 10 partners. And the truth is those 10 partners are going to integrate once. And if it's successful, they will be locked in. So the focus there is probably not the same as having millions of end users. Cool. Well, we want to get into the spicy future section here. Spicy futures.

As you mentioned, Sagar, what is your spicy hot take around infra? Probably API-related, I assume, but it doesn't have to be. Give us your spicy hot take here. Yeah, spicy hot take. I think that QA is going to become cool again. I think being a QA engineer or a QA person

or QA anything, that industry which feels like got relegated to second tier is going to be super fun again. And I think it's because you have a ton more code headed your way, like a combo of AI, a combo of CodeGen, a combo of every product I open up these days is just like a massive code on the screen, right? Because everyone's trying to ship you code in some way.

And I think that QA is going to be super hot again. I think you're going to see an explosion of companies, companies spending more time testing than developing because you have more and more products that try to do the work for you. You need to understand correctness and accuracy

as opposed to actually figuring out how to do integration or how to do the job. So that's my hot take. I know no one thinks QA is cool, but QA engineers, I would stick it out. It's going to be fun again.

That is not the spicy take I expected, but it's certainly spicy. But what is it that makes you believe that we're going to have the return of the QA engineer? I have a hypothesis of what the underlying thought process is, but I'm really curious to learn from you. What are you observing that results? Is it the fact LLMs are probability distributions? Like what is driving some of these thought processes? Yeah, yeah, exactly.

LLMs are probability distributions. I think that there's a fundamentally higher rate of code generation happening, right? Not just products like Speakeasy, but also to the LLM world, like you have things like v0, right? Shutting out code. You have a ton more just points of integration happening.

And so I think that in itself is enough tailwinds for people to start worrying about whether all the things that they're doing are accurate. I also think like another way to model the whole, which I'm sure you guys have heard of, like to model the whole LM explosion is getting a lot of junior contributors at a company. And so if you're going to have a lot more junior contributors,

you need to have a lot more guardrails. And so that's like the kind of meta way that I've been thinking about it. But curious to hear what, you know, Ian, what your take is here. I mean, I think my take on this is, I think we're entering a phase where, for a long time, development focused broadly on building deterministic systems. Yeah.

Right? Like, we had a spec we could test against. We could write a unit test that tests that thing. And we could write, like, a series of integration tests to test them as a unit. And we could basically come back and say, we thought we lived in a world where software could be true-false in terms of its, like, does it work? And now we're actually in a world that's more like data science, where it's a distribution of probabilities of whether the software is working or not. And I think that's just a

fundamental shift in thought process and model. And I think broadly, at the end of the day, all developers are going to be simply more thoughtful from a data science perspective and statistical perspective than they ever have been before. It means that the functional definition of what does working

mean is changing. We've seen some companies like Braintrust that are out there doing it, but I think developers broadly are just not ready for this shift. I don't think the traditional methodologies from the last 10 years are going to be the same methodology we have moving forward. And I think the idea of bringing a QA engineer back,

it's intriguing. I don't know if I agree with it, but it's intriguing. I mean, Tim, I'm super interested to hear what you have to think as well on this matter. I mean, actually, this is related to a question I want to ask you because AI is making code generation so much easier. But obviously, I think it's almost like

the distribution statistically are still not that high. That's why everybody is half disappointed or interested by Cursor. If you're doing serious work, you can't really get there. Simple work, you can't. You hear this quite often.

And you mentioned this QA stuff. I was back in my mind, people that are doing new QA companies are using AI as well. So we're adding more AI everywhere, basically. There's AI for code generation and there's AI for QA. And that doesn't make QA much more easier. If you cannot even generate code much more simply,

how do you do QA much more easier with AI? Because you need to trust QA more. Maybe I can throw spaghetti on the wall, whatever. But QA is the point where you're like, okay, this actually works. Your point, if the coders, there's so many. But if it's just all AI, at this point, nothing can be no AI.

If it's just manual QA labelers in some places, we're not going to get far. So there has to be AI in the box. But I wonder if you have a take on QA. There's a different kind of QA that should happen. Because AI is going to be here, the box, but I'm also I wonder if you have a take on QA there's a different kind of QA that should happen, because AI is going to be here

but it can't just be AI only and I feel like we haven't really even seen a really good QA company that has able to scale to some degree, and there's probably some reasons why Yeah, maybe it's not a good company and honestly, I love using the word

QA because I think that's the spiciest way to say it, honestly. But like, I don't know if the responsibilities and toolkit will be the same. But I do think the way the analogy to me is in the last kind of, I guess, Cambian explosion in software, right? Like the big thing that happened was you just had a lot more exposed APIs,

integrations, different services. And so you've got security became a big thing. Like you had security, security ops, the CISO became a really important person at the company. I think analogously, you're probably going to have something similar here, right? Where there's a ton of AI adoption at companies, but like who is managing,

whether all the stuff is working accurately, who's hedging downside for the company, right? The CISO is not doing it. I think it's going to be a new role. And I don't think it's the engineering, like head of AI or engineering team or whatever, because I think the incentives are wrong for them, right? I think you end up having someone

who's more of a compliance or regulatory role that is like hedging downside for the business, especially on like not just the co code gen and the AI side, but also the data access and that side as well. So that's why I think QA is going to come back, maybe in a new leap on, a new form, as this chief QA officer. I don't know.

Someone who has that role in the business. I think it's a really interesting insight because we kind of already have that role in some way from a compliance perspective when you're dealing with data. In the sense that if you're a modern financial institution, a fintech even, and you're doing some automated loan approval, well, actually there's a huge amount of liability on the company to ensure that that loan approval process doesn't have any bias in it. And so there's already a large

compliance function around how that model or that component of the company would work in the first place. And broadly, I think what I'm hearing you say, and I tend to agree with it, is if more of software goes from this deterministic rules-based thing, which is highly audible, and audible from the fact that I'm a software engineer, I can fully understand the problem space, and I can write a series of tests or rules about, or use ai to even generate those tests rules but i can still audit what it is to a world of it's probably correct in the sense that like i can test the distribution but i can't exhaustively test the distribution i can kind of establish points along the distribution of probabilities that you're now going to have to have someone on the other side that says well what is good enough for us to like have confidence what we're putting out there in in the world is going to create a bunch of liability for the business from a legal or product perspective? So it's interesting to think of it

from the perspective of product quality, user experience, and legal liability potentially emerging into a new role. Because it's really all of the same thing at the end of the day coming to one place. It's like, how do we measure whether the software we're creating is performing in accordance with what the day, coming to one place. It's like, how do we measure whether the software we're creating is performing in accordance with what the business is required to do?

It's a really insightful thought process. Yeah, there's just more risk to be managed, right? And whenever there's more risk to be managed, I think you often get someone thrown at that problem. How do you think the function of AI changes the spread of APIs in the world and what the shape of those APIs do and look like in our Spicy Future section? What do you think? There's a lot of companies out there that are basically doing function calling,

which largely at the end of the day is having an LLM call some APIs. I'm curious to understand what you think about this. Yeah, it's a really interesting one. I will preface it by saying I think it is truly like on the timeline, it's not even day one. It's day zero on this. Like everything you see up there is there's such a big and big chasm between POC and like enterprise adoption.

So I think like how this settles out is still pretty, at least relatively speaking, far on the timescale. I think some interesting things I've noticed is that you're right. A lot of these tools are just like making API calls under the hood. That standard API calls, like I don't think there's anything special about them. I do think that there's like more of these API calls happening. And so I've seen some interesting discussions around how is authentication going to change

in this world, right? Does OAuth make sense for an agentic workflow? OAuth makes sense for a user and you're going to go pull up a website and fetch a token and then stick that token in your SDK or API setup, right? Environment variables.

But what about if you're an agent? Do you want it to open a browser and navigate and like fetch the thing and come back? Like there seems to be like some inefficiencies that are going to emerge from having the actual consumers

of the API, which I think is what's changed the most, right? It's the consumption side. It's not the producer side necessarily. So I think the inefficiencies are going to result in like new patterns, new protocols. Auth is just an example.

I think we've seen that with like streaming, right? SSE, server-sent events just became so popular, but actually it's not even something you can write on an API spec. There's actually no standard

way of writing it. So I think you'll see more of that kind of thing. Just changing the way that we figure out, we enable consumers to have fast, reliable, safe integrations. Awesome.

Well, where can folks find you? Want to learn more about your super mastermind thoughts and also want to learn more about SpeakEasy, APIs, like tell us some of the socials and stuff where you can find you. Yeah, totally. So our website

is, we finally got the.com. Super excited about that. So the speakeasy.com finally. On Twitter, I'm Sagar underscore Bachu. Yeah, come hang out. We have a great Slack channel as well, Slack community. And we have an

office here in SF and we have got an office in London so if you're in either of the two definitely hit us up amazing thank you so much this has been

so informative and I can't wait to have you back to talk more about everything we just talked about likewise and I hope we catch a basketball

game soon that'd be great. you you you