Latest / The MonkCast / SDKs in the AI Era with Kin Lane

Transcript

SDKs in the AI Era with Kin Lane · The MonkCast

• speaker-0: there, Kate Holterhoff here. I'm a senior analyst at Redmonk and my guest today is Ken Lane. He's the co-founder and chief community officer for NAFTEKO, although he's probably best well known for being the API evangelist. So Ken, it's an absolute pleasure to welcome you on the... speaker-1: Pleasure to be here, Kate. Thanks for having me. Big fan of what you guys do. So honored to be here. speaker-0: So, we're going to be talking about unsurprisingly APIs today, but also SDKs and how they're relating to this AI era that we're all sort of grappling with. So, I want to start, you know, I'm going to be leaning into my ignorance here. You know, I love having guests on where I have a question to answer. So, just to lay the groundwork here, could you walk me through the SDK life cycle? How have they been produced historically and what purpose do they serve? speaker-1: Yeah, the SDK evolution and kind of journey is long and I would say there's many layers to it. But you got to start with APIs because application programming interface, ⁓ more specifically REST or HTTP APIs using the web ⁓ as an interface for programming, not just web. but mobile applications, device applications, many different types, and now AI applications. ⁓ Those are meant to be kind of across programming languages, meaning you learn REST, you learn HTTP, ⁓ and you program against that. You don't have to always know Java or Python or Go or JavaScript, but... When you're programming an application, you are using one of those languages. So you oftentimes have to produce an SDK or a software development kit. And the common thing starting around, would say 2008-ish with ⁓ REST APIs is you generate multiple programming languages or you write them. You don't always generate them. We can get into that in a little bit, but you produce an a software development kit. your Java developers have the language they know. .NET developers have the language they know. But your API should work across languages. And that's really one of the core tenets of doing APIs, because you can reach a really broad audience. But us engineers, developers, we love our programming languages. We tend to stick with one of them, maybe one or two of them. But we're pretty dogmatic and religious about our programming languages usually. so software development kits get generated and produced to support those languages. But they've kind of evolved over the years, which I'm sure we're going to get into a little bit more as far as how they're being used to support this AI moment. speaker-0: Okay, and so it is not incorrect to say that SDKs are still the primary interface for APIs. speaker-1: Yes and no. I it depends on where you come from. So I'm going to, that's a great question. So I'll kind of produce a schism there is some people work directly with the API and that's why you end up with clients like Postman, which is one place that I worked is so you, it's it's say it's a browser for APIs. ⁓ It is what Postman is. And now there's Bruno, there's Insomnia, there's a whole host of commercial and open source. clients that let you connect with those APIs and see your requests and responses, do your auth, and do all the things that your SDK traditionally would abstract away. Now, there's also the CLI, and this will come full circle again with AI because CLI is kind of having a resurgence. Some developers prefer to work with APIs through a CLI or a command line interface. and it will work directly with API, but doesn't need an SDK, but you can see requests and responses. Curl is a very common CLI ⁓ tool that allows you to work with APIs. it depends on how you got introduced to the API realm, ⁓ how you work, ⁓ how strongly ⁓ religious you are about a programming language. It depends on which doorway you come in. You might come in through the CLI, you might come in through an SDK, you might choose Postman or a client to work with it. And then I'll add another layer is a lot of APIs will generate documentation and some of those document, some of that documentation is interactive, meaning you can actually make requests and responses right in your documentation and you don't need an SDK and they'll produce snippets. or scripts that aren't quite an SDK. They're just a little JavaScript snippet that'll make the request or the response. But the difference between those is an SDK tends to have all the authentication. It'll have the OAuth, your API keys. It'll tend to have all of the API paths in there where a snippet will just be like one API path and maybe just a really simple token or key that you put in. It's much more lighter weight. So depending on what your jam is, you may not need an SDK, but at various stages, I would say every three years, maybe five, someone comes along and goes, SDKs are dead. They're gone away. You don't need them. And it's usually because it's some new startup that's got a new client or new something or other. that's how it speaker-0: Got it. Okay. I appreciate the nuance here because I'm going to need that. ⁓ And shout out to Curl. Daniel Stenberg was on the Mugcast not long ago talking about AI slop, which actually that might come up today again too. So that really helps. ⁓ Okay. So it seems that for almost 20 years now, we've treated SDKs as a central and important, a core maybe interface for the API. But then the question seems to be that we're hearing from vendors is that if developers are increasingly going to be interacting with APIs through AI tools that read the open API specs directly, ⁓ does the SDK start to become optional at this point? speaker-1: Yeah. And there was another nuance there. You said open API and that, you know, what I, what I said before is open API is often used to generate those ⁓ interactive documentation that I told you about swagger. You are is, one of those postman and clients use open API to generate what's needed for the client and then same for CLI. So open API is a key piece of that. And OpenAPI, formerly known as Swagger, is a machine readable JSON or YAML ⁓ artifact that describes the surface area of your API. And top API providers ⁓ produce that. GitHub maintains their own Twilio, Stripe. They all have OpenAPIs, which are just basically that manifest of what's available. What can you do? What parameters? How do you auth all of that? I've seen lots of people say, you know, SDK is going to go away because open API does, does what it needs at various stages. So I'm not ⁓ a big believer that this round it's going to happen, but you know, it could. But yeah, with where we're going with spec driven development, I guess, in the AI realm is, you you have that open API and your AI can. ⁓ usually generate that, like it can read documentation and then generate the open API for you, but it can also take that open API and know what it needs to make that call for you. And or it could write the SDK code on the fly that you're going to need to actually automate. And I think why it excites some people is because you could, it could potentially reduce that context window down, meaning Stripe's open API has, ⁓ gosh, forget how many actual API paths, it's a lot, but it's like a massive file. It's the whole menu for Stripe. It's got payments, invoices, all of it. And if you just need to make a payment in Copilot or in Cloud or wherever you're doing your AI integration, you just need that payments. And if you feed that whole open API to Cloud, It can reduce that context window down, find what it needs, and then potentially even generate an SDK just for that path rather than the full Stripe JavaScript or Java or Go ⁓ SDK that would have everything. So that context window when it comes to your tokens is pretty key to what's going on. speaker-0: Okay, there's a lot there to unpack. ⁓ So let's talk about the future of SDK generation, because I feel like that's kind of what we're looking towards here. So if most companies are still sort of hand crafting SDKs because the generated ones just aren't, they're not feeling right at this point, would you say that SDKs are the ones that ⁓ we're seeing on the market, maybe that are being introduced and aren't quite as established? How are they different than ones that have come out before? Like what sort of changes have you seen in the know, the realm of vendor created SDKs. speaker-1: Yeah. So there's a lot of details in the SDK, like why do you need a software development kit? There's the authentication layer. So it's going to depend on how complex that is. the design and the surface area of the API is going to, you know, speak to what ans- how I would answer your question. you're in there certificates and there's a sophisticated auth, the SDK is needed. It's a very, ⁓ usually handcrafted. structured to deal with that authentication, that security layer, as well as how do you actually make requests. And so that's something that AI is not always going to get and understand and be able to do. the right certificates and all of that. Another is that context window ⁓ is, like I said, the open API tends to be a full menu of what's available for an API. And when you generate an SDK or when they handcraft that SDK, it's everything. you started doing this even before AI start shifting, Microsoft has a SDK generation tool that generates using OpenAPI called Kyoto. Kyoto, Kyoto. ⁓ And it'll let you pick from that menu. like, you just want, you know, hamburger shakes and fries. You don't want the full, you know, you just want what you want. And it'll generate that SDK with the auth for you. And that's the precursor to that ⁓ context window that I'm talking about is just give me what I need, make it as fast and quick as possible. And then there's the design of the API, meaning what you need from the response. It may be a big JSON blob and you just need three fields from it, but your SDK is returning all of that. And for AI, you know, token usage, you gotta be pretty mindful of these things. And so with skills or with ⁓ agent skills, excuse me, with agent skills and with MCP, you're trying to narrow that context window from a cost perspective, but also ⁓ trying to get AI doing only what you need it to do and not doing a bunch of other things. And so that... That narrowing of what is an SDK, what's needed for an SDK ⁓ has been going on before AI, but I think now with AI because of the cost implications, because it can write the code, I think that dynamic nature, I guess, of SDKs and the narrowness and the precision of it is going to hopefully get dialed in using AI. speaker-0: Yeah, that's super helpful. know, one of the things that occurs to me is we've got this longer timeline around automation, that it's not just AI, that this has been a goal for a lot of folks writing SDKs, like they want to automate this. This has been something that is part of the developer experience maybe, that this is, ⁓ I don't know, did developers just consider this drudgery, like something that didn't need to be, they didn't need to waste time on this task? speaker-1: Yeah, there's a lot of, ⁓ what do they call it? Boiler plate. A lot of redundant work that SDKs, ⁓ hopefully generating SDKs would do away with. Where you just, if you have to write your own SDK, you, you, you dread doing like it's just a lot of repetitive, repetitive work. And so, ⁓ but a lot of, there's another aspect of that is a lot of companies will, ⁓ They won't use SDKs, you know, like Bloomberg, recently worked for Bloomberg, different company are highly regulated. ⁓ Don't trust SDKs. They want to write their own code. And so that drudgery, you know, those developers dread that. So generating it from an open API, ⁓ generating the stubs as they would call it, and then hand crafting just, you know, so generating the, the, the really boring work. And then, and then doing the artisan crafting of, of exactly, you know, the business logic and what happens. That's pretty common. ⁓ And then another thing we haven't talked about is. Multi-protocol aspect, meaning, you know, there's different flavors of APIs rest and HTTP is king, but you've got graph QL. You've got a event driven, you've got Kafka, you've got web sockets you've got, and those all have SDKs and sometimes. your SDKs have to be multimodal, meaning you start with HTTP and you switch to WebSockets for a live stream. ⁓ You might be doing request response and then you go to a long-lived sustained connection, which MCP is. MCP is a dedicated connection. And so your SDKs need to be multimodal as well as, you know, working. And so that can introduce a lot of overhead and a lot of ⁓ special work that has to happen. speaker-0: That's so interesting. Yeah, I mean, it occurs to me too that with a lot of the things that we're talking about where SDKs are involved, that there could be version drift issues and maintainability being a big part of this where it's not just like you write it and it's done. It's like you keep having to revisit this. ⁓ Is that something where the handcraftedness of this... ⁓ is working, has worked better from what you've seen rather than trying to automate it using one of these tools or even, you know, AI. speaker-1: ⁓ Yes, there's a lot of ⁓ details that have to go into the business requirements of this. And I think this is one of the reasons spec-driven development is so interesting right now is, you know, so that open API you spoke of, if it's an event-driven API, if it's Kafka, you might have an async API. You might have both. You might have a GraphQL specification in there. But now with the spec-driven kind of bundles, you might have an MCP, some agent skills in there, but you might have a PRD, meaning a product requirements definition in there that says, okay, here's why we're doing this from the business people. And that may have a RASO workflows in it. The RASO is another specification out of the open API that says, you know, You search for a product using a product API, then you place an order, then you check out. So it's got a sequence with it rather than just letting the agent or the co-pilot or the LLM figure that out. That might be in there. But if you don't have that ⁓ PRD in there, if you don't have those business stakeholders in there, ⁓ drift occurs because the business people tend to not speak open API or async API or Arrazzo and without those business requirements and product requirements, us engineers tend to just go to town creating that code, creating, generating those SDKs. And then by the time it reaches production, you've got something that's drifted, as you said, from the original intent of, of why we're doing this, how we're doing this. And so ⁓ that's what I'm betting on with Navtico and what we're building is. How do we bring that business alignment in there? How do we bring domain stakeholders, product managers, sales, support, other people into this conversation? So they're contributing to the spectrum and bundle. And that code that gets generated, ⁓ the artifacts that are in there, ⁓ all stakeholders have contributed to that. That's not just an engineer's job. And then hopefully using AI and co-pilots, can kind of check in on that throughout the life cycle and adjust and minimize that drift by the time it gets to production. ⁓ speaker-0: Awesome. And let's talk about DevTools a little bit because we're in this interesting moment with IDEs. ⁓ And you mentioned Copilot, of course, but there's a range of VS Code forks available. New things seem to be popping up all the time. And now, of course, we've moved from AI code assistance to agentic IDEs. So everything's moving very fast. But I'm interested in the relationship of IDEs and ⁓ know, APIs, SDKs, how is that entire space evolving at the same time? Like, is there a synchrony involved here where there's, as one technology improves, you know, the other one is quick to follow? I mean, I guess maybe another way of saying this is, like, do platform teams, like, even ship SDKs anymore? you know, where do we sit here? speaker-1: Yeah. I mean, would say similar to you said, ⁓ there's a lot to unpack what I said about SDKs. Yes, this space, there's many dimensions to unpack and the CLI, the SDK, the client, the interactive docs all fit into that. so, yeah, it's kind of diving into this realm a lot lately to understand what is VS code doing, but then I did a recent, pulled about 500 MCP servers to understand when someone publishes an MCP server, like Figma publishes their MCP server notion, they tend to say, hey, here's where you can use that MCP server. And they'll say VS code IDE, or they'll say cursor client slash IDE, you know? And so some people feel like the IDE is going away. I mean, if you're building a client tool, you're you're probably an AI client tool, you're probably invested in the ID going away. If you're ⁓ Microsoft and GitHub, you're probably not. ⁓ And so trying to understand how developers or engineers are using these MCP servers in their VS code, in their client, in their co-pilot, in their CLI. There's kind of a ⁓ Venn diagram of what people are using and there's not one. It's not as easy to say, oh, VS code. You used to be able to go, well, we'll just build a VS code extension. And you can't more because they could be using Claude or they could be using GitHub Copilot. And then the other part we just talked about as far as the business alignment, I interviewed, oh man, I'm dropping his name, but the product manager for Office 365 Copilot. And so a number of our customers are Microsoft shops and their engineers are on GitHub copilot. Their product managers are on Office 365 copilot. Both you can register MCP servers with as part of this API. So bypassing SDKs, MCPs kind of becoming an SDK in that respect. So you can help your clients. Now the other part is back to the interactive docs is when I talk to Microsoft about this, said, we're, we're not just giving you, know, if you're building a, ⁓ something on teams, ⁓ and, and office, so you have files and meetings, that's the core resources you're developing around. We're actually going to give you the documentation alongside that meaning. So MCP is, has tools. So think of the APIs like meetings and files. It has what's called resources, another layer, which is. how do you use those files and how do you use those meetings? How does the Microsoft Teams API works? That's in your docs. And then it has a set of prompts, the third layer is prompts. So you have tools, resources and prompts bundled as an MCP going to Office 365 and going to GitHub Copilot. And so I have to, as an API producer who used to generate SDKs in multiple programming languages, and publish docs to a portal and publish those SDKs to a portal in multiple programming languages. I'm now bundling it all as MCP and injecting it into the developer lifecycle via their client ID code or CLI, as well as trying to align the business stakeholders to reduce that drift by injecting MCP into their product management realm. And I'm exploring how do you do that with Figma and ⁓ Notion and other things so that you can kind of align all of these worlds and bridge that classic kind of IT product divide that exists using MCP. So if I was to put on that, how I would go, yeah, SDKs are going away. Look at this amazing new, you know, but then, you know, as soon as I get on that train, agent skills happen and there's a whole other, you know, I don't need SDKs now I can generate skills and align using skills. I don't know, you know, I would say I tend to ground it in the conversations I'm having with large enterprises who are, you know, procter and gambles of the world, the, you know, who are still trying to get off SAP. Yes, they're excited by AI, but they're still trying to do these other things and there's, know, so SDKs aren't going away anytime soon, but. there are new exciting ways to think about it. speaker-0: Okay, yeah, that's awesome. I know, I haven't brought up my favorite keyword, my favorite neologism of the era, which is vibe coding, but I will. So yeah, I like that we're sticking with the enterprise story first, how AI features into that, that maybe we'll kind of move into that fun stuff. ⁓ Okay, but I think all of this is pointing to the fact that historically, SDKs were optimized for human developers, right? But now we have AI agents that are increasingly the consumers of APIs. So I'm curious, what... What an SDK for agents look like? speaker-1: Yeah, so you hit on another little nuance there when you, that's kind of a, know, SDKs were made for humans, you know, and that's a common thing you hear in the API space. I would push back on a little bit is SDKs early on used what's called hypermedia ⁓ and they were meant to be automated, meaning they had hypermedia link. SDK would just. speaker-0: Great. speaker-1: follow and navigate and act like the web. didn't need the human to program every API endpoint in it. was ⁓ hypermedia using JSON-LD, how there's a bunch of hypermedia formats. And when you generate an SDK from that, you didn't need a human to do that. Now what happened along the way is enterprises said, well, there's a lot more overhead cognitive load with producing the APIs as well as generating these SDKs that didn't need humans. It's actually cheaper to just have humans do this work than to actually invest in hypermedia and build off of this core concept of the web and how automation works, media types. There's a lot of automation baked into the web that is kind of taken for granted now. People don't know about it, but SDKs were automated and didn't need the humans in there. But because of labor and because of costs, we chose, it's cheaper to pay developers to do this. Now you think of what's going on with coding and, and labor and, know, developers are going to go away, you know, right. You know, you hear a lot of that. And so I don't really, you know, buy that as far as developers may not write the code or write the SDK, but they're still there as a human in the loop kind of aspect of how SDKs. if we can still call them SDKs. mean, MCP is kind of a client slash SDK. There's still code, there's still artifacts, skills, you know, are still have a lot of SDK-ish like files and scripts and things that run in them with a set of human instructions that are more human readable. And so you're still gonna have humans in there. ⁓ But then is it a SDK? PDKs as I would call them platform development kits that are meant for specific platforms like Salesforce or things like that. So I think just the concept of a developer kit, if we drop the S I guess, you know, with MCP and skills, I think what is a developer kit is gonna shift, but you're gonna have that human in the loop. But then what does the agentic part of that, like how much of that can we offload to agents? And so it's an agent development kit as well as a human developer kit. So I don't know, you got to kind of balance those worlds, I guess. speaker-0: Wow. So are you advocating for some new vocab around this? speaker-1: I mean, I'm a writer, storyteller. I actually don't care about APIs. I don't care about AI. like telling stories. I like words. I like mythosaurus. So yeah, I'm all about inventing new words, but in meaningful ways, not like cloud or AI where it's kind of meaningless. I like being a little more precise if I can. So yeah, new words are great. speaker-0: How fantastic. And what you're making me think of with this ⁓ part of our conversation. And let me just say that that last explanation, I feel like was the most illuminating for me, just in the sense of like, I feel like that's where I was stuck in this swamp of confusion around where APIs are going to be the most useful as we move towards having agents more involved in the SDLC. Because I think it just ties back to this idea, the relationship between AI and determinism. And I keep hearing those words joined, often by marketers. ⁓ But I understand that it's something that the developers need. Like we're going to have to have more deterministic ways of interacting with AI. ⁓ But AI can never be deterministic, of course. So it is just, it signals this discomfort, this place that we're at in trying to integrate LLMs into our workflows. That is just going to be attention. Until we move away from the transformer model, there's just no way that we can eliminate having some non-deterministic parts of ⁓ what we're doing with code. And it seems to me that APIs and the specs that you're pointing to, these are just inherently deterministic, that they require clear parameters. ⁓ Have you thought about this determinism thing? Am I off base here with seeing this connection? speaker-1: on with the spectrum and development. I am not that excited about AI and and agenda and all of this. Okay. I'm always admit it. I really don't care about AI and I actually have other concerns you know that we won't go into on this you know when it comes to right energy environment all those things but ⁓ I'm an I'm an interface expert. This is what I do is is I you know application programming interfaces. I don't care how you're applying it. I didn't go too deep down the mobile rabbit hole, know, learning Swift and iPhone and Android and I stayed at the line, but I provided APIs. Same with device. I didn't get on the IoT training, you know, too heavily, but I delivered MQTT APIs and event-driven and things that devices use. I'm the same with AI, you but I have to go a little bit down the rabbit hole and poke my head in and play around and understand how things work. But I stay in an interface land. I'm about interfacing and providing the resources, the events and other things that you're going to need for any type of application and specifically across applications. So I'm not just saying everything's going to be AI. And determinism and non-determinism is kind of that line I'm walking right now. And OpenAPI and AsyncAPI, which describe the surface area of your request response and your event-driven APIs, which are the majority, ⁓ those both use JSON schema to describe the payloads, the request and the response, the messages, as well as validate your entire spec itself. it valid? And so I use Claude heavily. ⁓ for generating specs and iterating on specs and generating examples. Like I'll take Notion API, which has an open API. I'll generate the open API because Notion doesn't maintain their own. I will generate it from their docs and say, Claude, go generate that open API for me. Now I use JSON Schema to validate that open API that it works. And then I will fire it up with a client. make calls to each API endpoint and then use JSON schema to validate the requests and the responses. And then I certify that whole open API and that's very deterministic. It's repeatable. I know it works. And so I use that pretty heavily. And then I'll take Claude and say, okay, we'll generate a bunch of examples for the Notion API for a graphics design team or maybe a real estate company. And then I'll again. I will validate them with JSON schema that what Claude gave me back is validated. And so walking that line between where you can use, where you need determinism or non-determinism is very, very important to maintaining our sanity. For me, my sanity, but also the business value of this and making sure it works and does what you need and like generating descriptions for my open API. Claude's great at that. There's lots of parts and pieces I will use. The examples, I said, synthetic data, I love doing that. But if I can't validate it with JSON schema, or now there's a new format called JSON structure, it's out of Microsoft, I use it as well. I don't depend on, I don't use Claude to write my stories or write my, I don't even use it to edit. In some cases I do, but that... deterministic and non-deterministic line and being able to validate, that's at the heart of spectrum and development. And I feel like that's going to be the future here as kind of AI shrinks back down to realistic, you know, levels of where's the actual business value or the enterprise. Cause you got to validate and you got to be able to make sure this is repeatable. Even when it's non-deterministic, it's got to be repeatable within a certain scope. speaker-0: So where do you think that this should be happening in the stack? this, do we need like a new abstraction layer to help this, you know, succeed? speaker-1: Yeah, I'm trying to figure that out. You know, I don't have a really good answer. would say, you know, that's the only area where the skills and MCP kind of excites me is in the Office 365 and the GitHub copilot kind of bridging the business, the product and the engineering divide is, you know, that abstraction layer live in there that there's. I don't want to call it human in a loop, but I guess it kind of is, like, you know, when things are happening, you're asking the product manager, is this what you intended, you know, to minimize that drift? Doing it, excuse me, for the same for the developers. And so I'm trying to figure out what that abstraction layer looks like. ⁓ But I just can't imagine it's going to entirely live within co-pilots. I kind of. From what I learned doing API governance and at Bloomberg a year or so ago is you kind of got to bake things into whatever tool people have already kind of bought into. Meaning if you're in Office, you're using Office 365. But if you're a Notion, know, Notion is kind of your universe if you're Git, you're GitHub or GitLab. And then, so you got to kind of pick the tool. And I think using that tool's APIs, you... inject back whatever's needed from this abstraction layer. You talk about this kind of real time that we're iterating software throughout the life cycle, that it's pinging Notion, it's pinging Office 365. And some of it's co-pilots, some of it's not. Some of it's just notifications, Slack, know, Teams, Discord, those are big ones. Can you, you know, as agents are doing things, as engineers are doing things, as product managers, can you... ping people in Slack and then give them just a snackable context, you know, things to say this, yes, that looks right. Yes, that looks right. Yes, we're heading the right direction. No, no, that's a bad idea. Don't do that. Stop. You know, and so I think that abstraction layer can't be a new tool or a new abstraction layer. think it's got to speak to our existing investments and ⁓ and what we've already bought into. Cause that is the hardest thing. Like trying to get people change behavior is the hardest part. And and all the apps we use already have API. So can this abstraction layer just, you know, real time inject things into that. And that's going to, some of it's going to be co-pilot and AI, but I don't think it can all be that. think message apps are going to be a big one and productivity apps, other things. speaker-0: Yeah, that resonates with what I'm hearing as well. The ecosystem, hard to beat that. Okay, I want to dig into the idea of governance because we've been beating around this issue here. I guess the way that I want to ask this is if developers are increasingly generating SDK calls through AI copilots, ⁓ how does that affect API governance and usage patterns? speaker-1: Yeah, great question. That's a tough one. really trying to handle, so just my career trajectory, I did four years at Postman, went from Series A through Series D, you did the four years. then I had my podcast Breaking Changes there where I was talking to NBA, 7-Eleven, lots of great companies about what they need when it comes to APIs. And I kept hearing the two top things is we need this product alignment with engineering. gap, this drift that's causing us so much pain. And then two, governance. How do we govern this? And so when I got done at Postman, I poked my head up on the web at API product management and governance. Bloomberg came up and they had a job that said, hey, we need API governance. I was like, all right, I'll go there. And so I did about 13 months there standing up an API governance program that involved, aligned with product management. as well sales and support. So it's really got a key piece of that. ⁓ governing REST API is GraphQL, Kafka across ⁓ a very flat organization. ⁓ How do I say it? Tribes that don't always get along that are very different. You know, the quant group is very different than the media group. The buy side and the sell side of stocks can't talk to each other legally. can't. share any information or work together or coordinate because they're on buy side and sell side of a heavily regulated industry. So how do you govern that and how do you think about that? And what I said about the injecting into people's ⁓ apps they already use, that was how I kind of moved the needle forward is everything I did was artifact driven in Git. didn't do any apps because there's so much ideology and dogma associated with apps and why we bought this app, why we use Office 365, why we use GitHub or why we built it ourselves. A lot of companies I work with have built stuff on their own. So injecting into those is how I was able to govern. Now for me, governance, if you say governance with large enterprises, It's kind of an enforcement thing, meaning, all right, how do we have rules and policies and how do we enforce them in the pipeline? That's kind of where a lot of people start with it. I'm a big fan of shifting that left to use another overused phrase in the school. How do you get developers to do that as early on so they're thinking about what support cares about, but not after the fact or security thinks about? ⁓ how do you shift that left? But for me, governance is guidance. And my API evangelist newsletter is called weekly API governance parentheses guidance. Cause you got to guide developers to do the right thing. No one cares about governance. No one reads the docs, reads the rules. No one cares about the level I do. ⁓ there's always just a very finite group of people who will argue about. Do you version in the path or do you version in your headers? Like no one cares. And you're going to, you're going to beat yourself up trying to get people to care. You just can't. So you got to guide them. You got to put guard rails in. You've got to, ⁓ and I used to do that with like VS code extensions, IntelliSense, you know, auto complete. Here's the right path. Here's the right schema. Here's the right naming convention. Here's how it works. And now doing that with with ⁓ skills and Claude.md, that kind of spectrum of MD files that have kind of, that are on the, they're in Git, but they're also in our IDs and their local and the co-pilots and reading those. So there's rules.md, there's Claude.md, there's a whole bunch. There's sol.md, there's all these MD files now that kind of are, and this is for me, this is the, ⁓ This is the politics of it. This is what, this is what everyone's fighting for. know, 10 years ago, the spec open API one, but there's ramble, there's API blueprint, there's WSDL, there's Smithy out of my Amazon, there's spec, ⁓ type spec out of Microsoft. There's everyone was battling for the mind share ⁓ of that spec that's been amplified with AI and the MD files are kind of that. So. I'm still trying to figure out what governance is and the client, the SDK generation, the IDE, everything we talked about kind of feeds into that skirmish, that front line of what is governance, what is guidance, what are guardrails. And the MCP injecting the docs, I'm injecting rules now and policies using MCP in the same way, using the MCP resources and prompts. ⁓ and so governance is guidance to me, but it's, it's also gotta be deterministic and repeatable. ⁓ so that, you know, people, and I'm hoping that, and I haven't gotten too much thinking on this is how do we get business stakeholders and leadership through co-pilots and through the tools, the dashboards they already use to kind of, well, ⁓ shift what governance looks like, what that guidance is as this ship, you know, they're trying to turn the massive enterprise ship left or right. They need to dial in what some of those policies are, how important security is, you know, kind of manage that cost, risk, velocity kind of equation based upon policies and it's got to trickle down to in the ID, in the client, in the SDK. So you shouldn't be able to generate an SDK that doesn't ever use HTTPS encryption. That's like You cannot do that because security is priority. ⁓ that sounds silly, but that doesn't exist today for a lot of organizations. are plenty of API calls being made that don't use encryption. So ⁓ governance is critical, but ⁓ it's a tough landscape to try to figure out and implement at scale for a global enterprise company right now. speaker-0: Yeah. And I'm glad you brought up the security issue because I think the misuse of APIs is something that a lot of folks who are concerned about the relationship between APIs and AI are worried about, ⁓ I mean, yeah, there's so many ways that APIs could be misused, right? Rate limit abuse, undocumented features, and with AI, right, hallucinations. There's so much. ⁓ actually am wondering if you've approached this, if you've flipped this ⁓ question that we've been grappling with today. Are we heading toward a world where API providers need to design for AI misuse rather than human misuse? speaker-1: Yeah, I mean, ⁓ yes, we do. ⁓ But that's not new, I would say governance. OK. Backgate has been focused on getting producers of APIs to behave in the right way, design in the right way. And that doesn't always happen. ⁓ And so I've seen a lot. I've seen. banks come together as consumers and go to an API provider and say, your APIs suck, half of them are insecure, your documentation sucks, your reliability, and those providers just don't care. ⁓ And I've seen lawsuits be threatened from the consumer side. And so I'm a big believer in that a lot of this is going to happen, have to happen, this governance is going to happen from the consumer side. And that's really 2010 through 2019, I wrote the API management producer side of things. So Apogee, Mastery, MuleSoft, producers of API gateways. That was kind of my, what I wrote and was part of. When I went to Postman, Postman's a client about the consumer. They're testing focused, but we're trying to elevate that with a platform story. ⁓ There's a lot of power in the consumers. We saw that with developer power kind of evolving. ⁓ There's a lot of power at the consumer level. The problem is that's not what startups sell to you. That's not the lion's share of Silicon Valley selling to API consumers. But an API doesn't matter unless it's got consumers and people doing it. There's a lot of power there that's harnessed, aggregated, focused. ⁓ And it's very distributed and they don't know each other. there, there's no solidarity or communication. ⁓ and so I believe that a lot of this is going to have to come the governance, a lot, the, regulatory. so I've, I've worked with the European commission UK. I worked for the Obama administration on standards, APIs, fire specification for healthcare, PSD two for finance. And I believe that a lot of this governance security, lot of this is going to have to, and consistency, it's going have to come from the outside in. there's aren't always going to do the right thing. Now, whether regulation is the answer. I don't, you know, um, for some of it, yes, but I think there's going to have to be other standardization, uh, and sharing of skills or MCP designs. don't know, you know, that, Um, and this is what I'm trying to focus on it and now if Tico is how do you, you know, how do you, if you can't get 20 teams to follow the government's rules and produce APIs that are version the same, have the same security, have the same parameter naming conventions and requests and response structure. Can you put a middleware in between that and, and then translate that, make it consistent, make it secure. make it have a retry, have a rate limiting, have a cost and budget management. And so I think a lot of this alignment is going to have to come from the outside in and come from the market itself. ⁓ Producers, our API producers are just trying to do the best they can with very short staff ⁓ and they don't always have the resources. don't want to... blame them and say they don't care. They just don't always have the bandwidth and the resources to do it the right way or the education and awareness, like what is the right thing? And so I think a lot of this is going to come from the outside in. speaker-0: Right. Yeah. And I don't think it's unusual to point to the short shrift that security and QA often get in teams, right? So ⁓ I don't think that's controversial. I have one last question for you because as I predicted, I knew this conversation was going to be super interesting. so the one that I absolutely do have to ask you about though is the shifting, I guess, role of developers or maybe identity of them. So I mentioned Vibe Coders, of course, but there is a whole new quotient of folks who are using APIs now. And that's exciting in a lot of ways, but it also presents some challenges. so I am, I guess I'm interested in, so if developers increasingly rely on AI to generate API calls, are we at risk of these new developers who are entering the fray? losing an understanding of the underlying API surface through the complexity of it or vendor lock-in even, or they're unable to debug what they've done, right? So there's this opacity that maybe former generations of developers haven't grappled with. speaker-1: Yeah, I would say it's not a new thing. I I'm not a classically trained programmer. I didn't go to university or school to be a programmer. I can program in pretty much any language. I'm not dogmatic about any one of them because I'm not classically trained. And I would say I'm ⁓ a view source programmer, meaning 2001, I would hit view source. How did they do that? And reverse engineer the JavaScript and what's going on? And then I went down the rabbit hole. and became a programmer and started using APIs. Now, as the API evangelist, I've always been a big advocate that everyone should be aware of APIs. And like, you don't have to understand OAuth, you don't have to understand REST, but as a user, if you wanna be more in control of your professional career, you should know that APIs exist and power users are what made a lot of APIs. the media users made Twitter what it was. The power users that wrote for the New York Times and wrote, they could make buttons, badges, widgets, share things. They were using APIs. And so I am a believer that everyone should understand APIs. Now, there's a lot going on there. should unpack people. Not everyone should program against APIs. So there should be clients. There should be what we're doing with co-pilots. Now, a lot of providers feel that there are secret sauces in there, like getting people to share their open APIs, a company has been like pulling teeth. I've had entire IT groups walk out of talks I've done because I said, oh, you should put a link to your open API on your docs page. They're like, we're not going to give away the keys to the kingdom. you you're, you're insane that you're telling us to give away the every path, every parameter, how we handle keys and tokens. And I'm like, Look, if you ain't got that shit secured, I'm sorry, didn't mean to curse, but you you're in trouble. Like if that's a problem, you've got other problems than what we're dealing. So a lot of people feel this is closed. Now another, you know, series of stories around that is people hire me as a consultant to come in and go, hey, we want to talk to you about our API strategy. So before I go in, I would proxy their mobile apps and their websites. And I would print out an open API of all of their APIs. And I would go in and they're like, where'd you get this? This is private knowledge. This is private interface. I'm like, no, it's not. It's back behind your public mobile app. It's not at all private. And so I've done this for many, many groups. So many people see their APIs as proprietary, as secret sauce, as hidden behind their applications. And this is just amplified with AI, like obfuscation. We don't know what's going on and it's just further exacerbating what I've seen for 15 years already. So yeah, it's a mess, but I think people should be aware. I mean, I think more visibility, more observability, more transparency there is good. It's like open source, you know, within reason. I mean, we should be having this debate, but there's also a lot of money to be made in that obfuscation hiding things. ⁓ there's most of the reasons why people hide this and don't want people in there mucking around is just incompetency, know, incompetent. You know, they didn't program it. They're not, they don't even know what's in there. They don't want anybody to look at it. And so AI is just making that even worse. And so, ⁓ I, I, I, I'm big fan of vibe coder people on, on API's, know, I don't know about apps. I'm not going to vote on that one. I'll let y'all talk about that, but. or accessing APIs and getting access to the data you need to do your job. Hell yeah. Like, vibe code the hell out of that. Get that, learn what you need, probe, ⁓ you know, and make it as visible as possible, but it's just gonna get really bad. I don't see any light at the end of that tunnel as far as ⁓ people getting empowered. I just think it's, I mean, I'm getting confused. I'm getting lost in there and I'm an interface expert. So I don't honestly, I don't have a lot of hope that we're gonna get back to this. speaker-0: You're reminding me about the gentleman who used Claude to access like 7,000 vacuum cleaners and I believe that was, like humans had missed it, but because Claude has this superhuman visibility, he's willing to go through all these lines of code, discovered this IoT issue and was able to command what, you everybody's cameras on these robots. And yeah, it sounds like we're only going to be seeing more of that. speaker-1: Yeah. And times 10,000. speaker-0: going to be made. ⁓ geez. Yeah. OK. Well, and yes, and then also on your point about the money to be made, yeah, it's interesting. I'll tell you from Redmonk's perspective, I know that we've been briefed on some ⁓ SDKs that are coming out to facilitate getting VibeCoders to use products because there's a need for having that onboarding. And also, We can even think about it as like agent-led growth where you want to have these things visible to the agents because the agents are ⁓ increasingly choosing the developer tools that these five coders are using. ⁓ So yeah, there's a lot of interesting stuff here. ⁓ Again, I could drag this conversation out ⁓ much longer, but ⁓ I think that's probably a good place for us to stop because you had such a great CTA there, right? ⁓ Know what APIs you're using. Don't just treat it like this opaque thing. So in terms of other CTAs though, where do you direct folks, who are interested in following more of your hot takes and deeply held beliefs here? speaker-1: Yeah, so I'll split that into two directions. it's enterprise scale doing this ⁓ for grownups, market-driven industry-led government, navtico.io is the startup I'm building, building integrations addressing a lot of what we're talking about. If you're looking for the juicier, more opinionated ⁓ version of the same, go to ⁓ apievangelist.com. been writing there for 15 years. There's over 5,000 blog posts and I don't hold back. I'm known for being pretty vocal and being pretty opinionated about how I feel about this stuff, pretty transparent. So it depends on what you've got the appetite for. Navtico for the business enterprise version, API Evangelist if you want to get the raw version of what's going on. speaker-0: Fantastic. All right. So again, my guest today has been Ken Lane. My name is Kate Holderhoff. I'm a senior analyst at Redmonk. If you enjoyed this conversation, please like, subscribe, and review the MonkCast on your podcast platform of choice. If you're watching us on Redmonk's YouTube channel, please like, subscribe, and engage with us in the comments.