Harness AI Programming in Practice: A Guide to Engineering Claude Code E-Commerce Projects

The rise of AI programming tools has sparked a controversial question: can someone with zero technical background independently build a project using Claude Code, Codex, or Cursor? In a public course, Bilibili creator Mr. Zhu offered his observation — it's true that non-technical people have managed to produce projects with these tools, but their output almost always stays at the demo level: simple web pages, wrappers, mini-games. For anything moderately complex — especially enterprise-grade projects involving high concurrency, distributed architecture, or massive data processing — people without a technical background can hardly finish them independently.

This raises a key proposition: the real value of AI programming tools is not replacing programmers, but amplifying the productivity of those with technical skills. And to achieve that, a systematic engineering methodology is needed — Harness Engineering.

From Prompt Engineering to Context Engineering: The Three Stages of AI Programming

To understand the value of Harness Engineering, we first need to see the evolution of AI programming paradigms.

Mr. Zhu divides AI-engineered programming into three stages. The first is Prompt Engineering, whose core is asking the question clearly. When ChatGPT first appeared, the whole industry was studying how to write better prompts — essentially a question-and-answer interaction model.

The second stage is Context Engineering, which solves the problem of making AI understand the background. He gives an example: asking Doubao to write a technical article in his own writing style based on a one-line instruction will inevitably produce poor results — because the model doesn't know what "Mr. Zhu's" style is. But if you feed it hundreds of articles he previously wrote as context, letting it learn first and then output, the results are much better. This explains why most developers using Claude Code or Cursor today proactively provide code references and specification snippets.

According to Mr. Zhu's observation, more than 95% of developers today are still stuck at the Context Engineering stage. The third stage — Harness Engineering — is the key to handling enterprise-grade complex projects.

Prompt Engineering is the most basic level of AI interaction. Its core assumption is: the model is already capable enough, and the key is how to express requirements accurately. Early research focused on techniques like role-playing, few-shot examples, and Chain-of-Thought, aimed at making the model output more aligned with expectations. However, Prompt Engineering has an obvious ceiling — it cannot solve the problem of the model knowing nothing about project background. After a conversation ends, the model won't remember the architectural decisions, naming conventions, or business constraints you previously told it. This is precisely what Context Engineering aims to solve.

Context Engineering is essentially about managing the model's "working memory." Large language models are stateless — each inference is based only on the input within the current window. Context Engineering systematically organizes materials like code snippets, documents, historical conversations, and specification files, injecting necessary information into the model's window at the right moment, so that the AI's output aligns with the project's actual situation. But Context Engineering also has limitations: it's good at providing information but not at continuously exerting control during execution. When a task requires multiple steps, multiple rounds of correction, and dynamic strategy adjustments, simply "feeding materials" cannot guarantee the AI won't go off track — which brings us to Harness Engineering.

What Exactly Is Harness Engineering?

The word "Harness" in English means "horse tack" or "reins." Mr. Zhu uses an intuitive metaphor: a large model is like a powerful hunting horse — highly capable but requiring effective harnessing. The Harness is the system of tools that lets the rider command the horse to turn left, turn right, and accelerate.

Translated into engineering language, Harness Engineering means: Large Language Model + Systematic Harnessing Tools = Agent. Unlike Prompt Engineering and Context Engineering, Harness Engineering deals with tasks that require substantial constraints, continuous interactive feedback, and complex control.

One detail worth noting: Mr. Zhu emphasizes that this stage is not simply about "passing a bit of context." It requires developers to constantly correct and give feedback during the AI's task execution, using systematic constraint mechanisms to get the AI to complete complex work.

Agent is the key concept for understanding Harness Engineering. In the AI field, an Agent typically refers to a system that can autonomously perceive its environment, formulate plans, invoke tools, and execute multi-step tasks. Unlike single-turn Q&A, an Agent has loop reasoning capability — it adjusts its next action based on execution results. But the greater the autonomy, the greater the risk of losing control. Harness Engineering is precisely the engineering method that puts "reins" on an Agent: limiting its behavioral boundaries through preset rules, standardizing its tool invocation through skill modules, anchoring its factual basis through knowledge bases, and auditing its output through change management. An Agent without a Harness is like a smart but willful intern; with a Harness, it can become a stable, enterprise-grade productivity unit.

The Engineering System in an Enterprise E-Commerce Project

Mr. Zhu's team, in collaboration with a large model startup, has already delivered over a hundred enterprise-grade projects in the Harness Engineering direction. He chose an e-commerce project as the practical case for a straightforward reason: everyone is familiar with e-commerce business, so no extra explanation of business logic is needed, allowing focus on the engineering method itself.

In this system, several core modules form the complete Harness framework:

Rules — Set clear coding standards, architectural constraints, and business boundaries for AI to prevent code from diverging through iterations.

Skills — Encapsulate reusable capabilities into standardized modules, keeping AI consistent across different tasks.

Wiki — Accumulate project context, business documents, and technical decision records, solving the AI's "amnesia" and hallucination problems.

Changes — Manage and review AI-generated code changes in a structured way, ensuring project maintainability.

The direct effect of this system is that it addresses the most common problems developers encounter. In a course survey, students reported typical pain points including: code turning into unmaintainable "spaghetti" as it grows, AI amnesia and random writing due to insufficient context, rapidly consuming token costs, and issues AI repeatedly fails to fix. Mr. Zhu points out that for developers with technical skills, the vast majority of these problems can be solved through the Harness framework; for non-technical beginners, once the AI "can't fix it anymore," the project is completely stuck.

In the actual implementation of Harness Engineering, the four modules — Rules, Skills, Wiki, Changes — do not exist in isolation but form a closed-loop control mechanism. Rules draw boundaries before a task starts, equivalent to giving the AI a "construction spec"; Skills provide standardized capabilities during task execution, like prefabricated components, reducing quality fluctuations caused by AI improvisation; Wiki provides factual basis throughout the task, like a "project encyclopedia" available at any time; Changes audits and traces back after task completion, like a quality inspection checkpoint. When the four work together, even if the AI deviates at some step, it can be detected and corrected in time through change management, preventing errors from accumulating into an unmanageable "spaghetti." Another implicit value of this framework is that it turns AI programming from a "one-off conversation" into an "iterable engineering process," making projects maintainable in the long term.

Will Programmers Be Replaced by AI? A Judgment Based on Engineering Reality

In the course, Mr. Zhu spent considerable time addressing the anxiety that "AI will put all programmers out of work." His judgment is clear: non-technical people who produce projects with AI tools do exist, but their work, every single one, is at a very small demo level. For technical projects involving high-concurrency microservices, distributed architecture, or massive data processing at major internet companies, there has never been a case of someone completely without technical knowledge independently completing one with AI.

His conclusion: the AI impact is real, and layoffs are a fact, but those who ultimately remain are people in every industry who both understand their professional domain and know how to leverage AI tools. This judgment is consistent with his experience as an architect at a major tech company and later as a startup founder working on enterprise large-model projects.

"If AI could truly replace all programmers, why don't software companies lay off all their programmers and just have product managers hand requirement documents to AI?" Mr. Zhu closes the topic with a rhetorical question.

From an engineering reality standpoint, the gap between enterprise-grade projects and demos is far greater than it appears. A working demo usually only needs to implement the core functional path, ignoring non-functional requirements like exception handling, concurrency safety, data consistency, access control, and observability. Enterprise-grade systems, however, spend enormous engineering effort precisely on these "invisible places." In high-concurrency scenarios, a single cache penetration or lock contention can cause a production incident; in distributed architectures, timeout, retry, and idempotency design between services require precise trade-offs; massive data processing involves partitioning strategies, resource scheduling, and fault-tolerance mechanisms. The solutions to these problems cannot be "asked out" of prompts — they depend on a developer's deep understanding of system behavior, and that understanding is exactly what current AI struggles to generate independently.

Suggested Learning Path for Harness Engineering

Mr. Zhu's course design is primarily hands-on, with dozens of pages of accompanying documentation, but the theoretical part is concentrated in the first twenty to thirty pages, with everything afterward being project practice. His teaching philosophy is "learn it and use it immediately" — through two complete practical projects, developers understand how Harness Engineering is implemented in real work.

For developers who want to get started quickly, he recommends starting directly with Claude Code (Codex and Cursor are also alternatives), experiencing the collaboration of the four modules — Rules, Skills, Wiki, Changes — in real projects. The concepts become naturally clear through practice, far more effective than simply memorizing terms.

The core value of this methodology is not the tools themselves, but that it answers a practical question: as AI programming moves from "writing a small feature" to "delivering enterprise-grade systems," what kind of engineering capability do developers need to harness it?