現在あるAI駆動開発のパターンを調べてみたThe article categorizes and compares major AI-driven development patterns—vibe…

A new blog post published on Qiita sets out to untangle one of the more persistent sources of confusion in modern software work: the loose, overlapping vocabulary surrounding "AI-driven development." The piece argues that when practitioners say they "wrote it with vibe," "went spec-driven," "tuned the context," or "built a harness," they are frequently describing very different activities, even though the phrases sound adjacent. Clarifying these distinctions matters because teams that assume shared meaning often end up talking past one another about tooling, review practices, and where human judgment should sit.

The article's central observation is that "AI-driven" can point to at least four separable ideas. For one person it captures prompting technique; for another it concerns permissions and evaluation; for a third it describes an autonomous loop that runs inside continuous integration. The closer the terms sit to one another, the easier it becomes to conflate them, and the harder it becomes to agree on what "good" looks like in a given workflow.

The first pattern, vibe coding, refers to a fast, conversational style in which a developer describes intent in natural language and accepts generated code with relatively light inspection. The term entered wide circulation in early 2025 after Andrej Karpathy used it to describe leaning into the model's output and iterating by feel. It is well suited to prototypes and throwaway experiments, but the article frames it as one point on a spectrum rather than a universal method.

Spec-driven development sits toward the more disciplined end. Here the emphasis is on writing an explicit specification first—requirements, interfaces, acceptance criteria—and then having the model implement against that artifact. This approach has gained momentum alongside tooling such as GitHub's spec-kit and Amazon's Kiro, both of which try to make the specification, rather than the chat transcript, the durable source of truth. The trade-off is more upfront structure in exchange for output that is easier to review and reproduce.

Context engineering, the third pattern, concerns what information the model actually sees at inference time. Rather than crafting a single clever prompt, it focuses on assembling the right files, documentation, rules, and prior state so the assistant operates with adequate grounding. The term has been gaining traction as a successor to "prompt engineering," reflecting a shift in emphasis from wording toward the systematic management of context windows, retrieval, and project-specific rules—an area where editor-integrated tools like Cursor and its rules files are commonly cited.

The fourth pattern, described in terms of harnesses and autonomous loops, moves beyond an individual editing session. It covers agents that operate with defined permissions, run tests, evaluate their own results, and iterate—often wired into CI so that changes can be proposed and validated with limited human intervention. This is the most operationally demanding of the four, because it raises questions about guardrails, evaluation criteria, and trust that the earlier patterns can sidestep.

By laying these categories side by side, the article's stated goal is not to crown a single winner but to build shared vocabulary that teams can use to reason about their own practices. That framing appears deliberate: each pattern carries different assumptions about how much a human reviews, how much autonomy the system holds, and how success is measured. A prototype built by vibe is judged differently from a change merged by an autonomous pipeline.

The piece fits a broader industry trend in which the label "AI coding" is fragmenting into more precise sub-disciplines as the tooling matures. Editors such as Cursor, command-line agents, and specification frameworks each nudge developers toward one pattern or another, and many real workflows blend several—vibe coding to explore, specs to formalize, context curation to keep the model grounded, and automation to scale. The article's contribution is less a new technique than a map, and for teams struggling to agree on terms, that map is likely to be the more immediately useful artifact.