3 Evolution of the Discourse
As soon as the term vibe coding took hold, a flood of concepts emerged to refine or move beyond it: CHOP, context engineering, spec-driven development, loop engineering, vibe engineering. This chapter traces the genealogy of these concepts and tracks what bottleneck each conceptual shift was responding to. The final section treats this marketplace of concepts itself as an object of analysis.
3.1 CHOP and Agentic Coding: A Spectrum of Autonomy
Not yet drafted. Check TOPICS.md at the repository root for ownership and status.
Brief. This section starts from the concept of CHOP (chat-oriented programming), which Steve Yegge used before the term vibe coding spread, and moves on to the agent autonomy spectrum (how far humans are involved and from what point agents move autonomously) that was formulated afterward. The key question is how CHOP, vibe coding, and agentic coding are distinguished from and overlap with each other. Chapter 3 covers the follow-up concepts that poured out after the term vibe coding took hold, and this section covers the earliest of these threads.
Seed Questions
- When and in what context did Steve Yegge first propose CHOP, and what is its chronological relationship to vibe coding?
- How do CHOP and vibe coding differ by definition, and do practitioners use the two terms distinctly or interchangeably?
- How does the term “agentic coding” relate to CHOP and vibe coding respectively?
- Who organized the attempts to divide agent autonomy into stages (from autocomplete to autonomous execution and autonomous verification), and by what criteria?
- How did the book co-written by Gene Kim and Steve Yegge synthesize these concepts?
Research Pointers
- Check Steve Yegge’s remarks on CHOP in the O’Reilly podcast interview
- Check the exact publication date and core arguments of the book “Vibe Coding,” co-written by Gene Kim and Steve Yegge
- Find and compare practitioner blog posts that address stages of agent autonomy (cases that present a level table)
3.2 Context Engineering
Pre-draft. Check ownership and status in TOPICS.md at the repository root.
Brief. This section covers the naming and formalization of the concept of context engineering. Shopify CEO Tobi Lütke coined the term in a June 2025 tweet, and Karpathy lent weight to its formalization by endorsing it. The core claim is that the bottleneck has shifted from the skill of writing a single good prompt to the skill of designing the entire construction of the context window — what the agent sees and doesn’t see on each turn. In Chapter 3, this section covers the concept that directly succeeds prompt engineering (Part 1).
Seed Questions
- In exactly which tweet did Tobi Lütke propose this term, and what problem awareness did it arise from?
- In what way did Karpathy agree with this naming, and what role did his endorsement play in the term’s spread?
- What is the substantive difference between “prompt engineering” and “context engineering,” and where do they overlap?
- How did Simon Willison and Phil Schmid each summarize this concept, and is there a difference in emphasis between the two summaries?
- What development practices has the concept of context engineering actually changed (documents like CLAUDE.md and AGENTS.md, context window budget management, etc.)?
Research Pointers
- Check Tobi Lütke’s naming tweet (2025-06-19) and Karpathy’s endorsement tweet
- Read Simon Willison’s summary post (2025-06-27)
- Read Phil Schmid’s summary post
3.3 Spec-Driven Development
Pre-draft. Check ownership and status in TOPICS.md at the repository root.
Brief. This section treats spec-driven development as a reaction to vibe coding. Spec Kit, released by GitHub in September 2025, is a tool that explicitly walks through four stages: Spec, Plan, Tasks, and Implement. The core question is what tension exists between vibe coding’s attitude of “forget that the code even exists” and spec-driven development’s attitude of writing the specification first and prioritizing it over the code. It should also address whether this conflict is a replay of the waterfall versus agile debate (revisited in Part 4 §10.1). In Chapter 3, this section covers the first systematic reaction to vibe coding.
Seed Questions
- What problem was each of the four stages specified by GitHub Spec Kit (Spec, Plan, Tasks, Implement) designed to address?
- Are there other tools or workflows that claim to be spec-driven development, and if so, how do their approaches differ?
- Is spec-driven development an attempt to replace vibe coding or to complement it, and which is closer to practitioners’ actual usage patterns?
- What similarities and differences emerge when this conflict is overlaid with the waterfall versus agile debate (Royce 1970, Agile Manifesto 2001)?
- Is there evidence that the spec-first approach actually improved code quality or verifiability?
Research Pointers
- Read GitHub’s official announcement, “Spec-driven development with AI” (2025-09)
- Contrast the primary sources Winston Royce, “Managing the Development of Large Software Systems” (1970) and the Agile Manifesto (2001)
- Investigate and compare similar workflows besides Spec Kit (plan-mode-type features from other vendors)
3.4 Loop Engineering and Harness Engineering
Pre-draft. Check ownership and status in TOPICS.md at the repository root.
Brief. This section covers two successor concepts formalized in 2026: loop engineering and harness engineering. Loop engineering is a concept that Addy Osmani formalized and popularized around June 2026; it covers designs that make agents iterate on their own, finding and verifying work by themselves. Harness engineering is a concept that emerged from the formulation “an agent is the sum of a model and a harness,” emphasizing the design of the tools, prompts, and verification mechanisms that surround the model rather than the model itself. The key question is where these two concepts sit, alongside prompt engineering and context engineering, on the continuum of bottleneck shifts.
Seed Questions
- What is the core claim of the loop engineering concept as formalized by Addy Osmani, and what practical examples does he cite?
- How does the “loop” as a unit (a cycle in which the agent finds work, does it, verifies it, and remembers it on its own) differ from earlier conversation-turn-based interaction?
- Who first proposed the formulation “Agent = Model + Harness,” and when, and what does this formulation emphasize?
- In practice, how is the term harness engineering distinguished from context engineering, or do the two overlap?
- Which of loop engineering and harness engineering refers to the broader concept, or are they different axes altogether?
Research Pointers
- Trace back to Osmani’s original formalization via the adtmag report, “Loop Engineering Emerges as Developers Put AI Coding Agents on Repeat” (2026-07-01).
- Read Faros AI’s “harness engineering” blog post.
- Check the genealogical relationship with Anthropic’s “Building effective agents” (2024-12).
3.5 Vibe Engineering and Its Reactions
Pre-draft. Check TOPICS.md at the repository root for owner and status.
Brief. This section covers the concept of vibe engineering proposed by Simon Willison and the attempts to redefine it that arose around it. Once vibe coding came to be widely understood as an attitude of “not reading the code and leaving everything to it,” terms emerged in reaction, referring to an attitude that maintains speed while taking responsibility for the results. This section needs to verify exactly what distinguishes vibe engineering from vibe coding, and whether these attempts at redefinition are actually used distinctly in practice. In Chapter 3, this section, together with §3.3 (spec-driven development), forms the axis of reaction against vibe coding.
Seed Questions
- What problem was Simon Willison responding to when he proposed vibe engineering, and exactly when did he propose it?
- Specifically, where is the boundary drawn between vibe engineering and vibe coding?
- Are there other writers or concepts that have attempted redefinitions along the lines of “accountable acceleration,” and if so, how do they compare with Willison’s definition?
- Are these attempts at redefinition actually used distinctly in practice, or are they all lumped together under the term vibe coding?
- How widely did the term vibe engineering itself spread afterward, or did it remain a minority discourse?
Research Pointers
- Simon Willison, “vibe engineering” - check the full original text and the exact publication date.
- Compare the continuity of argument with Willison’s earlier piece “Not all AI-assisted programming is vibe coding” (2025-03-19).
- Find follow-up pieces that cite or rebut vibe engineering to gauge the extent of its spread.
3.6 Observing the Concept Market: How Is the Next Buzzword Made?
Pre-draft. Check ownership and status in TOPICS.md at the repository root.
Brief. This section serves as a meta-analysis of the entire Chapter 3. It takes as its object of analysis the pattern itself of birth, spread, and disappearance (or settling) of the terms that led from prompt engineering to vibe coding, agentic coding, context engineering, spec-driven development, loop engineering, harness engineering, and vibe engineering. The core hypothesis is that each conceptual replacement reflects a shift in the actual bottleneck (from a lack of model capability, to a lack of context management, to a lack of verification, to a lack of loop and system design). If this hypothesis holds, we can also try to predict which bottleneck the next buzzword will point to. As the final section of Part 1, it serves to summarize the entire conceptual history before moving on to Part 2 (Technology).
Seed Questions
- If we arrange the concepts covered in this chapter in chronological order, how long was each concept’s lifespan (from its emergence until it gave way to the next concept)?
- At each point of conceptual replacement, what can we claim was the bottleneck that actually shifted, and what is the basis for that claim?
- Did these discourses actually change development practices, or were they closer to just putting a new name on existing practices?
- Is there a common pattern in the paths by which concepts spread (a single tweet, endorsement by an influential figure, media coverage, dictionary entry)?
- If this analysis is correct, in which direction can we predict the next bottleneck and the next buzzword will lie?
Research Pointers
- Organize into a table the exact emergence timing of each concept as established in the other sections of this chapter (§3.1-§3.5), and compare them chronologically.
- Search for whether there is linguistic or meme-diffusion research that addresses the mechanism of terminology diffusion itself.
- Examine whether Meir Lehman’s laws of software evolution (1970s) can also be analogized to the evolution of concepts themselves.