Por Qué Seguimos Creando Add‑ons en la Era de la IA

Si hoy le pedimos a la IA que nos cree un componente para Vaadin, seguramente en pocos minutos tengamos algo que compila, se renderiza y hasta se ve bien. Entonces surge la pregunta: si cualquiera puede generar rápidamente un componente con ayuda de la IA, ¿por qué seguimos creando, publicando y manteniendo add-ons?

Hace tiempo que me hago esa pregunta. Uso Claude todos los días, creé un add-on con su ayuda en tiempo récord y migré una aplicación de 8 años. Y aun así, mi respuesta es que los add-ons importan más ahora, no menos. Te cuento por qué.

Crear se volvió más rápido. Mantener, no.

La IA redujo muchísimo el tiempo que lleva construir la primera versión de un componente. Leer la documentación de la librería original, mapear atributos a una API en Java, escribir una primera demo: lo que antes llevaba días, ahora lleva horas.

Pero la primera versión nunca fue la parte difícil.

En Flowing Code mantenemos más de 30 add-ons en el Vaadin Directory. El verdadero trabajo empieza después del primer release, y en realidad nunca termina:

• Nuevas versiones de Vaadin. Cada versión mayor trae breaking changes, y hasta las menores traen deprecaciones. Muchos de nuestros add-ons soportan varias versiones de Vaadin en el mismo código base, así que cada cambio tiene que funcionar, y probarse, en todas ellas.
• Temas. Con Vaadin 25 ya no alcanza con soportar Lumo: nuestros add-ons también tienen que verse bien con Aura. Ahí aparecen detalles como un badge que se achica a 2 píxeles o un menú de overflow que ignora el tema, y solo los encuentra alguien que mira el componente con cada tema.
• Cambios en las librerías originales. Algunos add-ons son wrappers de una librería JavaScript o de un Web Component. Cuando esa librería cambia, el wrapper tiene que acompañarla.
• Tests, demos y documentación. Un componente que nadie puede probar ni entender es un componente que nadie adopta. Las demos tienen que seguir funcionando y la documentación tiene que coincidir con la API actual.
• Issues y pull requests. Los usuarios reales encuentran casos reales, y alguien tiene que responder, reproducir y corregir.

Un ejemplo reciente: Vaadin 25.2 empezó a advertir que los add-ons que tienen sus archivos de frontend en META-INF/resources/frontend/ están usando una ubicación deprecada. Hoy no se rompe nada, pero los archivos se tienen que mover. Parece un cambio chico, hasta que haces la cuenta: más de 20 de nuestros repositorios estaban afectados. En cada uno hay que mover los archivos, revisar el jar generado y verificar la demo, y el cambio todavía tiene que llegar a los usuarios con el próximo release de cada add-on. Una sola línea en un log se convierte en un proyecto en sí mismo.

Nada de esto es glamoroso, y nada de esto aparece cuando generas un componente en una ventana de chat.

Un componente generado es un snapshot. Un add-on es un compromiso.

Lo que obtienes con un add-on mantenido

Cuando un equipo suma uno de nuestros add-ons a su proyecto, no está obteniendo solo código. Está obteniendo:

• Continuidad. El componente sigue funcionando cuando actualizan Vaadin, porque ese trabajo ya lo hicimos nosotros.
• Un contrato probado. La API fue revisada y usada en proyectos reales, y mejora con cada caso borde que alguien encuentra. Por ejemplo, nuestro add-on RelativeTime rechaza una zona horaria inválida con un error claro, donde el Web Component original mostraría algo incorrecto sin avisar. Ese conocimiento queda en el add-on, y lo aprovechan todos los que lo usan.
• Correcciones compartidas. Cuando un usuario reporta un bug, todos se benefician de la corrección. Un componente generado dentro de un proyecto corrige sus bugs solo para ese proyecto, si es que los corrige.
• Alguien a quien preguntar. Issues, discusiones y un equipo que conoce el código.

Un componente generado le pasa toda esa responsabilidad a quien lo generó. Es una elección perfectamente válida para una necesidad puntual. Es mucho más difícil de sostener para un componente que tiene que vivir durante años dentro de una aplicación empresarial, que, como escribí en Por Qué Vaadin Sigue Siendo Relevante en 2026, es justamente el tipo de aplicación para el que está pensado Vaadin.

Cuando Vaadin te alcanza

A veces el desafío no es un bug ni una versión nueva, sino que Vaadin incorpora algo muy parecido a lo que ya ofrece tu add-on.

Cuando Vaadin 25.3 sumó un componente Switch al core, nuestro add-on ToggleButton de repente tuvo una alternativa oficial que hacía casi lo mismo. Podíamos deprecarlo, dejarlo como estaba o reconstruirlo sobre el nuevo componente del core. Elegimos la última opción, y conté toda la historia en Cuando Vaadin Implementa tu Add-on: Qué Hicimos con Toggle Button.

Lo importante aquí no es qué opción elegimos. Es que alguien tuvo que tomar esa decisión y darles un camino claro a quienes ya usaban el add-on. Un componente generado hace un año en el proyecto de alguien no recibe esa decisión. Simplemente se va quedando atrás, sin que nadie lo note.

Cuando generar es la decisión correcta

Para ser justos, no todo componente necesita ser un add-on. Si necesitas algo chico, para un solo proyecto, que nadie más va a usar y que estás dispuesto a mantener por tu cuenta, generarlo probablemente sea la decisión correcta. Convertirlo en un add-on, con su propio repositorio, demo y ciclo de releases, sería exagerado.

La línea no la marca qué tan difícil es construir el componente. La marca cuánto tiempo tiene que vivir y cuánta gente depende de él. Cuanto más larga su vida y más amplio su público, más importa el mantenimiento, y más vale un add-on mantenido.

La IA no es la competencia. Es parte de cómo mantenemos.

Y aquí viene el giro: la misma IA que hace tan rápido crear componentes es la que hace sostenible que un equipo chico mantenga decenas de ellos.

La mayor parte del trabajo de mantenimiento es repetitivo. El mismo tipo de cambio, aplicado en muchos repositorios, siguiendo las mismas convenciones cada vez. Ahí es justamente donde la IA brilla, siempre que le enseñes cómo trabaja tu equipo.

Eso es lo que venimos haciendo con las skills de Claude Code: empaquetar nuestras convenciones y tareas repetitivas para que Claude las aplique siempre igual, mientras las decisiones siguen siendo nuestras. Voy a contar esa historia en detalle en el próximo post, incluido lo que salió mal la primera vez.

Conclusión

La IA hizo mucho más rápido construir componentes, pero no cambió lo que hace que uno sea confiable: alguien que lo mantenga funcionando, lo pruebe, lo documente y responda cuando algo se rompe.

Por eso seguimos creando add-ons. No a pesar de la IA, sino con ella.

Gracias por leernos ¡and let’s keep the code flowing!