Les outils de codage par IA peuvent générer du code rapidement, mais la vitesse seule ne résout pas les problèmes d’ingénierie logicielle les plus difficiles. Les développeurs doivent toujours fournir du contexte, valider les résultats, préserver la maintenabilité et rester responsables de ce qui est mis en production.
Pour découvrir comment des développeurs expérimentés trouvent cet équilibre, nous nous sommes entretenus avec trois Java Champions, tous forts de plus de dix ans d’expérience avec Java. Ils ont partagé des exemples concrets d’utilisation de GitHub Copilot en production et dans l’open source, ainsi que les pratiques qu’ils emploient pour transformer les productions générées par l’IA en logiciels fiables.
Voici les conseils qu’ils nous ont partagés.
Vlad Mihalcea
Profil GitHub : @vladmihalcea
Comment GitHub Copilot vous a-t-il aidé récemment ?
Je l’ai utilisé pour analyser, concevoir et implémenter diverses fonctionnalités, tant dans Hypersistence Utils que dans Hypersistence Optimizer.
Par exemple, je souhaitais depuis longtemps développer une application web qui fournisse l’historique des événements d’Optimizer afin que nous puissions voir comment les efforts d’amélioration des performances se concrétisent dans les performances des applications. Avant l’IA, je repoussais sans cesse cette tâche car elle m’aurait pris des semaines à développer. Mais utiliser Copilot, c’est comme avoir un nouveau membre dans l’équipe, alors je l’ai utilisé pour créer une application qui sera livrée dans la prochaine version de Hypersistence Optimizer. Au lieu de semaines, cette tâche n’a pris que deux jours à implémenter.
Quelle est votre utilisation typique ? Utilisez-vous GitHub Copilot comme plugin d’IDE ou l’application GitHub Copilot ?
J’utilise GitHub Copilot dans IntelliJ IDEA parce qu’il est pratique à employer lors de la revue du code source ou pendant une session de débogage.
Il est très utile comme assistant de code, et il m’aide à accélérer à la fois les investigations et la construction de prototypes pour les fonctionnalités qui nécessitent une validation.
Je passe toujours en revue les plans et le code générés par l’IA, car leur objectif est d’améliorer ma productivité, pas de me remplacer entièrement. Bien que l’IA fournisse la bonne réponse dans de nombreuses situations, il arrive encore que la réponse ne soit pas satisfaisante et exige mon intervention.
Pouvez-vous partager des conseils et bonnes pratiques ? Par exemple, quelles skills utilisez-vous ?
J’ai créé mes propres skills afin que tout le texte généré par Copilot ressemble à quelque chose que j’aurais écrit moi-même.
Cette skill capture ma plume à partir de 65 de mes articles publiés, si bien qu’un brouillon revient avec le ton de mon blog plutôt que celui d’un modèle de langage. C’est vraiment utile pour générer la documentation de ce projet, car cela permet au LLM d’apprendre de 12 années de blogging et de fournir des exemples qui suivent les mêmes principes, comme l’expressivité, la testabilité et la simplicité.
Tout au long de ma carrière d’ingénieur logiciel, j’ai appris que nous passons bien plus de temps à maintenir le code qu’à le créer. Par conséquent, comme la maintenance et la stabilité sont essentielles pour les produits existants, j’ai développé des skills qui aident l’IA à imiter les pratiques de code existantes conformément au principe de moindre étonnement.
Un conseil consiste à changer le type de modèle selon le type d’opération. Pour une réflexion approfondie, j’utilise Opus avec la fenêtre de contexte de 1 million et un raisonnement Extra High ou Max. Cependant, pour des tâches plus simples, comme générer des rapports, des notes de version ou vérifier la documentation, j’utilise des modèles plus légers qui consomment moins de tokens.
Patrick Baumgartner
Profil GitHub : @patbaumgartner
Votre travail consiste à accompagner des équipes. Quelle est votre approche ?
Une grande partie de mon travail se déroule alors que l’activité normale doit continuer de fonctionner. On ne peut pas tout arrêter pendant six mois pour « se transformer ». Nous commençons généralement par résoudre ensemble les problèmes immédiats, comprendre où en est actuellement l’équipe, définir où nous voulons aller et comment nous saurons que nous nous améliorons, puis nous avançons vers cet objectif pas à pas.
Selon la situation, cela peut signifier des pratiques de Software Craft telles que le TDD, le refactoring, la livraison continue et XP ; l’architecture et la modularisation avec Spring Boot, Spring Modulith ; Spring Security ; l’optimisation d’applications Java et Spring Boot pour les conteneurs ; ou, de plus en plus, l’ingénierie agentique.
L’important pour moi, c’est que je travaille avec l'équipe. Nous prenons les décisions ensemble. Je ne veux pas qu'une équipe devienne dépendante de moi. Idéalement, après un certain temps, elle n'a plus besoin de moi, sinon peut-être comme partenaire de sparring.
Et peut-être que cela explique pourquoi je trouve cette nouvelle génération d'outils d'IA si intéressante : j'aime travailler avec les gens, apprendre, expérimenter et résoudre des problèmes. L'IA nous offre un autre outil très puissant pour faire exactement cela.
Pouvez-vous raconter une belle histoire sur la façon dont GitHub Copilot vous a récemment aidé ?
Il y a en fait trois exemples très différents qui ont changé ma façon de penser le travail avec GitHub Copilot.
Commençons par le premier.
L'une était la migration d'environ 900 diapositives pédagogiques réparties sur 15 présentations de Reveal.js vers Marp. Ce n'étaient pas des diapositives simples. Beaucoup contiennent du code, des animations et même des exemples interactifs où je peux modifier du JavaScript en direct pendant mes cours. Plus important encore, les présentations avaient déjà été éprouvées auprès des étudiants. Le déroulement fonctionnait. Perdre un petit élément pouvait casser le récit que j'utilise en classe.
Faire cette migration manuellement m'aurait probablement pris une semaine ou plus—et de manière réaliste, j'aurais peut-être simplement évité de la faire tant ce travail était fastidieux.
Avec Copilot, j'ai procédé différemment. Nous avons d'abord analysé le contenu existant, défini l'objectif, établi un plan de migration, fixé des contraintes, fourni des exemples et défini ce qui devait rester intact. Puis nous avons travaillé des grandes modifications structurelles jusqu'aux détails.
La partie vraiment importante était la vérification.
Nous avons généré des captures d'écran des versions Reveal.js et Marp et les avons comparées visuellement et algorithmiquement. Nous avons créé une petite application où je pouvais exécuter les deux jeux de diapositives côte à côte pour vérifier manuellement les animations. Nous avons même comparé les PDF générés.
Cela signifiait que l'agent ne se contentait pas de dire : « Migration terminée. » Nous avions des preuves.
Toute la migration m'a pris environ huit à dix heures. Je restais propriétaire du contenu, de l'intention pédagogique et de chaque modification significative. Copilot pouvait corriger automatiquement une faute de frappe, mais si le contenu, les versions, les dates ou le sens changeaient, c'était quelque chose que nous discutions.
Pour moi, cette expérience a renforcé un principe important : déléguer l'exécution, pas la responsabilité. Je suis propriétaire du résultat.
Pouvez-vous partager le deuxième exemple ?
Un deuxième exemple est venu de la création d'une application d'interface en terminal avec Tamboui. Elle fonctionnait initialement parfaitement sous Linux dans WSL, et j'avais complètement oublié que quelqu'un pourrait l'exécuter directement dans Windows CMD ou PowerShell.
Et puis un véritable utilisateur l'a fait.
Il a découvert que la touche Entrée était simplement ignorée dans certains formulaires. C'est un autre principe auquel je crois fortement : livrer le logiciel tôt, car on apprend de la façon dont les gens l'utilisent réellement.
Nous avons utilisé Copilot pour transformer ce retour en tests d'interface reproductibles. Sous Linux, Copilot naviguait dans l'application avec tmux. En travaillant avec lui, j'ai découvert psmux et j'ai pu exécuter des flux similaires dans PowerShell. Nous avons reproduit le problème, créé un correctif local, remonté le vrai problème jusqu'à Tamboui, et j'ai soumis le correctif en amont, qui a été fusionné.
Au cours de ce travail, les descriptions des tests elles-mêmes sont devenues trop volumineuses pour le contexte disponible. J'ai donc demandé à Copilot de m'aider à repenser la façon dont les tests étaient représentés. Au lieu de tableaux verbeux contenant des identifiants, des noms et des descriptions répétées, il a proposé une notation en flèches beaucoup plus compacte : step → step → input, avec des informations supplémentaires uniquement là où c'était critique.
Cela m'a surpris. Nous n'utilisions pas seulement l'IA pour exécuter des informations ; nous travaillions ensemble sur la façon dont l'information devait être représentée pour l'exécution. Elle n'avait pas à être maximalement conviviale pour l'humain. Elle devait préserver la sémantique tout en étant efficace pour l'agent.
Et le troisième exemple ?
Le troisième exemple est encore complètement différent.
Une personne proche de moi devait s'exercer en mathématiques, et je me suis dit : pourquoi ne pas construire une petite application d'apprentissage ?
Elle couvre l'addition, la soustraction, la multiplication, la division et la division avec reste pour les niveaux de la première à la quatrième année. Mais je ne voulais pas construire une énième application de quiz simple. Avec Copilot, j'ai étudié des approches d'apprentissage telles que la répétition espacée, le retour immédiat, la difficulté adaptative, la motivation, l'apprentissage coopératif et la ludification sans dark patterns.
Fait intéressant, au cours de ces recherches, Copilot a remis en question l'une de mes hypothèses initiales. Je voulais au départ que l'application soit générique pour les enfants partout. Les recherches nous ont orientés vers l'examen du programme scolaire réel. J'ai réalisé que l'ordre d'introduction des sujets, les opérations et les plages de nombres diffèrent suffisamment pour que la rendre « universelle » immédiatement était inutile.
Nous nous sommes donc d'abord concentrés sur la Suisse et avons aligné la progression en conséquence. Comme la Suisse est multilingue, l'application est disponible en allemand, français, italien et anglais.
Elle propose également des modes coopératifs et compétitifs à deux joueurs, et lorsqu'une personne se trompe, l'application explique une façon de résoudre le problème et fait revenir des questions similaires par répétition espacée.
J'ai délibérément choisi une architecture sans backend. Il n'y a aucune raison pour que je collecte des données personnelles d'enfants sur un serveur, donc les données restent sur l'appareil et l'application peut simplement être hébergée sur GitHub Pages.
Ce qui a commencé comme une petite expérience est aujourd'hui utilisé et partagé entre amis. C'est devenu par accident un petit produit.
Cette expérience m'a montré un autre côté de Copilot : ne l'utilisez pas seulement pour implémenter votre solution. Utilisez-le comme partenaire de réflexion pour élargir et remettre en question l'espace des solutions avant de commencer à construire.
Comment utilisez-vous habituellement Copilot ?
En réalité, je n'utilise plus l'expérience classique d'autocomplétion de Copilot.
Mon travail s'est presque entièrement orienté vers les flux de travail agentiques.
J'utilise VS Code lorsque j'ai besoin d'une boucle de retour visuel serrée—quand je veux examiner de près des documents, du code, des présentations ou des résultats intermédiaires et adapter le processus au fur et à mesure.
Pour les tâches plus importantes orientées exécution, je travaille souvent avec l'agent de codage depuis le terminal. Là, je suis plus à l'aise pour déléguer un morceau de travail, le laisser s'exécuter, puis inspecter le résultat complet. L'interface que je choisis dépend surtout de la boucle de retour dont j'ai besoin.
J'ai également vécu une expérience fascinante en utilisant le workflow d'agent de codage via GitHub pendant mon voyage vers JavaLand. J'avais commencé à explorer une idée de plugin Maven qui optimise quelles auto-configurations Spring Boot sont chargées. Durant un trajet d'environ quatre heures, je pilotais l'agent depuis mon téléphone : lui donner une tâche, examiner ce qu'il avait fait, réfléchir à l'étape suivante et envoyer l'instruction suivante.
Au moment où je suis arrivé, j'avais un plugin Maven fonctionnel, un pipeline CI, des tests de performance contre une application d'exemple, et des rapports pouvant démontrer si l'optimisation fonctionnait réellement.
C'était la première fois que je travaillais de cette manière, et j'ai été émerveillé que cela fonctionne réellement. Je n'essayais pas d'écrire du Java sur mon téléphone. Je révisais, décidais et pilotais pendant que l'agent exécutait.
J'utilise aussi des serveurs MCP lorsqu'ils m'apportent des capacités ou du contexte utiles. Par exemple, j'ai utilisé Context7 pour la documentation, des intégrations avec ma base de connaissances Logseq, et j'ai expérimenté une intégration MCP pour Adobe Premiere Pro.
Mais je n'utilise pas MCP simplement parce que je le peux. Si un bon CLI existe, je préfère souvent le CLI car il me semble plus direct et plus rapide.
Dans mon modèle mental, l'agent n'est pas non plus un « développeur junior ». Je le considère beaucoup plus comme un partenaire d'entraînement. Mais comme toute personne rejoignant un projet, il doit d'abord être mis à niveau.
Le contexte est roi.
Pouvez-vous partager quelques conseils et bonnes pratiques ?
La chose la plus importante que je recommande : arrêter le prompt one-shot.
Pour tout ce qui n'est pas trivial, je veux comprendre le problème avant que l'exécution ne commence. Très souvent, je demande explicitement à l'agent de m'interviewer d'abord. Le but de cet entretien est de révéler les hypothèses et attentes qui restent implicites.
Un bon agent peut exécuter une mauvaise idée à une vitesse incroyable. Cela ne rend pas le détour moins coûteux.
J'en ai fait moi-même l'expérience en travaillant sur mon optimiseur d'auto-configuration Spring Boot. Au début, je voulais prendre en charge à la fois Spring Boot 3.5 et 4.x. Il y avait des différences architecturales, nous avons donc implémenté les deux approches. Plus tard, j'ai réalisé que je n'avais plus besoin du chemin 3.5 et son retrait a été douloureux.
La leçon était simple : les détours sont coûteux. Obtenez les bonnes exigences avant d'accélérer.
Une fois l'intention claire, je veux un plan. Lorsque je révise ce plan, quatre choses comptent particulièrement pour moi : les hypothèses sont-elles visibles, des portes de vérification sont-elles définies, l'approche correspond-elle à l'architecture, et évite-t-elle le travail inutile ?
Le second principe est de définir des portes de vérification spécifiques à la tâche.
« Terminé » ne devrait pas signifier que le modèle dit que c'est terminé.
Pour un refactoring, les portes peuvent inclure des tests qui passent, la preuve que tous les fichiers prévus ont été traités, la mise à jour de la documentation et l'absence de TODO laissés derrière. Pour la migration des diapositives, les portes incluaient des captures d'écran, des diffs visuels, les animations, la sortie PDF et la complétude du contenu.
Les portes dépendent de la tâche. Le principe, non : l'agent doit être capable de fournir la preuve que le travail satisfait la definition of done.
J'ai récemment découvert une compétence appelée unlazy qui suit une idée similaire : créer des portes explicites, les parcourir méthodiquement, et prouver qu'elles ont été accomplies plutôt que de prendre des raccourcis.
Le troisième principe est de transformer vos leçons en compétences réutilisables.
J'ai commencé à écrire et à maintenir mes propres Agent Skills. Lorsque j'apprends quelque chose d'une exécution — peut-être que l'agent a mal compris une convention, qu'une vérification utile manquait, ou que j'ai trouvé une meilleure façon d'aborder une tâche — je mets à jour la compétence.
La prochaine fois que j'effectue cette tâche, la leçon est déjà là.
Un exemple est une compétence que j'appelle maintainer-audit, inspirée par le travail de la communauté open agent skills. Je l'utilise dans tous mes dépôts. Elle vérifie et, le cas échéant, corrige ce que j'attends d'un projet maintenu : la documentation du dépôt, les pipelines CI, la configuration Dependabot, CodeQL, un nettoyage cohérent et d'autres normes de projet.
L'objectif n'est pas de générer un autre rapport d'audit pour moi à lire. Elle ramène automatiquement le dépôt vers la base de référence que je souhaite. Cela rend mes projets plus cohérents et plus faciles à maintenir.
Je considère ces compétences comme un savoir-faire d'ingénierie vivant plutôt que des prompts statiques.
Le quatrième principe consiste à entourer le modèle probabiliste d'outils d'ingénierie déterministes.
Je dispose de mon propre harnais de qualité qui encapsule des outils tels que Checkstyle, PMD et les vérifications d'architecture de Spring Modulith, et produit un rapport consolidé que l'agent peut exploiter. Je peux l'exécuter depuis des hooks et laisser l'agent itérer :
modification → exécution des vérifications → lecture des constats → correction → nouvelle exécution.
Le processus continue jusqu'à ce qu'il n'y ait plus aucun constat.
Cela ne signifie pas que je cesse d'examiner le logiciel. Je lance toujours l'application, j'interagis avec elle et je décide si elle se comporte et apparaît comme je m'y attends. Parfois, je mets délibérément en œuvre fonctionnalité par fonctionnalité parce que la boucle de retour est beaucoup plus courte.
J'ai appris que demander tout d'un coup parce que « l'IA peut le faire » est généralement une mauvaise idée. Des spécifications vastes et génériques produisent des implémentations vastes et génériques — et leur nettoyage ensuite peut s'avérer plus difficile que de construire correctement des incréments plus petits.
Plus largement, je pense que nous, développeurs, devrions parler bien davantage de comment nous utilisons ces outils. Partagez les expériences qui ont fonctionné. Partagez celles qui ont échoué. Empruntez-vous des idées les uns aux autres et adaptez-les à votre propre contexte au lieu de chercher un processus de développement IA unique et universel.
C'est aussi pourquoi j'aime l'idée de l'IA comme partenaire d'entraînement. Un vendredi soir, quand je veux expérimenter quelque chose et qu'aucun binôme humain n'est disponible, j'ai soudain quelqu'un—ou quelque chose—avec qui challenger une idée, examiner une approche, ou que je peux utiliser comme un canard en plastique très sophistiqué.
Mais je ramène quand même ces idées à de vraies personnes. Le retour humain, la compréhension du produit et le contexte réel restent essentiels.
Comment pensez-vous que l'IA transforme notre profession ?
Je ne pense pas que les étudiants en génie logiciel devraient principalement aspirer à devenir des machines à produire du code. Ils doivent devenir de forts résolveurs de problèmes. Ils doivent comprendre les utilisateurs et les parties prenantes, découvrir le vrai problème derrière une exigence, challenger les hypothèses, comprendre les produits et les marchés, faire des arbitrages architecturaux, penser de manière critique, travailler de façon structurée et transférer des solutions utiles d'un contexte à un autre.
Le modèle est extraordinairement bon pour générer des possibilités et exécuter des choses. Mais en tant qu'humain, je connais généralement une bien plus grande partie du contexte réel—including les choses que personne n'a jamais documentées.
Donc je veux rester maître de la conception de la solution et laisser l'agent prendre en charge davantage d'exécution.
En ce sens, je pense que l'IA remet l'ingénierie dans le génie logiciel.
Et j'aime ça.
Frank Delporte
Profil GitHub : @FDelporte
Comment vous êtes-vous lancé dans la tech ?
Je suis fasciné par les ordinateurs depuis que j'ai eu un Commodore 64 quand j'avais 11 ans. J'ai fait quelques détours par la production vidéo et le travail télévisé après l'école, mais je suis revenu au code parce qu'il fallait mettre cette vidéo sur DVD et créer les tout premiers sites web… Oui, je suis de cette génération ;-).
Comment GitHub Copilot vous a-t-il aidé récemment ?
C'est un compagnon parfait pour évaluer les pull requests et enquêter sur les rapports de bogues.
Une histoire remarquable concerne la bibliothèque Pi4J qui permet de créer des applications Java pour interagir avec des composants électroniques sur le Raspberry Pi. En février 2026, nous avons publié la V4 qui inclut un nouveau plugin utilisant l'API Foreign Function & Memory. Nous l'avons testée minutieusement avant la publication, mais tout de même, peu après la sortie, quelqu'un a signalé que l'utilisation de 5 boutons d'entrée ne fonctionne pas comme prévu. Appuyer sur l'un des quatre premiers boutons configurés déclenche une exécution de code comme prévu, tandis que rien ne se passe avec le cinquième bouton.
C'est le genre de rapport que l'on ne veut pas recevoir. Rien n'était visiblement cassé. Aucune exception, aucun avertissement dans les logs, le cinquième bouton était simplement silencieux. Et cela empirait : avec l'ancien plugin gpiod, exactement le même matériel et exactement la même application fonctionnaient parfaitement. Donc le problème se trouvait dans notre nouveau code FFM, qui repose sur le périphérique de caractères GPIO du noyau Linux et communique avec lui via des appels natifs. Ce n'est pas la partie de la base de code où l'on s'attend à trouver une réponse rapide.
J'ai donc assigné l'issue à l'agent de codage Copilot et je lui ai donné deux chemins de fichiers comme point de départ, la classe provider et FFMDigitalInput. Environ une demi-heure plus tard, il y avait une pull request, avec une explication que je n'avais vraiment pas prévue.
Chaque entrée exécute un observateur d'événements qui se bloque dans un appel natif poll() , en attendant que le noyau signale un changement sur sa ligne GPIO. Ces observateurs s'exécutaient dans des threads virtuels. Et un thread virtuel qui se bloque dans un appel natif ne peut pas être démonté de son thread porteur. Il y reste épinglé pendant toute la durée de l'appel. Un Raspberry Pi 4 a quatre cœurs, donc l'ordonnanceur de threads virtuels dispose de quatre threads porteurs. Enregistrer quatre entrées, et les quatre porteurs sont garés dans poll() pour toujours. Le cinquième observateur est créé, mais n'est jamais programmé. C'est exactement le bogue qui a été signalé. Pas « les événements sont erratiques », mais « le cinquième ne fait rien ».
Ce que j'ai le plus apprécié, ce n'est pas le diff, c'est la conversation qui a suivi lors de la revue. J'ai laissé un commentaire demandant à Copilot d'expliquer cela plus en détail :
Je pensais que le but des threads virtuels était justement de s'affranchir de la limite des threads plateforme ? Alors comment est-ce un problème que quatre threads virtuels bloquent les quatre threads sur un processeur à quatre cœurs comme le Raspberry Pi ?
Consultez la pull request pour la conversation complète. Copilot a pu relier l'utilisation du Raspberry Pi qui a quatre cœurs CPU au problème signalé. Il a pu proposer une correction simple du problème, plus quelques améliorations supplémentaires qu'il a découvertes lors de son enquête.
Pouvez-vous partager des conseils et bonnes pratiques ?
- Indiquez-lui où chercher : Pour le problème Pi4J n° 622, j'ai ajouté deux chemins de fichiers. C'est un tout petit effort qui évite énormément de recherches dans une large base de code. On a généralement une intuition du quartier même quand on n'a aucune idée du bug. Donnez-la à l'outil pour qu'il n'ait pas besoin d'examiner tout le code.
- Demandez des preuves et des tests : « Ajoute un test unitaire pour valider la modification » est quelque chose que je demande très souvent ces derniers temps. Enfin, demandais, parce que c'est devenu une règle dans mon fichier d'instructions. Cela évite aussi les cas où le diagnostic était erroné, car le test n'échouera pas sur l'ancien code.
- Demandez pourquoi : Si vous ne comprenez pas une correction, dites-le et posez la question. L'explication est aussi un livrable et devrait être ajoutée à la documentation de votre projet ou dans le ticket ou la pull request. Cela instruit tous ceux qui liront l'information plus tard. Par exemple, cela a également suscité davantage de questions au sein de l'équipe Pi4J sur le blocage des threads virtuels lors des appels natifs.
- Gardez le contrôle : Toutes ces pull requests dans Pi4J ont été relues et approuvées par les mainteneurs avant leur intégration. C'est le modèle qui fonctionne le mieux dans ce projet : l'agent fait l'investigation, les humains restent responsables de ce qui est livré. Mais pour mes autres projets également, je relis toujours le code généré par l'outil. Je veux toujours garder un code lisible et maintenable. Trop souvent, un outil crée des méthodes en double ou recrée quelque chose qui existe déjà ailleurs et qui devrait être fusionné. C'est votre responsabilité. Vous pouvez aller très vite de nos jours avec le codage assisté par l'IA, ce qui signifie aussi que vous pouvez créer très rapidement un désordre. Ne le faites pas, gardez votre code gérable, vos collègues et votre futur vous remercieront s'ils doivent investiguer des bugs ou apporter des améliorations plus tard.
Commencer avec GitHub Copilot >
Étiquettes :
Écrit par
Principal Cloud Advocate
Articles associés
AI & MLComment poursuivre une session d'application GitHub Copilot dans VS Code
Apprenez à déplacer une session d'agent de l'application GitHub Copilot vers VS Code sans perdre la conversation, les modifications de code ou le contexte de travail.
AI & MLLe modèle de GitHub pour la détection de secrets : trouver plus de secrets avec moins de bruit
Le classificateur de secrets tenant compte du contexte de GitHub améliore la qualité de la détection, augmente l'acceptation pondérée de 11.5 % et réduit le temps médian d'exécution des analyses de 86 %.
AI & MLL'application GitHub Copilot pour débutants : comment apprendre à Copilot à connaître votre base de code
Apprenez à ajouter des instructions et des compétences personnalisées à votre dépôt, à utiliser des agents personnalisés et à connecter des serveurs MCP comme Playwright.