Comment Stanford enseigne l'ingénierie à l'ère de l'IA (Mihail Eric, Monaco)

Ce changement de format déplace la difficulté de l'écriture du code vers sa compréhension. Un agent peut implémenter une fonctionnalité en un après-midi, mais il faut encore savoir si le mainteneur la souhaite, pourquoi le code se comporte ainsi et ce que le correctif risque de casser. Cet échange est aussi la manière dont un ingénieur junior apprend auprès d'un senior. Chez Monaco, l'outil interne Hal illustre cette logique : un ingénieur lui demande d'enquêter sur une panne et d'ouvrir une demande de fusion, tandis qu'un commercial l'interroge sur le fonctionnement du produit. Dans un cas, le résultat utile est un changement à relire, dans l'autre une explication à donner à un client. Un même flot de sortie de débogage ne sert que l'un des deux. Pour s'entraîner, Geoffrey Litt propose une compétence « explain-diff » qui transforme une modification en parcours visuel puis interroge le lecteur à son sujet, ce qui révèle les points où il faut rouvrir le code.

Le contexte tient à la place croissante des agents dans le développement quotidien et à la question de ce qu'un ingénieur doit encore apprendre. La règle de Mihail Eric chez Monaco est : « On achète pour apprendre, on construit pour garder ». Les espaces de travail pour agents relèvent du second cas, car un agent en arrière-plan a besoin d'un environnement où exécuter le produit, reproduire une défaillance et tester son correctif, et celui-ci dépend de la configuration cloud de l'entreprise. Reste une question ouverte : un agent voit le code actuel, mais où trouve-t-il les raisons pour lesquelles l'équipe a rejeté le même changement six mois plus tôt ? Mihail Eric prédit que les dépôts open source deviendront des usines logicielles pilotées par des agents, mais quelqu'un devra toujours décider quels changements appartiennent au projet. La discussion sert aussi d'avant-goût à la conférence AI Engineer CODE, organisée à San Francisco.