TL;DR
Not on an impression. In the only published same-task benchmark found here, every model scored at least as well in React as in Vue, but the models date from early 2025, and Vercel's current Next.js evals show bundled documentation lifting agents by up to 16 points in one framework. Many Vue failures trace to missing versions, conventions, checks or unclear requirements. Run one representative ticket in your Vue app with that context and those checks first, then weigh whatever still fails against the full cost of a rewrite.
Two reports about the same framework
Two Hacker News comments, sixteen months apart, describe the same framework in opposite terms. In May 2025 one developer wrote that Gemini 2.5 Pro and Claude 3.7 still produced React components in their Vue codebase almost daily, even when told not to (comment 44031781). In September 2026 another wrote that their team uses Vue, Claude and Codex handle it fine, and they feel no need to change anything (comment 49561287).
That second comment answered an essay by Nolan Lawson (August 2026) arguing that React is overrepresented in training data and that "agent experience" is starting to matter more than developer experience. It is observation, not measurement.
The same worry shows up as a question. In July 2025 an Ask HN post asked whether companies will keep their frameworks simply because AI tools handle them well, and counted Vue alongside React among those. On the Cursor forum, a developer building with Laravel and Vue asked which AI model to use. The reply they praised named models but was mostly about workflow: an MCP server for Laravel, a detailed requirements file, a reviewed plan, a fresh chat per task and tests.
Which describes your codebase can be tested before anyone budgets a rewrite.
What has actually been measured
Web-Bench, published in May 2025 by ByteDance researchers, built the same 20 sequential tasks in React, Vue, Angular and Svelte and ran six models on each (arXiv 2505.07473). Scored as the share of tasks passed with one retry, best of five runs, React came out at least level with Vue for every model. Claude 3.7 Sonnet passed 65% in React and 30% in Vue; its thinking mode passed 60% and 40%; Doubao 1.5 tied at 35%. The full-stack comparison was mixed. Claude did better with Next.js than with Nuxt, while GPT-4o (25% against 10%) and DeepSeek-R1 (25% against 20%) did better with Nuxt, and the authors note that Next.js's changing API and its split between Server and Client Components confused the models.
Vercel's Next.js agent evals, last run on 25 September 2026, test agents on Next.js only, so they say nothing about Vue. They do show how much depends on what the agent reads. Current agents pass 74% to 97% of the evals (an eval passes if one of four attempts succeeds); with an AGENTS.md file bundling the Next.js documentation, several move from 81% or 84% to 97%. Even in the framework assumed to be favoured, context moves about a sixth of the tasks.
Vue has equivalent inputs. Its documentation has published an llms.txt index and a full-text version since April 2025, and Nuxt added an MCP server and its own llms.txt in November 2025. Nobody has published whether they close the Web-Bench gap; a trial on your codebase can.
Name the failure before blaming the framework
"The agent is worse at Vue" covers several problems. Treat the causes below as possibilities to check, not diagnoses; many would travel with the code into a migration:
Comparison
| What you see | A possible cause | Try first, in the Vue app |
|---|---|---|
| React hooks, or JSX where the project uses templates | React habits winning over thin context; Vue itself supports JSX when the build is configured for it | State the Vue version, component format and whether the project uses JSX, and point to two existing components |
| Options API and Composition API mixed in one change | No written convention; Vue supports both styles | Name the style the project uses in the instructions file |
| Vue 2, Nuxt 2 or deprecated APIs | The installed versions are not in context | Copy versions from the lock file into the instructions, and give the agent documentation for that major version (vuejs.org's llms.txt covers Vue 3) or the Nuxt MCP server |
| A new component that duplicates an existing one | The agent did not search the codebase | Ask it to list the components and composables it will reuse before it edits |
| Compiles, looks right, does the wrong thing | An unclear requirement, or an ordinary implementation error | Write acceptance criteria and edge cases before the run |
| Looks right in the diff, fails the build | No checks in the loop | Require vue-tsc, eslint-plugin-vue and Vitest to pass before the agent reports done |
Only the first row is plainly about the framework, and a rewrite would not cleanly remove even that: it trades Vue mistakes for React ones, while the other rows travel with the code. The Vue documentation calls the two API styles equally capable and recommends vue-tsc for type checking and Vitest for unit tests, so every fix uses tools Vue's own documentation recommends. A Next.js app has its own versions and conventions to get right; the article on stopping an AI coding tool suggesting outdated Next.js patterns covers that side of the fence.
Run one real ticket through the Vue app first
A fair test uses work the team actually does, run twice from the same starting point:
- Pick a representative ticket: a real change touching a component, shared state or a composable, a route and a test, at the size you normally hand to an agent. A demo task flatters every framework.
- Write the acceptance criteria and two or three edge cases before any run.
- Run it with the current setup. Record whether checks passed when the agent first reported done, how many corrections you made, and whether each was framework knowledge, project context or an unclear requirement.
- Improve the setup, not the framework: an instructions file with installed versions, API style, canonical components, a documentation source and required checks.
- Run the same ticket again from the same commit, then repeat with a second ticket so one lucky run does not decide.
- If someone proposes React, build the same feature in a small React or Next.js prototype with equally good context. A well-briefed new project against a poorly briefed old one measures the briefing, not the framework.
Two or three tickets give a direction, not a benchmark. Record the model and tool version; results move with each release.
Paqad does not make models equally capable in every framework or supply runtime tests; the checks come from your project. It can make the setup in step 4 repeatable. Its stack detection, a script rather than a model, reads package.json and the lock file, recognises Vue among its framework packs and records the versions the lock file pins, including a major-version band for packages such as vue and nuxt; Nuxt is one of the Vue pack's traits. Paqad's documentation explains how stack detection reads your project and picks the pack.
Put the rewrite on the same scale
Viget's August 2026 account of moving a project from Lit to React with AI shows the other side. The move was driven by new infrastructure requirements, not by the agents. By their estimate, doing it by hand would have taken about a month of migration and another month of QA; with AI it took a few days of migration and two weeks of QA. The AI did not get all the styles right, so they recommend a visual check of every component and warn that design review can take several rounds. Lit components are a small surface next to a Vue app with a router, store, component library or Nuxt modules.
Price the rewrite in the same units as the problem: code to translate, libraries with no React equivalent, QA and visual review, regressions that reach users, retraining and weeks without product progress. Against that, put the monthly cost of the framework-knowledge failures still left after step 4. Context and requirement failures do not count; they would follow the code.
Decision guide
- Keep Vue if the improved setup removed most failures, if what remains is context or requirements, or if the remaining framework errors cost less over your planning period than the rewrite and its QA.
- Plan a migration only if framework-knowledge errors remain after the improved setup, appear with more than one tool or model, cost more than the migration over that period, and other reasons such as hiring or a needed library point the same way.
- Re-run the trial when a major model or tool release lands, because neither the gap nor its cost is fixed.
If the case holds, approve the migration as a project with its own acceptance tests and a rollback point. The article on starting a coding agent on an existing codebase safely describes the baseline worth recording first, whichever way you decide.
Frequently Asked Questions
Should I change a working Vue project to React or Next.js just because an AI tool seems better at them?
Not on that basis alone. "Seems better" usually comes from a handful of bad sessions, and a session is a mix of model, tool, context and request. Separate those first. A migration can be the right decision for other reasons, and AI support can be one input among them, but it should be a measured input on your own tickets, not a reputation.
Are the failures caused by the framework, the agent's context or unclear requirements?
Classify each correction you make during a week of normal work. If a fix needed knowledge any Vue developer would have, count it as framework; if it needed something about this project, context; if you had to decide what the feature should do, requirements. A plain bug in clear, well-briefed work is an implementation error that no framework removes. A count by category is more useful than a general impression, and it shows where to spend effort first.
What representative Vue task would fairly test whether a better workflow solves the problem?
One that crosses a boundary your app actually has: a form that writes to shared state and changes a route, or a component that must reuse an existing composable. Avoid isolated components with no dependencies, since agents do well on those in any framework, and avoid the hardest legacy corner, which tests the legacy code more than the framework.
How should migration cost and regressions be weighed against any measured improvement in AI assistance?
Use one period, such as the next twelve months, for both sides. Estimate the rewrite including QA and a regression allowance, and the remaining framework-related correction time over the same period. Add the risk that the AI advantage shrinks with the next model release, while a rewrite's cost is paid in full up front.
What evidence would justify keeping the current stack or approving a migration independently of model hype?
For keeping it: the same tickets passing checks with fewer corrections after the improved setup. For migrating: a side-by-side prototype with equal context that still shows fewer framework errors, repeated with a second tool, plus a non-AI reason pointing the same way. Write the decision and its evidence down so it can be revisited when tools change.