
Toutefois, le développeur doit donc toujours vérifier, modifier et optimiser le code suggéré, ce qui peut demander du temps et de l’énergie. Le code suggéré peut contenir des erreurs, des biais ou des failles. Le développeur doit donc toujours comprendre le code qu’il utilise, et ne pas le copier-coller sans le tester ou le documenter. Sinon, il risque de compromettre la fiabilité, la sécurité et la maintenabilité du code. Cet outil d’IA ne peut pas se substituer au travail du développeur, qui doit toujours faire preuve de jugement, de compétence et de responsabilité.
Codegen ne peut pas s’adapter à tous les cas d’utilisation, car il ne connaît pas les besoins spécifiques et le cadre de chaque projet. Il peut créer une dépendance ou une paresse chez les développeurs, qui pourraient se reposer entièrement sur l’IA pour écrire le code. Cela pourrait réduire la créativité, la curiosité et l’apprentissage des développeurs, qui ne chercheraient plus à améliorer ou à innover leur code. Cela pourrait également poser des problèmes d’éthique ou de sécurité, si le code suggéré contient des données sensibles ou personnelles, ou si le code suggéré est utilisé à des fins malveillantes ou illégales.
Seuls 3 % de développeurs déclarent avoir une grande confiance dans la précision des outils d’IA pour le développement. « Ce scepticisme n'est pas surprenant. Lorsque nous avons commencé à travailler sur Dev Mode, un espace pour les développeurs dans Figma, nous l'avons imaginé comme un moyen d'automatiser le passage de la conception au code. Les premières versions étaient prometteuses, mais au fur et à mesure de l'itération de notre approche, nous avons constaté que les développeurs ne trouvaient pas toujours le code utile », déclare Figma.
Cependant, codegen offre le plus d'avantages lorsqu’il est appliqué d'une manière spécifique, pour une équipe, une entreprise et votre flux de travail. Par exemple, si votre système de conception et votre bibliothèque de composants sont déjà dans Figma, vous n'avez pas besoin d'une application automatisée de conception à codage. Dans ce cas, il est préférable de se référer aux jetons, de consulter la documentation ou de créer un plugin codegen pour générer des extraits personnalisés.
Selon Figma, en appliquant ces conseils, il est possible de traiter et de comprendre ce que vous regardez plus rapidement, lorsque vous commencerez à écrire le code vous-même. « Codegen vous aidera à passer d'un écran vide à un point de départ - peut-être pas de 0 à 1, mais de 0 à 0,5 - beaucoup plus rapidement. » Codegen peut également aider à interpréter les exigences de conception comme les valeurs de style brutes - telles que les codes hexadécimaux et les pixels - pour construire un élément d'interface utilisateur ou découvrir un nom de jeton ou une valeur de propriété de composant lorsque vous mettez en œuvre un système de conception.
Le code d'implémentation d'une instance d'un composant est très différent du code définissant le style et les propriétés d'un composant. Si vous développez la bibliothèque de composants de votre équipe, vous écrirez le code du composant pour le style visuel sous-jacent ainsi que les définitions des variantes et des propriétés. Si vous mettez en œuvre une bibliothèque de composants, le code que vous écrivez est souvent un code d'instance de composant ainsi que le style de présentation qui l'entoure.
L’équipe Figma explique que Codegen analyse les éléments visuels d’une conception et recommande des noms de composants et des valeurs de propriétés qui correspondent au système de conception utilisé par le développeur.
Ainsi, Codegen permet au développeur de gagner du temps et d’éviter des erreurs en lui donnant un point de départ pour le code. L’équipe suggère également de créer un plugin Codegen personnalisé, qui pourrait s’adapter aux besoins et aux cadres spécifiques de chaque projet. Toutefois, l’entreprise reconnaît que cela prend du temps et des ressources, et qu’il est plus simple d’établir une bonne base en s’assurant que les conceptions de l’équipe correspondent à des modèles dans le code.
À l’exemple des composants et des variables de Figma, qui rendent les systèmes de conception faciles à mettre en œuvre et à maintenir, car ils encapsulent les modèles dans des jetons et des propriétés. L’équipe Figma souligne ensuite les limites de Codegen, qui ne peut pas se substituer au travail du développeur, ni remplacer les modèles de l’équipe. Il rappelle que le développeur doit toujours vérifier, modifier et optimiser le code suggéré, ce qui peut demander du temps et de l’énergie.
Codegen ne remplacera pas les modèles de votre équipe
Les besoins de votre équipe en matière de conception et de développement sont uniques. Des facteurs tels que la taille de l'entreprise, les exigences de sécurité et les contraintes techniques contribuent tous à une situation spécifique. Afin de répondre et de s'adapter à ces besoins, une équipe a certainement pris des décisions sur le style ou les Framework de composants pour la bibliothèque d'interface utilisateur, le schéma de des jetons de conception, la façon dont les fichiers sont organisés et nommés, ou même les conventions préférées autour de la syntaxe et du formatage du code.
Avec tout ce contexte spécifique à l'organisation, il n’est simplement pas possible de coller le code généré automatiquement directement dans une base de code sans le modifier davantage. Bien qu’il est possible de trouver des moyens d'utiliser l'apprentissage automatique pour se faire aider, en raison des limites des outils existants, la création de la base de code d’une équipe est une activité pratique, et les modèles de l'équipe sont là pour faciliter le processus.
Le code généré peut être un point de départ très utile. Mais même dans ce cas, les bouts de code doivent encore être modifiés pour y intégrer d'autres propriétés, ajouter du formatage, des styles supplémentaires et bien d'autres choses encore. Une fois que le code est dans cet état, les modifications ultérieures du fichier Figma ne peuvent pas toujours être « collées » en utilisant codegen de la même manière ; cela reviendrait à écraser le travail déjà édité. Tout outil finit par se heurter à ses limites.
Récemment, les grands modèles de langage (LLM) ont montré une capacité extraordinaire à comprendre le langage naturel et à générer du code de programmation. Les ingénieurs logiciels ont l'habitude de consulter les LLM lorsqu'ils sont confrontés à des questions de codage. Bien que des efforts aient été faits pour éviter les erreurs de syntaxe et aligner le code sur la sémantique prévue, la fiabilité et la robustesse de la génération de code à partir des LLM n'ont pas encore fait l'objet d'une étude approfondie.
Pour combler cette lacune, Li Zhong et Zilong Wang proposent dans leur travail un ensemble de données RobustAPI pour évaluer la fiabilité et la robustesse du code généré par les LLM. Ils ont recueilli 1208 questions de codage de StackOverflow sur 24 API Java représentatives. Ils ont résumé les schémas d'utilisation abusive courants de ces API et les évaluons sur des LLM courants et populaires. Les résultats de l'évaluation montrent que même pour GPT-4, 62% du code généré contient des abus d'API, ce qui entraînerait des conséquences inattendues si le code était introduit dans un logiciel réel.
Inconvénients des outils d’IA de génération de code comme codegen
Les outils d’IA de génération de code comme codegen sont présentés comme des innovations qui facilitent le travail des développeurs, mais ils ne sont pas sans risques ni limites. En effet, ces outils pr...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.