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!
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?
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.
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.
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 ")
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.
Ok, if I were to examine the most common areas where applications and projects go wrong with Vaadin using LLMs, for me they are:
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.
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.
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.