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.

Meine bisherigen Erfahrungen mit Agentic Coding

Viele Diskussionen über KI klingen aktuell so, als würde durch Agenten automatisch Wissen verloren gehen.

Meine Erfahrung ist bisher eine andere.

Ich habe nicht das Gefühl, dass ich dadurch Fähigkeiten verliere.

Eher im Gegenteil:

Mein technischer Hintergrund wird wichtiger.

Ich kann Konzepte verstehen, Architekturen bewerten, Fehler erkennen und die richtigen Fragen stellen.

Genau diese Fähigkeiten brauche ich, um Agenten sinnvoll einzusetzen.

Agenten ersetzen kein Engineering

Ein Agent ist kein magischer Softwareentwickler, der eine Idee in ein perfektes Produkt verwandelt.

Er braucht:

• Kontext
• klare Ziele
• technische Leitplanken
• jemanden, der Ergebnisse kritisch bewertet

Ich lese weiterhin Code.

Ich schaue mir Diffs an.

Ich versuche zu verstehen, was geändert wurde und warum.

Das ist vielleicht sogar wichtiger geworden, weil die Geschwindigkeit steigt.

Wenn man in kurzer Zeit viele Änderungen erzeugen kann, muss man umso besser beurteilen können, welche davon sinnvoll sind.

Die Veränderung liegt woanders

Weniger Zeit geht dafür drauf, jede einzelne Zeile manuell zu schreiben.

Mehr Zeit fließt in:

• Architektur
• Anforderungen
• Kommunikation
• Qualität
• die Frage: Bauen wir eigentlich das Richtige?

Natürlich ist das auch eine neue Fähigkeit, die man entwickeln muss.

Man muss lernen, Agenten richtig anzuleiten, gute Kontexte bereitzustellen und die Zusammenarbeit mit ihnen zu verbessern.

Das ist kein fertiger Prozess.

Es ist eine Reise.

Nicht, weil KI den Menschen ersetzt.

Sondern weil Menschen mit einem guten Verständnis für Technologie plötzlich Dinge umsetzen können, für die früher viel mehr Zeit oder ein größeres Team notwendig gewesen wäre.

Warum ich bei vutuv nicht nur diskutieren möchte

Ein weiterer Grund, warum ich vutuv spannend finde, ist die Art, wie man sich beteiligen kann.

Ich arbeite selbst seit vielen Jahren im Technologie- und Innovationsumfeld.

Ich kann ordentlich coden, bin mit Linux auf der Kommandozeile groß geworden und verstehe Softwarearchitekturen, technische Konzepte und die Entscheidungen dahinter.

Aber Softwareentwicklung ist nicht mein Vollzeitjob – und niemand beherrscht jede Programmiersprache, jedes Framework und jede Toolchain gleichermaßen gut.

Das heißt aber nicht, dass mir Ideen fehlen oder ich nicht sehr konkrete Vorstellungen davon habe, wie etwas funktionieren und technisch umgesetzt werden sollte.

Genau hier finde ich Agentic Coding spannend

Für mich bedeutet Agentic Coding nicht:

“Die KI schreibt schon irgendwas und fertig.”

Im Gegenteil.

Mein technisches Hintergrundwissen brauche ich ständig, um Agenten sinnvoll zu dirigieren.

Ich muss verstehen, welchen Weg sie einschlagen, Entscheidungen hinterfragen, Diffs lesen und mir weiterhin den Quellcode ansehen.

Was sich verändert, ist vor allem die Menge an Handarbeit zwischen einer Idee und ihrer Umsetzung.

Nicht weniger Engineering – sondern anderes Engineering

Statt mich tagelang in jede neue Programmiersprache oder jedes Framework einarbeiten zu müssen, kann ich schneller experimentieren, ausprobieren und konkrete Lösungen entwickeln.

Dabei hat mir auch @wintermeyer mit seinem letzten Heise-Beitrag zu Agenten sehr aus der Seele gesprochen.

Ich finde es schwierig, wenn Open-Source-Projekte KI entweder grundsätzlich ablehnen oder Regeln schaffen, die am Ende so kompliziert werden, dass ein großer Teil des Produktivitätsgewinns wieder verloren geht.

Natürlich brauchen Agenten Leitplanken.

Aber wir wissen heute noch nicht perfekt, wie diese aussehen müssen.

Wir müssen experimentieren, lernen und unsere Arbeitsweisen verbessern:

• bessere Guidelines

• bessere Skills

• bessere Tests

• bessere Reviews

Das ist eine Reise.

Und genau deshalb sind Open-Source-Projekte für mich eine ideale Spielwiese:

Man lernt neue Werkzeuge kennen und schafft gleichzeitig echten Mehrwert.

Deshalb möchte ich bei vutuv nicht nur Feature-Wünsche äußern.

Wenn aus “Ich hätte da eine Idee” mit Hilfe von Agenten irgendwann “Hier ist der Pull Request” wird, finde ich das ziemlich großartig.

Diese Woche habe ich gelesen wie ein Entwickler geschrieben hat, das er vor 30 Jahren aufgehört hat Assembler Code zu lesen und einfach dem Compiler vertraut hat. Heute macht er das gleiche mit Source Code und Agents. Es liest sich den Source Code nicht mehr durch. Er arbeitet nur noch mit dem Agenten.

Ich finde den Vergleich sehr treffend.

Caveman: Claude Code redet wie Höhlenmensch

Im ohnehin dichten Strom neuer Claude-Code-Skills sticht ein Repository ungewöhnlich weit heraus. Caveman von Julius Brussee sammelt seit Anfang April 2026 über 90.000 GitHub-Sterne ein. Die Prämisse ist so simpel wie kurios: Der Skill weist Claude Code an, in einer rudimentären, an Höhlenmenschen erinnernden Kurzform des Englischen zu antworten. Ein Alltagsbeispiel zeigt das Prinzip. Vorher: „It is going to rain later this afternoon, so you might want to take an umbrella with you“. Nachher: „Rain later. Take umbrella“. Das Motto aus dem README bringt die Idee auf den Punkt: „why use many token when few do trick“.

Was der Skill tut

Caveman bündelt Slash-Commands, einen MCP-Wrapper (Middleware zwischen Claude und externen Werkzeugen) und ein Skript zur Verdichtung der Memory-Dateien. Aktiviert wird der Modus per /caveman oder Klartext-Anweisung „talk like caveman“. Drei Stufen sind in der Praxis relevant: lite (leichte Kürzung), full (Default) und ultra (radikal). Brussee verspricht 65 bis 75 Prozent Token-Ersparnis. Daneben kondensiert /caveman-commit Commit-Botschaften, /caveman-review schrumpft PR-Kommentare auf eine Zeile, und /caveman-compress verdichtet Markdown-Memorys laut README um 46 Prozent.

Die Installation läuft in 30 Sekunden per curl-Einzeiler (macOS, Linux, WSL) oder PowerShell-irm (Windows). Voraussetzung: Node.js ab Version 18, Lizenz MIT. Neben Claude Code unterstützt der Skill rund 30 weitere Coding-Agenten, darunter Codex, Cursor und Copilot.

Was den Reiz ausmacht

Zwei Gründe sprechen für Caveman. Erstens die Token-Ökonomie. Wer Claude häufig nutzt, kennt die anschwellenden Token-Zähler. Ein um zwei Drittel kürzerer Output schlägt sich unmittelbar in der Abrechnung nieder und füllt das Kontextfenster langsamer, weil er als Verlauf in jeden weiteren Turn einfließt. Die Statistik /caveman-stats weist das eingesparte Volumen sogar in US-Dollar aus.

Zweitens die Geschwindigkeit, gleich in zweifacher Hinsicht: Eine Zeile wie „Off-by-one in pagination loop. Uses < not <=“ erfasst sich schneller als der ausformulierte Stand der Lehre, den erfahrene Entwickler längst kennen. Und weil LLMs Tokens sequenziell erzeugen, sinkt mit kürzerem Output auch die Antwortzeit. Bei langen Erklärungen spürbar, bei knappen Antworten weniger.

Wo der Charme bröckelt

So weit die Werbeprosa. In der Realität stößt das Konzept rasch an Grenzen, die das Repository selbst nicht thematisiert.

Die wichtigste betrifft die Sprache. Sämtliche Regeln im Skill-Prompt sind auf Englisch zugeschnitten. Der Skill weist Claude an, die Artikel a, an und the zu streichen, listet englische Füllwörter wie „just“, „really“, „basically“, „actually“ und „simply“ sowie englische Höflichkeitsfloskeln wie „sure“, „certainly“ oder „happy to“. Die mitgelieferten Beispiele zeigen ausschließlich englische Ausgaben. In der Praxis funktioniert der Modus deshalb nur auf Englisch gut.

Die zweite Grenze ist die Nuance. Komprimierung ist immer Verlust. Aus „This pattern is acceptable because the component owns its state, but in a shared-state context it would cause re-renders“ wird in full schnell „state local, fine. shared, bad“. Die Aussage stimmt im Kern, die für eine Architekturentscheidung relevante Bedingung verschwindet jedoch. Erfahrene Entwickler kompensieren das mit Nachfragen, die allerdings jede Token-Ersparnis ad absurdum führen, weil jede Klärung selbst wieder Tokens kostet. Einsteiger nehmen die verkürzte Heuristik unter Umständen als Regel. Genau hier liegt die Crux: Der Modus spart Token in jenen Antworten, in denen die Nuancen am ehesten zählen.

Zwei Erkenntnisse aus der KI-Forschung erweitern diese Skepsis. Sprachmodelle sind auf vollständige Prosa trainiert; reguläre Antworten liegen näher an dieser Trainingsverteilung und fallen schon deshalb substanzieller aus. Eine ACL-2024-Studie (Jin et al.) zeigt zudem: Verkürzte Reasoning-Schritte mindern die Leistung selbst bei erhaltener Information. Caveman beschneidet damit jenen „Denkraum“, den das Modell sonst über seine Ausgabe-Tokens entfaltet.

Hype-Kurve und stille Indizien

Die Sterne-Kurve stützt eine vorsichtige Lesart. Nach dem viralen Initialschub flacht das tägliche Wachstum sichtbar ab. Auch die offenen Issues häufen sich schneller, als Commits sie abarbeiten. Eindeutig zu lesen ist das nicht: Es kann ein Warnsignal sein, ebenso gut aber Folge einer Zeit, in der KI-Assistenten Issues und Pull Requests in einem Tempo einreichen, das ein einzelner Maintainer kaum noch sortieren kann.

Das wichtigste Indiz: Wäre das Konzept ein echtes Produktivitätswerkzeug, hätte Anthropic selbst längst eine vergleichbare Funktion in Claude Code eingebaut oder das Projekt übernommen. Bislang ist davon nichts zu sehen. Auch in Teams, die den Skill in Coding-Sessions testen, bleibt nach informellen Berichten nur ein Bruchteil dauerhaft beim Caveman-Modus.

Was sich mitnehmen lässt

Den Kern der Idee gibt es auch ohne Plugin. Eine kurze Anweisung in der projektweiten CLAUDE.md oder der globalen ~/.claude/CLAUDE.md reicht:

- Fasse dich kurz. Verzichte auf Höflichkeitsfloskeln, einleitende
  Bestätigungen und Wiederholungen der Frage.
- Antworte direkt mit dem technischen Kern, gerne in Stichpunkten.
- Code-Blöcke, Fehlermeldungen und Bezeichner bleiben unverändert.

Das funktioniert sprachneutral und lässt vollständige Sätze zu, wo Nuancen tragen. Hooks und MCP-Wrapper bleiben außen vor, der Lerngewinn nicht.

Fazit

Caveman ist ein gelungener Hack und ein Beleg dafür, wie schnell ein Meme heute GitHub-Trends dominiert. Als gelegentliches Experiment für Routinesitzungen lässt sich der Modus rechtfertigen. Als Default-Setting für seriöses Pair-Programming taugt er nicht. Wer Token sparen will, fährt mit dieser CLAUDE.md-Regel besser. Antworten zu kürzen bleibt eine gute Idee. Der Höhlenmensch-Sprech muss es dafür nicht sein.

Pro und Contra