Subscribe
Share
Share
Embed
Interviews with developers and API technology leaders.
Hosted by Sagar Batchu, CEO of Speakeasy.
speakeasy.com
[00:00:00] Tom Hacohen: 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.\n\n[00:00:14] Sagar Batchu: Welcome to another episode of Request Response. Today we speak with Tom Hacker, him founder, and CEO of Swix, a Webworks as a service platform. Tom has a unique journey as a developer who felt the pain of servicing Webworks for his own product and decided to make it a business. I enjoyed his view on how to make MCP servers more useful by creating a meta MCP server for all your APIs so AI can better discover and plan for making tool calls and taking action.\n\n[00:00:39] The best type of API design for AI will be well scoped endpoints that answer complete questions instead of traditional brittle crowd endpoints that we have today. Enjoy this episode with Tom Hackerman. Hey everyone. Welcome to Request Response. I'm your host Saga, CEO, and co-founder of Speakeasy. Uh, we are the modern tool chain to build, test, and distribute your APIs.\n\n[00:00:59] I'm joined today by Tom Hacken, founder and CEO of Swix. Tom, it's uh, it's great to have you here today. How's it going all there in New York? Yeah, it's great. Thank you for having me. I'm looking forward to it. So, Tom, I've been, uh, a like, um, you know, long time fan and observer of your, of your business. I love what you guys do.\n\n[00:01:18] I love what you built. Um, kind of take us through your journey. How did you end up working, um, and building swix? \n\n[00:01:26] Tom Hacohen: Yeah. So first of all, thank you so much. I appreciate the kind words. Yeah. So how slick started it was, to be honest, mostly luck. I was working on my, on a previous company, uh, actually still running on the side and, you know, making me money, but whatever.\n\n[00:01:38] But it, it's, it is, it's something I was working on and like people kept on asking us for web hooks. I. You know, I, we started looking into it and we kind like, okay, you know, what, what are we gonna do if we're gonna build this for you? And we just realized it's gonna take us a lot of time and effort to build it.\n\n[00:01:50] So we just said no. And then people kept on asking us still, and we just kinda like, you know what, we're gonna find the time to build it. Um, but then, you know, what about maintenance? And we realized it's gonna be like a lot of maintenance costs. And, you know, all of our, the core product was our request response.\n\n[00:02:04] Well, this added like this whole asynchronous. You know, like, uh, just a whole set of challenges. So we said no again. We're just like, we don't have the time to build this. People kept on asking us still, and we, you know, we, we, we figured out we could find the time to build it. We are gonna figure out the maintenance, but then we realized we have this like beautiful API, great product.\n\n[00:02:22] We're not gonna have a shitty web experience, right? So kinda like multiple, like the first two estimates by like two x, three x and we're just like, you know what? This is just not meant to be, we're not gonna do it. And I wish I was smart enough at that point to realize that there was a business there.\n\n[00:02:36] And, but it was actually a few months later that someone asked a silly question about webhooks in a Slack community I'm a member of. And I started like explaining to her, you need to x, you need to do Y because we did all the work for the, for the previous company. And I realized she couldn't care less about anything I was saying.\n\n[00:02:50] Um, so all she wanted to do is just to send web hooks and I have to think about it. I'm just like, you know what? If I build your product, will you pay me? She's just like, hell yeah. By the way, she never did. But other people chimed in on the thread Yeah. And said yes as well, and, and they became our first customers and it just, yeah, it just happened honestly.\n\n[00:03:08] Sagar Batchu: It's, I think it's such a funny thing to relate to you on that when, as developers we get very passionate about these technical problems we're solving and we're doing, and then you go to a user and you explain it to them and you realize they're not, they're excited because, not of the technical problems, but because you're about to get rid of a bunch of, I.\n\n[00:03:25] Geo tickets that they need to do. You know? And, and like, that's why people are actually excited. And I, I, I, I love that story you brought up because it reminds me ultimately, like for the people we build products for, would making their lives easier and hopefully getting rid of some pain that they otherwise have to go through.\n\n[00:03:42] Um, no, that's, it's such a cool origin story. I mean, it's. Um, nothing quite builds a business like feeling the pain yourself. Right. And I think that's exactly what happened to you. So at speakeasy we work on APIs, right? We work on kind of the very much another side of the same coin. And, um, I think what's really cool about the space that we're working in is.\n\n[00:04:04] Like you said, it's, it's a part of your product that you ship and you really want to ship something high quality. Like it kind of reflects the rest of the business and product. It, it feels like you've really embodied that at Swix. Like you want to give people the best, best in class webworks experience that they could possibly have.\n\n[00:04:21] Um, how has that played out in the product and what \n\n[00:04:24] Tom Hacohen: you're focused on? Yeah, so I think one thing that is very relevant, I guess for you is that. We launched a lot of SDKs Day one of the company, uh, you guys, I don't think you were around back then, or at least I wasn't aware of you all. Um, or maybe you didn't just sup support all the languages that you support now, but we spent a lot of time building all of the SDKs for like Python and Java and um, and JavaScript.\n\n[00:04:45] I don't remember what, what we started with. Now we have like way more. Uh, and I think that's a key part of it. It's kind of like meeting people where they want to be. I guess to give you like a more general answer to what I just asked, like the developer experience really matters because. It's, it's what you said a moment ago.\n\n[00:05:01] They don't care about webhooks. Like they're literally, 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. That's what they care about. It's just like the SDKs are just an implementation detail.\n\n[00:05:16] The webhooks are just an implementation detail. Um, so I think that is. That is the key thing. \n\n[00:05:21] Sagar Batchu: No, totally. And, and before Swix, how were customers solving this problem? Um, it sounds like that that one interaction you described in Slack, if someone was hand rolling this themselves, but were there, were there other automated ways?\n\n[00:05:34] Was there, like, in my mind, SWIX has always been one of the first, if not the first company, that kind of has offered this off the shelf. \n\n[00:05:42] Tom Hacohen: Yeah. So we're definitely the first company like. The current era. I think, you know, there are like some companies, like I think Fan Out had like a, like a webhook product to some point, but it didn't last for long.\n\n[00:05:55] Um, so I think like we really started it. Um, and before, I mean to put it differently, like we never switched from like a, a different vendor to us, right? We were always the first always switched like our home build. Um, and yeah, and people just used to build it themselves. So just like do a lot of research relearn the same problems that we've relearnt along the way.\n\n[00:06:14] Um. Make mistakes by the way. And you know, as you know, APIs, you know, change, fixing mistakes is like a very painful process. So you just, you're stuck with the mistakes and just have like a subpar experience. Um, yeah. So I think mostly that, and we, we've been lucky to. To both. Like have customers that come to us with a new build as in like we're just adding web hooks, but also people that build it themselves.\n\n[00:06:37] And just, even though you kinda like what I walked you through earlier, like my process, which is like the build, maintain, and quality. They may have done the build already, but they're now stuck at maintaining and improving the build. Or they're just really lacking on quality that their customers is complaining about it and they're saying, you know, it's time to level up and that's when they come to us.\n\n[00:06:55] Sagar Batchu: That makes sense. I if you had to. Like we go through a lot of the similar build versus buy and interactions with our customers. If you have to give your customers who ask build versus buy, like why they should go with with buy I. Has there been like a theme or one thing that you say to them as to why you, why they should use Swix?\n\n[00:07:15] Tom Hacohen: I am a developer. Absolutes, like I think we're developers, we can build everything, right? Uh, how do I know, like our company was built by developers. Your company was built by developers. Stripe was built by developers. Everything was built by developers. So obviously they, you can build everything. The question is like.\n\n[00:07:31] A, is it worth the time and effort? Um, B like, is it worth the relearning? Like, right, because like it's, it's not coding it out if you know what to do, like coding it out doesn't take a lot of time. And the problem is kind of like learning all the mistakes, you know, like making a mistake in your SDKs and like being screwed over over there, but like, or figuring out how to deploy to.\n\n[00:07:50] You know, the Maven repositories or whatever. Oh my God. Not rocket science, but you have to learn it. Yeah. And now they, you know, they, they've made some changes recently as well, so that's, that's another kind of hell that you have to worry about on an ongoing basis. So I, I, I think it's really just about that.\n\n[00:08:06] Like, you have to, you have to decide how to allocate your time, and you have to decide like, what is the bar quality? Because web hooks you can build, or SDKs for the matter, like you can build. V one in an hour, right? So in a can in a day or in a week. The question is, is this what you gonna put in the hands of your customers and are you willing to deal with the all day?\n\n[00:08:27] Hell that will see you like as. As it as it hits production, like as you get like real customer usage and all of a sudden still things start breaking. Or again, people use your S-D-K-S-D-K incorrectly, et cetera. Um, so those kinda like the things. So \n\n[00:08:41] Sagar Batchu: no, absolutely. That, uh, that idea of like V one is quite interesting to me.\n\n[00:08:45] I sometimes, I, I find that I'm more excited to talk when it comes to actually like purchasing the product, more excited to talk to the managers. Because often when I, I ask the managers is like, what's your plan when this developer leaves your team? Right? And he or she or them is the only person who's actually built to be one of this thing.\n\n[00:09:03] And they, they, they have all the context and knowledge like, who's gonna build V two? Right? And who's gonna, and, and you're going to be like, you leadership is going to be saying, Hey, this customer can't launch till V two of the SDK is live. Or the Java SDK is ready to go. Right? And so, like giving your business.\n\n[00:09:20] Uh, really that confidence that you'll be able to continue to move and iterate at the same speed is, I think, very undervalued. As you said, as developers, our, our hubris is that we know we can build everything. So we're like, oh, VZO, super easy, two weeks, one week, two days. But then what about V two V three?\n\n[00:09:37] What about scale? What about changes to the ecosystem? Yeah, no, I, I completely agree \n\n[00:09:41] Tom Hacohen: with that. You actually, you brought a really good point that I'm probably gonna steal this talking track, which is like, what happens when the person who built V one and actually knows what to do. Leaves and that, that's a great, um, that's a great point.\n\n[00:09:53] And I think another thing as well, is that, correct me if I'm wrong, I don't think people, whoever built V one of their Java, [00:10:00] SDK, is not gonna be maintaining it daily for the next year. Right. So like, even if they don't leave, they end up forgetting or maybe they're gonna move to a different team and it's gonna be starting with scratch every time, right?\n\n[00:10:10] Or \n\n[00:10:10] Sagar Batchu: totally, uh, building V one is fun. Building V two for the same person is never fun. And I think V two can become V one for someone else when they join the team, right? Like it's, yeah. This is as much of a people problem as it is a tech problem, by the way. \n\n[00:10:25] Tom Hacohen: And it's not theoretical. We see it time and time again with companies that they come to us when it's time to build webhooks version four.\n\n[00:10:32] Uh, because like they already did version one, version two version, like complete rewrites. And then they, they get to version four and they're like, you know what? We've had enough. Let's just outsource it. \n\n[00:10:41] Sagar Batchu: And why are they rewriting? Is it a scale problem or the products just change or that they don't have people like Yeah.\n\n[00:10:46] I'm curious what, what causes them to go through those multiple cycles. \n\n[00:10:49] Tom Hacohen: Yeah, so I'll give you like the, the, the two variants of this answer, right? Like I'm first one is kind of like you hitting scale issues or. You wanna implement some functionality that is just impossible or very hard with the current infrastructure.\n\n[00:11:03] Um, the second part is I'm sure like as, as you both, we both know, like engineers just love rewriting things. So like, I'm sure it's just like, if it's not the same person, the second person just like, oh, this is terrible. I, I can do a much better job at, they just rewrite it from scratch. So I think that plays in as well.\n\n[00:11:16] Um, so like what you said, people don't wanna maintain, they wanna just write V zero \n\n[00:11:20] Sagar Batchu: V. That's super interesting. We see, we see a lot of that as well. And um, I think we have kind of a unique. Problem on our hands of when an SDK goes through iterations. It's also often a breaking change to the whole user.\n\n[00:11:33] Basic. It's very hard to, even if you're handwriting it, there's always these edges that you don't account for that cause breaking changes in the interface itself. And so it's a very, it's almost like a very brittle. Uh, piece of the product right? Once V one goes out there, V two now has a much smaller, more higher set of constraints.\n\n[00:11:52] V three has a even higher set of constraints, and so over time you actually lose velocity, lose the ability to innovate if you don't think about this stuff upfront. Um, yeah, I mean, um, just, um, as we talk about all that, I think something I've, I've been thinking about is like how the buyers we interact, um, how are you seeing them change the kind of perception of build versus buy now that they have all these powerful AI tools at the fingertips.\n\n[00:12:18] Like is it changing for you? Are you finding. Selling is getting harder, easier, or is it just different? Um, yeah. I'm just kind of curious how your customers are reacting to the fact that they have even more superpowers now. \n\n[00:12:32] Tom Hacohen: I, I don't think we've seen like a significant change because I, I, I think like what I.\n\n[00:12:36] What I mentioned earlier as well, which is, it's actually the, it, it's kind of okay. It's like a completely unrelated anecdote, but like, you know, it's kinda like I, I heard from like a lawyer friends once, so maybe I read it online, which is like, why are you paying a lawyer a thousand bucks an hour? Right?\n\n[00:12:49] You're not paying them for the hour, you're paying them for the 20 years of learning that they've done before. Um, so I think here as well, like, yeah, maybe you can get an AI to, to build something for you. By the way, I'm not entirely sure you can. Um. What you're missing is like all the learning, and I think it's like similar to, you know, open source software as well, right?\n\n[00:13:07] I mean, like you can get an AI to rewrite an open source piece of software or you can just use the open source component as well. But like people still buy software. They don't always use the open source component. So I think there's just like much more to, especially for a large company, much more for procurement in procurement than, than just like getting a piece of code to run.\n\n[00:13:25] Um. You know, there's like observability, there's like a million things. \n\n[00:13:28] Sagar Batchu: Totally. And there's like, I think you, you hit on important, but like domain expertise, right? You wanna know you're working with some of the best people to understand this problem. \n\n[00:13:37] Tom Hacohen: Correct. And, and, and I think you probably do it as well, which is like, you know, with our larger customers, we very much handhold them.\n\n[00:13:43] Not because they're not competent, but because they wanna learn exactly what we see and what we do and what other comp companies do in order to do the best version, um, of webhooks, \n\n[00:13:52] Sagar Batchu: um, that they can. Totally. Yeah. I think, um, that's ano it's been another big learning for me building a business is as a developer, you, you often feel like, Hey, let's just build the best, nicest PLG self-serve experience, but nothing is a replacement for giving your customers your time.\n\n[00:14:10] Um, and I think as some devs often look at that and, and immediately react as like, oh, solutions or custom work is like not the way to go. But I actually have maybe a. L you know, controversial or spicy take, which is that I think especially for a startup, doing solutions is amazing because you get like, plugged in with your customer as long as you know, you're not breaking your product up in weird ways.\n\n[00:14:34] Um, I think you get so plugged in with your customer that you give them the expertise, you get all this great insight, you understand like how the company is set up, which, and, and a lot of companies are set up similarly, so. The, the, the kind of learnings really translate. So that's been another big takeaway for me is like, don't, as you said, don't steer away from solutions.\n\n[00:14:53] Um, or just spending time with them to, to kind of help them along the process. And they want that as well. Right? It's not justly for us. \n\n[00:15:01] Tom Hacohen: Yeah. \n\n[00:15:02] Sagar Batchu: Yeah. Especially now with ai, I would say like getting time with a real person becomes even more novel. I, I feel like it's, it's gonna become like in five years. You know, getting time with a, uh, solutions engineer is going to be like the top tier in a pricing tier.\n\n[00:15:16] Right. And all the other tiers are gonna be agents. The top tier is gonna say like, real human interaction. You know? \n\n[00:15:24] Tom Hacohen: I do, you know, like one thing that's very much related that I always tell the team and our customers is that we aim for our customers to feel as if we're like a staff engineer on their team that happened to build a web hook system.\n\n[00:15:36] So, so it's kinda like related to what you just said, like I think the. The ability to ask questions when things go wrong or like when things are unclear is actually a key part of just like a great developer experience and like building stuff in a nice way, because like otherwise, it's kinda like we talked about build versus buy.\n\n[00:15:53] When I'm building, I have that staff engineer sitting next to me, so like when I'm buying, I wanna have a similar experience as well. Um, \n\n[00:16:01] Sagar Batchu: totally. Yeah. Like being an extension of someone's engineering team I think is a great value proposition for a business. Yeah. Um, transitioning a little bit to more APIs and, and, uh, the more technical side shift of what's happening with ai, like, what's your kind of top level view of how, you know, APIs and air AI are interacting?\n\n[00:16:20] I mean, we have like, obviously tool calling is huge. Now. MCP is a big thing. We're doing a lot there. What's, what's your kind of top level view on all of this? \n\n[00:16:29] Tom Hacohen: I think the way, the way I think about ai, and this is maybe a bit of a cop out, is everything is different, but everything is exactly the same. Um, so tool calling, very different, right?\n\n[00:16:39] All of a sudden like this LLM calling a string and you pass the string and like whatever, it's like very weird. Um, but at the end of the day, it's just like an API call with just like a slightly different format. Um, so I think when you think about AI and APIs in general. Like when I'm trying to think like what is not gonna change?\n\n[00:16:55] Firewalls are not gonna change. Routers are not gonna change. T-C-P-I-P is gonna stay load balances, gateways, probably Jason, maybe Jason is gonna change. I don't know. HTP, A lot of velocity there. I think it's gonna be a lot of work to change. That's like, I think a lot of the stuff that we know. Are gonna remain exactly the same.\n\n[00:17:11] And, and you can see even MCP, right? That's HT TP, right? And, and a lot of JSON. And because we have the tools, we have the knowledge, we have all of those kind of things. Um, so I think a lot, as I said, I think a lot is not gonna change, but some things are changing. As you mentioned, like tool calling I think is gonna be extremely interesting.\n\n[00:17:30] Um, I mean it's already is, but it's gonna be even more. Um, and I think related to that, I think APIs are gonna become like. More larger and abstract. Um, so I'm gonna use, you know, like the flights example because that's every MCP demo. Yeah. But, um, you, you know, it's kinda like at the moment to do like an integration, you're gonna like make an API call list flights and second API call get flight information, get then another API called, get quote and all of that.\n\n[00:17:59] And you can like build a workflow around it. I think we're gonna see APIs that look more like, Hey, book me a flight. And then it comes back in like 10 minutes and then like, books your flight or like, gives you options. So like the, so the integrate, the way that people integrate is gonna maybe be more high level rather than just like what we have now.\n\n[00:18:16] That is like a lot of the es on the integrator. \n\n[00:18:19] Sagar Batchu: Totally. Yeah. Like I have another example I think mirrors what you said in, in our company. So we've been building and generating MCP services like an addition to our product offering and the top MCP server that we generate for ourself, so just internally at speakeasy is, is HubSpot, so it's like the top, it's our CRM.\n\n[00:18:38] So it's the number one tool that GTM support engineer, like everyone kind of interfaces to, uh, HubSpot because it's the source of truth on customer status, pricing tier, you know, how, if they're happy or not happy, all of those things. And so. Um, it's the most used MCP and we realized that the top, like once we started using it, we are logging all these tool calls and you, and you look at the tool calls and you realize the top used endpoint I.\n\n[00:19:05] By in the MCP, by, by AI is the search endpoint. It's not the like get customers endpoint or the, uh, create customers get deal. None of those, uh, like you said, brittle crud calls. It's actually just the search endpoint. And we're just lucky that HubSpot has an underlying kinda search, uh, graph database and it understands basic NLP search.\n\n[00:19:25] Um, and that just powers the, from the AIRS perspective, it's the go-to endpoint. You get the information and then you go to. Get customer, get, deal, get company. Right. So it's, it's fascinating to your point. I agree. I think the types of APIs that will become popular are going to shift from traditional, like when you're looking at open specs these days, it's always, you know, standard verbs.\n\n[00:19:48] Standard resources. Yeah. Now it's going to be like, I bet you there's gonna be a lot more search and points just like a get all endpoint. Um, yeah. Uh, less pagination, hopefully. I think that's also something that's like really. [00:20:00] Messing up, messing up LMS and agents, just context windows can't handle huge amounts of ated data.\n\n[00:20:07] Um, but yeah, no, I, I'm, it's, I totally agree with kind of your viewpoint that there's gonna be even more APIs as a result of this. They're just gonna be shaped and they're gonna look a little different. \n\n[00:20:18] Tom Hacohen: And, and I think there may still be smaller APIs, like I'm not, not completely discounting them, but I think for those as well, I think it's gonna be a consumption pattern.\n\n[00:20:26] It's gonna be different. So this is what I'm gonna say next. Is like half bake thought, so, okay, go for it. But yeah, I, I see a world, and I don't even know how it looks like, and maybe that's just JavaScript, but like when you interact with an API and the API just goes back to you and says, you know what?\n\n[00:20:40] This is the workflow you need to run. So you kinda like almost remote code execution kind of thing. But like, you almost run like a very safe workload thing when they tell you like, go do this, go do that, go that. So kinda like essentially like that API helping your LLM to decide how to build a workflow.\n\n[00:20:56] In order to achieve what you want in like an achieve, in a consistent, reliable manner. Again, it's half-baked, but I, I, I can see how, how we gonna still have like the smaller building blocks, but just like assisted by those things in order to build those workflows. \n\n[00:21:12] Sagar Batchu: Yeah, totally. I mean, we are already seeing kind of the, the day zero effects of that.\n\n[00:21:16] Like, no one wants to ship an MCP server with, you know, like 200 tools, right? Um, they're starting to ship. Even kind of the best practice we're communicating to people is almost like break it up by resources. Right. Or use cases. And if you are, let's say like a, uh, someone like Stripe, you have an MCP for, uh, charges and refunds, and then you have an MCP for invoices and billing.\n\n[00:21:40] Right. And you try to break it up by use case. Yeah. \n\n[00:21:43] Tom Hacohen: Yeah. I think one thing that I found. I mean, I think MCP as a protocol maybe supports it already, but I don't know if people actually use it that way, is like, like having a hierarchy. So like instead of having like separate MCP service, why can I not just like tell 'em like, Hey, MCP oh A LLM, these are like the high level tools that I have.\n\n[00:22:01] Like I have charges, I have customers, I have all of those. And then you can go and just like say, oh, I think like charges seem relevant to me. So like, go and then like query all the tools for charges. So kinda like a recursive mc p, but within the same server. I think that could be very interesting. \n\n[00:22:15] Sagar Batchu: Yeah, no, absolutely.\n\n[00:22:17] Especially 'cause an MCP server doesn't have to be tool called directly. It can just be an MCP server for your docs or for static content. And so maybe there is a world where you're making an MCP server just on like the open API spec, not even the tools themselves, the tool, the tools that are generated is just a single tool that understands markdown.\n\n[00:22:36] And so it's just telling you what are the end points that are available. You know, I, I agree. I, I kind of see, I kind of see what you're saying this. A concept very similar to how we have like system prompts and meta prompts. There was a concept here of like a meta MCP server for Yeah. Every API. Right.\n\n[00:22:51] Exactly. Yeah. That's a better way of putting it. Exactly. Yeah. No, uh, I think you're giving me a roadmap right now to go think about after this call. Um, that's very cool. Is there, is there something you all are working on at, to the extent that you want to share, like exciting things in the intersection of AI today?\n\n[00:23:08] Tom Hacohen: So I think the way the, the quick answer is no, not really, um, because, you know, we, we see ourself as like very core infrastructure. Um, so it's kinda like we see ourselves more like a web server than like an MCP. Um, we, we power a lot of like cool API companies, you know, like replicate and spot ai, like a million other recall, I forgot all the names.\n\n[00:23:28] And also actually we, we created standard webhooks, which I think you all support, right? Speakeasy supporting this. Yeah, I'm pretty sure. And OpenAI just announced that they're following standard Web Hook as well, just yesterday. I know. \n\n[00:23:39] Sagar Batchu: Congratulations on that. That's huge. Yeah. \n\n[00:23:41] Tom Hacohen: Yeah, I appreciate it. Yeah, so that was like a really cool stuff.\n\n[00:23:43] So, so it's kinda like what I was saying, I don't think we are working on anything AI specific, although that may change in the next few months. We have some something that we're working on secretly, but we are, you know, we are affecting that ecosystem and we are learning from that ecosystem and we are changing our product and the web hooks to better support how agents interact with like a synchronous, um, API notifications and all of that as well.\n\n[00:24:06] Um, so again, like we are adjacent, but we're infrastructure. \n\n[00:24:09] Sagar Batchu: Yeah, that's a very fair thing. I think something that occurred to me, I think it was a couple cycles ago, maybe a month or so, the Anthropic CTO was doing like a discussion around at Stripe sessions on what's coming up. And one of the things that he mentioned was I.\n\n[00:24:25] In a year's time, he felt that most agents, people interact with would be long earning asynchronous agents that you set off on a very complex series of tasks. Like, Hey, help me plan my honeymoon over the next week. Right? And goes and does 10 different things, comes back to you and, and that's scenario. I think maybe as an API person, the first thing my brain went to was like, it's gonna need a lot of web books because.\n\n[00:24:50] Async as, I mean, I'm, I'm preaching to the ultimate choir here, but like Async means, you know, you're going to be like an observing user and just get a bunch of web books sent away events as these, as the agent makes progress, right? Notifications on my phone, that's like agent finish step two of four and continuing on its way.\n\n[00:25:07] So, um, you know, it's, it's, I, I totally agree with you there. I think it's kind of our approach at speakeasy as well is. Once your core infrastructure, it doesn't matter whether it's an agent or a developer, so some of the interfaces may change and I think that's why we're investing in MCP. But the core idea is still powering your API, helping make your API very easy to use is still kind of our driving, driving force.\n\n[00:25:31] Yeah. Um, just around things out here, I think, um, I love always asking folks like yourselves, um. You know, what does like great develop experience mean to you? Has there been moments in your career, products you've used, things you've done where you used it and you were like, wow, this is what great devex means and this inspires me to go build great devex?\n\n[00:25:56] I, \n\n[00:25:56] Tom Hacohen: I don't have like any specific, I mean, there's so many, right? And like, again, it's kind of like the way you build stuff is kind of like you learn from all the things that you've built. So I, I can't what I'm trying to say, I can't attribute all the good ideas, uh, but I can share some good ideas. \n\n[00:26:09] Sagar Batchu: Yeah. \n\n[00:26:10] Tom Hacohen: Um, so I think before that about developer experience, I think a lot of people get it wrong.\n\n[00:26:15] Um, and what they get wrong is that they kind of like, they tie it to a specific thing. So it's kind of like the same way that like sometimes you would talk about the UI designer and like what would people, some people would think is like the whole UI experience and some people would think just making the butter red or blue.\n\n[00:26:29] Um, and I think it's kinda like similar to that. So like developer experience, you can under limit yourself to just thinking, oh, I should have a good API and I say stick. Um, which for some people is enough, but then other people would say, look, you know, you also need docs and tutorials. And then other people will also say, well integrate onboarding, and then great support and probably observability as well.\n\n[00:26:48] You know, if I'm like, I'm gonna use this tool, I want to like plug to my rest of the ecosystem. So what I'm trying to say is that I think a lot of people just like take. The developer experience, like one step too short and forget that it, it literally isn't the name developer experience, the whole experience that the developer gets.\n\n[00:27:04] And you have to take it from like cradle to grave and not just like stop halfway through. Um, so I think that's on the high level, like most specific stuff that I think are important that not everyone does. Um, so I think one of the most important thing is like making, doing the right thing easy. Mm-hmm.\n\n[00:27:24] And making it hard to do the wrong thing. Mm-hmm. Mm-hmm. And, and this kinda like, sounds semi obvious maybe, but like it's, it's, it's, it's kinda like manifests in very insidious ways, which is just like someone asks you, like for a feature and you look at that feature and you're like, Hey, you know what, that sounds like a good feature.\n\n[00:27:37] And then you, you ask the team and you build it and they're like, oh, another feature. Then you build another feature. Um, but then you realize that now all of a sudden your product is not obvious. Like someone that's just starting out. They don't know which path to walk on. Yeah. And, which I think is like the worst thing you can do for your.\n\n[00:27:52] For your product, you know, and that, that's what we actually have. You know, you can see the six API, we have a lot of undocumented APIs that we don't, don't tell anyone about until we realize that they, no, they really need this API. Yeah, because it's so easy to shoot yourself in the foot, you know, if you see this API in the quick start or like in the main docs.\n\n[00:28:09] And so I think that's one area. Um, and I think the other area as well is that people. Sometimes think too much or like, I, I obsess too much about like easy to get started or obsess too much about like, making a powerful platform, but they don't realize that you kind of need both. Like it has to be like super easy to get started.\n\n[00:28:30] Like you have to like start using the product almost immediately. It needs to be very obvious what the product is, but you also wanna make it possible for them to do more advanced stuff. So like, and you, you have to like, figure out how to design the product in a way that supports both rather than just one or the other.\n\n[00:28:45] Um. \n\n[00:28:46] Sagar Batchu: Yeah, I totally agree. I I love that. Uh, I, it's the most serious take I've heard on develop experience, cradle to grave. I'm gonna have to use that with my team, like I com completely agree with it, right? It's like a, it's an end-to-end problem, like doing it halfway doesn't actually, it's like an all or nothing, I think.\n\n[00:29:04] And it's also continuous, like I found even in just the, the couple years of building this business, like you have great DX as you said. You add a bunch of features and new functionality, and then suddenly, like one day I. You look at it and you're like, oh, what happened? Right? Why is this suddenly a little, little bit harder?\n\n[00:29:19] Or, and then you have to like continue to craft and it's just continues chiseling away at the problem. And I, I think there was like a period in, in the last year where there was a month or so where for whatever reason, like a piece of our product was unstaffed. And suddenly I, I felt like just little things were so suddenly starting to appear.\n\n[00:29:37] 'cause you just didn't have someone kind of chiseling away on it. Right. Every day. And, and that's how I always see the Dev X thing is it's really like a. Something you measure as a result of just continually crafting and crafting and crafting away. Yeah. Um, Tom, it's been really wonderful to chat. I think, um, I, you know, I love a lot of the takes you have.\n\n[00:29:59] Around, [00:30:00] um, not just develop experience, but also like how AI is gonna impact APIs. And, um, you know, as I said, I've been a huge fan of your business and what you all have built. Um, a lot of the things we do at speakeasy, we speakeasy, we try to embody some of the things that you've shown at swix, um, in terms of our, our user base and our listeners here, if they want to get in touch with you or, or find out what you're up to these days, what's the best place to do that?\n\n[00:30:24] Tom Hacohen: Yeah, just come to slick.com, check us out, join the Slack community, or engage us in GitHub. \n\n[00:30:29] Sagar Batchu: Amazing. Well, um, I am hopeful to see you out here in SF soon and, um, um, thanks so much for joining us. Hope to have you back on here soon. Yeah, catch you soon. See ya.\n\n