Stundensatz oder Festpreis: Vom Wert der Erfahrung beim Programmieren mit KI

Worum es geht

Es gibt Rechnungen, die uns beleidigen, weil wir die Arbeit nicht gesehen haben. Im März 1965 erzählte ein Leser des Magazins Life von einer solchen Rechnung. In Henry Fords Werk River Rouge sei ein gewaltiger Generator ausgefallen, und die eigenen Ingenieure wussten nicht weiter. Man rief Charles Proteus Steinmetz von General Electric. Er hörte der Maschine zwei Tage und Nächte lang zu, rechnete, verlangte schließlich nach Leiter, Maßband und Kreide und setzte einen Kreidestrich auf das Gehäuse. An dieser Stelle ließ er sechzehn Windungen aus der Feldspule entfernen. Der Generator lief wieder. Dann kam die Rechnung: 10.000 Dollar.

Ford, der etwas von Effizienz verstand, bat um eine Aufschlüsselung. Steinmetz berechnete einen Dollar für den Strich und 9.999 Dollar für das Wissen, wohin er gehört. Die Kreide, darf man annehmen, hätte Ford sich auch selbst leisten können. Man versteht den Ingenieur. Man versteht allerdings auch den Kunden, der gern gewusst hätte, wie dieser Preis zustande kam.

Vermutlich ist die Geschichte erfunden. Der Zitatforscher Garson O'Toole fand ihre Pointe bereits 1907 in einer Lokalzeitung aus Yorkshire, ausdrücklich als Fabel (1). Offenbar braucht jede Generation einen neuen Ingenieur, um sich darüber zu wundern, dass Können die Arbeit verkürzt, von deren Dauer es leben soll. Man betrachtet den Handgriff und vermisst die Mühe. Die Erfahrung hat ihre Spuren verwischt.

Heute sitzt der Verdacht vor einem Bildschirm. Eine KI schreibt in Minuten Code, für den gestern noch Stunden veranschlagt wurden. Der Auftraggeber sieht die Beschleunigung und erwartet, völlig zu Recht, dass sie auf seiner Rechnung ankommt. Nur verrät das Tempo wenig darüber, was da entstanden ist. Funktioniert die Lösung? Hält sie dem Betrieb stand? Und wer erkennt den Fehler, dem die Maschine bereits eine tadellose Form gegeben hat?

Ein fairer Preis muss deshalb drei Dinge auseinanderhalten: den Aufwand des Anbieters, den Nutzen für den Auftraggeber und das Risiko, das beide mit einem Projekt eingehen. Die Berufung auf Erfahrung allein genügt dafür ebenso wenig wie der Blick auf die Uhr.

Ein Stundensatz entsteht rückwärts, aus den Kosten. Angenommen, eine Entwicklerin verdient 70.000 Euro brutto im Jahr. Mit dem Arbeitgeberanteil zur Sozialversicherung kostet sie ihren Arbeitgeber rund ein Fünftel mehr, also etwa 85.000 Euro. Hinzu kommen Gemeinkosten, die auf jeden Kopf entfallen: Büro, Hardware, Softwarelizenzen, Buchhaltung, Weiterbildung, Akquise, die Verwaltung des Ganzen. In einer kleinen Agentur sind 30.000 Euro pro Person dafür keine kühne Annahme. Am Ende stehen gut 115.000 Euro Vollkosten im Jahr.

Geteilt wird diese Summe durch die Stunden, die sich tatsächlich verkaufen lassen, und das sind weniger, als man denkt. Nach Wochenenden, Feiertagen, Urlaub und Krankheit bleiben rund 210 Arbeitstage, also knapp 1.700 Stunden. Davon gehen Abstimmungen ohne Auftrag ab, Angebote, Fortbildung, interne Weiterentwicklung und die kurze Supportfrage, für die niemand ein Ticket schreibt. Realistisch sind etwa zwei Drittel fakturierbar, rund 1.100 Stunden. Die Grundformel lautet also:

Kalkulatorischer Mindeststundensatz = jährliche Vollkosten ÷ fakturierbare Jahresstunden

Im Beispiel ergibt das rund 105 Euro netto, die Selbstkostengrenze. Erst darauf kommen Wagnis und Gewinn; mit einem Aufschlag von etwa 15 Prozent liegt der angestrebte Verkaufssatz um 120 Euro netto. Schon eine andere Auslastung verschiebt das Ergebnis erheblich. Zur Orientierung: IT-Freiberufler im deutschsprachigen Raum verlangen laut dem aktuellen Freelancer-Kompass im Median 95 Euro (2). Vergleichbar sind die Zahlen nur bedingt, denn Freiberufler haben eine andere Kostenstruktur und tragen Altersvorsorge, Absicherung und Leerlauf selbst.

Die Rechnung ist nützlich, weil sie eine Untergrenze zieht: Unterhalb dieses Satzes arbeitet ein Unternehmen auf Dauer gegen sich selbst. Einen Anspruch auf diesen Erlös begründet sie nicht. Eine teure Organisation kann eine einfache Leistung anbieten, eine gut organisierte eine schwierige Aufgabe günstig lösen. Über den Wert einer Leistung sagt die Kalkulation deshalb nichts. Die Stunde ist ein Divisor, kein Produkt. Niemand beauftragt eine Agentur, weil er 40 Stunden erwerben möchte; er will eine Anwendung, die funktioniert, sicher ist und in drei Jahren noch gepflegt werden kann. Dass sich trotzdem fast alle Angebote der Branche in Stunden ausdrücken, ist eine Gewohnheit, die lange gut funktioniert hat, weil Zeit und Ergebnis grob miteinander wuchsen.

Dass sich Programmierende in ihrer Produktivität stark unterscheiden, gehört zu den ältesten Beobachtungen der Disziplin. Schon 1968 maßen Harold Sackman und seine Kollegen bei vergleichbar erfahrenen Programmierern Unterschiede in der Bearbeitungszeit um ein Vielfaches (3). Die Studie ist methodisch angreifbar, ihr Grundbefund kaum: Dieselbe Aufgabe kostet den einen einen Nachmittag und den anderen eine Woche. Was das für die Abrechnung bedeutet, zeigt ein Gedankenexperiment. Zwei Entwickler sollen eine Schnittstelle zwischen Website und Mitgliederverwaltung umsetzen. Der eine hat so etwas schon ein Dutzend Mal getan und braucht vier Stunden, der andere tastet sich heran und braucht vierzehn. Bei gleichem Stundensatz erzielt der zweite den dreieinhalbfachen Umsatz, ohne dass der Auftraggeber ein besseres Ergebnis erhält.

Langsamer heißt dabei nicht schlechter, und Einarbeitung ist kein Vorwurf. Es kommt darauf an, welche gemeint ist. Die Eigenheiten einer Organisation, ihre Abläufe, Daten und Systeme muss auch ein erfahrener Dienstleister erst verstehen. Allgemeine Grundlagen auf Kosten des Kunden nachzuholen, ist etwas anderes. Ein gutes Angebot macht erkennbar, wo ein Projekt neue Erkenntnisse verlangt und wo vorhandene Kompetenz einfließt. Wo diese Grenze verschwimmt, bezahlt der Auftraggeber das Lernen mit Stunden. Man könnte von einer Ineffizienzprämie sprechen.

Der Markt gleicht das nur teilweise aus. Erfahrene Leute verlangen höhere Sätze, aber die Spreizung der Stundensätze ist weit geringer als die Spreizung des Aufwands. Wer anderthalbmal so viel pro Stunde kostet und dreimal so schnell ist, ist für den Auftraggeber die günstigere Wahl, wirkt auf dem Papier aber teurer. Warum sollte, wer eine Aufgabe in vier Stunden löst, an ihr weniger verdienen als jemand, der vierzehn braucht? Der niedrigere Stundensatz kann die höhere Rechnung ergeben, und wer nur Sätze vergleicht, blendet genau die Erfahrung aus, die den Aufwand begrenzt. Die Abrechnung nach Zeit erzeugt so einen Wahrnehmungsfehler, der beide Seiten etwas kostet.

Bei einer Abrechnung nach Aufwand zählt die tatsächlich geleistete, vereinbarte Arbeit. Erfahrung fließt in den Stundensatz ein; bei klar beschriebenen Leistungen kann sie auch die Grundlage eines vorab vereinbarten Festpreises sein.

Mit KI-Werkzeugen verschiebt sich, worin Erfahrung besteht. Das Tippen war selten der Engpass, und KI beschleunigt vor allem etwas anderes: das Ausformulieren von Lösungen. Eine Berufseinsteigerin mit einem guten Agenten bringt heute in kurzer Zeit erstaunlich viel lauffähigen Code hervor. Was sich nicht angleicht, ist das Wissen darüber, was an diesem Code falsch ist.

Das gemeinnützige Institut METR ließ Anfang 2025 sechzehn erfahrene Open-Source-Entwickler reale Aufgaben in ihren eigenen Projekten erledigen, zufällig verteilt mit und ohne KI. Mit KI brauchten sie im Schnitt 19 Prozent länger, waren hinterher aber überzeugt, schneller gewesen zu sein (4). Ein im Februar 2026 veröffentlichtes Update zur Nachfolgestudie deutet auf Zeitgewinne mit neueren Werkzeugen hin; METR selbst hält diese Daten wegen mehrerer Verzerrungen aber für kein verlässliches Maß, unter anderem, weil viele Entwickler gar nicht mehr ohne KI arbeiten wollten. Belastbar ist vor allem die Lücke zwischen Gefühl und Messung.

Hinzu kommt die Qualität dessen, was die Maschine liefert. Der Anbieter CodeRabbit, der KI-gestützte Code-Reviews verkauft und am Thema naturgemäß Interesse hat, verglich Ende 2025 knapp 500 Pull Requests aus Open-Source-Projekten. In Änderungen, an denen KI mitgeschrieben hatte, fanden sich pro Pull Request im Schnitt etwa 1,7-mal so viele Probleme, darunter deutlich mehr Logikfehler und Sicherheitsmängel (5).

Das ist keine allgemeine Fehlerquote pro Codezeile, und ob eine Änderung tatsächlich von KI oder von Menschen stammte, ließ sich nicht in jedem Fall sicher bestimmen. Die Richtung deckt sich trotzdem mit dem, was viele Teams berichten. Solcher Code sieht plausibel aus und besteht oft die ersten Tests. Eine Schnittstelle funktioniert im Test und legt im Betrieb bei einer unterbrochenen Verbindung Datensätze doppelt an; eine Berechtigungsprüfung behandelt den normalen Zugriff korrekt und übersieht einen seltenen Sonderfall.

Was das im Betrieb ganzer Unternehmen bedeutet, haben die Harvard-Ökonomen Fiona Chen und James Stratton untersucht. Sie werteten Aktivitätsdaten aus mehr als 700 Softwarefirmen aus, erhoben bis März 2026 (6). Nach Einführung teilautonomer Agenten entstanden im Schnitt 30 Prozent mehr Codezeilen und 23 Prozent mehr Pull Requests; Tickets und größere Vorhaben wurden deshalb aber nicht messbar häufiger abgeschlossen. Der Zeitgewinn versickerte in der Prüfung.

Vom Einreichen eines Pull Requests bis zu seiner Übernahme verging fast die Hälfte mehr Zeit, der Anteil zurückgewiesener Änderungen verdoppelte sich beinahe, und mehr Beschäftigte als zuvor waren mit Reviews befasst. Die Autoren deuten das als Stau hinter der Schreibphase. Ihre Daten sind beobachtet, nicht experimentell erhoben, und reichen nicht bis zu den jüngsten Werkzeugen. Sie bestätigen trotzdem eine alte Einsicht der Fertigungslehre: Eine Produktion wird nur so schnell wie ihre langsamste Station.

Erfahrung zeigt sich darin, die passende Gegenfrage zu stellen. Was passiert, wenn die Antwort ausbleibt? Wer darf diese Daten tatsächlich sehen? Welche Annahme gilt nur in der Testumgebung? Wer so fragt, hat die Fehler meist schon einmal gemacht oder bei anderen gesehen. Darin liegt der Kreidestrich von heute: zu wissen, welchen Teil einer Aufgabe ein Agent zuverlässig erledigt, welcher Teil menschliche Prüfung braucht und wo in zweitausend generierten Zeilen das eigentliche Problem steckt. Die Verifikation wird damit zum Engpass. Je günstiger das Erzeugen von Code wird, desto knapper wird, gemessen an der erzeugten Menge, das Urteilsvermögen, das ihn bewertet.

Noch früher fällt eine Entscheidung, die sich in keiner Zeile Code zeigt: ob der erzeugte Code überhaupt gebraucht wird. Vielleicht genügt eine vorhandene Funktion, vielleicht lässt sich ein Ablauf vereinfachen, statt eine weitere Schnittstelle einzuführen. Jede vermiedene Abhängigkeit erspart über Jahre Pflege. Die wertvollste technische Entscheidung kann darin bestehen, etwas nicht zu entwickeln, und auf der Stundenliste erscheint sie als kleine Zahl.

Werkzeuge haben in der Softwareentwicklung immer Geld gekostet: Lizenzen, Testinfrastruktur, Server. Diese Kosten waren aber weitgehend fix; ob man eine Entwicklungsumgebung viel oder wenig nutzte, änderte die Rechnung kaum. Bei nutzungsabhängigen KI-Diensten kann jeder zusätzliche Versuch zusätzliche Grenzkosten erzeugen; Abonnements bündeln einen Teil davon, intensive Agentenarbeit sprengt diesen Rahmen schnell. Anthropic beziffert die durchschnittlichen Kosten für sein Werkzeug Claude Code in der eigenen Dokumentation auf rund 13 Dollar pro aktivem Entwicklertag, 150 bis 250 Dollar im Monat.

Noch im April 2026 hatte dort die Hälfte gestanden; das Unternehmen verdoppelte die Schätzung, nachdem ein leistungsfähigeres Modell zum Standard geworden war. Gartner erwartet weiter steigende Kosten, weil Infrastrukturinvestitionen und Profitabilitätsdruck die Modellpreise nach oben treiben, und merkt trocken an, dass Entwickler ihre Werkzeuge eher nach Tempo und Bequemlichkeit auswählen als nach den Kosten (7).

Zwei Rechenszenarien zeigen die Größenordnung. Ein KI-Budget von 400 Euro im Monat ergibt, verteilt auf 1.100 fakturierbare Stunden, gut vier Euro pro Stunde. Bei 2.000 Euro, wie sie bei intensiver Agentenarbeit entstehen können, sind es über 20 Euro, ein Fünftel der Selbstkosten. Vorausgesetzt ist jeweils, dass diese Kosten nicht schon in den Gemeinkosten stecken. Bei Modellpreisen, die eher steigen als sinken, ist das keine Randgröße mehr.

KI ist damit ein Produktionsmittel wie Miete oder Hardware und gehört in die Kalkulation, mit ihren Kosten ebenso wie mit dem Produktivitätsgewinn, den sie ermöglicht. Hohe Werkzeugkosten rechtfertigen sich allerdings so wenig von selbst wie hohe Personalkosten. Ein Agent, der wiederholt in die falsche Richtung arbeitet, wird durch seinen Verbrauch nicht wertvoller; Auswahl und Begrenzung der Werkzeuge gehören zur Kompetenz des Anbieters.

Für Auftraggeber zählt die gesamte Rechnung. Ein höherer Stundensatz kann zu einer niedrigeren Projektsumme führen, ein niedriger Satz wenig nützen, wenn sich daneben Nutzungsgebühren sammeln. Ob Werkzeuge im Satz enthalten sind oder über ein eigenes Budget abgerechnet werden, sollte aus dem Angebot hervorgehen.

Die Mechanik lässt sich an einer einzigen Aufgabe zeigen. Ein Modul, das früher zehn Stunden Arbeit bedeutete, kostete bei 120 Euro pro Stunde 1.200 Euro netto. Mit einem gut eingesetzten Agenten und einer erfahrenen Person, die das Ergebnis prüft, dauert es heute vielleicht sechs Stunden. Bei unverändertem Stundensatz erhält der Auftraggeber den Preisvorteil unmittelbar: Er zahlt 720 Euro für ein Ergebnis, das womöglich gründlicher getestet ist als zuvor. Der Anbieter gewinnt vier Stunden freie Kapazität, während er die zusätzlichen Werkzeugkosten trägt. Ob daraus ein wirtschaftlicher Vorteil wird, hängt davon ab, ob sich die gewonnene Zeit wieder verkaufen lässt.

Das ist keine Selbstverständlichkeit. Freie Stunden werden erst zu Umsatz, wenn genügend Nachfrage da ist und jemand die zusätzlichen Aufträge gewinnt, betreut und abstimmt. Für kleinere Dienstleister mit einem festen Kundenstamm ist das ein spürbares Risiko, und es erklärt, warum die Stundenlogik gerade jene unter Druck setzt, die früh in Werkzeuge und Kompetenz investieren. Manche heben deshalb ihre Sätze an, andere weisen ein Werkzeugbudget transparent aus, wieder andere nutzen die Kapazität für zusätzliche Projekte.

Fair wird es, wenn beide Seiten am Gewinn teilhaben, und eine Vereinbarung kann das ausdrücklich regeln. Ein Festpreisvon 900 Euro für dasselbe, klar beschriebene Modul läge deutlich unter der früheren Summe und ließe dem Anbieter Spielraum für Werkzeuge und Prüfung. Dauert die Umsetzung kürzer, bleibt der Preis; dauert sie länger, ebenfalls; zusätzliche Anforderungen brauchen eine neue Absprache. Zeitabrechnung und Festpreis verteilen Unsicherheitunterschiedlich, und welche Form passt, hängt davon ab, wie viel sich zu Beginn schon wissen lässt.

Unter dem Begriff Value-based Pricing wird eine weitere Frage seit Jahren diskutiert, in der Softwarebranche aber selten konsequent gestellt: Was verbessert die Lösung beim Auftraggeber? Der Preis orientiert sich dann am Wert des Ergebnisses, und die interne Stundenkalkulation dient als Plausibilitätsprüfung nach unten. Ein Verband, dessen Geschäftsstelle jedes Jahr wochenlang Tagungsanmeldungen abtippt, gewinnt mit einer sauberen Online-Anmeldung Arbeitszeit, weniger Fehler und früher verfügbare Daten. Ehrlich gerechnet zählt dabei der Nutzen nach Betriebskosten: Einführung, Schulung, Pflege und laufender Betrieb gehören ebenso in die Rechnung wie die eingesparte Erfassungszeit.

Einen beliebigen Anspruch auf die Einsparung gibt ein hoher Nutzen dem Anbieter allerdings nicht. Es kann günstigere Alternativen geben, der Nutzen kann unsicher sein, und ein Teil des Erfolgs hängt von der Organisation selbst ab. Der eigentliche Wert der Betrachtung liegt oft schon vor der Preisverhandlung: Sie hilft, das richtige Projekt zu beauftragen. Eine technisch eindrucksvolle Erweiterung kann wirtschaftlich nebensächlich sein, eine kleine Änderung an einem täglich wiederkehrenden Ablauf dagegen viel bewirken.

Ein Festpreis ist noch keine wertorientierte Preisgestaltung. Er legt zunächst nur die Vergütung für einen vereinbarten Leistungsumfang fest; woran sich ihre Höhe bemisst, ist eine eigene Entscheidung, und oft entsteht er schlicht aus geschätzten Stunden plus Risikozuschlag. Er verlagert das Risiko: Läuft ein Projekt aus dem Ruder, trägt der Anbieter die Mehrarbeit.

Gerade hier zahlt sich Erfahrung ein zweites Mal aus, denn wer zwanzig Mitgliederportale umgesetzt hat, kann das einundzwanzigste verlässlich einschätzen. Sinnvoll ist häufig eine Folge von Vereinbarungen: zunächst eine begrenzte Analyse nach Aufwand, dann feste Preise für ausreichend geklärte Leistungen, später ein passendes Modell für Pflege und Weiterentwicklung. Die Analyse verringert Unsicherheit so weit, dass beide Seiten vernünftig entscheiden können. Auch das ist Arbeit, obschon dabei noch keine Funktion auf dem Bildschirm erscheint.

Für Auftraggeber verändert das die Art, Angebote zu lesen. Ein niedriger Stundensatz sagt wenig über die Endsumme, solange unklar ist, wie viele Stunden er tragen muss. Aufschlussreicher sind andere Fragen: Welcher Ablauf soll sich verbessern? Was ist im Preis enthalten, Tests, Dokumentation, Code-Review, eine Prüfung der Sicherheit? Wer prüft, was eine KI geschrieben hat? Wie werden Änderungen behandelt, und was kostet der Betrieb nach dem Start? Ein Festpreis macht den vereinbarten Umfang kalkulierbar; ob dieser Umfang das eigentliche Problem löst, ist eine andere Frage, und ein scheinbar günstiges Angebot wird teuer, wenn notwendige Teile fehlen und später nachkommen. Wer Angebote so liest, vergleicht Ergebnisse statt Sätze.

Auch in der Softwareentwicklung wird der sichtbare Teil der Arbeit durch KI kürzer, und an diesem Gewinn sollen Auftraggeber teilhaben. Wenn mehr Software schneller entstehen kann, gewinnt allerdings die Entscheidung an Gewicht, welche Software entstehen soll, und die Prüfung dessen, was entstanden ist. Ein fairer Preis berücksichtigt beides: die gewonnene Geschwindigkeit und das Wissen, das aus einem schnellen Vorschlag eine verlässliche Lösung macht.

In der Geschichte versteht Ford erst nach der Reparatur, wofür er bezahlt hat.
Ein gutes Angebot erklärt es vorher.