Claude Code nach 18 Monaten: 20 Prozent, nicht 10x
Ich arbeite seit ungefähr anderthalb Jahren jeden Tag mit Claude Code. Shopware-Plugins, Shopware-Migrationen, ein Laravel-SaaS, dieser Blog. Wenn ich ehrlich schätze, spart es mir 20–25 Prozent meiner Zeit.
Das ist eine gute Zahl. Mit den 10x, die mir jede Woche in die Timeline gespült werden, hat sie aber wenig zu tun. Und sie ist deutlich besser als die Schlagzeile vom letzten Sommer, nach der KI einen langsamer macht. Beides kommt irgendwoher. Also hab ich mir die Studien noch mal richtig angeschaut, bevor ich meine eigenen Zahlen aufschreibe.
Was die Studien wirklich gemessen haben
Die bekannteste ist METRs randomisierte Studie von 2025. Sechzehn erfahrene Open-Source-Entwickler haben 246 Issues aus ihren eigenen Repos bearbeitet, meistens mit Cursor und Claude 3.5/3.7 Sonnet. Mit KI haben sie 19 Prozent länger gebraucht. Vorher hatten sie mit 24 Prozent Speedup gerechnet. Und hinterher dachten sie trotzdem, sie wären 20 Prozent schneller gewesen.
Diese Lücke zwischen Gefühl und Messung ist für mich das Spannendste an der ganzen Sache. Merk sie dir für meine Zahlen weiter unten.
Im Februar 2026 kam das Update, diesmal mit Tools von Ende 2025: 57 Entwickler, 143 Repos, über 800 Aufgaben. Die zehn, die schon beim ersten Mal dabei waren, brauchten mit KI jetzt rund 18 Prozent weniger Zeit (Konfidenzintervall −38 bis +9 Prozent), die 47 neuen rund 4 Prozent weniger (−15 bis +9). Beide Intervalle schließen null ein. Und die Studie selbst kam ins Rutschen: 30 bis 50 Prozent der Entwickler haben Aufgaben gar nicht erst eingereicht, weil sie die nicht ohne KI machen wollten. Da wird Randomisieren schwierig. METR nennt das eigene Ergebnis „nur sehr schwache Evidenz” für die Größe des Effekts und baut das Studiendesign um.
Dann gibt’s das obere Ende. METR hat 5.305 Claude-Code-Transkripte von sieben eigenen Leuten aus dem Januar 2026 ausgewertet und kommt bei den Aufgaben, die mit dem Agenten erledigt wurden, auf grob 1,5x bis 13x Zeitersparnis. Allerdings: Sie nennen das selbst eine weiche Obergrenze, und der LLM-Judge, der die Schätzungen macht, wurde nur an 34 menschlichen Labels überprüft. Den wichtigsten Satz schreiben sie gleich mit dazu: Wer bei KI-Aufgaben zehnmal so schnell ist, schafft deshalb wahrscheinlich noch lange nicht zehnmal so viel Wert.
In einer Umfrage vom Mai 2026 sagen 349 Leute aus technischen Berufen im Median, sie seien dreimal so schnell und ihre Arbeit sei 1,4- bis 2-mal so viel wert. Gleich daneben der Hinweis derselben Autoren: 2025 haben Leute den Effekt von KI auf ihre Zeit im Schnitt um 40 Prozentpunkte überschätzt.
Die großen Branchenumfragen passen ins Bild. Laut DORA 2025 nutzen 90 Prozent der Entwickler KI, im Median zwei Stunden am Tag. Der Report nennt KI einen „Spiegel und Multiplikator”: Sie verstärkt, was im Team sowieso schon da ist. Rob Bowley hat sich die sieben Team-Cluster aus dem Report angeschaut. Nur zwei davon schaffen mehr Durchsatz, ohne dass die Change-Failure-Rate steigt. Beim Stack Overflow Survey 2025 nutzen 84 Prozent KI-Tools oder haben es vor, aber 46 Prozent trauen den Ergebnissen nicht. Zwei Drittel nervt vor allem Code, der „fast richtig, aber eben nicht ganz” ist. 45 Prozent sagen, KI-Code zu debuggen dauert länger.
Unterm Strich: Wo sauber gemessen wird, liegt das Ergebnis irgendwo zwischen etwas langsamer und vielleicht 20 Prozent schneller. Wo Leute selbst schätzen, kommen 2–3x raus. Die 10x gibt’s nur als Obergrenze für einzelne Aufgaben. Meine 20–25 Prozent sind übrigens auch nur geschätzt. Da gehört derselbe Abschlag drauf wie bei allen anderen.
Wo es mir Zeit spart
Am deutlichsten bei kleinen Aufgaben in Code, den ich nicht kenne. Ein Kunde kommt mit einem Shopware-Plugin, das jemand anderes vor drei Jahren geschrieben hat. Er braucht ein zusätzliches Feld in der Administration oder einen Fix in einem Event-Subscriber. Früher war das eine Stunde, und die ging größtenteils fürs Lesen drauf: Welches Event? Welche Service-Definition? Wo hängt das Ding überhaupt dran? Heute sind es etwa 15 Minuten. Der Agent liest sich ein, ich schau mir an, wo er gelandet ist.
Das passt besser zur METR-Studie von 2025, als ich gedacht hätte. Die Leute dort waren Experten in Repos, die sie seit Jahren pflegen. Genau da bringt es mir auch am wenigsten.
Von der Konfiguration nutze ich alles: eine CLAUDE.md pro Projekt, Skills, Hooks, MCP-Server, Subagents. Aus Plugin-Marktplätzen kommt davon fast nichts. Was sich gehalten hat, hab ich größtenteils selbst gebaut, weil es so funktioniert, wie ich arbeite. Ein Skill released Shopware-Plugins mit zweisprachigen Changelogs, ein anderer prüft ein Plugin vor dem Upload gegen die Store-Regeln, und durch meine Review-Befehle ist auch dieser Artikel gelaufen. Die fertigen Sachen waren für den Workflow von jemand anderem gebaut. Die zurechtzubiegen hat länger gedauert, als selbst was zu schreiben.
Wo es mich Zeit kostet
Vor allem, wenn es sich Dinge ausdenkt. Claude Code ist sich bei Shopware-APIs, die es gar nicht gibt, erstaunlich sicher: Repository-Methoden und Event-Namen, die genau richtig klingen. Das Fiese ist, wann das auffällt. Nicht lokal, sondern erst in der Testsuite oder auf Staging. Jeder Fall kostet also einen kompletten Durchlauf statt eines zweiten Blicks. Mit den Leuten bei Stack Overflow, die sich über „fast richtig, aber eben nicht ganz” ärgern, fühle ich sehr mit.
Das andere sind Läufe, die aus dem Ruder laufen. Mit manchen Modellen ist aus einer Zwei-Zeilen-Änderung schon mal eine lange Session geworden: das halbe Repo gelesen, Tests immer wieder laufen lassen, Sachen umgeschrieben, um die keiner gebeten hat. Konzentriert an was anderem arbeiten kannst du in der Zeit nicht. Und manchmal ist das Ergebnis schlechter als die zwei Zeilen, die du selbst getippt hättest.
Wie ich reviewe, und warum das vom Gewinn was abknabbert
In einer Codebasis, die ich gut kenne, geht das Review schnell. Riecht es komisch? Wie groß ist der Diff? Welche Dateien hat er angefasst? Wenn ein Zehn-Zeilen-Fix vier Dateien ändert, stimmt was nicht, und ich schau genauer hin.
In Code, den ich nicht kenne, lese ich so lange, bis ich die Änderung verstanden habe. Sonst kann ich plausibel nicht von korrekt unterscheiden. Und das ist der unbequeme Teil: Wo der Agent mir am meisten Zeit spart, muss ich am genauesten hinschauen. Von den 45 Minuten, die ich beim fremden Plugin spare, geht ein Teil direkt wieder ins Review. Die 15 Minuten stimmen nur, wenn ich das nicht weglasse.
Das Geld
Ich zahle 90 Euro im Monat für den Max-5x-Plan. 20–25 Prozent von einem Vollzeitmonat sind irgendwas über 30 Stunden. Rein rechnerisch ist das keine schwere Entscheidung.
Aber denk an die 40 Prozentpunkte. Wenn ich mich genauso verschätze wie der Durchschnitt 2025, bin ich mit dem Tool sogar langsamer. Glaube ich nicht. Gerade die Aufgaben in fremden Codebasen kann ich ungefähr messen, und die gehen klar schneller. Für den Rest kann ich es aber nicht ausschließen.
Werde ich schlechter im Programmieren?
Wahrscheinlich ja. Allerdings eher beim Abrufen als beim Verstehen. Wenn ich festhänge, krame ich nicht mehr lange in meinem Kopf nach dem, was ich früher mal auswendig wusste. Ich frag einfach.
Wenn es morgen abgeschaltet würde, bräuchte ich ein paar Tage, um mich umzugewöhnen. Danach wäre ich hoffentlich so produktiv wie vorher. Wobei das „hoffentlich” in dem Satz ganz schön viel tragen muss.
Also, 10x?
Nein. Bei mir sind es solide 20 Prozent, die ich vor allem in fremdem Code hole und zum Teil im Review wieder abgebe. Das sind die 90 Euro im Monat locker wert. Beweisen kann ich es trotzdem nicht ganz.
Wenn du deine eigene Zahl willst und nicht meine oder die von METR, dann frag dich nicht, wie viel schneller du dich fühlst. Genau da lagen die Leute 2025 um 40 Prozentpunkte daneben. Nimm dir ein paar kleine Aufgaben, schreib vorher auf, wie lange jede ohne Agent dauern würde, und vergleich hinterher mit der Uhr. Grob, aber besser als Bauchgefühl.
Und wenn bei dir eine ganz andere Zahl rauskommt, egal in welche Richtung: Schreib mir, an was für Projekten du sitzt.