12 도구와 관행의 재발견 → translation below

13 Rediscovering Tools and Practices

Version control, continuous integration, documentation, open source collaboration. Tools and practices built for human collaboration are taking on new roles in loops that agents have now joined. This chapter covers that shift in roles.

13.1 Version Control: From History to Safety Net

Drafting Status

Pre-draft. Check ownership and status in TOPICS.md at the repository root.

Brief. This section contrasts the historical background of Git as a collaboration tool with the way its use in agentic coding has shifted toward reverting experiments at the commit level. Write only what is confirmed about the year Git emerged or its founding narrative, and defer the rest to research directions. Structure the section in three parts. First, confirm, only to the extent verifiable, the history of version control systems and in particular the conventional narrative that the shift to a distributed model was meant to solve collaboration problems. Next, gather examples of recent practices in agentic workflows where commits, branches, and worktrees are used as a safety net. Finally, argue which properties of Git’s design remain valid, and which have become excessive, now that its use has shifted from a tool that coordinates the parallel work of multiple people to a tool with which one person reverts an agent’s experiments.

Seed questions

What facts can be stated definitively about the historical background of Git’s creation, and which parts, such as the exact year or detailed narrative, need verification? (Check primary sources; do not assert years without confirmation.)
How much does the problem version control systems originally set out to solve, namely conflicts from simultaneous editing by multiple people and history tracking, overlap with the use actually observed in agentic coding, namely reverting code after an agent has broken it?
When and in what form did practical advice to have agents commit frequently, or to make a commit at every checkpoint, first appear in tool documentation or practitioner writing? (Collect rediscovery cases.)
Is the practice of multiple agents working simultaneously in different worktrees closer to the parallel work of multiple people that Git originally set out to support, or to one person coordinating the parallel work of multiple agents?
How do Git collaboration practices meant for one person to explain to another, such as commit messages or review diffs, change when an agent is the one generating the commit? Do they still assume a human reader, or do they become a record intended for other agents or for the agent itself?
Do problems from the era before version control, namely conflicts in shared-file or lock-based systems, reappear in the uncontrolled bulk edits made by agents? (Collect rediscovery cases.)

Research pointers

Git’s official history documentation and early announcement materials (verify exact dates and the circumstances of its origin; do not assert from memory)
Official documentation on commits and checkpoints in agentic coding tools
Practitioner writing on git worktree and branching strategies
Division of labor with §5.5 of this book (Make It Revertible). That section focuses on practical technique, this section on the historical shift in how the tool is used.

13.2 CI/CD and Gates: Checkpoints in a Loop Without Humans

Writing Status

Pre-draft. Check ownership and status in TOPICS.md at the repository root.

Brief. This is a section that contrasts the original rationale for continuous integration with the phenomenon in which, in an era of agent-generated code that human reviewers cannot look at for every commit, CI gates become effectively the only automated checkpoint. Write it in a three-part structure. First, accurately read the original rationale for CI/CD: the practice that frequent integration prevents integration hell, and the empirical finding that automating the deployment pipeline correlates with organizational performance. Next, collect cases of the practical convention of using CI as the last line of defense for agent-generated code. Finally, argue what changes when CI’s premise, that a human commits and a human interprets failures, shifts into a loop where the agent commits and also interprets failures itself.

Seed Questions

What exactly is the core practice Fowler presented in his writing on CI, namely integrating several times a day and verifying each integration with an automated build? (verify primary source)
What did the deployment pipeline concept that Humble and Farley presented in “Continuous Delivery” (2010), and the correlation between deployment frequency and stability that Forsgren et al. demonstrated empirically in “Accelerate” (2018), fundamentally show? (verify primary source)
How well established in practice is the workflow in which an agent writes code, commits it, and if CI fails, reads the logs and fixes it itself? Are there tool documentation or case studies that explicitly address this? (collect rediscovery cases)
When the structure CI originally presupposed, where a test failure signals a human and the human diagnoses the cause, shifts into a structure where the agent both receives the signal and does the diagnosis, how should the design of CI gates, that is, what to test and how strictly to block, change?
Does Accelerate’s finding that high-performing organizations have high deployment frequency still hold in the same direction now that agent-generated code has greatly increased deployment frequency, or is a reversal observed where deployment frequency alone rises while stability declines? (collect rediscovery cases)
Have there been reported failure cases of agents manipulating code with the sole goal of bypassing CI gates or merely getting them to pass?

Research Pointers

Martin Fowler’s writing on CI (verify original title and main point)
Humble and Farley, “Continuous Delivery” (2010), original text
Key metrics from Forsgren, Humble, and Kim’s “Accelerate” (2018) original text (deployment frequency, lead time, change failure rate, time to restore)
Points of contact with §8.3 (Verification Asymmetry) and §5.4 (Creating Verifiable Units) in this book; avoid role duplication

13.3 Documentation: From Literate Programming to CLAUDE.md

Writing Status

Pre-draft. Check ownership and status in TOPICS.md at the repository root.

Brief. This section contrasts the ideal presented by Knuth’s (1984) literate programming, the argument that code should be woven together with explanatory prose meant for human readers, with the new documentation genre created by files like AGENTS.md and CLAUDE.md. It is written in three parts. First, it reads closely what Knuth’s ideal actually intended: that the WEB system and programs should be written to explain themselves to people. Next, it gathers cases of when and how the new practice of AGENTS.md and CLAUDE.md became standardized. Finally, it argues what remains and what becomes meaningless, among the narrative quality of explanation and the integration of code and prose that Knuth emphasized, when the reader of the document shifts from a human to an AI.

Seed Questions

What is the exact wording and basis of the core argument Knuth presents in “Literate Programming” (1984), the claim that a program should be treated as a literary work that explains itself to people? (verify against the primary source)
Confirm precisely how Knuth’s WEB system actually worked: in what order it wove together code and explanatory prose, and how it split into two outputs, a human-readable document and compilable code. (verify against the primary source)
Since when, and starting from which tool or practice, did files like AGENTS.md and CLAUDE.md become established as project descriptions read by AI agents? (collect rediscovery cases; if it cannot be confirmed, leave it as a research directive)
The core of Knuth’s literate programming was physically weaving code and explanation together into a single file, whereas files like AGENTS.md are separate files apart from the code. Is this physical separation compatible with Knuth’s argument that the order of the narrative need not follow the execution order of the code, or is it a design that runs in the opposite direction?
How are the reasons commonly cited for why literate programming failed to gain wide adoption in practice (lack of tooling, maintenance burden, and so on) either avoided or reproduced identically in AGENTS.md-style documents?
If there is a practice of AI generating or updating the AGENTS.md that it will itself read, how does this change literate programming’s premise of authorship, that a person explains something for another person?

Research Pointers

Knuth, “Literate Programming” (1984), the original text published in The Computer Journal
Announcements or presentations related to the standardization of AGENTS.md (the process by which multiple tools came to adopt it in common; verify the exact timing)
Official documentation on CLAUDE.md and AGENTS.md from Claude Code, Cursor, and others
Division of roles with §5.3 of this book (The Art of Context Management). That section focuses on practical techniques, while this section focuses on the historical lineage of the documentation genre.

13.4 Open Source Collaboration Models: Cathedral, Bazaar, Agent

Drafting Status

Not yet drafted. Check ownership and status in TOPICS.md at the repository root.

Brief. This section contrasts the cathedral model and the bazaar model presented in Raymond’s “The Cathedral and the Bazaar” (essay 1997, book 1999), along with the proposition that given enough eyeballs, all bugs are shallow, against the recent phenomenon of AI contributors appearing en masse in open source projects. It is written in a three-part structure. First, it accurately reads Raymond’s original argument: Linus’s Law, early release, frequent releases, and treating users as co-developers. Next, it gathers cases of how AI-generated issue triage or PRs are changing the review bottleneck and trust problems of open source projects. Finally, it argues whether the proposition that more eyeballs make bugs shallow still holds when those eyeballs are AI rather than human, and whether the hidden premise of trust in the bazaar model collapses in the face of AI contributors.

Seed Questions

What was the exact original wording of Linus’s Law as presented by Raymond in “The Cathedral and the Bazaar”, the proposition that given enough eyeballs, all bugs are shallow, and what evidence did he cite to support it? (Source verification)
What exactly were the conditions Raymond presented for the bazaar model to work, namely frequent releases, treating users as co-developers, and the coordinating role of the project leader, and among these, was there a stated precondition without which the bazaar model would not function? (Source verification)
Are there actually reported cases of large volumes of AI-generated PRs or issues flooding open source projects, or public response policies from maintainers? (Rediscovery case collection)
When “enough eyeballs” are filled not by humans but by AI reviewers or AI contributors, does the qualification of eyeballs that Raymond presupposed, namely trustworthy judgment and understanding of the project, still hold, or is a reversal observed in which the number of eyeballs increases while quality declines?
How many concrete cases can be found of policies newly introduced by open source maintainers to handle AI-generated contributions, such as changes to contribution guidelines, automatic labeling, or mandatory disclosure of AI contributions? (Rediscovery case collection)
Is there a trend in which Raymond’s cathedral model, the approach in which a small number of trusted developers develop in a closed manner, is being reevaluated in the AI era, and if so, can it be seen as a reaction to the crisis of the bazaar model?

Research Pointers

Raymond, “The Cathedral and the Bazaar” (essay 1997, book 1999), original text
Public policy documents on AI contributions from major open source projects, maintainer blogs
Related sections in Chapter 9 (Limits and Risks) of this book, and points of contact with §12.3 (Documentation)
Discussion of AI slop is split with concept dictionary entry G13 (slop/workslop) handling that topic; this section focuses on the open source collaboration model itself