現在あるAI駆動開発のパターンを調べてみたThis article maps the various AI-driven development patterns seen in practice…

The phrase "AI-driven development" has quietly become one of the most overloaded terms in software engineering, and that ambiguity is now a practical problem for teams. When one engineer says they "wrote it with Vibe," another says they "went Spec-driven," a third that they "organized the Context," and a fourth that they "built a Harness," all four may describe their work as AI-driven while pointing at very different things. A new article on the Zenn Cursor blog sets out to map these patterns as they appear in practice, with the stated aim of clarifying which layer a given discussion is really about.

The author's central observation is that the vocabulary around AI-assisted work has converged faster than the concepts behind it. One person uses "AI-driven" to mean a collection of prompting techniques; another means questions of permissions and evaluation; a third means an autonomous loop that runs inside continuous integration. Because the words sound so similar, conversations tend to drift out of alignment. The closer the terminology, the author suggests, the harder it becomes for participants to realize they are discussing entirely different concerns.

Importantly, the piece frames itself as a map rather than a ranking or a promise of results. It does not argue that any one pattern is best, nor does it guarantee effectiveness. Instead it tries to lay the approaches side by side so that teams can agree on the layer they are operating on before debating specific techniques.

At the most immediate layer sits the conversational style often labeled "vibe coding," in which a developer works interactively with a model, iterating on prompts and accepting or discarding suggestions as they go. This is primarily a prompt-engineering activity, and it tends to be fast and exploratory but loosely specified. A step further is spec-driven development, where a written specification comes first and the model implements against it, shifting the human effort toward defining intent clearly rather than steering each edit.

A separate layer concerns context: what information the model can actually see. Here the work is about assembling rules files, repository structure, retrieved snippets, and other signals so the model operates with the right background rather than guessing. This is distinct from prompting because it deals with the surrounding data pipeline rather than the wording of any single request. Higher still is the notion of a "harness," the scaffolding of permissions, evaluation, and automation that lets an agent act with some degree of autonomy, potentially running loops in CI where changes are proposed, tested, and iterated with limited human intervention.

The article notes that its authors, at a team referred to as INTERESTIC, already use some of these techniques in their own work, including role division, assigning different responsibilities to different agents or prompts, and git worktrees, which allow multiple working directories from a single repository and are useful when parallel AI-driven changes need to be isolated. Rather than deep-diving into any one of these tactics, the piece prioritizes aligning on which layer is under discussion.

For readers less familiar with the surrounding ecosystem, this framing sits alongside a broader industry shift toward agentic and specification-first workflows. Tools such as Cursor, which gives the article its blog context, have popularized deep editor integration where models read repository context and apply multi-file edits, while the wider move toward spec-driven and test-driven agent loops reflects growing interest in making AI output verifiable rather than merely plausible. Concepts like context management overlap with retrieval-augmented generation, and the "harness" idea echoes the evaluation and guardrail work seen in more mature machine-learning deployments.

The practical takeaway is modest but useful. Before arguing about whether AI-driven development works, or which tool is superior, teams likely benefit from establishing whether they are talking about prompting, specifications, context, or autonomous harnesses. That