教授 Supervisor of Doctorate Candidates
2026-08-14
|
This is the English translation of an article originally published on our team's WeChat official account, CodeWisdom.
To read the original Chinese version of this article, please visit: https://mp.weixin.qq.com/s/NhOiHVx8NrvNjhPHvd2Mag
In early 2026, OpenAI unveiled an internal experiment that captured the industry's attention: a small team of just three engineers (later expanded to seven) started from an empty Git repository in August 2025 and, over five months, delivered a complete beta product containing over one million lines of code—using their in-house Codex AI agent. Not a single line of code was written manually by human engineers throughout the entire process. When something broke, the team's response was not "let me fix it manually," but rather "what capability is the agent missing, and how can we make it understand and execute this fix?" The initial three-person team averaged 3.5 pull requests per person per day, accumulating roughly 1,500 merged PRs, delivering roughly 10x the development productivity of traditional approaches. As the team grew to seven, overall throughput continued to increase.
This experimental result sparked strong reactions among enterprise R&D leaders and software engineers alike. Excitement was accompanied by anxiety and confusion. One core question emerged: do the development processes, software engineering platforms, toolchains, and quality systems that enterprises have built over the years still matter? If AI's code generation capabilities have become this powerful, are these processes, platforms, and quality assurance measures now constraints? Or even, in a future with sufficiently powerful AI support, can all of this be abandoned?
These questions deserve serious consideration. This article, while tracing the evolution of AI Coding engineering methodologies, acknowledges the significant progress in AI-assisted software development on one hand, and on the other hand, argues for the irreplaceable value of enterprise software engineering systems from the first principles of system complexity. Based on this, we explore how enterprises can actively embrace AI while placing high priority on long-term infrastructure building—for example, through Code Digital Twin systems to enable the continuous accumulation of software development knowledge, and through human-AI collaborative development platforms built around the philosophy of "AI as Chief of Staff, not Commander-in-Chief."
Over the past two years, the engineering methodology surrounding AI Coding has undergone three significant paradigm shifts: from Prompt Engineering to Context Engineering, and now to the emerging Harness Engineering. This evolutionary path itself carries profound engineering insights.
Prompt Engineering was the first systematic methodology for AI interaction. Its core concern is how to better formulate requests to large language models—by carefully designing the structure, wording, and examples of prompts to guide the model toward higher-quality outputs. From zero-shot to few-shot, from Chain-of-Thought to Tree-of-Thought, Prompt Engineering has accumulated a wealth of practical experience through continuous evolution.
In software development scenarios, Prompt Engineering places particular emphasis on the standardized description of requirements—how to transform vague development needs into instructions that large language models can accurately understand and execute. This aligns closely with the emphasis on Requirements Specification in classical software engineering. Indeed, the more complex the coding task, the more it requires clear and complete functional descriptions and constraints in the prompt—which precisely confirms a fundamental principle that software engineering has reiterated for decades: good software begins with a good definition of requirements.
As the capabilities of large language models grew and context windows expanded, the industry gradually recognized a more fundamental issue: the bottleneck on output quality is often not "how to ask," but "what the model can see." As Andrej Karpathy put it, context engineering is "the delicate art and science of filling the context window with just the right information". It focuses on how to dynamically select, organize, and optimize the background information provided to large language models, including system prompts, working memory, long-term memory, and environmental context.
In the AI Coding domain, the core concern of Context Engineering is the supply of software development knowledge—how to enable AI to understand the current project's codebase structure, architectural design principles, coding standards, API interface definitions, and historical design decisions. Current explorations and practices around software knowledge in AI Coding, such as project-level code graphs and project wikis, are valuable attempts in this direction. The knowledge dimensions emphasized by Context Engineering are highly consistent with software engineering's longstanding pursuit of development knowledge management and accumulation—the difference is that this knowledge previously served human developers primarily through documentation, and now it must also serve AI agents.
Entering 2026, Harness Engineering rapidly gained prominence as a new conceptual framework. The concept originated from the OpenAI team's practices in the aforementioned "million lines of code" experiment, and was subsequently systematized by Thoughtworks senior engineer Birgitta Böckeler in an analytical article published on Martin Fowler's personal website, which proposed a structured framework combining software engineering practices and experience with AI agent harnessing.
In the context of Coding Agents, Harness is defined as "everything in the agent except the model itself"—that is, Agent = Model + Harness. For users of coding agents like Codex, Claude Code, and Cursor, the inner harness (Builder Harness) is provided by the tool vendor, while the outer harness (User Harness) needs to be custom-built by users for their own projects and systems. Harness Engineering focuses on the systematic design of this outer harness.
Birgitta Böckeler's article proposed a clear 2×2 matrix framework to organize harnessing strategies. The first dimension is control direction: Feedforward control corresponds to "Guides"—setting rules and constraints before the agent acts to guide it toward generating code in the right direction; Feedback control corresponds to "Sensors"—detecting the quality of results after the agent acts, helping it identify issues and self-correct. The second dimension is execution mode: Computational means are deterministic and fast, such as type checking, static analysis, and automated testing; Inferential means leverage large language models for semantic judgment, such as AI code review and "LLM-as-judge," which are more expressive but also more expensive and non-deterministic.
From this framework, we can see that a good harnessing system needs to combine feedforward guidance with feedback sensing—feedback without feedforward means the agent will make the same mistakes repeatedly; feedforward without feedback means we have no way of knowing whether the guidance rules are truly effective. At the same time, it needs to combine computational means with inferential means—the former providing deterministic "hard constraints," the latter providing semantic-level "soft judgment."
A vivid example is LangChain's coding agent performance on Terminal Bench 2.0: by merely changing the harnessing strategy (with the same model), the score jumped from 52.8% to 66.5%, propelling it from the Top 30 to the Top 5 on the leaderboard. The same model, different harnessing—dramatically different results.
What is worth pondering is that these seemingly novel AI Coding engineering methodologies are, at their core, a "rediscovery" of classical software engineering methodologies and practices: Prompt Engineering corresponds to requirements engineering; Context Engineering corresponds to knowledge management; test feedback loops correspond to CI/CD; Claude Code's Skills mechanism corresponds to software reuse; progressive disclosure corresponds to abstraction and decomposition. Even one of the core lessons from OpenAI's "million lines of code" experiment points in the same direction: they enforced layered architecture dependency constraints (Types → Config → Repo → Service → Runtime → UI) through customized linters and structural tests, and performed regular "technical debt garbage collection"—encoding "golden principles" into the code repository, building automated background Codex tasks that scan for violations and open targeted refactoring PRs. Isn't this exactly the classic practice of layered architecture, dependency inversion, and continuous refactoring?
These observations tell us an important fact: AI has not made software engineering obsolete. On the contrary, the introduction of AI has made us more deeply aware of the value of classical software engineering practices. What is changing, however, is the form and execution of these practices—shifting from management and regulation for human developers to systematic guidance and constraint for AI agents.
If AI Coding engineering methodologies are advancing rapidly, then why do people's experiences with AI Coding remain so divided—some marveling that "10x efficiency improvement is no dream," while others complain that "AI-generated code is worse than writing it myself"? To answer this, we first need to clarify the information structure behind the current cacophony.
The first type of voice comes from stakeholders—tool sellers, course sellers, book sellers, and training providers. Their claims are not necessarily lies, but the selective narratives and exaggerations warrant caution. When an AI programming tool vendor proclaims how many times their users have improved efficiency, one should ask about the specific scenarios and measurement criteria behind that number. The second type comes from trend-chasers—some media outlets habitually package every AI Coding advance as a "disruptive breakthrough" to attract attention and traffic, with clickbait-style dissemination further amplifying collective anxiety. The third type comes from developers who have pioneered successful paths with AI Coding. Their experiences are genuine, and their success stories are highly valuable, but one should note that they may, in their excitement, over-generalize and exaggerate their success under specific project types and complexity conditions—their generalizability needs to be judged in light of specific contexts.
Beyond these voices that require discernment, many developers report genuine experiences. But as Zhang Gang put it in our "Intelligent Software Development Micro-Interview" #41 ["From Vibe Coding to SDD: A Review of AI-Assisted Development in 2025"](https://mp.weixin.qq.com/s?__biz=MzU4NDU4OTM4OQ==&mid=2247515280&idx=1&sn=ed256d9ec771529b99dfd1a7506e155f&scene=21#wechat_redirect), this is like the fable of "the little horse crossing the river": the squirrel says the water is deep, the ox says it's shallow, and only when the little horse tries it himself does he find it's neither as deep as the squirrel said nor as shallow as the ox said. Everyone faces different software project types and levels of complexity, different development modes (greenfield vs. maintenance), different team technology stacks and engineering maturity, different personal domain knowledge and programming experience, and different AI tools and methods—these factors together determine the "depth of the water" in each person's AI Coding experience.
The key to understanding this diversity lies in recognizing that the software spectrum is extremely broad. A typical personal project might contain hundreds to thousands of lines of code involving 1–2 technology stacks; a large enterprise software system might contain tens of millions of lines of code, hundreds of microservices, involving a dozen technology stacks and dozens of teams—the complexity gap between them may span three to four orders of magnitude, comparable to the distance between a bicycle and a spacecraft. For smaller, less complex software (such as simple web applications, script tools, data analysis pipelines), AI can indeed already generate complete code and make modifications as needed—"10x efficiency improvement" in such scenarios is entirely credible. But for larger and more complex enterprise software, AI's performance is far less impressive. What is the core obstacle behind this? The answer points to a fundamental problem we must seriously confront: system complexity.
The core issue hindering deeper application of AI in enterprise software development is, ultimately, system complexity. And this complexity goes far beyond sheer size factors like lines of code and number of files—it is more deeply manifested in the intricate relationships and mutual influences among different parts of the software.
Turing Award winner Frederick P. Brooks, in his classic 1986 paper *"No Silver Bullet: Essence and Accidents of Software Engineering,"* distinguished two types of complexity: Essential Complexity, which is inherent to the problem domain itself and irreducible; and Accidental Complexity, which is additionally introduced during the solution process due to deficiencies in tools, methods, technologies, or architecture. Enterprise software development must simultaneously face the squeeze of both types of complexity. In terms of essential complexity, under the trend of "software-defined everything," software is rapidly penetrating all aspects of socio-economic life, with complex business logic from various industries being increasingly mapped into software. The business rules, regulatory compliance requirements, risk control strategies, and multi-channel interaction logic that a large banking core system must handle represent essential complexity that is itself continuously growing.
In terms of accidental complexity, enterprise software development in the vast majority of cases must deal with numerous legacy systems. These systems, after years or even more than a decade of continuous evolution, have accumulated substantial technical debt—overly coupled module relationships, inconsistent design styles, deteriorated abstraction layers, uncleaned deprecated code, and a vast body of "ancestral" legacy code that "looks unreasonable but breaks if touched". Although these accidental complexities are theoretically "avoidable," under real engineering constraints (limited time, limited understanding, limited accountability), they are almost inevitably generated. As I have previously argued, "accidental complexity" contains a deep "inevitability." It is true that AI technologies such as large language models and agents, through their permeation into software forms and the development process, may gradually help dissolve some of the historically accumulated accidental complexity, but this process may be very long.
In understanding system complexity, there is a dimension often overlooked but extremely important: the awe and sense of responsibility that human engineers possess. An experienced engineer, when modifying a complex system, typically has an instinctive alertness. He does not treat "all tests passing" as the sole criterion for completion—he starts from his understanding of the requirements and considers all development requirements as fully as possible, including those implicit constraints not explicitly written as test cases. More importantly, when he feels his understanding of a certain part is insufficient and he cannot confidently grasp the impact of the modification, he proactively seeks help—consulting with architects to analyze the design, bringing in domain experts to discuss business logic, or running a small experiment to verify his assumptions. This metacognitive ability of "knowing what one does not know," combined with the sense of responsibility that "one's name is on the commit," is an important self-protection mechanism for human engineers when facing complex systems. It cannot eliminate complexity, but it can build a resilient defense line in the face of complexity. As we will see later, this is precisely a key dimension currently lacking in AI for software development.
Another important feature of system complexity is emergent effects—the system's components, through complex interactions, produce entirely new behavioral patterns at the overall level that cannot be predicted from individual parts alone. This is like a city's traffic system: each car's behavior is rational and predictable, but the interactions of tens of thousands of cars can create completely unexpected congestion patterns and chain reactions. The emergent effects in software system performance, reliability, and security are similar.
From a spatial perspective, there are intricate interactions among different modules, services, and components of software. A seemingly reasonable modification in one place can cause unexpected problems elsewhere through multi-layered mutual influences (including both explicit dependencies like call relationships and implicit interactions like resource sharing). During one exchange, an enterprise expert mentioned that after making some modifications to their system, full regression testing would take a week to run; without running it, they were genuinely worried about potential problems lurking somewhere unexpected. This concern reflects the "unknowable" change impact brought by system complexity.
From a temporal perspective, software grows in an evolutionary manner, and design and implementation decisions from different periods can form unexpected couplings. Hyrum's Law profoundly reveals this: when an API has enough users, all observable behaviors of the system will be depended upon by some users, even if those behaviors are not promised in the documentation. This means that much code in a software system that appears "modifiable" is actually already "locked in" by external dependencies, and any change requires extremely careful impact analysis.
We have seen that Harness Engineering, at the methodological level, is a natural embodiment of classical software engineering wisdom with significant value. But methodological continuity does not equate to resolving the underlying challenges. We need to confront a key question: to what extent can these methodologies address the challenges posed by system complexity?
This question can be understood progressively at three levels: the incompleteness of feedback mechanisms (are tests sufficient?), the precision ceiling of guidance (are rules accurate enough?), and the fundamental difficulty of defining architectural constraints themselves (are standards clear enough?). These three limitations together point to a more fundamental concept—Harnessability.
In the Harness Engineering framework, automated testing is one of the most important computational sensors. Using test feedback to help AI iteratively complete software development tasks is the right direction, but it has fundamental limitations. First, test cases are difficult to make complete—especially for complex business logic and system interaction scenarios, exhaustively enumerating all possible state combinations is theoretically infeasible.
More concerning is that AI, driven by test feedback, may develop in the direction of "overfitting"—that is, generating code that happens to pass all existing tests but does not truly satisfy the underlying business intent. This is where the previously mentioned human engineer's "sense of responsibility" and "awe" come into play: human engineers generally do not treat passing tests as the sole goal, but rather start from their understanding of the requirements and consider all development requirements as fully as possible; more critically, human engineers proactively think about "whether there might be problems in areas not covered by tests." AI currently lacks this metacognition—it is a powerful code generator, but not a system engineer with a sense of responsibility. Many have even observed that AI, when possible, will look for loopholes in the evaluation system to "pass" assessments via bypass routes.
Notably, Birgitta Böckeler also acknowledged in her article that Behavior Harness is currently the "elephant in the room"—how to guide and sense whether the application is functioning according to expected functional behavior remains a far-from-solved problem. Her exact words: the current approach "puts a lot of faith into the AI-generated tests, that's not good enough."
The Guides emphasized by Harness Engineering primarily use natural language prompts to guide AI code generation. This approach has two inherent limitations.
On one hand, design rules and technical decisions determined before specific design and implementation commence can usually only be macro-level principles and requirements—such as "use dependency injection," "log formats should follow structured standards," "database access should uniformly use the Repository pattern," etc. These macro-level guides are effective for establishing basic architectural consistency, but it is difficult to achieve precise control over various specific implementation details. In complex systems, "the devil is often in the details"—performance bottlenecks, concurrency issues, resource leaks, and other problems typically arise at the level of specific implementation details. Moreover, as Martin Fowler wrote in his article *"Is Design Dead?"* more than 20 years ago, much design grows incrementally with the software implementation process (so-called "Evolutionary Design"). Expecting to give a complete software design before coding begins (so-called "Planned Design") is generally unrealistic.
On the other hand, natural language instructions are inherently vague and informal expressions, and the large language model's generation process is probabilistic. This is like telling an assistant in Chinese "help me make a delicious dish"—the vagueness of "delicious," combined with deviations in the assistant’s understanding and execution, may result in a dish quite different from what you had in mind. In complex software systems, this "gap between expectation and reality" is magnified countless times. The combination of these two layers of uncertainty makes it fundamentally impossible to achieve control over all implementation details of code through natural language harnessing. For example, human engineers can achieve precise code modifications after careful analysis and deliberation. But how precisely can code modifications achieved through natural language instructions and the probabilistic generation process of large language models actually be, especially when human programmers are not reviewing the code? In fact, as many experts have noted, modifying code through natural language prompts is somewhat like "wishing" or a mysterious "incantation"—often we can only pray that the magical AI will grant our wish.
This is also why the OpenAI team found that AGENTS.md files "decay rapidly"—the more natural language rules there are, the greater the possibility of contradictions and obsolescence, and the more unpredictable the agent's behavior when faced with conflicting instructions. They ultimately condensed AGENTS.md to about 100 lines, using it as a "table of contents" rather than an "encyclopedia."
Harness Engineering emphasizes providing sufficient feedback to AI through sensors, including precise (computational) code inspection rules and tests, as well as imprecise (inferential) large-model code reviews. But this touches upon a long-standing fundamental difficulty in traditional software engineering: how to precisely define the various constraints that software needs to satisfy—especially complex design and implementation constraints? And how to effectively safeguard architecture—especially when human engineers themselves are not entirely sure what the "right design" looks like? The concept of Architectural Fitness Functions, though proposed years ago, remains limited in practice. The reason is that many architectural quality attributes (such as maintainability, extensibility, conceptual integrity, etc.) are difficult to express with precise computational rules. Inferential sensors (such as having another LLM review code) can perform semantic-level judgment, but their non-determinism means the same code may receive different evaluations at different times.
In fact, companies like Huawei have long emphasized the practice of "architecture guardianship"—I first heard this concept from Huawei experts more than a decade ago (they used a tool called Structure101 for architectural analysis and governance), and we have since collaborated on software architecture evaluation. The complexity of software architecture stems largely from the fact that it is effectively submerged in a vast body of code, lacking explicit existence, making identification and evaluation extremely difficult. If software architecture evaluation is already very difficult for human experts, how can we expect another LLM to achieve high-level architectural problem identification through code review? Moreover, as I pointed out in ["The Road to Higher-Level Intelligent Development: A 2023 Summary for LLMs"](https://mp.weixin.qq.com/s?__biz=MzU4NDU4OTM4OQ==&mid=2247508017&idx=1&sn=9fdbbac418ffc20b53fd5940fdcfe8dc&scene=21#wechat_redirect), large language models learn code knowledge in a flat manner, lacking high-level design abstraction knowledge above the code and the deep design decision knowledge behind the code.
The limitations at the above three levels collectively point to a concept particularly worth attention in the Harness Engineering framework—"Harnessability." Birgitta Böckeler's article points out that not all codebases are equally amenable to harnessing—a codebase written in a strongly typed language naturally has type checking as a sensor; clearly definable module boundaries afford architectural constraint rules; frameworks like Spring abstract away details the agent doesn't even need to worry about. The article refers to these as "Ambient Affordances"—structural properties of the development environment that make it legible, navigable, and tractable to agents operating within it. This observation provides a key to understanding the role AI can play in enterprise software development. It emphasizes the importance of environment construction: building an environment for the agent that is understandable, navigable, and controllable, thereby enabling the agent to explore autonomously within it and iteratively work toward achieving goals based on feedback.
If a software system achieves sufficient decoupling through good architectural design, AI can generate code for each module relatively independently. Microservice architecture is a typical example—relatively independent microservices can independently generate code based on precisely defined interfaces without overly worrying about mutual influences. If a software system, through appropriate abstraction, decouples the development process from low-level details, it can also significantly reduce the complexity that AI needs to harness. For example, low-code development, through domain-specific language (DSL) abstractions, decouples application development from system-level details, making complete code generation relatively easy to achieve; microservices, through cloud-native infrastructure abstraction, can also to some extent decouple from underlying system details.
Conversely, if a software system struggles to achieve sufficient decoupling, or involves complex interactions at the operating system and hardware levels, then harnessing AI code generation becomes extremely difficult. This also explains why AI performs well in generating independent small applications and microservices, but struggles in scenarios such as complex legacy system transformations and low-level system software development. Harnessability essentially depends on the complexity structure of the system—and this structure cannot be changed by AI tools; it requires solid architectural design and sustained engineering practice to shape.
Furthermore, the harnessability of the software generation process is closely related to the intuitiveness and automability of software verification and validation. If we can automatically generate large numbers of high-quality automated test cases, or easily discover various problems in the software from a user's perspective, then we can provide timely and comprehensive feedback to the generation process. For example, software translation tasks from language A to language B can fully leverage the runtime results of the A-language version as test oracles for the B-language version; compiler software testing can automatically synthesize large numbers of programs for testing; flat business software or personal applications can easily expose various problems through user perspective testing.
Returning to the core question raised in the introduction: Do the development processes, engineering platforms, and quality systems that enterprises have built over the years still matter? The answer is not only that they matter, but that their importance has increased rather than decreased in the AI era—they simply need to evolve, not be abandoned.
First, as we can see from the preceding analysis, the core idea of Harness Engineering—systematically harnessing the code generation process through guidance and sensing—is essentially building an AI-oriented software engineering system. The guidance rules correspond to architectural design principles and coding standards; the sensors correspond to code review and quality gates; the regulatory loops correspond to the feedback mechanisms in CI/CD pipelines. None of these are brand-new creations; they are core components of enterprise software engineering systems.
Second, for complex software development, sound requirements analysis and software design remain prerequisites for the success of Harness Engineering. For example, Ryan Lopopolo, who led the OpenAI team's "million lines of code" experiment, noted in a subsequent interview: "Our repository was probably split into 500 npm packages, which for a 7-person team is severely over-engineered. But if you see each person as 10 to 50 agents, then it makes sense—deep splitting, module isolation, and interface boundaries become very important." This shows that the success of this experiment also depended on fine-grained module decomposition, which enabled AI to complete the development of each module relatively independently. It should be noted that this was a greenfield project starting from scratch, without legacy code or historical baggage. For the vast majority of real enterprise development scenarios, however, most development tasks are based on continuous and incremental development of legacy systems, where maintaining loose coupling and high extensibility design quality is even more critical. Therefore, under the context of AI dramatically increasing code output speed, engineering systems such as quality gates, code review, and architectural governance cannot be weakened—on the contrary, they need to be further strengthened; otherwise, continuous quality degradation in evolving code will increasingly undermine AI's ability to play an effective role.
Finally, the value of enterprise software engineering systems lies not only in regulating the code production process, but also in managing the long-term evolution of software. A core enterprise system may need to run for 10 years or more, during which it will undergo countless requirement changes, architectural adjustments, technology stack upgrades, and team personnel turnover. In this long process, how to maintain architectural consistency, how to manage the accumulation of technical debt, how to ensure the preservation of development knowledge—these are all problems that software engineering systems must continuously address, and they will not automatically disappear with the introduction of AI. In fact, the presence of large volumes of implicit software development knowledge is one of the main reasons AI underperforms in complex software development tasks. Therefore, how to achieve effective accumulation of software development knowledge through enterprise software engineering systems is also an important issue in sustaining AI's role. For example, by making code commits atomic and maintaining good forward tracing (to requirements or issue tickets) and backward tracing (to tests and review results), we can extract high-quality software evolution knowledge and help AI better capture and utilize relevant knowledge.
Since enterprise software engineering systems cannot be abandoned, how should they evolve in the AI era? We believe that long-term infrastructure construction in the following three areas is strategically significant for the intelligent development of enterprise software.
Both Context Engineering and Harness Engineering emphasize a common key point: how well AI performs in code generation largely depends on what it can "see"—the project's architectural design, coding standards, interface definitions, historical design decisions, business rules, and other knowledge are all prerequisites for AI to work effectively. The quality and continuous updatability of these knowledge supplies directly determine the ceiling of AI-assisted development in enterprise scenarios.
The core concept of Code Digital Twin is precisely designed for this purpose—it aims to build a structured software development knowledge system that continuously synchronizes with the codebase. This is not merely a code mirror or a collection of documents, but a multi-dimensional, multi-layered knowledge graph covering architectural structure, module relationships, design decisions and their rationales, mappings between business rules and code, change history and impact analysis, and other dimensions. The knowledge in the Code Digital Twin can not only be extracted automatically from code and its evolution history, development documents, mailing lists, and other sources, but can also be contributed by developers in a "crowdsourced" manner (with appropriate value recognition methods and incentive mechanisms).
From the perspective of Harness Engineering, Code Digital Twin provides a rich contextual foundation for Guides—AI can obtain not only rule instructions on "what should be done," but also the design rationales and historical background of "why it should be done this way." At the same time, it also provides more precise references for Sensors—through the software design and business knowledge reflected in the Code Digital Twin, more targeted inspection rules can be constructed. More importantly, Code Digital Twin is a knowledge asset that can be continuously iterated and grown; it records key decisions and lessons learned during the software evolution process, effectively alleviating the pain point of software development knowledge loss due to personnel turnover.
When building the tool system for AI-assisted development, a core positioning question is: what role should AI play in software development? Our view is that in the context of complex enterprise software development, AI should serve as the "Chief of Staff" rather than the "Commander-in-Chief."
This positioning does not stem from a denial of AI's capabilities, but from a deep understanding of enterprise software complexity. The system complexity of enterprise software means that many critical decisions require comprehensive consideration of multiple dimensions—technical feasibility, business requirements, system constraints, team capacity, and long-term evolution direction. This kind of holistic judgment remains the core strength of human architects and senior engineers for now. As Birgitta Böckeler notes in her article, human developers bring an "implicit harness" to every codebase: we internalize conventions and best practices, we have experienced the cognitive burden of complexity, and we know our names are attached to every commit. AI lacks all of this: it has no sense of social accountability, no inherent aversion to bloated 300-line functions, no intuition of "this is not how we do things here," and no organizational memory.
Accordingly, enterprises should build a human-AI collaborative software R&D platform. AI takes charge of high-speed code generation and routine checks, while humans oversee key architectural decisions, complex requirements analysis, and systematic quality control. The two collaborate through well-designed workflows and toolchains, each playing to their strengths instead of replacing one another.
Specifically: in the requirements analysis phase, AI can assist with structured requirement decomposition and consistency checks, but key business judgments rest with humans; in the architectural design phase, AI can provide design proposals and impact analysis based on the Code Digital Twin, but final architectural decisions are made by human architects; in the coding implementation phase, AI can generate code within clearly defined module boundaries, while human engineers conduct review and integration; in the testing and quality assurance phase, AI can generate and execute test cases, but verification of critical paths still requires human judgment.
The preceding analysis of "Harnessability" reveals a critical long-term investment direction: to unlock greater value from AI in enterprise software development, continuous investment in system architecture decoupling and abstraction is essential—for it directly defines the harnessable scope of AI code generation.
From a practical standpoint, first, enterprises need to continuously optimize the partitioning and interface design of software modules (such as microservices), ensuring clear boundaries and explicit interface contracts between modules, so that AI can independently generate code for each module under precisely defined interface constraints. Second, the implementation of Domain-Driven Design (DDD) should be advanced, reducing coupling between domain modules through the division of Bounded Contexts.
Equally important is building and improving Platform Engineering capabilities. Through a unified technology platform and infrastructure abstraction, upper-layer application development can be decoupled from underlying complex details, thereby expanding the scope where AI can operate effectively. In addition, continuous architectural governance mechanisms need to be established. Through architectural fitness functions, dependency rule checks, module boundary enforcement and other means, enterprises can prevent the system from gradually degenerating into an unharnessable "technical quagmire" during evolution.
The returns of these investments are reflected not only in current code quality and development productivity, but more importantly in the long-term amplifying effect on AI empowerment. A system with clear architecture, decoupled modules, and standardized interfaces is not only friendly to human developers, but also naturally delivers higher harnessability for AI code generation. Conversely, a system with heavy coupling, blurred boundaries, and accumulated technical debt will struggle to produce high-quality generated code no matter how advanced the AI tools are. To borrow Ashby's Law as quoted in Birgitta Böckeler's article: the variety of the regulator must be at least equal to the variety of the system being regulated. Reducing the system's "variety" through decoupling and abstraction is precisely the fundamental way to make harnessing feasible.
From Prompt Engineering to Context Engineering, and then to Harness Engineering, every leap in AI Coding engineering methodology sends the same signal: writing code is becoming increasingly easy, yet designing a sound development environment is growing more difficult and more critical. The core conclusion drawn by the OpenAI team from the "million lines of code" experiment points to the same direction: "Our hardest challenge is no longer writing code, but designing the environment, feedback loops, and control systems."
This statement aligns perfectly with the core mission of enterprise software engineering systems. The development processes, engineering platforms, and quality systems that enterprises have built over the years are, in essence, the "environment, feedback loops, and control systems" constructed for software development. In the AI era, these systems are not historical baggage to be discarded, but strategic assets to be evolved and upgraded.
Looking ahead, our recommendation is to emphasize both "harnessing and awe". On one hand, enterprises should actively embrace AI and fully leverage methodologies such as Harness Engineering to guide the practical implementation of AI-assisted development. On the other hand, they should maintain awe toward system complexity, keep a clear understanding of AI's capability boundaries in enterprise software development, and continuously invest in long-term infrastructure such as Code Digital Twin, human-AI collaboration platforms, and harnessable architecture design. The ability to harness AI determines how fast we can go; the wisdom to revere complexity determines how far we can go. On the long journey of enterprise software development, what we need is not blind acceleration, but a clear sense of direction.
220 Handan Rd., Shanghai(200433) © 2019 FUDAN UNIVERSITY.
Click:
The Last Update Time:..
中文