Disha Agarwal - Reo.Dev (00:03)
Hello everyone, welcome. Today we're diving into a very interesting topic, how AI is reshaping developer experience. I think DevEx has changed dramatically over the last 20 years. How developers learn, how they discover tools, how they troubleshoot problems, all of that has changed multiple times, sometimes gradually and sometimes very suddenly. And right now it feels like we're at another inflection point. With AI assistance, co-pilots and ID native workflows becoming very common,
the way developers access information seems to be evolving again. But the real question is, how deep is this change? Is it just a layer of productivity on top of what already existed? Or is it actually reshaping how developers evaluate and adopt tools? And more importantly, what it means for teams building developer tools right now. And that's exactly what we are to unpack today. And I'm joined today by Emil Sorensen, co-founder of Kappa.ai.
which is building the AI interface layer between developers and the company's technical knowledge. And Gaurav Jain, CTO of Rio.dev, which surfaces developer-intent signals and helps DevTool companies identify which engineering teams need their products today. Welcome, Emil and Gaurav.
Gaurav Jain (01:13)
Thanks, thanks, Isha. Happy to be here.
Emil (kapa.ai) (01:15)
Yeah, thanks for having
us.
Disha Agarwal - Reo.Dev (01:17)
Perfect. let's begin with you. If you can tell us a bit about Kappa and what you're building here.
Emil (kapa.ai) (01:23)
Yeah, I'd be super happy to. ⁓ At Kappa, we make it easy for teams that have complex products ⁓ to make them easy to use. ⁓ What we essentially do is we work with very technical companies, folks like Nordic Semiconductor, Grafana, Sentry, ⁓ to turn their technical knowledge bases, whether it's documentation or tacit knowledge, like the stuff that lives in GitHub issues, into AI assistance that teams can put on their documentation sites.
Disha Agarwal - Reo.Dev (01:50)
Very interesting. So you're essentially changing how developers are consuming this content.
Emil (kapa.ai) (01:55)
Yeah, pretty much. It used to be way back in the day, know, books and manuals. ⁓ That's moved on. At some point it became documentation sites. There's still very much around. We went through a phase of looking at Stack Overflow and now we're at a point where people expect to be able to ask an AI ⁓ about a tool and get an answer.
Disha Agarwal - Reo.Dev (02:18)
Definitely. think at each stage, the expectation ⁓ of what developers want, that has changed a lot and how they're consuming information has changed too. So really exciting stuff, Emil. I'm going to same question for you. For those who may not know, ⁓ could you give us a quick sense of what Rio does and what problem you are trying to solve?
Gaurav Jain (02:39)
Sure. So Rio.dev is an intent tool, developer intent tool, helping any developer-focused companies build a revenue pipeline using activities which developers are doing on their first party or third party ⁓ data sets. So in a very short line, we are converting developer activity into a revenue pipeline.
Disha Agarwal - Reo.Dev (03:03)
Understood. Thank you both for the context. think what is interesting is that you both are seeing the shift that AI is bringing, but from very different sides. Emil, you're at the layer where developers are actually asking questions through AI. And Gaurav, you're looking at what that actually activity means for developer tool companies. So very interesting perspective. ⁓ So think before we deep dive into AI specifically, we would love to zoom out a bit. So Gaurav, my first question is to you.
Looking back 20 to 30 years, developer experience has changed a lot. That's what we discussed. You know, from buying books to joining IRC chats, to Stack Overflow, to today's documentation. What really has changed in these phases?
Gaurav Jain (03:46)
Right. So I think the overall journey for developer experience has been phenomenal. In fact, ⁓ I have been in the industry for more than 17 years now. And I remember my early days when we had to write a code or build a solution.
We had to find out a book, then figure out which chapter to look in, then turn over so many pages. And it used to take weeks and sometimes even months to get an appropriate solution to the problem which we are looking at. Obviously, forums and IRC channels helped us a lot. We were able to ask questions, but we had to wait for the answers. The Stack Overflow was a breeze where we were able to get the solutions in a few hours or maybe in a day's time.
But with AI coming in, I think it has become very quick, almost instantaneous. if I have to just give you a one line to this, would say a dev-x evolution is more of a story of shrinking time to solution, which is what every developer really care about. ⁓ Other thing which I feel which has changed is the knowledge, which has moved from being static to
being more interactive and dynamic. Like in books, everything was like, know, whatever you can consume, you can consume. But ⁓ with AI, it's like, you somebody, an expert sitting next to you and you can just converse. So now you are able to converse with knowledge. So that's another big change which I see. And third, I would say is, ⁓
The cognitive load has shifted. devs were supposed to know where to search. Today, what they need to know is what to ask. So the behavior is changing from search and browse to what I say is query and execute. In fact, the discovery friction, in my opinion, has reduced more in last three years than the previous 20 years.
Disha Agarwal - Reo.Dev (05:33)
Mm-hmm.
Interesting, I Gaurav totally agree. And Emil, what is your perspective here? Were there moments that you felt for inflection points where you saw a change in how developers were learning and evaluating tools?
Emil (kapa.ai) (06:08)
Yeah, I mean, I think by the way, Rob, I really agree very much with your narrative here of like time to shrinking, ⁓ time to solution shrinking. answer your question, I think the big moment was the chat GPT moment, like late 2022. ⁓
I think developers got their first taste of, ⁓ here's this new way where you can just dump in your problem and you don't have to sit and wait ⁓ for some kind incident soul to answer your question on Stack Overflow. And you might actually get the solution right there. ⁓
I really think that was the biggest shift. You know, back then there were lots of issues, models hallucinated a lot more and you you're relying on older training data. A lot of stuff since then has been kind of solved or closer to being solved for how developers can make use of this more interestingly. I would maybe argue that there's been one more shift that's way more recent. So it's still a bit too early to say, but arguably with like the Opus 4.6 release, I think
back in November that finally felt like it was the unlock to make some of these longer running agent systems work well. Arguably, we've entered the shift where traditional developer experience matters a bit less. And to kind of borrow the term from Netlify CEO, agent experience matters ⁓ increasingly more so.
Gaurav Jain (07:30)
Thank
Disha Agarwal - Reo.Dev (07:38)
Emma, could you elaborate a bit there what do you mean by the Opus 6 change that happened for people who might not know?
Emil (kapa.ai) (07:45)
Yeah, of course. I think there's been this wonderful dream of having models use tools for the longest time. ⁓ I think one of the earliest users of Kappa was Langchain, actually, more than three years ago when Harrison was struggling in his Discord to manage his technical support. But even back then, there was a lot of talk of using React paradigms to potentially let agents call tools and so on. ⁓
And frankly, like it's been two, two and a half years and some smaller versions of this have worked until then, but I think it really wasn't until quad code and ultimately quad code with kind of Opus four six, now increasingly Codex 5.3 that really moved the needle to a point where you can get to a point where you can just kind of let these systems run on their own.
I think there's a great quote from Peter Steinberger, the open-claw author on a podcast he was on. I forget if it was Lex Friedman or the YC1, where he essentially talks about learning. In the last few months, you've gotten to a point where you can, it's still tricky, but you can learn to just let go and trust these systems to write your code.
I wouldn't do this necessarily with our own full code base yet, but I've been trying this on a bunch of weekend hacks and projects. This idea of learning to let go and just let the agents run is really fascinating. But of course, the implication here for developer experience is it means, if devs or hobby devs are comfortable letting go and not reviewing any of the code and models they're producing, no longer do you have to cater to humans directly and your dev tool, only if your
agent comes back and asks for an API key, then you might look at a website and go, hey, is this something I trust giving an API key to my agent with? But yeah, it matters all of a sudden a lot more how good your developer experience is for agents.
Disha Agarwal - Reo.Dev (09:44)
No, I mean, it makes sense. now when developers are talking more to documentation rather than reading it, and now with agents also sort of doing all of that, how has developer experience reshaped? So are we saying that the tasks which were
very repetitive wherein there were certain things that needed to be done. Those are being outsourced with agents and developers are focusing on other things. How have you seen developer experience evolve in this context?
Emil (kapa.ai) (10:15)
That's a good question. ⁓ I mean, the extreme end is that case, would say. It's like, hey, developers are no longer looking at their code, Like Boris, author of Claude Code, saying 90 % of the Claude Code code was written using Claude Code. And really learning to let go. ⁓ In which case, mean, then developer experience has changed massively, right? Because now all of sudden, it values a lot more your ability to hold an entire system in your head and become way more
of an input giver as opposed to a reviewer. I think that's the extreme case. know developer Twitter loves glorifying this Nirvana that we're here today. I think if you bring it back much closer to reality, there's inklings of this that's interesting when it comes to developer experience. A much more practical approach to this is what we're seeing is like, hey, most people do use something like cursor, etc. Today, you're a variant of it. Hey, you're a plot code. But that stuff will still struggle to
implement your framework because you know what, like web search is clunky or like hey, you you have two versions and it's not clear which one it's supposed to pick and so on. And there you can do a lot more practical things from a developer experience perspective, like launch MCP servers that are hooked up to all the latest developer information you have and so on. But it's a really interesting ⁓ time.
Disha Agarwal - Reo.Dev (11:39)
Yeah, I think it's a spectrum diet and as you said, it depends on how much you can let go.
Emil (kapa.ai) (11:41)
Yeah.
Yeah.
Disha Agarwal - Reo.Dev (11:46)
Perfect. Gaurav, what is your take here if developers are increasingly interacting through AI instead of navigating documentation directly? Does it also change how evaluation is happening?
Gaurav Jain (11:58)
So, Satish, I think I agree with most of the things what Emil was saying that ⁓ the discovery of tools obviously have started. ⁓
at AI layer where you go, you ask questions, you evaluate tools there, you compare them. But what I feel being a developer is when it comes to like, you know, hardcore production stuff, you obviously want to go back to the documentation. And that's where what becomes very important is that now your docs,
Emil (kapa.ai) (12:29)
Yeah.
Gaurav Jain (12:34)
are not just your point of entry, but they are basically part of your bottom of the funnel. And in fact, they are helping the developers build the validations which they have in their head. So yeah, think ⁓ docs' importance is increasing, not just because machine is reading it, but it is becoming more and more integral part of ⁓
the whole evaluation cycle for a developer. So that's what I feel right now.
Disha Agarwal - Reo.Dev (13:10)
So what am I saying? Sorry, Amal, please.
Emil (kapa.ai) (13:10)
Maybe
building on that, totally agree. I think an interesting conundrum we often hear people come back to us to say is, hey, you know what? It's 2026, our docs visitors are down, but we're getting more inbound leads and demos than ever. I think what's happening is there's a shift.
Gaurav Jain (13:30)
with you.
Emil (kapa.ai) (13:31)
Like people are going less to the documentation to implement and troubleshoot your solution and they're spending a lot more time with your documentation to evaluate whether or not they should be using or buying this tool. So if anything that the kind of intent you get off, you know, uses on your documentation is arguably more important than ever.
Gaurav Jain (13:52)
Right, right. So one of the things which I always say, Emil, is the reading part of the documentation is now getting escaped. Now it is the integration part, or thinking of documentation as a core part of the infrastructure, which is what the DevTools should be thinking about. This is not just a content or a destination, but this is an infrastructure which you are giving to agents or these LLMs, which can actually help
you ⁓ build more concrete production use cases and hence the developers will eventually come ⁓ in the end ⁓ to basically consume it.
Disha Agarwal - Reo.Dev (14:35)
No, makes sense, Gaurav. So what I'm understanding is that while earlier there would be a lot of hobbyists or people who were early in their evaluation coming to docs, now that part is getting skipped. And the people that were coming to documentation are the ones who are really serious and are actually evaluating and looking to build. So think that's an interesting sort of shift. So, I mean, my next question is to you. And I understand that we feel that ⁓
AI in dev experience is not just a productivity boost, but it's like a full paradigm shift. And in that context, is ID become the primary interface for learning and documentation?
Emil (kapa.ai) (15:16)
Ooh, that's a good question. So IDEs, so things like cursor, VS code, are they becoming the primary interface for documentation? That's a good question. think.
I think maybe it goes back to the point we had here ⁓ just before. So are IDs becoming the primary interface for documentation? Maybe, but if so, it's for troubleshooting. It's for implementation usage. It's not for evaluation. ⁓
serious company or serious enterprise before you go and rip out Postgres and put in some sort of like scalable like alternative you'll probably want to go through and look at the Yugo Byte or Cockroach documentation etc. like ⁓ but your you know infrastructure engineer who has to do the implementation might be spending a lot more time on
directly engaging with the documentation, using their documentation MCP server directly in an IDE. ⁓ So I think it's increasingly becoming.
An interface, I would probably be hesitant to say the primary interface yet. But it definitely depends on the seriousness of the application. I'll give you an example. As total hobby dev, weekend projects, I have my open client since come back and go like, hey, I'd love to use an email inbox. Could I use agent mail? I did not look at the docs. I just very quickly like, hey, here's an API key. Yeah, go do your thing. It's limited on a credit card.
Disha Agarwal - Reo.Dev (16:37)
Mm-hmm.
Emil (kapa.ai) (16:56)
worried. ⁓ I did not look at the docs there, but that's not a very like high like high risk use case. It's not ripping out Postgres.
Disha Agarwal - Reo.Dev (17:07)
Make sense. Gaurav, what is your take on this? How do you see ID's evolving? And ⁓ if you fast forward this two, three years, how different does our developer workflow look to you?
Gaurav Jain (17:17)
Right. So interesting question. In fact, how I see it is from a very developer-centric lens, right? See, what developers really care about is solving the problems fast. And I mean, for whatever has happened in the past, but going to 10 different tabs and searching what is there and what is not there, and then building a dog for a comparison.
was always time consuming and developers never wanted to do that. Now if they are writing code in IDE and if there is a small window where they can just ask whatever questions they want to, I think as a developer I would love that. In fact, ⁓ if you see in the last six months or so with cursor and all these LLM integrations in IDE, a lot of developers have started doing that. There are two problems which I see. One is, or actually,
not two problems, but one major problem, which is a lot of these dev tools, like what Emil was also mentioning, their documentation are not agent friendly as of today, or not these LLM friendly. mean, it's in the process today, And hence, these LLMs hallucinates a lot.
Disha Agarwal - Reo.Dev (18:33)
Okay.
Gaurav Jain (18:33)
So
what happens is if you're asking for a very mission critical sort of a job to these LLMs inside the IDs, they will hallucinate and they'll do things here and there and it will just become a very complex situation for the developer to debug. So I think going forward, I would see that two things will happen. A lot of these MCPfication of the documentation will happen and
Developers, if they start integrating those MCP docs, or sorry, yeah, MCP docs inside their IDs and start using it from there, I think that would be an amazing experience for developers. Everything happening inside ID, every code line as a context in the ID is already there and they will be able to be more productive and able to solve more problems pretty quickly.
Disha Agarwal - Reo.Dev (19:26)
No, and I think if past evolution is something that we learn from.
Developers are moving towards things which gives them access to information faster. And if ID is able to give them the documentation, then that seems to be where we're moving towards. So I think definitely makes sense. And but Gaurav, I had a follow up question here. So now that documentation is increasingly being accessed by AI assistants and agents inside IDs, how does that change what intent means? And does it break the way DevTool companies currently
measure engagement.
Gaurav Jain (20:05)
⁓ I would not say it will break the way. But yes, there are definitely a few changes which needs to happen. Like what Emil was talking about agent experience. I think everybody has to be prepared for agent experience. In fact, one of the things which I was talking internally also.
we need to evolve from dev GTM to agent to agent GTM, right? Because the consumers are also going to be agent and the providers are also going to be agent. So how would that agent to agent GTM work is going to be very, very interesting. So two things or, you know, a few things which seems pretty logical, right? Agents are going to evaluate tools before humans. But...
I believe accountability will still lie with the developers. So at the end, they need to sign it off, like every other place, right? Second is, feel intent signals will evolve. For that matter, think website visits are going to be no longer ⁓ important. I don't think anybody is going to.
go to ⁓ websites in general. I ⁓ personally feel MCP is going to be a big ⁓ boon for developers and even for your marketing team at DevTool companies.
⁓ One more thing which I feel is the ⁓ evaluation cycles are going to compress massively. So like, know, we used to have this two weeks or three weeks of time to capture the intent and act on it. I think that time will also shrink because the agents will be able to compare, build a POC in days or not even days, in a few hours now. So I think the...
teams, the GTM team needs to get accustomed to all these kind of changes and build their pipeline accordingly.
Disha Agarwal - Reo.Dev (22:05)
Make sense. Interesting times. And Emel, what is your take on agent to agent evaluation? Do you see us moving towards that? And then what changes do you foresee?
Emil (kapa.ai) (22:15)
I mean, I'll give you a kappa anecdotes. Like we constantly track the number of like new opportunities or leads we get from not necessarily agents, but like guess traditional like chat GPT and cloud stuff, if that's any sort of proxy. And that's the fastest growing channel for us right now.
Disha Agarwal - Reo.Dev (22:36)
It is okay. Makes sense. So what really excites the both of you about AI-driven future of DevEx and what worries you? Emil, if we can start with you.
Emil (kapa.ai) (22:48)
I mean, it's just, it's like if executed well, right? Like we could build so much cool stuff.
I think it's just the coolest, right? Like, I mean, just from, again, like personal perspective, someone who has to sit and think through, like, what do you build every single week? How do you keep pulling the product in the right direction and so on? I mean, our linear board is like endless with customer feedback, right? There's so many great things to go build that, you know, even us as like a fantastic engineering team, like world-class, like engineering team, we're just not gonna have time to build.
There's a long tail of stuff that's gonna impact like, you know, sure it's gonna impact like three customers, but it's not gonna impact like a hundred, but it's still a really helpful thing for those three, you know. ⁓
Gaurav Jain (23:30)
hopefully.
Emil (kapa.ai) (23:38)
we're getting a lot closer to a world where we don't have to make that like prioritization and we can still make those three folks happy ⁓ and actually go build that. So I think that's the that's the bull case. Right. And, you know, expand that way beyond cop a scope and a real scope just means we can like ⁓ increase global productivity by a ton. I think the bear case or the thing that makes me worried, right, is, we're not quite there yet. Like we're still very much in like a slough land. And if you do this,
without too much taste, I don't know. Things are going to turn out for the worse. One of my favorite reason examples is... ⁓
is I think I was watching like a YC landing page tear down like one of the partners Aaron occasionally will do these. They're always like they're a hoot. They're great to watch. And I think one of the things they commented on is like, well, you're looking at a website for a startup. looks really promising and has all these like screenshots. But, you know, because it's February 2026, you don't know if the thing actually works or if it's like a vibe coded thing over the weekend. Right.
Disha Agarwal - Reo.Dev (24:48)
Yeah.
Emil (kapa.ai) (24:48)
So
you're at a point now where you can build something that looks great, right? But like, you know, yeah, does it actually work? I guess that's the bare case. But I say overall, I'm very bullish.
Disha Agarwal - Reo.Dev (25:00)
⁓
What about you Gaurav, what is your thought here?
Gaurav Jain (25:05)
Absolutely exciting. In what seems impossible, I would not say impossible, but impossible in a time frame is now seeming very much possible. The point I mentioned about there is a massive reduction in time to solution today. In fact, I am seeing more and more.
people becoming builders. So I would rather change this term of developer to builder because a developer does not just need to know the coding. They should ideally be building something. And I see even marketing folks, even finance folks are building stuff today. So that's amazing, right? The second thing which I feel is with this whole AI thing coming into the picture,
⁓ It is becoming very easy to figure out multiple solutions and compare them. So at the end, better solutions are going to win. It's not just the ones who are making a lot of noise and lot of marketing spend on the website, but the better solution is what is going to win, which is a very, very good thing, at least from a ⁓ developer's standpoint. And ⁓ I think another interesting thing is ⁓
While I think in the last five years, there has been a lot of push on developer experience, but with what is happening today, I think this will become much, much better. There will be more accountability on developer experience, and that is something which is going to be liked by a lot of developers.
So yeah, and in fact, from a concern point of view, one of the biggest concern is, I think Emil also mentioned, is AI slopes, right? mean, couple of days back only I was reading a new product coming in which is equivalent of GitHub, which is going to manage all the code which is getting committed by AI, right? There's so much of code which is getting written, and nobody knows how to manage it. So that's a big, big problem.
Another one which I feel, and this might not happen actually, but I personally feel that products improve because of feedback coming from developers. Now, if developers are ⁓ slightly away from the product and AI is doing a lot of stuff, then the whole feedback cycle will slow down. And I don't know how the product teams are going to cope up with that. But yeah, I think that's one of the concerns which I have.
Emil (kapa.ai) (27:34)
I think, okay, actually I have an idea on this one. I mean, now we're really pushing into the future, but I think one of the, and I'll check my own bias here, because this is copy related. ⁓ One of the most interesting patterns we're seeing is the fact that you can run analytics on top of what kinds of questions your MCP servers, like IDEs are trying to ask your MCP servers.
Maybe let me rephrase that, right? You can essentially run analytics on what cursor is trying to call your MCP server to do. ⁓ That's for example, something we realized that we can add on in terms of values. So for teams like, know, Clickhouse and Netlify and Sentry and Grafana and like lots of these cool tools that... ⁓
that build their MCP servers on top of Kappa, you can now go to like a Kappa dashboard and go like, hey, what are some of the top questions that these like ID, these agent harnesses are essentially trying to call ⁓ like to ask their docs MCP servers for. And you can like find these really, really interesting patterns to go like, wow, seems like it's really, really, really struggling to, you know, like run a, like this part of the installation journey.
maybe there's something you have to take into account for from, I don't know, running this in a sandbox, et cetera, et cetera, that you wouldn't normally do. ⁓ So I think ensuring that you have some sort of analytics layer on top of your MCP server so you can at least understand or begin to understand how agents are using this, that's something we personally are very, very excited about.
Disha Agarwal - Reo.Dev (29:16)
Yeah, and I think that's such powerful information. Sorry, Amit. Please go on.
Emil (kapa.ai) (29:16)
Actually, yeah, no,
I was curious. I don't mean to go off script, but I actually had a question for you, Rob. I'm really excited. I'd be curious to hear. Is this a good time to ask?
Gaurav Jain (29:28)
Yeah.
Disha Agarwal - Reo.Dev (29:28)
Yes, yes, of
course.
Emil (kapa.ai) (29:29)
Cool, no, I was genuinely wondering, I mean, you guys are dev go-to-market experts, and as things are changing so fast, are there new types of intent signals that you think developer tooling companies should be increasingly aware of? ⁓ You mentioned the inverse, that website traffic and traditional website visitors, that might be less interesting now, but I guess to flip it around, what are some signals that...
Gaurav Jain (29:31)
Thanks.
Emil (kapa.ai) (29:58)
might be emerging.
Gaurav Jain (29:59)
So, Emil, what you really mentioned just in that analytics on top of the questions which they are asking, actually these questions are a very good internet signal for GTM teams also. For example, ⁓ earlier when somebody is going to 20 different doc pages, we had to somehow...
figure out what this guy is trying to do. But in this case, the person is coming and asking what he wants to do, or what is his use case, or what is the problem they are trying to solve in the company, or where are they stuck. And in fact, one of the things which I always tell, you should not reach out to developer ⁓ randomly, but you should reach out to them if they are stuck at a problem. And if you have a solution for that, they will absolutely pick up the phone.
ready to come on a ⁓ call with you. So this query, these conversations which are coming from AI bots and the kind of solutions, for example, Kappa provides, becomes a very good intent signal. So if you can ⁓ understand those, and that is what we are also trying to do with partnership with Kappa also, which is we are giving them the entire timeline of what kind of questions they ask, what was the response, what was the next question.
they are, so what kind of use case they are trying to solve and hence what opportunity is coming for the tool to basically sell to this developer. So yeah, I think that's a very interesting, signal which we are seeing now.
Emil (kapa.ai) (31:38)
Cool.
Disha Agarwal - Reo.Dev (31:40)
So there's so much, sort of understanding there's so much powerful data now because you're able to understand what is it that these agents and these people are trying to access ⁓ through documentation.
So when that flows into your how your documentation should improve how your product should improve where are people struggling and people are literally telling you You know, this is where I'm struggling. So instead of piecing information together They literally asking you that you know, this is this is what I'm trying to do if you can help me do this That's when I'm sold. So I think really really interesting and powerful signals What if I had a follow-up on? What you had said so you said that you know now marketers product people everyone is coding. So do you feel that that's
a threat to developer jobs. Do you see that declining?
Gaurav Jain (32:25)
Sorry, can you come again? I probably missed.
Disha Agarwal - Reo.Dev (32:27)
So as I was saying that you were
mentioning that now with Vibe Coding and with so many AI tools, you need to be a builder. You don't need to be a developer per se, right? ⁓ So now marketeers, product people, everyone can code. So do you see that as a threat to developer jobs in the future?
Gaurav Jain (32:46)
Not really. mean, it's one of the most hottest topics being discussed for the last six to eight months. I think, you know, if you look at historically also, whenever something becomes easier, the jobs have always increased. Right. I mean, and if I may take a liberty of, you know, going back like 40, 50 years when there was assembly language, building anything was like so complex.
that not a lot of people were able to really do it. But from assembly language to C, C++ to let's say Java to Python and then building some very high level programming language, every time the skills required to build something has reduced, the number of developers or number of builders have actually increased. Now, this is the same thing. Now you are able to build something very easily. My assumption is the number of builders will increase a lot.
I the number of jobs will go down. Probably you might need to adjust on your skills. What you used to do earlier versus what you will be doing now. But I think the number will obviously increase. It cannot go down.
Disha Agarwal - Reo.Dev (34:00)
Emil, what is your thought here? What do feel?
Emil (kapa.ai) (34:04)
That's a tricky question, but I mean, and this one, nothing, I don't think I have too much of an alt-tick. I very much agree with Grav. I think it's so exciting that, I mean, it goes back to this point.
If we're trending towards even developers being more comfortable letting go and letting the agents take control, what this implies for the talent pool of potential builders, it means folks that might not have grinded away for 10 years can also ship code.
Gaurav Jain (34:30)
Thank
Emil (kapa.ai) (34:37)
And I think that's really exciting. Like I'm feeling this firsthand. Like I've not done any engineering on the Kappa stack now for more than two years and I'm a rusty engineer at that. ⁓ But I've been shipping more code than ⁓ ever before. ⁓ Admittedly not like core, core Kappa, like backend service stuff, but it's very empowering knowing that you can go from idea to something shipped pretty quickly. ⁓
Gaurav Jain (35:08)
And just to add on to what Emil was saying, Rishabh, right? See, the art of letting go, I mean, it has to happen because like, for example, when I was coding in Java, I never used to care what assembly language or what assembly code it was generating behind the scenes. Because at the end, everything has to be that machine language, which is what computers understand. But we evolved from assembly to Java, and we are not caring anymore.
Disha Agarwal - Reo.Dev (35:08)
Makes sense.
Mm-hmm.
Gaurav Jain (35:38)
what sort of snippets it is actually creating in the machine language. So same thing. mean, these are all the level of abstractions which are getting created. And once you go higher up, you start solving higher order problems. And you assume that all the lower order problems are already taken care of.
Disha Agarwal - Reo.Dev (35:55)
Makes sense. But what if then who brings in this structure? Because I think you also mentioned that the owner still lies on the developer. And ⁓ while agents might do part of their work, the final check and balance is something that the developer should do. And I think, Emil, you also mentioned that you wouldn't let an agent do the entire evaluation. You would like to keep some checks. So who decides, and where do you draw that line?
Gaurav Jain (36:21)
Interesting question. I ⁓ mean, see, at the end, whoever has the accountability should draw that line.
And I'm assuming that accountability will always be there. I no systems will be built without accountability. There has to be somebody who is accountable for building stuff, right? So yeah, whoever is accountable will own it. And we'll figure out whether they have to use 100 % of agents or whether they have to use 10 % of the agents, whatever it is. And they should be knowledgeable enough to decide on these things.
Disha Agarwal - Reo.Dev (36:57)
Make sense. Emil, do you have any thoughts here?
Emil (kapa.ai) (37:01)
I think Gerov's needing the answers to all of these questions.
Gaurav Jain (37:05)
you
Disha Agarwal - Reo.Dev (37:06)
Just coming back to the point where you were saying that documentation is evolving so much and Gaurav, you had mentioned that documentation needs to become more agent friendly. So Emma had a question here. If documentation becomes like an infrastructure which is powering AI rather than just like a destination for developers, how should companies rethink how they write and structure it?
Emil (kapa.ai) (37:29)
That's a good question. So on this, I think you could draw lot of parallels from the like ⁓ CEO geo debate that's happening now. You know, how do you optimize like everything for geo? How do you like ensure the chat GPT sites your product? I think honestly the same applies ⁓ to developer experience and agent experience. And overwhelmingly the take is it's not that different. Like sure there's a bunch of tricks you can do
Disha Agarwal - Reo.Dev (37:46)
Yeah.
Emil (kapa.ai) (37:59)
and you have to get all the technical parts right of your page structure and all this. But most of that is table stakes anyway. From a CEO perspective, it's hey, make sure you have relevant and interesting and high quality content that matches based on what people are searching for is up to date. You have high dwell time that people are like.
engaging with a page, et cetera, et cetera. Same applies to docs, right? I ⁓ think we have the most high-ranked hacker news front page thing for writing docs in AI. We wrote sometime last year. And there, it's all the same thing. It's like, just ensure your documentation is well-structured. So if you land on a random page that you know where this is from a bread-crumbs hierarchy level across the stack, make sure that
sections have good metadata associated with them, so if this only applies to a certain version, say so. Make sure that everything is self-contained and has good code snippets and all this stuff. But all of this would have applied if you had asked a technical writer for how to write good technical documentation in a pre-LLM era as well.
Disha Agarwal - Reo.Dev (39:11)
Make sense. And what are some of the biggest mistakes you see DevTool teams make when they're trying to enable AI-driven docket support?
Emil (kapa.ai) (39:20)
I think one of them is probably being too hesitant to lean in. A common objection we hear is, hey, you know, I don't think our documentation is AI ready. So we don't feel that we're at a point where, you know, for example, we should add an AI search layer on top or create our own MCP because we have, you know, half a year of content works is due to catch up.
I think that's a fallacy because what happens is now you're relying on the big, like big general models to hopefully give good answers to those questions, right? As opposed to providing your users a more direct way of actually engaging with this content. ⁓ So what we usually say at this point is, well, hey, you know, in that case, like better to have something live that you own and control and know where it falls short, know where it can answer questions. So you know what to improve against.
⁓ So pushing people over that initial bump of being overly cautious still is probably the number one failure mode we see.
Disha Agarwal - Reo.Dev (40:29)
And do you see more and more companies now moving towards AI enabled docs or is there still some hesitancy?
Emil (kapa.ai) (40:36)
Yeah, I mean, think it varies a lot across industries too. If you're a new two-person YC startup, chances are you're going to be pretty aggressive on this stuff. Versus, we spent a bunch of time last year working with Nokia, right?
They moved on from making tires and phones, and now they power a lot of the networking infrastructure that probably powers my current 5G on my phone now, for example. They're a massive, huge organization. They were really worried. Are we in a good point where we can have something like this live? Of course, it's a lot more complex. Any dev tool would look at their documentation and go, whoa, order of magnitude, more technical writers, and so on.
complex. But even they, they got to a point after they started engaging with us that like, hey, you know what, like now's the time this stuff has passed the bar of being good enough to go live with something like this.
Disha Agarwal - Reo.Dev (41:32)
Got it. And Digo.dev works with more than 150 plus DevTool companies now. Have you seen them adopting ⁓ MCP-enabled docs and using MCP gateways? And what is the change that they are seeing?
Gaurav Jain (41:46)
Right. Absolutely. In fact, very fascinating data coming up, right? So there are some pretty interesting insights. Like, for example, what we have started seeing is in the core categories, like database and some of the core infrastructure, we are still seeing good documentation usage. But categories like AI infra, ML Ops, API companies is where we are seeing some decline.
Emil (kapa.ai) (41:46)
Yeah.
Gaurav Jain (42:16)
What we have also seen is a lot of these AI infra-company, just by the nature of what problem they are trying to solve, they are much aware about AI documentation and all. And hence, they are adopting much faster. In fact, ⁓ almost 10 to 12 of our customers have already.
created their MCP doc servers and they are going pretty heavy on this side. I think everybody has these basic things like skills or agents.md already on their documentation for easy navigation and agents should be able to discover them quickly. I think they are doing it. One thing which I feel should happen and specifically on closed source companies which are... ⁓
whose code snippets are not widely available is they should start adding more and more code on their documentation because see all the open source obviously everything is available on GitHub and agents are able to understand that. Old DevTool companies, yes, their code is available on Stack Overflow, and all those places so agents are still able to pick up. But new companies and where there are not a lot of these executables or these code snippets,
is where the problem is happening. I think I have seen a few companies have started doing it, but not a lot. But I'm assuming in the next six months, things are going to change.
Disha Agarwal - Reo.Dev (43:43)
And one of the companies that have sort of enabled MCP in their docs and are using MCP intent gateway, ⁓ what change are they seeing in terms of the kind of intent they're getting in terms of conversions that they might be getting? Is there any data there?
Gaurav Jain (43:58)
This is fascinating. In fact, one of our customers, there was a big bank in Australia.
they were just trying to figure out how to reach out to them. I think even just after 15 to 20 days of ⁓ integrating with their MCP docs, they started understanding exactly the problem they are trying to solve. So they were writing in plain English that this is what I'm trying to do, why this is not working, this is my use case, how can ⁓ whatever that tool was can help me in this.
So the moment they knew it, the outreach was so contextualized that in the next seven days, they were able to book the meeting. And in the next one, one and a half month, they were able to close it. So I think the results are fascinating. mean, it's happening at a more than expected sort of rate,
Disha Agarwal - Reo.Dev (44:57)
Interesting. ⁓ As I said, I think the kind of intent that you get when you're able to understand what is it that they're trying to do, I think that's unmatched. That's like a product demo that they're asking you for. So I think it's quite interesting.
Gaurav Jain (45:12)
Absolutely.
Disha Agarwal - Reo.Dev (45:14)
Yeah, so think we've talked about, you know, books to forums, stack overflow to documentation, and now from, you know, browsing to actually asking. And maybe I think it's just not AI. It's also about where knowledge lives and who or what is consuming it. And I think as documentation is becoming something which is more queried and not read, and evaluation may involve agents as much as humans, DevTool teams need to rethink not just distribution, but how they're actually understanding who's interacting with it and why.
I think having that layer is something which is truly important. So I'd love to close with this one question to the both of you and maybe we can start with you Emil. What's one thing DevTool leaders should start doing today to get ready for what's happening and where this is headed?
Emil (kapa.ai) (46:03)
I'll give you two things. think the first thing is like tinker with this stuff. Like if you haven't spun up an open claw instance and like how to do stuff at home, definitely do that. If you haven't used like Claude code yet, definitely tinker, try to install your own tools, work with them, go through onboarding journeys. Just like get this in your hands because I guess how this worked in January is very different than February 2026 when we're now recording this. And by the time this gets published, it'll probably look even
Gaurav Jain (46:30)
Thank
Emil (kapa.ai) (46:33)
even different than. I think that's one. I think the second thing I'll implore people to do is if you have some sort of AI agent or assistant live in your product on your documentation side, if you've hosted an MCP server, look at the data.
Disha Agarwal - Reo.Dev (46:35)
Yes.
Emil (kapa.ai) (46:52)
Gaurav, to your point before, there's some really interesting intent here. mean, one side, of course, from a marketing perspective, like trying to understand what your leads are, or potentially asking if there's high intent folks. But increasingly, I would argue from a product direction and roadmap perspective.
If you're starting to, you will see a stark difference in how users and traditional human developers are asking questions to AI chat ⁓ and then actually seeing how agents are using them. It's surprisingly different and it's very, very interesting.
Disha Agarwal - Reo.Dev (47:31)
Interesting, got a Viotic on the same.
Gaurav Jain (47:35)
I think I was going to say the same two things which Emma said. Double down on agent experience. If you're not doing it today, you are already out of the race.
And second, feel is MCPifying the docs. Make sure you are looking at those questions, both from product as well as from a GTM perspective. Understand your users well and try to see how you can make more and more install your MCP servers in their IDs or wherever cloud, whatever they are using.
Yeah, I those two things.
Disha Agarwal - Reo.Dev (48:17)
So I think both of you are aligned on where this is headed and what the DevTool teams should do. But thank you so much. I think this was a very thoughtful discussion. And while the shift may be quiet, I think the implications are significant. And it's very fascinating to see how DevTool teams respond here. So thank you so much for your time and this discussion.
Gaurav Jain (48:29)
Thank you.
Thank you. Thank you, Disha. ⁓
Emil (kapa.ai) (48:39)
Thanks for hosting.
Disha Agarwal - Reo.Dev (48:43)
Thank you.
