All in on CLINE

This is a translation of an article written by a Japanese Node.js engineer. Original source: https://zenn.dev/mizchi/articles/all-in-on-cline

I've been using Cline for about 2 months now.

My intuition tells me that Cline is both the gateway to true innovation and a Pandora's box that should not be opened.

When I refer to Cline here, I'm talking about Cline-type coding agents, which broadly includes tools like Devin, Cursor, and Copilot Agent. However, as I'll explain later, there's a world that only Cline can show us.

I'm going to talk about why I'm all in on this future as a programmer.

The End of Programming as We Know It

Everything important is already written in the following article. Please read this first:

https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/

Steve Yegge points out that it's not junior and mid-level programmers who will be replaced, but programmers who refuse to embrace new programming tools and paradigms and cling to the past.
[...]
This isn't the end of programming. It's the beginning of its latest reinvention.

https://steve-yegge.medium.com/the-death-of-the-stubborn-developer-b5e8f78d326b

I want you to feel the weight of this statement coming from Tim O'Reilly himself.

AI and Programmers Are Now Truly on the Same Playing Field

At its core, Cline is simply a "programming editor running in headless mode" like VSCode.

Cline references environmental information just like human programmers do. It runs code, absorbs the logs, and makes corrections.

However, I feel there's been a fundamental change in this workflow when working with Cline. Cline has strong (and dangerous) execution permissions, and this cycle is overwhelmingly faster than before. This speed drastically transforms the AI programming experience.

I've used Cursor's YOLO mode for command execution permissions, but the experience was more like an extension of Copilot, generally respecting human decision-making.

Cline is like a runaway train, seemingly indifferent to human input beyond the initial instructions. As a result, it achieves a speed that can't be realized any other way, and I can't bear to work without it now. Honestly, it's quite addictive.

This kind of magical power didn't exist in Copilot or Cursor. That's why I use Cline, or more specifically, Roo Code, which is a fork of it.

Perhaps human assumptions have unconsciously imposed constraints until now. Only Cline, freed from these shackles, is showing me the future. I really want you to try it.

How (In)competent Is AI at Programming?

For most professional programmers, the general perception is that AI is poor at programming.

In fact, I too think it's not particularly smart when it comes to "simple" coding performance. The current smartest model, Claude-3.7-sonnet, is probably at the level of a second-year new graduate.

However, I've come to realize that this may have been unfairly underestimated due to the information asymmetry between AI and humans. When you feed data to Cline, you can clearly observe its performance improving. Perhaps it was simply a lack of information until now.

Cline has solved this problem. The result is an overwhelming coding speed, albeit with the caveat that it's within AI's areas of expertise.

Ultimately, humans also have to write code through trial and error in PDCA cycles, but Cline's speed of iteration is reaching a level that no expert can compete with.

Let Cline Do What It's Good At

When I give instructions, it can write about 700 lines of code that passes tests in about 15 minutes.

For example, I had it write a function called dig that extracts data from a specific access path in JSON while inferring types.

https://github.com/mizchi/ailab/blob/main/core/dig.ts

export function dig<T, Q extends Query>(
  obj: T,
  query: Q
): DeepValue<T, QueryToArray<Q>> {
  return digUntyped(obj, query) as DeepValue<T, QueryToArray<Q>>;
}
//...

// Unit Tests
import { expect } from "@std/expect";
import { test } from "@std/testing/bdd";

test("dig - string query basic object access", () => {
  const obj = { a: { b: 1 } };
  expect(dig(obj, "a")).toEqual({ b: 1 });
  expect(dig(obj, "a.b")).toBe(1);
});
// ...

And it's passing tests like this:

$ deno test -A dig.ts               
Check file:///home/mizchi/lab/core/dig.ts
running 17 tests from ./dig.ts
dig - string query basic object access ... ok (1ms)
dig - array query basic object access ... ok (0ms)
dig - string query array access ... ok (0ms)
dig - array query array access ... ok (0ms)
dig - string query wildcard ... ok (0ms)
dig - array query wildcard ... ok (0ms)
digUntyped - regex query ... ok (0ms)
digUntyped - object query ... ok (0ms)
digUntyped - $keys query ... ok (0ms)
digUntyped - $values query ... ok (0ms)
digUntyped - $flat query ... ok (0ms)
digUntyped - $pick query ... ok (0ms)
digUntyped - $exclude query ... ok (0ms)
digUntyped - combined special queries ... ok (0ms)
dig - edge cases ... ok (0ms)
digUntyped - basic functionality ... ok (0ms)
dig - type inference ... ok (0ms)

As I was building it, I gave instructions like "structure the query internally," "I want regex support," and "handle nested objects with self-recursion," and had it write tests each time.

This is clearly letting AI do what it's good at:

• No external references or context
• Confined to a technical domain
• Easy to create mock data
• Likely has existing implementations

To be honest, I could write this myself, but the significant factor is that it took only about 5 minutes. If I had written this amount myself, it would probably have taken 30 minutes to an hour. It's also easy to develop further - create mock data and make the tests pass. That's exactly the technique of expressing specifications through tests, which will become a more demanded skill.

I think the number of operations is most important, and we've already reached a phase where humans can't compete in terms of those operations.

And you'll realize: human judgment is the bottleneck. This is a realm that only Cline, which doesn't defer to humans, could achieve - a level that Copilot couldn't reach on its own.

Assigning Difficult Tasks: HM Type Inference for JSON

The dig function was a case where the implementation method was obvious, so let me deliberately assign something more difficult.

I want to infer the type from a typeless JSON and create a zod validator from it.

The specific instruction I gave was to first implement a simple HM type inference, then extract types from it and build a zod validator.

Hindley–Milner type system - Wikipedia

https://github.com/colinhacks/zod

https://github.com/mizchi/ailab/blob/main/scripts/json_type_inference.ts

To be honest, I haven't fully developed this, but it's already implemented this far:

///...
test("Inference for nested objects", () => {
  const env = new TypeEnvironment();
  const json = {
    user: {
      id: 1,
      name: "John",
      tags: ["admin", "user"],
    },
  };

  const type = inferTypeFromJson(json, env);
  const typeStr = typeToString(type);
  expect(typeStr).toBe(
    "{ user: { id: number, name: string, tags: string[] } }"
  );
});

It's working well for simple examples. From here, I could just increase the test cases and have it implement them.

At this point, I think there are several things I've learned:

Insights from the user side are essential as prerequisites. Prior knowledge and context are needed:

• What can be expressed with the JSON data structure
• Knowledge of type inference, specifically HM type inference
• How the structures you want to extract can be represented in JSON
• Whether applying HM type inference to JSON makes sense

Frankly, I only vaguely understand HM type inference conceptually, so my evaluation is already ambiguous here. However, the test code that uses it seems relatively easy to evaluate. I think we could probably work it out by adding more test cases.

Implementing something I don't fully understand requires a fairly advanced thought process of "intuition about internal structures that can be reverse-engineered from results." I think this is the feeling that non-programmer people have had when asking programmers to do work.

The Decision and Resolve to Hand Over the Driver's Seat

GitHub Copilot was, as the name suggests, merely a passive navigator. As an end-user experience, it felt like the intellisense that suggests sin,cos,tan,PI... when you press Tab after Math.<Tab> had expanded from static analysis method level to (probabilistically) include function call arguments like .sin(Math.PI/n).

That was impressive enough, but Cline is in a completely different dimension. In pair programming terms, Cline is the driver and the user is the navigator. The roles are reversed.

What humans need to consider is whether the problem involves mathematics, algorithms, or libraries that Cline is good at, and if so, let Cline handle it. You can simply say Implement a distance function that calculates the Euclidean distance between two points.

I just tried it:

// Implement a distance function in TS that calculates the Euclidean distance between two points. Also write Deno tests.
/**
 * Calculates the Euclidean distance between two points in n-dimensional space
 * @param point1 First point as an array of numbers
 * @param point2 Second point as an array of numbers
 * @returns The Euclidean distance between the two points
 * @throws Error if the points have different dimensions
 */
export function distance(point1: number[], point2: number[]): number {
  if (point1.length !== point2.length) {
    throw new Error("Points must have the same number of dimensions");
  }

  let sumOfSquares = 0;
  for (let i = 0; i < point1.length; i++) {
    const diff = point2[i] - point1[i];
    sumOfSquares += diff * diff;
  }

  return Math.sqrt(sumOfSquares);
}

import {
  assertEquals,
  assertThrows,
} from "https://deno.land/std/assert/mod.ts";

Deno.test("distance between identical points is 0", () => {
  assertEquals(distance([0], [0]), 0);
  assertEquals(distance([1, 2], [1, 2]), 0);
  assertEquals(distance([5, 5, 5], [5, 5, 5]), 0);
});

Deno.test("distance in 1D space", () => {
  assertEquals(distance([0], [5]), 5);
  assertEquals(distance([10], [5]), 5);
  assertEquals(distance([-5], [5]), 10);
});

Deno.test("distance in 2D space", () => {
  // Distance between (0,0) and (3,4) should be 5 (Pythagorean triple)
  assertEquals(distance([0, 0], [3, 4]), 5);

  // Distance between (1,1) and (4,5) should be 5
  assertEquals(distance([1, 1], [4, 5]), 5);

  // Distance between (-1,-1) and (2,3) should be 5
  assertEquals(distance([-1, -1], [2, 3]), 5);
});

Deno.test("distance in 3D space", () => {
  // Distance between (0,0,0) and (3,4,0) should be 5
  assertEquals(distance([0, 0, 0], [3, 4, 0]), 5);

  // Distance between (1,1,1) and (4,5,1) should be 5
  assertEquals(distance([1, 1, 1], [4, 5, 1]), 5);

  // Custom 3D case
  const result = distance([2, 3, 4], [5, 7, 9]);
  assertEquals(Math.round(result * 100) / 100, 7.07); // Rounded to 2 decimal places
});

Deno.test("throws error when points have different dimensions", () => {
  assertThrows(
    () => distance([1, 2], [1, 2, 3]),
    Error,
    "Points must have the same number of dimensions"
  );
});

This takes about 15 seconds. It takes me a minute to verify it, but the burden is reduced because there are tests.

(I noticed that it's avoiding floating-point ambiguity to make the tests easier to write.)

However, this coding ability depends on the performance of the model you're actually communicating with. My gut feeling is that the probability of a task ultimately succeeding is about 70%, and the probability that the written code meets my quality requirements is about 70%. As a result, the probability of getting usable code is about half.

So my approach is to first let Cline handle areas it's good at, then refactor and modularize it myself.

This has resulted in these scripts:

https://github.com/mizchi/ailab/tree/main/scripts

If I can come up with an approach, I feel like I can write 700 lines in 15 minutes.

What Cline/Claude Struggles With: Context Retention

I take the approach of "implementing a PoC limited to a single file" or "implementation against explicitly referenced libraries/modules." This is because it struggles with resolving references in environments where context isn't explicit.

We know this will be solved as AI model performance improves and context windows expand.

Regarding context retention, there are makeshift strategies like Memory Bank, MCP, and Agentic RAG technologies, but honestly, I can't fully predict whether context windows or summary generation will be the surviving technology. Currently, we can only choose case by case while considering costs.

https://docs.cline.bot/improving-your-prompting-skills/custom-instructions-library/cline-memory-bank

Introducing the Model Context Protocol \ Anthropic

What Programmers Need in the Cline AI Era

I think it can be organized like this:

• Ability to describe context
• Ability to describe domains
• Intuition about AI performance

Other than intuition about AI, these are about appropriate modularization, extraction of bounded contexts, building ubiquitous language, DDD, and the ability to abstract implementation targets as domain experts.

I end up writing quite a lot of instructions in .clinerules, and I feel that being able to build this according to your own abilities is the value of being a domain expert in programming.

https://github.com/mizchi/ailab/blob/main/.clinerules

I recognize that there's a limit to generic prompts, and it's important to prepare documentation summarizing programming languages, implementation targets, and surrounding technologies.

Separately, in the short term, there's a role as an agent that manually corrects AI mistakes and assists while compressing context to reduce costs.

Cline and Programming Language Aptitude

There's also an aptitude for programming languages. At present, Cline functions with a limited set of languages: high-level languages like TypeScript, C#, and Python that are popular, have a lot of learning data, and have static typing support that can check types before execution.

From what I've tried, the presence of static typing directly affects the speed of iteration. TS has a significantly better success rate than JS.

On the other hand, with languages that have strict compiler constraints like Rust/Haskell, the current Claude has a high probability of struggling to pass compilation/tests without the help of a human expert.

(No matter how much instruction I give, it tends to distort the implementation to pass tests, so I have to scold it every time. This behavior is very junior engineer-like.)

For this, we either need to wait for AI model performance improvements or accompany it as experts.

Why This Is a "Pandora's Box"

Cline tries to execute various commands directly to gather environmental information.

There are safeguards like confirming with the user before executing unknown commands and the ability to create allow lists for auto-execution. This is called the Auto Approver mechanism.

However, as you go along, you'll notice the user's confirmation gets more and more lenient. Once you realize that humans are the bottleneck, you want to give permission immediately.

Cline itself basically executes commands outside the sandbox based on its own ideas, which is dangerous. As a result, it absorbs environmental information and improves coding accuracy...

I imagine the security officers at companies that want to use Cline will have quite a headache.

Since I can anticipate this far, I predict that container security and WebAssembly Sandbox will become hot topics where Cline is headed.

As a small resistance, I run with execution-time permissions like deno run --allow-net, but I'm often lazy and just use -A (--allow-all). Still, I think deno is well-suited for this.

vs. The "Programmers Are Unnecessary" Argument

I don't think programmers will become unnecessary. I believe programmers are not just code-writing workers but specialists trained in abstract thinking to decompose and reconstruct elements of a domain.

And without this way of thinking, programming cannot be realized. This is the level at which AI does programming, so humans need to meet AI's expectations. Areas that cannot be met will be filled with hallucinations.

Advanced AI is like a mirror of oneself, and the performance you can draw from AI is directly proportional to your own abilities. Programming work has just moved a little closer to natural language, but the actual operation level is still programming language, and the level required during debugging hasn't changed, and may even be more difficult.

The profession of programmer isn't ending. It's just changing.

I still don't believe it. Sure, a breakthrough that puts advanced computing capability into the hands of many more people means that ordinary people will be able to execute what was once the realm of highly trained specialists. But that same breakthrough creates new kinds of services and new demand for those services. It creates new sources of deep magic that only a few people can understand.
https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/

However, I also think it's dangerous to be too optimistic due to the sunk cost bias of being a specialist myself.

For example, the following article about translation jobs disappearing felt too vivid to dismiss as someone else's problem:

About human translation that will soon disappear｜Akito Hirano

As of the end of 2024, I have 0 requests coming in for next year.
As a result, my income forecast for 2025 is 0 yen.

This is just one translation story.
In other words, it's one story about translation.
If you think it's not relevant, you don't have to read further.
If it differs from the reality you know, you don't have to believe what follows.

AI coding is probably at the peak of the hype cycle right now, and by destiny, a period of disillusionment will follow. People with low programming proficiency will enter, complain that it doesn't work, and leave. Cline is not set up to be usable for the current AI enthusiasts who don't want to get their hands dirty.

The real competition starts from there, and when Cline-type coding becomes well-established, opened to everyone, and practices are organized, only those on the adaptive side of humanity will survive, at least in terms of productivity.

To put it more simply, you won't be able to win in salary competition based on productivity. Or rather than productivity, you'll need to make AI management pipeline design your core skill. I have such a premonition.

So I'm betting my future programmer life on Cline to survive.