De zéro à un cube tournant créé par le chat

L'étoile du nord : pourquoi "un cube qui tourne"

Tout ce jour visait un point d'acceptation : sur une machine propre, clonez, déposez une clé, exécutez une commande, puis dites à l'agent dans l'interface "créez un cube qui tourne" - il édite le code, le moteur se recharge à chaud et un cube tournant apparaît immédiatement dans le navigateur. Le cube lui-même n'a rien de remarquable, mais c'est la preuve minimale du pari principal du produit – "vous pouvez construire quelque chose de véritablement exécutable simplement en parlant" – et si un maillon de cette chaîne se brise, la plate-forme ne tient pas. Réduire l'objectif en un seul point d'acceptation sans ambiguïté qu'une seule capture d'écran peut prouver signifie que l'équipe ne « ressent pas de progrès » mais poursuit un objectif difficile de réussite/échec. Ce jour-là, c'est passé.

La boucle de bout en bout s'exécute : dites une phrase, l'image change

Cette boucle enchaîne six liens bout à bout : vous indiquez une exigence dans la boîte de discussion → l'agent écrit le code correspondant dans le fichier du jeu → un observateur de fichiers remarque le changement → un canal en temps réel informe le front-end → le moteur charge dynamiquement le nouveau code → l'image se met à jour instantanément. Ce jour-là, ces six liens ont été connectés de manière complète et stable pour la première fois, et une capture d'écran automatisée du navigateur a en fait capturé le cube à mi-rotation avec une inclinaison, sans erreur tout au long du processus, à l'exception d'un avis d'icône manquante inoffensif. Cela signifie que « ce que vous voyez est ce que vous obtenez » n'est plus une ligne dans un jeu de vision mais un véritable pipeline déclenché de manière répétée. Chaque expérience ultérieure de « construire en discutant et voir le résultat immédiatement » repose sur cette boucle ; une fois que cela fonctionne, le produit a vraiment pris vie une fois.

Les trois couches débarquent : des rôles clairs, remplaçables

Pour que cette boucle puisse durer sur le long terme, le système a été découpé en parties avec des responsabilités claires et remplaçables indépendamment : un noyau d'exécution qui pilote réellement la réflexion et l'action de l'agent (gestion des appels de modèles, des outils, des sessions, de la mémoire) ; un pur pont d'orchestration et d'interface (diffusant les modifications de fichiers vers le front-end, sans jamais toucher au grand modèle lui-même) ; un moteur (rendre le code du jeu dans une image) ; plus l'interface à trois colonnes à laquelle l'utilisateur est confronté. Cette scission a été inscrite dans un contrat d'interface interne et définie comme une règle de fer à ne pas remettre en cause à la légère : le noyau est le noyau, l'orchestration est l'orchestration, les limites restent sans ambiguïté. Sa valeur : chaque couche peut évoluer et être permutée d'elle-même, un problème dans une couche ne fait pas tomber l'ensemble, et "échanger le moteur, échanger l'interface" devient possible plus tard plutôt qu'une réécriture.

Remplacement du « shell d'espace réservé » par un véritable environnement d'exécution d'agent

Dans la version d'avant l'aube de la boucle, ce qui conduisait l'agent était toujours un shell d'espace réservé temporaire ; aujourd'hui, en une trentaine d'étapes, il a été remplacé par un véritable environnement d'exécution d'agent de « classe assistant de codage professionnel ». Ce noyau possède ce dont un véritable agent a besoin : il peut appeler le grand modèle, utiliser des outils, maintenir des sessions et de la mémoire, et avancer dans une boucle « penser-agir ». Après l'échange, le système a reçu pour la première fois de véritables réponses de modèle et a exécuté une boucle complète « modèle réel + outils réels ». Cette étape a fait passer le produit de « on dirait qu'il peut discuter » à « peut réellement faire le travail » – les conversations précédentes étaient une performance ; derrière eux se trouve désormais un moteur capable de lire, d'écrire et d'utiliser des outils pour véritablement changer votre projet.

Ne réinventez pas : réutilisez les standards au lieu de copier des milliers de lignes

Lors du remplissage des capacités de l'agent, deux éléments auraient pu être réalisés en « copiant mille lignes d'ailleurs » : la couche de protocole qui apporte la capacité de l'outil et un protocole standard d'événement de conversation. Le jugement d'aujourd'hui était clair : partout où un standard ouvert mature existe déjà et peut être installé et utilisé directement, ne le recopiez pas à la main. Ainsi, les deux ont été remplacés par des implémentations standard officielles des versions manuscrites précédentes : le code du protocole d'outil est passé d'une centaine de lignes à quatre-vingts et a obtenu des transports plus complets et des notifications de changement de capacité gratuitement ; le protocole d'événements de conversation a extrait une bibliothèque standard et réexporté plus de trente événements standard sans presque aucun nouveau code. Ensemble, les deux étapes ont ajouté moins de deux cents lignes nettes tout en offrant des capacités de niveau entreprise. Derrière tout cela se cache une discipline récurrente : consacrer des efforts à des problèmes difficiles que personne n’a résolus pour vous, et non à réinventer des roues déjà inscrites dans les normes publiques.

Des centaines de passes d'interface utilisateur de chat : du texte brut au niveau quasi-ordinateur de bureau

Une fois que la boucle a vraiment fonctionné, les lacunes d’expérience de l’interface sont devenues le point le plus sensible. Ce jour-là, en petites étapes sur une centaine d'itérations, le panneau de discussion a été peaufiné, passant de "zones de texte brut et d'espace réservé" à quelque chose qui se rapproche d'un assistant de bureau mature. Il comprend un moteur de rendu Markdown entièrement écrit à la main (blocs de code, listes, tableaux, listes de tâches tous pris en charge), une animation en streaming caractère par caractère dont la vitesse s'adapte à la longueur du contenu, des appels d'outils condensés dans une balise « pilule » haute densité qui s'étend jusqu'au résultat complet, « l'autocorrection/réflexion » de l'agent déclenchée visuellement, le contraste entre les bulles et l'arrière-plan réglé pour répondre aux normes d'accessibilité, et les animations en boucle désactivées pour les utilisateurs qui préfèrent réduire les mouvements. Chaque passe touchait une chose, était auto-testée et enregistrait une note. Le point est clair : quelle que soit la puissance de la capacité, si la lecture est laborieuse ou semble bon marché, les utilisateurs ne lui feront pas confiance ; polir la surface sur laquelle vous regardez le plus pour obtenir quelque chose d'agréable fait en soi partie de la fonctionnalité principale.

Une restructuration à plat + un développement sans build et exécuté à partir des sources

Dans l'après-midi, il y a eu un aplatissement structurel : les répertoires autrefois profondément imbriqués ont été posés à plat afin que les parties soient placées côte à côte de manière plus directe. Parallèlement, un mode de développement « zéro build » a été établi : après le clonage, une commande exécute directement la source, sans aucune longue étape de compilation et de regroupement au préalable. Pour les développeurs, cela signifie changer une ligne et voir le résultat dans le navigateur presque immédiatement, une itération progressive accélère d'un niveau ; pour les nouveaux arrivants, le chemin « du clone à la vision de l’image » est réduit à son plus court. La simplification structurelle est intangible, mais elle décide si les semaines à venir peuvent maintenir une cadence « un grand pas par jour » : plus les fondations sont simples et claires, plus vous construisez rapidement et de manière stable.

Le Studio à trois colonnes prend forme : fichiers, prévisualisation, console, mélangeurs

Le soir, le Studio à trois colonnes était aménagé, avec un lot de panneaux véritablement utilisables à la fois : l'arborescence des fichiers à gauche reliée à de vrais fichiers de projet, cliquez sur un produit pour le prévisualiser ; une fenêtre d'aperçu en direct au centre connectée directement au moteur, avec une lecture de la fréquence d'images, des modes pause, rechargement, plein écran et ordinateur de bureau/appareil mobile ; plus un panneau qui canalise la sortie de la console du moteur, un sélecteur qui répertorie et rejoue les sessions passées, et des entrées pour changer de projet et de jeu avec un « nouveau » menu. Notamment, cette journée a également suivi un instinct et a fusionné les deux concepts « projet » et « jeu » en un seul : l'utilisateur a dit qu'il s'agissait de la même chose, donc l'interface ne devrait pas les séparer. Avec cela, la disposition « gérer-gauche / aperçu-centre / chat-droite » s'est installée et le Studio a commencé à converger d'un ensemble de fonctionnalités vers une forme de produit utilisable.

Ce que signifie cette journée

Dans l'ensemble, le poids de cette journée est le suivant : il ne s'agissait pas d'une livraison d'une seule fonctionnalité, mais de la thèse fondamentale du produit qui a été prouvée de bout en bout pour la première fois. D’une phrase à un cube en mouvement, chaque lien intermédiaire – rendu, exécution, orchestration, interface – s’exécutait véritablement, sur une machine propre, comme en témoigne une capture d’écran. Tout ce qui est complexe après le cube – des jeux réels, des scènes complexes, toute une équipe d'agents – se développe sur ce tronc déjà connecté. C'est exactement pourquoi cette journée mérite d'être enregistrée comme modèle : connectez d'abord la chaîne principale la plus critique et la plus falsifiable, puis parlez des branches ; courir une fois est ce qui vous donne confiance pour la deuxième fois et la centième fois.