Clline announces their $32m Seed+A today. In an age of nonstop VSCode forks (Kiro) and terminal agents (Warp 2.0, Charm Crush, Augment CLI), why is a free open source VSCode extension doing so well in 2025?
As the AI coding wars rage on, there seems to be an unlimited demand for new entrants in this space. In January of this year, Cline launched their AI engineer extension compatible with VS Code, Cursor, and Windsurf. In the 6 months since release, they are closing in on 2 million downloads.
Plan & Act and why RAG for coding is dead
The first change the Cline team introduced to the regular AI IDE workflow is going from sequential chat to plan + act where the models can create an outline of the changes needed, and then work through them.
One of the key differences in this mode is moving on from RAG (i.e. index your codebase and do semantic search) to agentic search. You can read pash’s blog post here about RAG being a mind virus.
This all ties into the newly-coined “context engineering” practice, which for Cline has a few different pieces:
- Dynamic Context Management: Employing strategies to intelligently read and summarize file content in real-time, ensuring context remains relevant and up-to-date without overwhelming the context window.
- AST-Based Analysis: Using Abstract Syntax Trees (AST) to precisely identify and extract relevant parts of code, which aids in accurate navigation and manipulation of files.
- Narrative Integrity: Ensuring continuous narrative coherence throughout tasks by summarizing past interactions and retaining key information to maintain context accuracy during long or complex tasks.
- Memory Bank: Developing mechanisms to capture and retain essential "tribal knowledge" and developer preferences without explicit input, facilitating more personalized and contextually aware interactions.
MCPs for Everyone
Cline also leaned into MCPs very early, and already launched their own marketplace. We asked them what the most popular MCPs are, and got a list of the “usual suspects” which you can find in their MCP marketplace:
- File System MCP: For managing files and directories.
- Browser Automation MCPs: Playwright, Puppeteer, and Browser Tools for web tasks.
- Git Tools: For repository interactions and version control.
- Documentation Retrieval (Context 7): Allows easy access to documentation libraries.
- Third-party integrations: Slack, Perplexity Research, Unity, and Ableton for tasks beyond typical coding environments.
The surprising thing was how MCPs are also the killer feature for non-technical people. There are Cline users who don’t code at all but use it as a workflow automation platform, with two leading use cases:
- Automated Marketing and Social Media: Leveraging Reddit and Twitter MCP integrations to automate content scraping and post generation right in the IDE.
- Presentation Creation: Non-technical users generated entire slide decks by transcribing voice notes and automatically formatting them into professional presentations. (You can argue this is coding-adjacent as it uses code as slides frameworks, but still!)
As MCPs keep growing in popularity and the multi-modal textbox keeps growing as the best AI interface, we’ll see more of these.
Show Notes
Timestamps
- [00:00:05] Introductions
- [00:01:35] Plan and Act Paradigm
- [00:05:37] Model Evaluation and Early Development of Cline
- [00:08:14] Use Cases of Cline Beyond Coding
- [00:09:09] Why Cline is a VS Code Extension and Not a Fork
- [00:12:07] Economic Value of Programming Agents
- [00:16:07] Early Adoption for MCPs
- [00:19:35] Local vs Remote MCP Servers
- [00:22:10] Anthropic's Role in MCP Registry
- [00:22:49] Most Popular MCPs and Their Use Cases
- [00:25:26] Challenges and Future of MCP Monetization
- [00:27:32] Security and Trust Issues with MCPs
- [00:28:56] Alternative History Without MCP
- [00:29:43] Market Positioning of Coding Agents and IDE Integration Matrix
- [00:32:57] Visibility and Autonomy in Coding Agents
- [00:35:21] Evolving Definition of Complexity in Programming Tasks
- [00:38:16] Forks of Cline and Open Source Regrets
- [00:40:07] Simplicity vs Complexity in Agent Design
- [00:46:33] How Fast Apply Got Bitter Lesson'd
- [00:49:12] Cline's Business Model and Bring-Your-Own-API-Key Approach
- [00:54:18] Integration with OpenRouter and Enterprise Infrastructure
- [00:55:32] Impact of Declining Model Costs
- [00:57:48] Background Agents and Multi-Agent Systems
- [01:00:42] Vision and Multi-Modalities
- [01:01:07] State of Context Engineering
- [01:07:37] Memory Systems in Coding Agents
- [01:10:14] Standardizing Rules Files Across Agent Tools
- [01:11:16] Cline's Personality and Anthropomorphization
- [01:12:55] Hiring at Cline and Team Culture
Transcript
Introductions
Alessio [00:00:05]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO at Decibel, and I'm joined by my co-host Swyx, founder of Small AI. Welcome, welcome.
Swyx: And today in the studio with a nice two guests from Cline, Pash and Saud. That's right. Yes.
Alessio [00:00:20]: You nailed it. Let's go.
Swyx [00:00:23]: I think that Cline has a decent fan base, but not everyone has heard of it. Maybe we should just get an upfront, like what is Cline, maybe from you and then you can modify that as well.
Saoud [00:00:35]: Yeah, Cline's an open source coding agent. It's a VS Code extension right now, but it's coming to JetBrains and NeoVim and CLI. You give Cline a task and he just goes off and does it. He can take over your terminal, your editor, your browser, connect to all sorts of MCP services and essentially take over your entire developer workflow. And it becomes this point of contact for you to get your entire job done, essentially.
Swyx [00:01:01]: Beautiful. Pash, what would you modify? Or what's another way to look at Cline that you think is also valuable?
Pash [00:01:08]: Yeah, I think Cline is the kind of infrastructure layer for agents, for all open source agents, people building on top of this like agentic infrastructure. Cline is a fully modular system. That's the way we envision it. And we're trying to make it more modularized so that you can build any agent on top of it. Yeah. So with the CLI and with the SDK that we're rolling out, you're going to be able to build fully agentic systems for agents.
Plan and Act Paradigm
Swyx [00:01:35]: Oh, okay. That is a different perspective on Cline that I had. So, okay, let's talk about coding first and then we'll talk about the broader stuff. You also are similar to Ader. I don't know who comes first in that you use the plan and act paradigm quite a bit. I'm not sure how well known this is. Like to me, I'm relatively up to speed on it. But again, like maybe you guys want to explain like why different models for different things.
Saoud [00:02:02]: Yeah, I'm going to take the credit. Yeah, I'm going to take the credit for coming up with plan and act first. Okay. Cline was the first to sort of come up with this concept of having two modes for the developer to engage with. So just in like talking to our users and seeing how they use Cline where it was really only an input field, we found a lot of them starting off working with the agent, coming up with a markdown file where they asked the agent to put together some kind of architecture plan for the work that they want the agent to go on to do. And so they we would find that that people just came up with this workflow for themselves just organically. And so we thought about how we might translate that into the product. So it's a little bit more intuitive for new users who don't have to kind of pick up that pattern for themselves, and can kind of direct and, and put in guardrails for the agent to hear to these different modes, whenever the user switches between them. So for example, in plan mode, the agents directed to be more exploratory, read more files, get more data, get more data, get more data, get more data. Sort of understanding and fill up its context with any sort of relevant information to come up with a plan of attack for whatever the task is the user wants to accomplish. And then when they switch to act mode, that's when the agent gets this directive to look at the plan and start executing on it, running commands, editing files. And it just makes working with agents a little bit easier, especially with something like Cline, where a lot of the times, people's engagement with it is mostly in the plan mode, where there's a lot of back and forth. There's a lot of extracting context from the developer, you know, asking questions, you know, what do you want the theme to look like? What pages do you want on the website, just trying to extract any sort of information that the user might not have put into their initial prompt. Once the user feels like, okay, I'm ready to let the agent go off and work on this, they switch to act mode, check auto approve, and just kick their feet up and you know, get coffee or whatever and let the agent get the job done. So yeah, most of the engagement happens in the plan mode. And then act mode, they kind of just have a peripheral vision into what's going on, mostly to course correct whenever it goes in the wrong direction. But for the most part, they can just rely on the model to get it done.
Alessio [00:04:14]: And was this the first shape of the product? Or did you get to the plan act iteratively? And maybe, was this the first idea of the company itself? Or were you exploring other stuff?
Saoud [00:04:26]: It was a lot of, especially in the early days of Cline, it was a lot of experimenting and talking to our users. And seeing what kind of workflows came up that they found that were useful for them and translating them into the product. So plan and act was really a byproduct of just talking to people in our discord, just asking them what would be useful to them, what kind of prompt shortcuts we could add into the UI. I mean, that's really all plan and act mode is. It's essentially a shortcut for the user to save them the trouble of having to type out, you know, I want you to ask me questions and put together a plan the way that you might have to. You know, some of the other tools, you'd have to like be explicit about, I want you to come up with a plan before, you know, acting on it or editing files, incorporating that into the UI, just saves the user the trouble of having to type that out themselves.
Alessio [00:05:14]: But you started right away as a coding product. And then this was part of, okay, how do we get better UX, basically? Exactly. Yeah. What was the model evaluation at the time? So I'm sure part of like the we need plan and act is like, maybe the models are not able to do it end to end. When you started working on the model, what was the evaluation like? And then how did you start working on that? Where were the model limitations? What were the best models? And then how has that evolved over time?
Model Evaluation and Early Development of Cline
Saoud [00:05:37]: Yeah, when I first started working on Client, this was, I think, 10 days after Cloud 3.5 Sonic came out, I was reading Anthropix model card addendum. And there was this section about agentic coding and how it was so much better at this step by step accomplishing tasks. And they talked about running this internal test where they let the model run in this loop where it could call tools. And it was obvious to me that, okay, they have some version, and they have some application internally, that's really different from how the, you know, the other things at the time were things like Copilot and Cursor and Ader. They didn't do this for like step by step reasoning and accomplishing tasks. They were more suited for the Q&A and, and one shot prompting paradigm. At the time, I think it was June 2024, Anthropix was doing a build with Cloud hackathon. So I thought, okay, this is going to be fun. And I think this is a really cool new capability that none of the models have really been capable of doing before. And I think being able to create something from the ground up and take advantage of kind of like the nuances of how much the models improved in that point in time. So for example, Cloud 3.5 was also really good at this test called needle in a haystack, where if it has a lot of context in its context window, for example, you know, 90% of its 200k context window is filled up. It's really good at picking out. granular details in that context, whereas before Cloud 3.5, it really pay a lot more attention to whatever was at the beginning or the end of the context. So just taking advantage of kind of the nuances of it being better at understanding longer context and it being better at task by task, sorry, step by step, accomplishing tasks, and building a product from the ground up just kind of let me create something that just felt a little bit different than anything else that was around at the time. And some of the core principles and building the first version of the product was just keep it really simple. Just let the developer feel like they can kind of use it however they want, so make it as general as possible, and kind of let them come up with whatever workflows, you know, works well for them. People use it for all sorts of things outside of coding, our product marketing guy, Nick Bauman, he uses it to connect to, you know, a Reddit MCP server, scrape content connected to an X MCP server and post tweets, essentially, even though it's a VS Code extension, and a coding agent. MCP kind of lets it function as this everything agent where it can connect to, you know, whatever services and things like that, and that's really a side effect of having very general prompts just in the product and not sort of limiting it to just coding tasks.
Use Cases of Cline Beyond Coding
Pash [00:08:14]: I was at a conference in Amsterdam, and I built my whole presentation, my whole slide deck using this library. It's like a JavaScript library called SlideDev, and I just asked Cline, like, hey, like, here's like my style guidelines. I wrote like a big Cline rules document explaining like... how I want to style the presentation in SlideDev, I told Cline, like, the agenda I kind of recorded using this other app called Limitless, like transcribed my voice in a text about like my thoughts, just like stream of consciousness about what I was going to talk about for this conference for my talk, and Cline just went in and built the whole deck for me, so, you know, Cline really can do anything. In JavaScript. In JavaScript, yeah.
Swyx [00:08:56]: Yeah, so it's kind of a coding use case.
Pash [00:08:59]: It was kind of a... It was kind of a coding use case, but then making a presentation out of it, but it can also like run scripts, like do like data analysis for you, and then put that into a deck, you know, kind of combine things.
Why Cline is a VS Code Extension and Not a Fork
Saoud [00:09:09]: And being a VS Code extension is kind of this, like, it gives you these interesting capabilities where you have access to the user's OS, you have access to the user's terminal, and, you know, you can read and edit files. Being an extension, it reduces a lot of the onboarding friction for a lot of developers, or they don't have to, you know, install a whole new application. Or have to, you know, go through whatever internal jumping through hoops to try to get something approved to use within their organizations. So the marketplace gave us a ton of really great distribution, and it's sort of like the perfect conduit for something that needs access to files on your desktop, or to be able to run things on your terminal, to be able to edit code, and to take advantage of VS Codes. It's really nice UI and show you like diff views, for example, before and after it makes changes to files.
Swyx [00:09:59]: Weren't you tempted to fork VS Code, though? I mean, you know, you could be sitting on $3 billion right now.
Saoud [00:10:05]: Well, no, I actually like pity anybody that has to fork VS Code, because Microsoft makes it like notoriously difficult to maintain these forks. So a lot of resources and efforts go into just maintaining, keeping your fork up to date with all the updates that VS Code is making. I see.
Swyx [00:10:23]: Is that because they have a private repo and they need to just sync it? There's no like... Exactly. Exactly. And there's one of those kinds of open source projects.
Saoud [00:10:31]: Right. And VS Code is moving so quickly where I'm sure they run into all sorts of issues, not just in, you know, things like merge conflicts, but also in the back end. They're always making improvements and changes to, for example, their VS Marketplace API. And to have to like reverse engineer that and figure out kind of how to make sure that your users don't run into issues using things like that is, I'm sure, like a huge headache for anybody that has to maintain a VS Code fork. And it also, you know, being an extension also gives us a lot more distribution. You have to use us or somebody else. You can use Cline in Cursor or in Windsurf or in VS Code. And I think Cline complements all these things really well in that, you know, we get the opportunity to kind of figure out and work really closely with our users to figure out what the best agentic experience is. Whereas, you know, Cursor and Windsurf and Copilot have to think about the entire developer experience, the inline code edits, the Q&A, sort of all the other bells and whistles that go into writing code. Right. Right. Right. Right. So I think that's what we're going to focus on, what I think is the future programming, which is this agentic paradigm. And as the models get better, people are going to find themselves using natural language, working with an agent more and more and less being in the weeds and editing code and tab autocomplete.
Pash [00:11:42]: Yeah, just like imagine how many like resources you would have to spend maintaining a fork of VS Code where we can just kind of stay focused on the core agentic loop, optimizing for different model families as they come out, supporting them. You know, there's so much work that goes into all of this that maintaining a fork on the side would just be such a massive distraction for us that I don't think it's really worth it.
Economic Value of Programming Agents
Alessio [00:12:07]: I feel like when you talk, I hear this distinction between we want to be the best thing for the future of programming. And then also, this is also great for non-programming. Is this something that has been recent for you where you're seeing more and more people use the MCP servers, especially to do less technical thing? And that's an interesting area. Yeah. Yeah. Yeah. Yeah. I mean, it's still like the highest kind of like economic value thing to be selling today. I'm curious if you can share more.
Saoud [00:12:34]: In terms of economic value, programming is definitely the highest cost to benefit for language models right now. And I think, you know, we're seeing a lot of, you know, model labs recognize that opening-eyed, anthropic or taking coding a lot more seriously than I think they did a year ago. What we've seen is, well, yes, like the MCP ecosystem is growing and a lot of people are using it for things outside of programming. The majority use case is mostly developer work. There was an article on Hacker News a couple of weeks ago about how a developer deployed a buggy Cloudflare worker and used a sentry MCP server to pull a stack trace and ask Cline to sort of fix the bug using the stack trace information, connect to a GitHub MCP server to close the issue and deploy the fix to Cloudflare. All right within Cline using natural language. Never having to leave VS code and it sort of interacts with all these services that otherwise the developer would have had to have the cognitive overload of having to, you know, figure out for himself and leave his developer environment to essentially do what the agent could have done just on the background, just using natural language. So I think that's kind of like where things are headed is the application layer being connected to sort of all the different services that you might have had to interact with before manually and it being this sort of single point of contact for you to interact with using natural language. And. You being less and less in the code and more and more a high level understanding of what the agent's doing and being able to course correct. I think that's another part of what's important to us and what's allowed us to kind of cut through the noise in this like incredibly noisy spaces. I think a lot of a lot of people have really grand ideas for, you know, where things are heading, but we've been really maniacal about what's useful to people today. And a large part of that is understanding sort of the limitations of these models, what they're not. So good up and giving enough insight into those sorts of things to the end developers so that they know how to course correct. They know how to give feedback when things don't go right. So, for example, Cline is really good about, you know, giving you a lot of insight into the prompts going into the model, into when there's an error, why the error happened into the tools that the model is calling. We try to give as much insight into what exactly the model is doing in each step in accomplishing a task. So when things don't go wrong or it starts to. Go off in the wrong direction, you can give it feedback and course correct. I think the course correcting part is so incredibly important and in getting work done, I think much more quickly than if you were to kind of give a sort of a background agent work, you come back a couple of hours later and it's just like totally wrong. And it didn't do anything that you expected it to do. And you kind of have to retry a couple of times before it gets it right.
Alessio [00:15:16]: I think the Sentry example is great because I feel in a way the MCPs are like cannibalizing the products themselves. Like I started using the Sentry MCP. And then Sentry released here, which is like their issue resolution agent, and it was free at the start. So I turned it on in Sentry, I was using it, it's great. And then they started charging money for it. And I'm like, I can use the MCP for free, put the data in my coding agent, and it's going to fix the issue for free and send it back. I'm curious to see, especially in coding where you can kind of have this closed loop where, okay, RDS MCP is going to become the paid AI offering so that then you can plug it in and. It's client going to have kind of like a MCP subscription where like totally you're kind of fractionalizing all these costs. To me today, it feels like it doesn't make a lot of sense the way they're structured.
Early Adoption for MCPs
Pash [00:16:07]: Well, yeah, we were like very early on. We like we've been bullish on MCP from the very beginning.
Saoud [00:16:13]: And we are a launch partner, a financial MCP, I think. Sorry to interrupt. Yeah, no worries. I think when Anthropic first launched MCP and they made this big announcement about this new protocol that they've been working on and open sourcing it. Nobody really. Understood what it meant. And it took me some time really digging into their documentation about how it works and why this is important. I think they kind of took this bet on the open source community contributing to an ecosystem in order for it to really take off. And so I wanted to try to help with that for as much as possible. So for a long time, most of client system prompt was how does MCP work? Because it was so new at the time that, you know, the models didn't know anything about it and how to make MCP servers. So like if the developer wanted to, you know, make something. Like that would be really good at it. And I'd like to think that, you know, client had something to do with how much the MCP ecosystem has grown since then. And just getting developers more insight and sort of awareness about how it works under the hood, which I think is incredibly important in using it, let alone just developing these things. And so, yeah, when we launched MCP in client, I remember our Discord users just trying to wrap their heads around it. And in seeing clients build MCP servers from the ground up, they're like, OK. They started to connect the dots. This is how it works under the hood. This is why it's useful. This is how agents connect to these tools and services and these APIs and sort of saved me a lot of the trouble of having to do this sort of stuff myself.
Pash [00:17:37]: Those were like the early days of MCP when people were still trying to wrap their heads around it. And there's like a big problem with discoverability. So back in like February, we launched the MCP marketplace where you could actually go through and have like this one-click install process where client would actually go through looking at a readme. And that's like linked to a GitHub, install the whole MCP server from scratch and just get it running immediately. And that was like, I think around that time, that's when MCP really started taking off with like the launch of the marketplace where people were able to discover MCPs, contribute to the MCP marketplace. We've listed over like 150 MCP servers since then. And like the top MCPs in our marketplace have over, you know, hundreds of thousands of downloads. People use them. And, you know, there's like really notable examples where you mentioned like, how are people like, it's like kind of eating existing products, but at the same time, we're starting to see like this ecosystem evolve where people are monetizing MCPs like a notable example of this is 21st dev magic MCP server where it injects some taste into this coding agent into the LLM where they have this library of beautiful components and they just inject relevant examples. So that. Client can go in and implement beautiful UIs. And the way they monetize that was like a standard API key. So we're starting to see developers really like take MCPs, build them in, have distribution platforms like the MCP marketplace and client and monetize their whole business around that. So now it's like almost like you're selling tools to agents, which is a really interesting topic.
Alessio [00:19:22]: And you can do that because you're in VS code. So you have the terminal. So you can do. And PX run the different servers. Have you thought about doing remote MCP hosting or you feel like that's not something you should take over?
Local vs Remote MCP Servers
Pash [00:19:35]: Yeah, we haven't really hosted any ourselves. We think that's we we're looking into it. I think it's it's all very nascent right now, the the remote MCPs, but we're definitely interested in supporting remote MCPs and listing them on our marketplace.
Saoud [00:19:50]: And another part, I think what sort of local MCP servers and remote MCPs is. Most of the remote MCPs are only useful to connect to different APIs. But that's only a you know, that's only a small use case for MCPs. A lot of MCPs help you connect to different applications on your computer. For example, there's like a a Unity MCP server that helps you create, you know, 3D objects with right from within VS code. There's an Ableton MCP server. You can make songs using something like client or whatever else uses MCPs. We won't see a world where these MCP servers are only hosted remotely. There will always be some mix of local MCP servers and remote MCP servers. I think the remote MCP servers do make the installation process a little bit easier with, you know, with something like an OAuth flow and just authenticating a little bit not as painful as having to manage API keys yourself. But for the most part, I think the MCPs ecosystem is is is really in its earlier days. We're still trying to figure out this good balance of security, but also convenience for the end developer so that it's not a pain to have to set these things up. And I think we're still in this very much experimental phase about how useful it is to people. And I think now that it is seeing this level of market fit and people are coming out with, you know, these sorts of like articles and workflows about how it's totally changing their jobs. I think there's going to be a lot more of resources and efforts that go into the ecosystem and just building out the protocol, which I think there's a lot on Anthropics Roadmap. And I think the community in general just has a lot of ideas and our marketplace in particular has given us insights into some ways that we can do this. And I think the community in general just has a lot of ideas and our marketplace in particular has given us insights into some ways that we can do this. and I think the community in general just has a lot of ideas and our marketplace in particular has given us insights into some ways that we can do this. Things that, you know, developers have asked for from it, that we're kind of thinking about how do we you know, what is the marketplace of the future look like? And for us, that's it's it's going to be a combination of, you know, well, there's a lot of our users are very security conscious. And there's a lot of ways that MCPs, you know, servers can be pretty dangerous to use if you don't trust the end developer of these things. And so we're trying to figure out, you know, what is a future look like where you can where you have some level of security? and to kind of build some level of confidence in the MCP servers you're installing? I think right now it's just it's too early and there's a lot of trust in the community that I don't think a lot of, you know, enterprise developers or organizations are quite willing to do yet. So that's something that's top of mind for us.
Anthropic's Role in MCP Registry
Swyx [00:22:10]: There's an interesting tension between the Nthopic and the community here. You basically kind of have a model register MCP registry internally, right? Honestly, I think you should expose it. I was looking for it on your website and you don't have it like the only way to access is to install client. But there's others like Smithery and all the other guys, right? But then Anthropic has also said they'll launch a model registry at some point or MCP registry at some point? Some point. If Anthropic launched the official one, would they just win by default, right? Because like, would you just use them?
Saoud [00:22:40]: I think so. I think the entire ecosystem will just converge around whatever they do. They just have such good distribution and they're, yeah, they came up with it. Yeah, exactly. Cool.
Most Popular MCPs and Their Use Cases
Swyx [00:22:49]: And then I wanted to, I noticed that you had some like really downloaded MCPs. I was going by most installs. I'm just going to read it off. You can stop me anytime to comment on them. So top is file system MCP. Makes sense. Browser tools from agent-AI. I don't know what that is. Sequential thinking. That one came out with the original MCP release. Context 7. I don't know that one.
Pash [00:23:12]: That's a big one. What is it? Context 7 kind of helps you pull in documentation from anywhere. And it has like this big index of all of the popular libraries and documentation for them. Okay. And you can, your agent can kind of submit like a natural language query and search for any documentation. It just says everyone's docs. Yes.
Swyx [00:23:33]: And apparently Upstash did that, which is also unusual because Upstash is just normally Redis. Git tools, that one came out originally. Fetch. Browser use. Browser use, I imagine, competes with browser tools, right? I guess. And then below that, playwright. Playwright, right? So there's a lot of. Like, let's automate the browser and let's do stuff. I assume for debugging. Firecrawl, Puppeteer, Figma. Here's one for you. Perplexity research. Is that yours?
Pash [00:23:59]: Well, yeah, I forked that one and listed it. But yeah, that's, you know, that's another very popular one where you can research anything.
Swyx [00:24:06]: So people want to emulate the browser. I'm just trying to learn lessons from what people are doing, right? They want to automate the browser. They want to access Git and file system. They want to access docs and search. Anything else? You think, like, it is notable?
Pash [00:24:21]: There's all kinds of stuff where it's like, you know, there's like the Slack MCP where you can send, you know, that's actually one workflow that I have set up where you can, like, automate repetitive tasks in Client. So I tell Client, like, OK, pull down this PR, use the GH command line tool, which I already have installed using the terminal to pull the PR, get the description of the PR, the discussion on it and get the full diff as like a like a single command, non-interactive command. Yeah. Pull in all that context, read the files around the diff, review it, ask a question like, hey, do you want me to approve this or not with this comment? And if I say yes, approve it and then send a message in Slack to my team using the Slack MCP, for example. Oh, use it to write. Yes. I would only use it to read. Yeah, no, it's, you know, people like I love it. You know, I love being able to just like send an automated message in Slack or whatever. You can also like set it up, like set up your workflow however you want, where it's like, OK, client. Please ask me before doing anything, you know, just make sure you're asking me to like approve before you send a message or something like that.
Challenges and Future of MCP Monetization
Swyx [00:25:26]: Yeah. OK, just just to close out MCP side, anything else interesting going on in MCP universe that we should talk about? MCP off was recently ratified.
Pash [00:25:34]: I think monetization is a big question right now for the MCP ecosystem. We've been talking a lot with Stripe. They're very bullish on MCP and they're trying to figure out like a monetization layer for it. But it's all so early that it's kind of hard to really even envision where it's going to go.
Swyx [00:25:55]: Let me just put up a straw man and you can tell me what's wrong with it. Like, how is this different from API monetization? Right. Like you sign up here, make an account, I give you a token back and then you use token. I charge you against your usage.
Pash [00:26:07]: No, like like I think that's how it is right now. That's how like the the magic MCP, the 21st dev guys did it. But we're kind of envisioning a world where agents can. Can pay themselves for these MCP tools that they're using and pay for each tool call and you can't deal with like a million different API keys from different products and like signing up for all this, there needs to be like a unified kind of payment layer. Some people talk about like stable coins, how like those are coming out now that agents can natively use those. Stripe is they're considering this like abstraction and around the MCP protocol for payments. But like I said, it's kind of hard to really tell where it's going. How that's going to manifest.
Swyx [00:26:50]: I would say like I covered when they launched their agent toolkit last year, a few months ago, it seemed like that was enough. Like you didn't seem to need stable coins except for the fact that they take like 30 cents every transaction. Yeah.
Alessio [00:27:04]: Have you seen people use the X402 thing by Coinbase to make this basically like the you can do a HTTP request that includes payment in it? What?
Pash [00:27:15]: Yeah, yeah, it's a it's been around forever. The 402 error that's like payment not accepted or something. Right. So, yeah, we've seen some people talking about that, like more like natively building that in. But yeah, nothing. Yeah, no one's really doing that right now.
Security and Trust Issues with MCPs
Swyx [00:27:32]: Anything you're seeing on like are people like in making MCP startups that are interesting?
Alessio [00:27:39]: Mostly around rehosting local ones and do remote and then basically do instead of setting up 10 MCPs, you have like a canonical URL that you put in. All of your tools and then expose all the tools from all the servers. Yeah, there's like MCP that run some of these tools.
Swyx [00:27:54]: Yeah, but I think it kind of has the same issues of how do you incentivize people to make better MCPs, you know, and will it be mostly first party or will it be a third party? Yeah, like your perplexity. MCP was the photo.
Pash [00:28:06]: What's wrong with the perplexity when with MCPs and installing them locally on your device, there's always a massive risk associated with that. And when an MCP is created by someone that. We have no idea who they are at any point. They might, you know, update the GitHub to like introduce some kind of malicious stuff. So even if you like verified it when you're listing it, you might change it. So I ended up having to fork a few of those to make sure that we lock that version down.
Swyx [00:28:33]: Oh, OK. So this is just like you're just forking it so that you don't change it. Yeah, without without. That's interesting. These are all the problems of a registry, right? Like that you need to ensure security and all that. Cool. I'm happy to move on. I would say like the last thing that's kind of curious. It's like if Anthropic hasn't hadn't come along and made MCP, what would have happened? What's the alternative history like? Would you have come with MCP?
Alternative History Without MCP
Saoud [00:28:56]: So we saw some of our competitors who have been kind of working on their own version of plug and play tools into these agents. They kind of had to natively create these tools and integrations themselves directly into their product. And so I think anybody in the space would have had to just do the laborious work of having to recreate these tools and integrations for So I think Anthropic just saved us all a lot of trouble and tapped into the power of open source and community driven development and allowed, you know, individual contributors to make an MCP for anything people could think of and really take advantage of people's imagination in a way that I think is necessary right now for us to really tap into full potential of this sort of thing.
Alessio [00:29:38]: So we've had, I think, a dozen episodes with different coding products. Yeah.
Market Positioning of Coding Agents and IDE Integration Matrix
Swyx [00:29:43]: And this, by the way, this this episode came directly after he tweeted about it. I think he tweeted about the Cloud Code episode where they were sitting right where you're sitting. Thanks for sharing the clip. Talking about RAG. Yeah.
Alessio [00:29:52]: Can you give people maybe the matrix of the market of, you know, you have like fully agentic, no IDE, you have agentic plus IDE, which is kind of yours. You have IDE with some co-piloting. How should people think about the different tools and what you guys are best at or maybe what you don't think you're best at?
Saoud [00:30:11]: I think what we're best at and like our ethos since the beginning is just meet the developers where they're at today. I think there is a little bit of insight and handholding these models need right now. And the IDE is sort of the perfect conduit for something like that. You can see the edits it's making. You can see the commands that it's running. You can see the tools that it's calling. It gives you the perfect UX for you to have the level of insight and control and be able to course correct the way that you need to to work with the limitations of these models today. But I think it's pretty obvious that as the models get better, you'll be doing less and less than that, less and less of that and more and more of the initial planning. And prompting and sort of have the trust and confidence that, you know, the model will be able to get the job done pretty much exactly how you want it to. I think there will always be a little bit of a gap in that these models will never be able to read our minds. So there will have to be a little bit of, you know, making sure that you give it the most comprehensive and sort of like all the details of what you want from it. So if you're a lazy prompter, you can expect a ton of friction and back and forth. You really get what you want. But I think we're all learning for ourselves as we work with these things, kind of the right way to prompt these things and to be explicit about what it is that we want and kind of how they hallucinate the gaps that they might need to fill to get to the end result and how we might want to avoid something like that. So what's interesting about Cloud Code is there isn't really a lot of insight into what the agent's doing. It kind of gives you this like checklist of what it's doing holistically at a high level. I don't think that really would have worked well if the models weren't good enough to actually produce. But I think the space has to catch up to, okay, maybe people don't need as much insight into these sorts of things anymore. And they are okay with letting an agent kind of get the job done. And really all you need to see is sort of the end result and tweak it a little bit before it's really perfect. And I think there is going to be different tools for different jobs. I think something like totally autonomous agent that you don't have a lot of insight into is great for maybe scaffolding. New projects, but for kind of the serious, more complex sorts of things where, you know, you do need a certain level of insight or you do need to kind of have like more engagement. You might want to use something that does give you some more insight. So I think these sorts of tools complement each other. So for example, writing tests or spinning off 10 agents to try to fix the same bug, you know, might be useful for a tool that doesn't require too much engagement from you. Whereas something that requires a little bit more creativity or imagination. Or extracting context from your brain requires a little bit more of insight into what the model is doing and a back and forth that I think client is a little bit better suited for.
Visibility and Autonomy in Coding Agents
Pash [00:32:57]: Like visibility into what the agent is doing. That's like one axis. And then another is autonomy, like how automated it is. And we have a category of companies that are focusing more on the use case of people that don't even want to look at code, which is like, you know, the lovables, the replets. Where. It's like you go in, you build an app, you might not even be technical and you're just happy with the result. And then you have kind of stuff that's kind of like a hybrid where it's, you know, for engineers, it's built for engineers, but you don't really have a lot of visibility into what's going on in a hood. This is like for like the vibe coders where they're, you know, fully, you know, letting, letting the AI take the wheel and building stuff very rapidly and lots of open source fans and, you know, people that are hobbyists enjoy coding in this. And then you get to like serious engineering teams where they can't really give everything over to the AI, at least not yet. And they need to have high visibility into what's going on every step of the way and make sure that they actually understand what's happening with their code. You're kind of handing off your production code base to this non-deterministic system and then hoping that you catch it in review if anything goes wrong. Whereas personally, the way I use AI, the way I use Cline is I like to be there every step of the way and kind of guide it in the right direction. So I know every step of the way, like as every file is being edited, I prove every single thing and make sure that things are going in the right direction. I have a good understanding as things are being developed, where it's going. So like this kind of hybrid workflow really works for me personally. But, you know, sometimes if I want to go full YOLO mode, I go ahead and just auto approve everything. And just step out for a cup of coffee and then come back and, you know, review the work.
Alessio [00:34:50]: My issue with this as an engineer myself is that we all want to believe that we work on the complex things. How have you guys seen the line of complex change over time? I mean, if we sat down having this discussion 12 months ago, complex was like much easier than today for the models. Do you feel like that's evolving quickly enough that like, you know, in 18 months, it's like you should probably just do four. Follow Gen Tech for like 75% of work, 80% of work, or do you feel like it's not moving as quickly as you thought?
Evolving Definition of Complexity in Programming Tasks
Saoud [00:35:21]: I think, I think what was complex a couple of years ago is totally different to what is complex today. Now, I think what we need to be more intentional about are the architectural decisions we make really early on and how the model kind of builds on top of that. If you have kind of a clear direction of where things are headed and what you want, you kind of have a good idea to what, how you might want to like lay the foundation for it. And I think what we might have considered complex a few years ago, algorithmic, you know, challenges, that's pretty trivial for models today and stuff that we don't really necessarily have to think too much about anymore. We kind of give it, you know, a certain expectation or unit test about what we want, and it kind of goes off and puts together the, you know, the perfect solution. So I think there's a lot more thought that has to go into tasteful architectural decisions that really comes down to you having experience with what works and what doesn't work. Having a clear idea. For the direction of where you want to take the project and sort of your vision for the code base. Those are all decisions that I think is hard to rely on a model for because of its limited context and its, you know, its inability to kind of see your vision for things and really have a good understanding of what you're trying to accomplish without you, you know, putting together a massive prompt of, you know, everything that you want from it. But I think what we were, you know, what we spent most of our time working on a couple years ago has totally changed. And I think for the better. I think architectural decisions are a lot more fun to think about than putting together algorithms.
Pash [00:36:49]: It kind of frees up the senior software engineers to think more architecturally. And then once they have a really good understanding of what's what the current state of the repository is, what the current state of the architecture is, and when they're introducing something new, they're really thinking at an architectural level. And they articulate that to Cline. And that's also there's like some skill involved there. And some of that can be mitigated with like asking follow up questions, being proactive about clarifying. Things on the agent side, but ultimately, you need to articulate this new architecture to the agent, and then the agent can go down and down into the mines and implement everything for you. And it is more fun working that way. Like, personally, like, I find it a lot more engaging to just think on a more architectural level and for junior engineers, it's a really good paradigm to learn about the code base. It's kind of like having a senior engineer in your back pocket where you're asking Cline. Like, hey, can you explain the repository for me? If I wanted to implement something like this, what files would I look at? How does this work? It's great for that as well.
Alessio [00:37:53]: If you're moving on from competition, I have one last question. Competition. Yeah. So there's Twitter beef with RooCode. I just want to know what the backstory is, because you tweeted yesterday, somebody asked RooCode to add Gemini CLI support, and then you guys responded, just copy it from us again. And they said, thank you. We'll make sure to give credit. Is it a real beef? No. Is it a friendly beef?
Forks of Cline and Open Source Regrets
Pash [00:38:16]: I think we're all just having fun on the timeline. There's a lot of forks.
Saoud [00:38:21]: There's like 6,000 forks.
Pash [00:38:23]: Yeah, there's like, if you search Cline in the VS Code marketplace, it's like the entire page is just like forks of Cline. And there's like even forks of forks that, you know, came out and raised like a whole bunch of money. What? Yeah, it's crazy.
Saoud [00:38:37]: The top three apps in OpenRouter are all Cline, and then Cline fork, Cline fork.
Pash [00:38:42]: It's funny. Yeah, billions of tokens getting sent through. Like all these forks, there's like, there's like fork wars and 10,000 forks and all you need is a knife, you know, so no, it's, it's exciting. Uh, I think they're all really cool people. We've got people in Europe forking us. We've got people in China making like a little fork of us. I think Samsung recently came out with like a, was a Wall Street Journal article where they're using Cline, but they're using like their own little fork of Cline. That's kind of isolated. You know, we, we encourage it.
Alessio [00:39:12]: Do you have any regrets about being open source?
Saoud [00:39:14]: Not at all. I think Cline started off as this like really good foundation for what a coding agent looks like, and people just had a lot of their own really interesting ideas and spinoffs and concepts about, you know, what they thought, you know, they, that they wanted to build on top of it was, and just being able to see that and see the excitement around, just in the space in general has just been, I think, inspirational and has helped us kind of glean insights into what works and what doesn't work and incorporate that into our own product. And for the most part, I think for, you know, the same. I think for many of us, like, you know, we've been so many years with Samsung and all of the organizations where there's a lot of friction and be able to use software like this on their, on their code bases, it reduces that barrier to entry, which I think is like incredibly important when you want to get your feet wet with this whole new agentic coding paradigm that's going to completely upend the way that we've written software for decades. So in the grand scheme of things, I think it's a net positive for the world and for the space. And so no regrets.
Simplicity vs Complexity in Agent Design
... [Content truncated due to size limits]