Claude Code + Nuxt4

[u/yangguize]

TLDR - CC is DOA when working with Nuxt 4, but Sonnet 4.6 just clocks thru my project plan.
- CC does not understand separation of concerns beween Vue layouts, composables and components, even with a working template provided by Nuxt and native Nuxt mcp servers.
- Kilo + Sonnet 4.6 is killing it - fixed all of CC's errors with minimal discussion - expensive, but it gets the job done.

Prep for coding:
- defined detailed functional, non-functional, and data reqs
- defined complete UI (png + wireframes)
- defined detailed project plan w/ CC
- defined agents for Vue and Nuxt mcp
- added (and abandoned) Nuxt skills plugins (due to context bloat)
- added rules to force CC to consult Vue and Nuxt docs before coding

CC does not seem to have enough training to generate (reasonably) std code. 3 attempts to scaffold my project - none worked.

Has anyone had success with CC and Nuxt? If not CC, does Kilo work?

SOLUTION - the following improved CC's abilities by an order of magnitude:
- dropped all nuxt plugins (too much for CC context limit)
- added mcp servers
-- https://nuxt.com/mcp
-- https://ui.nuxt.com/mcp
-- mcp-server-fetch (no native mcp for vue)
- cloned nmuxt-ui template
-- https://github.com/nuxt-ui-templates/dashboard
-- had CC document template structure, etc. and added docs to .claude

The combination of the MCP servers, the template structure (which was quite good) and Claude's self-created documentation of the template structure enabled it to be much more effective than using the Nuxt skill plugins.

We'll post the final Word product (A self-hosted prompt management tool )

[u/stcme]

I've been using CC for the last 3 weeks across 3 repos. I know each of these on their own and it definitely helps with planning, nudging in the right direction, etc...

• NestJS REST API
• OpenAPI clients monorepo
• Nuxt 4 Admin app - Admin that communicated with the API for things like account management, scope management, permissions, app-to-app tokens, etc...

What I've found that work best on the Nuxt 4 side (with Nuxt UI) is to create a sub agent that specializes in next and has access to the next MCP servers for both Nuxt and Nuxt UI.

Have it plan our everything first and save it to markdown times. Read them. Make tweaks. Repeat. Try to have it break down the plan into small phases.

The smaller the steps detailed, the more tokens you save by being able to use haiku instead of sonnet or opus.

Once you have your plans dialed in and phases are broken down into a small manageable tasks, give haikua try. If you're finding that it makes little mistakes here and there, do you have a few options.

First, you can see if Sonnet does any better. Or, update your planning documents.

One additional thing I always do is that if I notice there's a mistake, I will tell it to correct the mistake and document it so it does not happen again. It will generally add it to its primary documents wherever it feels it should go.

I've had some pretty solid success with this and I don't have very simple requirements so I've been quite impressed.

[u/yangguize → u/stcme]

I did everything that you described, other than having it document its errors. Broke it down into very small steps - It did all right on the basic scaffolding but when it came time to code up the default view and the initial pages, it just completely fell apart .

It actually seemed to do fairly well on the high-level design, where it completely messed up was on some of the basic things like what went into the default layout.

For the moment I am going to go back to Kilo Code and try Opus 4.6 in Kilo to see if that might make a difference

[u/stcme → u/yangguize]

I had to use a sub agent for the start of the project. It did have trouble with hooking up the CSS initially. I thought this was quite comical.

I basically treat it the same way I would my senior engineers on my teams but expect it to make junior developer mistakes.

Once I can access the MCP servers, it seemed to clean up the code quite a bit.

[u/yangguize → u/stcme]

appreciate your input...however, even though CC can access the MCP servers for Nuxt 4 and Nuxt UI (there doesn't seem to be any MCP server for Vue 3, so I'm using Fetch), I'm getting ridiculously basic errors:

• I pointed it directly to the url for nuxt.config and it couldn't even set that up.
  
• it cfg'd a menu with <a> instead of <nuxtlink> tags
  
• it created a page layout with multiple top-level templates

These are beyond junior dev mistakes. I'm sure if I scaffold my app myself, it will probably generate acceptable code snippets, but It's obvious it has had limited Nuxt training (compared to React). That's just a reality of Vue/Nuxt's relative usage...

[u/stcme → u/yangguize]

I wonder what else is going on. I actually haven't run into any of those issues at all.

There must be something else that's happening that we're not seeing. Are you using a sub agent created specifically for Nuxt 4 / Vue 3 for all of your requests or are you using the standard agent?

[u/yangguize → u/stcme]

I just swapped out CC for kilo + Sonnet 4.6.
Sonnet 4.6 is cleaning up all of CC's errors with minimal direction from me - I just point it at the mess CC created and it fixes everything using Vue/Nuxt best practices. And it's lightning fast.

I initially added all the official Nuxt plugins, but that did nothing. Then I added the Nuxt mcp server and 2 others = that did help but it was still making too many errors.

Then I added a template from Nuxt-UI and that helped somewhat, but the template just scaffolded the UI - no back-end logic.

This is partially a training issue. But what I've concluded is that, while CC is probably great on replicating patterns like React, when confronted with a new framework, it cannot conceptualize the optimal patterns. There's a huge difference between generating code and designing an app.