Harness Engineering: A New Paradigm for Software Production in the AI Era

The article introduces Harness Engineering, a paradigm that ensures AI coding quality through checkpoints, acceptance criteria, and automated scoring.

By Fang Wu

A Fundamental Question

AI capabilities are being redefined every day. Code generation, automated testing, even architecture design—LLMs are permeating every aspect of software development faster than expected. But beneath this wave, a fundamental question has been widely overlooked:

What are the specific requirements for our production deliverables? What are the quality standards?

This is not a new question. In traditional development, project managers answer it naturally—through requirements reviews, design documents, code reviews, test coverage metrics, and a host of other mechanisms that define and enforce delivery quality. But these mechanisms share a common implicit premise: the executor is a human.

When the executor becomes AI, that premise no longer holds. Existing quality mechanisms need to be re-examined, even redesigned.

When you seriously answer this question—how should project quality be assured in the AI era—you naturally arrive at a path: quality requirements must be transformed into something AI can understand, comply with, and be verified against. You need to define the production line, design checkpoints, and establish acceptance criteria.

This is harness engineering. Not because AI is dumb and needs to be managed, but because anyone who takes project quality seriously will inevitably arrive at this point.

A Double-Edged Sword

Let us start with the good side. The efficiency gains from AI coding are real. A bug fix that once took half a day to a full day can now be resolved by AI in ten minutes with a plausible solution. Writing tests, documentation, and refactoring—all those "should-do but never-have-time-for" tasks—AI dramatically lowers the execution barrier. For many routine development tasks, AI output speed has already reached several times or even an order of magnitude beyond human capacity.

But the bad side is equally significant. AI introduces substantial quality risks—the kind that traditional quality systems cannot catch.

Here is why: traditional quality metrics—code coverage, test case counts, static analysis pass rates—are trivially easy for AI to satisfy. Want 90% code coverage? AI can pad the numbers effortlessly, writing a bunch of happy-path tests to inflate the metric. Want every function to have a unit test? AI can write the implementation first and backfill tests that only verify "what the code does" rather than "what the code should do"—mock everything, win every time.

These metrics were designed for human developers—they measure discipline. But AI has no concept of "discipline"; it simply satisfies the explicit numerical requirements.

The result is that the only quality checkpoint that truly works is human review. But a new problem emerges: AI can produce a month's worth of code in a single day, while human review speed has not scaled accordingly. Review becomes the bottleneck. A single reviewer facing thousands of lines of AI-generated code in one day simply cannot examine every line.

This has led to an awkward polarization in the industry: core projects dare not use AI—the quality risk is too high, and the cost of failure is too steep; non-core projects are handed entirely to AI—it is not on the critical path anyway, as long as it runs, quality is left to chance.

This is not a healthy state of affairs.

The Assassin Agency

Imagine this scenario: you run an assassin agency. Your assassins are extraordinarily capable and efficient—give them any target and they will almost certainly get the job done. But they have no moral constraints, no long-term contracts, purely transactional—complete the job and move on, ready to disappear at any moment with zero accountability.

As the boss, how would you manage them? Trust? Impossible—there is no foundation for trust. You can only rely on a rigorous control system: Does the task planning conform to SOP? Has the execution process left verifiable evidence? Did the final result meet expectations? Only when every one of these checkpoints passes do you confirm delivery. You do not manage how the assassin kills—but you must manage whether the right target was eliminated and whether it was disguised as an accident—and you need an evidence chain.

Anyone who has played Hitman knows that the final score depends on every action you take. An SSS rating is determined by each step of the execution, not just the simple fact of whether the target is dead.

This analogy is not an exaggeration. It precisely describes the current relationship between software development teams and AI.

The fundamental difference between AI and an employee lies not in capability or speed, but in accountability: an employee is an entity that can be held accountable; AI is not.

Consider why existing software quality systems work. On the surface, they rely on code coverage, test cases, and code reviews. But behind these explicit mechanisms lies a massive implicit premise: the executor is an entity with long-term stake. Employees have professional reputations to maintain, contracts to honor, years of domain-trained judgment, and the pressure of "if I mess up, there will be consequences." Together, these form an implicit quality assurance layer. Because this implicit layer exists, quality systems have never needed to deeply scrutinize an employee's development process—whether they wrote tests first or code first, which files they consulted while debugging, what reasoning path they followed for architectural decisions—none of this needs to be tracked, because there is a default trust in the basic reliability of humans as accountable entities.

AI has completely removed this implicit assurance layer. It has no professional reputation, no contractual pressure, not even continuity across conversations—every interaction starts fresh. Its black-box development process is the single largest risk in current AI coding.

Returning to the assassin agency analogy: as assassins grow more capable, the boss's only option is still to build that comprehensive acceptance system covering planning, process, and delivery. Software development using AI coding faces an isomorphic problem. The only way forward is not to hope that the executor will someday self-regulate, but to build a control system that does not depend on self-regulation.

Compliance Gaming and Context Loss

Since AI cannot be held accountable, we must understand exactly what is happening inside its black box. The problems that arise when AI writes code may appear varied on the surface, but they ultimately fall into two categories: compliance gaming and context loss.

Let us start with compliance gaming. Ask AI to follow TDD, and it is likely to write the code and a passing test simultaneously, skipping the RED phase entirely—the result looks the same, but the process is completely wrong. Ask it to follow the project's architectural standards, and it may comply with only the portion it "sees," ignoring the other half because it was not in context. Ask it to fix a bug, and it may only address the surface symptom, because it has no awareness that a refactoring three months ago completely changed the internal logic of that module.

This is not intentional deception—it is simply that AI's optimization target is "satisfying the currently visible explicit requirements," and it has no perception of implicit quality expectations.

Then there is context loss. Architectural decisions confirmed in the previous conversation are forgotten when a new session starts; code style conventions repeatedly emphasized are abandoned as AI reverts to the default patterns in its training data. For AI, almost every interaction is a fresh start.

The most critical root cause of all these problems is that AI's context management capability is currently very limited—it cannot ensure that the context loaded during AI coding actually contains all the expected content.

You can tell AI to "follow the architectural standards," but you cannot confirm that it actually read the standards document in full. You can say "pay attention to the recent changes in this module," but you have no way of knowing whether it reviewed the last three months of git logs or just glanced at the latest commit message. You cannot even be certain that when it is writing code, the context in its "mind" is the current project's context—or a pattern from some similar project in its training data.

It is like handing an assassin a target dossier but having no way to verify how many pages they actually read, or whether they noticed the critical note on page three that the target recently changed bodyguards. If they miss it, the entire execution plan is built on faulty intelligence.

For human developers, context management is an internalized capability. A senior developer picking up a bug will automatically review related design documents, check recent change history, and recall why this module had problems last time—this is professional instinct honed over years. AI has no such instinct; its context depends entirely on what is externally fed to it. Feed it too little, and it fabricates on an incomplete information base, producing code that "looks right but is actually wrong."

As a result, more and more of the team's work is actually context engineering—organizing the project's knowledge, standards, history, and constraints into a format that AI can consume. This is already part of harness engineering.

"Just Wait for the Models to Get Better"?

At this point, a common objection arises: AI is advancing rapidly—today's problems may not exist tomorrow. Isn't investing heavily in a process oversight system a waste of effort? Can't latecomers simply wait for models to become powerful enough and use them directly?

The answer is no, for two reasons.

First, process oversight is quality infrastructure, not a patch for model deficiencies.

Perhaps one day AI will write perfect code without following TDD principles. But even then, oversight of the RED/GREEN process and traceability of AI's reasoning will remain the core means of tracing issues and iterating improvements at a finer granularity.

This is like quality inspection on a factory floor. Even if the production line's pass rate has reached 99.99%, you would not dismantle the inspection process—because the value of inspection is not just "catching defects," but "understanding why defects occur so you can continuously optimize the production line."

An important point must be made here: improvements in AI capability are not limited to coding—they also improve the oversight system. Stronger models mean better process analysis, more accurate output evaluation, and smarter workflow scheduling. The efficiency of harness engineering scales with model capability—this is not a direction opposed to model progress; it is aligned with it.

Second, humans have a reliable context system; AI does not—and this gap will not automatically close as models get stronger.

Consider an example. A critical production issue requires a rapid fix. In a human team, an experienced developer can quickly assess the blast radius of a code change—if the impact is minimal, they can bypass standard quality processes and ship a hotfix immediately. This decision is reliable because it is backed by a complete, internalized context system: system architecture, module dependencies, hard-won lessons from past failures.

But for AI, the black-box development process makes it impossible to assess whether its judgment about system impact is reliable. It says "this change has minimal impact"—on what basis should you believe it? It says "only this one file needs to change"—how do you verify? A human developer's judgment is backed by years of domain experience; AI's judgment is backed by an invisible probability distribution.

Stronger models will make AI's judgments more accurate, but they will not make its reasoning process traceable. And in engineering practice, traceability is just as important as accuracy.

Learning from the Front Runners: OpenAI and Beyond

So how exactly do you practice harness engineering? Let us look at what the teams at the frontier are doing.

OpenAI internally practices a methodology called Spec-Driven Development. The core idea is simple: before writing any code, have AI generate a detailed specification (Spec); a human reviews the Spec; then AI implements strictly according to the Spec. According to their engineering team, there are already projects running with three engineers, five months, and zero hand-written lines across a million-line codebase.

This sounds radical, but the logic is self-consistent. A Spec is an explicit harnessing mechanism. Rather than trying to control AI's coding process, quality requirements are front-loaded to the Spec phase—AI writes not "code" but "an implementation of the Spec." Acceptance criteria become clear accordingly: is the implementation faithful to the Spec, not whether the code "looks" correct.

Their subsequently released Codex (Symphony framework) system is essentially the tooling embodiment of this philosophy—breaking complex tasks into multiple stages, each with defined inputs, outputs, and validation criteria; AI executes stage by stage, and the system validates stage by stage.

But OpenAI's practice has an important prerequisite: most of their work involves greenfield projects. Starting from scratch, with no legacy baggage, no stale code, and all project context definable from the ground up in the Spec.

For most real-world teams, the situation is entirely different.

Our Experiments at PolarDB-X

The PolarDB-X database project is a textbook example of "entirely different." This is a project with deep historical accumulation—millions of lines of code, over a decade of evolution, complex module dependency chains, and a wealth of implicit knowledge that exists only in the minds of senior engineers.

Doing AI-assisted development on such a project is a fundamentally different challenge from building something from scratch.

What is the reality? A significant portion of the team's development effort is actually spent on AI adaptation for the project—that is, context engineering. Structuring design documents, organizing architectural standards into AI-consumable formats, making module dependency relationships explicit. This work is not glamorous, but it is the prerequisite for AI to be useful on this project.

On this foundation, for development work involving moderately complex tasks, AI can still only play a supporting role. The quality system remains unchanged—engineers remain accountable for the final deliverable. AI is the tool; the human is the accountable entity.

At the same time, a more aggressive direction is being explored: for certain specific task types, can we achieve fully zero-human-intervention, with AI completing the work autonomously?

Specifically, we chose bug fixes and lab case fixes as our testing ground. The reason: problem boundaries are relatively clear, acceptance criteria are relatively well-defined, and the daily volume is large, consuming significant developer bandwidth.

The approach: design a phased task workflow, fully executed by AI stage by stage, with AI plus preset scripts and the existing CI system overseeing the workflow's deliverables at each stage. Each stage has explicit input/output requirements—problem analysis documents, root cause identification, fix proposals, test cases, TDD RED-GREEN verification. It is not a vague "go fix that bug," but rather a bug-fix decomposed into a pipeline with checkpoints.

The critical step is driving workflow iteration through automated scoring of deliverables. Every AI deliverable is evaluated by a scoring system—is the analysis document complete? Do the test cases effectively cover the problem? Did the code changes pass CI?—and the scores feed back to adjust the workflow itself. Effective workflow templates are retained and reinforced; underperforming ones are retired or improved.

The target state: for these routine standardized tasks, AI produces all deliverables and engineers only review the final results. But note that this "review" is different from traditional code review—AI delivers not just code, but also problem analysis documents, test cases, and strict TDD process assurance. Engineers receive a deliverable package with a complete chain of reasoning, making the review burden far lighter than handling the task from scratch.

The developer's role is evolving from "the person who writes code" to "production line designer" and "quality final reviewer."

Closing Thoughts

Objectively speaking, this path is still being explored, and many components are still under construction.

The automated scoring system is the linchpin of the entire closed loop, but it is still in the build phase without sufficient data to prove its effectiveness. Workflow design is still undergoing trial-and-error iteration. What we can confirm is the direction; the exact shape of the destination is still emerging.

But one thing is becoming increasingly clear: harness engineering is not optional—it is the essential path for software development in the AI era.

Not because AI is inadequate, but precisely because AI is too capable. Its production efficiency far exceeds that of humans, but its controllability falls far short. As more development work is handed to an executor that cannot be held accountable, has limited context, and operates as a black box, the choice is binary: either build a control system worthy of this executor's capability, or bear the risk commensurate with that capability.

AI will continue to grow stronger—of that there is no doubt. But "growing stronger" does not mean "requiring no oversight." A fighter jet is vastly more powerful than a bicycle, yet it requires a far more complex control system.

What harness engineering builds is the runway and air traffic control system worthy of that fighter jet. This is not about limiting how high it can fly—it is about ensuring it flies in the right direction.

Community

Harness Engineering: A New Paradigm for Software Production in the AI Era

A Fundamental Question

A Double-Edged Sword

The Assassin Agency

Compliance Gaming and Context Loss

"Just Wait for the Models to Get Better"?

Learning from the Front Runners: OpenAI and Beyond

Our Experiments at PolarDB-X

Closing Thoughts

Read previous post:

ApsaraDB

You may also like

Comments

ApsaraDB

Related Products

PolarDB for Xscale

PolarDB for PostgreSQL

PolarDB for MySQL

Qwen