KI-Nutzung ist einsam

Wer heute mit KI arbeitet, arbeitet allein. Das Gegenüber ist da und antwortet sofort, und trotzdem sieht niemand zu. Niemand sieht, wie die Session gelaufen ist, wo sie hakte, was dreimal gesagt werden musste, bis das Ergebnis stand. Am Ende liegt ein Text, ein Skript, eine Auswertung auf dem Tisch, und das Ergebnis sieht gut aus. Der Weg dorthin ist weg.

Das klingt harmlos, bedeutet aber, dass jede Person den Umgang mit dem Werkzeug für sich allein lernt und dieses Wissen niemanden erreicht.

Das ist eine Beobachtung aus meiner eigenen Arbeit, keine Studie. Ich kann sie nicht beweisen, und ich schreibe sie trotzdem auf, weil ein paar Zahlen, die ich nachgeschlagen habe, in dieselbe Richtung zeigen. Darum geht es hier: warum das so ist, warum es kaum jemandem auffällt, und was dagegen hilft.

Der zweite Platz am Tisch ist besetzt

Beim Programmieren gab es dafür einmal ein Verfahren: Pair Programming. Zwei Personen, eine Tastatur. Eine tippt, die andere denkt mit, fragt nach und sieht den Fehler, bevor er im Code landet. Der Nutzen kam nie vom Tippen, sondern vom Zusehen.

Eine KI-Session sieht auf den ersten Blick genauso aus. Eine Person, ein Gegenüber, das mitdenkt und antwortet. Und das betrifft längst nicht nur Leute, die programmieren: Wer das volle Potenzial will, landet bei den Kommandozeilenwerkzeugen aus der Softwareentwicklung, auch ohne je eine Zeile Code schreiben zu wollen. Texte, Auswertungen, Recherchen, ganze Arbeitsabläufe laufen heute über Werkzeuge, die für Programmierarbeit gebaut wurden.

Nur ist der zweite Platz am Tisch von der KI besetzt. Der Mensch, der zusieht und irgendwann fragt “Warum hast du das jetzt so formuliert?”, fehlt. Die KI stellt diese Frage nicht, sie macht weiter.

Das Gewicht geht hoch, also stimmt die Technik

Wer allein im Fitnessstudio trainiert, merkt lange nicht, wenn die Ausführung falsch ist. Das Gewicht geht hoch, die Zahl auf der Scheibe steigt, alles sieht nach Fortschritt aus. Den Schaden sieht Jahre später erst die Physiotherapie.

Mit der KI ist es dasselbe. Sie liefert immer etwas Plausibles, es gibt keinen Compilerfehler, keine Kollegin, die beim Lesen die Stirn runzelt, keinen Moment, in dem das Werkzeug sagt: So hättest du es schneller haben können. Das Ergebnis ist der einzige Maßstab, und das Ergebnis sieht fast immer gut aus.

Daraus entsteht eine Selbstüberschätzung, die niemand böse meint. Wer mit dem eigenen Ergebnis zufrieden ist, sieht keinen Grund, von anderen zu lernen, und schon gar nicht von deren Fehlern. Die Notwendigkeit verschwindet nicht, sie wird nur unsichtbar.

Das ist nicht nur mein Eindruck. Eine Studie der Aalto University (Fernandes u. a., Computers in Human Behavior, 2026) ließ 246 Teilnehmende mit ChatGPT Aufgaben zum logischen Denken lösen, eine zweite Runde mit 452 Teilnehmenden wiederholte das. Mit KI schnitten alle besser ab, und alle überschätzten ihre Leistung. Am stärksten überschätzten sich die, die am meisten über KI wussten. Die meisten stellten pro Aufgabe genau eine Frage und übernahmen die Antwort.

“Ich tausche mich doch aus”

Stimmt, über KI wird viel geredet: welches Modell gerade besser ist, welcher Prompt funktioniert hat, welche neue Funktion es gibt. Das ist Rezepttausch, und Rezepte sind nützlich. Er läuft heute dort, wo auch sonst alles läuft, in Posts und Likes, und ein Like ist das Gegenteil von Zusehen.

Gemeinsam gekocht wird dabei trotzdem nicht. Kaum jemand sitzt zu zweit vor einer Session. Kaum jemand erzählt, an welcher Stelle das Gespräch mit der KI gekippt ist, wie es zurückgeholt wurde, welche Rückfrage den Unterschied gemacht hat. Genau dieses Wissen ist das Wertvolle, und genau dieses Wissen verblasst oft schon, während die Session noch läuft. Am Ende bleibt das Ergebnis und ein vages “Nächstes Mal mache ich das anders”.

Wie genau, bleibt das Geheimnis der Person. Und so erarbeitet sich im selben Team jede Person dasselbe Wissen noch einmal, Session für Session, allein.

Die Zahlen dazu gibt es. Nach dem Ivanti Technology at Work Report 2025 verschweigt knapp ein Drittel der Beschäftigten, die KI nutzen, das ihrem Arbeitgeber; 36 Prozent davon sagen, sie mögen den geheimen Vorteil. Im AI Paradox Report 2026 von Employment Hero sagt die Hälfte der Beschäftigten, ihr Arbeitgeber tue wenig oder nichts, damit sie KI lernen, und mehr als die Hälfte hat es sich über YouTube, TikTok, Reddit und Discord beigebracht. Wer einen Vorteil geheim hält, teilt ihn nicht. Wer bei YouTube lernt, lernt allein.

Pair Prompting: zu zweit vor eine Session

Die Lösung ist alt und braucht keine neue Software. Sie braucht eine zweite Person. Und sie braucht eine Warnung vorweg.

Microsoft hat bei Gap Inc. mit 388 Beschäftigten getestet, was passiert, wenn Paare ein vorgeschriebenes Protokoll für gemeinsame KI-Nutzung befolgen müssen (Farach u. a.,März 2026). Die Paare mit Protokoll lieferten an diesem Tag schlechtere Dokumente und seltener überhaupt eins. Zur Einordnung: Alle Autoren arbeiten bei Microsoft, das Werkzeug war Copilot, die Studie ist nicht vorregistriert, und benotet hat ein Sprachmodell, das lange Texte mag. Das schreiben die Autoren selbst. Gemessen wurde Output an einem Nachmittag, nicht, was die Paare voneinander gelernt haben. Ich nehme aus der Studie trotzdem eines mit: Verordnete Zusammenarbeit wird zur Koordinationsaufgabe und verdrängt die Arbeit.

Die Gegenprobe gibt es auch, vorregistriert und ohne Einfluss des Unternehmens auf die Ergebnisse: ein Feldexperiment der Harvard Business School mit 791 Fachleuten bei Procter & Gamble (Dell’Acqua u. a., Organization Science, 2026). Einzelpersonen und Zweierteams arbeiteten jeweils mit und ohne KI an echten Produktideen. Eine Person mit KI war so gut wie ein Team ohne. Das klingt zunächst wie ein Argument gegen den zweiten Menschen, und genau deshalb passt es in diesen Text: Der zweite Platz am Tisch ist tatsächlich besetzt. Zweierteams mit KI waren im Schnitt nicht messbar besser als Einzelpersonen mit KI. Unter den besten zehn Prozent der Lösungen aber waren die Teams mit KI deutlich häufiger. Der Unterschied zwischen gut und herausragend kam vom zweiten Menschen.

Deshalb geht es im Folgenden nicht um Vorschrift und nicht um schnellere Ergebnisse. Es geht darum, dass jemand sieht, wie die andere Person arbeitet.

Ein Beispiel, das mir nahe liegt: dieser Text. Er ist mit KI entstanden, und kein Gedanke darin stammt von ihr. Die Inhalte sind meine, die KI hilft beim Formulieren, mal mehr, mal weniger, je nachdem, wie gut ich an dem Tag selbst schreibe. Dass das funktioniert, liegt an Vorarbeit, die im Text unsichtbar bleibt: ein Profil, in dem steht, wie ich schreibe und was ich nicht lesen will, dazu eine Reihe weiterer Anleitungen für wiederkehrende Aufgaben. Das hat mich Wochen gekostet, und ich bin bis heute nicht sicher, ob ich es richtig gemacht habe, weil es niemand gesehen hat.

Die meisten überlassen diese Anpassung dem Werkzeug. Die KI schreibt sich selbst Notizen über das, was zufällig in einem Gespräch vorkam, und hält das für ein Profil. Das ist kein Fehler des Werkzeugs, es weiß nicht, was fehlt. Nur: Woher soll jemand wissen, dass hinter einem guten KI-Text Wochen Vorarbeit stecken, wenn die Wörter ohne diese Vorarbeit auch schon flüssig kommen? Und wer zeigt dieser Person, wie sie anfängt? Die KI selbst kann das nur bedingt. Sie kann sagen, was technisch geht. Sie sieht nicht, was bei mir über Monate funktioniert hat und was still gescheitert ist, weil sie jede Sitzung bei null anfängt. Diesen Vergleich hat nur, wer mir über die Schulter geschaut hat. Bisher niemand.

Drei Dinge, die das ermöglichen:

• Zu zweit an einer Session arbeiten: Eine halbe Stunde, ein Bildschirm, eine Person tippt, die andere sieht zu und fragt nach: Warum jetzt diese Rückfrage? Warum hast du den Vorschlag verworfen? Woran hast du gemerkt, dass die KI vom Thema abkommt? Die Fragen sind das Training, für beide.
• Verläufe teilen statt Ergebnisse: Das fertige Dokument zeigt nicht, wie es entstanden ist. Der Chatverlauf zeigt es. Wer einen Verlauf mit einer Kollegin durchgeht, lernt in zehn Minuten mehr über deren Arbeitsweise als aus zehn fertigen Dokumenten.
• Stolpersteine aufschreiben, solange sie frisch sind: Nach der Session drei Zeilen: Was musste ich der KI dreimal sagen? Wo hat sie mich falsch verstanden? Was würde ich beim nächsten Mal zuerst sagen? Sichtbar für das Team, nicht in der eigenen Notiz-App.

Das alte Gegenargument gilt nicht mehr

Pair Programming hat sich nie flächendeckend durchgesetzt, und der Grund war immer derselbe: Es fühlte sich teuer an. Zwei Leute für die Arbeit von einer. Bei Microsoft hatten 2008 22 Prozent der Befragten je zu zweit programmiert; im laufenden Projekt taten es 3,5 Prozent.

Bei der KI trägt das Argument nicht mehr. Die Arbeit macht das Werkzeug. Die zweite Person kostet nur noch die halbe Stunde, in der sie zusieht. Was diese halbe Stunde einspart, sieht heute niemand, weil niemand weiß, was die andere Person längst gelernt hat.

Wie ich aktuell mit mehreren Coding-Agenten arbeite

Inzwischen merke ich immer deutlicher: Es gibt nicht den einen perfekten Agenten – und vermutlich auch nicht die eine perfekte Entwicklungsumgebung – für alles.

Ich arbeite aktuell vor allem mit Claude und Codex und merke dabei, dass beide unterschiedliche Stärken haben.

Claude gefällt mir häufig bei Planung, Struktur und einer ersten Umsetzung innerhalb vorhandener Projektregeln. Codex empfinde ich oft als pragmatischer und direkter und setze ihn deshalb gerne als zweiten Blick oder für Reviews ein.

Dabei ist das aber längst kein fester Workflow mehr.

Je nach Aufgabe wechsle ich zwischen den Werkzeugen und lasse auch bewusst einen Agenten auf die Arbeit des anderen schauen.

Der eigentliche Schlüssel ist gemeinsamer Kontext

Damit das funktioniert, muss das Repository selbst gut vorbereitet sein.

Guidelines, Skills, Projektregeln, Tests und eine verständliche Entwicklungsumgebung werden für mich immer wichtiger.

Denn wenn jeder Agent erst wieder neu erraten muss, wie ein Projekt aufgebaut ist und welche Regeln gelten, verliert man einen großen Teil des Produktivitätsgewinns.

Mein Ziel ist deshalb weniger, den „besten“ Agenten zu finden.

Ich möchte ein Projekt so vorbereiten, dass unterschiedliche Agenten sinnvoll daran arbeiten können und austauschbar bleiben.

Agentische Entwicklung findet für mich nicht nur in Agent-First-IDEs statt

Ich nutze VS Code mit Devcontainern ebenfalls intensiv für agentische Entwicklung.

Der Unterschied ist für mich eher: Dort kann ich den Agenten wesentlich besser auf die Finger schauen.

Ich sehe Dateien, Diffs und die Struktur des Projekts direkt vor mir, kann Änderungen gezielt nachvollziehen und habe stärker das Gefühl, jederzeit eingreifen zu können.

Agent-First-Umgebungen wie Claude Code oder Codex sind dagegen besonders angenehm, wenn ich eine Aufgabe stärker delegieren und den Agenten relativ selbstständig daran arbeiten lassen möchte.

Für mich läuft es deshalb nicht auf VS Code oder Agent hinaus.

Und auch nicht auf Claude oder Codex.

Sondern auf eine Kombination daraus – abhängig davon, was ich gerade erreichen möchte und wie eng ich die Umsetzung begleiten will.

Vielleicht ist genau das die neue Fähigkeit:

Nicht nur Code zu schreiben, sondern für jede Aufgabe den richtigen Agenten, den richtigen Kontext und die passende Arbeitsumgebung zusammenzubringen.

Bei aller Begeisterung für Agentic Coding bleibt für mich eine Frage offen:

Was bedeutet das eigentlich für die nächste Generation von Entwicklerinnen und Entwicklern?

Ich habe darauf keine einfache Antwort.

Denn bei mir selbst merke ich sehr deutlich: Der Grund, warum ich Agenten heute sinnvoll einsetzen kann, ist mein technischer Hintergrund.

Ich verstehe Konzepte, Architekturen und Abhängigkeiten und kann zumindest beurteilen, ob ein eingeschlagener Weg plausibel ist.

Aber was passiert ohne dieses Fundament?

Ich kann mir nur schwer vorstellen, wie es wäre, mit Agentic Coding aufzuwachsen, ohne vorher selbst Code geschrieben, gelesen, debuggt und Systeme von Grund auf verstanden zu haben.

Genau hier sehe ich eine echte Herausforderung.

Ich glaube nicht, dass die Zukunft darin liegt, jede Zeile Code weiterhin von Hand schreiben zu müssen.

Aber wir dürfen auch nicht den Fehler machen, Verständnis durch reine Bedienung zu ersetzen.

Wer Software nur noch über Agenten erzeugt, ohne die Grundlagen zu verstehen, kann irgendwann kaum noch beurteilen, ob das Ergebnis wirklich gut, sicher oder überhaupt sinnvoll ist.

Und daraus entsteht eine weitere Abhängigkeit: von den Modellen, Werkzeugen und Plattformen, die diese Arbeit für uns übernehmen.

Deshalb bleiben offene Technologien und Wissen wichtig

Das betrifft nicht nur einzelne Entwickler, sondern langfristig unsere gesamte digitale Infrastruktur.

Gerade deshalb halte ich offene Standards, Open Source und Wissenstransfer für wichtiger denn je.

Wir müssen die neuen Werkzeuge nicht ablehnen.

Wir müssen lernen, sie richtig einzusetzen – und gleichzeitig dafür sorgen, dass Menschen weiterhin verstehen, was sie damit erschaffen.

Vielleicht ist genau das eine der großen Aufgaben beim Agentic Coding:

Nicht zu verhindern, dass Maschinen uns Arbeit abnehmen.

Sondern sicherzustellen, dass wir trotzdem noch wissen, was sie da eigentlich für uns tun.