Qu’est-ce que Stanford CS146S ?

Stanford CS146S est le cours The Modern Software Developer, enseigné par Mihail Eric et lancé pour la première fois à l’automne 2025. Pour l’aperçu officiel du cours et les détails du syllabus, la meilleure référence est themodernsoftware.dev. Les devoirs se trouvent dans le dépôt GitHub mihail911/modern-software-dev-assignments de Mihail Eric (mihail911). La description du dépôt est “Assignments for CS146S: The Modern Software Dev (Stanford University Fall 2025)”. Cet ensemble dit déjà l’essentiel : Stanford ne traite plus l’AI coding comme un sujet périphérique, mais comme le cœur d’une pratique logicielle moderne. C’est là que le cours a raison — ma critique commence là où l’architecture de l’AI, les frontières du système et la remplaçabilité deviennent la discipline décisive.

Stanford formalise quelque chose de bien réel

Le simple fait que Stanford consacre un cours entier à ce basculement formalise quelque chose de bien réel.

Pendant des années, la position respectable consistait à traiter l’AI coding comme un jouet, un raccourci, ou une fine couche de productivité posée sur la « vraie ingénierie ». Cette position vieillit déjà très mal.

D’après la description publique du cours et la séquence des devoirs, CS146S couvre le prompting, les flux de travail Cursor et Warp, les serveurs MCP, les autonomous coding agents, le security scanning, l’AI code review et la génération d’apps multi-stack. Ce n’est pas un séminaire de curiosité. C’est la reconnaissance que le software development lui-même est en train de se réorganiser autour des modèles.

Stanford a raison là-dessus. Le software developer moderne doit comprendre comment bien prompter, travailler avec des agents, connecter des tools, inspecter des outputs et shipper plus vite avec l’AI dans la boucle. Faire semblant que ce n’est pas devenu le métier, c’est simplement rester en retard sur le marché.

La première version n’a jamais été le vrai problème

Là où, à mon sens, la conversation actuelle sur l’AI development sous-estime encore le problème, c’est ici : l’AI coding échoue rarement à la version un.

La version un est la partie facile.

L’écran de login fonctionne. Le dashboard s’affiche. Le flux CRUD part en prod. La démo récolte des applaudissements. Les problèmes commencent au quatrième, cinquième, sixième changement, quand l’équipe doit remplacer un auth provider, changer analytics, démêler une décision de styling prise trop tôt, ou ajouter une feature sans casser trois systèmes sans rapport.

C’est là que la plupart des codebases générées par AI révèlent leur vraie nature : rapides à produire, coûteuses à faire évoluer.

Le failure mode central n’est pas que le modèle écrive n’importe quoi. Le failure mode central, c’est que le système généré a des boundaries faibles, donc chaque changement futur traîne un rayon d’impact invisible.

Maîtriser les tools n’est pas la même chose que garantir la sécurité structurelle

Un cours peut enseigner le prompting, les AI IDE flux de travail, MCP, l’agent automation, Semgrep, Graphite et la génération multi-stack. Tout cela compte. Rien de cela ne garantit que la codebase obtenue restera saine après un mois d’itération.

Une équipe peut être excellente en flux de travail AI-native et malgré tout construire un système où :

  • les screens importent directement des implementation details
  • les modules générés laissent fuiter des vendor APIs dans le app code
  • les optional services sont initialisés comme des hard dependencies
  • une deuxième LLM review est traitée comme de la verification
  • chaque refactor devient un travail d’archéologie

Voilà pourquoi je ne pense pas que l’avantage décisif de l’AI-native development viendra uniquement de l’usage des tools.

Il viendra d’une architecture capable de survivre à des changements répétés.

Le sujet manquant, c’est la remplaçabilité

Chaque sous-système généré par AI devrait être traité comme remplaçable par défaut.

Cela veut dire auth derrière une interface. Analytics derrière une interface. Storage derrière une interface. Styling derrière un contract. La construction des dépendances dans une composition root. La validation aux bords du système. Des checks déterministes à chaque commit.

Si un mauvais module peut être supprimé et réimplémenté derrière le même contract, la vitesse apportée par l’AI se compose. Si chaque partie générée va toucher toutes les autres, l’équipe finira par ralentir, quels que soient les prompts.

C’est le sujet que j’aimerais voir rendu beaucoup plus explicite dans les conversations sur l’AI development.

La vraie question n’est pas seulement : « Est-ce que l’AI peut nous aider à shipper la première version plus vite ? »

La vraie question est : « À quel coût peut-on remplacer la mauvaise version quand la réalité produit finit par arriver ? »

Le développeur logiciel moderne a toujours besoin de guardrails

Beaucoup de conseils AI actuels reposent encore trop sur le goût :

  • mieux prompter
  • reviewer plus soigneusement
  • comparer plusieurs sorties du modèle
  • donner plus de contexte à l’agent
  • ajouter un autre AI reviewer

Tout cela aide. Rien de cela ne scale comme fondation.

La relecture humaine est incohérente. La relecture par le modèle l’est encore plus. Le seul pattern auquel je fais confiance à l’échelle, c’est :

  • laisser l’AI générer
  • laisser des règles déterministes faire l’enforcement
  • laisser les humains juger la specification et les tradeoffs

Voilà pourquoi je reviens toujours aux mêmes éléments : contracts, boundary rules, composition roots, contract tests et checks rapides non négociables. Le but n’est pas de rendre le modèle parfait. Le but est de rendre le système structurellement plus difficile à endommager.

Stanford a raison. L’étape suivante est plus dure.

CS146S compte parce qu’il formalise une vérité que l’industrie ne peut plus ignorer : l’AI-native development fait désormais partie du métier.

Mais je ne pense pas que le développeur logiciel moderne se définisse seulement par son aisance avec les AI tools.

La barre suivante est plus haute.

Le développeur logiciel moderne doit aussi savoir construire des codebases où les parties générées par AI peuvent être contraintes, vérifiées et remplacées sans entraîner tout le système dans un rewrite.

Stanford enseigne le développeur logiciel moderne.

Très bien.

Le cours qui manque, c’est la discipline d’architecture qui empêche une codebase AI-native de s’effondrer sous sa propre vitesse.