【AI駆動開発 #4】ループエンジニアリングとは何か — バイブコーディング・Spec駆動開発との違いThe article introduces "Loop Engineering," an AI-human iterative development…

Loop Engineering is emerging as a proposed vocabulary for describing how developers work alongside AI coding assistants, and it matters because the industry still lacks shared terms for the distinct styles that have appeared as tools like Claude Code, Cursor, and GitHub Copilot have grown more capable. The article, published as the fourth installment of a Japanese series on AI-driven development, introduces the concept and positions it against two better-known approaches: vibe coding and spec-driven development.

At its core, Loop Engineering treats the iterative cycle between a human and an AI as the fundamental unit of work. Rather than defining success by a single prompt or a finished specification, the method appears to emphasize repeated rounds of generation, evaluation, and refinement. A developer sets an initial direction, the AI produces code or a plan, the human reviews the result, and that feedback informs the next iteration. The loop continues until the output converges on something acceptable. In this framing, the quality of the process depends less on the perfect initial instruction and more on how effectively each pass narrows the gap between intent and implementation.

To clarify what Loop Engineering is, the article contrasts it with vibe coding. That term was popularized in early 2025 by Andrej Karpathy to describe an intuition-first style in which a developer leans heavily on the AI, accepts its suggestions with light scrutiny, and prioritizes speed and momentum over careful verification. Vibe coding is well suited to prototypes and exploratory work, but it can accumulate problems when applied to production systems, because the human may not fully understand or vet what the AI has generated. Loop Engineering, by comparison, keeps the human actively in the evaluation seat on every pass.

The article also distinguishes Loop Engineering from spec-driven development, which front-loads effort into detailed specifications before implementation begins. In spec-driven workflows, a written document describes requirements, behavior, and constraints, and the AI then implements against that contract. Tools and frameworks such as AWS's Kiro and GitHub's Spec Kit reflect this direction, aiming to make the specification a durable, reviewable artifact that guides code generation. The trade-off is that heavy upfront specification can be slow and may struggle when requirements are still uncertain. Loop Engineering appears to occupy a middle ground, allowing direction to emerge and sharpen through iteration rather than being fixed in advance.

Framed this way, the three approaches can be read as points on a spectrum of how much structure precedes the AI's work. Vibe coding minimizes upfront structure and trusts intuition, spec-driven development maximizes it through documentation, and Loop Engineering centers the feedback cycle itself. The distinctions are largely conceptual rather than strictly technical, and in practice many developers likely blend them, sketching a rough spec, entering a loop of generation and review, and occasionally coding by feel when the task allows.

Some background helps explain why such terminology is proliferating now. The rise of agentic coding tools, which can plan tasks, edit multiple files, run commands, and respond to test results, has shifted the developer's role toward directing and reviewing rather than typing every line. Claude Code, the assistant most associated with this article's source, is one example of a command-line agent built around iterative execution. As these tools take on more autonomy, teams are searching for mental models that describe when to give the AI free rein, when to constrain it with specifications, and when to stay tightly in the loop.

It is worth noting that Loop Engineering, as presented, is a conceptual framework rather than a formal standard or a specific product, and the boundaries between it and neighboring ideas remain fluid. The value of the article lies less in a rigid definition than in giving practitioners language to reason about their own habits. For developers evaluating how to integrate AI into their workflows, understanding these categories can inform practical choices about review discipline, documentation effort, and how much to trust automated output on any given task. As the tooling continues to evolve, such vocabularies are likely to keep shifting, but they offer a useful starting point for comparing methods that would otherwise be hard to discuss precisely.