600 fichiers, une commande : ce que le refactoring de moonshot.ai révèle sur les agents IA au travail

En mars 2026, moonshot.ai a dévoilé une nouvelle apparence. Le journal des modifications ressemblait à la liste de souhaits d'un designer : nouvelle palette de couleurs, typographie resserrée, animations mises à jour. En coulisses, le travail n'avait rien de glamour.

Le rafraîchissement a touché les composants partagés, les tokens de design, les routes et les couches interactives sur l'ensemble du site. Aucune édition individuelle n'était algorithmiquement difficile. Le défi était l'ampleur. Savoir ce que chaque changement touchait et s'assurer que rien ne passait à travers. Ce type de travail est exactement là où un agent de codage IA peut gagner sa place, ou brûler son budget dans le bruit.

L'équipe d'ingénierie de Moonshot a utilisé Kimi Code CLI, propulsé par Kimi K2.5, comme assistant principal pour ce refactoring. Le projet s'est déroulé sur une base de code en production avec des contraintes réelles : pas de bacs à sable de démonstration, pas de tâches choisies. Les résultats, publiés dans un post-mortem détaillé, offrent un aperçu concret de ce qu'un agent en mode terminal fait réellement bien, et de ce qui nécessite encore un humain dans la boucle. minimax-launches-m27-model-with-strong-software-engineering-and-office-productivity-skills

L'idée centrale : l'ampleur plutôt que la complexité

Le rafraîchissement de Moonshot ne consistait pas à réécrire la logique centrale. Il s'agissait de tracer les tokens partagés, de mettre à jour les composants, de vérifier le comportement interactif et de s'assurer que l'analytique et l'accessibilité survivaient. Individuellement trivial. Collectivement, épuisant. how-local-llms-like-gemma-and-qwen-are-taming-open-source-repository-triage-at-scale

Le premier geste de l'équipe n'a pas été d'écrire une invite. Ils ont exécuté /init pour générer un fichier AGENTS.md, puis ont passé environ une heure à l'affiner : ce qui était dans le périmètre, ce qui ne pouvait pas changer, comment le projet était structuré, comment les builds fonctionnaient. Ils ont également ajouté un fichier de règles pour les noms, l'espacement et le contraste.

Cet investissement initial a porté ses fruits. Sans contexte spécifique au projet, un agent IA a tendance à produire des résultats raisonnables mais génériques. Avec ce contexte, le comportement de l'agent s'est aligné plus étroitement sur celui d'un coéquipier qui comprenait déjà la base de code.

Comment l'agent a réellement été utilisé

Six workflows distincts ont défini le refactoring. Chacun ciblait une phase spécifique du processus de production, non pas l'automatisation pour elle-même, mais la réduction de l'incertitude.

Tracer les dépendances avant de toucher au code

Avant de modifier quoi que ce soit, l'équipe a demandé à Kimi Code CLI de lire une zone cible et de lister ce qui en dépendait. Un changement de couleur de bouton, par exemple, pouvait se répercuter sur les sections hero, les appels à l'action de téléchargement, les états de survol et les tokens partagés. Obtenir cette carte en premier a rendu les modifications prévisibles et a réduit les ruptures surprises.

Faire correspondre le code aux specs Figma

En utilisant une connexion Model Context Protocol (MCP) avec Figma, l'agent a extrait les tokens de design, les données de mise en page et la typographie directement de l'outil de conception. La comparaison composant par composant est devenue un processus structuré : hero, navigation, sections produits, pied de page. L'agent a produit des listes de changements au niveau des propriétés en faisant correspondre les styles avec les tokens de design et les valeurs de mise en page. La plupart des différences étaient mineures (espacement, rayon de bordure, poids de la police), mais l'agent a mis en évidence des incohérences plus importantes là où des composants qui auraient dû partager des variantes avaient dérivé au fil du temps.

Rechercher de nouveaux comportements interactifs

Le rafraîchissement a introduit des fonctionnalités absentes de la base de code existante : un curseur personnalisé, un hero piloté par l'exécution, des cartes d'illustration animées au survol et des entrées déclenchées par le défilement. Pour chacun, l'équipe a chargé la documentation et l'état du dépôt dans la même session. La grande fenêtre de contexte de Kimi K2.5 permettait à l'agent de raisonner à travers l'implémentation et les références en un seul passage.

Les questions étaient pratiques : les animations de survol doivent-elles se terminer ou s'annuler à la sortie ? L'état du curseur interagit-il avec le canvas du hero ? Qu'est-ce qui casse lorsque plusieurs couches se chevauchent ? Garder l'intention de conception et le code dans la même session a permis d'obtenir ces réponses plus rapidement.

Vérifier le poids et les performances

Le rafraîchissement a introduit une nouvelle police de caractères, plus d'animations et des ressources supplémentaires. L'agent a adapté le script de sous-ensemble de polices existant, vérifié la sortie et aidé à interpréter les rapports Lighthouse tôt. L'objectif n'était pas d'optimiser tout à la fin ; c'était de prendre des décisions de conservation ou de suppression pendant que les changements étaient encore petits.

Tracer les risques d'intégration avant la fusion

Plusieurs couches interactives (animations d'entrée, curseur, canvas hero) partageaient l'ordre et le comportement du pointeur. L'agent a tracé les conflits d'interaction potentiels entre des lots de diffs, signalant les cas où un changement dans une couche pouvait en casser une autre. Les différences entre navigateurs et systèmes d'exploitation ajoutaient une autre dimension.

Revues de code structurées via une compétence personnalisée

L'équipe a écrit une compétence, un fichier de règles qui indique à Kimi Code CLI comment évaluer une demande de fusion de bout en bout. L'agent a lu le diff, tracé les fichiers et composants affectés, vérifié les violations du système de conception (littéraux de couleur bruts, espacement hors grille, rappels d'accessibilité manquants), évalué le risque par zone et généré un rapport structuré avec des résultats regroupés par sévérité.

Chaque PR pendant le rafraîchissement est passée par cette étape avant la fin de la revue. La sortie incluait toujours un résumé de l'intention, des résultats classés par sévérité avec des preuves et des éléments d'action concrets. Des problèmes tels que des URL codées en dur à côté de constantes partagées, des champs d'analytique nécessitant un alignement et des cas limites d'interaction mobile ont été détectés ici, avant d'atteindre la boîte de réception d'un relecteur. cuga-ibms-open-source-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list

Ce qui a surpris l'équipe

Trois tendances ont émergé, qui n'étaient pas évidentes au départ.

Le passage des specs au code a été plus rapide que prévu. Avec Figma MCP et Kimi Code CLI dans le même fil, les dimensions et les tokens de design arrivaient en entrée structurée. Les boucles d'itération par section se sont réduites. Les changements et corrections au niveau des propriétés aboutissaient souvent en un seul passage au lieu de rebondir entre les outils.

Les invites de recherche ont été plus payantes que prévu. Le rafraîchissement reposait fortement sur de longs passages documentaires à travers la documentation d'exécution et les implémentations de référence aux côtés du dépôt. Garder ces documents dans la même session que le code s'est souvent avéré aussi précieux que les modifications elles-mêmes.

La compétence de revue a transformé les petites incohérences en une liste gérable. URLs codées en dur, alignement de l'analytique, cas limites mobiles. La plupart étaient mineurs individuellement, mais plus faciles à traiter une fois regroupés en un seul passage. Les longs fils de discussion restaient peu coûteux à reprendre via les commandes kimi, continue et /compact, évitant de reconstruire le contexte chaque matin. the-hidden-bottleneck-in-ai-inference-why-deepseeks-dspark-rewrites-the-rules-of-speculative-decoding

La ligne de partage : qui fait quoi

L'équipe est explicite sur la division du travail : ils ont pris les décisions, examiné chaque changement et validé le résultat final. L'agent s'est occupé du traçage répétitif, de la comparaison et du travail de revue initial. Cette distinction est importante car elle définit la frontière pratique pour les agents de codage IA dans les workflows de production.

Pour les refactoring multi-fichiers, la vérification design-code et le travail de cohérence à grande échelle, cette approche s'est avérée utile. L'agent a éliminé la partie fastidieuse (la partie où un humain aurait dû garder 600 fichiers en tête et comparer mentalement chaque déviation). Mais il n'a pas remplacé l'architecte, le relecteur ou la personne qui valide l'expérience finale.

Pour les équipes envisageant un workflow similaire, les leçons sont claires : investissez dans le contexte du projet dès le départ, connectez tôt une source de vérité (Figma, CMS, API interne) et gardez l'intention de conception et le code dans la même boucle. L'agent amplifie la cohérence sur l'ampleur. L'humain conserve les décisions qui comptent. ibms-open-source-cuga-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list