· · 2 minutes de lecture

Le meilleur conseil GitHub Copilot pour les développeurs .NET en ce moment est d'arrêter de penser en termes de fonctionnalités

Un nouveau guide GitHub Copilot centré sur .NET avance un point fort : la meilleure façon d'obtenir de la valeur n'est pas de mémoriser les modes de Copilot, mais d'aligner la surface de l'outil sur la tâche réelle à accomplir.

GitHub Copilot .NET Visual Studio VS Code Developer Productivity
Cet article est aussi disponible en :English, Español, Català, Deutsch, Português, Italiano, 日本語, 中文, 한국어, Русский, हिन्दी, Polski, Türkçe, العربية, Bahasa Indonesia, Nederlands

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Je pense que l’un des changements les plus utiles dans l’adoption de Copilot est de sortir de l’obsession des fonctionnalités.

C’est exactement pour cela que ce nouveau guide GitHub Copilot pour les développeurs .NET fonctionne si bien.

L’idée principale est simple : arrêtez de demander quel mode de Copilot est le plus cool, et demandez plutôt quelle surface correspond à la tâche.

C’est le bon modèle mental

Pour la plupart des vrais travaux .NET, la question n’est pas :

  • chat ou agent ?
  • Visual Studio ou CLI ?
  • inline ou cloud ?

La meilleure question est :

  • est-ce que j’essaie de comprendre du code ?
  • est-ce que je planifie un refactoring ?
  • est-ce que je mets à jour des tests ?
  • est-ce que je corrige un build cassé ?
  • est-ce que je coordonne un changement qui touche plusieurs fichiers ?

C’est une façon bien plus productive de travailler avec Copilot.

La phrase la plus utile de l’article source

La phrase que je soulignerais dans l’article d’origine est celle-ci :

La question n’est pas de savoir lequel est le plus avancé. La meilleure question est : lequel correspond à la tâche que je fais en ce moment ?

C’est exactement le conseil que je donnerais aussi.

Parce qu’une grande partie de la confusion autour des outils d’IA vient du fait qu’on traite les surfaces comme des identités plutôt que comme des outils.

Visual Studio, VS Code, CLI et les agents en arrière-plan conviennent à des moments différents.

Et une fois qu’on accepte cela, toute l’expérience devient beaucoup plus pratique.

Pourquoi cela compte particulièrement pour les équipes .NET

Le travail .NET couvre souvent plusieurs types de tâches dans une seule journée :

  • comprendre un service legacy
  • planifier un refactoring
  • générer des tests
  • corriger un build cassé
  • toucher du code, de la config, de la doc et de l’infrastructure ensemble

Cela signifie qu’aucune surface Copilot ne sera la meilleure pour tout.

C’est pourquoi le conseil de ce guide est bon, parce qu’il reflète la manière dont le travail se passe réellement.

Mon avis

Ce guide est utile parce qu’il traite Copilot comme une partie de la boucle réelle de développement .NET, et non comme une couche de nouveauté au-dessus.

Cela le rend pertinent.

Et franchement, davantage de guides IA seraient améliorés par ce même passage vers une pensée d’abord centrée sur la tâche.

Article original : Doing More with GitHub Copilot as a .NET Developer

Partager :
Voir le code source de cet article sur GitHub ↗
← Arrêtez de Pilonner une Dépendance en Difficulté : Patterns de Retry pour Azure Functions + Service Bus
Azure SQL Peut Maintenant Générer des Embeddings — En T-SQL Pur, Sans Couche Applicative →