[Samsung Electronics] Un scénario où l’IA développe 100 % du firmware MCU des appareils électroménagers est-il possible ?

Titre : Un scénario où l’IA développe 100 % du firmware MCU des appareils électroménagers est-il possible ?

Source : Samsung Tech Blog - https://techblog.samsung.com/blog/article/90

• Samsung Electronics a appliqué le « Harness Engineering » au développement du firmware MCU d’un appareil électroménager (une hotte aspirante) afin de vérifier si un agent IA pouvait créer 100 % du firmware sans intervention humaine dans le codage, en répétant de manière autonome les cycles planification-implémentation-vérification.

• Ici, le « harness » ne consiste pas à rendre le modèle plus intelligent, mais à concevoir l’environnement de travail pour que l’IA produise le résultat voulu : informations nécessaires, interdits, boucles d’auto-vérification, structure de dossiers, spécifications, standards de codage, build/linter. Le rôle du développeur passe ainsi de « rédacteur de code » à « concepteur de spécifications et de harness ».

• Le principe clé est : « une spécification que l’IA ne peut pas vérifier n’existe pas ». Une exigence non documentée ne peut servir ni de critère d’implémentation ni de critère de vérification ; elle équivaut donc à une « exigence inexistante » (par exemple, si l’on n’indique pas si le débit d’air doit être Low-Mid-High ou On-Off, l’IA décidera arbitrairement). Le point de départ est la « conception des spécifications », qui consiste à structurer les anciennes spécifications et le « savoir tacite » des développeurs sous une forme exploitable par l’IA.

• Les spécifications dispersées ont été réorganisées autour du dossier docs/. Le comportement du produit est placé dans behavior/, les justifications de conception dans design/, les informations de configuration et d’initialisation matérielles dans hardware/, tandis que les spécifications de communication, les machines à états et les protocoles de communication sont rangés dans leurs dossiers respectifs. À cela s’ajoutent AGENTS.md, qui contient les règles de travail de l’IA, et ARCHITECTURE.md, qui définit la structure en couches et les règles de dépendance, complétant ainsi la base du harness. Au final, la documentation joue le rôle de « Single Source of Truth ».

• En plus des trois types de harness — spécification, implémentation et vérification — des « skills » sont fournis, comme les spécifications MCU propres à Samsung, le mode d’emploi du débogueur MCU et un USB Switch permettant de couper et rétablir physiquement l’alimentation 220 V. SDD/TDD/BDD servent à contrôler le périmètre d’implémentation, et il faut passer les quality gates Build/Test/Lint pour accéder à l’étape suivante.

• La boucle AUTOPILOT démarre à partir d’un code Zero-Base et répète de manière autonome planification, implémentation et vérification. À ce stade, l’« agent qui génère » et l’« agent qui évalue/vérifie » sont séparés afin d’éviter que l’IA n’évalue trop favorablement ses propres résultats.

• Le défi le plus difficile consiste à mettre en place un environnement dans lequel l’IA peut vérifier directement ses résultats sur un « vrai MCU ». L’environnement de vérification se compose de Codex AI sur PC, d’un débogueur MCU basé sur JTAG et d’un USB Switch pour le contrôle de l’alimentation, Codex AI contrôlant le débogueur et le switch. Le débogueur lit et écrit directement l’état du MCU, tandis que l’USB Switch allume et coupe l’alimentation 220 V, permettant à l’IA de réinitialiser elle-même l’ensemble même en cas d’état irrécupérable.

• L’IA reçoit les spécifications du produit, les informations sur les protocoles et paquets, la datasheet du MCU, le mode d’emploi du débogueur, le code source et la structure des variables, ainsi que la méthode d’alimentation On/Off. Elle analyse les spécifications pour déduire des scénarios de test par « volonté autonome », injecte des entrées de touches dans l’équipement réel via le débogueur (memory Write), puis lit les valeurs d’état sous forme de variables (memory Read) afin de déterminer elle-même le Pass/Fail de chaque scénario. Autrement dit, la vérification automatique autonome devient possible lorsque les trois éléments — « scénario de fonctionnement + memory Write + memory Read » — sont coordonnés.

• Résultat : les 5 essais ont tous été finalisés de manière autonome sans intervention humaine (environ 4,5 à 5,5 heures par essai), avec un taux d’achèvement des fonctions de base d’environ 95 %. Les quelque 5 % manquants provenaient principalement du HAL (UART, Timer, WatchDog, Clock, etc., relevant de la vérification du matériel réel) et peuvent être complétés par 1 à 4 heures de débogage avec un humain.

• La possibilité de réduire en moyenne la durée de développement de 50 à 70 % a été confirmée. Toutefois, il s’agit d’une estimation par l’IA portant sur le temps de développement pur, hors approbation, revue et release ; les défis pour une adoption plus large restent l’investissement initial et la définition de critères de vérification suffisamment parfaits pour que l’humain n’ait plus besoin de relire le code.