10 Rediscovering Methodologies
The last 50 years of software engineering are being rediscovered one by one in the age of AI. Each section of this part takes a single classic concept, reads the original source, and contrasts it with its reappearance in the age of AI. This chapter covers methodologies for how we work: waterfall and agile, pair programming, code review, and TDD.
10.1 Waterfall and Agile, Again
Not yet drafted. Check ownership and status in TOPICS.md at the repository root.
Brief. This section asks whether the conflict between spec-driven development and vibe coding is a rerun of the waterfall-versus-agile debate. It is written in three parts. First, it reads closely what Royce’s (1970) original paper actually argued, and what the four values and twelve principles of the Agile Manifesto (2001) actually say in the original text. Next, it gathers recent cases to see which side spec-driven development in the style of GitHub Spec Kit is closer to, and which side vibe coding practice, which starts with a prompt and iterates through repeated checking, is closer to. Finally, it argues by distinguishing the points that are genuinely the same, such as the length of the iteration cycle and the placement of the specification, from the points where the agent, as a new actor, changes the premises of both models.
Seed Questions
- Reading Royce’s (1970) original paper directly, did he really advocate for waterfall as a pure sequential model, or was he already warning about the need for iteration? (verify against the primary source)
- Among the Agile Manifesto’s four values and twelve principles, which clauses are most often cited today as the justifying logic for vibe coding? (verify against the primary source)
- Do proponents of spec-driven development (Spec Kit and others) frame their workflow as a revival of waterfall, or as a variant within agile? (collect rediscovery cases)
- In what ways is vibe coding practice, which starts with a prompt and iterates through repeated checking, the same as or different from agile’s iteration cycle, and does the theory still hold even when the unit of iteration shrinks to seconds?
- How much do the criticisms from the waterfall-versus-agile debate at the time (excessive documentation, the fiction of planning) overlap with today’s criticisms of spec-driven development?
- If there are cases of practitioners mixing the two workflows, what criteria do they use to divide them? (collect rediscovery cases)
Research Pointers
- Royce’s 1970 original paper (search by author name and year to verify the original text)
- agilemanifesto.org original text (four values, twelve principles)
- The GitHub Spec Kit announcement post and practitioner blogs on its adoption and criticism
- Points of contact with §3.3 (spec-driven development) and §2.2 (spread of terminology) in this book; avoid duplicate exposition
10.2 Pair Programming: When Your Pair Stops Being Human
Not yet drafted. Check owner and status in TOPICS.md at the repository root.
Brief. This section contrasts the arguments Beck’s XP (1999) used to justify pair programming with today’s practice of pairing with AI. It is written in three parts. First, it reads closely what the original XP text says about pairing arguments such as continuous review, knowledge propagation, and role rotation. Next, it collects examples of how tools introduce themselves as an “AI pair programmer” and how practitioners describe their workflows. Finally, it argues whether the premises of human pairing, namely two equal actors, mutual learning, and social pressure, hold or fail to hold in a human-AI relationship.
Seed Questions
- What exactly was the core argument Beck made for pair programming in “Extreme Programming Explained” (1999), including the parts that go beyond simple defect reduction (verify against the primary source)
- XP’s pairing presupposes rotation between the driver and observer roles; does this role rotation actually happen when collaborating with AI, or is the human always fixed in the observer role?
- What product or document first used the phrase “AI pair programming,” and how far does that phrase carry over XP’s original meaning before it slides into metaphor? (collect rediscovery cases)
- Among the effects reported by human-to-human pairing research (defect reduction, learning effects), are there recent studies or cases claiming that these are also reproduced in human-AI pairing? (collect rediscovery cases)
- The social mechanisms of pair programming, namely embarrassment, peer pressure, and the demand for immediate explanation, do not operate on an AI partner; how does this difference affect actual work quality?
- How are the objections to pair programming that even existed among XP practitioners (fatigue, cost) raised differently in the age of AI pairing?
Research Pointers
- The chapter on pair programming in Beck’s original text, “Extreme Programming Explained” (1999)
- Empirical studies on pair programming (papers measuring defect rates and time spent)
- Self-descriptions and presentation materials of tools such as GitHub Copilot and Cursor introducing themselves as pair programmers
- Practitioner blog posts describing workflows for pairing with AI
10.3 Code Review: From Fagan Inspections to AI Reviewers
Pre-draft. Check TOPICS.md at the repository root for owner and status.
Brief. This section contrasts the original purpose of code review established by Fagan’s inspections (1976) with LLM-based automated review tools. It is written in three parts. First, it reads the formal procedure of Fagan inspections precisely from the original source: preparation in advance, role-based participants, defect classification, and rework verification. Next, it gathers cases of what AI reviewer tools actually check and what they miss. Finally, it argues which of the three functions of review, defect detection, knowledge diffusion, and establishing organizational norms, survive in the AI era and which fall away.
Seed Questions
- In Fagan’s (1976) inspection procedure, how exactly were participant roles (moderator, author, reviewer, recorder) and the defect classification system defined? (verify against the original source)
- What Fagan inspections explicitly tried to prevent, such as authors defending themselves or unstructured ad hoc review, reappears or disappears in what form in today’s AI review tools? (verify against the original source)
- Of the three traditional purposes of code review, defect detection, knowledge diffusion to newcomers, and establishing team coding norms, which does the AI reviewer replace and which can it not replace? (collect rediscovery cases)
- How does the structure in which AI reviews code written by AI conflict with the principle of author-reviewer independence that Fagan assumed?
- Does data exist on the rate at which people actually act on what AI review tools flag in practice? (collect rediscovery cases)
- Formality already receded once when the field moved from Fagan inspections to lightweight code review; does the emergence of AI reviewers push formality back up or down further?
Research Pointers
- Fagan, “Design and Code Inspections to Reduce Errors in Program Development”, IBM Systems Journal(1976) original text
- Official documentation for tools such as GitHub Copilot code review and Claude Code /code-review
- Empirical research on code review (papers covering code review practices at large tech companies)
- Focus on the review procedure and purpose itself, to avoid overlapping with §9.3 (Quality Debt) of this book
10.4 The Revival of TDD: When Tests Become the Spec
Pre-draft. Check ownership and status in TOPICS.md at the repository root.
Brief. This section contrasts the red-green-refactor cycle and the argument that tests are specifications, as presented in Beck’s TDD (2002), with the recent practice in agentic coding of writing tests first to serve as guardrails and verification signals. It connects directly to this book’s observation that verification is the bottleneck (§8.3). It is written in three parts. First, it reads the original TDD cycle and argument precisely. Second, it gathers cases showing how test-first prompting became established practice in agentic workflows. Finally, it argues whether TDD as a design tool, as Beck emphasized, and tests as a tool for verifying AI output are the same thing or different.
Seed Questions
- What is the exact sequence of the red-green-refactor cycle presented by Beck in “Test-Driven Development: By Example” (2002), and in what context did he call tests a design tool? (verify against the source)
- Beck’s argument for TDD placed emphasis on design pressure, breaking work into small units and thinking through interfaces first, rather than on defect reduction. Does this design-pressure argument hold equally when AI is the one writing the code, or was it an argument valid only when humans wrote the code?
- Since when has the workflow of writing tests first and having the agent make them pass appeared explicitly in tool documentation or practitioner conventions? (gather rediscovery cases)
- TDD originally presupposed that the person writing the tests and the person writing the code are the same. How is this condition broken when an agent writes both the tests and the implementation, and does this undermine the validity of tests as a verification signal?
- Are both success stories cited by TDD revivalists and failure cases, where AI manipulates the tests themselves in order to pass them, reported? (gather rediscovery cases)
- Has Kent Beck himself publicly commented on the relationship between AI coding and TDD recently, and if so, what did he say?
Research Pointers
- Beck, “Test-Driven Development: By Example” (2002), original text (preface, early example chapters)
- Test-first recommendation documentation from agentic coding tools, practitioner blogs
- Points of connection with §8.3 of this book (verification asymmetry); avoid duplicate exposition
- Check whether Kent Beck has mentioned AI coding in recent interviews or blog posts