In this episode of the MonkCast, RedMonk senior analyst Kate Holterhoff sits down with Kin Lane, API Evangelist and Co-Founder & Chief Community Officer (CCO) for Naftiko, to untangle one of the most pressing questions in developer tooling today: what happens to APIs and SDKs when AI enters the picture? Kin traces the SDK from its origins in the REST API era of 2008, through the recurring (and always premature) declarations of its death, to its current identity crisis in an age of AI co-pilots, MCP servers, and agentic IDEs. The conversation explores how OpenAPI specs are being used to shrink context windows and why AI might generate bespoke, single-purpose SDKs on the fly rather than shipping monolithic language-specific kits.
Links
Transcript
Kate Holterhoff (00:04)
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.
Kin Lane (00:20)
Pleasure to be here, Kate. Thanks for having me. Big fan of what you guys do. So honored to be here.
Kate Holterhoff (00:26)
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, love having guests on where I have a question to 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?
Kin Lane (00:55)
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. now,
AI applications. Those are meant to be kind of a cross 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 a 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. your Java developers have.
the language they know. .NET developers have the language they know. But your API should work across languages. That’s really one of the core tenants of doing APIs because you can reach a really broad audience. But as 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.
Kate Holterhoff (03:02)
Okay, and so it is not incorrect to say that SDKs are still the primary interface for APIs.
Kin Lane (03:10)
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 a, it’s say it’s 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 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 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 API. 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 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, 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 and 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 go, 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
Kate Holterhoff (05:45)
Yeah.
Got it. OK, 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 that might come up today again, too. so that really helps. OK, 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?
Kin Lane (06:36)
Yeah, yeah. And there was another nuance there. You said OpenAPI and that,
Kate Holterhoff (06:37)
Ha ha.
Kin Lane (06:43)
What I said before is OpenAPI is often used to generate those 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 CLI. So OpenAPI is a key piece of that. And OpenAPI, formerly known as Swagger, is a machine readable JSON or YAML.
Kate Holterhoff (06:51)
Yeah.
Kin Lane (07:10)
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, SDK is going to go away because
OpenAPI 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, within 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’s cause you could, it could potentially reduce that context window down meaning
Stripe’s OpenAPI 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 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.
Kate Holterhoff (09:20)
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 SDKs are, the ones 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?
Kin Lane (09:53)
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 answer, how I would answer your, your question. If, if you’re a, and there’s certificates and there’s a sophisticated auth, that SDK is, is needed. It’s a, it’s a very, usually handcrafted structured to, deal with that authentication, that security layer.
Kate Holterhoff (10:01)
Mm-hmm.
Yeah.
Kin Lane (10:26)
as well as how do you actually make requests. And so that’s something that AI is not always gonna get and understand and be able to do and the right certificates and all of that. Another is that context window is 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.
Kate Holterhoff (10:36)
Yeah.
Kin Lane (10:55)
And you started seeing this even before AI start shifting, Microsoft has a SDK generation tool that generates using OpenAPI called Kiota Kiota, Kiota. And it’ll let you pick from that menu. It’s like, you you just want, you know, hamburger shakes and fries. You don’t want the full, you know, you just want what you want. It’ll generate that SDK with the auth for you. And that’s the precursor to that.
context window that I’m, that I’m talking about is just give me what I need and make it as fast as and quick as, as, as possible. And then, then there’s, you know, the design of the API, meaning what you need from the response. 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 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 gonna hopefully get dialed in using AI.
Kate Holterhoff (12:44)
Yeah. all right, yeah, that’s super helpful. one of the things that occurs to me is, so 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?
Kin Lane (13:15)
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 dread doing like, it’s just a lot of repetitive, repetitive work. And so, but a lot of companies, there’s another aspect of that is a lot of companies will,
They won’t use SDKs, you know, like Bloomberg, I recently worked for Bloomberg, different companies 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 hand crafting just, 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, you know, 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, 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.
Kate Holterhoff (15:06)
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 has worked better from what you’ve seen rather than trying to automate it using one of these tools or even, you know, AI.
Kin Lane (15:37)
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 OpenAPI 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 Arazzo workflows in it. The Arazzo is a,
another specification out of the OpenAPI that says, you 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 async API 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 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 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 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.
Kate Holterhoff (18:06)
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. everything’s moving very fast. But I’m interested in the relationship of IDEs and
APIs, how is that entire space evolving at the same time? is there synchrony involved here where there’s, as one technology improves, the other one is quick to follow? mean, I guess maybe another way of saying this is, do platform teams even ship SDKs anymore? Where do we sit here?
Kin Lane (18:58)
Yeah. I would say similar to you said, there’s a lot to unpack 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. 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
an AI client tool, 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 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, I’m dropping his name, but the product manager for Office 365 Copilot. And so a number of our customers are,
Kate Holterhoff (20:36)
Mm-hmm.
Kin Lane (20:53)
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. you register with your clients. Now the other part is back to the interactive docs is when I talk to
Kate Holterhoff (21:15)
Wow.
Kin Lane (21:24)
Microsoft about this, said, we’re not just giving you, you 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 gonna give you the documentation alongside that, meaning, so 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? 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, for 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, their product management realm.
And I’m exploring how do you do that with Figma and a 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. So 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 & 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, you know, so SDKs aren’t going away anytime soon, but. there are new exciting ways to think about it.
Kate Holterhoff (23:52)
OK, 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. OK, 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 curious what does an SDK for agents look like?
Kin Lane (24:24)
Yeah. So you hit on another, a little, little nuance there when you, that’s kind of a, you know, SDKs were made for humans, you know, and that’s a, that’s a common thing you hear in the API space. And I, 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, they had hypermedia link relations and your SDK would just.
Kate Holterhoff (24:38)
Yeah. great.
Kin Lane (24:53)
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 it, you didn’t need a human to do that. Now what happened along the way is enterprises said,
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 like 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 human
in there, but because of labor and because of costs, we chose no, it’s cheaper to pay developers to do this. Now you think of what’s going on with coding and, and labor and, you 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.
Kate Holterhoff (26:00)
Mm-hmm.
Kin Lane (26:15)
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 going to have humans in there. But then is it a 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 is a developer kit is gonna shift, but you’re gonna have that human in the loop But then what does the agent take 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 gotta kinda balance those worlds I
Kate Holterhoff (27:21)
So are you advocating for some new vocab around this?
Kin Lane (27:25)
I mean, I’m a writer, storyteller. 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 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.
Kate Holterhoff (27:47)
Fantastic. And what you’re making me think of with 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 this swamp of confusion around where APIs are be the most useful as we move towards 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
this place that we’re at in trying to integrate LLMs into our workflows. That is just going to be a tension 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? Great.
Kin Lane (29:10)
You’re spot on with the spect-driven development and I am not that excited about AI and agentic and all of this. I’m openly always admitted I really don’t care about AI and I actually have other concerns that we won’t go into on this when it comes to right energy, environment, all those things. But I’m an interface expert. This is what I do is I
Kate Holterhoff (29:19)
Okay.
Alright.
Kin Lane (29:38)
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, 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, with, with AI, you know, 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 gonna need for any type of application and specifically across applications. So I’m not just saying everything’s gonna 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 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. 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 will, again, I will validate them with JSON schema that 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 OpenAPI. Claude’s great at that. You know, there’s, lots of parts and pieces. 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 spect-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 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.
Kate Holterhoff (33:17)
where do you think that this should be happening in the stack? Like, this, do we need like a new abstraction layer to help this, you know, succeed?
Kin Lane (33:25)
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.
Kate Holterhoff (33:29)
Okay.
Mm-hmm.
Kin Lane (33:51)
I don’t want to call it human in a loop, but I guess it kind of is, 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? I’m 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 in,
and what we’ve already bought into. Because that is the hardest thing. Trying to get people change behavior is the hardest part. And all the apps we use already have APIs. So can this abstraction layer just real time inject things into that? some of it’s going to be copilot and AI. But I don’t think it can all be that. I think message apps are going to be a big one, and productivity apps, other things.
Kate Holterhoff (35:47)
Yeah.
Yeah, that resonates with what I’m hearing as well. The ecosystem, hard to beat I want to dig into the idea of governance because we’ve been 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 co-pilots, how does that affect API governance and usage patterns?
Kin Lane (36:38)
Yeah, great question. That’s a… It’s a, it’s a tough one. I’m really trying to handle it. So just my career trajectory, I did four years at Postman went from series eight through series D did you do the four years? And then I had my podcast breaking changes there where I was talking to, know, NBA, seven 11, lots of great companies about what they need when it comes to API’s. And I kept hearing the two top things is 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 I, when I, when I got done at Postman, I poked my head up on the web.
API product management and governance. Bloomberg came up and 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 involved was aligned with product management as well as sales and support. So it’s, it’s really got a key piece of that. But, um, governing rest API is GraphQL Kafka across, um, a very flat organization. Um,
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 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. 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 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 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 gotta 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 gonna beat yourself up trying to get people to care. You just can’t. So you gotta guide them. You gotta put guardrails in. You’ve gotta, and I used to do that
like VS Code extensions, IntelliSense, know, autocomplete. Here’s the right path. Here’s the right schema. Here’s the right naming convention. Here’s how it works. now doing that with, with skills and CLAUDE.md that, 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 IDE and their local and the co-pilots and, and,
reading those. there’s rules.md, there’s CLAUDE.md, there’s a whole bunch. There’s SOUL.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. 10 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 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, how do you…
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 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 kinda, well, shift what.
governance looks like, what that guidance is, as the 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 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 that 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.
Kate Holterhoff (43:13)
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, Rate limit abuse, undocumented features, and with AI, right, hallucinations. There’s so much.
Actually, I’m wondering if you’ve approached this, if you’ve flipped this question that we’ve been grappling with today. So are we heading toward a world where API providers need to design for AI misuse rather than human misuse?
Kin Lane (43:57)
Yeah, I mean, yes, we do. But that’s not new. 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 banks come together as consumers.
Kate Holterhoff (44:05)
Okay.
Kin Lane (44:27)
and go to an API provider and say, your API 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 in that a lot of this is gonna happen, have to happen, this governance is gonna happen from the consumer side. And that’s…
Really, 2010 through 2019, I wrote the API management producer side of things. So Apigee, Mashery, 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. And there’s a lot of power in consumer.
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 not harnessed, aggregated, focused, and 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 gonna have to come to governance, the regulatory. And so I’ve worked with the European Commission, UK. I worked for the Obama administration on standards, APIs, FHIR (Fast Healthcare Interoperability Resources) specification for healthcare, PSD2 (The Revised Payment Services Directive) for finance. And I believe that a lot of this…
Governance security a lot of this is gonna have to inconsistency. It’s gonna have to come from the outside in and And there’s aren’t always gonna 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 gonna have to be other standardization and sharing of skills or MCP designs, I don’t know, know that that
Um, and this is what I’m trying to focus on at Naftiko is how do you, you know, how do you, if you can’t get 20 teams to follow the governance rules and produce API 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 in budget management. And so I think a lot of this alignment is gonna 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 wanna…
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 gonna come from the outside in.
Kate Holterhoff (47:47)
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.
one for you, because as I predicted, I knew this conversation was going to be super interesting, and So the one that I absolutely do have to ask you about, 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 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. So there’s this opacity that maybe former generations of developers haven’t grappled with.
Kin Lane (49:00)
Yeah, I would say.
I would say it’s, not a new thing. I mean, I’m not a classically trained programmer. 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, 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 of your professional career,
You should know that APIs exist and power users are what made a lot of APIs. mean, the media users made Twitter what it was. The power users that wrote for the New York Times and wrote them, 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 API. So there should be clients. There should be, you know, what we’re doing with co-pilots. Now.
A lot of providers feel that their secret sauce is in there, like getting people to share their OpenAPIs. A company has been like pulling teeth. I’ve had entire IT groups walk out of talks I’ve done because I said, 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, 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 know, you’re, in trouble. Like if you, if you, 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 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 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. mean, I think more visibility, more observability, more transparency there is good. It’s like open source, you know, open within reason. I mean, we should be having this debate, but there’s also 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. They didn’t program it. not, they don’t even know what’s in there.
want anybody to look at it. so AI is just making that even worse. And so I’m a big fan of vibe coder people on APIs. I don’t know about apps. I’m not going to vote on that one. I’ll let y’all talk about that.
we’re 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 going to get really bad. I don’t see any light at the end of that tunnel as far as.
people getting empowered. just think it’s, I mean, I’m, 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 going to get back to this.
Kate Holterhoff (53:29)
You’re reminding me about the gentleman who used Claude to access like 7,000 vacuum cleaners I believe that was, like humans had missed it, but because Claude has superhuman visibility, willing to go through all these lines of discovered this IoT issue and was able command what everybody’s cameras on these robots. and yeah, it sounds like we’re only gonna be seeing more of that.
Kin Lane (53:56)
Yeah, and times 10,000, it’s going to be max.
Kate Holterhoff (53:59)
geez.
Yeah, OK. Well, and yes, and then also on your point about the money to be made. Yeah, it’s 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 there’s a need for having 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. 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
Kin Lane (55:05)
Yeah, so I’ll split that into two directions. One, you know it’s enterprise scale doing this for grown-ups, 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 that 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. Naftiko for the business enterprise version, API Evangelist if you want to get the raw version of what’s going on.
Kate Holterhoff (55:59)
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. If you’re watching us on RedMonk’s YouTube channel, please like, subscribe, and engage with us in the comments.
