Ein Nachwuchsentwickler kann eine KI um Hilfe bei einer unbekannten Bibliothek bitten, funktionierenden Code erhalten und zur nächsten Aufgabe übergehen. Die Funktion ist womöglich fertig, bevor die Person versteht, warum sie funktioniert. Das wird wichtig, wenn der Code später fehlschlägt, sich die Anforderungen ändern oder jemand entscheiden muss, ob die Lösung des Assistenten sicher ist.

Der Softwareentwickler Alexandru Nedelcu hat diese Sorge in einem Essay vom 22. September geäußert. Er argumentiert, dass Entwickler Urteilsvermögen aufbauen, indem sie Code lesen, Entscheidungen treffen und mit Fehlern umgehen. Seine Vorhersage, einige Unternehmen würden Richtlinien gegen KI-Nutzung bewerben, ist eine Meinung und kein beobachteter Wandel der Branche. Ein anderes, im Januar veröffentlichtes Experiment stellt die Lernfrage enger und überprüfbar: Was verstanden Programmierer unmittelbar nach einer Aufgabe mit KI-Unterstützung? Anthropics Darstellung der Studie

Die große Veränderung

  • Was sich geändert hat: KI erleichtert die Abgabe fertiger Software, ohne dass ihr Urheber sich mit deren Logik auseinandergesetzt hat. Sie kann eine Implementierung liefern, bevor ein Neuling die nötigen Entscheidungen zum Erklären oder Reparieren geübt hat.
  • Warum das wichtig ist: Manager können heute mehr Ergebnisse erhalten und zugleich den Weg schwächen, auf dem Nachwuchskräfte zu den Fachleuten werden, die morgen Fehler diagnostizieren können. Am größten ist das Risiko bei Aufgaben mit unbekannten Konzepten; Unterstützung bei vertrauter Arbeit kann weiterhin nützlich sein.
  • Worauf zu achten ist: Teams könnten Lernen als Teil der Leistungserbringung behandeln und Zeit dafür einplanen, KI-gestützte Arbeit zu erklären, Fehler zu diagnostizieren und sie anzupassen. Dann könnten Einstellungstests und Programmierprodukte neben Geschwindigkeit auch nachgewiesenes Verständnis belohnen.

Eine erledigte Aufgabe und eine erlernte Fähigkeit sind zwei verschiedene Ergebnisse

In einer randomisierten Studie mit 52 Programmierern nutzten die Teilnehmenden eine unbekannte Python-Bibliothek namens Trio, um zwei Programmieraufgaben zu bearbeiten. Die Hälfte konnte in der Entwicklungsumgebung einen KI-Assistenten verwenden, die andere Hälfte nicht. Alle wussten, dass anschließend ein Quiz stattfinden würde. Kurz nach der Arbeit prüfte das Quiz Konzepte, das Lesen von Code und die Fehlersuche.

Die KI-Gruppe erreichte durchschnittlich 50 Prozent, die Gruppe ohne KI 67 Prozent: ein Unterschied von 17 Prozentpunkten, kein relativer Rückgang um 17 Prozent. Bei Fragen zur Fehlersuche war der Abstand am größten. Im Mittel war die KI-Gruppe etwa zwei Minuten schneller fertig; dieser Zeitunterschied war statistisch jedoch nicht signifikant. Die Ergebnisse betreffen eine kurze Begegnung mit einer Bibliothek und einen unmittelbar danach durchgeführten Test, nicht die Laufbahn von Entwicklern oder die Qualität eines Produktivsystems. Ergebnisse und Grenzen der Studie

Die Forschenden beobachteten auch, wie die Teilnehmenden den Assistenten nutzten. Manche ließen Code und Fehlersuche weitgehend von ihm erledigen; andere baten um Erklärungen oder arbeiteten die Konzepte selbst durch. Die stärker eingebundenen Gruppen erzielten tendenziell bessere Werte, wurden aber erst im Nachhinein so eingeteilt. Die Teilnehmenden wurden zufällig dem Zugang zu KI zugeteilt, nicht einer bestimmten Art, mit ihr zu arbeiten. Eine Erklärung anzufordern kann beim Lernen helfen; diese Studie kann jedoch nicht belegen, dass ein bestimmter Prompt oder Arbeitsablauf die Lernlücke verhindert. Die Interaktionsanalyse der Studie

Ein Fehler ist häufig der Moment, in dem ein Neuling erkennt, welche Annahmen eine Bibliothek macht. Übernimmt der Assistent sowohl die erste Implementierung als auch deren Reparatur, bekommt der Entwickler womöglich weniger davon mit. Das ist eine mögliche Erklärung für den Abstand bei der Fehlersuche.

Geschwindigkeit zählt weiterhin, und die Aufgabe verändert das Ergebnis

Unter anderen Bedingungen hat KI-Unterstützung das Programmieren ebenfalls beschleunigt. In einem kontrollierten Experiment mit GitHub Copilot sollten 95 freiberufliche Softwareentwickler einen HTTP-Server in JavaScript erstellen. Unter denjenigen, die die Aufgabe abschlossen, benötigte die Copilot-Gruppe durchschnittlich etwa 71 Minuten, verglichen mit etwa 161 Minuten in der Kontrollgruppe. Das entspricht einer um 55,8 Prozent kürzeren Bearbeitungszeit. Die Forschenden prüften nicht, was die Programmierer anschließend gelernt hatten. Es ging um eine klar abgegrenzte Implementierung, nicht um die Einführung in eine unbekannte Bibliothek mit anschließendem Verständnisquiz.

Beide Ergebnisse können für eine Führungskraft nützlich sein. Wenn ein erfahrener Entwickler mit KI wiederkehrende Arbeit schneller erledigt, kann die Zeitersparnis real sein. Geht es darum, ein neues System zu erlernen, müssen schnellerer Output und besseres Verständnis getrennt geprüft werden. Ein pauschales KI-Verbot würde mögliche Gewinne aufgeben, ohne die Frage zu beantworten, wie Menschen lernen, die Arbeit zu beaufsichtigen.

Nedelcus Essay geht über das Experiment hinaus. Er argumentiert, dass sich Wartbarkeit erst über Monate oder Jahre zeigt und Erfahrung wächst, wenn man Verantwortung für Fehler übernimmt. Die Studie misst weder langfristige Wartbarkeit noch belegt sie, dass KI-Nutzer ganz aufhören zu lernen. Seine hilfreiche Herausforderung betrifft die Organisation: Wenn ein Team zunehmend die praktische Übungsarbeit delegiert, wo werden seine künftigen Fehlerdiagnostiker diese Erfahrung sammeln? Nedelcus Essay

Lernenden nach dem Funktionieren des Codes etwas beweisen lassen

Eine praktische Maßnahme wäre, einem Neuling eine KI-gestützte Aufgabe zu geben und anschließend um eine kurze unabhängige Prüfung zu bitten, bevor die Arbeit als Lernerfolg gilt. Das ist unser Vorschlag, keine Maßnahme, die eine der beiden Studien untersucht hat:

  1. Erklären: Ohne den Assistenten zu fragen, soll die Person erläutern, warum der unbekannte Teil des Codes funktioniert, welche Annahmen er macht und wodurch er fehlschlagen könnte. Eine erfahrene Entwicklerin oder ein erfahrener Entwickler kann eine Rückfrage zur konkreten Änderung stellen.
  2. Diagnostizieren: In einem sicheren Test-Branch wird ein kleiner, realistischer Fehler eingeführt. Die lernende Person soll die Ursache finden und erklären, welche Beobachtung eine verlockende, aber falsche Reparatur ausgeschlossen hat. Es geht ums Schlussfolgern, nicht darum, sich einen Befehl zu merken.
  3. Anpassen: Eine Anforderung wird geändert; anschließend soll die lernende Person die Implementierung und ihre Tests überarbeiten. KI darf dabei verwendet werden. Die Person sollte jedoch die neue Funktionsweise begründen und benennen können, was noch überprüft werden muss.

Wenn ein Assistent beispielsweise einen neuen asynchronen Vorgang schreibt, könnte eine prüfende Person fragen, was passiert, wenn er auf halbem Weg abgebrochen wird. Der Entwickler sollte den Ablauf nachvollziehen und eine geänderte Anforderung testen können. Eine Codeprüfung allein kann einen Fehler finden, ohne die lernende Person darauf vorzubereiten, den nächsten zu beheben. Bei der vorgeschlagenen Prüfung geht es darum, ob das Wissen mit dem ausgelieferten Code erhalten bleibt.

Daraus muss keine Prüfung für jedes Routine-Ticket werden. Ein Team könnte die Übung unbekannten Bibliotheken, wiederkehrenden Fehlerbildern oder Aufgaben vorbehalten, für die eine Nachwuchskraft später Verantwortung übernehmen soll. Das kostet bezahlte Arbeitszeit und erfordert eine prüfende Person, die das System kennt. Zählt das Management nur zusammengeführte Aufgaben und eingesparte Zeit, könnten genau diese Aufwände zuerst gekürzt werden. Damit würde das Lernproblem schwieriger, selbst wenn der heutige Output steigt.

Die Frage der Ausbildung reicht bis zu Einstellungen und Produktdesign

Einstiegsrollen verbanden häufig die Erledigung von Aufgaben mit angeleiteter Praxis. KI verändert dieses Verhältnis, wenn ein Bewerber eine beeindruckende fertige Funktion vorweisen kann, ohne zu zeigen, wie er zu seinen Überlegungen gelangt ist. Arbeitgeber könnten Bewerber bitten, einen kleinen Arbeitsbeitrag zu erklären und zu verändern, statt ein ausgefeiltes Code-Repository als Beweis selbstständiger Kompetenz zu behandeln. Das ist ein Vorschlag für die Einstellungspraxis, kein Beleg für einen aktuellen Einstellungstrend. Geprüft werden sollten die für die jeweilige Rolle benötigten Fähigkeiten – nicht eine generelle Arbeit ohne Werkzeuge.

Auch Programmierprodukte stehen vor einer ähnlichen Entscheidung. Ein Assistent kann auf schnelle Antworten optimiert sein oder es erleichtern, Annahmen zu prüfen, Verständnisfragen zu stellen und Änderungen auszuprobieren, bevor er eine Lösung zeigt. Die beobachteten Interaktionsmuster in der Studie machen die zweite Gestaltung einen Versuch wert; sie belegen jedoch nicht, dass eine bestimmte Benutzeroberfläche besser lehrt. Für Arbeitgeber stellt sich beim Kauf entsprechend die Frage, ob ein Werkzeug Mitarbeitenden hilft, seine Ausgaben zu prüfen und zu verändern – und nicht nur, wie viel Code es erzeugt.

Das kurze Quiz kann nicht vorhersagen, wer in fünf Jahren eine Fachperson sein wird. Es zeigt jedoch, warum eine akzeptierte Implementierung kein guter Ersatz für einen Nachweis von Verständnis bei einer unbekannten Aufgabe ist. Teams, die sowohl Automatisierung als auch eine kompetente nächste Generation wollen, müssen Raum für praktische Übung schaffen und prüfen, was Menschen tun können, wenn sich die Antwort ändert.