フレームワークは人間軸ではなくAI軸で選ぶ時代になった｜開発手法のパラダイムシフトAs AI-assisted coding becomes mainstream, the criteria for choosing a framework…

The way development teams pick a web framework is quietly changing. For years, the answer to "Why Next.js?" or "Why this stack?" came down to human considerations: a gentle learning curve, a large hiring pool, familiarity within the team, or simply that a tool was fashionable. A recent argument circulating among developers—particularly those using AI coding assistants like Cursor—suggests that the deciding factor is increasingly whether a framework is easy for an AI to understand and work with. If accurate, this represents a meaningful shift in how technical decisions get made.

The reasoning behind the shift is straightforward. The large language models that power tools such as Cursor, GitHub Copilot, and Claude Code learn from publicly available code, documentation, and discussion. Frameworks with abundant, high-quality training data—stable APIs, consistent conventions, and thorough documentation—tend to produce more reliable AI output. When an assistant can generate correct, idiomatic code with fewer corrections, the practical cost of building and maintaining software drops. Under this logic, a framework's "AI compatibility" becomes a first-class selection criterion rather than an afterthought.

Several technical characteristics appear to make a framework more amenable to AI assistance. Strong typing, as found in TypeScript-first ecosystems, gives models and their tooling more signal to reason about correctness. Predictable file structures and naming conventions reduce ambiguity, helping an assistant place code where it belongs. Stable, slowly changing APIs matter too, because models trained on older snapshots can fall behind when a framework introduces frequent breaking changes. Frameworks that ship clear, machine-readable documentation—or that publish guidance specifically for AI agents—may further improve the accuracy of generated code.

This is where the human-centric and AI-centric criteria can diverge. A framework that is comfortable for experienced engineers is not automatically the one an AI handles best, and vice versa. Popularity still matters, but its role is changing: a widely adopted framework generates more public code, which in turn strengthens a model's knowledge of it. That creates a potential feedback loop in which popular, well-documented frameworks become even more entrenched because AI tools reinforce their use. Newer or niche frameworks, however capable, may struggle to earn AI fluency until enough examples exist for models to learn from.

Context is important here. The past couple of years have seen AI-assisted coding move from novelty to routine for many teams. Cursor, an editor built around AI-native workflows, sits alongside GitHub Copilot, Amazon's tooling, and command-line agents in a crowded and fast-moving market. Vendors have introduced features such as project-wide context, rules files, and the Model Context Protocol to feed assistants more accurate information about a codebase. These mechanisms let teams partly compensate for gaps in a model's built-in knowledge by supplying documentation, examples, and conventions directly—suggesting that "AI-friendliness" is not fixed and can be engineered to some degree.

It is worth treating the strongest version of this claim with some caution. The argument that framework choice is now primarily an AI question reflects a particular viewpoint from the AI-assisted development community, and human factors have not disappeared. Teams still need engineers who can review, debug, and take responsibility for what an assistant produces, and hiring, long-term maintenance, performance, and licensing remain real constraints. The more measured reading is that AI compatibility is becoming one influential factor among several, rather than a wholesale replacement for the criteria that came before.

Even so, the underlying trend is worth watching. If AI tools continue to shoulder more of the day-to-day coding, the frameworks that produce the cleanest, most predictable output for those tools are likely to gain an advantage in adoption. That could influence not only how teams choose between established options like Next.js but also how framework maintainers design their APIs, structure their documentation, and think about publishing machine-consumable guidance. For developers, the practical takeaway is to add a new question to the usual checklist: beyond whether a team can work with a framework, how well can the AI?