Télécharger
← Blog
Notre journal9 min de lecture

Le problème de granularité dans le GenUI : où la génération par LLM doit-elle s'arrêter ?

Notes issues de la construction du moteur GenUI d'AirJelly — et pourquoi donner plus de liberté au LLM a dégradé le résultat.

Par wanghelan

Translated by AI

Cet article provient de notre exploration pratique du moteur GenUI dans le projet AirJelly. Nous n'avons pas commencé par la théorie. Nous sommes partis d'une expérience honnêtement assez frustrante : pourquoi le résultat s'est-il dégradé lorsque nous avons donné au LLM plus de liberté pour générer l'UI ?

01 · Contexte

Pourquoi le GenUI mérite une attention sérieuse

Avant d'entrer dans les détails, il vaut la peine de clarifier pourquoi le GenUI est un problème d'ingénierie sérieux, et non un simple tour de démonstration. Dans Generative Interfaces for Language Models, l'équipe SALT-NLP / Stanford a comparé les préférences des utilisateurs entre le GenUI et le chat textuel traditionnel. La conclusion est claire : lorsqu'un système d'IA doit communiquer un contenu structuré et dense en informations, une interface générée dynamiquement peut être bien meilleure qu'un mur de texte.

La vague GenUI s'est accélérée entre 2023 et 2025 parce que deux conditions ont mûri en même temps : les LLM sont devenus bien meilleurs en génération de code, et les écosystèmes de composants comme shadcn/ui et Radix sont devenus suffisamment stables pour construire dessus. Une fois ces conditions réunies, des outils ont naturellement émergé — Vercel v0 en est l'une des implémentations industrielles les plus représentatives.

02 · Le point de départ

Nous avons laissé le LLM improviser, et le résultat s'est dégradé

Sur la branche feat/genui-real-content-experiment, nous avons mené une série de comparaisons. L'ancienne approche avait une mise en page fixe et des composants unifiés — soignée et prévisible. La nouvelle approche rendait la mise en page plus flexible, mais le visuel est devenu désordonné et les styles de composants incohérents.

Cela allait à l'encontre de notre intuition. Plus nous donnions de liberté au modèle, moins nous avions de contrôle, et plus la cohérence visuelle se dégradait. L'article Gen-UI-Lang fait le même constat : demandez à un LLM du HTML ou du JSX brut et la sortie est verbeuse, fragile et facile à casser. Ce n'est pas un problème de qualité de prompt — cela signifie que nous avons poussé le LLM à une granularité où il n'est pas à son meilleur.

03 · La tension centrale

Une contradiction structurelle dans le GenUI

À travers l'expérience, nous avons identifié une contradiction interne qui s'applique à pratiquement tout système GenUI.

Plus le LLM a de liberté, plus il est difficile de garantir la cohérence visuelle. Plus les contraintes sont fortes, moins le GenUI a de sens.

Il s'agit d'une tension structurelle du paradigme, pas d'un bug dans une implémentation particulière. Chaque système GenUI doit trouver son équilibre quelque part entre ces deux forces. La question devient donc très concrète : où la frontière de génération du LLM doit-elle s'arrêter ?

04 · Le domaine

Les choix de granularité existants

Avant d'arrêter notre propre réponse, il est utile d'examiner comment d'autres ont abordé la même question.

Vercel v0 — générer jusqu'au code de composant

v0 laisse le LLM descendre jusqu'au bout et générer du code de composant React complet. Sa cohérence visuelle provient du système de tokens sémantiques de shadcn/ui — il externalise la cohérence vers le thème de la bibliothèque. Le coût : la logique de génération devient étroitement couplée à l'écosystème de composants, si bien que sortir de la stack shadcn/ui + Next.js + Vercel crée de vraies frictions.

Une forme typique de code de composant à la v0
<Card className={cn("flex flex-col",
  plan.recommended && "border-primary shadow-lg scale-105"
)}>

L'approche arXiv — une représentation intermédiaire structurée

L'approche SALT-NLP / Stanford insère une représentation intermédiaire structurée entre le langage naturel et le code UI, à deux niveaux : un flux d'interaction de haut niveau (un graphe orienté des parcours utilisateur et des étapes de tâche) et des machines à états finis de bas niveau (les états de chaque composant et les réponses aux événements). La sortie finale reste du HTML, CSS et JavaScript — la représentation est un garde-fou, pas la destination.

Gen-UI-Lang — définir une couche d'intention UI

Gen-UI-Lang conçoit un DSL dédié pour que le LLM ne produise que des descriptions de nœuds structurées. La structure des nœuds est explicite, peu profonde et cohérente — exactement ce que les LLM génèrent de manière fiable. Par rapport à la génération directe de HTML, il rapporte une réduction de 65,3 % de l'usage de tokens tout en améliorant la stabilité, et il peut rendre en HTML, React JSX ou Gradio à partir de la même description.

Une description d'intention UI en Gen-UI-Lang
genui(
  row(
    text("Sales Overview"),
    btn("Load", on_load=lambda: get_graph(2001, 2002))
  ),
  chart(type="line", data="sales_q4"),
)
05 · Notre choix

S'arrêter à la couche de sémantique produit

Les trois approches poussent le LLM vers le haut, loin de la couche de rendu. Elles ne diffèrent que par leur point d'arrêt. Nous avons choisi de nous arrêter plus haut qu'aucune d'elles : à la couche de sémantique produit.

Le LLM ne produit pas de nœuds UI génériques comme row ou btn. Il produit des concepts produit — « ceci est une carte de résumé de tâche, à forte densité d'informations, issue du calendrier du jour. » Quel composant rendre, et comment le disposer, est décidé entièrement par la bibliothèque de composants — pas par le LLM.

01La leçon directe de notre cas d'échec

Dès que nous avons relâché la liberté de génération du LLM, le résultat visuel s'est dégradé. Plus le LLM s'approche de la couche de rendu, plus le coût de son aléa augmente.

02L'analogie avec les moteurs de rendu des navigateurs

Les navigateurs ne laissent pas le JavaScript de la page contrôler directement les pixels. Ils acceptent une description DOM contrôlée, et le moteur décide des pixels. Un moteur GenUI devrait fonctionner de la même manière.

03La fiabilité des sorties structurées des LLM

OpenAI a livré les Structured Outputs en 2024 précisément pour lutter contre la dérive de format. Plus la sortie est proche de la couche de rendu, plus le coût des erreurs de formatage est élevé.

04Le besoin à long terme d'une bibliothèque de composants remplaçable

Arrêtez-vous à la couche de sémantique produit et la bibliothèque de composants devient un backend de rendu enfichable — changez le design system demain sans toucher à la couche sémantique.

06 · Une direction non vérifiée

Génération en deux tours

En déboguant le composant complexe GenUIPager, nous avons constaté qu'une passe unique de LLM avait du mal à optimiser simultanément la qualité du contenu et celle de la mise en page. Cela nous a conduits à une architecture en deux tours — à titre d'hypothèse.

Hypothèse de génération en deux tours
First-round LLM:  content orchestration + page-structure decisions
                  (product semantics layer)
      ↓
Second-round LLM / component library:  concrete rendering decisions

La motivation est raisonnable : l'orchestration du contenu et le rendu sont deux tâches cognitives différentes, et les forcer dans une seule passe peut les faire interférer l'une avec l'autre.

Mais nous devons être honnêtes : ce n'est qu'une hypothèse, et nous ne l'avons pas pleinement validée.

Elle figure ici parce qu'elle indique une direction qui vaut la peine d'être explorée — pas parce qu'il s'agit d'une conclusion établie.

07 · La carte

Une carte des compromis entre choix de granularité

Aucun choix de granularité n'est universellement correct. Il dépend de la tolérance du produit à l'incohérence visuelle, du cycle de vie attendu de la bibliothèque de composants et du degré de structuration du contenu généré.

ApprocheJusqu'où le LLM produitComment la cohérence est garantieBibliothèque remplaçable ?Scénarios adaptés
Vercel v0Couche de code de composantTokens sémantiques shadcn/uiNon, étroitement coupléePrototypage rapide dans l'écosystème Vercel
Gen-UI-LangCouche d'intention UI généraleMoteur de rendu multi-cibleOui, indépendant du frameworkPrototypage multi-framework, workflows axés sur l'efficacité
Approche arXivHTML / CSS / JSReprésentation intermédiaire structurée comme garde-fouCela dépendScénarios à forte complexité d'interaction
AirJellyCouche de sémantique produitLa bibliothèque de composants possède entièrement le renduOui, enfichableApplications à fortes exigences de cohérence de l'UI produit

Si le produit tolère peu l'incohérence visuelle, la granularité doit être plus élevée, plus proche de la sémantique produit. Si la bibliothèque de composants est susceptible d'évoluer ou d'être remplacée, plus élevée encore. Et si le contenu généré est fortement structuré, il est plus approprié de le décrire sémantiquement à un niveau supérieur.

Sources

Sources et lectures complémentaires

Conclusion

La granularité est la décision de conception centrale en GenUI.

Le principal enseignement n'est pas que nous avons trouvé la bonne réponse. C'est que nous avons clarifié la question : GenUI ne consiste pas à laisser le LLM dessiner l'interface. Il s'agit de concevoir une répartition claire des responsabilités entre le LLM et le système de rendu.

Le choix de la granularité détermine où cette frontière est tracée — et l'endroit où la frontière est tracée détermine la maintenabilité du système, sa stabilité visuelle et sa capacité à évoluer sur le long terme.

En octobre 2025, le W3C Design Tokens Community Group a publié la spécification stable Design Tokens 2025.10 — un signe que la séparation de la sémantique et du visuel devient une norme d'ingénierie. Le problème de granularité dans GenUI est cette même tendance qui se manifeste à l'intérieur des interfaces générées par IA.

Nous sommes encore en chemin. Si vous explorez quelque chose de similaire, j'aimerais beaucoup en discuter.

Plus d'articles de l'équipe AirJelly →