Voici comment je ressens le codage par ambiance. Tout projet que j'essaie et qui présente une certaine complication connaît immédiatement une poussée de progrès. Les choses sont incroyables et on a l'impression d'avoir un super pouvoir. Puis... à mesure que j'ajoute plus de complexité, tout s'arrête net. Les seuls projets que je pense pouvoir créer sont ceux qui tombent dans cette "zone d'ambiance". Prototypes, interfaces utilisateur, produits—tout ce qui est simple et a une faible complexité s'inscrit parfaitement dans cette zone. Preuves de concept, interactions, des choses comme ça. Les outils sont capables de créer des choses qui s'insèrent dans cet espace. Mais. Tout s'effondre à mesure que cette courbe de complexité augmente. Et le problème est que tout bon processus de conception de produit a une complexité croissante. Un prototype de base devient un bon prototype dès qu'il a des interactions superposées, des transitions, de bonnes affordances, des états de survol, 1000 petits détails qui font qu'une chose semble correcte et réelle. Le bénéfice du codage par ambiance est censé être que vous avancez rapidement et que vous pouvez produire des choses—laissant l'IA faire tout le travail pour vous. Le problème est qu'il perd de son élan dès que la complexité nécessaire est ajoutée. Il continue à se réécrire, à réécrire du code, à affecter des choses qui ne sont pas liées et à provoquer d'autres problèmes. Mais si vous ajoutez cette complexité, chaque session de codage par ambiance se transforme rapidement en une session de chasse aux bogues de type whack-a-mole. Je ne suis pas sûr de la solution à cela. Avec le prototypage traditionnel, la solution consiste à dupliquer, ajouter plus de complexité, créer plus de cadres/scènes, ajuster, forker, etc. Cependant, avec le codage par ambiance, une petite invite peut détruire littéralement tout. Il y a une étape où je me retrouve à marcher sur des œufs d'invite—essayant de ne pas lui donner trop ou trop peu de contexte pour qu'il ne devienne pas fou et ne casse pas tout. Il n'y a que quelques exceptions à cela. @cursor et @framer. Je peux faire de grands progrès avec Cursor, lui donner un contexte étroit, et je dois approuver les modifications qu'il apporte. Cela ressemble à un flux de travail correct. Le problème est que je ne peux pas voir ce qu'il crée parce que c'est un IDE, pas un environnement visuel. Oui, je peux créer des builds locaux et rafraîchir mon navigateur et tout ce genre de choses. Mais l'aspect visuel est totalement perdu dans l'expérience de codage. C'est un outil pour développeurs. Framer réussit cela parce qu'il ne permet que des mises à jour étroites au sein d'un seul composant sur la page. Oui, c'est limitant car il ne peut faire qu'une seule chose à la fois, mais au moins il n'essaie pas de créer toute la page à partir de zéro et de tout gérer via une interface d'invite. Cela semble être la bonne approche. @Cursor : Permettre à l'IA de modifier quoi que ce soit mais permettre à l'utilisateur d'approuver ces modifications et de les voir dans leur contexte. @Framer : Permettre à l'IA de ne modifier qu'un seul fichier ou composant de manière étroite pour maintenir la complexité au minimum et réduire les modifications catastrophiques. Je suis optimiste quant à ce que des outils comme @Figma, @Lovable, @Bolt et @V0 peuvent créer de cool prototypes, mais je me heurte sans cesse à des murs quand il s'agit de faire quoi que ce soit de plus qu'un simple prototype d'interaction de base. Ils doivent faire moins à mon avis. J'espère que ces outils ajouteront plus de contrôles qui sont dans la même lignée que Cursor et Framer. Je vais également ajouter que c'est similaire à la façon dont nous le faisons avec la génération de graphiques @Basedash aussi. Mais nous ne sommes pas un outil d'ambiance au sens normal, donc les parallèles sont un peu plus difficiles à établir.