AI-Native Delivery Evolution: Harness Framework for Controllable, Auditable Engineering

Introduction

Dewu's Xiaotan project is an innovative business incubated from 0 to 1. For a period, I simultaneously handled design, implementation, integration, and delivery of H5, admin backend, Node gateway, and Go services. As the business advanced and collaboration scope expanded, a single requirement often had to traverse multiple engineering and runtime environments. I began letting AI participate in parallel development across these modules. Code output speed increased significantly, and one person effectively gained a "virtual full-stack team."

Codex evaluation of development capabilities based on recent task records.

However, after the engineering radius expanded, new problems emerged: how to ensure the same business rule remains consistent across different runtimes, changes stay within boundaries, and verification, acceptance, and release remain traceable? To solve this, I shifted focus from "writing smarter prompts" to exploring a Delivery Harness for solo full-stack delivery.

In this chain, AI can retrieve, implement, supplement tests, organize reports, and even drive multiple modules simultaneously; but every state transition must be backed by contracts and evidence: whether requirements were read correctly, whether changes exceeded boundaries, whether business invariants hold across runtimes, whether the product was confirmed on real devices, and whether production release left auditable anchors.

I call this system Delivery Harness . It solidifies a person's engineering judgment into four reusable components: Version Contract locks facts, Execution Boundary limits change radius, Evidence Gate controls state transitions, and Repair Loop turns real feedback into default rules for the next round. It does not replace engineering judgment but puts the timing, inputs, and results of judgment into an auditable chain. Even when driven by one person, subsequent reviewers can see why it was done and on what basis it proceeded.

A Semantic Fork: How One Number Impacts the Entire Delivery Chain

The first semantic fork that alerted me was tiny: a seemingly ordinary progress number on the group-buy page—whether the target headcount should be the minimum group-buy number or the current available inventory.

Both numbers exist in the system and both can be justified. Minimum group-buy expresses "what condition triggers success"; inventory expresses "how many more can be sold." The formula is simple; the danger is that if I guess wrong here, the error propagates through interfaces, pages, share posters, and acceptance test cases.

Initially the input was just a discussion. Product cared whether the user-facing progress was reasonable; engineering cared where the field came from; testing cared how to construct reproducible state. If we simply picked a "seemingly more reasonable" value and started coding, subsequent design, implementation, and testing would all be self-consistent on a wrong premise.

The core is a business semantic fork. AI may not be more prone to guessing wrong, but it can spread a single guess at high speed into a shared premise across interfaces, pages, posters, and tests.

I then broke the distortion chain into five control points: input deviation, execution overreach, verification absence, defect escape, and feedback fracture. They cascade: missing a rule at input means no corresponding branch in design; testing anchors to existing implementation; ultimately a non-existent business path may enter acceptance with a "verified" label.

The first goal of Delivery Harness is direct: expose errors at the cheapest, earliest position and prevent unproven states from propagating further.

From Prompt to Harness: Four Components Managing Delivery State

This Harness wraps around the model and takes charge of four things: which facts the task reads, how large a range the agent may modify, how results are proven, and under what conditions it must stop. The model handles generation and judgment; Harness handles boundaries and state.

Prompts continue to carry intent and context; permissions, release, and evidence gates go to deterministic systems. Once paths, branches, document registration, repository scope, and release anchors have objective answers, they should not be left for the model to re-guess in every task.

I distinguish two classes of problems:

Paths, branches, file scope, whether interfaces go through a unified gateway, whether release records are complete—these have definite answers and suit scripts and gates.

Product semantics, architectural trade-offs, real experience, cross-file semantics—these require context understanding and can be judged by constrained agents, but final responsibility remains with a human.

The four components form a closed loop: Version Contract provides facts; Execution Boundary constrains execution; Evidence Gate decides whether to advance; Repair Loop writes real feedback back into the contract.

Harness Layer 1: Version Contract Locks Facts and Boundaries

Version Contract and Execution Boundary together solve the two easiest-to-lose-control problems: what serves as the truth for this delivery, and what exactly the agent is allowed to do.

"What should be looked at" is not stuffing all materials into context at once. Facts should reside closest to their source: confirmed product semantics stay in product docs; impact scope and technical solution stay in spec changes; version and delivery repos enter the version contract; acceptance results enter a unified report; real defects enter Repair Cases. At task start, only the portion needed for this round of judgment is loaded.

This creates a hard boundary: temporary inferences cannot automatically become long-term facts. Only after being confirmed by documents, code, or verification results can they enter the default context of subsequent tasks.

"What is allowed" lands in repository and environment rules. Each requirement uses an isolated workspace and branch; cross-repo changes must be declared per repo; clients cannot bypass the unified request layer to hit business services directly; special test environment entries cannot be casually extended to staging or production; when external writes, releases, or message sends are involved, the process stops without explicit authorization.

Worktree: Turning Requirement Boundaries into Physical Isolation

In this project, worktree is not a Git trick but the first layer of Execution Boundary implementation. Every new product requirement, defect, or independent technical need must create a dedicated worktree from a verified stable baseline before first write; pure read-only analysis does not create one. Confirmed versions are named by version and topic; unscheduled prototypes by date and topic; dev branches use a unified namespace.

The same requirement reuses the first-created worktree and branch throughout development, UI and interface linkage, integration fixes, acceptance rework, to release closure. When multiple code repos are involved, each repo retains one workspace. Thus the isolation unit can be expressed as: one requirement × one repo = one worktree. Multiple repos are linked by the same version contract but do not share uncommitted files, branch states, or dependency environments.

Worktree lifecycle: read-only tasks create no tree; first write verifies baseline then isolates workspace per repo; development through release closure continuously reuses; only after production release record succeeds, all required commits are pushed, release records are complete, and evidence is persisted, can git worktree remove be executed from another registered worktree, followed by git worktree prune; direct directory deletion, forced removal, and auto branch deletion are prohibited. These constraints enter the version contract and delivery checks.

Below is an abstracted version contract structure schematic: multiple requirements and technical docs enter the same version; different code repos declare delivery scope separately; test, staging, unified acceptance, and production release each record status, with incomplete items staying pending. The diagram shows structure only, not real versions, repos, or release data.

Harness Layer 2: Evidence Gate Decides Whether to Proceed

Evidence Gate does not accept a mere "code complete." Compilation, unit tests, interface verification, real-device acceptance, production release, and stable-branch merge are six distinct states; each step must produce evidence matching the conclusion.

Every delivery must answer four questions: which requirements and repos are registered for this version; which test case corresponds to each product rule; what auditable evidence the cases produced; which experience judgments still require the product owner. If not fully answered, the state stays put.

The unified acceptance report is a "document–requirement–case–evidence" mapping, not a completion manifesto. Anyone should be able to trace along it to command results, real-device screenshots, run logs, and uncovered items. Document read failure, rule without case, cross-module without receipt—state uniformly stays pending.

The most confusing part is delivery states. They cannot be equated:

Code Complete ≠ Dev Verification Passed ≠ Product Acceptance Criteria Met ≠ Real-Environment Product Acceptance Passed ≠ Production Released ≠ Merged to Stable Branch

Automation suits checking interfaces, states, boundaries, and page elements. Whether real-device operation feels awkward, whether copy is misleading, whether container and network conditions meet expectations—these still need product owner judgment. AI can organize evidence but cannot sign off for the responsible person.

Next phase plans to introduce an independent evaluation perspective: another evaluation agent reads only requirements, diff, and test evidence to independently judge whether to allow entry into acceptance. Further separating generation from evaluation will make evidence gates more stable.

Harness Layer 3: Repair Loop Upgrades System from Real Feedback

Repair Loop handles system memory. For cross-module, cross-environment, or recurring issues, merely recording "what was fixed last" has no value; original feedback, localization process, failing baseline, candidate results, and regression results must land in the same Repair Case.

I set a strict completion condition for Repair Case: on different commits, baseline check must fail; candidate fix must pass; regression check must also pass. When objective red/green contrast cannot be established, the Case stops at an early stage with limitations noted. Environment recovery cannot be written as a code fix; intermittent issues cannot be declared solved just because they temporarily stop reproducing.

A feedback only counts as truly absorbed by the system when it changes the default behavior of the next task: what can be written as a test enters tests; what can be solidified as a permission boundary enters gates; what can become a version invariant enters the contract. The endpoint of Repair Loop is not a retrospective doc, but the next same-class error failing earlier.

Real Battle: A Multi-SKU Order Traversing Multiple Runtimes

This Harness faced its first full cross-runtime test in a multi-SKU fulfillment refactor.

An order originates from the user end, passes through admin backend, Node service, and Go service, then enters downstream systems. If any layer misinterprets "order" as "SKU," it creates locally correct but globally wrong results: frontend shows complete, backend processes only part; interface returns success, downstream generates multiple unrelated fulfillment records.

We first wrote the single inviolable business invariant into the contract: order is the atomic fulfillment unit. Multiple SKUs share one fulfillment decision—either the whole order is accepted or the whole order fails; external receipts must rely on a persisted stable identifier to return to the original order, not on guessing associations from the current request.

Delivery Harness did a key thing here: it turned "order-level atomicity" from a product phrase into a cross-runtime invariant. Product docs define semantics; interface contracts constrain I/O; server side validates resources and state; tests actively construct partial-failure counterexamples; acceptance report records cross-service results; relevant code repos each retain branches, commits, and release evidence.

Hard Ledger: Established Capabilities and Gaps

This system is operational but not yet a "mission accomplished" architecture. Three areas still need building:

First: Unify local and CI check entry points so the same rule set covers real commits and remote pipelines.

Second: Feed the full version contract and delivery contract into the pipeline so local verification and remote gates use consistent standards.

Third: Unify stable branch and version contract semantics so the system can reliably judge whether a version has entered the stable mainline.

Next-phase goals: Let an independent evaluation agent read only requirements, diff, and evidence to make a second judgment; plug full contract checks into CI; then use runtime observation to automatically feed production feedback back into Repair Loop.

Conclusion: The Ceiling of AI-Native Is Not Generation Speed

Delivery Harness adds a few steps to a task: verify fact sources, confirm boundaries, run contract checks, organize evidence, wait for real-environment acceptance. Looking only at the generation moment, it is slower; placed in the full delivery cycle, it prepays the cost of rework, overreach, false positives, and irreproducibility.

What it truly amplifies is a person's effective engineering radius: I can let AI enter four runtimes simultaneously without keeping all quality judgments in my own memory. Contracts guard boundaries; evidence drives state; real feedback upgrades the system.

The endgame of AI-Native delivery is to let models take on more and more execution work while making every delivery conclusion inspectable, reproducible, and accountable. Speed can be amplified by models; quality order must be guaranteed by the system.

That is why I am increasingly certain AI-Native will change not only R&D efficiency, nor stop at "product writes PRD, engineering feeds PRD to AI for code generation." When requirements, versions, implementations, and evidence are connected by a single Harness, the basic unit of product-engineering collaboration shifts from document handoff to verifiable hypotheses: product defines business invariants and real-experience standards; engineering translates them into interface contracts, state machines, gates, and observability; AI continuously completes solutions, generates implementations, constructs counterexamples, and replays evidence between the two.

Product no longer needs to wait until development finishes for first acceptance; engineering no longer needs to wait for a "100% complete" PRD to start. Both can advance in parallel around the same fact source, but state transitions still have only one standard: is the hypothesis confirmed? Is the boundary enforced? Is the evidence sufficient to support the next step? AI expands exploration and execution speed; humans own business judgment, engineering trade-offs, and final sign-off.