Gains :
- Capacité à distinguer où l'IA apporte une réelle vitesse dans le cycle de vie du développement logiciel et où la décision et la responsabilité reviennent à l'ingénieur
- Capacité à appliquer une discipline d'ingénierie à trois niveaux qui vérifie chaque code et conception produit par le biais de la compilation, des tests et de l'examen.
- Prenez l'habitude d'effacer le contexte pour tirer parti de l'IA sans partager le code source confidentiel, les informations d'identification et les données client.
Lorsque vous regardez la journée d'un ingénieur informaticien, la situation est similaire dans la plupart des équipes : comprendre une demande commerciale, concevoir, écrire du code, lire le code de quelqu'un d'autre, déboguer (le processus consistant à découvrir pourquoi un programme ne fonctionne pas correctement et à le corriger), rédiger des tests, préparer la documentation, réviser le code et assister à des réunions. En d’autres termes, le temps consacré au véritable « jugement technique », c’est-à-dire à la question de savoir si une solution est correcte, sûre et durable, est écrasé par un travail répétitif. C’est là qu’intervient l’intelligence artificielle (IA en abrégé ; logiciel qui fonctionne sur du texte et du code avec un grand modèle de langage). L'IA ne prend pas la décision à votre place ; Il vous prépare à la décision, produit un squelette de code, affine le bogue et vous présente un brouillon travaillé. Tout au long de ce module, nous positionnerons l'IA non pas comme un « programmeur automatique », mais comme un partenaire de programmation en binôme discipliné dont les résultats sont compilés, testés et révisés à chaque fois.
Dans cette première unité, nous clarifions trois choses : à quelles étapes du cycle de vie du développement logiciel (les étapes par lesquelles passe un logiciel de l'idée à la production : analyse, conception, codage, tests, déploiement, maintenance) l'IA ajoute-t-elle une réelle valeur ; quelles décisions doivent rester strictement du ressort de l'ingénieur ; et quelle est la discipline de vérification et de confidentialité que vous devez respecter lors de cette opération. Sans ce toit installé correctement, les techniques appliquées aux unités suivantes peuvent devenir dangereuses ; Parce qu’une erreur dans le logiciel atteint des millions d’utilisateurs en même temps et peut se transformer en faille de sécurité.
Concepts : Hallucination : fabrication convaincante par l'IA d'une méthode, d'une bibliothèque, d'une API ou d'un comportement qui n'existe pas réellement. Contexte : L'entrée que vous donnez à l'IA (code, message d'erreur, exigence, contraintes). Vérification : Vérification du résultat de manière indépendante (compilation, tests, documentation). Ces trois concepts constituent l’épine dorsale de l’ensemble du module.
Dans quelles entreprises l’IA Accelerator est-il utilisé, dans quelles entreprises est-ce risqué ?
Les emplois dans le domaine des logiciels se situent sur un spectre à deux volets en termes de résultats. À une extrémité se trouvent des travaux de préparation réversibles et à faible risque ; À l’autre extrémité, il existe des tâches difficiles à restituer qui entrent dans l’environnement de production et peuvent entraîner des pertes de données, des failles de sécurité ou des interruptions. La valeur de l’IA varie en fonction de votre position sur ce spectre.
type d'entreprise
Contribution de l'IA
Le rôle de l'ingénieur
Squelette de code / passe-partout
Génération rapide de structure répétitive
Contrôle de l'état de la logique et des fronts
débogage
Hypothèse et liste des causes possibles
Reproduction et confirmation de la cause profonde
tests d'écriture
Projet de test et création de scénarios
Vérification significative des assertions et de la portée
refactorisation
Proposition de refactorisation
Maintenir le comportement grâce aux tests
Documentation
Première ébauche et structure
Vérification de l'exactitude par rapport au code
Décision architecturale/sécurité
Liste des options et avantages et inconvénients
Décision finale et responsabilité
La règle est simple : le risque d’une sortie de l’IA est égal aux dommages qu’elle subira si cette sortie commet une erreur. Suggérer incorrectement un nom de variable est inoffensif ; Une authentification incorrecte (vérifier que l'utilisateur est bien celui qu'il prétend être) rend l'ensemble du système vulnérable. La première question à se poser avant d'utiliser le résultat est donc : "Que se passe-t-il si cela ne va pas, qui le remarque et quand ?"
Attention : l'IA produit un code fluide et fiable. La maîtrise n’est pas une garantie d’exactitude. Un modèle de langage peut produire de manière crédible un nom de fonction qui n'existe pas réellement, une séquence de paramètres incorrecte ou même un modèle dangereux. Dans le logiciel, cela ne reste pas sur papier ; Il se compile, s'exécute et explose en production.
Des décisions qui devraient être laissées à l’ingénieur
Certaines décisions ne devraient jamais être entièrement automatisées ; comporte des risques techniques, juridiques et éthiques :
- Approbation pour la production : La mise en production d'un code et la responsabilité de celle-ci.
- Sécurité et architecture : décisions coûteuses telles que l'authentification, l'autorisation, le cryptage et le modèle de données.
- Licence et droit d'auteur : Utilisabilité du code produit dans le produit commercial et conformité de la licence.
- Travailler avec des données confidentielles : transactions avec des données client, des secrets de code source et des informations d'identité.
Attention : même si l'IA dit "ce code est sécurisé et prêt pour la production", l'accepter sans tests de sécurité, revue et validation du code sous charge réelle est inacceptable. Dans les travaux critiques pour la sécurité, les résultats de l’IA ne remplacent jamais l’approbation d’un ingénieur compétent ; Tout résultat menant à une décision doit être vérifié et approuvé de manière indépendante par l’ingénieur agréé avant sa mise en œuvre.
Discipline de vérification : contrôle à trois niveaux
Appliquez trois niveaux de contrôle pour utiliser les résultats de l’IA comme un évaluateur principal plutôt qu’aveuglément. C’est le réflexe de base que nous répéterons tout au long du module.
- Compilation et vérification statique : le code est-il réellement compilé/exécuté ? Y a-t-il des erreurs de type, des variables inutilisées, des API inexistantes ? Que dit l’outil d’analyse statique (l’outil qui examine le code sans l’exécuter) ?
- Reproduction indépendante (test) : exécutez le code avec de petites entrées connues et voyez si vous obtenez le résultat attendu. Essayez les cas extrêmes (nul, zéro, négatif, énorme).
- Vérification de la source : chaque API, version de bibliothèque et fonctionnalité de langage utilisée par l'IA doit être vérifiée à partir de la documentation officielle.
Invite de vérification (facilite la vérification du résultat) : "Répertoriez TOUTES les bibliothèques, méthodes et fonctionnalités de langage externes que vous utilisez dans votre code. Pour chacune d'elles, indiquez dans quelle version elle est disponible et étiquetez-la 'doit être vérifiée à partir de la documentation'. N'inventez pas d'API dont vous n'êtes pas sûr ; si vous n'êtes pas sûr, écrivez clairement « pas sûr ». Répertoriez également tous les cas extrêmes que vous n'avez pas abordés dans une liste distincte. "
Critiquez votre propre invite de code : « Regardez d'un œil critique le code que vous venez d'écrire, comme un ingénieur senior qui vous a embauché. Donnez des éléments concrets sous ces trois rubriques : (1) erreurs de logique/cas extrêmes, (2) risques de sécurité, (3) problèmes de performances ou de lisibilité. Pour chaque élément, écrivez « pourquoi le problème » et « solution suggérée ». S'il n'y a pas de problème, dites « Je n'ai pas trouvé de problème » ;
Invite faible/Invite forte
FAIBLE : "Écrivez-moi une fonction d'authentification utilisateur." (Résultat : ne sait pas quelle langue, quelle règle, quel comportement d'erreur ; code générique, souvent non sécurisé ou hors contexte.) FORT : "Écrivez une fonction de validation d'e-mail pour Python 3.11. Entrée : chaîne. Sortie : vrai si valide, faux sinon. Règles : chaîne vide Faux ; aucune conformité RFC requise, le format de base est suffisant. NE PAS UTILISER de bibliothèque externe. Un test de 5 échantillons sous le bloc d'ajout de fonction : valide, vide, pas de '@', double '@', contenant uniquement des espaces."
La différence est dans le contexte. Invite puissante ; Il comprend la langue, la version, le contrat d'entrée-sortie, les contraintes et les attentes du test. Cette seule discipline réduit considérablement le risque d’hallucinations et de codes dangereux.
Mini-étuis
Cas 1 — Méthode artificielle. Un développeur apprend de l'IA qu'il existe une méthode appelée date.addBusinessDays(5) dans une bibliothèque de dates et elle est expliquée de manière confiante. En regardant la documentation, il voit qu’une telle méthode n’existe pas, la bonne méthode est une boucle manuelle. L'hallucination est capturée avant d'être mise en production avec une vérification de 10 minutes.
Cas 2 — Perte d’état Edge. L'IA produit une fonction « calculer la moyenne » ; Cela fonctionne lorsqu'il est testé avec 1 000 lignes de données. Cependant, lorsque la liste est vide, elle donne une division par erreur nulle. Depuis que l'ingénieur a ajouté le test d'entrée vide, il voit et corrige l'erreur avant qu'elle ne soit mise en ligne. Un test de condition de front unique empêche une alarme de production à 3 heures du matin.
Cas 3 — Risque pour la vie privée. Un expert est sur le point de coller un fichier contenant une véritable chaîne de connexion à la base de données et une clé API dans un outil public. Se souvient de la politique de l'établissement ; Il remplace les secrets par <SUPPRIMÉ>, réduit le code à un exemple représentatif et le demande. Ainsi, il obtient de l'aide en 5 minutes, mais ses informations d'identité ne sortent pas.
Principe de travail avec le code secret et les informations d'identité
La partie la plus sensible du logiciel ; secrets du code source, informations d’identité (clé API, mot de passe, jeton) et données client/personnelles. Principe de base : faire le ménage avant de partager, ne demander que l'essentiel du problème avec un exemple représentatif si possible.
Modèle d'invite anonymisé : "Il y a une erreur dans la fonction suivante. J'ai remplacé la logique métier réelle et les constantes cachées par des valeurs représentatives (clé API, noms de tables, noms de champs génériques). Problème : j'obtiens l'erreur Y dans l'entrée X. Trouvez simplement l'erreur logique dans ce code représentatif et expliquez la version corrigée. [code représentatif]"
Astuce : en cas de doute, faites ce test : « Mon organisation aurait-elle des problèmes si j'écrivais ceci publiquement sur un forum ? » Même si la réponse n’est pas claire, clarifiez-la d’abord. Réinitialiser est toujours moins cher que de rechercher la fuite plus tard.
Erreurs courantes
- Utiliser la sortie sans compiler/tester. « AI a écrit » n’est pas une justification ; Chaque morceau de code est vérifié en l'exécutant.
- Faire des demandes sans contexte. Si la langue, la version, les entrées-sorties et les contraintes ne sont pas indiquées, le code devient générique et souvent peu sécurisé.
- Partager des informations confidentielles sans réfléchir. La clé API, le mot de passe et les données client ne doivent pas être divulgués sans avoir été effacés.
- Confondre langage précis et exactitude. Plus l'IA parle avec confiance, plus vous devez être prudent ; Un ton confiant n’est pas une preuve.
- Déléguer la décision à l’IA. La décision de mise en production, de sécurité et d'architecture appartient à l'ingénieur ; L'IA ne produit que des matériaux.
En résumé
L'IA accélère les parties répétitives et chronophages du travail logiciel : squelette de code, rédaction de tests, réduction des bogues, documentation. Cependant, la décision et la responsabilité appartiennent à l'ingénieur. Chaque sortie doit passer trois niveaux de contrôle (compilation/statique, tests, source). Écrire des invites avec du contexte et effacer les informations cachées sont deux habitudes clés que nous répéterons dans chaque unité de ce module. Lorsque vous utilisez l’IA avec discipline, vous gagnez en vitesse ; lorsque vous l’utilisez sans discipline, vous transférez des erreurs et des vulnérabilités en production.
Tâche de candidature
Choisissez une petite tâche de codage issue de votre propre travail ou d'un projet imaginaire (par exemple une fonction de validation). Écrivez d’abord une invite faible et obtenez le résultat. Appliquez ensuite le puissant modèle d'invite de cette unité : ajoutez la langue/la version, le contrat d'entrée-sortie, les contraintes et les attentes de test. Mettez les deux impressions côte à côte et notez la différence. Compilez ensuite la sortie robuste et testez-la avec au moins trois cas extrêmes (format nul, zéro/négatif, inattendu) et notez ce que vous trouvez dans quel test.
liste de contrôle
- [ ] J'ai ajouté la langue, la version et le contrat d'entrée-sortie à l'invite.
- [ ] J'ai écrit "Ne l'inventez pas, dites-moi si vous n'êtes pas sûr" et la contrainte de portée.
- [ ] J'ai compilé/exécuté le code, vérifié les avertissements statiques.
- [ ] J'ai testé avec au moins trois cas extrêmes.
- [ ] J'ai vérifié les API utilisées à partir de la documentation officielle.
- [ ] J'ai effacé tout code secret/identifiant ou utilisé un outil d'entreprise.
- [ ] J'ai confirmé que la décision de mise en production et de sécurité appartient à l'humain.