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