Cline：不以削减成本为目标的开源编码代理

I think Cline has a decent fan base, but not everyone has heard of it. Maybe we should get an upfront explanation: What is Cline, maybe from you? Then you can modify that as well.

Yeah. Cline is an open-source coding agent. It's a VS Code extension right now, but it's coming to JetBrains, Neovim, and the CLI. You give Cline a task, and it just goes off and does it. It can take over your terminal, your editor, and your browser, connect to all sorts of MCP services, and essentially take over your entire developer workflow. It becomes this point of contact for you to get your entire job done.

Pash, what would you modify, or what's another way to look at Cline that you think is also valuable?

Yeah. I think Cline is the infrastructure layer for agents—for all open-source agents and people building on top of this agentic infrastructure. Cline is a fully modular system. That's the way we envision it, and we're trying to make it more modular so that you can build any agents on top of it.

With the CLI and the SDK that we're rolling out, you're going to be able to build fully agentic systems for anything, not just coding.

Oh, okay. That is a different perspective on Cline than I had. Let's talk about coding first, and then we'll talk about the broader stuff.

1. The Plan And Act Workflow

You also are similar to Aider—I don't know who came first—in that you use the plan-and-act paradigm quite a bit. I'm not sure how well known this is. I'm relatively up to speed on it, but maybe you guys want to explain why you use different modes for different things.

Yeah. I'm going to take the credit for coming up with plan/act first.

Cline was the first to come up with this concept of having 2 modes for the developer to engage with. Just in talking to our users and seeing how they use Cline, when it was really only an input field, we found a lot of them starting off working with the agent and coming up with a Markdown file where they asked the agent to put together some kind of architecture plan for the work they wanted the agent to do.

We found that people just came up with this workflow for themselves organically. 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 pick up that pattern for themselves. They can direct the agent and put in guardrails for it to adhere to these different modes whenever the user switches between them.

For example, in plan mode, the agent is directed to be more exploratory, read more files, and get an understanding of the relevant information in its context to come up with a plan of attack for whatever task the user wants to accomplish. When they switch to act mode, that's when the agent gets the directive to look at the plan and start executing on it—running commands and editing files.

It just makes working with agents a little bit easier, especially with something like Cline, where a lot of the time people's engagement with it is mostly in plan mode. There's a lot of back and forth, a lot of extracting context from the developer, and asking questions like, “What do you want the theme to look like? What pages do you want on the website?” It's trying to extract any 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 get coffee or whatever while the agent gets the job done. Most of the engagement happens in plan mode. In act mode, they have a peripheral vision into what's going on, mostly to course-correct whenever it goes in the wrong direction. For the most part, they can just rely on the model to get it done.

Was this the first shape of the product, or did you get to plan/act iteratively? And was this the first idea for the company itself, or were you exploring other things?

It was a lot of experimenting, especially in the early days of Cline, and talking to our users to see what kinds of workflows they found useful and translating them into the product. Plan and act was really a byproduct of talking to people on our Discord and asking them what would be useful to them and what kinds of prompt shortcuts we could add to the UI.

That's really all plan and act mode is. It's essentially a shortcut for the user that saves them the trouble of having to type out, “I want you to ask me questions and put together a plan,” the way they might have to in some of the other tools. They would have to be explicit about, “I want you to come up with a plan,” before acting on it or editing files. Incorporating that into the UI just saves the user the trouble of having to type that out themselves.

But you started right away as a coding product, and then this was part of figuring out how to get a better user experience, basically.

Exactly.

What was the model evaluation at the time? I'm sure part of the reason for needing plan and act was that maybe the models weren't able to do it end to end. When you started working on that paradigm, what were the model limitations? What were the best models, and how has that evolved over time?

2. Claude 3.5 Unlocks Agentic Coding

When I first started working on Cline, this was, I think, 10 days after Claude 3.5 Sonic came out. I was reading Anthropic's model card addendum, and there was a section about agentic coding and how it was so much better at accomplishing tasks step by step. They talked about running this internal test where they let the model run in a loop and call tools.

It was obvious to me that they had some version and some application internally that was really different from the other things at the time, like Copilot, Cursor, and Aider. They didn't do this sort of step-by-step reasoning and task accomplishment. They were more suited for the Q&A and one-shot prompting paradigm.

At the time, I think it was June 2024, Anthropic was doing a Build with Claude hackathon. I thought this was a really cool new capability that none of the models had really been capable of before. I thought being able to create something from the ground up and take advantage of the nuances of how much the model had improved at that point in time would be valuable.

For example, Claude 3.5 was also really good at a test called “needle in a haystack.” If it has a lot of context in its context window—for example, 90% of its 200K context window is filled up—it's really good at picking out granular details in that context. Whereas before Claude 3.5, it would pay a lot more attention to whatever was at the beginning or the end of the context.

Just taking advantage of the nuances of it being better at understanding longer context and better at accomplishing tasks step by step let me create something that felt a little bit different from anything else that was around at the time.

Some of the core principles in building the first version of the product were to keep it really simple and let the developer feel like they could use it however they wanted. We made it as general as possible and let people come up with whatever workflows worked well for them.

People use it for all sorts of things outside of coding. Our product marketing guy, Nick Baumann, uses it to connect to a Reddit MCP server, scrape content, connect it to an X MCP server, and post tweets. Even though it's a VS Code extension and a coding agent, MCP lets it function as this everything agent, where it can connect to whatever services and things like that.

That's really a side effect of having very general prompts in the product and not limiting it to just coding tasks.

I was at a conference in Amsterdam, and I built my whole presentation—my whole slide deck—using this library. It's a JavaScript library called Slidev. I asked Cline, “Here are my style guidelines.” I wrote a big Cline rules document explaining how I wanted to style the presentation in Slidev.

I told Cline the agenda. I recorded my thoughts using another app called Limitless, which transcribed my voice into text—just stream-of-consciousness thoughts 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 Cline really can do anything.

In JavaScript?

In JavaScript, yeah.

So it's kind of a coding use case.

It was a coding use case, but then it was making a presentation out of it. It can also run scripts, do data analysis for you, and then put that into a deck. It can combine things.

3. The Extension Distribution Advantage

Being a VS Code extension gives you these interesting capabilities: you have access to the user's OS and terminal, and you can read and edit files. Being an extension also reduces a lot of the onboarding friction for developers, so they don't have to install a whole new application or go through internal hoops to get something approved for use within their organizations. The marketplace gave us a ton of really great distribution and is sort of the perfect conduit for something that needs access to files on your desktop, run things on your terminal, edit code, and take advantage of VS Code's really nice UI, showing you diff views, for example, before and after it makes changes to files.

Yeah.

Weren't you tempted to fork VS Code, though? I mean, you could be sitting on $3 billion right now.

Well, no. I actually pity anybody that has to fork VS Code because Microsoft makes it notoriously difficult to maintain these forks. A lot of resources and effort go into just keeping your fork up to date with all the updates that VS Code is making.

I see.

Is that because they have a private repo and just sync it? There's no—

Exactly. Exactly.

It's one of those kinds of open-source projects.

Right.

Yeah.

VS Code is moving so quickly that I'm sure they run into all sorts of issues, not just with things like merge conflicts, but also on the back end. They're always making improvements and changes to, for example, their VS Marketplace API. Having to reverse-engineer that and figure out how to make sure your users don't run into issues using things like that is, I'm sure, a huge headache for anybody who has to maintain a VS Code fork.

Being an extension also gives us a lot more distribution. It's not that you have to use us or somebody else: you can use Cline in Cursor, Windsurf, or VS Code. I think Cline complements all these things really well because we get the opportunity to figure out and work really closely with our users to determine what the best agentic experience is. Cursor, Windsurf, and Copilot have to think about the entire developer experience—the inline code edits, the Q&A, and all the other bells and whistles that go into writing code. We get to just focus on what I think is the future of programming, which is this agentic paradigm.

As the models get better, people are going to find themselves using natural language and working with an agent more and more, and spending less time in the weeds editing code and using tab autocomplete.

Just imagine how many resources you would have to spend maintaining a fork of VS Code. We can just stay focused on the core agentic loop, optimizing for different model families as they come out and supporting them. There is so much work that goes into all this that maintaining a fork on the side would just be such a massive distraction for us. I don't think it's really worth it.

I feel like when you talk, I hear this distinction between wanting to be the best thing for the future of programming, and this also being great for non-programming. Is this something that's recent for you, where you're seeing more and more people use MCP servers to do less technical things, and that's an interesting area? Or do you feel like programming is still the highest-economic-value thing to be selling today? I'm curious if you can share more.

In terms of economic value, programming is definitely the highest cost-to-benefit use case for language models right now. I think we're seeing a lot of model labs recognize that. OpenAI and Anthropic are taking coding a lot more seriously than I think they did a year ago.

While 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 fix the bug using the stack-trace information. The developer connected to a GitHub MCP server to close the issue and deploy the fix to Cloudflare, all within Cline, using natural language and never having to leave VS Code.

Cline interacts with all these services that the developer otherwise would have had the cognitive overload of figuring out and leaving their development environment to use manually. It can essentially do what the agent could have done, all in the background, using natural language. I think that's where things are headed: the application layer being connected to all the different services that you might have had to interact with manually, and becoming this single point of contact for you to interact with using natural language. You are less and less in the code and have more and more of a high-level understanding of what the agent is doing, with the ability to course-correct.

I think that's another part of what's important to us and what's allowed us to cut through the noise in this incredibly noisy space. A lot of people have really grand ideas for where things are heading, but we've been really maniacal about what's useful to people today. A large part of that is understanding the limitations of these models and what they're not so good at, and giving the end developer enough insight into those things so that they know how to course-correct and how to give feedback when things don't go right.

For example, Cline is really good about giving you a lot of insight into the prompts going into the model, when there's an error and why the error happened, and the tools that the model is calling. We try to give as much insight as possible into what exactly the model is doing at each step to accomplish a task. When things 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 incredibly important for getting work done much more quickly than if you were to give a background agent some work, come back a couple of hours later, and find that it's totally wrong and didn't do anything you expected it to do. You then have to retry a couple of times before it gets it right.

I think the Sentry example is great because I feel like, in a way, the MCPs are cannibalizing the products themselves. I started using the Sentry MCP, and then Sentry released Here, which is their issue-resolution agent. It was free at the start, so I turned it on in Sentry and used it, and it was great. 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 have this closed loop: are these MCPs going to become the paid AI offering that you can plug in? Is Cline going to have an MCP subscription where you're fractionalizing all these costs? To me, today, it doesn't make a lot of sense the way they're structured.

4. MCP Builds The Agent Ecosystem

Well, yeah. Very early on, we've been bullish on MCP from the very beginning.

Were you a launch partner?

Sorry to interrupt.

Yeah, no worries.

I think when Anthropic first launched MCP and made this big announcement about this new protocol that they had been working on and open-sourcing, nobody really understood what it meant. It took me some time to really dig into their documentation about how it worked and why it was important. I think they made this bet on the open-source community contributing to an ecosystem in order for it to really take off, and I wanted to try to help with that as much as possible.

For a long time, most of Cline's system prompt was about how MCP worked because it was so new at the time that the models didn't know anything about it or how to make MCP servers. If a developer wanted to make something like that, Cline would be really good at it. I'd like to think that Cline had something to do with how much the MCP ecosystem has grown since then, by giving developers more insight into and awareness of how it works under the hood. I think that's incredibly important for using it, let alone developing these things.

When we launched MCP in Cline, I remember our Discord users trying to wrap their heads around it. Seeing Cline users build MCP servers from the ground up helped them connect the dots: "Okay, this is how it works under the hood. This is why it's useful. This is how agents connect to these tools, services, and APIs, and it saved me a lot of the trouble of having to do this stuff myself."

Those were the early days of MCP, when people were still trying to wrap their heads around it.

Yeah.

And there was a big problem with discoverability. Back in February, we launched the MCP marketplace, where you could go through a one-click installation process. Cline would look at a README linked to GitHub, install the whole MCP server from scratch, and get it running immediately. Around that time, I think MCP really started taking off with the launch of the marketplace. People were able to discover MCPs and contribute to the MCP marketplace.

We've listed over 150 MCP servers since then, and the top MCPs in our marketplace have hundreds of thousands of downloads and people using them. There are notable examples where, as you mentioned, MCPs are kind of eating existing products. At the same time, we're starting to see this ecosystem evolve, where people are monetizing MCPs. A notable example is the 21st.dev Magic MCP server, which injects some taste into a coding agent and the LLM. They have a library of beautiful components, and they inject relevant examples so that Cline can implement beautiful UIs. They monetize it with a standard API key. So we're starting to see developers take MCPs, build them in, use distribution platforms like the MCP marketplace in Cline, and monetize their whole business around that. Now it's almost like you're selling tools to agents, which is a really interesting topic.

And you can do that because you're in VS Code, so you have the terminal. You can run npx to run the different servers.

Yes.

Have you thought about doing remote MCP hosting, or do you feel like that's not something you should take over?

Yeah, we haven't hosted any ourselves. We're looking into it. I think remote MCPs are all very nascent right now. But we're definitely interested in supporting remote MCPs and listing them on our marketplace.

Another part, I think, with local MCP servers and remote MCPs is that most remote MCPs are only useful for connecting to different APIs. But 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 a Unity MCP server that helps you create thirty objects right from within VS Code. There's an Ableton MCP server, so you can make songs using something like Cline 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 and remote MCP servers.

I think the remote MCP servers do make the installation process a little bit easier, with something like an OAuth flow and just authenticating a little bit. It's not as painful as having to manage API keys yourself. But for the most part, I think the MCP ecosystem is really in its early days. We're still trying to figure out the right balance of security and convenience for the end developer, so that it's not a pain to have to set these things up. I think we're still very much in an experimental phase of figuring out how useful it is to people.

Now that it's seeing this level of market fit, and people are coming out with articles and workflows about how it's totally changing their jobs, I think there are going to be a lot more resources and efforts that go into the ecosystem and building out the protocol. I think there's a lot on Anthropic's roadmap, and the community in general has a lot of ideas. Our marketplace, in particular, has given us insights into ways we could improve it and things that developers have asked for. We're thinking about what the MCP marketplace of the future looks like.

For us, it's going to be a combination of several things. A lot of our users are very security-conscious, and there are a lot of ways MCP servers can be pretty dangerous to use if you don't trust the end developer of these things. We're trying to figure out what a future looks like where you have some level of confidence in the MCP servers you're installing. Right now, it's just too early, and there's a lot of trust in the community that I don't think many enterprise developers or organizations are quite willing to place yet. That's top of mind for us.

There's an interesting tension between Anthropic and the community here. You basically have an 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. The only way to access it is to install Cline. But there are others, like Smithery and all the other guys, right? Anthropic has also said they'll launch an MCP registry at some point.

At some point.

If Anthropic launches the official one, would they just win by default? Because would you just use them?

I think so. I think the entire ecosystem will just converge around whatever they do. They have such good distribution.

Yeah.

They came up with it.

Cool. I wanted to ask about some of the most downloaded MCPs. I was going by most installs, so I'm just going to read them off. You can stop me anytime to comment on them. The top is the filesystem MCP. Makes sense. Browser Tools from AgentDeskAI—I don't know what that is. Sequential Thinking; that one came out with the original MCP release. Context7—I don't know that one.

That's a big one.

What is it?

Context7 helps you pull in documentation from anywhere, and it has a big index of all the popular libraries and their documentation. Your agent can submit a natural-language query and search for any documentation.

It just has everyone's docs?

Yes.

But apparently Upstash did that, which is also unusual because Upstash is normally just Redis.

Mm-hmm.

Git tools—that one came out originally. Fetch. Browser Use. Browser Use, I imagine, competes with Browser Tools, right?

Yeah, there's some competition.

And then below that, Playwright. Playwright, right? So there's a lot of, “Let's automate the browser, and let's do stuff.” I assume for debugging. Then there are Firecrawl, Puppeteer, and Figma. Here's one from Perplexity Research. Is that yours?

I forked that one and listed it. That's another very popular one where you can research anything on Perplexity.

So people want to automate the browser. I'm just trying to learn lessons from what people are doing, right? They want to automate the browser, access Git and the filesystem, access docs, and search. Anything else that you think is notable?

There's all kinds of stuff. There's the Slack MCP, where you can send messages. That's actually one workflow I have set up to automate repetitive tasks in Cline. I tell Cline, “Pull down this PR, use the GitHub command-line tool,” which I already have installed, using the terminal to pull the PR, get its description and the discussion on it, and get the full diff as a single, noninteractive command. Pull in all that context, read the files around the diff, review it, and ask me, “Do you want me to approve this or not with this comment?” 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.

People—I love it. I love being able to send an automated message in Slack or whatever. You can also set it up however you want: “Cline, please ask me before doing anything. Just make sure you're asking me to approve before you send a message,” or something like that.

Just to close out the MCP side, is there anything else interesting going on in the MCP universe that we should talk about? MCP Auth was recently ratified.

5. MCP Monetization Remains Unsolved

I think monetization is a big question right now for the MCP ecosystem.

Okay.

We've been talking a lot with Stripe. They're very bullish on MCP, and they're trying to figure out a monetization layer for it. But it's all so early that it's kind of hard to even envision where it's going to go.

Let me just put up a straw man, and then you can tell me what's wrong with it.

Mm-hmm.

How is this different from API monetization? You sign up here, make an account, I give you a token back, and then you use the token, and we charge you based on your usage.

No, I think that's how it is right now. That's how the Magic MCP—the 21st.dev guys—did it. But we're kind of envisioning a world where agents can pay themselves for the MCP tools they're using and pay for each tool call, and you can't deal with a million different API keys from different products and signing up for all this. There needs to be a unified payment layer. Some people talk about stablecoins, which are coming out now and that agents can natively use. Stripe is considering this abstraction around the MCP protocol for payments. But like I said, it's hard to really tell where that's going to manifest.

Yeah. I would say—I covered it when they launched their agent toolkit a few months ago. It seemed like that was enough. You didn't seem to need stablecoins, except for the fact that they take $0.30 every transaction.

Have you seen people use the x402 thing by Coinbase? It's basically like—you can do an HTTP request that includes payment in it.

What?

Yeah, it's been around forever, the 402 error that's payment not accepted or something, right? So we've seen some people talking about that, more natively building that in.

Anything you're seeing? Are people making MCP startups that are interesting?

Mostly around rehosting local ones and making them remote. Basically, instead of setting up 10 MCPs, you have a canonical URL that you put in all of your tools and then expose all the tools from all the servers.

Yeah.

There's mcp.run and some of these tools.

Yeah.

But I think it kind of has the same issues: How do you incentivize people to make better MCPs and charge people for them?

And will it be mostly first-party or third-party?

Yeah, exactly.

Your Perplexity MCP was the fork. What was wrong with the Perplexity one?

With MCPs and installing them locally on your device, there's always a massive risk associated with that. When an MCP is created by someone we have no idea who they are, at any point they might update the GitHub to introduce some kind of malicious stuff. So even if you verified it when you were installing it, they might change it. I ended up having to fork a few of those to make sure that we lock that version down.

Okay. So this is just—

Yeah.

You're just forking it so that it doesn't change without your permission.

Yes.

Interesting. These are all the problems of a registry, right? You need to ensure security and all that. Cool. I'm happy to move on. I would say the last thing that's kind of curious is: If Anthropic hadn't come along and made MCP, what would have happened? What's the alternative history? Would you have come up with MCP?

We saw some of our competitors who had been working on their own versions of plug-and-play tools for these agents. They kind of had to natively create these tools and integrations themselves, directly into their products. I think anybody in this space would have had to do the laborious work of recreating these tools and integrations.

I think Anthropic just saved us all a lot of trouble and tapped into the power of open source and community-driven development. They allowed 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 the full potential of this sort of thing.

We've had, I think, a dozen episodes with different coding products.

Yeah. By the way, this episode came directly out after he tweeted about Claude Code, the episode.

Our Claude Code. Mm-hmm.

Where you're sitting, right where you're sitting.

Thanks for sharing the clip.

I'm a RAG, yeah.

Can you give people maybe the matrix of the market? You have fully agentic, no IDE. You have agentic plus IDE, which is kind of yours. You have IDE with some copiloting. 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?

6. Choosing The Right Agent

I think what we're best at, and our ethos since the beginning, is just meeting the developers where they're at today. There is a little bit of insight and hand-holding that 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, the commands that it's running, and the tools that it's calling. It gives you the perfect UX to have the level of insight and control you need and to be able to course-correct the way you need 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 of that and more and more of the initial planning and prompting, and having the trust and confidence that 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 making sure that you give it all the details of what you want from it.

If you're a lazy prompter, you can expect a ton of friction and back-and-forth before you really get what you want. But I think we're all learning for ourselves, as we work with these things, the right way to prompt them and to be explicit about what it is that we want. We're learning 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.

What's interesting about Claude Code is there isn't really a lot of insight into what the agent's doing. It kind of gives you this checklist of what it's doing holistically, at a high level. I don't think that really would've worked well if the models weren't good enough to actually produce work that people were generally happy with. We're kind of there, and I think the space has to catch up to the idea that maybe people don't need as much insight into these sorts of things anymore, and they are okay with letting an agent get the job done.

Really, all you need to see is the end result and tweak it a little bit before it's really perfect. I think there are going to be different tools for different jobs. A totally autonomous agent that you don't have a lot of insight into is great for maybe scaffolding new projects. But for the serious, more complex sorts of things where you do need a certain level of insight or more engagement, you might want to use something that gives you more insight.

I think these sorts of tools complement each other. For example, writing tests or spinning off 10 agents to try to fix the same bug 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 insight into what the model's doing and a back-and-forth that I think Cline is a little bit better suited for.

You also have visibility into what the agent is doing. That's one axis. Another is autonomy—how automated it is. We have a category of companies that are focusing more on the use case of people who don't even want to look at code, like Lovable and Replit, where you go in, build an app, and might not even be technical, and you're just happy with the result.

Then you have stuff that's kind of a hybrid. It's for engineers, built for engineers, but you don't really have a lot of visibility into what's going on under the hood. This is for the vibe coders who are fully letting the AI take the wheel and building stuff very rapidly. Lots of open source fans and hobbyists enjoy coding in this manner, and it is really fun.

Then you get to serious engineering teams, where they can't really give everything over to the AI, at least not yet. They need to have high visibility into what's going on at every step of the way and make sure that they actually understand what's happening with their code. You're handing off your production codebase to this nondeterministic system and then hoping that you catch it in review if anything goes wrong.

Personally, the way I use AI, the way I use Cline, is that I like to be there every step of the way and guide it in the right direction. That way, I know every step of the way—as every file is being edited, I approve every single thing and make sure that things are going in the right direction. I have a good understanding, as things are being developed, of where they're going.

This kind of hybrid workflow really works for me personally. But sometimes, if I want to go full YOLO mode, I go ahead and auto-approve everything, step out for a cup of coffee, then come back and review the work.

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 complexity change over time? If we sat down to have this discussion 12 months ago, “complex” was much easier for the models than it is today. Do you feel like that’s evolving quickly enough that, in 18 months, you should probably just do full agentic for 75% or 80% of work, or do you feel like it’s not moving as quickly as you thought?

I think what was complex a couple of years ago is totally different from what is complex today. Now, I think what we need to be more intentional about is the architectural decisions we make really early on and how the model builds on top of that. If you have a clear direction of where things are headed and what you want, you have a good idea about how you might want to lay the foundation for the code base that you’re producing. I think what we might have considered complex a few years ago—algorithmic challenges—is pretty trivial for models today, and stuff that we don’t necessarily have to think too much about anymore. We give it a certain expectation or unit test about what we want, and it goes off and puts together the perfect solution.

There’s a lot more thought that has to go into tasteful architectural decisions. That really comes down to 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 having a vision for the code base. Those are all decisions that I think are hard to rely on a model for because of its limited context and its inability to see your vision for things and really have a good understanding of what you’re trying to accomplish without you putting together a massive prompt of everything that you want from it. I think what we spent most of our time working on a couple of years ago has totally changed, and I think for the better. I think architectural decisions are a lot more fun to think about than—

Yeah.

—putting together algorithms.

It kind of frees up senior software engineers to think more architecturally. Once they have a really good understanding of what the current state of the repository is and what the current state of the architecture is, when they’re introducing something new, they’re really thinking at an architectural level. They articulate that to Cline, and there’s some skill involved there as well. Some of that can be mitigated by asking follow-up questions and 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 into the mines and implement everything for you.

It is more fun working that way. Personally, I find it a lot more engaging to think at a more architectural level. For junior engineers, it’s a really good paradigm for learning about the code base. It’s kind of like having a senior engineer in your back pocket, where you’re asking Cline, “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.

If we’re moving on from competition—

Okay.

—I have one last question—

Yes.

—on competition.

Yeah.

So there’s Twitter beef with Roo Code. I just want to know what the backstory is, because you tweeted yesterday that somebody asked Roo Code to add Gemini CLI support, and then you guys responded, “Just copy it from us again.” They said, “Thank you. We’ll make sure to give credit.” Is it a real beef?

No, no.

Is it a friendly beef? What’s the—

I think we’re all just having fun on the timeline. There are a lot of forks—

There are 6,000 forks now.

Yeah, there’s… If you search Cline on the—

What?

—on the VS Code Marketplace, the entire page is just forks of Cline. There are even forks of forks that came out and raised a whole bunch of money, and it’s—

What?

Yeah. It’s crazy.

The top 3 apps on OpenRouter are all Cline—

Cline forks?

—and then Cline fork, Cline fork. Yeah, it’s funny.

Billions of tokens are getting sent through all these forks.

Yeah.

There are fork wars and 10,000 forks, and all you need is a knife. No, it’s exciting. I think they’re all really cool people. We’ve got people in Europe forking us. We’ve got people in China making a little fork of us. I think Samsung recently came out with a… Was it a Wall Street Journal article where they’re using Cline, but they’re using their own little—

Right.

—fork of Cline that’s kind of isolated? You know—

Yeah.

—we encourage it.

Do you have any regrets about being open source?

Not at all.

I think Cline started off as this really good foundation for what a coding agent looks like. People had a lot of their own really interesting ideas, spinoffs, and concepts about what they wanted to build on top of it. Being able to see that and see the excitement around the space in general has been inspirational and has helped us glean insights into what works and what doesn’t work and incorporate that into our own product.

For the most part, I think that for the Samsungs and all the organizations where there is a lot of friction in being able to use software like this on their code bases, it reduces that barrier to entry. I think that’s 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. In the grand scheme of things, I think it’s a net positive for the world and for the space, so no regrets.

7. Open Source Rewards Simplicity

In a lot of ways, it’s us and the forks. We were there originally when we were the only ones with this philosophy of keeping things simple, keeping things down to the model, letting the model do everything, not cutting corners, not trying to make money off inference, going context-heavy, and reading files into context very aggressively.

Going back to Claude Code, it was really nice to see that they came out and validated our whole philosophy of keeping things as simple as possible. That also goes along with the whole RAG thing. RAG was this early thing in 2022. You started getting these vector database companies. People called it, “Oh, you can give your AI infinite memory.” It’s not really that, but that was the marketing that was sold to the venture backers who were investing in all these companies, and it became this narrative that really stuck around.

Even now, we get potential enterprise prospects going through the procurement process, and it’s almost like they’re going through a checklist asking, “Hey, do you guys do indexing of the code base and RAG?” And I’m like, “Well, why? Why do you want to do this?” I think it was said very well on this exact podcast: We tried RAG, and it doesn’t really work very well, especially for coding. The way RAG works is you have to chunk all these files across your entire repository, chop them up into small pieces, throw them into this high-dimensional vector space, and then pull out these random chunks when you’re searching for relevant code snippets. Fundamentally, it’s so schizo, and I think it actually distracts the model, and you get worse performance than just doing what a senior software engineer does when they’re first introduced to a new repository: You look at the folder structure, you look through the files, and say, “Oh, this file imports from this other file. Let’s go take a look at that.” You agentically explore the repository. That’s what we found works so much better.

There are similar things where simplicity always wins, like the bitter lesson. Fast Apply is another example. Cursor came out with this Fast Apply—they called it Instant Apply—back in July 2024. The idea was that models at the time were not very good at editing files. The way editing files works in the context of an agent is that you have a search block and then a replace block, where you have to match the search block exactly to what you’re trying to replace, and then the replace block just swaps that out.

And at the time, models were not very good. I forget which GPT model they were using under the hood at the time, but it wasn't very good at formulating these search blocks perfectly, and it would often fail.

So they came up with this clever workaround: they fine-tuned this Fast Apply model. They let the frontier models at the time be vague and output those lazy code snippets we're all very familiar with, such as “rest of the file here” or “rest of the imports here,” and then fed that into this fine-tuned Fast Apply model. It was probably a quantized Qwen 7B or something—a very small, dinky little model.

They fed this lazy code snippet into the smaller model, which was fine-tuned to output the entire file with the code changes applied. One of the founders of Aider said this really well in very early GitHub discussions: “Well, now instead of worrying about one model messing things up, now you have to worry about 2 models messing things up.”

What's worse is that the other model you're handing your production code to—the Fast Apply model—is a tiny model. Its reasoning is not very good. Its maximum output might be 8,000 or 16,000 tokens. Now they're training them to 32,000 tokens, maybe.

A lot of coding files are longer than that. We have a file in our repository that's 42,000 tokens long, which is longer than the maximum output length of one of these smaller Fast Apply models. So what do you do then? You have to build workarounds around that. You have to build all this infrastructure to pass things off, and then it's making mistakes.

They're very subtle mistakes, too. It looks like it's working, but it's not actually what the original frontier model suggested. It's slightly different, and it introduces all of these subtle bugs into your code.

What we're starting to see is that as AI gets better, the application layer is being reduced. You're not going to need all these clever workarounds or have to maintain these systems. It's really liberating not to be bogged down with RAG or Fast Apply, and just focus on the core agentic loop and minimizing diff-edit failures.

In our own internal benchmarks, Claude Sonnet 4 recently hit a sub-5%—actually, around a 4%—diff-edit failure rate. When Fast Apply came out, that was much higher, in the 20s and 30s. Now we're down to 4%.

How does it go to 0?

Well, it's going to 0 as we speak. It's going to 0 every day.

I was actually talking with the founders of some of these companies that do Fast Apply. They were trying to work with us. Their whole bread and butter is fine-tuning these Fast Apply models—Relace and Morph.

I had a very candid conversation with these guys where I asked, “There was a window of time where Fast Apply was relevant. Cursor started this window of time back in July. How much time do you think we have left until they're no longer relevant? Do you think it's an infinite time window?”

They said, “No, it's definitely finite. This era of Fast Apply models is definitely coming to an end.”

I asked, “How long do you guys think?”

They said, “Maybe 3 months, maybe less.”

I still think there are some cases where RAG is useful. If you have a lot of human-readable documents or a large knowledge base of documents where you don't really care about the inherent logic within them, sure, index it, chunk it, and do retrieval on it. Fast Apply might be useful if your organization is forced to use a very small model that's not very good at search and replace, like a DeepSeek or something.

I think RAG and Fast Apply were just tools in a toolkit for when models weren't the greatest at large context or search-and-replace diff editing. But now they're extra ingredients that could make things go wrong, and you just don't need them anymore.

There was an interesting article from Cognition Labs about multi-agent orchestration.

Oh, getting right into it.

Yeah.

You're on autopilot for us. That's right.

Yeah, they—

It's a great article, by the way.

They talked about how, when you start working with different models and different agents, a lot gets lost in the details. The devil is in the details. Those are the most important things, and you have to make sure that you don't have agents running in loops, running into the same issues again, and that they have all the right context.

I think being close to the model, throwing all the context you need at it, and not taking this cost-optimized approach to pulling in relevant context—using something like RAG or a cheaper model to apply edits to a file—is ultimately better. Yes, it's more expensive to ask a model like Claude Sonnet to do all these things, grep an entire codebase, and fill up its entire context, but you kind of get what you pay for.

I think that's been another benefit of being open source: our developers can peek under the hood. They can see where their requests are being sent and what prompts are going into these things. That creates a certain level of trust. When they spend $10, $20, or $100 a day, they know where their data is being sent, what model it's being sent to, and what prompts are going into these things. So they get comfortable with the idea of spending that much money to get the job done.

Yeah. It's like not making money off inference. I think the incentives are so relevant in this discussion because if you're incentivized to charge $20 per month and you're trying to make money on that, you're going to be offloading all kinds of important work to smaller models or optimizing for cost with RAG—retrieving with RAG instead of reading the entire file, and maybe reading only a small snippet of it.

Whereas if you're not making money off inference and you're just going direct—users can bring their own API keys—then all of a sudden you're not incentivized to cut down on cost. You're actually incentivized just to build the best possible agent.

We're starting to see this trend: the whole industry is moving in that direction. You're starting to see everyone open up to pay-as-you-go models or pay directly for inference, and I think that is the future.

What's the Cline pricing business model?

8. Bring Your Own API Key

Right now, it's bring your own API key. Essentially, you use whatever pre-commitment you might have to whatever inference provider and whatever model you think works best for your type of work. You just plug in your Anthropic, OpenAI, or OpenRouter API key into Cline, and it connects directly to whatever model you select.

I think that level of transparency—where we're building the best product and not focused on capturing margin through price obfuscation, clever tricks, and model orchestration to keep costs low for us and optimize for higher profits—has put us in this unique position to really push these models to their full potential. I think that's shown. You get what you pay for. Throw a task into Cline and it gets expensive, but—

That's the cost of intelligence, right?

It's the cost of intelligence, yeah.

Yeah.

The business model right now is that you get to choose where—It's open source. You can fork it. You can choose where your data gets, and you can choose who you want to pay. A lot of organizations we've talked to get some volume-based discounts with these providers, and so they can take advantage of that through Cline, which is helpful because Cline can get pretty expensive.

Wait, so I'm still not hearing how you make money. You said you don't—

Why?

Why make money?

Yeah.

Because you have to pay your salaries.

A lot of people ask us that, and I always just throw the “why?” at them. But it's—

They sound like the Partiful guys. Partiful is like—

The real answer is enterprise.

Which we can say because we're releasing this when you launch it.

Yeah. So you want to talk about enterprise?

Yeah. I think being open source and bringing your own API key has given us a lot of easy adoption in these organizations where data privacy, control, and security are top of mind. It's hard to commit to sending their code in plain text to God knows what servers or training models on their data that might output their IP to random users.

I think people are a lot more conscious about where their data is getting sent and what's being done with it.

And so it’s given us this opportunity to say, “Okay, nothing passes through our own servers. You have total control over the entire application and where your data gets sent.” That’s given the organizations we’ve been talking to over the course of the last couple of months this sort of easy adoption, and I think it’s given us an opportunity to work more closely with them and say, “What are all the things that we can do to help with adoption in the rest of your organization?”

Essentially, how can we pour gasoline on the evangelism that people have for Cline in these organizations and spread the usage of agentic coding at an enterprise level?

Well, yeah, what’s crazy is we open-sourced Cline. People really liked it. Developers were using it within their organizations, and their organizations were reluctantly okay with it because they saw that we’re open source and not sending their data anywhere. They could use their existing API keys.

Then we launched a contact form for enterprise on our website: “If you’re interested in an enterprise offering, hit us up.” We had no real enterprise product at the time. It turned out that we got this massive influx of big enterprises reaching out to us.

We had a Fortune 5 company come up to us, and they were like, “Hey, we have hundreds of engineers using Cline within our organization, and this is a massive problem for us. This is a fire that we need to put out because we have no idea what API keys they’re using, how much they’re spending, or where they’re sending their data. Please just let us give you money to make an enterprise product.” So the product kind of just evolved out of that, right?

Right. Right. I mean, it really just comes down to listening to our users. Right after we put out this page, we had a lot of demand for the table-stakes enterprise features: the security guardrails, governance, and insights that admins in these organizations need to reliably use something like Cline.

We’ve gotten a lot of people wanting us to give them 2 things: invoices, just to help with all the budgeting and spending thousands of dollars—

All the Europeans.

Yeah. The other thing, which I thought was a little bit surprising, was some level of insight into the benefit that Cline’s providing them. It could be hours saved or lines of code written, because it allows these AI-forward drivers for adopting these sorts of tools in these organizations to take that as a proof point and go to the rest of their teams and say, “This is how much Cline’s helping me. You need to start adopting this so we can keep up with the rest of the industry.”

This is for internal champions to prove the ROI?

Exactly.

Okay.

Use it as evidence to justify the spend—

Yeah.

—but also to promote the product in these organizations.

We can do this afterward, but we’d like to talk to some of those people and actually feature what they’re saying to their bosses on the podcast so that we can get a sense. Oftentimes, we only talk to founders and builders of the dev tool, but not the end consumer.

Yeah.

We want to hear from them about how they’re thinking about it and what they need. It could be kind of cool.

One thing I wanted to double-click on is the relationship between OpenRouter and your enterprise offering. My understanding is that currently everything runs through OpenRouter.

Not everything. You can bring API keys to OpenAI, Anthropic, or Bedrock—

And then you have a direct connection there if I—

The user has a direct connection there.

Yeah, great. But everything else would run through OpenRouter, and so basically the enterprise version of Cline would be that you have your own OpenRouter that you would provide visibility and control to that enterprise.

Yeah, that’s for the self-hosted option, right? There are a lot of enterprises that are okay with not self-hosting, as long as they’re using their own Bedrock API keys and things like that. Whereas the ones that are really interested in self-hosting, or that want to be able to manage their teams, would have this internal router going on.

Yeah.

The curious thing here is, what if model costs just go to zero? What if Gemini Code comes out and it’s like, “Yeah, guys, it’s free”?

Well, yeah, they—

That’d be great for us.

Yeah.

That’d be great for us.

Our thesis is that inference is not the business.

You would just never make money on inference, right?

Yeah. We want to give the end user total transparency into price, which I think is incredibly important to even get comfortable with the idea of spending as much money as you do.

The price obfuscation in this space has given developers this reluctance to opt into usage-based plans. We’re seeing a lot of people converge on this concept of having a base plan just to use the product, but getting out of the way of the inference and respecting the end developer enough to give them insight not just into the cost, but also into the models being used.

That gives them more confidence in spending however much it takes to get the work done. You can use tricks like RAG and faster models to keep costs low, but for the most part, there’s enough ROI on coding agents that people are willing to spend money to get the job done.

Yeah.

For a truly good coding agent, the ROI is almost hard to even calculate because there are so many things that I would have never even bothered doing. But now I have Cline, and I could just do this weird experiment or side project, or fix this random bug that I would have never even thought about. So how do you measure that?

Yeah.

Right?

9. Background Agents Go Autonomous

One variant of this problem I wanted to touch on before we move on to context engineering and memory and all the other stuff is background agents and multi-agents.

The instantiations of this now, I would say, are background agents. It would be Codex, for example, spinning up 1 PR per minute, or Devin from Cognition. So would you ever go there? That’s one concrete question I can ask you: would there be Cline on the server, whatever?

The other version is still on the laptop, but with more parallel agents. Kanban is currently very hyped; people are making Kanban interfaces for Cursor and also for Claude Code. Anything in a parallel or background side of things.

Yeah.

We’re releasing a CLI version of Cline, and using the CLI version of Cline, it’s fully modular. You can ask Cline to run the CLI to spin up more clients, or you could run Cline in some kind of cloud process, in a GitHub Action—whatever you want.

The CLI is really the form factor for these kinds of fully autonomous agents. It’s also nice to be able to tap into an existing Cline CLI running on your computer and take over and steer it in the right direction. That’s also possible. But what do you think, Saoud?

I don’t think it’s an either/or. I think all these different modalities complement each other really well. Codex, Devin, and Cursor’s background agent all accomplish the same thing. If we were to come out with our own version of it, I’d say that it would be the foundation for how other developers could build on top of it.

Nick’s older brother, Andre, is thinking 10 years ahead, and it always kind of blows my mind when I hear some of the ideas he has about where the space is going. We recently had a discussion about building this open-source framework for coding agents for any sort of platform.

Building the SDK and the tools necessary to bring Cline to Chrome as an extension, to the CLI, to JetBrains, to Jupyter Notebooks—

Mm.

—to your smart car, whatever it is.

Your fridge.

Your fridge, exactly.

The microwave, maybe.

Yeah, exactly. I mean, this is what we saw with the 6,000 forks on top of Cline. We put together this foundation that this community of developers could build on top of and take advantage of—their experiments, their imagination, and their creativity about where the space is headed.

I think, looking forward, building an open-source foundation and the building blocks for how we bring something like Cline to things that go outside the scope of software development or a VS Code extension will open the door to things that ultimately complement each other really well. But it’ll never be this either/or thing.

I think background agents are good for certain kinds of work, and parallel Kanban multi-agents might be good for when you want to experiment and iterate on 5 different versions of how a landing page might look. Then something like a back-and-forth with a single agent like Cline works really well for when you want to pull context and put together a really complicated plan for a really complex task. I think all these different tools will ultimately end up complementing each other, and people will develop a taste and an understanding for what works best for what kind of work. But looking 10 years ahead, I think we at the very least want to be at the frontier of providing the building blocks for what comes after background agents or multi-agents.

10. Context Engineering And Memory

I was going to go into context engineering, kind of the topic du jour. I think this is similar-ish in the thread to RAG and how RAG is a mind virus, which I love, by the way—the way that you phrased it. You have context management in your docs. You also have a section on Memory Bank, which is kind of cool. I think a lot of people are trying to figure out memory. Let's just start at a high level, and then we'll go into memory later. What does context engineering mean to you?

Context engineering means to me?

Means prompt engineering.

Yeah. Right. I think there is a lot of art to what goes in there. I think that really is the 80/20 of building a really good agent: figuring out what goes into the context. I think the interplay between MCP, the system, the client, and recommended prompts is ultimately what makes a good agent.

Yeah. I think context management is one part of it: what you load into context. The other part is how you clean things up when you're reaching the context window. How do you curate that whole life cycle from 0 to the maximum context window? The way I think about it is that there are so many options on the table and so many risks to misdirecting or distracting the agents. There are ideas about RAG or other forms of retrieval; that's one idea. There's agentic exploration; that's another idea that we found works much better.

It seems like the trend is generally, for loading things into context, to give the model tools that it can use to pull things into context, let the model decide what exactly to pull into context, as well as give it some hints along the way—kind of a map of what's going on. That could include ASTs, abstract syntax trees, and potentially what tabs they have open in VS Code. That was actually in our internal benchmarking, and it turned out to work very, very well. It's almost like it's reading your mind when you have a few tabs open.

It stresses me out because sometimes I have unrelated tabs open, and I have to close them before I kick off the thing.

I wouldn't think too much about it, especially when you're using Cline. Cline does a pretty good job of just navigating that.

Okay.

But there definitely are edge cases, right? There are edge cases for everything. It's kind of like, okay, what's the majority use case? When are you starting a brand-new task and you don't have a single tab open that's relevant to it? Obviously, in the CLI, you don't have that little indicator, so you have to think outside the box for that.

So that's for reading things into context. And then context management is: when you're approaching the full capacity of the context window, how do you condense that? We've played around with this kind of naive truncation very early on, where we would just throw out the first half of the conversation.

It's common.

And there are problems with that, obviously, because it's kind of like you're halfway through a book and you start reading halfway through. You don't know anything that happened beforehand. We like to think a lot about narrative integrity: every task in Cline is kind of like a story. It might be a boring story where it's this lonely coding agent that's determined to help you solve whatever it is. The big thing that the protagonist needs to overcome is the resolution of the task, right? But how do we maintain that narrative integrity where every step of the way the agent can predict the next token—the next part of the story—to reach that conclusion?

We've played around with things like cleaning up duplicate file reads. That works pretty well. But ultimately, this is another case where it's like, what if you just ask the model, “What do you think belongs in context?” Another form of this is summarization, which is like, “Hey, summarize all the relevant details, and then we'll swap that in.” And that works really, really well.

Yeah. Double-clicking on the AST mention, that's very verbose. When do you use that?

Right now, it's a tool. The way that it works is, when Cline wants to do the agentic exploration of trying to pull in relevant context and wants to get an idea of what's going on in a certain directory, for example, there's a tool that lets it pull in all the definitions from a directory. So it could be the names of classes, the names of functions, and that gives it some idea of what's going on in this folder. If it seems relevant to whatever task it's trying to accomplish, then it zooms in and starts to actually read those entire files into context. It's essentially a way to help it figure out how to navigate through large codebases.

Yeah. We've seen some companies working on an interesting idea. It's like an AST, but it's also a knowledge graph, and you can run these discrete, deterministic, almost like actions on this knowledge graph, where you could say, “Hey, find me all the functions in the codebase, then find me all the functions that aren't being used and delete all of them.” The agent can kind of reason in this almost SQL-like language while working with this knowledge graph to do these kinds of global operations.

Right now, if you ask a coding agent to go through and remove all unused functions or do some kind of large refactoring work, in some cases it might work, but very often it's just going to struggle a lot, burn a lot of tokens, and ultimately fail. Whereas with these kinds of tools, it can actually operate on the entire repository with these kinds of query-like, short little query statements. I think there's a lot of potential in something like this. It's the next level beyond the AST, and it's a language for querying this kind of knowledge graph.

But as we've seen with the Claude 4 release, these frontier model shops tend to train on their own application layer. You might come up with a very clever tool that, in theory, would work really well, but then it doesn't work well with Claude 4. Because Claude 4 is trained to grep, right? So that's another interesting phenomenon: you're expecting these frontier models to become more generalized over time, but instead they're becoming more specialized, and you have to support these different model families.

Just to wrap on the memory side, memory is almost the artifact of summarization. You summarize the context, and then you kind of extract some insights. Any interesting learnings from there? Things that are maybe not as intuitive, especially for code? I think people grasp memory about humans, but what do memories about codebases and things look like?

I think memories right now, for the most part, are mostly useless. The kinds of memories that you might want the coding agent to hold on to are specific quirks about how your team works in the project or certain rules, like only use camel case, for example. It's better to place those sorts of things in a general guideline or rules file, for example. But I've found that, with this idea of asking coding agents to hold on to certain memories about the project, how you work, or things like that, you mostly have to force them to store those things in memory. I don't think people want to have to think about those sorts of things.

So it's something we're thinking about: how can we hold on to the tribal knowledge that these agents learn along the way—knowledge that people aren't documenting or putting into rules files—without the user having to go out of their way to force them to store these things in a memory database, for example?

Those are kind of like workspace rules or tribal knowledge—general patterns that you use as a team. But then we ran this internal experiment where we built a to-do list tool. It was only one tool where you could just write the to-do, and every time you could rewrite the to-do from scratch.

We would pass in this context every once in a while—not every message—with the latest state of this to-do list. We found that this actually keeps the agent on track after multiple rounds of context summarization and compaction. It could all of a sudden build an entire complex kind of task from scratch over 10× the context-window length. In internal testing, this was very, very promising, so we're trying to flesh that out.

I think we had earlier versions of something like that in the Memory Bank. Nick Baumann, our marketing guy, came up with this memory bank concept where it was these Cline rules that would tell Cline, “Hey, whenever you're working, have a scratch pad of what you're working on.” This is a more built-in way of doing that, and I think that also might be very, very, very helpful for the agents to just have a little scratch pad of, “Hey, what have I done so far? What's left?”

It could include specific file mentions, what kind of code we're working on, general context, and pass that off between sessions. Yeah.

Any thoughts on CLAUDE.md versus AGENTS.md versus AGENT.md? I built an open-source tool called Agents 927, like XKCD 927, that just copy-pastes it across all the different filenames so all of them have access to it. Do you think there should be a single file? There's also the IDE rules versus the agent rules.

Yeah.

There's kind of a lot of issues right now.

I actually think it's fine that each of these different tools has its own specific instructions, because I find myself using Cursor rules and Cline rules separately when I want Cline, the agent, to work a certain way that's different from how I might want Cursor to interact with my codebase. So I think each tool is specific to the kind of work that I do, and I have different instructions for how I want these things to operate. I've seen a lot of people complain about it, and I get that it could make codebases look a little bit ugly, but for me it's been incredibly helpful for them to be separated.

I noticed that you said “him.” Does Cline have a gender?

Cline's a he/him. Yeah.

Okay.

Yeah.

Does he have a whole backstory—

Yeah.

Personality?

No. Cline... So Cline is a play on CLI—

Yeah.

—and editor.

'Cause it used to be Claude Dev, and now it's Cline.

Yeah. I feel like Cline kind of stands out in the space for being a little more humanized than something like a Cursor agent or a Copilot or a Cascade, and I think—

Well, there's Devin, which is a real name, you know.

Well, yeah.

Claude is a real name, I guess.

Claude's a real name.

Yeah. So I think we've all been intentional about just humanizing it, because, at least in working with it, it gives you more confidence, and I can lean on it a little bit more. There is kind of a trust-building with an agent, I think, and the humanizing aspect of it has been helpful to me personally—

This goes back to the narrative integrity. It's actually really important, I think, to anthropomorphize agents in general, because everything they do is like a little story, and without having a distinct kind of identity, you get worse results. And when you're developing these agents, that's how we need to think about them, right?

We need to think that we're crafting these stories. We're almost like Hollywood directors, right? We're putting all the right pieces in place for the story to unfold, and having an identity around that is really, really important. And Cline, you know, he's a cool little guy.

Yeah.

He's—

Just a chill guy.

He's a chill guy.

He's just a chill guy. He's helping—

He writes code.

He's helping us out. He's always happy to help. Or if you tell him not to be happy, he can be very grumpy. So it's great.

Awesome. I know you're hiring. You're 20 people now, and you're aiming for 100. You have a beautiful new office. What's your best pitch for working at Cline?

A lot of our hiring right now is—so far, it's been just friends of friends, people in our network, people that we've worked with before that we trusted and that we know can show up for this incredibly hard thing that we're working on. There are a lot of challenges ahead, and I think the problem space is probably the most exciting thing to be working on right now. Engineers in general love working on things that make their own lives easier, and so I couldn't imagine working on something more exciting than a coding agent. This is a little biased, but I think a large part of it is that it's an exciting problem space.

We're looking for really motivated people who want to work on challenges like figuring out what the next 10 years looks like and building the foundation for what comes next after background agents or multi-agents, and really helping define how all this shapes up. We have this really excited community of users and developers. I think being open source has also created a lot of goodwill with us, where a lot of the feedback we get is incredibly constructive and helpful in shaping our roadmap and the product that we're building. Working with a community like that is one of the most fulfilling things ever.

Right now we're in between offices, but we're doing things like go-karting and kayaking and things like that. So it's a lot of hard work, but we make sure to have fun along the way.

Yeah. No, Cline is a unique company because it really does feel like we're all just friends building something cool. We work really, really hard, and the space is not just competitive; it's hypercompetitive. Capital is flowing into every single possible competitor. We have forks of forks, like I said, raising tens of millions of dollars, and we're growing very rapidly. We're at 20 people now, and we're aiming to be at 100 people by the end of the year.

Being open source has its own challenges. We do all this research and benchmarking work to make sure our diff-editing algorithm is robust and to optimize for the lowest possible number of diff-edit failures. Then we open-source that, and we post it on Twitter, and someone's like, “Oh, thanks so much for open-sourcing that. I'm going to go and raise a bunch of money with our own product with it.”

But the way that I see it is: let them copy. We're the leaders in the space. We're showing the way for the entire industry, and being an engineer and building all this stuff is super exciting. So working with all these people is just amazing.

Okay. Awesome. Thank you guys for coming on.

Thank you.

Thank you.

All right. Thanks so much.

This was so much fun.