Aperçu du rechargement à chaud en direct + relecture de session

Du pari à la mémoire musculaire : rendre réflexif le « dis-le, vois-le »

Les jours précédents ont prouvé que « la conversation peut construire quelque chose d'exécutable » et ont posé les bases du rendu, des actifs et de la sécurité. Le thème de cette journée est de peaufiner cette boucle de « exécution unique » à « confortable à utiliser » : les changements sont visibles instantanément, l'historique n'est jamais perdu, l'agent ne sait jamais à quel point il agit. Tout cela ressemble à des expériences qui « devraient simplement fonctionner », mais derrière chacune d’elles se cache une véritable lacune technique en train d’être comblée. Ce n'est qu'une fois qu'ils sont tous remplis que la plateforme passe de « peut faire une démonstration » à « peut s'asseoir et utiliser pendant des heures ».

Aperçu en direct du rechargement à chaud : modifiez un fichier, l'image change d'elle-même

Cette journée a connecté l'aperçu central à un "pont de rechargement à chaud" : lorsque les fichiers d'un jeu changent, l'aperçu se rafraîchit pour afficher le dernier, sans clic de rechargement manuel. Il fonctionne grâce au backend qui surveille en permanence les changements de fichiers dans le répertoire de ce jeu et, dès que quelque chose change, en informe le front-end sur un canal en temps réel, qui recharge l'aperçu. Cela peut ressembler à « enregistrer un clic », mais il s'agit d'un lien essentiel dans la boucle « dites-le, voyez-le » : dès que l'agent termine l'édition, vous voyez le résultat à l'écran presque immédiatement, réduisant au minimum la latence entre la conversation et l'image. Pour quelqu'un qui s'assoit pour créer un jeu pendant des heures, ce retour instantané « ce que vous changez est ce que vous voyez » est ce qui relie l'inspiration à la mise en œuvre.

Replay de session : rouvrez une session et les allers-retours reviennent

Collaborez avec l'IA assez longtemps et l'historique des sessions devient un atout précieux : les exigences que vous avez soulevées, les décisions prises, les détours effectués. Cette journée-là, l'historique de la session a été conservé dans un "grand livre" durable et la réouverture d'une session a permis de rejouer les allers-retours précédents. Une subtilité technique a été gérée : le flux d'événements en temps réel ne contient que des enregistrements légers de "ce qui s'est passé", pas le texte intégral, de sorte que la relecture doit reconstruire le contenu réel à partir du grand livre plutôt que de rejouer naïvement les événements. La signification : fermez-le et revenez, et le contexte n'est pas perdu ; une partie de l’histoire peut être revisitée à tout moment, telle qu’elle s’est produite. Cela permet de « travailler sur un projet sur le long terme, sur plusieurs tours », au lieu de repartir d'une page blanche à chaque fois.

Shaders composables + rechargement à chaud entre fichiers

Le moteur a aujourd'hui donné aux shaders une capacité « composable » : les shaders peuvent s'importer les uns les autres, partager des fragments et paramétrer avec des définitions de macros, au lieu d'empiler tout le code dans un seul fichier. Mieux encore, il prend en charge le rechargement à chaud entre fichiers : modifiez un fragment partagé auquel d'autres font référence et chaque shader qui l'utilise s'actualise instantanément. Pour quelqu'un qui crée des effets visuels, cela signifie organiser le code du shader comme des blocs de construction : prendre en compte l'éclairage, le bruit et le traitement des couleurs communs dans des modules réutilisables référencés partout ; changez-en un et cela prend effet partout, vu d’un coup. Il transforme les « effets d'écriture » d'« essais et erreurs contre un gros blob » en « composition de modules réutilisables et réglage en direct » — une véritable expansion de l'expressivité du rendu.

Une console moteur unifiée : un seul canal d'exécution, cohérent partout

Le moteur a aujourd'hui unifié son canal de débogage/inspection « console » en une seule abstraction : le backend converge vers un canal d'exécution, tandis que le côté ligne de commande offre une entrée d'inspection plus légère en lecture seule. L’avantage de l’unification réside dans un comportement cohérent et un modèle mental plus simple : partout où vous lancez une inspection ou une exécution, elle suit le même chemin ordonné, plutôt que chaque endroit ait sa propre version légèrement différente. Une telle convergence dans l'abstraction est généralement invisible du côté de l'utilisateur, mais elle détermine si un système devient plus compliqué à mesure que les fonctionnalités s'accumulent. La convergence du « fonctionnement de la console » vers un canal faisant autorité définit très tôt les mêmes règles pour chaque fonctionnalité qui se connecte ultérieurement à la console.

Les nouveaux jeux sont livrés avec un démarreur exécutable + l'agent sait toujours quel jeu

Cette journée a été remplie de deux détails qui rendent la « création d'un jeu » plus fluide. Premièrement : un nouveau jeu est livré avec un démarreur directement exécutable (une ouverture de cube rotatif), de sorte qu'au moment où vous le créez, vous voyez une image, au lieu de regarder un blanc et d'écrire à partir de zéro. Deuxièmement : le contexte du "jeu sur lequel vous travaillez actuellement" est explicitement introduit dans l'invite système de l'agent, de sorte qu'il sait clairement dans quel jeu écrire du code. Ce dernier corrige un écueil dangereux : avec plusieurs jeux coexistant, un agent incertain de la cible actuelle édite facilement le mauvais endroit. Faire du « jeu actif » un contexte explicite et transmis de manière fiable, c'est comme donner à l'agent une boussole qui ne se trompera pas.

Le backend reste solide : plus de tests, rédaction du chemin, validation du nom

Le backend a maintenu son rythme de « fixation du comportement avec des tests », en ajoutant un autre grand lot de sondes et de tests unitaires de bout en bout. Quelques objectifs : verrouiller les règles de dénomination des jeux et des projets avec de nombreux cas (quels noms sont valides, lesquels doivent être rejetés, chaque limite gardée par des tests), continuer à rédiger le chemin d'accès de l'utilisateur dans les réponses extérieures (pas de fuite des chemins réels de votre machine) et extraire la logique clé comme la construction de l'invite système en une fonction pure et testable séparément. Aucune de ces fonctionnalités n’est flashy ; il s'agit du travail quotidien consistant à "créer un système d'édition de fichiers digne de confiance". Notamment, cette journée s'est également adaptée au format d'événement d'un autre backend de codage, facilitant l'intégration de davantage d'options de pilotage de modèle : un choix de plus, une expérience cohérente.

Ce que signifie cette journée

Vu ensemble, la ligne directrice est claire : rendre « construire en parlant » non seulement possible, mais sans friction. Modifications visibles instantanément (rechargement à chaud), historique entièrement récupérable (relecture de session), effets organisés comme des blocs de construction (shaders composables), l'agent ne modifiant jamais la mauvaise cible (contexte de jeu actif), le backend digne de confiance (tests et rédaction) — chacun supprime une petite friction qui interromprait le flux. Le fait qu’un outil soit agréable à utiliser dépend souvent moins de sa capacité à accomplir une grande chose que de la fluidité avec laquelle il accomplit les cent petites tâches quotidiennes. Ce que cette journée a apporté était parmi les plus cruciaux parmi ces centaines.