What's your biggest problem doing agentic coding with Vaadin?

Hello everybody who use AI agents to write Vaadin code! I have two questions for you:

  • What is the biggest problem you tend to run into, with or without the MCP and/or Skills?
  • Is there anything in particular you think is missing and you would like to see us add?

-Petter-

1 Like

Here is my minimal getting started prompt. No MCP or skills, but just relying on “internet knowledge”:

Create a minimal Vaadin app from this screenshot with stack: Vaadin 25.1, Java 25 and Maven, Spring Boot 4. Constraints:
  * Use as pom.xml:  https://github.com/vaadin/skeleton-starter-flow-spring/blob/v25.1/pom.xml                                                                                           
  * use only stock Vaadin components                                                                     
  * minimal code with no styling  and no AppShellConfigurator                                                                       
  * code must compile and run with mvn spring-boot:run 

The part that feels bit hacky is that I’m basically I’m augmenting the models with the AppShellConfigurator and pom.xml which are likely go wrong otherwise.

But beyond those you get a nice Vaadin simple app start from any screenshot in your OpenCode! :slight_smile:

I have no issues, but I always scaffold the application with my own archetype.

The problem when starting the app with the agent you may get outdated version and especially outdated Spring Security configuration.

That’s good to hear. How is the experience in terms of e.g. speed and token usage? Is there something that takes too much time, or too many turns for the agent to get right?

-Petter-

One thing that I have to specify each time is to create reusable design components intead of dumping everything in one large java view class.

I noticed that it has a tendency to overuse vertical/horizontal layouts in situations where a Div with a display grid would be better.

The CSS that claude opus generates - I find it does not make good use of the available --vaadin-* css properties. For almost all scenarios it tries to add a classname and write some css where overriding property values would have been sufficient and cleaner.

1 Like

No. All works very well. I’m using Claude Code in four Vaadin customer projects at the moment.
I really think that Vaadin is a great fit for AI-driven development.

One thing I find annoying is that unless I’m explicit about version numbers, I tend to get the first relevant major release, e.g. 25.0.0, which I never want and usually don’t notice until it later when it’s less convenient to switch.

Really? Don’t you use the MCP server? Because the primer returns the latest version.

Which agent with which model are you using?

Yes, I use the MCP server, with Claude Code. It happens occasionally regardless.

So I assume you create the project with Cloud Code?

I never do that because scaffolding the project is part of the harness, and I want full control.

Yes; I often need either throwaway projects of testing specific things in isolation, or the UI layer is sort of a side track ("create a Vaadin 25 UI with a single view to show this data in a Grid with filtering by year and author ")

I always start my project with https://start.spring.io

AI never knows the most recent version

1 Like

A couple of thoughts:

  • Improve scaffolding instructions: I know that there are good ways of kickstarting projects, like start.vaadin.com or start.spring.io, but eventually somebody will try to create a new Vaadin project from zero using the mcp, and I see that sometimes the agent will write the whole application from zero (write the pom, etc.) instead of doing something more “clever” like using the maven archetype or the vaadin cli if it still exists.
  • Improve mcp documentation: The site mcp.vaadin.com is not covering all installation methods. I tried to configure it in claude desktop, and that is not the same as claude code (ie: in MacOS you have to modify the file ~/Library/Application Support/Claude/claude_desktop_config.json). I know that everything changes almost every week, but it doesn’t hurt to run an update every now and then.
1 Like

I’d say agents not following the established implementation patterns.

Well that’s a matter of the harness.

The LLM is just one piece in the puzzle.
Guidelines and guardrails are very important to get consistent code

Ok, if I were to examine the most common areas where applications and projects go wrong with Vaadin using LLMs, for me they are:

  1. Layout problems. There are always some weird overlapping things and overflows with any more complicated UI. Resulting in unnecessary loops. Happens also with Vaadin MCP.
  2. Usage of Element API and CSS in applications. This should not be the default. CSS should be in CSS files and Java code should be generic UI semantics. Also Element API is intended as shortcut only used inside components.
  3. Related to previous: Choosing the right component architecture. I’ve written about this a few times. The real power of Vaadin is that it let’s you have separation of concerns inside your components. This keeps application code very portable. LLMs seem to ignore architectural ideas quite lightly.

Would love to hear if aura-theme skill improves this at all. It’s made for global configuration of Aura, but it should point the AI to right direction regarding styling components as well.

1 Like

Good point about the skills! They are not mentioned anywhere as far as I can see. Only the MCP server is promoted.

But if you install the plugin in Claude Code the MCP server is configured automatically!