Everyone can get their own "DeepSeek Harness", so why are we still paying for memberships of services like Claude Code?

"If you can't rebuild Cursor within a few hours, your next interview will be extremely tough — it's just a while loop with 300 lines of code."

Geoffrey Huntley, the creator of Ralph Loop, draws the bottom line for software engineers at 300 lines of code. It seems absurd at first, but people are finding that he might be right.

Over the past year, the underlying paths of major products such as Claude Code, Codex, and Antigravity have become increasingly similar: the Agent Loop reads and writes context, calls tools, executes repeatedly, and relies on tests and permissions as safeguards. Context, tools, Loop, memory, and multi-Agent have gradually become a set of publicly standard playing cards.

Beyond large tech companies, personal Harness projects are also emerging at a frantic pace.

Pi and Aider, which now have huge communities, both started as personal projects: Pi was independently developed by Mario Zechner, a 41-year-old Austrian software engineer, and Aider was launched single-handedly by Paul Gauthier, a Canadian software engineer around 54 years old. Reasonix, optimized for DeepSeek, was initiated by game engine developer YHH, and quickly grew into a community project with tens of thousands of Stars.

After DeepSeek announced the recruitment of Harness beta testers, the comment section quickly turned into a "personal Harness exhibition fair". The community sorted out thousands of replies under the post, including hundreds of open source repositories covering directions such as Coding Agent, memory, Skills, evaluation and security. Almost everyone came to recommend themselves with their self-built Harness.

The world is so wonderful: a few months ago, the difference between people was "whether AI-assisted developers can increase productivity by 2 times or 100 times", and now the difference has become "whether you can write your own set of Harness".

But when models can be replaced, Harness can be replicated, common components have converged, and even individual developers can assemble a usable system, what else can Coding Agent rely on to stand out? To this end, we interviewed Tang Liu from TiDB, Ru Bingsheng from Tencent Research Institute, Remy, architect of Floatboat Harness, and Tianzhu from ByteDance's Trae team.

Chasing models is less effective than building Harness? 

This year, many well-known founders of Coding tools have started to talk about a topic: models can no longer create gaps in daily programming tasks.

Thorsten Ball, co-founder of Amp, said: "The model is dead." The act of closely managing a single model has yielded diminishing returns. We no longer need to constantly adjust and test different models — they will eventually evolve to the level where "press a button, and you can get a John Carmack".

Dax Raad, co-founder of OpenCode, has a similar feeling: model companies have found a certain perfect zone in terms of usability. After using newer models and looking back at this generation, you will find that they are almost the same, "it makes no difference which one you use".

Mario Zechner, founder of Pi, believes that not only have models reached their peak now, but the capabilities of new versions may even regress. The stronger the capability, the harder it is for manufacturers to ensure that old capabilities do not degrade — there are too many use cases in the real world, and evaluations cannot cover all of them. Therefore, model manufacturers will choose to promote their own Harness, because Harness is the only part they can control, and at least the changes can be locked.

A few months ago, a domestic Coding tool expert told InfoQ a sentence: "If the (domestic) model is not good enough, we can only rely on tools to make up for it. The model is responsible for decision-making, and the real coding, debugging and refactoring are completed by the tools in Harness."

But the situation has changed now. Models are already capable of handling the complexity of most daily work. When daily tasks cannot touch the upper limit of the model's capability at all, it is no longer as important as before who has a higher upper limit.

Since models cannot create gaps, competition has entered the Harness layer.

Harness is also converging, but convergence is not the end

Harness is not a new thing. As early as 2022, when ChatGPT was first released, the 4000 Token context window forced developers to use tool calling, MCP, and RAG to manage context — Cursor, Windsurf, Cline, Aider were all products of that era. Later, the context window became larger, the tasks became longer, and after the Agent ran for a few hours, it began to compress and summarize, omitting key information. Some people introduced Sub-agent, some developed Agent Swarm, and essentially they were all doing the same thing: building a better operating environment for the underlying model.

The term "Harness" became widely popular in early 2026, but after only half a year, everyone's development direction has tended to be consistent.

The innermost Agent Loop, responsible for model looping, file reading and writing, context management and security control, can have only about 200 lines of code. Thorsten Ball, co-founder of Amp, wrote a Coding Agent that can read, search and edit files in the terminal from scratch with 315 lines of Go code.

Although the core has only a few hundred lines of code, a complete set of Harness still needs to stack a large number of components outward. Planner, Coder, Reviewer, Search, Edit, Shell, Sub-agent, MCP — Tang Liu from the TiDB team listed a series of names and then said: "These things will gradually become standard parts."

He used databases as an analogy: MySQL, TiDB, PostgreSQL, and Snowflake all have SQL, all have Optimizer, all have Storage Engine, but no one will think they are the same. The real gap never lies in "whether this component exists", but in how these components form a system that can truly solve problems.

The TiDB team has its own answer to the specific approach. Their new product TiDB Cloud Filesystem. The project itself is an exploration — the team iterated while advancing, and in the process of collaborating with AI, they polished a set of Harness synchronously. It was not designed in advance, but was gradually "forced out" in the process of the project constantly encountering bottlenecks, locating problems, and adjusting execution methods. This set of Harness was even formed earlier than the release of Claude Code's dynamic Workflow.

They did not write the innermost Agent Loop from scratch, mainly based on the open source project Pi. But task orchestration, permissions, persistent state, Sandbox, and failure recovery are all done by themselves. The design philosophy is summed up in one sentence: thin Agent Loop, thick Control Plane.

Why not write the Loop yourself? Because Agent Loop is the layer that changes the fastest and is most likely to be homogenized. Model protocols, Tool Calling, Streaming, and Reasoning are constantly changing, and LLM companies and cloud vendors will make it better and better sooner or later. "There is no need for us to engage in involution here. We can just stand on the shoulders of giants."

What really needs to be done by yourself are the problems that the database team has been solving for the past two decades: how to persist the state, how to close the permissions, how to control side effects, how to recover after failure, how to prove that a result is real, and how to audit and review after problems occur.

The main benefit of this design is that once you change the model or Agent Core, you don't have to start all over again. They initially used OpenCode, and later switched to Pi, but no matter how the upper Agent changes, the lower Sandbox, permissions, state and control plane do not need to be rewritten. The stronger the model capability, the more you can relax the exploration space in the Sandbox, but there is no need to relax the side effect boundary for the real production system at all.

This is very similar to a database. Components such as SQL and Optimizer can become smarter and smarter, but the boundaries of Transaction, Privilege, and Durability cannot disappear just because "the upper layer is smarter". The Agent Framework can change continuously, but the boundaries of state, permissions and side effects must be stable.

This set of Harness finally supported TiDB Cloud Filesystem to complete development and go online within three months. Persistent Workspace across Session, Sandbox and Executor, version, branch, Checkpoint, Rollback, permissions, quota and multi-tenant isolation — all completed by Agent, no human wrote a single line of code, nor reviewed a single PR. After going online, it has carried more than millions of Agent Workspace.

The gaps are hidden in these invisible places 

Harrison Chase, co-founder of LangChain, has also seen the same trend, with an extra layer of judgment: convergence is convergence, but it will converge into a continuous spectrum.

His observation is that general-purpose Harness is already competent for many basic tasks — letting Agent access the file system and call sub-Agent is enough for most scenarios. But the more unconventional the task, the more customized Harness is needed. Therefore, one end of the spectrum is off-the-shelf general products, the other end is a complete customized cognitive architecture, and there are countless states customized through Hook or middleware in the middle. What drives people to the customization end is often not performance, but predictability and control, such as the financial industry — customers would rather sacrifice a little intelligence in exchange for controllability.

And the customized cognitive architecture at the other end, to put it bluntly, is to embed domain knowledge, professional tools and expert processes into Harness together — this is especially critical in vertical fields.

Specific to Coding Agent, Ru Bingsheng from Tencent Research Institute believes that knowledge engineering determines its capability level.

The vast majority of AI programming work is not to develop new projects from 0 to 1, but to add features or fix Bugs on existing code. Therefore, the core capability of Coding Harness is to first understand the existing system, then judge where to make what modifications according to software engineering methods, and form a closed loop through rapid trial and error and verification.

He broke down what a good set of Harness needs to do into three layers.

The first layer: understand the existing system. The code of many projects is messy, and reading the code alone is not enough. It is best to combine the original requirements, system design and code to understand the original functions, business logic and specific implementation, so that Agent can understand "why this thing looks like this" and make targeted inferences.

This involves a lot of Harness work: how to import knowledge, how to map code and design. For large projects, it is impossible to stuff all the code into the context at once. How to do top-level modeling, build a Code Graph mechanism, locate relevant modules when needed, and then find finer code snippets inside the module through methods such as grep. All these need to be handled by Harness.

The second layer is project constraints and reasoning. The model itself needs to have software engineering capabilities, and it must also understand the constraints of specific projects and code repositories. Harness needs to make these rules visible to the model, ensure that it abides by the rules during execution, and check whether the rules are truly implemented after completion.

But it is not enough to just write "abide by the rules" in the Prompt — after the generation rules are available, there must also be a rule checking and reflection mechanism. Reflect on the generated results, and the reflection may go through more than one round. The results of multiple rounds of reflection are merged, and then iterated until the project constraints are met.

The third layer: deterministic verification. Code generation is only the starting point. It makes no sense for Agent to say "I fixed it". You have to use external invariants to prove it is correct. Therefore, Coding Harness needs to be connected with the continuous integration system, covering test generation, test execution, result analysis and error feedback, and then modify the code according to the running results. To achieve this, Harness also needs to have capabilities such as unit test environment, containerized test environment, compilation and operation, result analysis and result display.

After the code is generated, how to compile, run, start the environment and judge the results can all be completed through deterministic engineering means. And these engineering capabilities should become an indispensable part of Coding Harness.

Multi-Agent orchestration: sounds fancy, but is actually "distributed internal friction" 

The thing Boris Cherny talks about most often is showing off his multi-Agent capability — thousands of Agents run at the same time, and tens of thousands run directly when busy. Claude Code has taken this playbook to productization: Dynamic Workflows, where the user gives a goal, and Claude breaks down the task by itself, scheduling hundreds of sub-Agents to search, code, verify, and summarize.

2026 is known as the "Year of Agent Orchestration". Boris is probably the most enthusiastic person to prove this statement.

This script was performed once ten years ago. 2016 was also called the "Year of Orchestration", with containers as the protagonist. Docker standardized applications, and people found that running a container is not difficult, but managing thousands of them is. Then Kubernetes, Swarm, and Mesos competed, and the control plane won in the end. Ten years later, Agent is following the same path.

This position is already crowded now. Large model manufacturers, cloud vendors, enterprise software giants, open source frameworks, and governance layer platforms — all have poured in. Each has its own orchestration solution, and each solution wants to become the "control layer that manages Agents".

In fact, this judgment is not new. As early as 2025, Steve Yegge, author of *Vibe Coding* and former Google and Amazon engineer, went to the top management of Anthropic and told them that they should build a "Kubernetes for Agents" — Claude Code is just a component, and the real battlefield is the upper orchestration layer. No one paid attention to him. So he started working on it himself in August, and later made Gas Town. According to Yegge, Gas Town allows one person to continuously manage 20 to 30 concurrent Coding Agents (on a local single machine).

Now all players are competing for the same entry. But will this position really become an independent and unified platform like Kubernetes? Or is the whole industry rushing headlong into a dead alley that is overhyped?

Tang Liu from the TiDB team has a judgment that sounds like a radical statement, but the more you think about it, the more reasonable it is: the future of Agent orchestration may be less and less orchestration.

A year or two ago, to let Agent do a complex task, you had to teach it step by step: what to do in the first step, what to do in the second step, how Planner works, how Coder works, how Reviewer works, and write a lot of Prompts to embed the collaboration process. Now? Most of the time, you only need to tell the Agent "I want this result", and it can complete a large number of internal planning on its own to get the job done.

So the stronger the model, the more part of the explicit orchestration will definitely disappear. This is very similar to the evolution of databases — in the early days, you had to tell the database "how to Join, which table to start from". Later, the Optimizer became more and more powerful, and people only need to say "what I want", and the database decides the execution method by itself. Agents will also follow this path: from imperative orchestration to declarative goals.

After working on distributed systems for so many years