Was ist Stanford CS146S?

Stanford CS146S ist der Kurs The Modern Software Developer, unterrichtet von Mihail Eric und erstmals im Herbst 2025 angeboten. Für den offiziellen Überblick und Details zum Syllabus ist die Kursseite themodernsoftware.dev die beste Referenz. Die Aufgaben liegen im GitHub-Repository mihail911/modern-software-dev-assignments von Mihail Eric (mihail911). Die Repository-Beschreibung lautet „Assignments for CS146S: The Modern Software Dev (Stanford University Fall 2025)“. Schon diese Kombination zeigt, worum es hier geht: Stanford behandelt AI Coding nicht mehr als Randthema, sondern als Kern moderner Softwarepraxis. Genau darin hat der Kurs recht — meine Kritik setzt erst dort an, wo AI-Architektur, Systemgrenzen und Ersetzbarkeit zur entscheidenden Disziplin werden.

Stanford formalisiert etwas Reales

Dass Stanford diesem Wandel einen eigenen Kurs widmet, formalisiert etwas Reales.

Jahrelang war die respektable Position, AI Coding als Spielzeug, Abkürzung oder dünne Produktivitätsschicht über dem „echten Engineering“ zu behandeln. Diese Position altert bereits schlecht.

Nach den öffentlichen Kursmaterialien und der Aufgabenfolge deckt CS146S Prompting, Cursor- und Warp-Arbeitsabläufe, MCP Server, autonome Coding Agents, Security Scanning, AI Code Review und Multi-Stack App Generation ab. Das ist kein Neuheiten-Seminar. Es ist die Anerkennung, dass sich Software Development selbst gerade um Modelle herum neu organisiert.

Stanford hat damit recht. Der moderne Software Developer muss heute verstehen, wie man gut promptet, mit Agents arbeitet, Tools verbindet, Outputs prüft und mit AI im Loop schneller shippt. So zu tun, als wäre das nicht Teil des Jobs, heißt nur, dem Markt hinterherzulaufen.

Version eins war nie das Problem

Wo die aktuelle AI-Development-Debatte das Problem meiner Meinung nach noch unterschätzt: AI Coding scheitert selten bei Version eins.

Version eins ist der leichte Teil.

Der Login-Screen funktioniert. Das Dashboard rendert. Der CRUD Flow shippt. Die Demo bekommt Applaus. Die Schwierigkeiten beginnen bei Änderung vier, fünf und sechs, wenn das Team den Auth Provider tauschen, Analytics ersetzen, eine frühe Styling-Entscheidung entwirren oder ein Feature ergänzen muss, ohne gleich drei andere Systeme mitzunehmen.

Dann zeigen die meisten AI-generierten Codebases, was sie wirklich sind: schnell produziert, teuer zu verändern.

Der zentrale Failure Mode ist nicht, dass das Modell Unsinn schreibt. Der zentrale Failure Mode ist, dass das generierte System schwache Boundaries hat und jede spätere Änderung einen unsichtbaren Auswirkungsradius mitbringt.

Werkzeugkompetenz ist nicht dasselbe wie strukturelle Sicherheit

Ein Kurs kann Prompting, AI IDE Arbeitsabläufe, MCP, Agent Automation, Semgrep, Graphite und Multi-Stack Generation vermitteln. Das alles ist wichtig. Nichts davon garantiert, dass die resultierende Codebase nach einem Monat Iteration noch gesund bleibt.

Ein Team kann in AI-native Arbeitsabläufen hervorragend sein und trotzdem ein System bauen, in dem:

  • Screens direkt Implementierungsdetails importieren
  • generierte Module Vendor APIs ins App Code leaken
  • optionale Services wie harte Dependencies initialisiert werden
  • ein zweites LLM Review als Verification missverstanden wird
  • jeder Refactor zu Archäologiearbeit wird

Darum glaube ich nicht, dass der entscheidende Vorteil in AI-native Development allein aus Tool-Nutzung kommt.

Er wird aus Architektur kommen, die wiederholte Veränderung überlebt.

Das fehlende Thema ist Ersetzbarkeit

Jedes AI-generierte Subsystem sollte standardmäßig als ersetzbar behandelt werden.

Das heißt: Auth hinter einem Interface. Analytics hinter einem Interface. Storage hinter einem Interface. Styling hinter einem Contract. Dependency Construction in einer Composition Root. Validation an den Systemkanten. Deterministische Checks bei jedem Commit.

Wenn ein schlechtes Modul hinter demselben Contract gelöscht und neu implementiert werden kann, potenziert sich die AI-Geschwindigkeit. Wenn jeder generierte Teil in jeden anderen greift, wird das Team zwangsläufig langsamer, egal wie gut die Prompts sind.

Genau dieses Thema sollte in mehr AI-Development-Gesprächen explizit werden.

Die entscheidende Frage ist nicht nur: „Kann AI uns helfen, die erste Version schneller zu shippen?“

Die entscheidende Frage ist: „Wie billig können wir die falsche Version ersetzen, sobald die Produktrealität auftaucht?“

Der moderne Software Developer braucht trotzdem Guardrails

Viel aktuelle AI-Beratung hängt immer noch zu stark an Geschmack:

  • besser prompten
  • sorgfältiger reviewen
  • mehrere Model Outputs vergleichen
  • dem Agent mehr Context geben
  • noch einen AI Reviewer hinzufügen

Das hilft. Aber es skaliert nicht als Fundament.

Menschliche Prüfung ist inkonsistent. Modellprüfung ist noch inkonsistenter. Das einzige Muster, dem ich im großen Maßstab vertraue, ist:

  • AI generieren lassen
  • deterministische Regeln enforce lassen
  • Menschen über Specification und Tradeoffs urteilen lassen

Darum komme ich immer wieder auf dieselben Dinge zurück: Contracts, Boundary Rules, Composition Roots, Contract Tests und schnelle, nicht verhandelbare Checks. Das Ziel ist nicht, das Modell perfekt zu machen. Das Ziel ist, das System strukturell schwerer beschädigbar zu machen.

Stanford hat recht. Der nächste Schritt ist härter.

CS146S ist wichtig, weil der Kurs eine Wahrheit formalisiert, die die Branche nicht länger ignorieren kann: AI-native Development ist jetzt Teil des Crafts.

Aber ich glaube nicht, dass der moderne Software Developer nur durch Fluency mit AI Tools definiert wird.

Die nächste Messlatte ist härter.

Der moderne Software Developer muss auch wissen, wie man Codebases baut, in denen AI-generierte Teile begrenzt, verifiziert und ersetzt werden können, ohne das ganze System in einen Rewrite zu ziehen.

Stanford lehrt den modernen Software Developer.

Gut.

Der fehlende Kurs ist die Architekturdisziplin, die verhindert, dass die AI-native Codebase unter ihrem eigenen Tempo zusammenbricht.