SDKs in the AI Era with Kin Lane (RedMonk MonkCast)

Hi there, Kate Holterhoff here. I’m a senior analyst at RedMonk, and my guest today is Kin Lane. He’s the co-founder and chief community officer for Naftiko, although he’s probably best well known for being the API Evangelist. So, Kin, it’s an absolute pleasure to welcome you on the MonkCast.

Pleasure to be here, Kate. Thanks for having me. Big fan of what you guys do, so honored to be here.

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. 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?

Yeah, the SDK evolution and kind of journey is long, and I would say there’s many layers to it, but you’ve got to start with APIs, because application programming interface — more specifically REST or HTTP APIs — is 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, I 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 a software development kit. So 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. And 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.

Okay. And so it is not incorrect to say that SDKs are still the primary interface for APIs?

Yes and no. I mean, it depends on where you come from — that’s a great question. 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. It’s, say, a browser for APIs 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 the CLI is kind of having a resurgence — is some developers prefer to work with APIs through a CLI, or a command line interface, and it will work directly with the 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. So 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: a lot of APIs will generate documentation, and 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 know, 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 going 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, and that’s how it works.

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 MonkCast not long ago talking about AI slop, which actually 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, an 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 OpenAPI specs directly, does the SDK start to become optional at this point?

Yeah, yeah. And there was another nuance there — you said OpenAPI, and, you know, what I said before is OpenAPI is often used to generate that interactive documentation that I told you about. Swagger UI is one of those. Postman and clients use OpenAPI to generate what’s needed for the client, and then same for the CLI. So OpenAPI 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. And I’ve seen lots of people say, you know, SDKs are going to go away because OpenAPI 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 know, you have that OpenAPI, and your AI can usually generate that — like it can read documentation and then generate the OpenAPI for you — but it can also take that OpenAPI 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 it could potentially reduce that context window down. Meaning, Stripe’s OpenAPI has — oh gosh, I 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 Claude or wherever you’re doing your AI integration, you just need that payments. And if you feed that whole OpenAPI to Claude, 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, you know, 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.

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 handcrafting SDKs because the generated ones just aren’t — they’re not feeling right at this point — would you say that the SDKs that we’re seeing on the market, maybe, that are being introduced and aren’t quite as established — you know, how are they different than ones that have come out before? Like, what sort of changes have you seen in the realm of vendor-created SDKs?

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. So the design and the surface area of the API is going to, you know, speak to how I would answer your question. If there’s certificates and there’s a sophisticated auth, that SDK is needed. It’s 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. Like I said, the OpenAPI 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. And you started seeing this even before AI started shifting: Microsoft has an SDK generation tool that generates using OpenAPI called Kiota, and it’ll let you pick from that menu. It’s like, you know, you just want hamburger, shakes, and fries — you don’t want the full… 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: just give me what I need, make it as fast and quick as possible. And then there’s, you know, the design of the API, meaning what you need from the response. It may be a big JSON blob and you just need, you know, three fields from it, but your SDK is returning all of that. And for AI, you know, token usage — you’ve got to 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 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.

All right, yeah, that is super helpful. You 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. Did developers just consider this like drudgery — like something that they didn’t need to waste time on, this task?

Yeah, there’s a lot of, what do they call it, boilerplate — a lot of redundant work that SDKs, hopefully generating SDKs, would do away with. Where, if you have to write your own SDK, you dread doing it — like, it’s just a lot of repetitive work. But there’s another aspect of that: a lot of companies won’t use SDKs. You know, like Bloomberg — I recently worked for Bloomberg — different companies that 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 OpenAPI — generating the stubs, as they would call it — and then handcrafting, you know… so generating the really boring work and then doing the artisan crafting of exactly, you know, the business logic and what happens — that’s pretty common. And then another thing we haven’t talked about is the multi-protocol aspect, meaning there’s different flavors of APIs. REST and HTTP is king, but you’ve got GraphQL, you’ve got event-driven, you’ve got Kafka, you’ve got WebSockets — 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 well as, you know, working. And so that can introduce a lot of overhead and a lot of special work that has to happen.

Oh, 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 like version drift issues, and like maintainability being a big part of this, where, you know, 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 has worked better, from what you’ve seen, rather than trying to automate it using one of these tools or even, you know, AI?

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. You know, so that OpenAPI you spoke of — if it’s an event-driven API, if it’s Kafka, you might have an AsyncAPI. You might have both. You might have a GraphQL specification in there. But now, with these 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 Arazzo workflows in it. Arazzo is another specification out of the OpenAPI that says, you know, you search for a product using the 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 copilot 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 OpenAPI or AsyncAPI or Arazzo. 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 why we’re doing this, how we’re doing this. And so that’s what I’m betting on with Naftiko and what we’re building: 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 spec-driven 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 copilots, we can kind of check in on that throughout the life cycle and adjust and minimize that drift by the time it gets to production.

Awesome. And let’s talk about dev tools 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, you know, new things seem to be popping up all the time, and now of course we’ve moved from AI code assistants to agentic IDEs, so everything’s moving very fast. But I’m interested in the relationship of IDEs and, you know, APIs, SDKs. How is that entire space evolving at the same time? Like, is there synchrony involved here, where as one technology improves, the other one is quick to follow? I guess maybe another way of saying this is like, do platform teams even ship SDKs anymore? Like, where do we sit here?

Yeah. I would say, similar to what you said — oh, there’s a lot to unpack — about what I said previously 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. And so, yeah, I’ve been kind of diving into this realm a lot lately to understand what is VS Code doing. But then I did a recent — I 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, IDE, you know. And so some people feel like the IDE is going away. I mean, if you’re building a client tool — an AI client tool — you’re probably invested in the IDE 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 copilot, in their CLI — there’s kind of a Venn diagram of what people are using, and it’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 go. No 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, now I’m dropping his name — 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 — MCP is kind of becoming an SDK in that respect. Now, the other part is, back to the interactive docs: when I talked to Microsoft about this, they said, well, we’re not just giving you, you know — if you’re building something on Teams 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, MCP 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; you know, how does the Microsoft Teams API work — 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, 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 life cycle via their client, IDE, 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 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 hat, I would go, yeah, SDKs are going away — look at this amazing new… 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. So, I don’t know. I would say I tend to ground it in the conversations I’m having with large enterprises — who are, you know, the Procter & Gambles of the world, 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 so SDKs aren’t going away anytime soon, but there are new, exciting ways to think about it.

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. Then 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 does an SDK for agents look like?

Yeah, so you hit on another little nuance there. That’s kind of a, you know, “SDKs were made for humans” — that’s a common thing you hear in the API space, and I would push back on it a little bit.

Oh, great.

SDKs early on used what’s called hypermedia, and they were meant to be automated, meaning they had hypermedia links the SDK would just follow and navigate, and act like the web. It didn’t need the human to program every API endpoint in it. It was hypermedia using JSON-LD — 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 cost, we chose: no, it’s cheaper to pay developers to do this. Now, you think of what’s going on with coding and labor — and, you know, developers are going to go away, right? You hear a lot of that — and I don’t really buy that. 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 — work. I mean, MCP is kind of a client SDK. There’s still code, there’s still artifacts. Skills, you know, 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 going to have humans in there. But then, is it an SDK? There’s 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 a developer kit is is going to shift, but you’re going to have that human in the loop. But then, what does the agentic part of that look like — like, how much of that can we offload to agents? And so it’s an agent development kit as well as, you know, a human developer kit. So, I don’t know — you’ve got to kind of balance those worlds, I guess.

Wow. So are you advocating for some new vocab around this?

I’m a writer, storyteller. I actually don’t care about APIs. I don’t care about AI. I like telling stories. I like words. I like my thesaurus. So yeah, I’m all about inventing new words, but in meaningful ways — not, you know, not like “cloud” or “AI,” where it’s kind of, you know, meaningless. I like being a little more precise if I can. So yeah, new words are great.

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, I feel like that’s where I was stuck in the 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 of 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 just signals this discomfort, this place that we’re at in trying to integrate LLMs into our workflows, that is just going to be a tension. Like, 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 these 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?

Spot on, with the spec-driven development. I am not that excited about AI and agents and all of this — I’ll 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 — right, energy, environment, all those things. But I’m an interface expert. This is what I do — application programming interfaces. I don’t care how you’re applying it. I didn’t go too deep down the mobile rabbit hole, you know, learning Swift and iPhone and Android — I stayed at the line, but I provided APIs. Same with devices — I didn’t get on the IoT train, you know, too heavily, but I delivered MQTT APIs and event-driven and things that devices use. I’m the same with AI. You know, 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 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: is it valid? And so I use Claude heavily for generating specs and iterating on specs and generating examples. Like, I’ll take the Notion API, which has an OpenAPI — I’ll generate the OpenAPI, because Notion doesn’t maintain their own. I will generate it from their docs and say, Claude, go generate that OpenAPI for me. Now, I use JSON Schema to validate that OpenAPI, 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 OpenAPI. 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, generate a bunch of examples for the Notion API for a graphic design team, or maybe a real estate company. And then, 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 just the business value of this, and making sure it works and does what you need. And like generating descriptions for my OpenAPI — Claude’s great at that. You know, there’s lots of parts and pieces. I will use the examples, like 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 use Claude to write my stories or write my, you know — 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 spec-driven 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 at the enterprise. Because you’ve got to validate, and you’ve 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.

So where do you think that this should be happening in the stack? Like, do we need a new abstraction layer to help this, you know, succeed?

Yeah, I’m trying to figure that out. You know, I don’t have a really good answer. I would say, you know, the only area where the skills and MCP kind of excites me — and the Office 365 and the GitHub Copilot, kind of bridging the business, the product, and the engineering divide — is, you know, does that abstraction layer live there? I don’t want to call it human in the 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, 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 copilots. I kind of — from what I learned doing API governance at Bloomberg a year or so ago — you kind of have 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 Notion, you know, Notion is kind of your universe; if you’re Git, you’re GitHub or GitLab. And so you’ve got to kind of pick the tool, and I think using that tool’s APIs, you inject back whatever is 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 copilots, some of it’s not. Some of it’s just notifications — Slack, you know, Teams, Discord, those are big ones. Can you, as agents are doing things, as engineers are doing things, as product managers — can you ping people in Slack and then give them just snackable context, you know, things to say: yes, that looks right; yes, that looks right; yes, we’re heading in the right direction; no, no, that’s a bad idea, don’t do that, stop. And so I think that abstraction layer can’t be a new tool or a new abstraction layer. I think it’s got to speak to our existing investments and what we’ve already bought into, because that is the hardest thing — trying to get people to change behavior is the hardest part. And all the apps we use already have APIs. So can this abstraction layer just, you know, real-time inject things into that? And some of it’s going to be copilots and AI, but I don’t think it can all be that. I think messaging apps are going to be a big one, and productivity apps, other things.

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. But 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?

Yeah, great question. That’s a tough one I’m, you know, really trying to handle. So, just my career trajectory: I did four years at Postman — went from Series A through Series D during the four years — and I had my podcast, Breaking Changes, there, where I was talking to, you know, the NBA, 7-Eleven, lots of great companies about what they need when it comes to APIs. And I kept hearing the two top things: we need this product alignment with engineering — this 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 — they had a job and 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 aligned with product management as well as sales and support. So that’s really a key piece of that. But governing REST APIs, 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 — they can’t share any information or work together or coordinate, because they’re on the 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 injecting into people’s apps they already use — that was how I kind of moved the needle forward. Everything I did was artifact-driven, in Git. I 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 then 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 this: 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 what 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, parenthesis, Guidance — because you’ve 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 at 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 beat yourself up trying to get people to care — you just can’t. So you’ve got to guide them. You’ve got to put guardrails in. And I used to do that with, like, VS Code extensions, IntelliSense, you know, autocomplete: 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 skills and claude.md — that kind of spectrum of MD files that are in Git, but they’re also in our IDEs, and they’re local, and the copilots are reading those. So there’s rules.md, there’s claude.md, there’s a whole bunch — there’s soul.md — there’s all these MD files now. And this is, for me, the politics of it. This is what everyone’s fighting for. You know, ten years ago, the spec — OpenAPI won. But there’s RAML, there’s API Blueprint, there’s WSDL, there’s Smithy out of Amazon, there’s TypeSpec out of Microsoft — everyone was battling for the mindshare of that spec. That’s been amplified with AI, and the MD files are kind of that. So governance — 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 that 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 also got to be deterministic and repeatable. And I’m hoping — and I haven’t gotten too much thinking on this — how do we get business stakeholders and leadership, through copilots and through the tools, the dashboards they already use, to kind of shift what governance looks like, what that guidance is, as 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 IDE, 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, you know, because security is a priority. And, you know, it sounds silly, but that doesn’t exist today for a lot of organizations. There 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.

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, right? I mean, yeah, there’s so many ways that APIs could be misused, right? Rate limit abuse, undocumented features — and with AI, right, hallucinations. You know, there’s so much. So I actually am wondering if you’ve approached this, if you’ve flipped this sort of question that we’ve been grappling with today. So, like, are we heading toward a world where API providers need to design for AI misuse rather than human misuse?

Yeah, I mean, yes, we do. But that’s not new. I would say governance for a decade 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, you know, from the consumer side. And so I’m a big believer that a lot of this governance is going to have to happen from the consumer side. From 2010 through 2019, I wrote about the API management, producer side of things — Apigee, Mashery, MuleSoft, producers of API gateways. That was kind of what I wrote about and was part of. When I went to Postman — Postman’s a client, about the consumer; they’re testing-focused, but we were trying to elevate that with a platform story. And 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. 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 not harnessed, aggregated, focused. It’s very distributed, and they don’t know each other — like, 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 of the regulatory. And so I’ve worked with the European Commission, the UK; I worked for the Obama administration on standards, APIs — the FHIR specification for healthcare, PSD2 for finance. And I believe that a lot of this governance, security, a lot of this — and consistency — is going to have to come from the outside in. Providers aren’t always going to do the right thing. Now, whether regulation is the answer — I don’t, you know… for some of it, yes, but I think there’s going to have to be other standardization and sharing of skills or MCP designs. I don’t know, you know. And this is what I’m trying to focus on at Naftiko: how do you, you know — if you can’t get 20 teams to follow the governance rules and produce APIs that are versioned the same, have the same security, have the same parameter naming conventions and request and response structure — can you put a middleware in between that, and then translate that, make it consistent, make it secure, make it have a retry, have rate limiting, have 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. API producers are just trying to do the best they can with very short staff, and they don’t always have the resources. I 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 the awareness, like, what is the right thing. And so I think a lot of this is going to come from the outside in.

Right. Yeah, and I don’t think it’s unusual to point to, you know, 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, and the one that I absolutely do have to ask you about, though, is the shifting, I guess, role of developers, or maybe the 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. And so, I guess I’m interested in — 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, surfaced through, you know, the complexity of it, or, you know, 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.

Yeah, I would say it’s not a new thing. I mean, 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 want to be more in control over your professional career, you should know that APIs exist. And power users are what made a lot of APIs. I mean, the media users made Twitter what it was. You know, the power users that wrote for the New York Times — 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 you should unpack, people. Not everyone should program against APIs — so there should be clients, there should be, you know, what we’re doing with copilots.

Now, a lot of providers feel that their secret sauce is in there. Like, getting people to share their OpenAPIs — companies — 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 OpenAPI on your docs page. They’re like, we’re not going to give away the keys to the kingdom, and, you know, you’re insane that you’re telling us to give away every path, every parameter, how we handle keys and tokens. And I’m like, look, if you ain’t got that secured — I’m sorry, didn’t mean to curse — but, you know, you’re in trouble. Like, if that’s a problem, you’ve got other problems than what we’re dealing with. So a lot of people feel this is closed. Now, another, you know, series of stories around that: 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 would go in, I would proxy their mobile apps and their websites, and I would print out an OpenAPI 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 a private interface. And 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, but, you know, open 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. Most of the reasons why people hide this and don’t want people in there mucking around is just incompetency, you know — incompetence. They didn’t program it. 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’m a big fan of vibe coders — people on APIs. You 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 for accessing APIs and getting access to the data you need to do your job? Hell yeah — like, vibe code the hell out of that. Learn what you need, probe, you know, and make it as visible as possible. But it’s just going to get really bad. I don’t see any light at the end of that tunnel as far as people getting empowered. I just think — I mean, I’m getting confused, I’m getting lost in there, and I’m an interface expert. So, honestly, I don’t have a lot of hope that we’re going to get back.

Yes. You’re reminding me about the gentleman who used Claude to access, like, 7,000 vacuum cleaners. And I believe that was — yeah, like, humans had missed it, but because Claude has this superhuman visibility, willing to go through all these lines of code, discovered this IoT issue and was able to command, you know, everybody’s cameras on these robots. And, yeah, it sounds like we’re only going to be seeing more of that.

Yep. Times 10,000, it’s going to be…

Oh, jeez. Yeah, okay. 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 vibe coders 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 vibe 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 — like, don’t just treat it like this opaque thing. So, in terms of other CTAs, though, where do you direct folks, Kin, who are interested in following more of your, you know, hot takes and deeply held beliefs here?

Yeah, so I’ll split that into two directions. One, if, you know, it’s enterprise scale, doing this for grown-ups — you know, market-driven, industry-led, government — Naftiko.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. I’ve 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. Naftiko for the business enterprise version; API Evangelist if you want to get the raw version of what’s going on.

Fantastic. All right. So again, my guest today has been Kin Lane. My name is Kate Holterhoff. 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. And if you’re watching us on RedMonk’s YouTube channel, please like, subscribe, and engage with us in the comments.