Une chose étrange s'est produite l'année dernière.
L'IA est devenue incroyablement douée pour construire des logiciels.
Et pourtant, les produits ont commencé à paraître plus génériques.
Cela semble contradictoire.
Les modèles sont devenus plus intelligents. Les agents se sont améliorés. Les fenêtres de contexte ont explosé. Les développeurs sont devenus nettement plus productifs.
Pourtant, si vous avez passé du temps à parcourir Product Hunt, les lancements d'indie hackers ou les démos de startups IA récemment, vous avez probablement remarqué le même schéma.
Des fondateurs différents.
Des produits différents.
Des secteurs différents.
Mais les interfaces commencent toutes à sembler étrangement familières.
Les mêmes cartes.
Les mêmes tableaux de bord.
Les mêmes mises en page.
La même hiérarchie visuelle.
La même esthétique « SaaS généré par IA ».
Le code fonctionne.
Le frontend ne laisse pas de souvenir.
Et je pense que c'est parce que la plupart des développeurs se concentrent sur un problème qui n'existe plus.
Générer du code.
Aujourd'hui, générer du code est facile.
Générer un frontend qui semble vraiment intentionnel est bien plus difficile.
La plupart des workflows IA modernes ressemblent déjà à ceci :
Claude Code pour la planification.
Cursor pour l'implémentation.
Livrer.
Recommencer.
Et honnêtement, c'est déjà assez puissant pour construire des produits plus rapidement que jamais.
Claude Code est devenu mon outil de prédilection pour raisonner sur l'architecture, décomposer les systèmes et déterminer ce qui doit être construit.
Cursor reste l'un des meilleurs environnements pour transformer ces idées en logiciels fonctionnels.
Aucun des deux outils n'est le problème.
En fait, ils sont la raison pour laquelle la création de logiciels est devenue si ridiculement rapide.
Le problème commence après que le code est généré.
C'est là que la qualité du frontend devient un défi complètement différent.
Plus j'examinais de produits, plus je réalisais que l'écart entre un produit fonctionnel et un excellent produit n'est plus rarement la fonctionnalité.
C'est le raffinement.
C'est la cohérence.
Ce sont les décisions de conception.
C'est le contexte.
Et c'est exactement pourquoi je me suis intéressé aux workflows natifs du frontend.
Quand j'ai vu ce workflow visualisé pour la première fois, il capturait parfaitement comment j'ai commencé à penser au développement IA moderne.
Claude m'aide à réfléchir.
Cursor m'aide à construire.
Mais il manque encore une couche entre « logiciel fonctionnel » et « produit prêt pour la production ».
C'est la couche que Kombai essaie de résoudre.
Pas en remplaçant l'un ou l'autre outil.
En comblant un fossé qu'aucun d'eux n'a été conçu pour résoudre.
La façon la plus simple d'expliquer cela est avec une question simple :
Pourquoi les frontends générés par IA semblent-ils encore générés par IA ?
Pas tous.
Mais assez pour que vous puissiez généralement en repérer un en quelques secondes.
Ce n'est rarement parce que le code est mauvais.
Le problème est généralement bien plus profond.
La plupart des outils IA comprennent les prompts.
Les ingénieurs frontend comprennent les systèmes.
Cette distinction semble mineure.
Elle ne l'est pas.
Un ingénieur frontend senior ne regarde pas un bouton et ne pense pas :
« C'est un bouton. »
Il pense :
Quel composant est-ce ?
Quel token de design l'alimente ?
Cela existe-t-il déjà ailleurs ?
Cela suit-il l'échelle typographique ?
Cela appartient-il au système de design ?
Ce motif est-il réutilisable ?
Ces questions sont ce qui crée la cohérence.
Et la cohérence est ce qui crée la qualité.
Les meilleurs frontends ne sont pas des collections de composants.
Ce sont des collections de décisions.
Et ces décisions s'accumulent avec le temps.
C'est là que, je pense, la plupart des workflows IA échouent aujourd'hui.
La version générée fonctionne souvent.
La version prête pour la production semble intentionnelle.
La version générée coche les cases.
La version prête pour la production construit la confiance.
Et la différence entre ces deux résultats n'est généralement pas plus de code.
C'est plus de contexte.
- Design Mode : Commencer par l'interface, pas par l'implémentation
Tous les projets frontend que j'ai construits avec des outils IA ont commencé de la même manière : prompt → code → rafraîchir → recommencer.
Le Design Mode de Kombai inverse complètement cela.
Au lieu de commencer par l'implémentation, vous commencez par l'interface elle-même. Vous travaillez sur un canevas infini — esquisser des mises en page, itérer sur des composants, ajuster des décisions visuelles — avec une IA qui a un véritable goût créatif intégré.
Le résultat ne ressemble pas à un starter Tailwind par défaut. Il ne ressemble pas à un modèle shadcn. Il ressemble à quelque chose qui a été conçu.
Ce qui rend cela important : les designs ne sont pas déconnectés de votre codebase. Ils vivent dans votre dépôt.
Ce qui mène à la chose suivante qui m'a vraiment surpris.
- La synchronisation à quatre voies qui change tout
La plupart des workflows IA ont un mur solide entre le design et le code.
Vous concevez quelque part (Figma, v0, peu importe). Vous implémentez ailleurs (Cursor, Claude Code). Et ensuite vous vivez à l'intérieur de cette deuxième couche pour toujours, en effectuant des modifications en éditant des fichiers et en rafraîchissant les navigateurs.
Kombai brise ce mur — dans les quatre directions.
Vos designs, votre code et votre UI rendue vivent tous ensemble dans votre dépôt et votre IDE. Vous pouvez modifier n'importe lequel d'entre eux. Les autres sont mis à jour en un clic.
Voici ce que cela signifie concrètement :
Designs sur le canevas → Code dans votre dépôt
Votre canevas et vos designs sont créés en tant que code et vivent dans votre dépôt. Vous pouvez donc les référencer directement dans les prompts en utilisant @, extraire leur contexte dans n'importe quelle tâche et générer du code de qualité production directement à partir d'eux. Vous voulez créer un nouveau composant à partir d'un élément de votre design ? Pointez l'agent dessus. Vous voulez mettre à jour vos tokens pour correspondre à un nouveau design ? Un prompt.
Code dans votre dépôt → Designs sur le canevas
Le Design Mode de Kombai a un contexte complet de votre dépôt à tout moment. Vous pouvez donc aller dans l'autre direction aussi — utiliser votre code existant pour créer de nouveaux designs. Vous voulez créer des variations de votre carrousel de produits ? Demandez-lui de copier ce composant sur un canevas et de générer des versions créatives. Vous voulez concevoir l'état agrandi d'une modale qui existe déjà dans votre codebase ? Il sait déjà à quoi ressemble la modale.
Modifier l'UI rendue dans le navigateur → Code dans votre dépôt
Ouvrez n'importe quelle partie de votre application en cours d'exécution dans le navigateur Kombai. Modifiez le texte, les styles et la mise en page visuellement — exactement comme vous le feriez dans un outil de design. Envoyez ensuite ces modifications à l'agent en un clic et il les implémente dans votre code réel. Plus de changement de contexte entre le navigateur, l'inspecteur et l'éditeur de code. Vous le voyez, vous le corrigez, c'est fait.
UI rendue dans le navigateur → Designs sur le canevas
Utilisez la fonction de capture web pour envoyer n'importe quelle partie de votre UI en direct directement sur votre canevas de design. Fonctionne pour les pages tournant sur localhost et les URLs externes en dehors de votre dépôt. À partir de là, vous pouvez itérer dessus, générer des variations ou les utiliser comme inspiration en les référençant dans des prompts.
Ce n'est pas un tour de démo. C'est un modèle mental fondamentalement différent pour le travail frontend.
Au lieu de « code → rafraîchir → inspecter → recommencer », vous travaillez sur trois vues de la même vérité — et vous pouvez entrer et sortir de n'importe laquelle d'entre elles.
La boucle de rétroaction devient considérablement plus courte. Et lorsque vous prenez des dizaines de décisions frontend chaque jour, cela s'accumule rapidement.
- Du code de qualité production qui réutilise réellement votre système existant
L'une des idées les plus intéressantes à l'intérieur de Kombai est quelque chose qui semble simple mais qui est profond.
Il comprend votre stack avant de générer quoi que ce soit.
Voici ce que la plupart des frontends générés par IA font de travers.
Ils génèrent de nouveaux composants alors que des composants existants existent déjà. Ils créent de nouveaux tokens alors que le système de design en a déjà. Ils ajoutent de l'incohérence — lentement, invisiblement — jusqu'à ce que la codebase commence à sembler avoir été construite par cinq équipes différentes.
Kombai regarde d'abord vos composants, hooks et tokens existants. Ensuite, il réutilise ce qui est déjà là.
Un ingénieur frontend senior ne se contente pas d'écrire du nouveau code. Il demande : cela existe-t-il déjà ? Devrais-je réutiliser quelque chose ? Cela suit-il le modèle que nous avons établi ?
C'est la réflexion que Kombai essaie d'encoder.
Ce visuel l'explique probablement mieux que n'importe quelle page marketing.
La plupart des outils IA voient des instructions.
Kombai essaie de comprendre l'environnement dans lequel ces instructions vivent.
Et cette différence devient de plus en plus précieuse à mesure que les projets deviennent plus grands.
Parce que plus personne n'a de mal à générer un composant.
Le défi est de générer le centième composant sans casser la cohérence.
Le défi est d'ajouter de nouvelles fonctionnalités sans dégrader lentement le système de design.
Le défi est de faire évoluer la qualité du frontend tout en allant vite.
C'est là que le contexte devient un avantage concurrentiel.
La stack complète que j'utilise actuellement
Voici comment les trois outils répartissent réellement le travail :
Claude Code → Architecture, planification, raisonnement sur quoi construire et pourquoi.
Cursor → Implémentation, transformer les plans en logiciels fonctionnels.
Kombai → Design, raffinement du frontend et maintien de la cohérence de l'interface à mesure que le projet évolue.
Chaque couche a un travail clair. Aucune d'elles n'essaie de remplacer les autres.
La plus grande réalisation que j'ai eue l'année dernière est que le futur n'appartient probablement pas à un seul outil IA.
Il appartient aux stacks IA.
Des outils spécialisés résolvant des problèmes spécialisés. Chaque couche faisant ce pour quoi elle a été construite.
Claude Code n'essaie pas de devenir Figma. Cursor n'essaie pas de devenir un système de design. Et Kombai n'essaie pas de devenir un assistant de codage polyvalent.
Les workflows les plus forts se produisent lorsque chaque couche a une responsabilité claire.
Un outil vous aide à raisonner.
Un outil vous aide à implémenter.
Un outil vous aide à raffiner.
Et ensemble, le résultat devient bien meilleur que n'importe quel outil individuel travaillant seul.
Cette image capture parfaitement la distinction.
Construire et peaufiner sont des compétences différentes.
Construire fait fonctionner le logiciel. Peaufiner fait que les utilisateurs lui font confiance.
Construire crée la fonctionnalité. Peaufiner crée l'expérience.
Construire amène les gens à essayer le produit. Peaufiner les fait revenir.
Pendant des années, le peaufinage était coûteux car il nécessitait des talents frontend hautement spécialisés.
L'IA commence à changer cela.
Pas en remplaçant les ingénieurs frontend.
Mais en rendant le contexte frontend plus accessible.
C'est finalement pourquoi Kombai a attiré mon attention.
Pas parce qu'il génère du code. Tous les outils IA génèrent du code maintenant.
Pas parce qu'il remplace Cursor. Il ne le fait pas.
Pas parce qu'il remplace Claude Code. Il ne devrait pas.
La partie intéressante est qu'il se concentre sur une couche du développement logiciel que la plupart des outils IA ignorent largement.
Le contexte frontend.
Et à mesure que les logiciels générés par IA deviennent la norme, le contexte pourrait devenir l'un des actifs les plus précieux de l'ensemble du workflow.
Si je devais résumer mon workflow actuel en une phrase, ce serait celle-ci :
Claude Code m'aide à réfléchir.
Cursor m'aide à construire.
Kombai aide le frontend à se sentir intentionnel.
Et le plus grand changement qui se produit dans le logiciel en ce moment n'est pas que l'IA devient meilleure pour écrire du code.
C'est que nous réalisons enfin que le code n'a jamais été l'intégralité du travail.
Les produits sont des systèmes.
Les interfaces sont des systèmes.
Le design est un système.
La qualité du frontend est un système.
Et les outils qui gagneront dans les prochaines années ne seront probablement pas ceux qui génèrent le plus de code.
Ce seront ceux qui comprennent le plus de contexte.
C'est pourquoi je m'intéresse de plus en plus aux workflows natifs du frontend.
Pas parce qu'ils remplacent le reste de la stack.
Mais parce qu'ils font fonctionner l'ensemble de la stack mieux ensemble.
Et dans un monde où tout le monde peut générer des logiciels, cette différence pourrait finalement compter plus que jamais.
Essayez Kombai maintenant : https://kombai.com/
