L’IA qui écrit du code va-t-elle remplacer les programmeurs?

Deux annonces en moins de trois semaines ont mis cette question dans la tête de bien des développeurs. Le 29 juin, GitHub a ouvert un aperçu technique limité de Copilot, un outil qui propose des lignes et des fonctions entières dans l’éditeur Visual Studio Code. Une semaine plus tard, OpenAI a mis en ligne un article de recherche décrivant Codex, la famille de modèles qui l’alimente. Voir un commentaire se transformer en fonction qui marche est saisissant, et il est naturel de se demander ce qu’il adviendra des personnes qui écrivent du code pour gagner leur vie.

Une réponse honnête part des mesures plutôt que des démonstrations. Elles décrivent un outil souvent utile et souvent dans l’erreur, ce qui est très différent d’un remplaçant. Pour comprendre pourquoi, il est utile d’examiner ce qui a été testé et ce que contient vraiment la journée de travail d’un programmeur.

Ce que disent vraiment les résultats des tests

L’article sur Codex présente un banc d’essai appelé HumanEval. Chaque problème est une courte fonction Python décrite uniquement par sa docstring, la note en langage courant en tête d’une fonction qui dit ce qu’elle doit faire. Le modèle écrit le corps, et des tests unitaires cachés (de petites vérifications automatiques) décident si le code fonctionne. Seul le code qui s’exécute et réussit les tests compte.

Deux choses ressortent. L’entraînement sur du code public fait une énorme différence : GPT-3, un modèle de texte général, ne résout aucun de ces problèmes. Et une seule réponse de Codex échoue plus souvent qu’elle ne réussit. Le chiffre de 70,2 % exige cent échantillons, plus un moyen de choisir celui qui fonctionne, ce qui, en pratique, veut dire des tests écrits par une personne.

GitHub rapporte un portrait semblable à partir de son propre banc d’essai. Sur des fonctions Python dont le corps avait été effacé, la première suggestion de Copilot était juste 43 % du temps, proportion qui montait à 57 % quand il avait droit à dix essais. Sa FAQ ajoute que Copilot n’exécute ni ne teste ce qu’il propose, et qu’il peut recourir à des appels de bibliothèque dépassés.

Ce sont aussi de petits problèmes, de quelques lignes chacun. L’article rapporte que Codex a du mal quand une docstring décrit une longue chaîne d’opérations, et quand il doit suivre quelle opération s’applique à quelle variable. La plupart des vrais logiciels sont faits exactement de ces longues chaînes.

Ce que font vraiment les programmeurs

Taper de nouvelles lignes n’est qu’une partie du travail. Un programmeur en activité, en plus :

• détermine avec d’autres personnes ce qu’un programme doit faire, souvent avant que quiconque en soit sûr;
• découpe un gros problème en morceaux et décide comment ces morceaux s’emboîtent;
• lit du code existant, qui peut avoir des années et avoir été écrit par quelqu’un d’autre;
• traque les bogues, y compris ceux qui n’apparaissent qu’avec de vraies données;
• révise les modifications de ses collègues et garde le système sécuritaire et facile à entretenir.

Copilot ne voit que le fichier ouvert dans l’éditeur, et les longs fichiers sont réduits aux quelques centaines de lignes avant le curseur. Il ne sait rien de la réunion où les exigences ont changé, du client qui a signalé le bogue ni de la base de données trois services plus loin. GitHub présente l’outil comme destiné à un développeur qui garde les commandes et reste responsable du code, une conception qui concorde avec les chiffres ci-dessus.

Un exemple concret : classer les tâches selon leur exposition

Une façon pratique d’aborder la question est d’y aller tâche par tâche et de se demander deux choses : quelle part de cette tâche un modèle comme Codex pourrait-il ébaucher aujourd’hui, et à quel point est-il facile pour une personne de vérifier le résultat?

Ce tableau est un jugement raisonné, pas une mesure. Il montre que la « programmation » n’est pas une seule tâche, et que les forces d’un modèle correspondent aux parties qui sont déjà les plus routinières.

Quelles tâches de programmation changent en premier?

Les premiers changements toucheront probablement le travail routinier, rapide à vérifier. Le code passe-partout, les petites fonctions utilitaires et les tests unitaires qui les accompagnent ressemblent tous au code public dont Codex a appris, et une personne peut confirmer le résultat en quelques secondes. La page produit de GitHub met en avant ces mêmes usages : transformer un commentaire en code, compléter des motifs répétitifs, proposer des tests et montrer d’autres solutions à comparer.

Travailler dans un langage ou une bibliothèque qu’on connaît mal est un autre candidat précoce. Chercher le bon nom de fonction et ses arguments prend un temps réel, et même une suggestion imparfaite peut écourter cette recherche. Le hic, c’est que la personne qui découvre un langage est aussi la moins apte à repérer une erreur subtile; le temps gagné à taper doit donc en partie servir à vérifier.

Le travail qui dépend d’un contexte extérieur au fichier, ou de la décision même de ce qu’il faut construire, changera probablement lentement. Si des outils comme Copilot se répandent, beaucoup s’attendent à ce que l’équilibre du métier penche vers la lecture, la révision et le test du code plutôt que vers sa saisie. Les auteurs de l’article soulèvent aussi des questions ouvertes sur la sécurité et l’économie de la génération de code, qui méritent une attention soutenue. Pour l’instant, les compétences qui protègent un programmeur sont les mêmes qui rendent l’outil sûr à utiliser : comprendre le problème, écrire de bons tests et lire le code d’un œil critique.