Gains :
- Capacité à expliquer le fonctionnement d'un assistant de codage comme modèle de langage et les concepts de jeton, de fenêtre contextuelle, d'hallucination
- Capacité à distinguer les tâches logicielles où l'IA est forte et faible avec une carte mentale
- Capacité à appliquer le cycle de travail de base de proposer-produire-vérifier à leurs propres tâches
La journée d'un développeur de logiciels est rarement consacrée à "écrire du code à partir de zéro". Temps réel; Lire le code écrit par quelqu'un d'autre, essayer de reproduire un bug, analyser le journal (lignes de journal produites par l'application lors de son exécution), rédiger des tests, rédiger un PR (pull request - une demande de fusion où un changement de code est soumis à l'examen de l'équipe) explication et mise à jour de la documentation. L’intelligence artificielle (IA) est un multiplicateur de vitesse qui peut toucher presque tous ces emplois invisibles. Mais la première condition pour l’utiliser en toute sécurité est de bien comprendre ce que c’est et ce que ce n’est pas.
Dans cette unité, nous expliquons d'abord la technologie sous-jacente d'un assistant de codage en langage simple ; puis nous créons une carte mentale des forces et des faiblesses du modèle ; Enfin, nous établissons la discipline de travail de base que nous utiliserons tout au long du module : proposer, produire, vérifier. Ces trois étapes constituent l’épine dorsale des onze unités suivantes.
Remarque : Ce module est une formation générale. Dans les logiciels critiques en matière de sécurité (traitement des paiements, soins de santé, authentification, infrastructure critique), les résultats de l'IA ne remplacent pas l'examen et l'approbation par un ingénieur qualifié. L'IA est un assistant ; Le signataire est l'ingénieur.
Que fait réellement un assistant de codage ?
La plupart des assistants de codage sont construits sur un grand modèle de langage (LLM – une IA entraînée sur d'énormes quantités de texte et de code qui prédit le prochain « fragment » le plus probable). Le modèle ne « comprend » pas le code comme un humain ; Il génère la continuation la plus probable du contexte que vous lui donnez, sur la base des modèles qu'il apprend à partir d'un vaste bassin d'exemples. Ce mécanisme apparemment simple donne des résultats étonnamment efficaces dans la pratique, car la plupart des logiciels consistent en des modèles répétitifs : une requête HTTP, une boucle, une vérification nulle, un modèle de test.
Trois termes sont ici critiques. Le jeton est la plus petite unité que le modèle traite en divisant le texte ; Il s'agit à peu près de quelques lettres ou d'une partie d'un mot. La fenêtre contextuelle correspond à la quantité de jetons que le modèle peut « voir » à la fois ; Votre code, message d'erreur et instructions doivent tenir dans cette fenêtre. Une invite correspond à toutes les instructions et au contexte que vous donnez au modèle. La qualité du résultat que vous obtenez dépend directement de ces deux éléments : plus vous donnez un contexte et des instructions claires au modèle, meilleur sera le résultat que vous obtiendrez. Une mauvaise entrée produit une mauvaise sortie, même s’il s’agit d’un modèle intelligent – la règle classique du logiciel « garbage in, garbage out » s’applique également à l’IA.
Carte des forces et des faiblesses
Pour orienter l’IA vers les bons métiers, il est nécessaire de savoir où elle brille et où elle trébuche. Mémoriser cette carte vous fera vous demander à chaque prochaine mission : « Dois-je confier ce travail à l'IA ou le faire moi-même ? Il vous permet de répondre à la question en quelques secondes.
Ses points forts sont : Générer du code passe-partout, traduire d'un langage à un autre, écrire une expression régulière (regex), décrire une fonction, créer un squelette de test, interpréter un message d'erreur, rédiger une documentation, suggérer des noms de variables/fonctions et des refactorisations mineures (améliorer la structure du code sans changer son comportement).
Faiblesses : connaître les règles commerciales spécifiques à votre entreprise, mémoriser l'intégralité de votre base de code, exécuter et vérifier réellement le code, connaître avec certitude les dernières versions de la bibliothèque, détecter les vulnérabilités de sécurité avec une garantie à cent pour cent. Le plus dangereux, c'est l'hallucination : le modèle invente une fonction, une bibliothèque ou une API (interface permettant l'échange de données entre applications) inexistante dans un langage très convaincant. Ce risque peut en réalité être tourné à votre avantage, puisque le code, contrairement au texte brut, peut être testé pour voir s'il « fonctionne » – mais ne sautez pas l'étape de vérification.
Type de mission
Le rôle de l'IA
le rôle de l'homme
Produire un passe-partout/un squelette
produit un brouillon
Adapte, révise
Description des codes
Donne un résumé rapide
Vérifie la partie critique du code
tests d'écriture
Le cas suggère
Confirme la couverture et l'exactitude
Logique critique pour la sécurité
idée utile
La décision et la responsabilité incombent entièrement aux humains.
Utilisation de l'API/bibliothèque
Génère un échantillon
Vérifie l'existence et la version
décision architecturale
Sortes d'options
Sélectionne et défend en connaissant le contexte
Étape par étape : cycle de travail de base
- Clarifiez la tâche. Si vous ne pouvez pas écrire ce que vous voulez en une seule phrase, le modèle non plus. Plus l’incertitude s’infiltre tôt dans l’intrant, plus elle augmente dans la production.
- Donnez du contexte. Ajoutez le code pertinent, le message d'erreur complet, la version du langage/du framework et les contraintes à l'invite. Ne dites pas "réparez ça", dites "Python 3.11, FastAPI 0.110 ; cette fonction donne une erreur 500, elle explose lorsque le corps de la requête est vide".
- Rôle et format de l'imposition. Un cadre tel que « Vous êtes un développeur Go senior ; donnez simplement le code et une justification en deux phrases » concentre le résultat.
- Demandez petit. Décomposez-le en étapes plutôt qu'en une seule demande géante ; Vérifiez chaque étape séparément. Les changements majeurs sont risqués car ils sont difficiles à vérifier et susceptibles de cacher des erreurs.
- Vérifier. Exécutez-le, testez-le, lisez-le visuellement. Le code IA non vérifié est un « croquis », pas une « solution ». C’est l’étape la plus non négociable du cycle.
Trois mini-étuis
Cas 1 — Les gains de temps sont réels mais modestes. Lorsqu'une équipe a squelettisé de nouveaux points de terminaison CRUD (Create-Read-Update-Delete) avec l'IA, le temps de première ébauche est passé d'environ 40 minutes à 8 minutes. Cependant, après examen et tests, la durée totale était de 25 minutes ; le gain réel est donc de 40 à 25, soit environ 38 %. Ce rythme, mesuré au lieu de l’attente du « nous avons accéléré 10 fois », constitue un gain durable.
Cas 2 — L’hallucination coûte cher. Un développeur a utilisé l'appel request.get_json() suggéré par l'IA sans validation ; Une telle méthode n’existait pas (précisément Response.json()). 20 minutes ont été perdues lorsque le code n'a pas été compilé. Un simple « est-ce que cette méthode existe vraiment ? la vérification réinitialiserait la perte.
Cas 3 — Un bon contexte double le résultat. Pour le même bug, un développeur a simplement écrit "Je reçois une erreur" et l'autre a ajouté la trace complète de la pile, la version et l'échantillon d'entrée. Ce dernier a trouvé la bonne solution du premier coup ; Le premier a passé trois tours. La différence ne résidait pas dans le modèle, mais dans l’entrée.
Quatre modèles copiables
Une invite de démarrage puissante et à usage général :
Rôle : Vous êtes un développeur {{langue}} expérimenté.Tâche : {{what_want}}Contexte :- Framework/version : {{framework_and_version}}- Contraintes : {{performance, style, règles de dépendance}}Règles :- Ne pas utiliser de bibliothèque/fonction inexistante ; Si vous n'êtes pas sûr, marquez-le comme « vérifier ». - Donnez d’abord un petit plan, puis le code, puis 2 phrases de justification. - Produire du code testable et fonctionnel.
Pour filtrer l'incertitude dans le modèle :
Avant de résoudre la tâche ci-dessous, énumérez AU MOINS 3 points que vous trouvez manquants ou peu clairs comme questions. N'écrivez PAS de code avant de répondre. Tâche : {{task}}
Pour que la sortie soit auto-vérifiée :
Vous avez produit le code suivant. Changez maintenant de rôle et critiquez ce code : - Citez 3 cas (cas extrêmes) qui pourraient ne pas fonctionner. - Y a-t-il des API/fonctions que vous auriez pu inventer ? Mark.- Donner la version corrigée.Code :{{code}}
Pour décomposer une décision en options :
Suggérez 2 à 3 approches de solution pour {{problème}}. Pour chacun : brève description, plus/moins, quand choisir. Donnez sous forme de tableau. NE choisissez PAS à ma place ; clarifiez simplement l'option.
Invite faible/Invite forte
Faible : "Corrigez le bug dans ce code." (Quelle erreur ? Quelle langue ? Quel est le comportement attendu ?)
Strong : "Python 3.11 / FastAPI 0.110. Le point de terminaison suivant renvoie 500 avec KeyError lorsque le corps de la requête est vide ; je veux qu'il renvoie 400 et un message significatif sur un corps vide. Expliquez d'abord la raison, puis donnez la fonction corrigée, puis écrivez un test pour ce scénario. [code]"
Version puissante ; Il donne la langue, la version, l'erreur réelle, le comportement attendu et le format de sortie. Le modèle n'a plus besoin de prédire.
Erreurs courantes
- Faire confiance sans vérification. L'erreur la plus courante et la plus coûteuse. Ne dites pas "résolu" tant que le code n'est pas compilé et testé.
- Poser des questions sans contexte. La réponse sans version, texte d'erreur et restrictions est générique et souvent fausse.
- Une énorme demande. Ne pas pouvoir demander et examiner simultanément une production de 300 lignes rend les erreurs invisibles.
- Prendre la confiance en soi du modèle comme une preuve. L’IA peut dire quelque chose de mal en toute confiance ; Le ton n’est pas un indicateur de précision.
- Coller au hasard le secret de l'entreprise. Les clés privées, les données client ou le code source privé ne doivent pas être saisis dans des outils non approuvés (nous aborderons ce sujet dans l'unité 10).
Astuce : Traitez chaque sortie de l'IA comme « il s'agit d'un brouillon ». Cette seule habitude mentale éteint la plupart des risques que vous verrez tout au long du module.
En résumé
Un assistant de codage est un modèle de langage qui prédit le prochain fragment le plus probable ; Il ne comprend pas le code, il produit des modèles. C'est pourquoi il est fort dans les tâches répétitives et stéréotypées ; Il doit être utilisé avec prudence pour les travaux nécessitant une vérification spécifique à votre contexte. Le plus grand risque est l’hallucination et le seul antidote est la vérification. La discipline que nous suivrons tout au long du module est claire : clarifier la tâche, donner du contexte, demander des petits, valider chaque livrable.
Tâche de candidature
Notez trois tâches logicielles que vous avez effectuées au cours de la semaine dernière (par exemple, une correction de bug, un test, une mise à jour README). Regardez la « carte des forces et des faiblesses » de chacun et décrivez en une phrase quel serait votre rôle et celui de l’IA si vous demandiez à l’IA de faire cela. Ensuite, confiez l'une de ces tâches à l'IA avec le modèle « invite de démarrage » ci-dessus, puis exécutez et vérifiez la sortie ; Notez combien de minutes vous avez économisées et combien d’erreurs vous avez dû corriger.
liste de contrôle
- [ ] J'ai réalisé que LLM produit des modèles et ne « comprend » pas le code.
- [ ] Je peux expliquer les concepts de jeton, de fenêtre contextuelle et d'invite en une phrase.
- [ ] Je peux distinguer les types de tâches pour lesquelles l'IA est forte et faible.
- [ ] Je sais ce qu'est une hallucination et le seul antidote est la vérification.
- [ ] J'ai adapté le cycle « proposer, produire, vérifier » à ma propre tâche.
- [ ] Je peux montrer la différence entre une invite forte et une invite faible dans un exemple concret.