Der Code ist fertig. Das Denken geht jetzt los.

Ein Cent, über den niemand gesprochen hat

Nehmen wir eine kleine Rechnungsfunktion. Kein autonomes Fahrzeug, kein Kernkraftwerk. Ein paar Positionen, Nettopreise, Umsatzsteuer, Gesamtsumme. So eine Aufgabe, bei der man denkt: Na bitte, genau dafür haben wir doch jetzt KI. Für diesen Artikel liegt ein dokumentierter Modellversuch vor: Eine KI bekam die Aufgabe, so eine Funktion in Python zu schreiben. Gut dreißig Zeilen kamen heraus. Sie verwendet sogar einen Zahlentyp, der sich für dezimale Geldbeträge eignet, statt sich die üblichen Ungenauigkeiten von Fließkommazahlen einzuhandeln. Technisch erst einmal vernünftig.

Drei Stück zu 9,99 Euro netto, 19 Prozent Steuer: 35,66 Euro brutto. Stimmt. Jetzt vier Rechnungspositionen zu jeweils 15 Cent netto. Wieder 19 Prozent Steuer. Die Funktion addiert zunächst die Nettobeträge. 60 Cent mal 19 Prozent ergeben 11,4 Cent Steuer, gerundet also 11 Cent. Man kann aber auch die Steuer für jede Position einzeln berechnen und runden. Aus 2,85 Cent werden dann jeweils 3 Cent. Viermal 3 macht 12. Ein Cent Unterschied. Die Mathematik hat sich ordentlich benommen. Trotzdem müssen wir klären, welches Ergebnis unsere Anwendung liefern soll.

Die KI hat sich für einen Weg entschieden. In der Aufgabenstellung stand dazu nichts. Sie hat auch nicht nachgefragt. Und genau da wird es interessant: Eine offene fachliche Frage ist im fertigen Code plötzlich eine feste Regel. Ohne Besprechung, ohne Entscheidungsvorlage, ohne den lästigen Kollegen, der noch einmal nachfragt. Sehr effizient. Bis jemand wissen möchte, warum die Zahlen vom anderen System abweichen. Der gewählte Rechenweg lässt sich natürlich im Code erkennen. Was dort fehlt, ist die Begründung: Ist das so vereinbart? Passt das zum Rest der Rechnungsstellung? Oder hat das Modell einfach die naheliegende Variante genommen?

Der Computer rechnet auch Unsinn gewissenhaft aus

Das zweite Beispiel ist weniger subtil. Die Funktion erwartet den Steuersatz als 0.19. Übergibt jemand stattdessen 19, berechnet sie auf 100 Euro netto stolze 1.900 Euro Steuer. Macht 2.000 Euro brutto. Da freut sich höchstens jemand, der die Rechnung nicht bezahlen muss.

Die Vorgabe hatte das Zahlenformat ausdrücklich genannt. Die Funktion prüft es bloß nicht. Vielleicht übernimmt das ein anderer Teil der Anwendung. Vielleicht auch nicht. Wer den Baustein einsetzt, muss es wissen. Das ist kein exklusives KI-Problem. Menschen schreiben solche Funktionen ebenfalls. Menschen vergessen Eingabeprüfungen und treffen Annahmen, die sie anschließend niemandem erzählen. Dafür haben wir lange vor ChatGPT schon reichlich Übung gehabt.

Nur können wir solche Bausteine jetzt sehr viel schneller erzeugen. Und wenn ich mehr davon übernehme, muss ich entsprechend mehr Entscheidungen nachvollziehen. Oder ich lasse welche durchrutschen. Meine Sorge ist, dass wir uns an die Geschwindigkeit der Ausgabe gewöhnen und unsere Prüfung daran anpassen: schneller drüberschauen, wird schon passen. Ob das in einem konkreten Team passiert, muss man untersuchen. Aus einer Rechnungsfunktion lässt sich kein Urteil über die gesamte Softwarebranche ableiten. Aber sie zeigt ziemlich anschaulich, wonach man suchen sollte.

Früher von Hand war auch nicht automatisch besser

Jetzt könnte ich die Lochkarten hervorholen und behaupten, damals hätten wir wenigstens noch gewusst, was wir tun. Wäre eine schöne Geschichte. Nur würde ich sie selbst nicht glauben. Auch handgeschriebene Software kann ein undurchdringlicher Haufen sein. Und wer eine Funktion selbst geschrieben hat, ist noch lange nicht ihr bester Prüfer. Die eigenen Annahmen fühlen sich schließlich besonders vernünftig an.

Ich will die heutigen Werkzeuge behalten. Gerade mit Erfahrung können sie enorm nützlich sein: Ich kann einen Vorschlag einordnen, nachhaken und eine Alternative verlangen. KI kann mir beim Verstehen helfen, fremden Code erklären oder auf einen Fall bringen, an den ich selbst nicht gedacht habe. Es wäre absurd, ausgerechnet diese Möglichkeiten liegen zu lassen.

Was ich ihr trotzdem nicht einfach abnehmen kann, ist die Entscheidung, was meine Anwendung für ihre Nutzer leisten soll. Ein Modell kann mir verschiedene Rundungsverfahren erklären. Welches davon zu unserem Ablauf passt, muss geklärt werden. Dazu braucht es Informationen aus diesem Ablauf. Mehr erzeugter Code liefert die nicht von allein.

Ein brauchbarer Test braucht eine begründete Erwartung. Bei unseren vier Positionen müsste jemand festlegen, welches Ergebnis gelten soll und warum. Danach lässt sich wunderbar automatisch prüfen, ob die Software diese Regel auch morgen noch einhält. Die KI kann sogar die fehlende Entscheidung bemerken und nachfragen. Das wäre in diesem Fall die hilfreichere Antwort gewesen als sofort fertiger Code. Wir sollten solche Rückfragen ausdrücklich verlangen, statt jede Unterbrechung als verlorene Zeit zu betrachten. Im dokumentierten Versuch hat übrigens derselbe KI-Assistent die Funktion geschrieben und anschließend geprüft. Das ist ein Beispiel mit begrenzter Aussagekraft, keine unabhängige Qualitätsprüfung. Die beiden Auffälligkeiten sind trotzdem im Code und in den protokollierten Ergebnissen sichtbar.

Wie viel schneller? Bitte die ganze Arbeit zählen.

Natürlich kann KI Zeit sparen. In einem kontrollierten Copilot-Experiment erledigte die Gruppe mit KI eine klar umrissene Programmieraufgabe 55,8 Prozent schneller. Es ging um einen HTTP-Server in JavaScript. Ein ordentliches Ergebnis für diese Aufgabe, keine pauschale Lieferzeitgarantie für Softwareprojekte. Studie von Peng und Kollegen, 2023.

METR fand 2025 in einem anderen Versuch das Gegenteil: 16 erfahrene Entwickler brauchten bei Aufgaben in ihren vertrauten Open-Source-Projekten mit KI im Schnitt 19 Prozent länger. Besonders hübsch: Hinterher glaubten sie trotzdem, ungefähr 20 Prozent Zeit gespart zu haben. Das gute Gefühl hatte offenbar keine Stoppuhr dabei. METR-Studie, 2025. Die Zahl eignet sich allerdings nicht als ewiger Beweis gegen KI. METR vermutete im Februar 2026 inzwischen größere Vorteile, hielt die eigenen Folgedaten wegen Verzerrungen bei der Teilnahme und Aufgabenauswahl aber für wenig belastbar. METR-Update, Februar 2026.

Für mich folgt daraus eine ziemlich bodenständige Forderung: Zählt die Arbeit bis zu dem Punkt, an dem die Änderung tatsächlich verwendbar ist. Einschließlich Lesen, Rückfragen, Testen und Nachbessern. Sonst messen wir, wie schnell etwas auf dem Bildschirm erscheint. Auch wenn wir insgesamt schneller werden, kann die Prüfung zum Engpass werden. Beides passt problemlos zusammen. Wenn das Schreiben weniger Zeit braucht, fällt die übrige Arbeit stärker ins Gewicht. Ob ihre absolute Dauer wächst, ist damit noch nicht gesagt.

In einem halben Jahr fragt jemand nach Skonto

Stellen wir uns vor, unsere Rechnungsfunktion läuft seit Monaten. Jetzt soll Skonto dazukommen. Die nächste KI kann den vorhandenen Code lesen und erweitern. Sie sieht, wie gerundet wird. Aber ob das eine bewusst vereinbarte Regel war oder ein Überbleibsel des ersten Vorschlags, steht dort immer noch nicht.

Dann beginnt die Sucherei. Warum machen wir das so? Muss es so bleiben? Was erwartet das angeschlossene System? An dieser Stelle hilft ein kurzer Satz, der damals die Entscheidung festgehalten hätte, womöglich mehr als eine weitere Seite automatisch erzeugter Dokumentation. „Wir runden je Steuersatz auf die Nettosumme, weil …“ Das Entscheidende steht hinter dem „weil“. Für mich gehört dieses Wissen zur Software. Sonst liefern wir dem nächsten Menschen zwar eine funktionierende Maschine, lassen ihn aber raten, wofür ihre Einstellungen gedacht waren.

Wer wissen will, ob das im eigenen Team gerade schiefläuft, kann klein anfangen. Ein paar Wochen lang beobachten, wie lange Änderungen vom ersten fertigen Code bis zur Freigabe brauchen und wie oft danach korrigiert werden muss. Bei einigen Änderungen genauer nachsehen: Welche fachlichen Regeln wurden eingebaut, ohne dass sie irgendwo vereinbart waren? Das ist weniger spektakulär als eine Präsentation über zehnfache Produktivität. Dafür erfährt man vielleicht etwas über das eigene Projekt.

Ich werde weiter mit KI entwickeln. Mit erheblichem Vergnügen sogar. Aber bei „fertig“ möchte ich genauer hinsehen. Wer kann erklären, warum dieser Code für unsere Aufgabe richtig ist? Und was passiert, wenn jemand ihm etwas anderes vorsetzt als den freundlichen Normalfall?

Bei unserer kleinen Rechnung fängt das mit einem Cent an. Den würde ich gerne verstehen, bevor ich die nächste Million Zeilen bestelle.

Zum Rechnungsbeispiel: Grundlage sind eine Python-Funktion und ein Prüfprotokoll mit zehn Fällen aus einem dokumentierten Modellversuch mit Claude Sonnet 5.5 am 15. Oktober 2026. Es handelt sich um einen einzelnen Modellversuch, nicht um ein Kundenprojekt. Eine Zeitersparnis wurde dabei nicht gemessen. Die Szenen zur späteren Erweiterung sind Gedankenbeispiele.