Why We Still Build Add‑ons in the Age of AI

Ask an AI assistant for a Vaadin component today and, a few minutes later, you will probably have something that compiles, renders and even looks good. So it is fair to ask: if anyone can quickly generate a component with the help of AI, why do we keep building, publishing and maintaining add-ons?

I have been asking myself that question for a while. I use Claude every day, I have built an add-on with it in record time, and I have migrated an 8-year-old application with its help. And still, my answer is that add-ons matter more now, not less. Here is why.

Creating got faster. Maintaining did not.

AI has dramatically reduced the time it takes to build the first version of a component. Reading the upstream documentation, mapping attributes to a Java API, writing a first demo: what used to take days now takes hours.

But the first version was never the hard part.

At Flowing Code we maintain more than 30 add-ons in the Vaadin Directory. The real work starts after the first release, and it never really stops:

• New Vaadin versions. Every major version brings breaking changes, and even minor versions bring deprecations. Many of our add-ons support several Vaadin versions from the same codebase, in some cases going back to much older ones, so every change has to work, and be tested, on all of them.
• Themes. With Vaadin 25, supporting Lumo is no longer enough; our add-ons also have to look right with Aura. That is where details like a badge collapsing to 2 pixels or an overflow menu ignoring the theme show up, and only someone who looks at the component with every theme finds them.
• Upstream changes. Some add-ons wrap a JavaScript library or a Web Component. When that library changes, the wrapper has to follow.
• Tests, demos and documentation. A component nobody can try or understand is a component nobody adopts. Demos have to keep working, and docs have to match the current API.
• Issues and pull requests. Real users find real edge cases, and somebody has to answer, reproduce and fix them.

A recent example: Vaadin 25.2 started warning that add-ons keeping their frontend files in META-INF/resources/frontend/ are using a deprecated location. Nothing breaks today, but the files have to move. It sounds like a small change, until you count: more than 20 of our repositories were affected. Each one needs the files moved, the packaged jar checked and the demo verified, and the change still has to reach users through each add-on’s next release. A single line in a log turns into a project of its own.

None of this is glamorous, and none of it shows up when you generate a component in a chat window.

A generated component is a snapshot. An add-on is a commitment.

What you get from a maintained add-on

When a team adds one of our add-ons to their project, they are not just getting code. They are getting:

• Continuity. The component keeps working when they upgrade Vaadin, because we already did that work.
• A tested contract. The API has been reviewed and used in real projects, and it gets better with every edge case someone finds. For example, our RelativeTime add-on rejects an invalid time zone with a clear error, where the underlying web component would silently render the wrong thing. That knowledge stays in the add-on, and every user benefits from it.
• Shared fixes. When one user reports a bug, every user benefits from the fix. A component generated inside one project fixes its bugs only for that project, if at all.
• Someone to ask. Issues, discussions and a team that knows the code.

A generated component moves all of that responsibility to whoever generated it. That is a perfectly valid choice for a one-off need. It is a much harder one for a component that has to live inside an enterprise application for years, which, as I wrote in Why Vaadin Still Matters in 2026, is exactly the kind of application Vaadin is built for.

When Vaadin catches up

Sometimes the challenge is not a bug or a new version, but Vaadin itself adding something very similar to what your add-on already offers.

When Vaadin 25.3 added a Switch component to the core, our ToggleButton add-on suddenly had an official alternative that did almost the same thing. We could have deprecated it, kept it as it was, or rebuilt it on top of the new core component. We chose the last option, and I told the whole story in When Vaadin Ships Your Add-on: What We Did with Toggle Button.

The point here is not which option we picked. It is that someone had to make that decision, and give the people already using the add-on a clear way forward. A component generated a year ago in somebody’s project doesn’t get that decision. It just quietly falls behind.

When generating is the right call

To be fair, not every component needs to be an add-on. If you need something small, for a single project, that nobody else will use and that you are happy to maintain yourself, generating it is probably the right call. Wrapping it as an add-on, with its own repository, demo and release cycle, would be overkill.

The line is not about how hard the component is to build. It is about how long it has to live, and how many people depend on it. The longer the life and the wider the audience, the more the maintenance matters, and the more a maintained add-on is worth.

AI is not the competition. It is part of how we maintain.

Here is the twist: the same AI that makes creating components so fast is what makes it sustainable for a small team to maintain dozens of them.

Most maintenance work is repetitive. The same kind of change, applied across many repositories, following the same conventions every time. That is exactly where AI shines, as long as you teach it how your team works.

That is what we have been doing with Claude Code skills: packaging our conventions and repetitive tasks so Claude can apply them consistently, while we keep the decisions. I will tell that story in detail in the next post, including what went wrong the first time.

Conclusion

AI made building components much faster, but it did not change what makes one trustworthy: someone who keeps it working, tests it, documents it and answers when something breaks.

That is why we still build add-ons. Not despite AI, but with it.

Thanks for reading, and let’s keep the code flowing!