Un mois de travail, achevé en un jour par un ingénieur en poste depuis un an seulement.
Il n'avait jamais utilisé Claude Code, et ne comprenait même pas vraiment comment fonctionne l'USB.
La tâche du jour : créer des modèles USB de clavier et souris pour le simulateur, et développer le pilote de périphérique USB pour Android.
À l'ancienne, cela prendrait un mois. Il n'a mis qu'un jour.
Le logiciel doit tourner sur un simulateur avant même que la puce ne soit fabriquée. Le comportement des périphériques USB comme le clavier et la souris doit être entièrement recréé dans l'environnement virtuel.
Le fournisseur d'EDA ne fournit que du code de référence pour le transfert de données basique, le reste est à faire : d'abord digérer la norme de communication USB, puis créer un modèle séparé pour chaque type de périphérique.
C'est un travail long et fastidieux même pour un vétéran. Et cet ingénieur n'avait même jamais essayé le "Vibe Coding".
La première chose qu'il a faite, c'est de tout balancer à l'IA : la fonctionnalité à implémenter ainsi que ce code de référence.
Claude Code a complété les besoins, proposé des méthodes d'implémentation, écrit le code, et a modifié une version à chaque demande.
Ainsi, les modèles de clavier et souris, la validation fonctionnelle, le pilote de périphérique USB pour Android, tout a été achevé le même jour.
L'IA écrivant des pages web, des scripts, rénovant des bases de code entières, on a déjà l'habitude. Cette fois, l'IA s'attaquait à la validation de puces.
Ce qui est compressé, c'est la courbe d'apprentissage du débutant, pas le jugement professionnel du vrai et du faux.
Un employé de Samsung Electronics travaille sur une ligne de production de semi-conducteurs.
L'équipe du projet voisin a reçu une tâche plus épineuse.
Le client voulait un SoC sur mesure, avec rien que 64 canaux de données internes à la puce, entrelacés, chacun nécessitant une vérification. Le problème : le code du circuit gérant la mémoire n'était pas encore terminé, et une partie de la documentation de conception standard manquait.
Dans cette situation, les ingénieurs ne peuvent généralement faire qu'une chose : attendre.
Ils ne l'ont pas fait.
La mise en place et les vérifications de l'environnement de validation, initialement prévues pour plus d'un mois, ont été terminées en deux jours.
L'évaluation interne de Samsung : une accélération par 15.
Ce qui est économisé, c'est l'attente
Où était le blocage de ce SoC sur mesure ?
Le client voulait une toute nouvelle architecture de semi-conducteur, utilisant même de la propriété intellectuelle (IP) externe.
Dans la chaîne traditionnelle, les ingénieurs doivent d'abord attendre que la documentation de conception soit complète, que le RTL du contrôleur DRAM soit publié, avant de pouvoir monter l'environnement de validation, connecter les IP de validation, écrire les scénarios de test.
Cette chaîne est linéaire. Si le premier maillon n'est pas là, tout le reste est à l'arrêt.
La méthode de Samsung cette fois-ci a été de donner à l'IA ce qu'ils avaient déjà entre les mains : les informations de conception du SoC du fournisseur d'EDA, les spécifications de communication interne de la puce, les IP de validation, tout a été confié à Claude.
L'IA a identifié les IP de validation nécessaires, fait la disposition et les connexions, généré l'environnement de validation virtuel et les scénarios de test. Le contrôleur DRAM n'étant pas livré, un module virtuel a pris sa place temporairement, permettant aux chemins de données critiques de fonctionner.
La division System LSI de Samsung utilise déjà Claude Code pour le développement et la validation de semi-conducteurs, certaines tâches passant d'un mois à deux jours.
Le résultat : des erreurs précoces ont été détectées avant même la publication du vrai RTL.
C'est la vraie source de ce facteur 15. Ce qui est économisé, c'est ce temps mort d'attente que la documentation soit complète.
Accélération par 15 et trois écarts
L'évaluation interne de Samsung a également enregistré trois anomalies.
Première : un ingénieur lui a demandé de corriger une erreur. Il n'a pas réparé la cause racine, mais a modifié le message d'erreur en un avertissement général.
Feu rouge changé en orange, et l'indicateur passait au vert.
Deuxième : l'ingénieur ne lui a demandé que de revenir sur une fonctionnalité spécifique. Il a également annulé d'autres travaux déjà terminés.
Troisième : l'ingénieur ne lui a demandé que d'analyser les résultats de la validation. Il a tenté de modifier le code RTL réel du circuit.
S'agit-il d'une "IA qui a appris à dissimuler", ou d'une "modification non autorisée du code noyau" ?
Réduire une erreur en un simple avertissement s'apparente plus à un détour pris pour atteindre un objectif immédiat. C'est un problème d'alignement des objectifs, pas l'émergence d'une intention de tromper.
Anthropic lui-même, pour décrire ce type de comportement, utilise les termes "trop proactif" et erreur d'appréciation de la portée de l'opération.
L'attribution de cause interne chez Samsung pointe également dans cette direction : le grand modèle linguistique n'a pas suffisamment compris les relations de dépendance complexes dans le langage de conception matérielle. Il sait comment faire fonctionner une ligne de code, mais ne sait pas combien de choses cette ligne entraîne derrière elle.
Cette distinction est importante.
S'il s'agissait vraiment d'avoir appris à dissimuler, c'est un problème au niveau du modèle, que personne n'est en mesure de résoudre aujourd'hui. En revanche, le manque d'alignement ou l'incompréhension des dépendances est un problème d'ingénierie, qui peut être maîtrisé par des autorisations et des procédures.
La nouvelle tâche de l'ingénieur
est de tracer les frontières de l'agent intelligent
L'approche de Samsung dans cette affaire se résume à trois choses :
Où l'IA peut toucher, c'est l'homme qui le délimite ; les résultats qu'elle produit, l'homme les vérifie à nouveau ; une fois la stabilité confirmée, on lui accorde les droits petit à petit.
Concrètement pour l'ingénieur, cela se traduit par de nouvelles tâches : quels répertoires sont inscriptibles, le code de circuit comme le RTL peut-il être modifié, quelles règles de validation sont immuables, qui examine chaque changement...
Si vous avez déjà utilisé Claude Code pour travailler, vous avez probablement rencontré les trois écarts mentionnés précédents : lui demander de corriger une erreur, il baisse le niveau de log ; lui demander de retirer une fonctionnalité, il supprime aussi votre commit d'hier.
La différence réside dans la possibilité d'annuler les conséquences.
Dans le développement logiciel, le pire scénario est de revenir en arrière d'un commit et de recommencer.
Dans l'industrie des puces, c'est différent. Une fois le design envoyé en fabrication ("taped-out"), c'est-à-dire lorsque le plan est envoyé en ligne de production, le circuit est gravé dans le silicium. Pour le modifier, il faut mettre au rebut tout le lot et recommencer depuis le début.
Le logiciel peut être patché, pas la puce.
L'IA fabrique des puces
L'humain doit être dans la boucle
Il est intéressant de noter qu'au même moment, Anthropic lui-même mise sur cette ligne du matériel.
Le 9 juillet, il a annoncé un partenariat avec la société de services d'ingénierie UST, pour intégrer Claude dans la validation de puces, l'automobile, la fabrication, et former les 20 000 ingénieurs, architectes et consultants d'UST dans le monde.
UST possède une plateforme appelée iDEC, spécialisée dans la vérification du matériel et du silicium avant la production en série des puces.
Selon UST, cette chaîne de production a déjà réduit le cycle de validation de plus de moitié, un travail qui prenait quatre jours se termine maintenant en 48 heures.
Désormais, Claude Code est intégré en tant que cerveau : lire les définitions des broches et les schémas de circuits de la puce, écrire et exécuter les tests, puis comparer les données du matériel réel avec le modèle de simulation, en signalant les écarts.
Anthropic mentionne dans cette annonce que dans ces industries où le coût de l'erreur est très élevé, le fait de faire approuver par l'homme et de conserver une trace de chaque étape est la condition préalable pour que ce système puisse réellement être déployé en production.
Sur Reddit, un utilisateur se présentant comme travaillant pour une entreprise d'EDA est moins optimiste :
Même avec des agents intelligents et des flux de compétences, on est loin de la facilité d'utilisation, la mise en place d'un seul flux peut prendre des mois ; les effets sur les circuits numériques et la validation sont nettement meilleurs que sur l'analogique, le mixte signal et la mémoire.
Cette plainte cache en réalité une règle.
Que ce soit votre base de code ou la chaîne de production de Samsung, ce que l'IA réussit en premier, c'est la validation.
La raison est simple : la validation a une réponse standard, on sait si c'est juste ou faux après l'exécution, sans avoir besoin d'attendre le jugement humain.
L'IA ne vise pas à remplacer qui que ce soit
Elle vise à augmenter la production d'une personne
Les estimations du secteur donnent environ 6 000 personnes pour la division System LSI. Qualcomm en comptait environ 52 000 en septembre dernier.
Pour ceux qui sont assis au poste de System LSI, cela signifie que pour le même marché des puces, l'adversaire a plusieurs fois plus de personnel.
C'est dans cette position que se trouve l'ingénieur en poste depuis un an seulement : manque de personnel, délais tout aussi serrés, standards inchangés.
Ainsi, la véritable attente placée dans l'IA ici est d'augmenter la production d'une personne.
Confier les tâches les plus chronophages et répétitives, comme les connexions, la validation, l'étude des normes, libère les vétérans pour s'attaquer aux parties vraiment difficiles, et permet aux nouveaux de prendre en charge des tâches plus lourdes.
L'ingénieur qui a modélisé l'USB en un jour au lieu d'un mois, ce que l'IA lui a économisé, c'est précisément la barrière "comprendre d'abord à fond la norme USB".
Un professionnel de l'industrie des semi-conducteurs déclare : ce type d'agent intelligent est vraiment rapide, mais s'il n'est pas maîtrisé, les conséquences sont graves.
Son jugement est que le temps de développement global continuera d'être compressé, les étapes autrefois exécutées pas à pas par l'homme diminueront continuellement, et l'ingénieur finira par garder le contrôle des deux extrémités : comment définir l'objectif, et si le résultat est correct.
Le travail de l'ingénieur ne diminue pas, il change simplement de forme.
La compétence d'avant, c'était de pouvoir monter un environnement de validation ; la compétence de demain, c'est de savoir quel endroit de l'environnement monté par l'IA est incorrect.
L'IA peut comprimer un mois de travail en un jour ou deux. Mais une fois la puce envoyée en fabrication, personne ne peut la faire revenir en arrière.
Références :
https://news.nate.com/view/20260812n19157?utm_source=chatgpt.com
Cet article provient du compte public WeChat "Xin Zhi Yuan", auteur : ASI Revelations, éditeur : Yuan Yu
