Le nouveau cursus d'ingénierie IA de Stanford déplace le focus du codage vers la revue

Mihail Eric, qui enseigne The Modern Software Developer à Stanford et dirige l'IA chez Monaco, a mis à jour son programme pour aborder la manière dont les ingénieurs logiciels doivent apprendre dans une ère dominée par les agents de codage. Lors d'une discussion récente avec la chaîne YouTube AI Engineer, Eric a exposé comment les travaux académiques et les flux de travail professionnels évoluent de l'écriture de code vers son évaluation, la gestion des environnements d'agents et la compréhension du contexte historique au sein des bases de code.

Ce qui s'est passé

La structure du cours CS146S de Stanford a considérablement changé entre sa première et sa deuxième édition. Initialement, le cours comprenait neuf devoirs et un projet final, dont l'un exigeait que les étudiants exécutent un relecteur de code IA sur un dépôt et évaluent ses retours. Cependant, Eric a observé que les étudiants utilisaient déjà largement les agents, achevant souvent les exercices précédents avec une seule invite. Par conséquent, le programme actuel remplace beaucoup de ces tâches isolées par une exigence de contribuer à des projets open source, où des mainteneurs humains relisent les correctifs des étudiants.

Ce changement oblige les étudiants à s'engager avec les réalités sociales et techniques du développement logiciel au-delà de la simple implémentation. Bien qu'un agent puisse générer une implémentation de fonctionnalité en une après-midi, l'étudiant doit toujours déterminer si le mainteneur souhaite ce changement, comprendre pourquoi le code existant se comporte comme il le fait, et anticiper les potentielles ruptures. Ce processus reflète la dynamique d'apprentissage entre les ingénieurs juniors et seniors, où la valeur réside dans la conversation et la critique plutôt que dans le seul résultat brut.

Chez Monaco, l'équipe d'Eric a adopté une philosophie similaire dans leurs pratiques d'ingénierie professionnelle. Ils ont évalué divers produits de revue de code et ont décidé de continuer à utiliser Devin pour certaines tâches. Cependant, ils ont constaté que les espaces de travail d'agents prêts à l'emploi ne répondaient pas à leurs besoins, car les agents en arrière-plan nécessitent des environnements spécifiques pour exécuter le produit, reproduire les échecs et tester les correctifs. Comme ces détails dépendent fortement de la configuration cloud spécifique de Monaco, l'équipe a construit sa propre infrastructure d'espace de travail, aboutissant à un outil interne appelé Hal.

Comment cela fonctionne

Hal sert d'interface unifiée pour différents rôles au sein de l'entreprise, démontrant comment les sorties des agents doivent être adaptées à l'intention de l'utilisateur. Un ingénieur peut demander à Hal d'enquêter sur un problème de production et de générer une demande d'extraction (pull request) avec un correctif. Un commercial peut demander au même système comment fonctionne une fonctionnalité du produit. Dans le premier cas, la sortie est une modification de code prête pour une revue humaine ; dans le second, c'est une explication adaptée à la communication client. Cette distinction souligne que la sortie brute de débogage n'est utile qu'aux ingénieurs, tandis que les autres parties prenantes ont besoin de réponses synthétisées.

Un composant critique de ce flux de travail consiste à résoudre le problème de la « carte d'autorité ». Lorsqu'un agent propose un changement, il ne voit généralement que l'état actuel du code. Il manque de visibilité sur les raisons pour lesquelles des changements similaires ont été rejetés il y a six mois ou quelles décisions architecturales ont guidé l'implémentation actuelle. Pour résoudre cela, les équipes doivent fournir aux agents un accès au contexte historique, tel que les discussions passées sur les demandes d'extraction et les journaux de décision. Sans ce contexte, les agents peuvent proposer à plusieurs reprises des solutions jugées incorrectes ou indésirables auparavant.

Eric met également en avant des techniques pour améliorer la compréhension humaine du code généré par l'IA. Une méthode implique l'utilisation d'outils comme la compétence explain-diff de Geoffrey Litt, qui convertit une modification de code en une visite guidée visuelle et interroge le développeur sur les modifications. Cette approche garantit que les ingénieurs ne fusionnent pas aveuglément le code écrit par les agents, mais vérifient plutôt leur compréhension de la logique et des effets secondaires potentiels avant l'intégration.

Détails clés

• Le cours CS146S de Stanford exige désormais que les étudiants contribuent à des projets open source avec des revues de mainteneurs humains, au lieu de compléter des exercices d'évaluation IA isolés.
• Monaco a construit son propre outil d'espace de travail d'agents, Hal, car les solutions existantes ne pouvaient pas reproduire adéquatement leur environnement cloud spécifique pour les tests et la reproduction.
• Hal génère différentes sorties selon le rôle de l'utilisateur : des demandes d'extraction pour les ingénieurs et du texte explicatif pour les commerciaux.
• Une étude citée dans la discussion note que les équipes ayant une forte adoption de l'IA ont fusionné 98 % plus de demandes d'extraction, mais que leur temps de revue a augmenté de 91 %.
• Les flux de travail efficaces avec agents nécessitent l'accès à une « carte d'autorité » incluant les décisions historiques et les raisons des rejets passés pour prévenir les propositions redondantes ou incorrectes.
• Les outils qui visualisent les diffs et interrogent les développeurs sur les changements aident à atténuer le risque de fusionner du code généré par l'IA sans le comprendre.

Pourquoi c'est important

Pour les ingénieurs logiciels et les leaders techniques, ce changement signale que la maîtrise des agents de codage ne repose plus uniquement sur l'ingénierie des invites. Le goulot d'étranglement s'est déplacé de l'écriture du code vers sa revue et la fourniture du contexte nécessaire pour que les agents fonctionnent correctement. Les équipes qui négligent d'investir dans des environnements d'agents personnalisés ou des bases de connaissances historiques verront probablement augmenter le taux de rotation des demandes d'extraction et allonger les cycles de revue, car les agents auront du mal à s'aligner sur les modèles architecturaux établis.

L'augmentation du temps de revue malgré des taux de fusion plus élevés suggère que la supervision humaine reste critique. Les ingénieurs doivent développer de nouvelles compétences pour auditer efficacement les changements générés par l'IA, en se concentrant sur l'intention, les cas limites et la cohérence historique. Cela nécessite un changement culturel où la revue de code devient un processus d'investigation plus approfondi plutôt qu'une vérification superficielle, garantissant que la vitesse ne compromette pas la stabilité ou la maintenabilité du système.

Ce que vous pouvez faire

• Remplacez les exercices de codage isolés par des tâches exigeant de contribuer à de vrais projets open source ou à des bases de code héritées internes avec une revue humaine stricte.
• Construisez ou configurez des espaces de travail d'agents capables de reproduire précisément votre environnement de production pour les tests et l'investigation des échecs.
• Implémentez des outils qui visualisent les diffs de code et interrogent les développeurs sur les changements pour assurer une compréhension profonde avant la fusion.
• Créez une « carte d'autorité » en indexant les commentaires passés des demandes d'extraction, les documents de conception et les raisons des rejets pour l'accès des agents.
• Adaptez les sorties des agents aux rôles spécifiques, en veillant à ce que les ingénieurs reçoivent du code actionnable tandis que les parties prenantes non techniques reçoivent des explications claires.
• Surveillez attentivement les métriques des demandes d'extraction, en suivant spécifiquement le temps de revue par rapport au taux de fusion pour identifier les goulots d'étranglement dans les flux de travail assistés par l'IA.