〈Relying on the Dharma, Not on the Person: Human–AI Collaborative Software Engineering in an AI-Native Practice Hall — A Case Study of Deyuan Guanyin Hall〉

Abstract

Background: AI coding agents allow one person, giving only spoken instructions, to build a medium-to-large system within a few weeks. Yet software engineering has traditionally relied on a team's shared memory and division of labor to ensure that a system has been "built right," and under these conditions neither exists.

Purpose: Taking Deyuan Guanyin Hall as a case, this paper examines, under the conditions of "one person in charge plus one AI builder," what failure modes appear in rapid iteration, and what software-engineering operations and architecture were established to fill the resulting gaps. Deyuan Guanyin Hall is an online Guanyin practice hall designed, developed and operated by AI.

Analytical framework: Philosophy offers the notion of a "created mediator": that AI can generate does not mean it is rooted; to prevent an interface from being taken as the ultimate authority, a mediator must maintain three conditions—being grounded (有所本), locatable (可定位), and correctable (可修正). This paper adopts these three conditions as its research motivation and analytical framework, and does not treat them as propositions to be proven.

Method: An exploratory single-case study, with data drawn from a period of rapid iteration and a governance restructuring that followed it. The rapid-iteration period lasted about four weeks and comprised nearly a thousand commits; the governance restructuring took about a day and a half. The data include version records, change tickets, requirements/design/test specifications, issue logs and expense ledgers. The analysis of the rapid-iteration period is retrospective.

Results:

• The failures of the rapid-iteration period can be grouped into three types, each corresponding to the absence of one of the three conditions:
  • What the system "should look like" existed only in the code (absence of being grounded);
  • Whatever the AI wrote went live, and modifications could not be traced back to decisions or decision-makers (absence of being locatable);
  • Security and cost gaps could only be discovered after the fact (partial absence of being correctable).
• The governance system after the restructuring has four layers: norms, documents, processes, and machine gates.
  • Documents are organized around twelve "pillars," each with three specifications: requirements, design and testing;
  • Modifications of Grade B and above all open a change ticket, are reviewed by models from two different vendors, and are finally accepted by the person in charge;
  • The main branch accepts only commits that pass the automated checks.
• The process of writing the missing documents itself uncovered a large number of existing defects: more than half of the change tickets in the restructuring period arose from "the code being inconsistent with what it should be." The first complete rehearsal began with a single spoken sentence; within about ten minutes the documents and both reviews were completed, and the reviews caught a design error before construction began.

Conclusion: AI has reduced the cost of a prototype to almost zero, so "building it to see" has become cheaper than "writing it clearly." But AI has no reliable memory across conversations, so finalized documents matter even more than they do for a traditional team. This paper proposes a "dual-track" approach: an exploration track for free experimentation, and a delivery track that strictly observes documents, reviews and gates, with "finalization" as the gate between the two tracks. The long-term effects of the governance are left for later research to test with pre-registered indicators.

Keywords: AI-assisted software development, case study, specification-first, change management, traceability, LLM review, dual-track agile

I. Introduction

1.1 Origin: Stance First, Code Afterward

Deyuan Guanyin Hall did not begin with a technology and then look for a use. On the second day of work, a finalized stance had already been written down. This document on the agent mechanism states that the AI in the website is 「只是一根手指，月亮是觀音的教法」 (“only a finger; the moon is Guanyin's teaching”); it 「只說有根據的話，坦白說出不知道的事，有錯就公開改正」 (“speaks only what has a basis, frankly says what it does not know, and corrects mistakes in public”). This stance came before any line of code, and all later requirements flowed from it.

The problem this system sets out to solve is to let people who bring afflictions be properly heard, and, through Guanyin's teaching, to see their own situation clearly. This cannot be done by a chatbot that can “answer everything.” It must be a practice hall (道場): one with scriptures that can be consulted, rituals that can be followed, and clear boundaries that tell visitors what cannot be obtained here. From the beginning, this hall was defined as designed, developed, managed and operated by AI, and it tells every visitor so.

This article calls the human role that gives commands, makes rulings and accepts the work the “person in charge” (負責人), calls the AI that writes the code the “builder” (建置者), and calls the AI within the website that handles operations the “AI Guanyin Volunteer.” The terms of this site are glossed in plain language when they first appear: “大德” (Dade) refers to visitors; “道場” (daochang, practice hall) refers to a place of practice, here meaning the whole website.

1.2 Problem Awareness: When AI Not Only Answers but Builds the Practice Hall

The stance document governs how the AI speaks to visitors. But in this case the AI did something else as well: it wrote the code for the entire practice hall. The person in charge does not write code, and only says in conversation, “please change…”; the builder makes the change on the spot and puts it online on the spot. In about four weeks this way of working grew a complete system, with the following scale:

• six languages and over ninety kinds of pages;
• over two hundred data tables;
• content published automatically every day;
• thirty-three generative agents.

It works, but no document says what it “should” look like.

This situation is not unusual. Since AI coding agents became widespread, “one person plus one AI” has become a common form of development. Yet the usual disciplines of software engineering mostly presuppose a team:

• meetings and shared memory make up for what documents lack;
• reviews by colleagues offset individual blind spots;
• division of labor means the person who implements does not have to accept the work himself.

Under the condition of a single person in charge plus one AI, none of these exist. The AI starts afresh in every conversation. The one who writes the code and the one who checks it are the same model. And the person in charge sees only the screen, not the code.

This article connects this engineering problem to a philosophical one. The argument on the “created mediator” points out that an AI being able to generate does not mean it has roots. A generated mediator, provided it does three things, will not replace what it points to and become “the last word appealed to”:

• keep its dependence plainly visible (having a source);
• be locatable within an institution (locatable);
• remain open to correction (correctable).

The claim of this article is that when AI not only answers visitors within the practice hall but also builds the hall itself, these three conditions must be extended from “promises to visitors” into “engineering specifications for its own code.”

This transfer calls for some care. The relational structure of mediation can be transferred to software engineering; the normative verdict of “idolization” cannot be transferred directly. This article does not say that “the code is made into an idol” (程式被偶像化). In the Buddhist context, the same matter has a more accurate formulation. The Śūraṅgama Sūtra uses pointing at the moon as an analogy: 「若復觀指以為月體，此人豈唯亡失月輪，亦亡其指。」 (“If one again looks at the finger and takes it to be the substance of the moon, such a person loses not only the moon's disc, but also the finger.”) (T19n0945). 「依法不依人」 (“rely on the Dharma, not on persons”) comes from the Mahāparinirvāṇa Sūtra, fascicle 6 (T12n0374), and is the foothold of this article in engineering: the correctness of the system does not depend on anyone's memory or self-discipline, but on written, versioned documents and checkpoints that make no distinction among persons.

1.3 Research Questions

This article is an exploratory case study that first sorts out developments up to the present, with no observation period set. It answers three questions:

1. RQ1 (description): When a single person in charge directs an AI builder through conversation for rapid iteration, what failure modes appear? How do they correspond to the absence of the three conditions?
2. RQ2 (design): To fill these gaps, what software engineering operations and architecture were established? How does it handle the communication of concepts that are “hard to write clearly and must be seen to be known”?
3. RQ3 (cost and limits): What were the results and costs of going through the whole process once? How much “correctability” can “AI reviewing AI” bear within this system?

1.4 Contributions

1. It describes the failure modes of governance when a single person in charge plus an AI builder operate without a team's shared memory, supported by actual records.
2. It gives a full account of a four-layer system already in operation: norms, documents, process, and machine checkpoints, available to other “one person plus one AI” projects.
3. It proposes a “dual track plus finalization gate” approach, explaining how processes, screens, text and feeling move from trial versions into documents.
4. It shows how domain norms become automatically checkable specifications, for example not speaking on another's behalf, scripture unchanged by a single character, and referral in crisis.

Section 2 reviews related research, Section 3 sets out the analytical framework, Section 4 describes the method and the field site, Section 5 presents the results, Sections 6 and 7 offer discussion and limitations, and Section 8 concludes.

II. Related Research

This essay proceeds through five strands of literature, each of which leaves a gap that this essay seeks to fill.

2.1 AI Coding Tools and Productivity

Empirical findings on the effect of AI coding tools on productivity are inconsistent.

• In the controlled experiment of Peng et al. (2023), participants using GitHub Copilot to write a simple web server finished about 56% faster.
• The randomized controlled trial by METR (Becker et al., 2025) found that 16 experienced open-source developers, working on 246 real issues in projects they knew well, actually took 19% more time when AI was permitted. Beforehand they had expected to be 24% faster, and afterward they still believed they had been 20% faster.

These studies measure "how long a known task takes." What they do not measure is this: when an entire system is implemented by AI, who defines the "task" itself, and who judges that it has been "done well." The gap between expectation and actual result in the METR study also reminds this essay that judging by feeling whether something is "faster" or "better" is unreliable. All figures on efficiency in this essay are therefore offered only as description and are not to be taken as effects.

2.2 Spec-Driven Development

Beginning in 2025, the industry started to promote "spec-driven development" as a corrective to the fragmentary practice of "conversation as implementation."

• GitHub's open-source Spec Kit (Delimarsky, 2025) proceeds in three steps: first write "what is wanted and why," without choosing technologies; then write "how to do it"; and finally break the work into small pieces that AI can implement.

The focus of such tools is "how a new feature grows out of a specification." The present case encounters two other problems:

• how a system that has grown up on "conversation as implementation," and has no specification at all, can go back and supply one;
• once the specification has been written, how to ensure that it is not bypassed by the next conversation.

Section 5 of this essay records this dividing line honestly: the baseline documents were reconstructed from the existing code, and only later changes were made with "documents before code."

2.3 Requirements Engineering, Change Management and Traceability

Gotel and Finkelstein (1994) divided the problem of requirements traceability into two halves:

• post-requirements traceability: how requirements become design and code;
• pre-requirements traceability: from whom, why, and in what context a requirement was raised.

They point out that in practice the latter is the truly difficult half. The present case is an extreme instance of pre-requirements traceability: all requirements come from the spoken words of a single person, and the one who remembers those words is an AI that forgets. Every item in this essay's requirements document is marked with its source (which sentence, on which day, by which person in charge decided it), precisely in order to address pre-requirements traceability.

2.4 Waterfall, Spiral and Dual-Track Agile

"Documents before code" is easily read as a return to the waterfall. Yet three things in this strand of literature are often overlooked:

• Royce (1970) is often cited as the source of the waterfall, but his original text in fact points out that one-directional, phase-by-phase development is "risky and invites failure," and advocates building a pilot version early on, that is, "doing it twice."
• Boehm's (1988) spiral model places risk at the center: each cycle first builds a prototype of the highest-risk part, and only then decides the next step.
• In the dual-track agile described by Sy (2007), user-experience design and development advance in alternation on two parallel tracks, with the design track one cycle ahead of the development track.

All three deal with whatever cannot be stated clearly on paper by "making it and looking." All three also assume that a team is doing the work and doing the remembering. The "dual track plus finalization gate" of Section 5 of this essay connects to this strand of literature, except that it entrusts the place of the team's memory to versioned documents.

2.5 Using Language Models as Judges

The review in this case is carried out by language models, so it must face the known biases of "model as judge."

• Zheng et al. (2023) found that with GPT-4 as judge, agreement with human preferences can reach eighty percent. But they also recorded three biases: position bias, a preference for longer answers, and a preference for answers the model itself generated.
• Panickssery, Bowman and Feng (2024) further confirmed that models can recognize their own generations with better-than-chance accuracy, and that the stronger the ability to "recognize oneself," the stronger the "preference for oneself."

This is the reason the present case requires "two models from different vendors" and requires that "the reviewer not be the conversation that wrote the code." Yet it also shows that, even when the models come from different vendors, they may still share similar blind spots. This essay therefore calls this kind of review "heterogeneous-model-assisted review" and not "independent review." Final accountability remains with people (Section 6).

2.6 Summary

Each of the five strands handles one part of the problem, but all presuppose a condition that this case lacks:

• there is a team, or at least one person who can read code;
• or the system had its specification written first from the very beginning.

The combination of "one person in charge who does not write code, plus one AI that has written all the code, setting rules only after the system has already grown" has, to our knowledge, not yet been reported as a case.

III. Analytical Framework: Three Criteria

This section sets up one yardstick, which the failure modes and institutional design of Section 5 will all be measured against. The yardstick derives from the argument concerning the "created intermediary." This paper treats it as an analytical classification, not as a proposition to be proved here.

3.1 The Created Intermediary and the Three Conditions of Idolization

The argument concerning the created intermediary has three main points.

• AI is a created intermediary: it can generate, but generating is not the same as being rooted.
• Functionally it can surpass the people who made it. But functional surpassing does not mean that it may legitimately become "the last word appealed to."
• The idolization of an interface has three conditions, from shallow to deep:
  1. Dependence is substitutive: the interface occupies the place of scripture, of office, and of community;
  2. Dependence is functionally final: the interface becomes the last word;
  3. Correction loses practical force: neither an identifiable source nor an accountable person can interrupt it any longer.

When only the first condition holds, it is "dependence"; when the first two hold, it is "misplaced obedience"; only when all three hold is it "idolization." The corresponding converse is the three requirements that an intermediary places on itself:

• Having a source (有所本): evident dependence;
• Being locatable (可定位): locatable institutionally;
• Being correctable (可修正): remaining open to correction.

3.2 From a Commitment to Visitors to a Specification for Code

This site's position paper is itself a practice of the three requirements, directed toward visitors:

• The AI's answers must return to the sources in scripture (having a source);
• The AI declares itself an AI and does not claim to be a Bodhisattva (being locatable);
• Errors are corrected publicly (being correctable).

This paper extends the same set of requirements to the builder. Table 3-1 sets out what the three conditions look like when absent from the building process, what they become when written in engineering terms, and how they are expressed in this site's own vocabulary.

Table 3-1　The Three Conditions of the Created Intermediary Compared with Engineering Specifications

"Realization cannot be done on another's behalf" is taken from this site's threefold division of teaching, practice, and realization (教・行・證). Teaching lies in the scriptures, practice lies in the visitor's own hands, and realization belongs only to the visitor. Corresponding to engineering, requirements are teaching, construction is practice, and acceptance is realization. The builder may write code on another's behalf, but cannot say in place of the person in charge, "This is what I want." Pavāraṇā (自恣) is the rite at the end of the monastic rains retreat in which one invites others to point out one's own faults; this paper uses it to mean "actively submitting one's own work to others for review."

3.3 Correspondences and Non-correspondences in the Relational Structure

In transferring this yardstick, one must first state clearly what corresponds and what does not. The intermediary relation has three elements:

• The intermediary: the AI builder;
• The authority to which it points: the requirements settled by the person in charge, and the position paper behind them;
• The party that depends on it: the person in charge, and the visitors who ultimately use the system.

There are two points of non-correspondence:

• In a religious context, the authority (scripture, tradition) is not set by the dependent party itself. In this case, the authority for the requirements comes from the person in charge, that is, from the dependent party itself.
• "Idolization" is a normative verdict, not a description. This paper does not pass this verdict on the code, but only borrows the graded structure of the three conditions.

Accordingly, when this paper speaks of "absence," it means "there is no corresponding mechanism in the engineering." It does not mean that any party has taken the code to be the ultimate authority.

3.4 Observable Indicators of the Criteria

For the criteria to be usable, they must point to observable matters. The indicators must be independent of the measures themselves: "writing 36 documents" is a measure, not evidence of "having a source." The retrospective analysis of this paper uses the following observable matters to determine absence.

Table 3-2　Retrospective Indicators of the Three Criteria

Whether things improve after governance requires a pre-registered observation period and falsification conditions. This paper does not undertake this, and only lists the design of follow-up research in Sections 7 and 8.

IV. Research Method and Setting

This paper is an exploratory single-case study, designed and reported following the software-engineering case-study guidelines of Runeson and Höst (2009). The case is a system in active operation, and the unit of analysis is "a single modification to the system" together with the records surrounding it.

4.1 The Setting

Deyuan Guanyin Hall is an online Guanyin practice hall. It is open to the public, charges no fee, and tells every visitor that it is operated by AI. The website is organized from the outside inward into four stations, corresponding to teaching (教) and practice (行):

Three kinds of AI roles exist within the website:

• The AI Guanyin Volunteer: receives visitors, writes the daily content, hosts the ceremonies, and conducts daily inspection and review;
• The thirty-three generative agents: the research subjects who "practice" within the hall;
• Agents that act in the hall on behalf of visitors.

The boundaries of each role are written in a position document:

• They do not claim to be a Bodhisattva;
• They do not speak of protection or efficacy;
• They do not alter a single character of the scriptures;
• When crisis wording is encountered, they do not generate a reply, but give a fixed caring message and a helpline directly.

The scale of the system is recorded in orders of magnitude:

• More than ninety kinds of pages, in six languages;
• Dozens of server interfaces and over a hundred program modules;
• About sixty thousand lines of code and about forty thousand lines of database definitions;
• More than two hundred data tables.

Technically there are only three dependencies: version control, cloud hosting, and a managed database. Each function is accomplished through the interface of an external language model.

4.2 Participants and Roles

The case involves only one human participant in development.

The principal does not write code; he is the provider of domain knowledge and at the same time serves as product manager and acceptor. This condition is critical: the correctness of the system cannot be guaranteed by his "reading the code."

4.3 Division of the Period

This paper divides the development into three phases, with the "governance restructuring" as the dividing line:

1. Rapid iteration phase (about four weeks): the principal dictated and the builder implemented on the spot; there was only a single chronologically stacked dictation record, with no requirements or design documents. This paper conducts a retrospective analysis of this phase.
2. Governance restructuring (about a day and a half): after the principal required "version management, and documents for analysis, design, and acceptance," norms, baseline documents, and machine gates were established.
3. The first complete rehearsal: the first change after the restructuring that was raised in spoken language and went through all eight steps.

The timeline of how the criteria took shape is stated as it was: the position document was finalized on the second day of the rapid iteration phase, but it only constrained the AI's conduct toward visitors; its extension into an engineering specification came during the governance restructuring. This paper's rereading of the rapid iteration phase through the three criteria is a retrospective analysis, not the design of the time.

4.4 Data Sources

• Version records: the complete commit history of the main line, including dates, messages, and modified files.
• Dictation record: the only design record of the rapid iteration phase. It is a project description file several hundred thousand characters long, recording each of the principal's decisions in chronological order.
• Governance documents:
  • The development charter and operating principles;
  • The requirements, design, and test specifications of the twelve pillars;
  • Change requests and their review comments.
• Operational records:
  • Intake in the issue center;
  • Incident reports;
  • Expenditure accounts (aggregated at the account level).

All of the data are by-products of the development and operation process, and were not collected separately for this study.

4.5 Analysis Procedure

RQ1 uses the indicators of Table 3-2 as the coding framework, assigning the incidents, fix-type commits, and problems discovered during the restructuring in the rapid iteration phase to the three criteria. One event may be assigned to more than one criterion. RQ2 is primarily descriptive, setting out each layer of the system, what it solves, and which criterion it corresponds to. RQ3 uses the change request of the first rehearsal as data, recording the output, time, and review comments of each step.

The coding was done by the builder and rechecked by the principal; there is as yet no external coder. This is one of the main limitations of this paper; see Section 7.

4.6 Security Disclosure and Personal Data

The principle of disclosure in this paper is: the process may be made public, but only the "category, cause, and lesson" are disclosed.

• No names of interface paths, functions, data tables, fields, keys, or headers are written;
• No threshold figures, schedule times, or implementation details are written;
• No items not yet fully resolved are mentioned.

There is only one criterion: after reading a passage, could a technically knowledgeable person do something directly to this website? If so, remove it or abstract it.

This paper uses no visitor content. The two figures in the text are schematic diagrams; they contain no data of real visitors and no administrative interface.

4.7 Statement on the Scope of AI Participation

• The builder wrote all of the system's code, as well as the first drafts of the governance documents.
• This paper was drafted by Anthropic's Claude; Claude is what this paper calls the builder. The principal reviewed and approved it.
• The outline of this paper was reviewed by two models; before inclusion in Deyuan Academy, the full text was checked once more by another independent AI session, from the standpoint of an attacker, for security disclosure, and for factual accuracy and terminology. The opinions adopted are reflected in the positioning and terminology of this paper, for example "heterogeneous-model-assisted review," the temporal ordering of the criteria, and the manner of the cost comparison.

V. Results

5.1 RQ1: Failure Modes of the Rapid-Iteration Period

The speed of the rapid-iteration period came from "the person in charge speaks, and the builder changes it on the spot," with no documents in between. The evolution of this period falls roughly into four stages:

1. First, a knowledge database and question answering were built;
2. Then the three halls of the practice hall, the light lamp, and online ceremonies were built;
3. Next came daily content, six languages, the classroom, and generative agents;
4. Finally came autonomous improvement, the problem center, and outward-facing posts.

New features went live almost every day. This section organizes the observable signs left by this period according to the three criteria.

Table 5-1　Failure modes of the rapid-iteration period

Judging by commit messages containing words such as "fix," "repair," "error," and "incident," corrections make up about 5–6% of all commits, the proportion depending on the words used. This undercounts corrections that were not stated explicitly, so it serves only as a lower bound.

Categories and common causes of the security defects. The security defects found in the restructuring period fall into four broad categories: access-control defects, incomplete decommissioning of features, gaps in cost control, and premature exposure of content. They share three common causes:

1. Closing the screen but not the entrance. When a feature was put away, only the front-end button was removed, while the back-end entrance and the scheduled job remained. The rapid-iteration period often had features that were "built and then put away," so this pattern repeated again and again. These entrances have been closed one by one, and automatic checks now prevent their return.
2. The assumption that "only I will call it." Routes the builder made for personal use were given no gate. These routes were later given identity checks.
3. No one had looked it over from the attacker's point of view. Without documents there was no "should" to compare against.

Only after the restructuring, when review became "testing against the documents," were these defects discovered. According to the existing records, there is no evidence that they were ever exploited; but before the restructuring there were also not enough records to rule this out.

Answer to RQ1. In terms of the grading in Section 3:

• The absence of the first criterion (grounded) and the second (locatable) in the rapid-iteration period is established.
• The third criterion (correctable) is partly established: the person in charge could still call a halt within the conversation, but only after the fact, and only for screens that could be seen.

The three kinds of failure also compound one another: with no "should" document (grounded absent), review has nothing to compare against; with review absent, defects can only wait to be encountered after launch (correctable absent).

5.2 RQ2: The Four-Layer System

The system actually operating after the restructuring has four layers, from top to bottom:

1. Norms: only the person in charge may change them;
2. Documents: the formal definition of the system;
3. Process: every modification must follow it;
4. Machine gates: independent of anyone's self-discipline.

The relation among the four layers is:

• Norms determine what the documents must say;
• Documents determine what a modification "should look like";
• Process guarantees that documents are changed before code;
• Machine gates guarantee that even if someone in the first three layers forgot or skipped a step, the code still cannot enter the official release.

The upper three layers depend on humans and the AI following them; the bottom layer depends on neither: even if someone forgot to open a ticket or skipped review, the code still cannot enter the main line.

I. The Norm Layer

The norm layer has four documents.

Article 1 of the development charter reads: "Documents precede code, and test standards precede construction. The remaining articles of this charter all exist to uphold this one." Article 4 reads: "Norms do not rely on memory." The person in charge need not remember the process: the builder intercepts proactively, and the machine gates enforce it.

II. The Document Layer

The pillar map divides the whole site into three tiers and is the basis for the impact analysis of every change ticket.

The name of the "real" layer is taken from this site's principle of "expedient and real" (權與實): interface, language, and entrances may vary freely (expedient), while scripture, the AI's boundaries, and crisis referral are not moved by a single character (real). This is how domain norms become engineering specifications: they are placed in the foundation, so that changing even one character requires the heaviest process. They are also written as automatic checks, for example:

• Scripture quotations are verified character by character by program;
• Prohibited words are scanned by program;
• Crisis responses are fixed text, not generated by a model.

The three-document set is the formal definition of the system: each pillar has its own requirements specification (what to do), design specification (how to do it), and test specification (what counts as done correctly). Twelve pillars yield thirty-six documents, plus the pillar map and the charter. Each requirement in the requirements specification takes three to five lines and includes its purpose, rules, and source; the test specification writes acceptance cases for each requirement, corresponding to automatic tests or manual acceptance. Code, documents, tests, and database schema are kept in the same repository and frozen together under the same version.

How this body of documents came into being must be stated truthfully: they are a baseline "inferred backward from the existing code." The method was:

1. First draw the pillar map;
2. Then compare against the code pillar by pillar and write out "what it does now";
3. Problems found during the comparison were not fixed in passing while writing the documents, but were all handled by opening change tickets.

Only modifications made after the baseline are "documents before code."

III. The Process Layer

The person in charge speaks only in everyday language. The builder first classifies what he says, and then decides how to handle it:

As a principle, communication on a modification instruction takes four exchanges:

1. Acknowledgment report: the builder restates the request, and the person in charge corrects any misunderstanding;
2. Impact report and change ticket: the person in charge says "approved," or points out what needs to be changed;
3. Review results: a ruling is needed only where there is disagreement;
4. Completion report: the person in charge says "go live."

When a single sentence contains several matters, it is split into several tickets. New ideas that arise midway through the process are recorded as the next ticket and are not mixed into the ticket in progress.

Changes are divided into five grades, and the grade determines how heavy a process must be followed:

Review is divided according to what is being reviewed. The requirements and test specifications, which record "what it does now," are reviewed by a separate AI session that can open the code and check against it, because errors of this kind can be caught only by comparison with the code. Change tickets of grades B, C, and D are each reviewed by two models from different vendors. The rules are as follows:

• A ticket is finalized only when both agree; disagreements are ruled on by the person in charge;
• Review asks only "are there contradictions, missed failure cases, is the scope of impact complete";
• The reviewers are not asked to suggest new features.

This restriction is meant to prevent review from becoming another source of design.

IV. Machine Gates and the Three Layers of Insurance

Testing has four layers:

Two rules may not be bypassed:

• For any error that is fixed, a test that can reproduce it must be added first, so the error does not return;
• During construction, tests may not be loosened or deleted merely to make the code pass. Changes to tests must also be finalized in the change ticket.

The enforcement of the norms does not depend on anyone's self-discipline. It is guaranteed by three layers of insurance:

The machine gates were established in three steps, all of which took effect within the restructuring period:

1. Every push automatically runs the pre-launch checks;
2. The main line accepts only commits that pass the checks, administrators included, and force-pushing is not allowed;
3. The database schema can be changed only through schema files in the repository, and is periodically rebuilt from scratch and compared with the production environment.

The operating period has two further gates:

• There is only one ledger of spending, and every path that spends money registers a daily cap;
• Anomalies are automatically sent to the problem center and traced by the person on duty.

The specific thresholds and rhythm are not made public.

V. The Interface between the Operations Layer and the Development Layer

The AI Guanyin Volunteer within the website is responsible for operations but cannot change the code directly. Between it and the development layer there are only three channels:

• Improvement suggestions: proposed by the volunteer; after the person in charge approves, anything involving code is always converted into a change ticket and follows the same process.
• Settings within the whitelist (grade E): may be adjusted automatically only within registered items and their upper and lower limits, with a record left each time.
• Anomaly reports: problems found by routine patrols and the problem center; those that require code changes are converted into grade B change tickets.

This boundary lets "locatable" hold between the two kinds of AI as well: the operating AI cannot alter the program, and the building AI does not substitute for operations.

VI. Change Orders in the Restructuring Period

Up to now the restructuring period has opened twenty-eight change orders, classified by nature as follows:

"Corrections after comparison against the pillars" account for more than half. This is precisely the gap left by the rapid-iteration period's lack of a "what it should be"; the very process of writing the documents brought these gaps to light.

The answer to RQ2 is this: each of the four layers of the system corresponds to one criterion, and each layer has a way of being carried out that does "not rely on memory."

• The document layer and test-first practice supply "having a source";
• Roles, the classification of utterances, and change orders supply "locatability";
• Two-house review, the gate that makes no distinction among persons, the spending cap, and the issue center move "correctability" from after the event to before it.

5.3 RQ2: Concept Communication and the Dual Track

"Documents before program" raises an inevitable question. Some things cannot be written clearly and must be seen before one can tell whether they are right—for example, a flow, a screen, the tone of a sentence. How do these things enter the documents? The approach in this case is not waterfall but a dual track:

• The exploration track discusses "what is wanted." The person in charge states an idea in a sentence or a phone screenshot, and the builder directly produces a visible prototype (a design draft or a preview version). The person in charge looks at it on a real phone and computer; if it is not right, another version is made. This track can be discarded and has no gates.
• The delivery track guarantees "done correctly." At the moment the person in charge "finalizes" (定案), the result is written into the requirements book and the design book, and passes through acceptance criteria, two-house review, construction, testing, and acceptance, with no step skipped.

The two tracks make different demands on the criteria. The exploration track needs only "locatability": knowing who made it, which version, and why. It exists precisely to be corrected. The delivery track requires all three.

Looking back at 5.1, the problem of the rapid-iteration period was not that it was too fast, nor that there was too much exploration. The problem was the absence of a finalization gate: the products of the exploration track went live directly as products of the delivery track. The prototype became the official version, and no one wrote down "what was finalized."

Step 4 writes the acceptance criteria before construction; when a test fails, one returns to step 6 to change the program, not back to relax the criteria. Step 8 can be done only by the person in charge.

Table 5-2 How Various Development Models Handle "Concept Communication"

What a finalization is written into varies with the kind of concept.

Table 5-3 How Each Kind of Concept Enters the Documents from the Exploration Track

The last row of Table 5-2 is this paper's main observation in software engineering. It has two sides:

• The AI lowers the cost of a prototype to nearly zero, so "make it and look" is cheaper than "write it clearly";
• But the AI also has no reliable memory across conversations, so the documents after finalization matter more than in a traditional team.

Agile development treats "the team's shared memory" as a substitute for documents. One person in charge plus an AI that starts over each time has no such shared memory to rely on. This is also the most practical engineering reason for "relying on the Dharma, not on persons" (依法不依人)—relying on no party's memory.

5.4 RQ3: The First Complete Drill and Its Costs

The cost of the restructuring itself. From the person in charge's request for restructuring to the regulations, thirty-six baseline documents, and machine gates being in place and twenty-eight change orders being opened, about a day and a half was used. During this time the person in charge did almost only two things: setting principles, and adjudicating when the two reviewing houses disagreed. His replies eventually were mostly just "good," because at each stop the documents had already set out clearly what was to be decided. The cost of the external models' review was only a few US dollars.

The first complete drill. On the night the restructuring was completed, the person in charge raised, in one sentence: "On the phone, 觀易 is covered by a button." That sentence went through all eight steps.

Table 5-4 The First Complete Drill

From a single sentence to the completion of documents and review took twelve minutes. The review cost under one dollar. Measuring according to the test book also found another occlusion outside the scope of this order; it was opened as a separate change order rather than relaxing the criteria of this one.

The crux of the drill lay not in speed but in step 5. Before any work began, both reviewing houses caught the same design error: the hall screen scales proportionally with screen size, so margins hard-coded according to the original design would be multiplied a second time. Had the program been written first, this error would not have been seen until the person in charge used a tablet or a large screen. In the pre-restructuring way of working, it would very likely have become the next "fix-type commit."

The tug-of-war between the two houses. The two reviewing houses complement each other, and they also pull against each other. The change order for the budget system was reviewed in four rounds: one house agreed or agreed after revision from the second round on, while the other still disagreed in the fourth round. The last two points were adjudicated by the person in charge and listed under the change order's "known limitations." This is an outlet the charter designed, not a malfunction: the end point of disagreement is a person, not a third model.

The answer to RQ3. In this system, "AI reviewing AI" bears the first half of correctability: it moves the discovery of defects from after going live to before construction, and at very low cost. This kind of review has two limitations:

• It is effective only when documents exist to compare against. The security defects of the restructuring period were all found only when the reviewers "tested actually by following the documents"; in the rapid-iteration period, even with review, there was no "what it should be" to compare against. The effectiveness of review therefore depends on "having a source" being established first. For this reason Charter version 1.1 also entrusts the "documents recording the current state" to reviewers who can open the program and check.
• Reviewers may share blind spots. That both houses caught the same error is mutual corroboration; but errors that both houses missed cannot be seen in the data of this case. Without a comparison against review by human experts, recall cannot be computed.

Therefore the second half of correctability (accountability and the final judgment) must remain with human beings.

5.5 Comparison across the Five Stages of the Lifecycle

Table 5-5 The Lifecycle before and after Restructuring

VI. Discussion

6.1 When there is no team memory, documents are the memory

In traditional software engineering, documents are often regarded as a backup of the team's memory. Even if nothing is written down, someone still remembers, so agile development can "value working software over comprehensive documentation." The conditions of this case reverse that relation:

• The builder starts afresh in every conversation. Once the context changes, all it can rely on is the documents.
• The person in charge remembers what he or she wants, but does not remember which sentence, said three weeks ago, was written into which file.

Under these conditions, documents are not a backup of memory; they are the memory itself. The rapid-iteration phase did in fact have a "memory" as well: that dictation file of several hundred thousand characters. But it was stacked by time, not organized by system structure; new decisions were added at the end, and old decisions were never marked as void. In every conversation one had to reread it and guess again which sentences were still valid. What the pillar map and the three documents do is to turn a memory "by time" into a memory "by structure": every question has a fixed place where it can be looked up, and only one version is current.

6.2 The limits of using AI to review AI

The review design of this case made three choices, each corresponding to one of the biases in Section 2.5:

• The reviewer is not the conversation that wrote the code, to reduce "preference for its own generations";
• At least one reviewer comes from a different vendor, to reduce shared training bias;
• The review asks only about "contradictions, omitted failures, and scope of impact," not "whether it is well written," to reduce the preference for long and fluent text.

But all three choices only reduce bias; none eliminates it. This paper therefore calls the arrangement "heterogeneous-model-assisted review": it is a low-cost mechanism for discovering defects, not a mechanism of accountability.

From the standpoint of created mediation, this distinction is necessary. If it counts as "correct" whenever two models agree, then "the utterance finally appealed to" has merely moved from one model to two. The charter places the end point of disagreement with the person in charge and fixes acceptance as something only the person in charge can perform, precisely so that the review itself does not become a new final authority.

6.3 Cost: a sensitivity analysis

Readers will certainly ask: if the same system were built by a human team, how much would it cost? This question has no single answer, for three reasons:

• The quality of the two is not equivalent. A human team has dedicated security and testing staff, whereas this case suffered a security gap during the rapid-iteration phase.
• How the person in charge's time is priced determines the order of magnitude of the result.
• Some parts have no human-built counterpart; for example, the "practice" of the generative agents is itself AI research.

This paper therefore does not make a single comparison, but gives only a sensitivity analysis. The figures are divided into "actual" and "estimated": "actual" comes from the model vendors' real invoices; "estimated" states its method of calculation, converting at about NT$32 per US$1. The site's own spending ledger records only about one quarter of the actual invoices; the rest comes from calls that were never booked — which is itself part of the "spending without a ceiling" described in 5.1.

Table 6-1　Sensitivity analysis of build cost (NT$)

The difference in time is not in the table: this case took about one month, whereas the estimate for a human team is more than a year. Nor should the figures in the table be read as "how many times cheaper"; they can support only two conclusions.

First, however the person in charge is priced (A to C), the monetary cost of the AI build is far lower than that of a human team: when the person in charge's time is not priced, the difference is nearly three orders of magnitude, and even when all three of the person in charge's roles are priced as full-time, the difference is still dozens of times or more. The gap is so large that, even after allowing for the inequality of quality, the direction would not reverse. But this gap is not a free gift; it moves the risk to another place: the risks borne in a human team by dedicated security and testing staff are borne in this case by documents, review and gates. What Section 5 describes is precisely what happens to these risks when no one is bearing them.

Second, the main cost of an AI build is not the one that was expected. The largest single source of spending in this case was not the system's functions themselves, but the "absence of a ceiling." Had a budget system been in place from the start of the rapid-iteration phase, a counterfactual estimate suggests that most of the AI spending could have been saved. But this estimate must carry a discount: the overspending also bought the knowledge of "knowing only by having tried." A more accurate statement is that a budget system does not prevent experiments; it only lets experiments take place within a known sum.

After the restructuring, the additional cost of each modification is a dozen or so minutes of documentation and review, plus a review fee of less than one US dollar (Section 5.4). This is the observation of a single rehearsal, not an average.

6.4 Domain norms become checkable specifications

The norms of a religious setting are usually regarded as "soft" — relying on human judgment and hard to write as rules. The experience of this case is that some of them can be made very "hard":

The parts that cannot be made hard — for example, "whether the tone of this sentence is gentle" — take the path of "the builder proposes, the person in charge finalizes character by character" (Table 5-3). This boundary is itself part of the design: what can be made hard is given to the machine, what cannot is given to the human, and the model is not allowed to judge what lies between the two.

6.5 Generalizability

This case has a prerequisite that is not easy to replicate: the person in charge serves alone as product manager, domain expert and acceptance reviewer. In other settings these three roles may belong to different people. The following practices have nothing to do with the religious setting and can be taken away directly:

• The structure of the pillar map and the three documents;
• The classification of utterances and the five levels of change;
• The two rules "tests must not be relaxed" and "when a fix goes wrong, supplement the tests first";
• Mainline protection and comparison on database rebuilds;
• One ledger for spending.

For a new project, the implication of this case is one of sequence. Machine gates should be in place when the project is still empty; in this case they were added only after the system had already grown. Fields where the cost of error is higher — for example, those involving personal data or medical advice, such as health services — need this sequence even more.

If several people are to run it together, the greatest risk is that "two people each say their own thing about the same place." Possible measures are:

• Assign people by pillar;
• Make the change request the only entry point;
• Open only one major change per pillar at a time;
• Keep the gates identical for everyone.

This point has not yet been implemented in this case.

VII. Threats to Validity and Limitations

This section reports on the four types of validity set out by Runeson and Höst (2009) in turn, and ends by stating the researchers' position.

Construct validity. The three criteria come from philosophical argument, and converting them into engineering indicators carries two risks.

• An indicator may measure only the measure itself. For example, "a change ticket exists" does not equal "traceable". This paper therefore describes the rapid-iteration period only through signs of absence (Table 3-2), and does not use the existence of a measure to prove improvement.
• "Fix-type commits" are identified by the wording of commit messages, which may undercount and may also miscount.

Internal validity. This paper makes no causal claim about the difference between the periods before and after the restructuring, for three reasons:

• The restructuring coincided with the maturing of the system. The smaller number of later modifications may simply be because the features had already been completed;
• The operating principle "do less at this stage" itself reduces the volume of change;
• Only one complete drill was carried out after the restructuring, which is not enough to infer average cost and effect.

External validity. This is a single case, with three special conditions:

• The setting is a religious practice hall, and it charges no fees;
• The person in charge holds three roles at once;
• The builder is a particular model at a particular point in time.

The capabilities and memory mechanisms of models change quickly. If the premise that "there is no reliable memory across conversations" changes, the role of documents may change with it. The claim of this paper is an analytic generalization: it extends to forms in which "a shared team memory is lacking and the implementer and the reviewer may share the same origin", and it is not a statistical generalization.

Reliability. The coding was done by the builder and rechecked by the person in charge; there were no external coders and no consistency indicator. Expenditure during the rapid-iteration period follows the actual bills of the model vendors; the website's own accounts record only about a quarter of it and cannot be matched item by item to features. The builder's own usage fees fall under a subscription plan, with no per-transaction bills.

Chronological order of the baseline documents. The thirty-six baseline documents were reconstructed from the existing code at the time of the restructuring; they are not products of "documents before code". The "documents before code" of this paper applies only to modifications made after the restructuring.

The researchers' position. The researcher is also a participant:

• The first draft of this paper was written by the builder, and the builder is itself one of the roles under study;
• The person in charge is both the designer of the system and the one who approves its results.

This may produce a bias of "writing one's own system up too favorably"; and the builder writing about itself is exactly the case of "preference for its own generations" in Section 2.5. This paper adopted two mitigations:

• The outline was reviewed by two models, and the full text was reviewed from an attacker's perspective by another independent AI session;
• Failure modes and defects are in every case based on events in the records, not on recollection.

None of these mitigations can replace an external researcher.

Design for follow-up research. The limitations above can be addressed by follow-up research; the suggested approach is as follows:

1. Pre-register an observation period: at least sixty days and at least twenty change tickets, covering all levels; the day and a half of the restructuring is treated as a transition period and counted in neither period.
2. Compare the two periods with indicators independent of the measures, for example:
   • the number of post-launch problems of the type "what was done differs from what was wanted";
   • the proportion of post-launch defects that can be traced to a decision;
   • the change failure rate, the number of rollbacks, and the number of recurrences within seven days.
3. State the falsification condition in advance: the hypothesis counts as supported only if the indicators of at least two of the three criteria are better in the observation period than in the retrospective period.
4. Sample change tickets and have human experts review them independently, then compare against the two AI reviews and the actual post-launch defects, and calculate the recall rate.
5. Invite an external researcher to code a sample independently and report the consistency.

VIII. Conclusion

A person in charge who does not write code, together with an AI builder, can build a complete system in about a month. But without a written "ought," that system cannot be accepted as correct, cannot be predicted, and cannot be kept in hand.

Answers to the research questions:

• RQ1: The failures of the rapid-iteration period fall into three categories. First, "what it ought to look like" exists only inside the code. Second, changes cannot be traced to decisions, and state cannot be reconstructed. Third, gaps in security and cost can be found only after the fact. These correspond respectively to the absence of grounding, of locatability, and of correctability. The three compound one another: without documents, review has nothing to check against.
• RQ2: What fills the gaps is a four-layer institution: norms, documents, procedures, and machine gates. No layer depends on the memory of either party. A concept that cannot yet be stated clearly follows a dual track: free trials on the exploration track, and only after it is settled is it written into the documents and moved onto the delivery track.
• RQ3: In the first full rehearsal, from a single sentence to completed documents and two reviews took under a quarter of an hour, and the review caught a design error before work began. "Using AI to review AI" can carry the first half of correctability: it brings the discovery of defects forward at very low cost, but only on the condition that there are documents to check against. Accountability and final judgment must remain with people.

Recommendations for practice, addressed to those who develop with "one person plus one AI":

1. Before the first line of code, put the machine gates in place: protection of the main branch, automated checks, a rebuildable database, and spending limits. None of these requires someone who understands code to guard them.
2. Keep "build it and look" cheap, but at the moment of "settling" write the result into the documents. A prototype is not the official version.
3. Before fixing any error, add a test first; do not loosen the tests merely to make the code pass.
4. The reviewer should not be the same conversation that wrote the code; ideally one reviewer comes from a different vendor. Set the end point of disagreement at a person, not at a third model.
5. When a feature is withdrawn, withdraw the front end, back end, and scheduled jobs together.

"Rely on the Dharma, not on the person" (依法不依人) is not a religious slogan in this paper but an engineering judgment. When the implementer forgets every time and the person in charge cannot see the code, the correctness of the system can rest only on what is written down, versioned, and identical for everyone. The AI is the finger, not the moon. This holds for visitors, and it holds equally for the code the AI itself writes.

References

• Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR. arXiv:2507.09089. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61–72.
• Delimarsky, D. (2025, September 15). Diving into spec-driven development with GitHub Spec Kit. Microsoft for Developers. https://developer.microsoft.com/blog/spec-driven-development-spec-kit/
• Gotel, O., & Finkelstein, A. (1994). An analysis of the requirements traceability problem. In Proceedings of the First International Conference on Requirements Engineering (pp. 94–101). IEEE Computer Society Press.
• Panickssery, A., Bowman, S. R., & Feng, S. (2024). LLM evaluators recognize and favor their own generations. In Advances in Neural Information Processing Systems 37. arXiv:2404.13076.
• Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv:2302.06590.
• Royce, W. W. (1970). Managing the development of large software systems. In Proceedings of IEEE WESCON (pp. 1–9).
• Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering, 14(2), 131–164.
• Sy, D. (2007). Adapting usability investigations for agile user-centered design. Journal of Usability Studies, 2(3), 112–132.
• Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-judge with MT-Bench and Chatbot Arena. In Advances in Neural Information Processing Systems 36, Datasets and Benchmarks Track. arXiv:2306.05685.
• AI as a Created Mediator: Generativity, Grounding, and the Idolatry of the Interface (unpublished manuscript).
• Translated by Pramiti (般剌蜜帝). 《大佛頂如來密因修證了義諸菩薩萬行首楞嚴經》 (Śūraṅgama Sūtra), fascicle 2. CBETA T19n0945, p. 111a09–a11.
• Translated by Dharmakṣema (曇無讖). 《大般涅槃經》 (Mahāparinirvāṇa Sūtra), fascicle 6. CBETA T12n0374, p. 401b28–b29.

Texts on this site: Deyuan Academy DYSY-0002〈照見〉, DYSY-0004〈從生成式代理人到數位同修〉, DYSY-0006〈德原觀音堂設計理念與運作實務〉, DYSY-0008〈由智生悲〉, DYSY-0011〈中介者的自我要求〉; the site map on the "AI Practice Hall" (AI 道場) page.