Cline and Roo Code: open-source agents teach you more than closed ones

The most useful hour I’ve spent on any of these tools wasn’t using one. It was reading Cline’s system prompt.

Not the marketing description of what it does. The actual text sent to the model on every turn: the tool definitions, the rules about how to make an edit, the instructions about asking before acting, the exact wording that makes the difference between an agent that plans and one that thrashes. It’s in the repository. You can read it on a train.

You cannot do that with the closed tools, and after a year of working with both kinds I think that’s the whole argument.

What being able to read the prompt actually gets you

The behaviour of an agent is not magic and it is barely a model property. It’s mostly prompt engineering plus a tool loop, and when you can see both, three things stop being mysterious.

First, you learn why it failed. When a closed agent does something inexplicable you’re left guessing between three or four possible causes, and the guesses don’t improve with experience because you never get feedback. When Cline does something inexplicable you can go and read the instruction that produced it, and about half the time the instruction is right there being interpreted more literally than anyone intended.

Second, you learn what a good tool definition looks like. These projects have iterated their tool descriptions in public, in commits, with the arguments visible in the pull requests. If you’re building anything agentic yourself, that history is a free course in a subject nobody teaches: how much detail a tool description needs, where the ambiguity bites, what happens when two tools overlap.

Third, you learn the shape of your own token bill, because you’re bringing your own API key.

The bring-your-own-key effect

This is underrated and slightly unpleasant, which is why it teaches so well.

Subscription tools bury cost. You pay a flat monthly fee and the relationship between what you asked for and what it cost to answer is severed completely. That’s a fine product decision and it makes you a worse engineer, because the feedback loop that would have taught you what’s expensive never closes.

With a key attached, every run has a price attached, visible, in the panel. Within a week you develop intuitions that no amount of reading gets you: that a vague prompt against a large context is far more expensive than a precise one, that letting an agent explore a repository by reading files is enormously more costly than telling it which three files matter, that the difference between a good and bad first instruction can be a factor of ten.

I’ve watched that single number change how people work more effectively than any amount of advice about prompting. It’s the difference between knowing that context is expensive and paying for context.

Roo Code and the value of a fork you can read

Roo Code started as a Cline fork and diverged, which produced something genuinely useful for learning: two projects solving the same problem with visible disagreements.

The modes are the clearest example. Roo splits the agent into distinct personas with different permissions and different prompts, so an architect mode can plan without editing and a code mode can edit. You can read both prompts and see exactly what changes between them. That’s a design decision laid out on the table, along with the reasoning in the issue thread that produced it.

Compare that against a closed tool shipping a feature called “planning mode” in a changelog. You get the name. You get the behaviour. You never get the reasoning, which is the part that would transfer to your own work.

The honest counter-argument

None of this makes them better products for everyone, and it’s worth saying plainly.

The closed tools are more polished. Their defaults are better tuned, their onboarding is shorter, and they hide the machinery precisely because most people don’t want to see it. If your goal is to ship features on a Tuesday, an opinionated tool that has already made the hundred small decisions for you is a reasonable choice, possibly the right one.

The argument here is narrower. If you want to understand what these systems are and where they break, you need to see the machinery at least once, and only one category lets you. Use whatever you like day to day. Spend one afternoon in a repository you can read.

The thing that surprised me most when I did: how little of it is clever. The prompts are long, plain, and full of the same defensive instructions you’d write yourself after being burned a few times. Don’t guess at file contents. Read before you write. Ask when the requirement is ambiguous.

That’s not a disappointment. It’s the lesson. The agents that work are the ones with good instructions and honest tools, which means the skill transfers directly to the way you brief a human colleague, and to the way you’ll build the next one of these yourself.

More field notes on Cline and Roo Code

This piece is one entry in a running series on how AI coding tools change day-to-day engineering work. For more practical notes on Cline and Roo Code specifically, browse the full set at /blog/tag/cline/. For the wider view across every tool in the stack, the AI coding tag collects the whole archive in one place.