Stanfords neues KI-Engineering-Curriculum verlagert den Fokus vom Coden zum Review

Mihail Eric, der an der Stanford University das Modul „The Modern Software Developer“ lehrt und bei Monaco die KI-Leitung innehat, hat sein Curriculum aktualisiert, um zu reflektieren, wie Software-Ingenieure in einer Ära lernen sollten, die von Coding-Agenten dominiert wird. In einem kürzlichen Gespräch mit dem YouTube-Kanal AI Engineer skizzierte Eric, wie sich akademische Aufgaben und professionelle Workflows vom Schreiben von Code hin zu dessen Bewertung, dem Management von Agent-Umgebungen und dem Verständnis des historischen Kontexts innerhalb von Codebasen verschieben.

Was passiert ist

Die Struktur des Kurses CS146S an der Stanford University hat sich zwischen dem ersten und zweiten Durchlauf erheblich verändert. Ursprünglich umfasste der Kurs neun Aufgaben und ein Abschlussprojekt, bei dem eine Aufgabe darin bestand, einen KI-Code-Reviewer auf ein Repository loszulassen und dessen Feedback zu bewerten. Eric stellte jedoch fest, dass die Studenten bereits umfangreich Agents nutzten und frühere Übungen oft mit nur einem einzigen Prompt abschlossen. Daher ersetzt der aktuelle Lehrplan viele dieser isolierten Aufgaben durch die Anforderung, zu Open-Source-Projekten beizutragen, wo menschliche Maintainer die Patches der Studenten überprüfen.

Diese Verschiebung zwingt die Studenten, sich mit den sozialen und technischen Realitäten der Softwareentwicklung jenseits der bloßen Implementierung auseinanderzusetzen. Während ein Agent eine Feature-Implementierung an einem Nachmittag generieren kann, muss der Student dennoch entscheiden, ob der Maintainer diese Änderung wünscht, verstehen, warum sich der bestehende Code so verhält, wie er es tut, und potenzielle Bruchstellen antizipieren. Dieser Prozess spiegelt die Lern-Dynamik zwischen Junior- und Senior-Ingenieuren wider, bei der der Wert im Dialog und in der Kritik liegt, nicht nur im rohen Output.

Bei Monaco hat Erics Team eine ähnliche Philosophie in seinen professionellen Engineering-Praktiken übernommen. Sie evaluierten verschiedene Code-Review-Produkte und entschieden sich, Devin für bestimmte Aufgaben weiterhin zu nutzen. Allerdings stellten sie fest, dass Standard-Agent-Workspaces ihren Anforderungen nicht gerecht wurden, da Hintergrund-Agents spezifische Umgebungen benötigen, um das Produkt auszuführen, Fehler zu reproduzieren und Patches zu testen. Da diese Details stark von Monacos spezifischer Cloud-Infrastruktur abhängen, baute das Team seine eigene Workspace-Infrastruktur, was zu einem internen Tool namens Hal führte.

Wie es funktioniert

Hal dient als einheitliche Schnittstelle für verschiedene Rollen innerhalb des Unternehmens und demonstriert, wie Agent-Outputs auf die Absicht des Nutzers zugeschnitten werden müssen. Ein Ingenieur kann Hal bitten, ein Produktionsproblem zu untersuchen und einen Pull Request mit einer Lösung zu generieren. Ein Vertriebsmitarbeiter kann dasselbe System fragen, wie ein Produktfeature funktioniert. Im ersten Fall ist der Output eine Codeänderung, bereit für die menschliche Überprüfung; im zweiten Fall ist es eine Erklärung, geeignet für die Kundenkommunikation. Diese Unterscheidung verdeutlicht, dass rohes Debugging-Output nur für Ingenieure nützlich ist, während andere Stakeholder synthetisierte Antworten benötigen.

Ein kritischer Bestandteil dieses Workflows ist die Bewältigung des Problems der „Authority Map“. Wenn ein Agent eine Änderung vorschlägt, sieht er typischerweise nur den aktuellen Zustand des Codes. Ihm fehlt die Sichtbarkeit darauf, warum ähnliche Änderungen vor sechs Monaten abgelehnt wurden oder welche architektonischen Entscheidungen die aktuelle Implementierung getrieben haben. Um dies zu lösen, müssen Teams Agents Zugang zum historischen Kontext geben, wie etwa Diskussionen in vergangenen Pull Requests und Entscheidungsprotokolle. Ohne diesen Kontext könnten Agents wiederholt Lösungen vorschlagen, die zuvor als falsch oder unerwünscht eingestuft wurden.

Eric hebt auch Techniken hervor, um das menschliche Verständnis von KI-generiertem Code zu verbessern. Eine Methode besteht darin, Tools wie Geoffrey Litts „explain-diff“-Skill zu verwenden, der eine Codeänderung in einen visuellen Walkthrough umwandelt und den Entwickler zu den Modifikationen prüft. Dieser Ansatz stellt sicher, dass Ingenieure von Agents geschriebenen Code nicht blind mergen, sondern ihr Verständnis der Logik und potenzieller Seiteneffekte vor der Integration verifizieren.

Wichtige Details

• Stanfords CS146S verlangt nun von den Studenten, zu Open-Source-Projekten mit menschlicher Maintainer-Überprüfung beizutragen, anstatt isolierte KI-Bewertungsübungen abzuschließen.
• Monaco baute sein eigenes Agent-Workspace-Tool, Hal, weil bestehende Lösungen ihre spezifische Cloud-Umgebung für Tests und Reproduktion nicht angemessen replizieren konnten.
• Hal generiert unterschiedliche Outputs basierend auf der Nutzerrolle: Pull Requests für Ingenieure und erklärende Texte für Vertriebsmitarbeiter.
• Eine in der Diskussion zitierte Studie zeigt, dass Teams mit hoher KI-Adaption 98 % mehr Pull Requests merged haben, aber ihre Review-Zeit um 91 % gestiegen ist.
• Effektive Agent-Workflows erfordern Zugang zu einer „Authority Map“, die historische Entscheidungen und Gründe für vergangene Ablehnungen enthält, um redundante oder falsche Vorschläge zu verhindern.
• Tools, die Diffs visualisieren und Entwickler zu Änderungen prüfen, helfen dabei, das Risiko zu mindern, missverstandenen KI-generierten Code zu mergen.

Warum es wichtig ist

Für Software-Ingenieure und technische Führungskräfte signalisiert diese Verschiebung, dass Kompetenz im Umgang mit Coding-Agents nicht mehr nur auf Prompt-Engineering beruht. Der Engpass hat sich vom Schreiben von Code zum Überprüfen und zur Bereitstellung des notwendigen Kontexts für Agents verschoben, damit diese korrekt operieren können. Teams, die nicht in maßgeschneiderte Agent-Umgebungen oder historische Wissensdatenbanken investieren, werden wahrscheinlich eine erhöhte Fluktuation bei Pull Requests und längere Review-Zyklen sehen, da Agents Schwierigkeiten haben, sich an etablierte Architektur-Muster anzupassen.

Der Anstieg der Review-Zeit trotz höherer Merge-Raten deutet darauf hin, dass menschliche Aufsicht weiterhin kritisch bleibt. Ingenieure müssen neue Fähigkeiten entwickeln, um KI-generierte Änderungen effizient zu auditieren, wobei der Fokus auf Absicht, Edge Cases und historischer Konsistenz liegt. Dies erfordert einen kulturellen Wandel, bei dem Code-Review zu einem tiefergehenden investigativen Prozess wird, anstatt einer oberflächlichen Prüfung, um sicherzustellen, dass Geschwindigkeit nicht die Systemstabilität oder Wartbarkeit beeinträchtigt.

Was Sie tun können

• Ersetzen Sie isolierte Coding-Übungen durch Aufgaben, die Beiträge zu echten Open-Source-Projekten oder internen Legacy-Codebasen mit strenger menschlicher Überprüfung erfordern.
• Bauen oder konfigurieren Sie Agent-Workspaces, die Ihre Produktionsumgebung für Tests und Fehleruntersuchungen genau reproduzieren können.
• Implementieren Sie Tools, die Code-Diffs visualisieren und Entwickler zu den Änderungen prüfen, um tiefes Verständnis vor dem Mergen sicherzustellen.
• Erstellen Sie eine „Authority Map“, indem Sie Kommentare aus vergangenen Pull Requests, Design-Dokumente und Ablehnungsgründe für den Agent-Zugang indexieren.
• Passen Sie Agent-Outputs an spezifische Rollen an, sodass Ingenieure handhabbaren Code erhalten, während nicht-technische Stakeholder klare Erklärungen bekommen.
• Überwachen Sie Pull-Request-Metriken genau, insbesondere die Review-Zeit im Vergleich zur Merge-Rate, um Engpässe in KI-unterstützten Workflows zu identifizieren.