Ceci est le premier article d'une série sur les mises à jour de la version V3 de Caffeine. Cet article présentera la nouvelle architecture de construction. Dans le prochain article : comment le système de design de V3 crée des applis plus esthétiques.
Si tu as déjà rencontré Caffeine qui, après 50 modifications, a oublié à quoi ressemblait ton appli à l'origine, voici pourquoi ça s'est produit et pourquoi ça ne se reproduira plus à l'avenir.
Dans la version V3, nous avons complètement refondu la manière dont Caffeine construit les applis. Avant, Caffeine utilisait un pipeline séquentiel, essentiellement composé d'une série de proxies qui s'exécutent les uns après les autres : planification de l'appli, construction du backend, construction du frontend, exécution des contrôles de qualité, déploiement. Chaque étape doit être complétée pour commencer la suivante. Si la troisième étape détecte un problème dans la seconde, il n'est pas possible de faire marche arrière.
Cette méthode fonctionne bien pour des applications simples, mais à mesure que l'échelle du projet augmente (plus de pages, plus de fonctionnalités, plus d'itérations), le processus commence à rencontrer des goulets d'étranglement, la fenêtre contextuelle est saturée, les décisions prises tôt sont ignorées, et la qualité diminue.
La V3 a remplacé l'ancien processus séquentiel par une équipe composée d'agents professionnels, qui travaillent en parallèle à travers plusieurs cycles d'itération et transmettent les résultats d'apprentissage entre chaque cycle, tout cela étant coordonné par un orchestrateur que nous appelons 'Composer'. Vous pouvez le comprendre ainsi : vous n'avez plus besoin de compter sur une seule personne pour tout faire, mais sur une entreprise pour vous servir.
D'un agent à une équipe.
Composer ne lit ni n'écrit de code. Son rôle est de décomposer votre demande en plusieurs tâches, de les attribuer aux experts appropriés, de recueillir les résultats et de décider de la prochaine étape à suivre. Le travail réel est effectué par des experts :
Un agent de Discovery scannera votre projet pour comprendre avec précision son état avant que des changements ne se produisent.
Le chargé de produit traduira vos besoins en exigences structurées pour l'ensemble de l'équipe.
L'agent de design créera un système visuel (marques de couleur, polices, guides de mise en page), toutes les décisions du frontend suivront ce système.
L'ingénieur frontend écrira du code React, plusieurs morceaux de code React peuvent s'exécuter en parallèle pour différentes pages.
L'ingénieur backend écrira du code Motoko pour l'ordinateur Internet.
Le personnel d'assurance qualité examinera le code et effectuera des tests visuels.
Lorsque vous demandez à Caffeine de construire quelque chose, Composer prend le relais en arrière-plan. Pendant le processus de construction, vous pouvez continuer à discuter, ajouter du contexte, changer de direction ou arrêter complètement la construction si nécessaire.
Vagues : comment l'équipe s'accorde.
Composer organise le travail en flux en vagues, où des tâches indépendantes s'exécutent en parallèle dans chaque flux en vagues et les résultats sont transmis successivement entre les flux.
Le processus de développement typique est le suivant :
Première vague - Phase d'exploration scannant le projet, l'agent produit génère des spécifications.
Deuxième vague - L'équipe de design crée l'identité visuelle, le backend écrit les contrats API, les deux se déroulant simultanément.
Troisième vague - Le frontend utilise les tokens de design de la vague précédente et les contrats backend pour construire la structure de l'application.
Quatrième vague - Si l'application a plusieurs pages indépendantes, elles sont construites en parallèle (chaque page étant construite par un agent frontend distinct).
Cinquième vague - Revue de qualité selon les exigences initiales et inspection visuelle.
Déploiement.
L'essentiel réside dans les changements entre les cycles d'itération. Chaque expert renvoie un résultat structuré : ce qu'il a construit (pour que les agents en aval comprennent les ressources disponibles), ce qu'il a appris au cours du processus, et quels problèmes non résolus ont été découverts. Ces informations sont continuellement transmises, de sorte que chaque itération dispose d'un contexte plus riche que la précédente, et les résultats d'apprentissage continuent de s'accumuler au cours du processus de construction, rendant le système de plus en plus intelligent avec le temps.
Cela apporte deux caractéristiques que l'ancien processus n'avait pas : la parallélisation, ce qui signifie que pendant chaque cycle d'itération, des tâches indépendantes (design, backend, plusieurs pages, etc.) peuvent fonctionner simultanément, alors que l'ancien processus ne pouvait exécuter qu'une tâche à la fois, et l'itération, Composer peut exécuter autant de cycles d'itération que nécessaire. Si le frontend découvre qu'il doit apporter des modifications au backend, l'ingénieur backend sera de nouveau envoyé pour s'en occuper. Si l'audit qualité détecte des problèmes, un autre cycle d'itération sera ajouté pour les corriger, tandis que l'ancien processus ne pouvait fonctionner qu'une seule fois, de bout en bout.
Ce n'est pas à chaque fois que chaque changement nécessite toute l'équipe. Si vous avez juste quelques demandes ciblées, comme changer la couleur ou modifier le titre, Composer le comprendra et enverra directement un agent unique, sautant le processus de développement complet. Les fonctionnalités complexes passeront par le processus de développement complet, tandis que les corrections rapides prendront un chemin accéléré.
Chaque construction apporte un tout nouveau contexte.
Chaque construction commence de zéro, même si c'est juste pour ajuster un titre, Caffeine recommencera à vérifier le projet depuis le début avant d'apporter des modifications, c'est intentionnel : le modèle d'intelligence artificielle fonctionne mieux lorsqu'il n'est pas influencé par des accumulations de sessions précédentes.
Ce qui est réellement conservé entre les différentes versions est un fichier léger de préférences et d'accumulation d'expérience, c'est des métadonnées sur la façon d'utiliser le projet, et non un instantané du projet lui-même. Un projet avec 50 fichiers et 700 versions de brouillon fonctionne aussi efficacement qu'un tout nouveau projet. En réalité, Caffeine enregistre au fil du temps quelles méthodes fonctionnent pour votre projet spécifique, donc chaque construction est plus raffinée que la précédente, ce qui est en totale opposition avec votre expérience antérieure.
Vous pouvez maintenant voir ce qui se passe.
Dans la version V2, vous envoyez un message et voyez le message 'Construction de votre application...' puis vous devez attendre. Pour des applications complexes, cela peut signifier plusieurs minutes de silence, et vous ne pouvez pas savoir ce qui se passe ni évaluer si tout va bien.
La version V3 affichera en temps réel le processus de construction, la liste des tâches affichera chaque travail prévu par Composer, et affichera des indicateurs d'état lorsque les tâches sont terminées, échouées ou sautées. Un résumé d'avancement expliquera le travail actuellement en cours par Caffeine. De plus, il y a un bouton d'arrêt - si vous souhaitez changer de direction, vous pouvez toujours mettre la construction sur pause.
Cette liste de contrôle correspond directement au diagramme du processus de développement. Vous pouvez voir quand les étapes de conception sont terminées, quand le backend est compilé, quand plusieurs pages sont construites en parallèle et quand l'audit qualité est effectué. En cas d'échec, vous pouvez voir quelle tâche a échoué et pourquoi.
Récupération d'erreurs plus intelligente.
L'ancien processus se terminait par un seul contrôle qualité - il vérifiait si la structure du code était correcte, pas si l'application fonctionnait réellement. Est-ce que le code peut être compilé ? Oui. Après avoir cliqué sur le bouton 'ajouter au panier', le produit peut-il vraiment être ajouté au panier ? Personne ne l'a vérifié. La version V3 teste à la fois la qualité de la structure et la qualité fonctionnelle, les deux étant importantes.
La version V3 est capable de détecter les problèmes en temps réel. Le code backend est compilé avant le début du développement frontend. Le code frontend est vérifié pour les types après chaque modification, et le système d'assurance qualité valide l'application finale par rapport aux exigences initiales et attribue une note à chaque application - réussi ou échoué, avec des raisons. Il capture également des captures d'écran de l'application en cours d'exécution et les compare avec le design - le texte est-il lisible sur l'arrière-plan ? La position des éléments interactifs est-elle correcte ?
Lorsque des erreurs se produisent, Composer utilise les informations contextuelles pour réessayer : détails de l'erreur, leçons tirées de l'échec et une toute nouvelle fenêtre contextuelle, sans vous soucier des erreurs accumulées.
Cela s'applique également au déploiement. Lorsque le déploiement échoue, l'erreur est renvoyée à Composer, qui lit les informations d'erreur, essaie de réparer, puis réessaie le déploiement - généralement avant que vous ne remarquiez le problème. Si la construction échoue vraiment, elle sera proprement abandonnée au lieu de rester dans un état défectueux.
Ce qui n'a pas changé.
Votre projet fonctionne toujours de la même manière, vous devez toujours décrire vos besoins en langage clair et concis, et vous recevrez toujours un brouillon que vous pouvez prévisualiser, modifier et publier.
Ce qui change, c'est tout ce qui se passe entre la transmission de votre message et la génération de résultats.
Le prochain article de cette série : comment le système de design de V3 et le briefing DESIGN.md aident à créer des applications plus cohérentes et esthétiques.
#CaffeineAI #caffeine #vibecoding #AI
Le contenu IC qui vous concerne.
Progrès technologique | Informations sur le projet | Événements mondiaux.
Suivez le canal IC de Binance.
Rester à jour avec les dernières nouvelles.