Appendix A — Concept Dictionary
This is a dictionary of concepts that are born and evolve around vibe coding. Each entry records a definition, its origin, and its current status. Because concepts keep appearing and their meanings keep shifting, this appendix is permanently unfinished, and so it is the most frequently updated part of this book. One entry is a unit of contribution. Add new entries and claim ownership in the repository’s TOPICS.md.
A couple of sentences of definition, the origin (who, when), and the current status. For the date and person in the origin, check the primary source and link to it. Mark anything unconfirmed as “origin needs confirmation.”
A.1 vibe coding
This is an approach to building software by instructing an AI coding agent in natural language. In its narrow sense, it refers to a working style where you don’t read the generated code directly and instead iterate by watching only the execution results; in its broad sense, it refers to AI-assisted development in general.
Andrej Karpathy coined the term in a tweet from February 2025. The original text includes the phrase “fully give in to the vibes, embrace exponentials, and forget that the code even exists” (original tweet). In a one-year retrospective tweet in February 2026, Karpathy looked back on this as a “shower of thoughts throwaway tweet” (retrospective tweet).
It became a common word after being named Collins Dictionary’s Word of the Year in November 2025 (announcement, coverage). Simon Willison proposed distinguishing between “the approach of not reading the code” and “AI-assisted development in general” (post), but in actual usage the two meanings are used interchangeably.
- Read the full Willison post and organize the spectrum he distinguishes
- Check the full one-year retrospective tweet by Karpathy for the context at the time of the original tweet (which models and tools he was using)
- Cross-check against the Wikipedia overview article (link) and gather additional examples of the term’s meaning drifting
A.2 Prompt Engineering (프롬프트 엔지니어링)
The skill of designing the input given to a model, that is, the prompt, in order to obtain a desired output. This includes discovering and systematizing specific techniques such as constructing few-shot examples and inducing chain-of-thought.
For a while after the release of GPT-3 (2020), this was treated as something like a job function. Exactly who fixed this term as a job title, and when, needs verification.
As model performance improved and interaction shifted to conversational and agentic forms, its standing as an independent skill grew blurred. From the perspective of this book, it belongs to the prehistory of vibe coding.
- Check the timeline of when the job title “prompt engineer” appeared and when it disappeared from job postings
- Check the original papers for representative techniques such as few-shot and chain-of-thought
- Collect articles reporting on the disappearance of the job function (link with §1.3 section)
A.3 Context Engineering (context engineering)
This is the technique of designing not a single line of prompt but the entire context the model sees, including files, documents, conversation history, and tool outputs. It reflects a shift in the bottleneck of prompt engineering from “how do you say it” to “what do you show it.”
Tobi Lütke (Shopify CEO) coined the name in a tweet on June 19, 2025, and Karpathy left a tweet endorsing it (Karpathy tweet). Simon Willison and Phil Schmid each wrote posts organizing the concept (Willison, Schmid).
It began to be widely used from the second half of 2025, and has now become a practical term referring to the practice of designing context files like CLAUDE.md and AGENTS.md.
- Check the full text of Lütke’s original tweet and thread reactions
- Compare the definitional differences between the Willison and Schmid write-ups
- Cross-reference with practical cases covered in §3.2 and §5.3
A.4 Agentic Coding
This is a way of working in which the AI does not simply answer once and stop, but cycles through a loop of calling tools, executing code, checking the results, and then deciding on the next action. It is the technological form that actually made vibe coding possible.
It remains to be confirmed who first used the expression “agentic coding” and when. However, one reference that lays out this loop structure itself is Anthropic’s “Building Effective Agents” (December 2024) (link).
CLI-type coding agents (such as Claude Code) and IDE-integrated agents are cited as the representative tools implementing this approach. Sections §2.3 and §8.2 cover the lineage of tools and the loop structure, respectively.
- Confirm the earliest use of the term “agentic coding”
- Compare Anthropic’s “Building Effective Agents” distinction between workflows and agents against this book’s usage
- Check definitional consistency with §8.2 (Anatomy of a Coding Agent)
A.5 CHOP (chat-oriented programming)
A term for the practice of instructing AI to write code in a conversational manner through a chat interface. It is a concept adjacent to vibe coding, emphasizing that work proceeds through conversation rather than direct manipulation of code.
Steve Yegge coined the term before the phrase vibe coding emerged (O’Reilly podcast). The exact timing of its first use needs to be confirmed. Yegge co-authored a book titled “Vibe Coding” with Gene Kim, though the exact publication details need to be confirmed.
Since the term vibe coding became popular, CHOP is often used more as an earlier-generation term, or as something close to a synonym for vibe coding.
- Confirm from the original source when and in what context (which piece of writing, which talk) CHOP was first used
- Confirm the publication date and publisher of Kim and Yegge’s co-authored book “Vibe Coding”
- Collect examples that use CHOP and vibe coding as the same term, and examples that distinguish them (linked to §3.1)
A.6 바이브 엔지니어링 (vibe engineering)
A term for a way of working that keeps the speed of vibe coding while taking responsibility for the output. It amounts to a proposal to recombine engineering procedures such as verification, testing, and review back into the vibe coding workflow.
The concept was proposed by Simon Willison (post). It is known to date from fall 2025, but the exact publication date needs to be confirmed.
It is one of the reactive concepts to vibe coding’s “verification problem,” and §3.5 covers these reactive concepts together.
- Confirm the exact publication date of Willison’s post and the original wording of the definition
- Clarify the relationship between vibe engineering and adjacent reactive concepts such as spec-driven development and the TDD revival argument (§10.4)
- Check whether other authors or articles have used this term since Willison
A.7 loop engineering
Instead of a person typing a prompt every time, this is the technique of designing the loop itself, in which an agent finds work, performs it, verifies it, and records it. It is discussed as the successor concept to prompt engineering.
It spread widely following Addy Osmani’s summary piece in June 2026 (coverage).
From this book’s perspective, it is a concept corresponding to the next chapter of vibe coding. It is covered together with harness engineering in §3.4.
- Find Osmani’s original piece (the original source of the summary piece) and verify the citation
- Sort out where the concepts of loop engineering and agent harness overlap and where they diverge
- Collect real examples of tools and workflows that use this term (link with §3.4)
A.8 Agent Harness (agent harness / harness engineering)
This term refers to the execution environment that actually makes an agent work: the full set of mechanisms for tool access, permissions, loop control, and context management. In the formulation “Agent = Model + Harness,” it captures the view that, apart from the model’s own performance, harness design determines the quality of the agent.
It has been summarized as a three-stage progression running from prompt engineering through context engineering to harness engineering (Faros AI blog). It remains to be confirmed who first used the term “harness” for an agent execution environment before this summary post.
CLI-based coding agent tools such as Claude Code are cited as representative examples of a harness. This overlaps with §3.4 and §8.2.
- Confirm when the term “harness” first began to be used in the agent context
- Verify the three-stage progression (prompt → context → harness) from the Faros AI post against the original source and compare it with §3.4 of this book
- Connect to open-source agent harness examples (the source-reading targets covered in §8.2)
A.9 Spec-Driven Development (spec-driven development)
This is an approach in which, rather than telling AI to write code right away, you first draft a specification, or spec, together, and then carry out generation and verification based on that specification. It is often cited as a representative response to the verification problem of vibe coding, which by definition involves “not reading the code.”
In September 2025, GitHub released Spec Kit, presenting a four-stage flow of Spec, Plan, Tasks, and Implement (GitHub blog).
This can be seen as a case in which the specification-first principle of waterfall development was rediscovered in the AI era. §3.3 and §10.1 respectively cover the spread of the concept and the replay of the waterfall debate.
- Check whether similar “spec-first” tools or proposals existed before Spec Kit
- Compare Spec Kit’s four-stage flow with the stage divisions of the waterfall model covered in §10.1
- Collect adoption cases or critical write-ups of Spec Kit
A.10 Subagent (subagent / multi-agent)
This term refers to the structure in which a main agent delegates a specific task to a separate, independent agent instance, or to an individual agent that is delegated to and executes in this way. A delegated subagent typically has its own context window and its own scope of tool access, and returns only the result to the main agent once the task is finished. A structure that coordinates multiple subagents simultaneously or sequentially is called a multi-agent system.
The precise origin of the term needs confirmation.
As a means of parallelizing work while conserving the context window, several coding agent tools have adopted this structure. It is one of the components of agent anatomy covered in §8.2.
- Confirm which tool first productized the subagent concept, and when
- Compare how context isolation between subagents differs across tools
- Check consistency of this definition with §8.2 (Anatomy of a Coding Agent)
A.11 human-in-the-loop
This term refers to a design that explicitly places points of human confirmation or intervention within the execution process of an automated system. In the context of AI coding agents, it refers to mechanisms that require human approval before hard-to-reverse actions such as file modification, command execution, or deployment.
It is a general term used in the automation and control systems field even before AI coding, and its precise origin needs verification.
In coding agent tools, it is implemented in forms such as permission prompts, plan mode, and change approval UIs. This connects directly to the discussion of the limits of delegation covered in §5.6.
- Verify the earliest literature in which this term was used in the automation and control field
- Compare human-in-the-loop implementation methods (approval UI, plan mode, etc.) across coding agents
- Organize the relationship with §5.6 (When to Stop and Read It Yourself)
A.12 환각 (hallucination)
A term for when a language model plausibly generates content that is not factual or does not exist. A representative case in coding contexts is generating a function, library, or API that does not exist as though it were real.
The term is known to have moved from earlier use in the machine learning field to large language models, but the exact original usage and timing need verification.
This is directly connected to slopsquatting (G14) in that coding agents generating nonexistent package names can lead to supply chain attacks. It is covered in a security context in §9.2.
- Identify the earliest paper or writing where “hallucination” began to be used to refer to language model errors
- Collect empirical studies on hallucination in the code generation context (e.g., rates of generating nonexistent packages)
- Cross-check §9.2 (Security: New Attack Surfaces) and the slopsquatting entry
A.13 Slop (slop / workslop)
It refers to low-quality AI output generated in bulk without quality review. Workslop is a narrower term used specifically for output in a work context, such as reports, documents, or code, that colleagues or an organization must consume.
Origin needs verification. Both who coined the term and when, and when the variant “workslop” separately emerged, need to be checked and verified against original sources.
The term is commonly used to describe the phenomenon of generation speed outpacing review speed, and it connects to the issue covered in §9.3 (Quality Debt and Maintenance).
- Verify the earliest usage and origin of “slop” and “workslop” respectively from original sources
- Check whether there is empirical research on workslop (e.g., productivity loss estimates)
- Cross-check facts against §9.3
A.14 Slopsquatting
This term refers to a supply chain attack technique in which an attacker pre-registers a package name that does not actually exist but was hallucinated by an AI coding agent. If a developer pastes the agent’s suggestion directly into an install command, the malicious package registered by the attacker gets installed.
Origin needs verification. Who coined this term and when needs to be traced back to an original source. It appears to be a coinage derived from typosquatting (preemptively registering package names that exploit typos), but this lineage also needs confirmation.
It is frequently cited in security discussions as a representative case illustrating the trust problem with generated code. It is a key case covered in §9.2 (Security: New Attack Surfaces).
- Confirm the earliest use of the term “slopsquatting” (security research, blog posts, papers, etc.)
- Collect actual observed slopsquatting attack cases and the scale of damage
- Cross-check against §9.2 for factual consistency
A.15 MCP (Model Context Protocol)
A protocol that standardizes how AI models communicate with external tools, data sources, and services. Implementing a server that follows this standard lets different AI applications reuse the same tool integration code.
Anthropic released this protocol. The exact release date needs to be verified.
It has become the standard path for coding agents to access tools outside the file system (browsers, databases, internal company systems, etc.). In practice, some cases are also emerging where teams switch from MCP servers to direct API calls instead.
- Confirm the exact release date of MCP and the original announcement materials (Anthropic’s official blog/documentation)
- Summarize the differences from tool integration methods that existed before MCP (function calling, plugins, etc.)
- Collect the current state of MCP adoption (which companies/tools support it)
A.16 RAG (retrieval-augmented generation)
A technique in which a model retrieves relevant content from external documents or databases before generating an answer, and includes that content in the prompt. It allows the model’s response to reflect up-to-date information or private documents that are not part of its training data.
Origin needs verification. The original paper, its authors, and the publication date should be confirmed from the primary source.
In coding agents, it is used to search internal codebases or documentation and place the results into the context, and it is treated as one of the concrete implementation techniques of context engineering (G3).
- Confirm the authors and publication date of the paper that first proposed RAG from the primary source
- Collect examples of RAG usage in the context of coding agents (code search, document search)
- Clarify the relationship with the context engineering entry
A.17 Tokens / Context Window
A token is the smallest unit a language model uses to process text; it can be smaller than a word or span multiple words. The context window refers to the maximum number of tokens a model can reference at once.
This is a general technical term with no attributable origin tied to a specific person or moment.
This limit governs the size of codebase a coding agent can handle, the length of a conversation, and the number of files that can fit in context. There is an observation that as context windows grow larger, the importance of context engineering (G3) becomes even more pronounced, rather than less. §5.3 covers practical management techniques.
- Trends in context window size across major models (verify figures against official documentation)
- How tokenization methods (BPE, etc.) apply specifically to code
- Cross-check against §5.3 (the art of context management)
A.18 evals (evaluation)
This term refers to the procedure of scoring the output of an AI model or agent against a fixed set of criteria, or to the set of tests used for that scoring. It is a concept analogous to unit tests in software, used to quantitatively check model performance or detect regressions.
It is a general technical term with no origin attributable to a specific person or point in time.
In evaluating coding agents, evals that measure task success rates in real repositories are used alongside benchmark scores. This connects with §5.4 (Creating Verifiable Units).
- Confirm the methodology of representative benchmarks for coding agents (e.g., measuring repository-based task success rates)
- Summarize the differences between evals and traditional software testing (such as handling non-determinism)
- Cross-check facts against §5.4
A.19 가드레일 (guardrails)
A term referring to mechanisms that constrain the inputs and outputs of an AI system to prevent unintended behavior or dangerous outcomes. It is implemented at several layers, including prompt filtering, output validation, and execution permission restrictions.
This is a general technical term with no origin attributable to a specific person or point in time.
In coding agents, it is implemented in forms such as restricting file access scope, blocking dangerous commands, and requiring approval before execution, and it overlaps considerably with human in the loop (G11). It is discussed in the context of security and accountability in §9.2 and §9.5 respectively.
- Compare how guardrails are implemented across different coding agent tools (permission systems, sandboxes, etc.)
- Clarify the relationship with guardrail bypass cases (prompt injection, etc.)
- Cross-check facts against §9.2, §9.5
A.20 Software 2.0 / 3.0 (Software 2.0 / 3.0)
Software 2.0 refers to the paradigm of building programs by training neural network weights on data, rather than having people write rules directly as code. Software 3.0 continues this lineage and is used to refer to the stage in which a model’s behavior is programmed through natural language prompts.
Software 2.0 is a concept coined by Andrej Karpathy in a piece he wrote in 2017 (link). It remains to be confirmed who formalized the follow-up concept of Software 3.0, and when.
Software 2.0 has become established as a term for deep learning in general, while Software 3.0 is used in vibe coding discourse as a concept that underpins the view of natural language as a program.
- Confirm the original source of who first formalized the concept of “Software 3.0” and when (including Karpathy’s later talks and writings)
- Confirm in the original source where the three-stage distinction of Software 1.0/2.0/3.0 first appeared, and whether 3.0 was already present in the 2.0 article
- Work out how this connects conceptually to §8.1 (from next-token prediction to code)