Schneller tippen heißt
nicht schneller fertig.

Die häufigste Frage im Erstgespräch hat sich verschoben. Sie lautet nicht mehr „Wie lange dauert das?“, sondern „Warum dauert das überhaupt noch, du hast doch KI?“. Die ehrliche Antwort passt nicht in einen Satz – sie hat damit zu tun, was beim Programmieren eigentlich die Zeit kostet.

Der Nachmittag, der zwei Tage sparte

Ein Kunde brauchte einen Import: Produktdaten aus der Warenwirtschaft, einmal täglich als CSV, hinein in den Shop. Angesetzt hatte ich zwei Tage – Einlesen, Validierung, Fehlerbericht per Mail, Tests.

Fertig war es an einem Nachmittag. Der Assistent kannte das Muster, ich kannte das Muster, und was er vorschlug, sah aus wie das, was ich selbst geschrieben hätte. Die Tests liefen durch, der erste echte Import lief durch, der Kunde war zufrieden.

Drei Wochen später kam der Anruf: Bei einem Teil der Artikel steht der falsche Steuersatz. Danach saß ich anderthalb Tage vor Code, der von mir stammt und den ich nie Zeile für Zeile gelesen hatte. Die Frage, auf die es beim Debuggen ankommt, konnte ich nicht beantworten: Warum macht er es so? Am Ende war es ein Feld, das die Warenwirtschaft als leeren String statt als null liefert, und irgendwo in der Kette gab es eine Behandlung dafür, die ich nie bewusst getroffen hatte.

Die zwei Tage waren nicht gespart. Sie sind umgezogen.

Das ist keine Geschichte darüber, dass Assistenten nichts taugen. Der Nachmittag war echt, und ich würde ihn wieder so arbeiten. Es ist eine Geschichte über eine Rechnung, die nur die eine Hälfte erfasst: Gemessen wurde die Zeit bis zum Feature. Nicht gemessen wurde, was es kostet, diesen Code zu besitzen.

Was die Messungen hergeben

Belastbare Zahlen zu dieser Frage gibt es weniger, als die Lautstärke der Debatte vermuten lässt. Drei Erhebungen sind trotzdem brauchbar, wenn man sie nebeneinanderlegt.

METR, ein Institut für Modellevaluation, hat im Sommer 2025 einen randomisierten Versuch veröffentlicht: 16 erfahrene Open-Source-Entwickler, 246 echte Aufgaben in ihren eigenen, großen Repositories. Pro Aufgabe wurde ausgelost, ob der Assistent erlaubt war. Vorher schätzten die Teilnehmer, sie würden dadurch etwa 24 Prozent schneller. Hinterher, nach getaner Arbeit, schätzten sie eine Beschleunigung von 20 Prozent. Gemessen wurde eine Verlangsamung von 19 Prozent.

Diese Zahl wird seitdem viel zitiert, und sie trägt weniger, als sie scheint. METR selbst hat das Studiendesign im Februar 2026 überarbeitet und dabei offengelegt, warum: Gerade die Entwickler mit den höchsten Erwartungen an KI nahmen erst gar nicht teil, weil sie zeitweise ohne sie arbeiten sollten, und ein erheblicher Teil der Teilnehmer reichte genau die Aufgaben nicht ein, bei denen sie auf den Assistenten nicht verzichten wollten. Eine spätere Runde deutet in die andere Richtung – auf einer Datenbasis, von der die Autoren ausdrücklich abraten, sie als Beleg zu lesen.

Was von der Studie bleibt, ist deshalb nicht die 19. Es ist der Abstand zwischen geschätzt und gemessen, und der zeigte in beiden Runden in dieselbe Richtung: Die Beteiligten halten sich für schneller, als die Uhr sagt.

Der DORA-Bericht 2025 von Google Cloud befragte rund 5.000 Fachleute. 90 Prozent nutzen KI bei der Arbeit, über 80 Prozent berichten von mehr Produktivität. Im selben Bericht steht aber auch, was seltener mitzitiert wird: Höhere KI-Nutzung geht mit höherem Durchsatz einher und mit mehr Instabilität in der Auslieferung. 30 Prozent haben wenig oder gar kein Vertrauen in den Code, den sie täglich übernehmen.

Die Stack-Overflow-Umfrage 2025 benennt den Grund dafür ziemlich genau. Die größte Frustration, von 66 Prozent der Befragten genannt, sind Lösungen, die fast richtig sind, aber nicht ganz. Auf Platz zwei, mit 45 Prozent: Das Debuggen von KI-generiertem Code dauert länger.

Prüfen skaliert nicht mit

Dahinter steht ein einfacher Mechanismus. Programmieren besteht aus zwei Tätigkeiten, die sich völlig unterschiedlich verhalten: etwas herstellen und feststellen, ob das Hergestellte stimmt.

Das Herstellen lässt sich vervielfachen. Ein Assistent schreibt dreihundert Zeilen in der Zeit, in der du eine schreibst, und er wird dabei nicht müde.

Das Feststellen lässt sich nicht vervielfachen. Es läuft in deinem Kopf, in Lesegeschwindigkeit, und es ist bei fremdem Code teurer als bei eigenem. Wenn du eine Funktion selbst schreibst, entsteht das Verständnis nebenbei: Du hast jede Entscheidung getroffen, also kennst du sie. Kommt derselbe Code fertig an, musst du dieses Verständnis nachträglich herstellen – und dieser Posten taucht beim Selberschreiben gar nicht erst auf.

Solange die Ausgabe klein ist, fällt das nicht weiter auf. Ab einer bestimmten Menge kippt es: Der Assistent liefert schneller, als du lesen kannst. Dann passiert das, was in jedem Team passiert, in dem die Pull Requests zu groß werden – man liest nicht mehr, man überfliegt. Und Überfliegen findet genau die Sorte Fehler nicht, um die es hier geht.

Eine 2025 veröffentlichte Untersuchung von Microsoft Research und der Carnegie Mellon University hat 319 Wissensarbeiter zu 936 konkreten Aufgaben befragt. Der interessanteste Befund ist nicht, dass KI-Nutzung die empfundene Denkanstrengung senkt – das ist ja ihr Zweck. Interessant ist das Paar dahinter: Je mehr jemand dem Werkzeug vertraute, desto weniger prüfte er nach. Je mehr jemand der eigenen Fachkenntnis vertraute, desto mehr prüfte er nach.

Praktisch heißt das: Am wenigsten kontrolliert wird dort, wo man selbst am wenigsten kann. Das ist genau die Stelle, an der Kontrolle nötig wäre. Auch das ist eine Selbstauskunft und keine Messung – wie gründlich jemand tatsächlich geprüft hat, weiß die Studie nicht. Mit dem, was ich bei Projektübernahmen sehe, deckt es sich trotzdem.

Was im Repository zurückbleibt

Die zweite Hälfte der Rechnung steht nicht im Kalender, sondern im Code.

GitClear, ein Anbieter für Code-Analyse, wertet seit Jahren Versionsverläufe aus, zuletzt 623 Millionen Änderungen aus den Jahren 2023 bis 2026. Dort laufen zwei Kurven auseinander. Der Anteil verschobener, also refaktorierter Zeilen ist von 21 Prozent im Jahr 2022 auf 3,8 Prozent im laufenden Jahr gefallen. Der Anteil kopierter Zeilen ist im selben Zeitraum von 9,4 auf 15,7 Prozent gestiegen.

Die Zahlen kommen von einem Unternehmen, das Werkzeuge für genau diese Messung verkauft, und sie zeigen eine Gleichzeitigkeit, keine Ursache. Die Richtung ist trotzdem plausibel, weil sie sich aus der Arbeitsweise ergibt: Wiederverwenden setzt voraus, dass man weiß, was es schon gibt. Duplizieren setzt nur voraus, dass man die aktuelle Datei sieht. Ein Assistent sieht zuverlässig die aktuelle Datei.

Ein Beispiel aus diesem Projekt. Der Blog hier benutzt eine Kachel, zw-blog-card, die Rahmen, Radius, Hover-Zustand und Schatten mitbringt. Frage ich nach einem Teaser für eine neue Referenzen-Seite, ohne den Bestand mitzugeben, bekomme ich zuverlässig so etwas:

// Sieht im Browser richtig aus – und kennt den Bestand nicht.
.referenz-karte {
  background: #ffffff;
  border: 1px solid #e5e7eb;
  border-radius: 14px;
  overflow: hidden;
  transition: transform .25s ease, box-shadow .25s ease;

  &:hover {
    transform: translateY(-4px);
    box-shadow: 0 12px 28px rgba(0, 0, 0, .08);
  }

  &__titel {
    color: #e6195d;
    font-weight: 700;
  }

  &__mehr {
    color: #e6195d;
    text-decoration: none;
  }
}

Das ist nicht falsch. Es sieht korrekt aus, und es besteht jedes Review, das auf Funktion schaut. Es hat nur den Markenton zweimal fest eingetragen, den Radius neu erfunden und eine dritte Stelle geschaffen, die beim nächsten Redesign jemand finden muss. Der Bestand hätte das hier hergegeben:

// Die Kachel steht in _page-blog.scss und bringt Rahmen, Radius, Schatten und
// Hover-Zustand schon mit. Der Markenton kommt aus _variables.scss. Neu ist
// deshalb nur, was an einer Referenz tatsächlich anders ist als an einem Artikel.
.zw-blog-card {
  &--referenz &__visual {
    height: 12rem;   // Referenzen zeigen ein Projektfoto, kein Icon
  }
}

Drei Zeilen statt zwanzig, und der nächste Farbwechsel bleibt eine Änderung an einer Stelle. Den Unterschied macht nicht das Modell, sondern die Vorarbeit: Der Assistent hatte die Kachel nie gesehen, weil ich sie ihm nicht gezeigt habe. Genau dieser Schritt ist es, den das Tempo einspart – und er ist der, der den Unterschied zwischen einem Repository und einer Ansammlung von Dateien ausmacht.

Wegwerfbar oder besitzbar

Daraus folgt keine Regel wie „nur für einfache Sachen“. Einfach und schwierig ist die falsche Achse: Ein Assistent scheitert an trivialem Code mit einem Sonderfall genauso wie an komplexem.

Die Achse, die bei mir trägt, ist eine andere. Wird dieser Code weggeworfen oder besessen?

Weggeworfen wird das meiste, was man an einem Tag schreibt, ohne es je wieder anzusehen. Ein Skript, das eine Tabelle einmalig umsortiert. Eine Auswertung für eine Frage, die nach der Antwort erledigt ist. Testdaten. Ein Prototyp, der nur klären soll, ob eine fremde Schnittstelle das kann, was im Handbuch steht. Hier ist die Prüfung billig, weil sie nur lautet: Stimmt das Ergebnis? Und wenn der Code hässlich ist, schadet das niemandem, denn er ist morgen weg.

Besessen wird alles, was ins Repository geht und wieder gelesen wird. Hier lautet die Prüfung nicht „stimmt das Ergebnis“, sondern „verstehe ich, warum es so ist“ – und diese Prüfung kostet ungefähr das, was das Schreiben gekostet hätte. Das ist der Punkt, an dem die Beschleunigung rechnerisch verschwindet.

• check_circle Einmalige Skripte, Datenmigrationen, Auswertungen: erzeugen lassen, Ergebnis prüfen, danach löschen.
• check_circle Testdaten und Fixtures: erzeugen lassen – der Test selbst ist die Prüfung.
• check_circle Prototypen zur Klärung einer Frage: erzeugen lassen und nach der Antwort tatsächlich wegwerfen, statt sie produktiv zu setzen.
• check_circle Schnittstellen, Datenmodelle und Zugriffsregeln: selbst entwerfen, erst danach ausfüllen lassen.
• check_circle Fremder Bestand, den du noch nicht kennst: erst selbst lesen, dann ändern lassen.
• check_circle Alles, was Geld, Rechtsverbindlichkeit oder personenbezogene Daten berührt: Zeile für Zeile lesen, ohne Ausnahme.

Wie ich seitdem arbeite

Vier Dinge haben sich seit diesem Import geändert, und keines davon ist eine Einstellung im Werkzeug.

Die Schnittstelle schreibe ich selbst. Signatur, Rückgabetyp, Fehlerfälle – und den Test, der das festhält. Erst danach darf der Rumpf entstehen. Das kostet zwanzig Minuten und ist die Entscheidung, für die ich bezahlt werde. Der Rumpf ist Ausführung.

Ich begrenze die Menge, nicht die Qualität. In einen Commit geht nichts, was ich von einem Kollegen nicht in einer Sitzung durchgelesen hätte. Meine Grenze liegt bei etwa zweihundert Zeilen; darüber teile ich die Aufgabe, statt schneller zu lesen.

Die Commit-Nachricht ist der Test. In diesem Projekt begründet der Rumpf einer Commit-Nachricht die Entscheidung, nicht nur das Ergebnis. Wenn ich diese Begründung nicht in zwei Sätzen hinschreiben kann, habe ich den Code nicht verstanden, und dann geht er auch nicht rein. Das ist der billigste Verständnistest, den ich kenne, und er dauert eine Minute.

Ein Werkzeug zur Zeit. Das ist der Punkt, an dem ich mich selbst am meisten überrascht habe.

Zwischen Assistent im Editor, Agent im Terminal, Review-Bot im Pull Request und Chat im Browser war ich an manchen Tagen für vier Ausgaben zuständig, von denen keine meine war. Das Gefühl dabei ist nicht Überlastung, sondern etwas Harmloseres und deshalb Gefährlicheres: Beschäftigung. Es fühlt sich nach Arbeit an, während man im Grunde nur noch nickt.

Fazit

Ein Assistent ist eine Verschiebung, keine Ersparnis. Er nimmt Arbeit beim Schreiben weg und legt sie beim Prüfen wieder hin – und beim Prüfen gibt es keinen Hebel, der so wirkt wie beim Schreiben.

Das ist kein Argument dagegen, sondern eines dafür, die Rechnung vollständig aufzumachen. Ein Nachmittag statt zwei Tagen ist ein klarer Gewinn, wenn der Code danach wegkann. Bei Code, den jemand drei Jahre lang pflegt, steht die zweite Hälfte der Rechnung noch aus – und sie wird nicht von dem bezahlt, der den Nachmittag abgerechnet hat.

Die Frage, die ich mir vor einer Aufgabe inzwischen stelle, ist deshalb nicht, ob der Assistent das kann. Er kann erstaunlich viel. Die Frage ist, wer diese Datei in einem Jahr aufmacht, und ob dieser Jemand dann eine Chance hat zu verstehen, warum sie tut, was sie tut.