If you're a dev tool, your default is probably to create all your own SDKs but you might also wonder if sometimes you're signing yourself up for unnecessary pain. Today's guest is Sid Maestry who worked in DX PayPal and Xero and hosts the art of developer experience podcast and is also a dev rel at API Matic which is a DX API platform. We talk about when to build your own SDK. We talk about the open source tools available for building APIs, a lot of which I didn't know, and you also talk about how AI has impacted APIs and developers in general. Enjoy.
But 0 is you you were saying like 0 is like they fought they saw that APIs were gonna be like really important, even though they're they're we're an accounting platform, but APIs are gonna be useful because our partners are gonna build on top of Xero and, like, add all this value to our customers. And and I've I've met people building, like, Xero add ons, and, I know, like, how big of an ecosystem that is. So that must have been, like, a really big part of the growth, I would imagine.
Yeah. I think if you can imagine what life was like before, we started moving a lot of these applications from our desktop to the cloud, If you had a desktop accounting software package that you installed, how difficult it was to move data in and out of that software. The they had these import export, sort of menu items and the formats were always tough to wrangle and it was very time consuming. And people just spent a lot of time shuffling data back and forth. And API is really unlocked the ability to do that in real time even if that was what you needed and it was much more stable and reliable.
And yeah, I think I think the team that's founded 0 were very forward thinking in that way and they they kind of saw the wave of, you know, what was going on with Salesforce and companies like that. They just saw it as an opportunity to disrupt the existing, incumbent, accounting software that was out there.
Yeah. Do you do you get a sense, like, is this kind of, like, secondary I don't know. Like, this, like, developer plus, you you called it, like, economy is up would you say it's bigger than, like, the dev tools economy, or is it, like, sort of how do do you think it's, like, that world is bigger or, like, is it
Yeah. That's an interesting question. I think that in the past, platforms would get, would hit critical mass and you'd get this flood of developers wanting to build on top of it. I think I mentioned Shopify, Salesforce, 0 was definitely part of that as well. And I think that as time goes on, being able to find that Niche application that you can build and connect to it becomes harder to identify and actually monetize to the point that a developer can can feel like it's worth the investment building.
Who knows? Maybe AI is gonna make that a lot cheaper to build, and therefore the economics are going to make that a better proposition. I think that you get these big tentpole companies like that Facebook, remember, had their their platform play as well for a while, with games and things like that.
But I
feel like dev tools is like 1,000 or 100 of 1000 of opportunities. And open source, like, I think that there's probably a lot more activity going on in that space, because you don't have to be locked in and unfortunately, you know, constrained perhaps by the limitations of the platform that you bought into. If you become a Shopify app developer, then you have to play by Shopify's rules and you have to adhere to their terms of use and all those sort of things. So there's there's definitely limitations while if you're building your own dev tool to solve some kind of problem, then, you know, there's a lot less constraints on that. Maybe you can do things the way you want to as a as a company.
Yeah. It makes sense. Like and I guess there's only, like, a few platforms that are, like, big enough that you would yeah. As you said, I think Tempo, what you called them, like, big enough that people actually want to develop on top of them, like, tie their career. Because I guess it also involves, like, you know, like Salesforce.
Like, you have, like, the Salesforce developers and I suppose, Xero, you probably get, like, experts in Xero, APIs, and they build agencies and stuff like that. This episode is brought to you by WorkOS. At some point, you're gonna land a big customer and they're gonna ask you for enterprise features. That's where Work OS comes in because they give you these features out the box. Features like skin provisioning, SAML authentication, and audit logs.
They have an easy to use API and they're trusted by big dev tools like Vercel as well as smaller fast growing dev tools like Nock. So if you're looking to cross the enterprise chasm and make yourself enterprise ready, check out Work OS. We've also done an episode with Michael, the founder of Work OS, where he shares a lot of tips around crossing the enterprise chasm, landing your first enterprise deals and making sure that you're ready for them. Thanks Work OS for sponsoring the podcast and back to the show.
Yeah. I think that those those companies that build those kind of platforms have to be really successful with their core product to have a customer base that's large enough for developers to benefit from. And I think that's part of the Yeah. Attraction for developers is they've got a built in audience. If you're building a dev tool, you have to go and create that audience or you have to find that audience and connect with it.
And that that is not always a the strong suit of engineers. Right? Is is the marketing side of things. So it's a shortcut, but, you know, there's trade offs in in going with, more of a platform developer tool.
Yeah. 100%. Yeah. Yeah. I follow some of the, like, indie hacker, communities, and some of them are, like, for kind of indie hackers, it's, like, actually better to just build inside an ecosystem.
You know, start building, you know, Trello. We've had, someone on who was building, like, Trello power ups and, you know, it's great because you just you kind of in some ways, the distribution is, like, taken care of, but then it's like, you know, is there, like, a VC that's, like, enormous opportunity? It's, like, harder to see that because you're probably not gonna eclipse, like, the the whale that you're like. You're like the barnacle on the whale kind of thing. Like
Yeah. I think well, word WordPress. Right? Plugins. Right?
That that was really popular for a while. I think part of what you can do if you do go that route is the companies, the people inside those companies that are fostering and building ecosystems like I did at 0, we get really excited when there are developers that are all in on our APIs and our platform. If they are like, if you can build those relationships, if you're excited about the opportunity and you really foster it, you can get a lot of benefits from being the the rock star in that community, but that's an investment. And if you if you extend the platform in a way that ultimately could or should be core to the product, then your you got pluses and minuses to that. The the the pluses, maybe they acquire you, right, and you become part of their bigger product.
It cuts the other way, where if there's 6 of you all trying to fill that core need, only one of you might get acquired and the other 5 are now left in the cold because the acquired version becomes the default. So another thing to consider when you're looking to build tools is what's the landscape and how likely is it for a platform to disrupt me, in my, in my efforts.
They just add a feature and then, like, you're you're, like, irrelevant at that point because why do I go to the extension store when, like, it's just that? Like, I can do it already. It's like
Yeah. Yeah. I I will I I'll I'll give you an example where it turned out positive. Xero didn't have much of an inventory solution, and so they added, I would call very basic inventory functionality. And we had inventory app partners, but they were so focused and going so deep on that topic of inventory, which I didn't understand how complex that can be, but it can be very complex, especially in an online, offline retail environment where you've got inventory you need to manage that you're selling through multiple channels.
Like, there's all kinds of complexity. Xero wasn't interested in solving that. So even launching an inventory feature didn't really negatively impact the app partners there. So it's like knowing, like, how you fit into the puzzle and knowing that you're adding value in a deep and meaningful way for customers means that you've got more, more security long term.
Yeah. That makes sense. Yeah. One one of the things I wanted to ask you because, obviously, you're with API Matic and it's a, you know, developer experience platform, really helps with APIs. But then we've got, like, we've got, like, Stripe.
I think recently, it's, like, 70,000,000,000 valuation. And, you know, a big part of that, I think, is that they're famous for developer experience. And I think for them, they probably you and you can correct me on this. It's like, I think a lot of it's like build in house, and then there's this kind of like trade off of like, should we should we build everything in house, or can we actually get a better experience by buying? I wonder if you could talk a bit about, like, the build versus buy in terms of APIs because I know this is something that you think a lot about.
Yeah. Yeah. I think we all have a lot of respect for what Stripe is built. In the in the developer tool space, we often will quote them around why they build SDKs, which they have right in their developer docs, which is they want to reduce the amount of boilerplate code that developers have to write and maintain. That's why they have built them.
And they've got a really robust developer experience. And like you said, they've built to my knowledge, they've built that all in house and they've built it up over a long period of time. I imagine they've invested 1,000,000 and 1,000,000 of dollars. And yet we all aspire and want to have, you know, have that if we have an API that we're taking to market. So the question is build versus buy.
I think it depends a lot on there's lots of factors. I would say the stage of your company, the maturity of your APIs, I think you definitely have to know, you definitely have to achieve that product market fit with your APIs before you start thinking that you want to have the same d x as Stripe. You need to have, you know, great API documentation, of course. You need to have some good way to onboard those initial first hundred developers. But you probably don't have a huge catalog of APIs.
It just depends on the company and where you are, what stage you're at when you're releasing them.
I was gonna say, like, OpenAI kind of had like a theirs was so limited for such a long time, but it was just, like Yeah. They had this such a strong PMF that didn't matter because it was, like, everyone would just figure out how to do it anyway.
Yeah. Yeah. I think that's that's an interesting thing about APIs is like, how excited are developers? What use cases are you solving for? What's the competition like?
Those factors can really drive how much you invest in your DX. And so like I'll give you know, we'll stick with the Stripe example. There's a lot of great payment APIs out there now that are similar to Stripe and yet some are doing things that are very different in the payment space. You get companies like Adyen who have built up really strong reputation, PayPal, Square. You know, so you've got the original players.
You've got, you know, ones that are going after the point of sale. Right? Square is known for their point of sale, but they also have great APIs. So they are also, you know, they're competing on product features or API features, but they're also competing on the DX. And I think to come back to your question of build versus buy, I think everything's a trade off and you just need to figure out, for example, what level of control do you think that you need in your DX?
Like, do you need to control every single pixel? Do you need to control every line of code in the libraries you give developers? I think Square has or Stripe has a bit of that in their DNA where they just they have such a such such a strong opinion on everything that I think that they feel like they have to have that level of control. I also think that they have to hire a lot of experts, people with a lot of language expertise and have them on staff and they have to continue to invest in resources to build that DX. If you are budget constraint, I think we've seen a lot of this in tech where people are being asked to do more with less.
I think that if you have a limited headcount, are you going to have your engineers building new features on your platform and your APIs? Or are you gonna have them building, you know, building your own custom CMS for your documentation and your SDKs if there are also good open source and commercial solutions out there. So there's all these trade offs, I think, that come into play. And I sort of see it as 3 options. There's you can build everything yourself.
You can buy, you know, full out, get a commercial product and there's lots of them out there like APMatic. Or you can try to split the difference and say, I'm gonna go with open source, which is, you know, quote unquote free, but in a way you're both buying and building. Right? You're you're buying it in the sense that you're buying into that ecosystem with all of the pluses and minuses of an open source project and, you know, the direction it goes and what features it has and the bugs that exist. And you still have control.
You can kind of influence that to some degree, but you're hiring engineers to to contribute to that open source project and maintain that tool chain in house. And so, I've worked with open API generator, for example. So, you know, we've had to modify templates and get really skilled with mustache. And we weren't all language experts, you know, we weren't PHP experts, for example. So we had to go back and forth with our developer community.
So there's all these trade offs. When you go the commercial route, you're basically hiring a team of experts who 20 fourseven are thinking about developer documentation and they're thinking about SDKs and they're thinking about what's the next feature of DX that our customers might want. And let's go and build that so they don't have to. So we're doing that with, with AI and things like that inside of our docs. So there's all kinds of, you know, pluses and minuses.
And then, yeah, you have to wait for that commercial company to ship that. So, like, you can't you know, you can, you can push for it. You can try and get it prioritized on the road map, and we do that with our some of our customers, but, it's there's all these trade offs.
Yeah. Yeah. It makes sense. And I think, like, when you were saying that, one of the things I was thinking of, like, is it, like, partly, like, if, you know, your SDKs and and your docs and your like, how they use it is, like, your core proposition. It's like if you if your, like, core thing is that that is so innovative and it's, like, you know, shockingly good and, like, Stripe, like, they have their, like you know, they surprise you with, like, the test payments and, like, you can see the stuff, like, in line and, like, how it works and stuff like that.
And, like, when no one had ever done that before, that's like, okay. If you're trying to do that sort of thing, like, probably you're gonna just build it because, like, probably it doesn't exist. But then if it's like if your innovation is, like, elsewhere and you just want that part to be, like, really good, but, like, not, like, you know, completely novel, then, like, you're, like, maybe gonna look at buying. Is it is that sort of like and, obviously, there's the other trade offs around, like, constraints around, like, how much budget you've got, like, how many people you've got to work on it, that sort of stuff.
Yeah. Yeah. I I think if you've if you've got a process in place where your as your API changes, you're able to keep your documentation up to date and things like that. Keeping SDK libraries up to date can be challenging in itself. And I would say what is I'd step back and say, what do giving developers libraries, what does that do for you?
Well, when we've talked to our customers, we found that if you don't have them, what you end up doing is you end up devoting a lot of energy and resources to supporting and answering developers' questions because they're having to roll their own solutions and they're having to write all that code from scratch. And so you end up having higher level of support, especially if you have anything unusual or complex. Like, I've seen authentication that is non standard in different ways and that complexity can be harder for developers or I don't know if you've dealt with uploading binary data through a multi form sort of, you know, interface. Like, depending on the language that can be straightforward or it can be a little little little, tricky or a little touchy where you just you just get something just wrong, the spacing just wrong in in that header signature and it just doesn't work. And you can spend hours as a developer trying to figure that out versus a library that's been tested and you know it works.
So support is one issue. The other thing is if you are onboarding developers successfully and then waiting for months months months for them to actually build a production grade integration with all the tests around it that they need, with all the additional functionality beyond just making an API call. Like what happens if the API call fails? Do you have retries? What happens if you time out?
What happens if it gets into some kind of state where it's constantly retrying, do you have a circuit breaker or something? Like there's all kinds of things that you can get out of the box with a commercial SDK solution that if you don't provide it, developers who are trying to build really robust and reliable integrations because this is what they're putting in front of their customers and they care deeply about their customer's experience, they're going to have to build a lot of that machinery themselves and then maintain it. So those are the 2 things we see, support and just how long it takes for things to get built. And if you're monetizing your API and it takes 6 or 9 months for an integration to get built, that's time that you're not monetizing your API because there are no production API calls happening. You're just they're living in the sandbox and you're just waiting and waiting for them to launch.
And that can be pretty important if it's a high volume, customer or partner that's gonna be using your APIs.
Yeah. That that makes sense. And it's, it feels like it's one of those things as well where it's like you're gonna just be constantly, like, you're adding features. Like, I was talking to some guys yesterday about, like, their pricing. And I was like, every there's always, like, every line in their pricing is because someone came along and started, like, you know, doing something very odd.
And then, like, suddenly they had to change the pricing model because someone was, like, costing them so much money. And it's like it feels like it might be that sort of thing where it's like you start out with the basics and it's like, okay, so then someone needs to retry, so you built that. And then someone needs, you know, there's the circuit breaker, you built that. And then someone needs, like, this specific type of, like, authentication or, like, you know, like, you and you just keep adding it. Whereas, I guess, like, probably you probably get a lot further without having to keep doing those things, I would imagine.
Yeah. Yeah. I think a big one in the last few years has been, open API supporting polymorphism, and therefore a property could be a string or it could be an an object, like the full object itself. So it could be the contact ID or it could be a full contact object and the API will accept both. And how that gets, when you're generating docs and the, you know, and generating code, docs don't need to compile.
So you can sort of handle some of that polymorphism in your documentation and some do it better than others. But then when you want to generate code, like, you need to make sure your engines can handle some of that complexity in your API. And that's that's been something that that has to be tackled by a lot of these engines in the last couple of years. So that's as as our API designs change and evolve, then the tools have to catch up and and match some of those, design patterns.
Yeah. Yeah. And, actually, like, if if someone's not buying and they but they just kind of wanna use, like, the best, like, open source tools and stuff, like, are there any that you I mean, I guess this is gonna partly depend, like, by language and stuff, but are there any things that people should look at that they might not have been aware of? Because I recently went and and met your colleague, Suhayb, in, the API Days conference, and there were, like, so many tools. And he was talking about things that I had never really heard of, but, like, people who spend all their time on APIs are, like, very, very, like, very aware of.
Yeah.
Sure. Yeah. I feel like I've been living in a little bit of a bubble, where we all talk the same language, and then you get out of your bubble and and you realize, oh, I'm I'm really deep in it. I think, that's a great question that you're asking. I think for for, for DX and for helping with API consumption, if you're if you don't have to hand craft things, then you're wanna look for ways to automate them.
Right? And the way that we automate things around APIs is with, open API, formerly known as Swagger. And if you go and look out at the ecosystem that's been built around that specification standard, there is a huge number of tools, probably more yeah, definitely more than 5 years ago when I got started. And so I would say what I didn't know 5 years ago and that I I preach today is make sure that your API specification is well linted and validated for the uses that you intend. So if you're looking to generate docs oh, sorry.
You asked a question?
No. I was just gonna say and just maybe we should just just in case anyone's not used swagger or, like, specifications, maybe we just say exactly what that is as well.
Yeah. No problem. Yeah. Yeah. So open API, is not an API.
It's it's a it's a standard with which you can describe your API. So you would, it's machine readable, but it's also like humans can read it as well but it's really great for machines. So if you have specific endpoints, you would document those following the open API standard. If there are requests and response objects, you would define those. If you have a specific security scheme like OAuth 2 or Basic Auth, you can define that and you can tell which endpoints are secured using those different things.
So at a very high level, it's it's a description language. Does that maybe that'll help hopefully that'll help folks kind of orient Yeah. Yeah. So, with with an open API file, you can do like well, first of all, you can design your API, which means you can actually understand and think through how the API will work before you write any code. You can mock the your API and put it in front of customers, which I've seen done and at companies that I've worked at.
And it's amazing for our product manager to get feedback before, again, any code's been written and you can adjust the design. And then I've not done this. I know that some people will use it to generate some of the server side, you know, stubs, some of the server side code. I've not done that myself, but I know that there's some tooling out there that you can use to do that. And then you can use it to generate other things, documentation, SDKs.
So to answer your question, if I were starting, I'd want to make sure that my OpenAPI definition because there's how do I put this? You can create a totally valid open API spec that doesn't generate really great code because you've done things in a way like when you lint it, if the linter doesn't tell you that you have to have all the descriptions or all the examples, then when you generate the code, you may not have the examples to generate tests that test that code. If you name your models if you name your methods something really like not not intuitive for developers, it's gonna generate methods in your library that aren't readable. So there's a definite design eye that you have to put towards these and there's tools out there like Spectral that's open source. ReDoc has a good linting tool, but those tools are great for linting if you're generating docs.
I think API Matic might be the 1st company, maybe only company that's released a Versus Code extension that has 1200 linting rules specifically to lint your open API definition so it generates better code. So whether you choose to use API Matic or not, if you're looking to generate code I would go and, you know, if you use Versus Code go to the marketplace, it's free, download the API Matic Versus Code extension and open up your API definition in there and see what sort of linting and validation, issues it detects and see how close you are to being able to generate code. So to me, that's step 1. Step 2 is to actually go and generate the code.
So so, Sid, just on that, like, just the thing that made it Yeah. That crystallized it with me on that part was that, like, you can do stuff like, you know, plurals and things. Right? So, like, if you have, like, your path and you were like, the API that fetches all the chocolates available and, like, at one like, you had, like, you know, the path was like chocolate. And then the next time you did it, like, you were like, you know, crisps.
Say potato potato chips for the Americans. And then you were like potato chip or something. I don't know. Maybe that's a bad example because it's the plural is the thing. But, like, you can do, you can do stuff like that. Right? So that you're not like you're actually keeping it consistent, across. That those are the kind of things that you would learn.
Yes. Yes. You could you could you can okay. So if you don't give an operation ID because it's not required that you have an operation ID for every path, for every every method on your path. So you've got a, a get, a put, a post on a path.
If you don't put an operation ID then the machine, whether it's documentation or or code generation, is going to try to infer what to call that. And so they'll probably call it something like post chocolate. But you might actually say, I actually want it to be create chocolate. So if you leave out the operation ID, then then you you get whatever the machine gives you and it'll do its best. It's a machine.
But if you wanna be very specific about your DX, then you don't wanna forget that operation ID. That's just one small example. Does that make sense?
Yeah. It makes sense. And I think the big takeaway I'm and the I used OpenAPI for the first time recently. Guilty of not, you know, using it. And I think it's it's kind of annoying to to do it and to maintain it, to be completely honest, but it's, like, it's worth it, it feels like, to just do it and, like, have, like, consistency across it. Like, even just for, like, internal projects, like, where you're not public putting it out to the public.
I'm I'm curious. What tool did you use to, to edit and and create it?
I so I did it all, like, completely raw. I raw docked it as they would say. Like, I, I I think I was and I was honestly relying a lot on, like, the generated like, to using, like, cursor to actually generate, a lot of the the actual specs. And I think I was using this tool that would generate documentation a documentation page, but I had to remove it because it was, it was blowing up Snyk with, like, vulnerabilities. So then I I think I I can't even remember how I did it, but, like, I didn't use any library and, yeah, I was able to just, like, display, like, docs from the spec.
That was the main reason we we did it was to just have some docs to, like, hand over to different team, basically.
Yeah. Wow. Well, if it makes you feel any better, when I years ago when I was at 0, we didn't have a swag it was swagger 2 and they were transitioning to open API 3. We didn't have anything really. And so I basically hand coded reverse engineered from existing documentation the open API, file.
And it, you know, I got really comfortable in YAML, but it was it was really a massive, like, ongoing project that just took a long time to to do that. And so it's interesting to hear that, that you didn't use something like Spectral or some of these other tools that I think have come out since then that are making it even easier to, to create these sort of things.
Well, there you go. So that's a lesson for someone else. They can learn from my misery that, you'd check out Spectral also if you're gonna try Sorry.
Sorry. I shouldn't say Spectral. Spotlight. Spotlight created Spectral. Spotlight. Spotlight.
Spotlight.
Which is now part of smart which is they were bought by SmartBear. So, like, the names keep changing. So, but, yeah, Swagger Hub and those sort of UI tools, have made all of this a lot easier.
That's cool. Yeah. And then so, sorry. You and I did interrupt you. I think you were saying something before.
Oh, yeah. Well picking up. To to get back to your original question is, like, once you've got an API open API definition that's in good shape, I always feel like there's there's not really the perfect tool out there. It's the perfect tool for you and so if you are looking to just generate one language then you might go and find an open source project that's purpose built for that one language and try it out. You'll see what the code is like.
I think all the commercial tools out there have some kind of free trial. API Matic has a free trial. Just go in, import it, and generate some SDKs and see how see how the code looks. I think there's a level of trust that these tools have to overcome. I think that developers are naturally skeptical, especially with cogen.
Maybe that's shifting with AI, maybe not. Maybe people still don't trust AI completely. But I think that people have over time gotten more confident that the code that comes out is is quality code and doesn't have a lot of bugs and, you know, actually functions like I'll I'll be honest, I've tried I did try some tools years ago and I would, generate in some language and I'd go to try to compile it and it wouldn't compile. And, I'd find out it was because there was something in my spec that the machine didn't like. Maybe there was a space or a special character that I had in the name of something like and that debugging process can be kind of frustrating.
So if it works right out of the box, then that's a good sign that that, you know, the tools at least worth exploring further. And so it's good to kinda put them through their paces, in an afternoon.
Yeah. That that fits with what what I've seen. And so to transition quickly, from open API to the much to the often confused open AI. I feel like people say that all the time. So what kind of things are going on with AI now, with APIs, like some kind of considerations that people should be thinking about?
Yeah. I think, the first of I feel like we're 2 years in on this AI revolution. I mean, of course, machine learning has been around forever for for for a long time, and we've we used it at 0 and things like that internally. But I'd say the 1st year of really broad usage of AI, I think that there were a lot of experiments and people trying to do things with with AI around APIs that the results weren't really great. I think in the 2nd year, things have gotten much, much better and you're definitely seeing tools that are helping you, at least create that initial cut of an open API definition.
I'm seeing, people using it for fixing your open API. I've also seen it when it comes to developer experience, people are using it to consume your documentation and basically enabling like a chatbot that developers can ask questions. And some people are doing that in more of a, like, let's hook into Zendesk and let's hook into your forums and let's consume all of that and make make the model trained. Let's train the model on everything about your documentation. At API Matic, we've been doing our own experiments in that space as well, but we're really focused on the fact that we generate SDKs and code examples, and we generate guided walkthroughs, and we generate a lot of artifacts that are code centric.
And so our, our AI models are built that when a developer asks a question about how do I do x, it actually generates, I I say synthesizes code that doesn't exist anywhere based off of the SDKs that we've generated. So the import statements are importing our libraries and it's, you know, generating code for developers to, you know, stitch together 2, 3, 4 API calls into a piece of integration code that a developer could copy and paste into their IDE and run. So that's that's some of the ways that I've seen it, both internally at APImatic and also out in in the community, but I feel like there's even more opportunity. I think there's gonna be more innovation when we get into year 3 here.
Yeah. It does feel like it's all just gonna kind of completely change. It's hard to tell how.
Yeah. I'm I'm I'm really curious to see how engineering's changing. I'm wondering what your opinion is on the AI tooling and how like, what's gonna be the big impact when it comes to how AI helps write code? Have you have you given that much thought?
Yes. And I've asked quite a lot of people, and I've asked, I mean, I spoke to I asked similar questions to Swyx, who's, like, you know, very big in the AI space run runs the latent space podcast. And I also asked, Kenneth Auchenberg, who was, like, the, he was one on the team of Versus Code and, like, I think, led DX at Stripe and was like thinks about this a lot. And, I think the short answer is, like, they didn't know. They were like, yeah, we have we have, like, thoughts, but, like, it's so hard to tell what's gonna happen.
And and on a micro basis, I can only speak for myself. And, like, I some days, I use Cursor, and it's, like, amazing, and I think this is great. And then other days, I'm like, this is just, like, AI code sucks. Like, I just it sends me down rabbit holes. Like, I I just waste more time.
I'm like, I'm more effective if I just don't use it. Like, I kind of, like, bounce back and forth. And I felt like it it will have a huge impact, and it I mean, it really is. But my I'm very unsure on, like, the role of developers in the future and how that's gonna change. I don't know.
Yeah. I I feel like there's I'm hearing I'm hearing that that that some of the tools are getting really good at building very small, almost like micro applications. And so I I think that you probably get more people who aren't full time developers. I think building applications that don't have to be big commercial successes but scratch their itch, I feel like there's some interesting opportunities there. And I think that there's still work to be done, when it comes to the professional developers that are gonna be using these tools.
I'm gonna date myself but when we when we all started working with HTML, you know, back when there were dinosaurs roaming the earth, the big thing the big thing that people wanted was WYSIWYG. They what you see is what you get. They wanted a word processor that spit out HTML and you would, use some of these early tools and you were like, oh, it's amazing and the demos looked amazing because it was WYSIWYG. And then you would spit out the code and it was just a nightmare. I think Microsoft had 1, front page is what it was called.
Anyways, it was it wasn't until, like, Adobe came along and they released, their Dreamweaver tool, which they probably bought someone and put their name on it and and improved it. But basically, it gave you the ability to toggle between WYSIWYG, like a editor and down into the code level, and you could tweak it in either, you know, jump back and forth between it and have 2 panes open and you could toggle it and you can tweak it and you could see the updates live. I think we're gonna go, you know, we're gonna eventually get going in those sort of directions where, like, the developers can have more ability to jump between the AI and the code itself and iterate on the code. And I think we're already getting there, and I think it's just gonna keep improving in that direction. So, the don't judge I don't think you should judge the AI coding tools based on a year ago, because that was sort of the front page Yeah.
You know, HTML experience. And now it's gonna you know, they're gonna figure it out and it's gonna get better.
Yeah. That's a really good, I really like that. That's a really interesting analogy. And you can kind of see that it's like even now, you know, it's still of course, there's loads of like low code tools where you can just do everything by drag and drop, but there's still the place for developers and, you know, it's the harder problems probably that you need the developers for.
Yeah. And just sometimes you'll just look at what, you know, when it's no code and you are trying to get it to do something and you know how to do it in code and yet they don't allow you to do it.
That Yeah.
I think that's where technical people get super frustrated because they're like, I just know if I could get in there and tweak it a little bit, I know how to solve that alignment problem or I know how to solve that interaction that I'm trying to build.
Yeah. And maybe that's the analogous part on AI. Like, oh, if I knew it was trained on the stuff, then I don't know. Well, it knew what I knew. Trained on our brains. I don't know. Yeah. It's yeah. Super cool. Okay. Amazing. Sid, if people wanna learn more about you and or they wanna learn more about API Matic, where where should they go?
Oh, wow. Yeah. So I I would say for API Matic, just head over to API Matic dot io and you can check out some of the free tools that we have like the Versus Code extension. We have something that will transform your other API spec formats into open API or back. We're talking RAML and Blueprint and some of these other other or older swagger formats and we even have a tool free tool that'll score and give you like a 0 to a 100% rating on how ready your API definition is for generating code.
And then you can try out the tool itself but there's a lot of free stuff there as well. And there's also a link to my podcast, which is called The Art of Developer Experience and my most recent guest, amazing amazing thought leader, Jack Bridger. And so, you you could, you can get a get a, get that episode, once it's been released. So that'll be fun. And I'm on LinkedIn.
You can always go and connect with me there and ask questions. I love talking DX but I'm also I've been doing DevRel for over 10 years so I have lots of thoughts on how to build community and build tools for developers, since I've been doing that for a while and working with some pretty fun companies along the way.
Amazing. Well, thank you so much, Sid, and thanks everyone for listening. We'll see you again next time.