Quelle auf.

Ich stelle ChatGPT Fragen, bei denen ich selbst nicht weiß, ob meine Ausgangsannahme stimmt. Statt einer schnellen Antwort soll ChatGPT recherchieren, Quellen prüfen und offenlegen, worauf die Antwort beruht.

Warum ich diesmal frage: Gestern habe ich mir vorgestellt, meine KI würde nicht komplett ausfallen, sondern nur eine bestimmte Arbeit verweigern. Auf die Bitte, eine Funktion zur E-Mail-Validierung zu schreiben, würde sie antworten: „Nein. Schreib den Code selbst. Ich helfe dir beim Denken, bei Fragen, beim Review, bei Tests und bei der Fehlersuche – aber ich schreibe keine Zeile Code für dich.“ Das hat mich irritiert, weil meine Arbeit oft genau andersherum läuft: Ich beschreibe das Ziel, die KI schreibt, ich prüfe das Ergebnis. Die KI sitzt am Steuer, ich daneben.

Meine Frage: Ist KI im Pair Programming wirklich der bessere Fahrer – oder wäre sie als Beifahrer und Navigator nützlicher?

Hier ist die Antwort von ChatGPT:

Wer fährt, entscheidet sich nicht an der Tastatur

Die kurze Antwort lautet: Die KI sollte weder dauerhaft Driver noch dauerhaft Navigator sein. Die Rollen sollten wechseln – und zwar nicht nach Stimmung, sondern nach Lernziel, Aufgabenbekanntheit, Prüfbarkeit und Risiko.

Bei einer kleinen, bekannten und gut testbaren Aufgabe darf die KI ruhig fast den gesamten Code schreiben. Eigenes Tippen ist kein Beweis für Verständnis. Wenn ich dagegen eine neue Bibliothek lerne, eine unklare Architektur erkunde oder einen Fehler in einem System suche, das ich kaum kenne, kann dieselbe Delegation genau die Arbeit entfernen, durch die mein mentales Modell erst entstehen würde – mein Verständnis von Zweck, Datenfluss, Abhängigkeiten und Fehlermodi.

Die wichtigere Entdeckung der Recherche ist deshalb: Das Bild vom Fahrer und Navigator ist zu einfach. Es tut so, als seien Lenken und Schreiben dieselbe Tätigkeit.

Bei einem Coding Agent sind sie das nicht mehr.

Zwei Menschen teilen mehr als eine Tastatur

Im klassischen Bild des Pair Programming sitzt der Driver an der Tastatur und beschäftigt sich mit dem nächsten konkreten Schritt. Der Navigator beobachtet, denkt voraus und achtet auf Fehler oder die größere Richtung.

Schon bei zwei Menschen ist der Nutzen dieser Arbeitsweise nicht so eindeutig, wie die Metapher klingt. Eine Meta-Analyse von Pair-Programming-Experimenten fand im Mittel etwas bessere Qualität und kürzere Bearbeitungsdauer, aber auch höheren Gesamtaufwand. Die Ergebnisse unterschieden sich stark zwischen den Studien; Aufgabenkomplexität und Erfahrung spielten eine wichtige Rolle. Pair Programming war nicht einfach immer besser. Hannay et al., The effectiveness of pair programming: A meta-analysis, Abstract sowie Diskussion und Schlussfolgerung. [claim-001, claim-002]

Und ein Sprachmodell ist nicht bloß der zweite Mensch ohne Kaffeetasse. Ein menschlicher Partner sieht dieselbe Arbeitssituation, kennt einen Teil der Vorgeschichte, kann ungefragt widersprechen und trägt soziale Verantwortung für das Ergebnis. Ein moderner Coding Agent kann durchaus von sich aus Vorschläge machen, nächste Schritte ausführen oder Rückfragen stellen. Er handelt dabei innerhalb des Auftrags und des Kontexts, die wir ihm zugänglich machen, und kann überzeugend falschliegen. Vor allem trägt er nicht die organisatorische Verantwortung, wenn sein Patch am nächsten Morgen den Betrieb beschäftigt.

Navigator ist deshalb keine Eigenschaft des Werkzeugs. Es ist eine Rolle, die ein konkreter Arbeitsablauf ihm zeitweise geben kann.

Die KI kann schreiben, während der Mensch lenkt

Eine Beobachtungsstudie mit GitHub Copilot liefert dafür eine passendere Unterscheidung. Die Forscher beobachteten 20 Programmierer bei Aufgaben in vier Sprachen und fanden zwei wiederkehrende Modi.

Im Beschleunigungsmodus wusste der Mensch bereits, was als Nächstes geschehen sollte. Er hatte die Aufgabe in kleine Schritte zerlegt und nutzte Copilot, um bekannte Codeaktionen schneller auszuführen. Im Explorationsmodus war der Weg noch unklar. Copilot schlug APIs, Strukturen oder Lösungsansätze vor; der Mensch musste Alternativen vergleichen und gründlicher validieren. Die Teilnehmer wechselten innerhalb einer Aufgabe flüssig zwischen beiden Modi. Barke, James und Polikarpova, Grounded Copilot, Abschnitt 4, insbesondere 4.1 und 4.2. [claim-003, claim-004]

Das verschiebt die Frage.

Wenn ich die Aufgabe zerlegt habe, eine Funktionssignatur vorgebe und weiß, welche Fälle die Tests abdecken müssen, kann die KI zwanzig Zeilen erzeugen. Sie schreibt, aber sie lenkt nicht unbedingt. Ich habe den Weg festgelegt und kann das Ergebnis günstig prüfen.

Wenn ich dagegen nur sage Mach das Login sicher, kann die KI den Lösungsraum bestimmen, lange bevor die erste Zeile erscheint. Vielleicht tippe ich ihren Vorschlag anschließend sogar von Hand ab. Trotzdem hat sie gelenkt.

Der Fahrersitz hängt also nicht daran, wer die Zeichen erzeugt. Er hängt daran, wer das Problem zerlegt, Annahmen auswählt und entscheidet, welche Evidenz genügt.

Manchmal ist die KI tatsächlich der bessere Codeproduzent

Die stärkste Gegenposition zum Gedankenexperiment ist gut belegt: Für manche Aufgaben wäre es Verschwendung, die KI künstlich vom Schreiben abzuhalten.

In einem kontrollierten Experiment erledigten Entwickler mit Copilot eine abgegrenzte JavaScript-Aufgabe – einen HTTP-Server – 55,8 Prozent schneller als die Kontrollgruppe. Peng et al., The Impact of AI on Developer Productivity, Abstract. [claim-005]

Drei spätere Feldexperimente bei Microsoft, Accenture und einem weiteren großen Unternehmen umfassten zusammen 4.867 Entwickler. Gepoolt stieg die Zahl erledigter Tasks mit KI-Codevervollständigung um 26,08 Prozent; weniger erfahrene Entwickler zeigten höhere Nutzung und größere Gewinne. Das Ergebnis misst erledigte Arbeit, nicht tiefes Verständnis oder mehrjährige Wartbarkeit. Aber es ist ein kräftiges Gegenargument zur Idee, KI solle grundsätzlich nur Fragen stellen. Cui et al., The Effects of Generative AI on High-Skilled Work, Abstract. [claim-006]

Auch Qualität muss nicht automatisch leiden. In GitHubs kontrollierter Python-Studie bestanden Copilot-Nutzer häufiger alle Tests; blinde Reviewer bewerteten Lesbarkeit, Zuverlässigkeit, Wartbarkeit und Prägnanz geringfügig besser. Das war ein einzelner synthetischer Webserver-Task und eine Untersuchung des Herstellers. Es ist keine Generalvollmacht. Es zeigt aber: Generierter Code kann in einem begrenzten, prüfbaren Setting schneller und brauchbar sein. GitHub, Does GitHub Copilot improve code quality?, Abschnitte zu Funktionalität, Review und Methodik. [claim-009]

Die KI darf hier Driver heißen, wenn wir damit Codeproduzent meinen. Nur sollten wir nicht so tun, als habe sie damit auch Ziel, Qualitätsmaßstab und Verantwortung übernommen.

In einem vertrauten Repository kann derselbe Fahrer bremsen

Dann kommt ein zeitgebundener Gegenbefund. Er beschreibt frühe 2025er Werkzeuge in einem ungewöhnlich anspruchsvollen Umfeld, kein Urteil über alle heutigen Coding Agents.

METR ließ 16 erfahrene Open-Source-Entwickler 246 reale Aufgaben in großen Repositories bearbeiten, zu denen sie im Durchschnitt seit fünf Jahren beitrugen. Mit frühen 2025er KI-Werkzeugen benötigten sie im Mittel 19 Prozent mehr Zeit. Vorher hatten sie eine Beschleunigung erwartet; hinterher glaubten sie weiterhin, schneller gewesen zu sein. Becker et al., Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, Abstract und Abschnitt 3. [claim-007]

METR konnte eine spätere Untersuchung mit neueren Werkzeugen wegen Selbstselektion nicht zuverlässig auswerten; die Rohdaten deuteten schwach auf bessere Effekte. Der ältere Wert lässt sich deshalb nicht als aktuelle allgemeine Produktivitätszahl fortschreiben. METR, We are Changing our Developer Productivity Experiment Design, Eröffnungsabschnitt. [claim-008]

Der ältere Befund ist trotzdem interessant, weil er zwei Dinge trennt, die sich am Schreibtisch gleich anfühlen können: weniger tippen und früher fertig sein.

In einem bekannten System hat der erfahrene Mensch bereits ein dichtes Modell aus Architektur, Konventionen und früheren Fehlern. Jeder KI-Vorschlag muss erst in dieses Modell übersetzt werden. Ein fast richtiger Patch erzeugt dann neue Arbeit: Kontext erklären, Diff lesen, Abweichung erkennen, Prompt korrigieren, Tests nachziehen. Der Bildschirm bewegt sich schnell. Die Aufgabe nicht unbedingt.

Die Selbsteinschätzung der METR-Teilnehmer war in diesem Setting deutlich fehlkalibriert. Mehr lässt sich daraus nicht allgemein ableiten. Aber es genügt für eine praktische Frage: Messe ich gerade Durchsatz und Ergebnis – oder nur, wie leicht sich die Arbeit anfühlt?

Verstehen entsteht nicht in den Fingern

Die Versuchung wäre nun, das Pendel zurückzuschwingen: Wer lernen will, muss alles selbst schreiben.

Auch das hält die Forschung nicht aus.

In einer dreiwöchigen Studie arbeiteten 69 junge Programmieranfänger mit oder ohne eine Codex-basierte Lernumgebung. Die KI-Gruppe erledigte mehr Aufgaben und erzielte höhere Scores. Unmittelbare Tests und ein Test nach einer Woche zeigten keinen signifikanten Nachteil beim manuellen Ändern von Code oder bei der Retention. Entscheidend war das Design: Auf Codegenerierung folgten Änderungsaufgaben. Die Lernenden mussten wieder in das Ergebnis hinein. Kazemitabaar et al., Studying the effect of AI Code Generators on Supporting Novice Learners, Abschnitte 4 bis 6. [claim-010]

Eine kleine neuere Studie fand unter anderen Bedingungen das Gegenstück – und genau das ist der Punkt: Die Bedingungen entscheiden. Entwickler sollten eine ihnen unbekannte Python-Bibliothek lernen. Die Gruppe mit KI-Unterstützung erzielte bei einem unmittelbar anschließenden Wissenstest 17 Prozent niedrigere Werte; der kleine Zeitgewinn war statistisch nicht signifikant. In der qualitativen Auswertung waren vollständige Delegation und KI-geführtes Debugging mit schwachen Ergebnissen verbunden. Teilnehmer, die konzeptuelle Fragen stellten oder generierten Code aktiv erklären ließen und nachvollzogen, schnitten besser ab. Diese Nutzungsmuster sind Assoziationen, kein kausaler Beweis für eine bestimmte Prompttechnik. Shen und Tamkin, How AI assistance impacts the formation of coding skills, Ergebnisse, Interaktionsmuster und Limitationen. [claim-011, claim-012]

Zusammen ergeben die Studien eine weniger romantische Regel: Nicht das Tippen erzeugt Verständnis, sondern die kognitive Arbeit, die der Ablauf vom Menschen verlangt.

Ein Mensch kann KI-Code verstehen, wenn er Annahmen prüft, Kontrollfluss rekonstruiert, Änderungen selbst vornimmt und Fehler erklärt. Ein Mensch kann selbst geschriebenen Code kaum verstehen, wenn er nur ein Tutorial abtippt. Die Tastatur ist ein möglicher Träger dieser Arbeit. Sie ist nicht ihr Messgerät.

Bei Security reicht ein überzeugender Navigator nicht

Verständnis und Codequalität sind außerdem nicht dasselbe.

In einer 2023 veröffentlichten Studie mit sicherheitsbezogenen Programmieraufgaben produzierten Teilnehmer mit einem älteren Codex-Assistenten unsicherere Lösungen als die Vergleichsgruppe. Gleichzeitig waren sie eher überzeugt, sicheren Code geschrieben zu haben. Geringeres Vertrauen und aktivere Auseinandersetzung mit den Vorschlägen gingen mit besseren Ergebnissen einher. Die genauen Ergebnisse sind wegen des älteren Modells nicht ohne Weiteres auf heutige Werkzeuge übertragbar; das untersuchte Risiko plausibler Vorschläge mit versteckten Fehlern bleibt dennoch relevant. Perry et al., Do Users Write More Insecure Code with AI Assistants?, Abstract sowie Abschnitte zu Security-Ergebnissen und Vertrauen. [claim-013]

Das widerspricht GitHubs positivem Qualitätstest nicht direkt. Zehn Unit-Tests für einen Webserver und subtile Sicherheitsfehler messen verschiedene Dinge. Eine KI kann Boilerplate zuverlässig ergänzen und zugleich bei Kryptografie, Berechtigungen oder Eingabevalidierung eine plausible falsche Annahme einbauen.

Für solche Aufgaben ist Navigator allerdings ebenfalls zu freundlich. Ein Navigator kennt den Weg. Das Modell liefert eher eine zusätzliche Karte, deren Druckdatum gelegentlich fehlt. Es kann Threats sammeln, Gegenbeispiele suchen und Tests vorschlagen. Die Invarianten und die Freigabe sollten aber bei Menschen und unabhängigen technischen Prüfungen bleiben.

Wartbarkeit liefert bisher kein Verbotsschild

Was passiert mit dem nächsten Entwickler?

Eine zweiphasige Studie mit 151 Teilnehmern, überwiegend professionelle Entwickler, ging dieser Frage direkter nach. In der ersten Phase entstanden Java-Lösungen mit oder ohne KI-Unterstützung. In der zweiten Phase mussten andere Teilnehmer diese Lösungen ohne KI weiterentwickeln. Bei Bearbeitungszeit und Codequalität zeigte sich kein signifikanter großer Unterschied. Borg et al., Echoes of AI, Abstract und Abschnitte zu RQ1/RQ2. [claim-014]

Das Ergebnis ist kleiner, als beide Lager gern hätten. Es widerlegt die Behauptung, KI-mitentwickelter Code werde zwangsläufig sofort unwartbar. Es beweist nicht, dass jahrelange Agentennutzung keine Architektur- oder Wissensschuld erzeugt. Untersucht wurden ein kleines System und begrenzte Änderungen; kleine Effekte waren statistisch schwer zu erkennen.

Langfristige Handlungsfähigkeit bleibt damit teilweise eine offene Designfrage. Gerade deshalb sollte sie nicht über den Anteil KI-generierter Zeilen beurteilt werden. Relevanter ist, ob das Team Anforderungen, Schnittstellen, Datenwege und Fehlermodi noch erklären und verändern kann.

Vier Fragen vor dem Rollenwechsel

Aus den Studien lässt sich kein etablierter Branchenstandard für Mensch-KI-Paare ablesen. Die folgende Entscheidungshilfe ist meine eigene Synthese.

1. Lerne ich gerade oder wende ich Bekanntes an?

Beim Lernen sollte die KI häufiger erklären, Rückfragen stellen, Beispiele kontrastieren und Hinweise geben. Sie darf auch Code erzeugen, wenn der Ablauf mich zwingt, ihn zu rekonstruieren oder zu verändern. Bei bekannter Routine darf sie mehr Implementierung übernehmen.

2. Kenne ich den Weg oder erkunde ich ihn?

Ist die Aufgabe bereits in kleine Schritte zerlegt, kann KI diese beschleunigen. Ist schon die Richtung unklar, sollte sie mehrere Wege mit Annahmen und Nachteilen zeigen, statt einen großen Patch als scheinbare Entscheidung zu liefern.

3. Wie günstig lässt sich das Ergebnis prüfen?

Klare Akzeptanzkriterien, Typen, kleine Diffs, Tests und Invarianten machen KI-Produktion attraktiv. Bei einer mechanischen Migration kann die Implementierung fast vollständig automatisiert sein. Wenn niemand präzise sagen kann, was richtiges Verhalten bedeutet, hilft zusätzliche Codegeschwindigkeit wenig.

4. Was kostet ein unbemerkter Fehler?

Bei einer reversiblen Darstellungskorrektur darf der Prozess leicht sein. Bei Authentifizierung, Datenmigration, Geld oder schwer rückgängig zu machenden Aktionen braucht es qualifizierte menschliche Prüfung und andere Evidenz als das Urteil desselben Modells, das den Code erzeugt hat.

Nehmen wir die E-Mail-Validierung vom Anfang. Wenn ich die verwendete Bibliothek kenne, ist das Lernziel gering und der technische Schritt bekannt. Syntaxregeln lassen sich gut testen. Ob eine Adresse tatsächlich erreichbar ist und welche Sonderfälle das Produkt akzeptieren soll, beantwortet der Validator dagegen nicht. Auf einem unverbindlichen Kontaktformular ist ein Fehler meist reversibel; wird die Adresse zur Identität oder zur Wiederherstellung eines Kontos, steigt das Risiko. Das Ergebnis dieser vier Fragen lautet nicht selbst tippen, sondern: erst die Produktregel festlegen, dann darf die KI implementieren; Tests und Review müssen genau diese Grenze prüfen.

Der stärkste Einwand gegen jede Zurückhaltung lautet: Was, wenn ich Spezifikation, Akzeptanzkriterien und Tests vollständig kontrolliere? Dann darf die KI auch die gesamte Implementierung übernehmen. Das ist kein Verlust von Handlungsfähigkeit. Die vier Fragen entscheiden nicht über den Anteil generierter Zeilen, sondern darüber, wo die kognitive Arbeit liegt.

Daraus ergibt sich ein einfacher Arbeitszyklus:

Der Mensch rahmt. Die KI schlägt vor oder erzeugt. Der Mensch prüft begrifflich und ausführbar. Die KI sucht Gegenbeispiele. Der Mensch entscheidet.

Auch das ist kein neues Framework. Es ist nur eine Erinnerung daran, dass Rollen innerhalb einer Aufgabe wechseln dürfen.

Was vor dem Schreiben geklärt sein sollte

Zurück zur E-Mail-Validierung.

Die ursprüngliche Frage, ob die KI das Schreiben verweigern sollte, war zu eng. Die bessere Frage ist, was ich beantworten können sollte, bevor sie schreibt. Ihre Antwort könnte lauten:

Ich kann die Funktion schreiben. Sag mir vorher, welche Adressen du akzeptieren willst, wo die Validierung stattfindet und was bei Unsicherheit passieren soll. Danach zeige ich dir die Annahmen und die Tests, an denen du meinen Vorschlag prüfen kannst.

Wenn ich diese Fragen beantworten kann, darf die KI den Code gern erzeugen. Wenn nicht, sollte sie nicht aus Prinzip schweigen. Sie sollte mir helfen, zuerst die richtigen Fragen zu klären.