Das Geschäft mit 400 € pro Stunde: Aufräumen nach KI Katastrophen

KI gebaute Software aufräumen ist jetzt ein Geschäft

In der Softwarebranche gibt es eine neue Art von Arbeit: reparieren, was KI gebaut hat. Im September 2025 berichtete 404 Media, dass freie Entwickler und ganze Firmen "ein Geschäft daraus machen, schlampige, per Vibe Coding gebaute Software zu reparieren", und dass der "Spezialist fürs Aufräumen nach Vibe Coding", einst ein Witz auf LinkedIn, "tatsächlich ein wachsender Beruf" sei.¹ Jahrelang hieß es, KI werde Entwickler ersetzen. Bisher hat sie auch eine Menge Arbeit für die Entwickler geschaffen, die reparieren können, was sie hervorgebracht hat.

Um diese Arbeit geht es hier. Was das Durcheinander verursacht, wie es von innen aussieht, warum die Reparatur so viel kostet und wie du sie gar nicht erst brauchst.

Woher die 400 € pro Stunde kommen

Die Zahl im Titel ist der Satz, den ich in den Beispielen dieses Artikels für den Aufräumspezialisten ansetze. Es ist nicht mein Satz. Mein veröffentlichter Satz für Entwicklung liegt bei 195 € pro Stunde, und er steht für alle sichtbar auf der Preisseite. Ich habe 400 € für die Beispiele gewählt, weil das ein glaubwürdiger Aufschlag für erfahrene Notfallarbeit in einer Großstadt ist und weil die Rechnung damit leicht nachzuvollziehen ist.

Es ist auch nicht die schwindelerregende Zahl, nach der es klingt. Gern heißt es, wer Code repariert, verdiene inzwischen mehr als Anwaltskanzleien. Das stimmt nicht. Eine Tabelle mit Richtwerten für Stundensätze, wie sie britische Gerichte nutzen, gibt es in Deutschland nicht: Hier richtet sich die Vergütung von Anwältinnen und Anwälten nach dem Rechtsanwaltsvergütungsgesetz (RVG),² oder nach einer Vergütungsvereinbarung in Textform, in der oft ein Stundensatz steht.³ Den Vergleich liefern deshalb die britischen Zahlen. Die Richtwerte, die Gerichte in England und Wales seit dem 1. Januar 2026 für Anwaltskosten ansetzen, sehen für einen Solicitor mit mehr als acht Jahren Erfahrung im Zentrum Londons 579 Pfund pro Stunde vor, für einen mit mehr als vier Jahren 393 Pfund.⁴ 400 € liegen also in der Größenordnung einer Londoner Anwältin mit mittlerer Erfahrung. Der Titel will nicht sagen, dass Aufräumen bezahlt wird wie Recht. Er will sagen, dass die Rechnung fürs Aufräumen, bei jedem vernünftigen Satz für erfahrene Leute, weit höher ausfällt, als irgendjemand erwartet hat, der den schnellen Weg gewählt hat.

Rechenbeispiel: was eine Rettung zum Beispielsatz kostet

Ein erfundener Onlineshop braucht 200 Stunden Rettungsarbeit, eine Zahl, die ich im Abschnitt über die Phasen des Aufräumens herleite. Zum Beispielsatz:

1. Stunden: 200.
2. Satz: 400 € pro Stunde.
3. Kosten: $200 \times 400 = 80.000$, also 80.000 €.

Und das, bevor jemand die Umsätze zählt, die verloren gingen, während der Shop verrücktspielte. Merk dir diese 80.000 €, sie kommen zurück, wenn wir zwei Angebote vergleichen.

Vibe Coding funktioniert in der Demo

KI Werkzeuge fürs Programmieren wurden so gut, dass jemand ohne Programmierkenntnisse beschreiben konnte, was er wollte, und funktionierenden Code zurückbekam. So gut, dass manche Agenturen unerfahrene Leute einstellen, ihnen einen KI Assistenten geben und Projekte ausliefern konnten, die fertig aussahen.

Das entscheidende Wort ist "aussahen".

Andrej Karpathy hat den Namen Vibe Coding im Februar 2025 geprägt, für eine Art zu bauen, bei der du dich "ganz den Vibes hingibst" und "vergisst, dass der Code überhaupt existiert": jede Änderung annehmen, Fehlermeldungen zurück hineinkopieren, nie die Diffs lesen. Er hat klar gesagt, dass das zu "Wegwerfprojekten am Wochenende" passt.⁵ Keine Architektur, keine Teststrategie, kein Verständnis dafür, warum der Code funktioniert, nur dass er es gerade zu tun scheint, wenn du die Knöpfe in dieser Reihenfolge drückst.

Für eine Demo ist das fast Magie. Für ein Produktivsystem, das mit seltsamen Eingaben umgehen, Last aushalten, seine Daten stimmig halten und nicht umfallen soll, wenn eine Kundin etwas Unerwartetes tut, ist es eine langsam brennende Lunte.

Die Forschung sagt dasselbe aus mehreren Richtungen. In einer randomisierten kontrollierten Studie von METR aus dem Jahr 2025 brauchten 16 erfahrene Open Source Entwickler für 246 echte Aufgaben 19 % länger, wenn KI Werkzeuge erlaubt waren, und glaubten hinterher, die Werkzeuge hätten sie um 20 % schneller gemacht.⁶ Als ein Forschungsteam um Hammond Pearce GitHub Copilot 89 sicherheitsrelevante Szenarien vervollständigen ließ, waren rund 40 % der 1.689 erzeugten Programme verwundbar.⁷ Und Googles Forschungsprogramm DORA fand in seiner Umfrage von 2024, dass eine stärkere Nutzung von KI mit einem geschätzten Rückgang der Stabilität bei der Auslieferung um 7,2 % einherging.⁸ Diese letzte Zahl ist ein Zusammenhang aus einer Umfrage, kein Beweis für eine Ursache, aber sie zeigt in dieselbe Richtung: Tempo, das du spürst, ist nicht dasselbe wie Software, auf die du dich verlassen kannst.

Wo diese Systeme zuerst brechen, in der Datenbank, im Framework und in der Sprache, habe ich in die versteckten Kosten von KI gebauten Architekturen beschrieben. In diesem Artikel geht es um das Aufräumen danach.

Ohne Tests sagt dir niemand, was kaputtgegangen ist

Hier ist ein Gespräch, das ich im letzten Jahr, in Variationen, mindestens dreißigmal geführt habe.

"Wo sind die Tests?"

"Die was?"

"Die automatisierten Tests. Unit Tests, Integrationstests. Die Dinge, die prüfen, ob der Code noch tut, was er soll."

"Ich glaube, es gibt keine. Die Entwickler haben gesagt, sie hätten es getestet."

"Von Hand?"

"Vermutlich. Sie haben herumgeklickt, und es hat funktioniert."

"Und jetzt funktioniert es nicht mehr."

"Nein. Deshalb haben wir dich angerufen."

Das ist das Fundament fast jedes Durcheinanders aus Vibe Coding: Es gibt keine Tests. Keine schwachen Tests, keine veralteten Tests. Gar keine.

Für genau diesen Zweck gibt es zwei Praktiken, und keine davon ist neu. Testgetriebene Entwicklung (TDD, nach dem englischen test driven development), die Kent Beck Ende der 1990er entwickelt hat, steuert die Arbeit, indem zuerst ein fehlschlagender Test geschrieben wird und dann der Code, der ihn bestehen lässt. So weißt du, was der Code tun soll, und kannst beweisen, dass er es tut.⁹ Verhaltensgetriebene Entwicklung (BDD, nach dem englischen behaviour driven development), die Dan North 2006 vorgestellt hat, beschreibt das Verhalten in einfachen Sätzen der Form "gegeben ein Ausgangszustand, wenn ein Ereignis eintritt, dann stelle bestimmte Ergebnisse sicher", damit sich das Geschäft und die Entwickler einig sind, was "funktioniert" heißt, bevor jemand es baut.¹⁰ Diese Sätze laufen dann als Tests.

Viele Teams, die KI gebaute Projekte für Zehntausende Euro verkaufen, können keins von beiden erklären. Manche haben davon gehört und glauben, KI habe beides überflüssig gemacht. Das Gegenteil ist der Fall. Wenn eine Maschine Code schneller schreibt, als ihn jemand lesen kann, ist eine automatische Prüfung, ob das Verhalten noch stimmt, das Einzige, was zwischen dir und deiner Kundschaft steht. Wie das in der Praxis aussieht, beschreibe ich in TDD und BDD in Ruby on Rails und in Cucumber BDD.

Rechenbeispiel: ein Verhalten, aufgeschrieben vor dem Code

Papiermühle Neustadt ist ein erfundener Laden für Schreibwaren in Dresden, zu finden unter neustadtpapier.example. Die Inhaberin will versandkostenfreie Lieferung ab 40 € Bestellwert. Als BDD Szenario, bevor es irgendeinen Code gibt:

Feature: Grenze für versandkostenfreie Lieferung

  Scenario: Eine Bestellung genau an der Grenze wird kostenfrei geliefert
    Given ein Warenkorb im Wert von 40,00 €
    When die Kundin den Schritt Lieferung erreicht
    Then betragen die Versandkosten 0,00 €

  Scenario: Eine Bestellung knapp unter der Grenze zahlt Versand
    Given ein Warenkorb im Wert von 39,99 €
    When die Kundin den Schritt Lieferung erreicht
    Then betragen die Versandkosten 3,95 €

Schritt für Schritt:

1. Die Inhaberin liest die beiden Szenarien und bestätigt, dass sie stimmen. Das dauert zwei Minuten und klärt die Frage "sind genau 40 € schon kostenfrei?", bevor daraus ein Fehler wird.
2. Der Entwickler, oder die KI, schreibt den Code, bis beide Szenarien bestehen.
3. Sechs Monate später bittet jemand die KI, "den Checkout aufzuräumen". Sie ändert in der Prüfung der Grenze >= zu >. Das erste Szenario schlägt sofort fehl, auf dem Rechner des Entwicklers, nicht im Warenkorb einer Kundin.

Ohne die Szenarien geht dieselbe Änderung live, und der Laden erfährt davon, wenn sich eine Kundin mit einem Warenkorb über 40 € über 3,95 € Versand beschwert.

Eins reparieren, drei kaputt machen

Ohne Tests ist jede Änderung ein Glücksspiel.

Der Kunde meldet einen Fehler. Der Vibe Coder bittet die KI, ihn zu beheben. Die KI liefert eine Korrektur für das beschriebene Symptom. Die Korrektur geht live, und der ursprüngliche Fehler ist weg. Aber jetzt versagt etwas anderes, etwas, das vom gerade geänderten Verhalten abhing und das niemand geprüft hat, weil nichts geprüft wird. Der Kunde meldet den neuen Fehler. Die nächste Korrektur geht live. Jetzt sind zwei weitere Dinge kaputt.

Die Anbieter in meiner Lektion über 35.000 Pfund haben dasselbe Muster von außen gezeigt. Von innen liest sich die Git Historie wie ein Thriller, den niemand wollte:

fix login redirect
fix payment total after login fix
fix stock count after payment fix
fix login redirect (again)
revert part of payment fix
fix payment total

In einer getesteten Codebasis bricht diese Schleife von selbst ab. Du schreibst eine Korrektur, lässt die Tests laufen, und die Tests sagen dir, was du kaputt gemacht hast, bevor etwas live geht. In einer ungetesteten ist deine Kundschaft die einzige Testsuite.

Das Diagramm läuft von oben nach unten. Beide Zweige beginnen mit derselben Korrektur. Der einzige Unterschied ist, ob etwas sie prüft, bevor die Kundschaft es tut. Der Zweig "nein" hat kein eigenes Ende: Er führt direkt zurück nach oben.

Wie schnell sich ungetestete Änderungen summieren

Das Glücksspiel lässt sich beziffern. Angenommen, jede Änderung hat eine kleine Wahrscheinlichkeit, etwas anderes kaputt zu machen. Die Wahrscheinlichkeit, dass eine Reihe von Änderungen mindestens eine Sache kaputt macht, ist

$$P_{\text{break}} = 1 - (1 - p)^{k}$$

wobei $P_{\text{break}}$ die Wahrscheinlichkeit ist, dass mindestens eine der Änderungen etwas kaputt macht, $p$ die Wahrscheinlichkeit, dass eine einzelne Änderung etwas kaputt macht, und $k$ die Zahl der Änderungen. Die Formel multipliziert die Wahrscheinlichkeiten, dass jede Änderung harmlos ist, $(1 - p)$, und zieht das Ergebnis von eins ab. Sie nimmt an, dass die Änderungen unabhängig sind, und das ist großzügig gegenüber der ungetesteten Codebasis. Die Regeln dahinter stehen in Grundlagen: Wahrscheinlichkeit.

Rechenbeispiel: zwanzig kleine Änderungen

Nimm für das Beispiel an, dass jede Änderung an einer ungetesteten Codebasis mit einer Chance von eins zu zehn woanders etwas kaputt macht, also $p = 0{,}1$.

1. Nach fünf Änderungen: $1 - 0{,}9^{5} = 1 - 0{,}590 = 0{,}410$, eine Chance von 41 %, dass schon etwas kaputt ist.
2. Nach 20 Änderungen: $1 - 0{,}9^{20} = 1 - 0{,}122 = 0{,}878$, eine Chance von 88 %.
3. Mit Tests, die etwa neun von zehn dieser Nebenwirkungen vor dem Release finden, sinkt die Wahrscheinlichkeit, dass eine Änderung einen Fehler ausliefert, auf $p = 0{,}01$, und nach 20 Änderungen auf $1 - 0{,}99^{20} = 1 - 0{,}818 = 0{,}182$, also 18 %.

Zwanzig Änderungen sind ein paar Wochen ganz normaler Arbeit. Ohne Tests ist ein Fehler kein Risiko, sondern das erwartete Ergebnis.

Ohne Dokumentation wird jede Korrektur zur Archäologie

KI dokumentiert nicht, solange niemand danach fragt, und in einem Projekt aus Vibe Coding hat niemand gefragt.

Das klingt nach einer Kleinigkeit, bis du versuchst, eine Codebasis zu verstehen, die eine KI erzeugt hat, die jemand geändert hat, der sie nicht verstand, die eine andere KI neu erzeugt hat und die wieder jemand anderes geändert hat. Warum hat diese Funktion diese Form? Niemand weiß es. Warum laufen diese Daten durch drei Dienste statt durch einen? Niemand weiß es. Warum wartet dieser Vorgang genau 3,7 Sekunden, bevor er abschließt? Niemand weiß es, aber nimm die Wartezeit heraus, und etwas anderes bricht.

Ein gut gebautes System beantwortet solche Fragen schriftlich: Kommentare zu den Entscheidungen, die nicht offensichtlich sind, ein README, das die Architektur erklärt, Commit Nachrichten, die das Warum nennen, und kurze Protokolle der großen Entscheidungen. Ein System aus Vibe Coding hat nichts davon. Der Code existiert ohne Zusammenhang, und der einzige Weg, die Absicht wiederzufinden, ist, jede Zeile zu lesen und sie aus dem zu rekonstruieren, was der Code tut.

Ich verbringe in jedem Rettungsprojekt mindestens 30 % der Zeit allein damit, zu verstehen, was los ist. Das fügt nichts Neues hinzu. Es ist Archäologie. Aber nichts anderes kann beginnen, bevor sie erledigt ist.

Rechenbeispiel: ein Entscheidungsprotokoll, das eine Woche spart

Kaffeespeicher Lindenthal ist ein erfundener Kaffeegroßhandel in Köln, zu finden unter lindenthalkaffee.example. Sein Abgleich der Bestellungen wartet 3,7 Sekunden, bevor er ins Lagersystem schreibt. Zwei Zeilen in einem Entscheidungsprotokoll hätten es erklärt:

Entscheidung 7: 3,7 Sekunden warten, bevor eine Bestellung ans Lager geht.
Warum: Der Zahlungsanbieter bestätigt per Webhook bis zu drei Sekunden nach
dem Checkout. Früheres Senden erzeugte Lageraufträge für gescheiterte Zahlungen.
Ersetzen durch: beim Zahlungswebhook senden statt nach einem Timer.

Schritt für Schritt, was das Protokoll ändert:

1. Ohne es sieht ein neuer Entwickler eine seltsame Verzögerung, entfernt sie, um die Sache zu beschleunigen, und das Lager beginnt, Bestellungen zu packen, die nie bezahlt wurden.
2. Mit ihm liest derselbe Entwickler drei Zeilen, versteht, dass die Verzögerung ein Notbehelf ist, und sieht die richtige Lösung gleich daneben.
3. Die richtige Lösung, beim Zahlungswebhook zu senden, dauert einen Nachmittag. Herauszufinden, warum die Verzögerung existierte, anhand eines unbezahlten Pakets und eines verwirrten Lagers, dauert Tage.

Der kritische Pfad nutzt sich Änderung für Änderung ab

Der kritische Pfad ist die Abfolge der Dinge, die funktionieren müssen, damit das Produkt überhaupt funktioniert: ein Produkt finden, es in den Warenkorb legen, bezahlen, eine Bestätigung bekommen, das Paket erhalten. Als Planungsidee habe ich ihn in Time to Market beschrieben. In einem Projekt aus Vibe Coding erodiert er leise.

Der erste Wurf funktioniert, oft teilweise durch Glück. Dann werden Änderungen gewünscht, und jede wird gemacht, indem die KI für das unmittelbare Ziel befragt wird. Jede Änderung ergibt für sich Sinn. Jede schiebt etwas auf dem kritischen Pfad ein Stück zur Seite: ein Fehler, der nicht mehr behandelt wird, eine Prüfung, die nicht mehr läuft, ein Status, der an einer Stelle gesetzt wird und an einer anderen nicht. Niemand merkt es, weil die Demo noch funktioniert, wenn man in der richtigen Reihenfolge klickt. Nach fünfzig solcher Änderungen funktioniert das System nur noch auf dem Idealweg, genau der Route, die die Demos immer nehmen.

Dann geht es live, und die Kundschaft folgt nicht dem Idealweg. Sie vertippt sich, verliert mittendrin den Empfang, drückt den Knopf zweimal, fügt ein Emoji ins Feld für die Postleitzahl ein. Gegen nichts davon wurde das System je getestet.

Rechenbeispiel: der zweimal gedrückte Knopf

Radstation Schwabing ist ein erfundener Fahrradladen in München, zu finden unter schwabingrad.example. Bei einer langsamen Mobilverbindung drückt ein Kunde zweimal auf "Bezahlen". Der Checkout aus Vibe Coding legt zwei Bestellungen an und bucht zweimal 649 € ab. Ein Test, der das Verhalten festhält, fängt das ab:

it "creates one order when the same checkout is submitted twice" do
  2.times { post "/checkout", params: { basket_id: basket.id, token: "chk_123" } }
  expect(Order.where(basket_id: basket.id).count).to eq(1)
end

Schritt für Schritt:

1. Der Test schickt denselben Checkout zweimal ab, mit demselben Einmaltoken, so wie es der doppelte Druck tut.
2. Er erwartet eine Bestellung. Beim Checkout aus Vibe Coding findet er zwei, also schlägt er fehl.
3. Die Korrektur speichert das Token mit der ersten Bestellung und gibt bei der zweiten Anfrage diese Bestellung zurück, statt eine neue anzulegen.
4. Der Test besteht, und er läuft bei jeder künftigen Änderung weiter, sodass ein späteres "Aufräumen" die doppelte Abbuchung nicht still zurückbringen kann.

Eine Erstattung über 649 € und eine verärgerte Bewertung kosten mehr als die zehn Minuten, die dieser Test zum Schreiben braucht.

Die Rechnung der falschen Sparsamkeit

Hier ist, warum das Angebot mit der kleineren Zahl oft das teurere Projekt ist. Die Zahlen unten sind ein erfundenes Beispiel, jede Annahme ist genannt.

Ein Unternehmen braucht eine Funktion für seinen eCommerce und holt zwei Angebote ein.

Option A: ein erfahrener Engineer oder ein kleines Team aus erfahrenen Leuten. 80.000 € und drei Monate, gebaut mit Tests, Dokumentation und einer durchdachten Architektur. Klingt teuer.

Option B: eine Agentur mit Kampfpreisen, die sich als "KI nativ" verkauft. 25.000 € und sechs Wochen, mit beeindruckenden Demos und dem Versprechen schneller Iterationen. Klingt nach einem Schnäppchen, ein Drittel des Preises in der halben Zeit.

Das Unternehmen nimmt Option B. Die Demo ist wunderbar. Zwei Wochen nach dem Start beginnen die Probleme: kleine Fehler, dann größere, dann Daten, die nicht mehr aufgehen, dann ein Sicherheitsvorfall. Die Agentur antwortet nicht mehr, denn die Reparatur würde mehr Stunden kosten, als sie fürs ganze Projekt angeboten hat.

Die Gesamtkosten einer Option sind

$$C = B + h \times r + L$$

wobei $C$ die Gesamtkosten sind, $B$ der Preis für den Bau, $h$ die Zahl der Rettungsstunden, $r$ der Stundensatz für die Rettung und $L$ der Umsatz, der verloren geht, während das System verrücktspielt. Für Option A werden $h$ und $L$ mit null angesetzt, was sie leicht schönt, denn jedes System braucht irgendwann Korrekturen. Es ist schlichtes Addieren und Multiplizieren. Ist die Rettung unsicher, wird daraus ein Erwartungswert der Kosten, den Grundlagen: Erwartungswert erklärt und das zweite Beispiel unten nutzt.

Rechenbeispiel: zwei Angebote für dieselbe Funktion

Option B, mit den Annahmen des Beispiels:

1. Bau: $B = 25.000$.
2. Rettung: $h = 200$ Stunden zu $r = 400$, also $h \times r = 80.000$.
3. Verlorener Umsatz: Angenommen, der Shop setzt 10.000 € pro Woche um, und sechs Wochen Instabilität kosten ihn ein Viertel davon, also $L = 6 \times 10.000 \times 0{,}25 = 15.000$.
4. Gesamt: $C_B = 25.000 + 80.000 + 15.000 = 120.000$, also 120.000 €, und rund sechs Monate vom ersten Angebot bis zum funktionierenden System.

Option A: $C_A = 80.000$, in drei Monaten.

Jeder Balken ist eine Art, dieselbe Entscheidung zu zählen, und die senkrechte Achse ist die Summe in Euro. Der zweite Balken ist der einzige, den sich irgendjemand angesehen hat, als die Entscheidung fiel. Der vierte ist das, was das Unternehmen tatsächlich bezahlt hat. Die Kunden, die nicht wiederkamen, stehen in gar keinem Balken.

Rechenbeispiel: wenn die Rettung nicht sicher ist

Nicht jeder schnelle, ungetestete Bau braucht eine volle Rettung. Die fairere Frage ist also, wie wahrscheinlich die Rettung sein muss, bevor Option B im Schnitt mehr kostet. Mit einer angenommenen Wahrscheinlichkeit $q$, dass die Rettung nötig wird, sind die erwarteten Kosten von Option B $E[C_B] = 25.000 + q \times 95.000$, wobei 95.000 die Rettung plus der verlorene Umsatz sind. Das ist ein Erwartungswert, erklärt in Grundlagen: Erwartungswert.

1. Die erwarteten Kosten gleich Option A setzen: $25.000 + q \times 95.000 = 80.000$.
2. Auflösen: $q = 55.000 / 95.000 = 0{,}58$.
3. Lesen: Wenn mehr als etwa sechs von zehn solcher Projekte die Rettung brauchen, kostet Option B im Schnitt mehr.

Auch der Durchschnitt ist nicht die ganze Geschichte. Der Erwartungswert sagt nichts über das eine Mal, bei dem du dir den schlechten Ausgang nicht leisten kannst, und eine Rechnung über 120.000 € für ein Projekt über 25.000 € ist für viele kleine Unternehmen genau dieser Ausgang. Die Rechnung für ein fehlendes Fundament kommt immer. Offen ist nur, wie viel Zinsen sie bis dahin angesammelt hat.

Was das Aufräumen tatsächlich umfasst

Wenn ein Unternehmen mir ein System aus Vibe Coding zur Rettung bringt, läuft die Arbeit in sechs Phasen. Die Stunden sind meine Schätzungen für ein typisches System von der Größe im Beispiel, und die Spannen hängen davon ab, wie groß und wie beschädigt es ist.

1. Archäologie, 20 bis 40 Stunden. Den ganzen Code lesen. Verfolgen, wie die Daten fließen, die Abhängigkeiten kartieren, herausfinden, was das System tun soll, indem ich beobachte, was es tatsächlich tut, und alle befragen, die die Anforderungen kennen. Im Grunde die Spezifikation schreiben, die es nie gab.
2. Testinfrastruktur, 10 bis 20 Stunden. Die Testwerkzeuge einrichten, die von Anfang an hätten da sein sollen, und eine Pipeline, die bei jeder Änderung die Tests laufen lässt, bevor irgendetwas ausgeliefert wird (Continuous Integration und Delivery, CI/CD).
3. Tests für den kritischen Pfad, 40 bis 60 Stunden. Tests für die Dinge schreiben, die unbedingt funktionieren müssen. Das ist langsam, denn verknoteter Code muss oft umgebaut werden, bevor er sich testen lässt, und Umbauen ohne Tests ist riskant. Die ersten Tests beschreiben deshalb, was das System heute tut, richtig oder falsch, und dienen als Sicherheitsnetz für alles Weitere.
4. Stabilisierung, 40 bis 80 Stunden. Mit Tests im Rücken Dinge reparieren, ohne Angst, andere kaputt zu machen: zuerst der kritische Pfad, dann die Daten, die nicht mehr aufgehen, dann die Sicherheitslücken. Jede Korrektur wird durch einen Test belegt, also ist der Fortschritt messbar.
5. Randfälle, 20 bis 40 Stunden. Der Idealweg funktioniert. Jetzt die Wege, die echte Kunden nehmen: Fehler, Eingabeprüfungen, zwei Leute, die dasselbe bearbeiten, abgerissene Verbindungen, seltsame Eingaben.
6. Dokumentation, 10 bis 20 Stunden. Aufschreiben, was gelernt wurde: die Architektur, die Schnittstellen, wie ausgeliefert wird und warum die großen Entscheidungen so gefallen sind.

Das sind insgesamt 140 bis 260 Stunden. Die 200 Stunden im Beispiel liegen nahe der Mitte.

Die waagrechte Achse zeigt die sechs Phasen der Reihe nach, die senkrechte die Mitte jeder Schätzung in Stunden. Die Mitten ergeben zusammen $30 + 15 + 50 + 60 + 30 + 15 = 200$. Was du daraus mitnehmen solltest: Fast die Hälfte der Stunden, die ersten drei Phasen, fließt in das Verstehen des Systems und den Bau des Sicherheitsnetzes, bevor ein einziger Fehler behoben ist. Das ist der Preis dafür, beides nicht von Anfang an eingebaut zu haben.

Rechenbeispiel: die Rettung Phase für Phase bepreisen

Für den erfundenen Shop aus dem Beispiel zur falschen Sparsamkeit, zum Beispielsatz von 400 € pro Stunde:

1. Archäologie: $30 \times 400 = 12.000$.
2. Testinfrastruktur: $15 \times 400 = 6.000$.
3. Tests für den kritischen Pfad: $50 \times 400 = 20.000$.
4. Stabilisierung: $60 \times 400 = 24.000$.
5. Randfälle: $30 \times 400 = 12.000$.
6. Dokumentation: $15 \times 400 = 6.000$.

Gesamt: 80.000 €, dieselbe Zahl wie vorhin, jetzt mit einem Grund hinter jedem Euro. Davon werden 38.000 € ausgegeben, bevor der erste Fehler behoben ist.

Ich nutze KI auch, aber ich lese, was sie schreibt

Damit es klar ist: Ich bin nicht gegen KI. Ich nutze KI Werkzeuge jeden Tag. Sie machen mich schneller, und sie sind wirklich nützlich.

Aber ich nutze sie als Werkzeuge, nicht als Ersatz für Verständnis. Wenn eine KI Code für mich schreibt, lese ich ihn. Ich prüfe, ob der Ansatz stimmt, ändere ihn, wenn nicht, teste ihn und dokumentiere ihn. Die KI beschleunigt meine Arbeit. Sie erledigt sie nicht.

Vibe Coding überspringt jeden dieser Schritte: Prompt, annehmen, ausliefern. Für die Person, die ihn ausliefert, ist der Code eine Blackbox. Sie kann nicht sagen, ob er sicher ist oder voller Löcher, effizient oder verschwenderisch, denn ihr fehlt das Wissen, um das zu beurteilen. Das sind keine Entwickler, die KI nutzen. Das sind Bediener eines Werkzeugs, dessen Ausgabe sie nicht lesen können.

Darin liegt der ganze Unterschied. In erfahrenen Händen vervielfacht KI gute Arbeit. Ohne Verständnis dahinter vervielfacht sie Fehler, schneller, als irgendjemand sie finden kann. Das Werkzeug ist dasselbe. Die Ergebnisse sind gegensätzlich. Warum dieses Verständnis zählt, habe ich ausführlicher in wenn ein Experte ein ganzes Team schlägt beschrieben.

Wie du gar nicht erst aufräumen lassen musst

Wenn du gerade Software in Auftrag geben willst, so vermeidest du, später einen Spezialisten für die Rettung zu bezahlen.

Beauftrag Leute, die Software verstehen, nicht nur Prompts. Frag, ob sie Produktivsysteme gebaut und betrieben haben und ob sie ihre Entscheidungen zur Architektur erklären können. Die KI Werkzeuge sind für alle dieselben. Das Urteilsvermögen ist das, wofür du bezahlst.

Verlang Tests ab der ersten Woche. Lass dir die Testsuite zeigen, wie viel des Systems sie abdeckt und was passiert, wenn ein Test fehlschlägt. Verwirrt sie die Frage, hast du deine Antwort.

Verlang Dokumentation als Teil der Lieferung. Entscheidungen, die nicht offensichtlich sind, werden aufgeschrieben. Schnittstellen werden beschrieben. Für die Auslieferung gibt es eine Anleitung. Ein Team, das sagt, Dokumentation bremse es, baut etwas, das sonst niemand pflegen kann.

Stell sicher, dass ein Mensch jede Änderung prüft. Jemand, der den Code versteht, liest jede Änderung, bevor sie live geht, und kann auf "warum ist das so gebaut?" mit einem echten Grund antworten.

Vergleich die Summe, nicht das Angebot. Erfahrene Leute kosten pro Stunde mehr. Über die Lebensdauer eines Projekts kosten sie meistens weniger, aus den Gründen im Beispiel zur falschen Sparsamkeit. Die wahren Kosten des Outsourcings von Entwicklung gehen genauer darauf ein, was ein Angebot weglässt.

Rechenbeispiel: fünf Fragen an zwei Angebote

Wohnkontor Eimsbüttel, ein erfundener Laden für Wohnaccessoires in Hamburg, zu finden unter eimsbuettelwohnen.example, hat zwei Angebote für einen neuen Checkout und stellt beiden Anbietern dieselben fünf Fragen:

1. "Kann ich die Tests eines Projekts sehen, das ihr letztes Jahr gebaut habt?" Anbieter eins teilt eine Testsuite. Anbieter zwei sagt, sie "testen gründlich von Hand".
2. "Was passiert, wenn ein Test fehlschlägt?" Anbieter eins: "Nichts geht live, bis er besteht." Anbieter zwei ist nicht sicher, was gemeint ist.
3. "Wer prüft den Code, bevor er live geht?" Anbieter eins nennt eine Person. Anbieter zwei sagt, das übernehme die KI.
4. "Welche Dokumentation bekomme ich bei der Übergabe?" Anbieter eins zählt Architekturnotizen, eine Anleitung zur Auslieferung und Entscheidungsprotokolle auf. Anbieter zwei bietet einen Call zur Einführung an.
5. "Wenn ihr morgen verschwindet, könnte ein anderer Entwickler übernehmen?" Anbieter eins sagt ja und erklärt, warum. Anbieter zwei sagt, so weit werde es nicht kommen.

Die Angebote liegen 20.000 € zugunsten von Anbieter zwei auseinander. Die Antworten deuten an, welches am Ende mehr kosten wird.

Dieser Goldrausch wird nicht anhalten

Gerade gibt es echte Nachfrage nach Leuten, die Systeme aus Vibe Coding entwirren können, und die Arbeit ist, seltsamerweise, befriedigend, weil vorher und nachher so weit auseinanderliegen.

Sie wird nicht ewig anhalten, und das soll sie auch nicht. Die Geschichten werden sich häufen. Die Rechnung der falschen Sparsamkeit wird Allgemeinwissen. Gute Praxis setzt sich wieder durch, und die Agenturen, die Tempo ohne Verständnis verkauft haben, lernen entweder echtes Engineering oder schließen.

Bis dahin ein paar Worte an jede Leserin und jeden Leser.

Wenn du ein erfahrener Entwickler bist: Die Grundlagen, die du gelernt hast, Testen, Architektur, Dinge aufschreiben, sind jetzt mehr wert, nicht weniger, denn genau das kann ein Prompt nicht hervorbringen.

Wenn du ein Unternehmen führst: Bau richtig, teste richtig, dokumentier richtig. Am Ende kostet es weniger, und du musst deinen Gesellschaftern nie erklären, warum das Projekt, das wie ein Schnäppchen aussah, ein Vielfaches seines Budgets gekostet hat.

Und wenn du in die Entwicklung gekommen bist, weil KI dich Code ausliefern ließ, ohne ihn zu verstehen: Lern das Handwerk darunter. Lern, was Tests sind und warum Architektur zählt. Dieses Wissen brauchst du, um zu beurteilen, was die KI dir gibt, und niemand kann es dir hineinprompten.

Die Rechnung kommt immer. Du kannst sie vorab an jemanden zahlen, der richtig baut, oder später, mit Zinsen, an jemanden, der aufräumt.

Footnotes

1. Emanuel Maiberg, The Software Engineers Paid to Fix Vibe Coded Messes, 404 Media, 11. September 2025, https://www.404media.co/the-software-engineers-paid-to-fix-vibe-coded-messes/

2. Bundesministerium der Justiz, Rechtsanwaltsvergütungsgesetz (RVG), § 1 Geltungsbereich, gesetze im internet, https://www.gesetze-im-internet.de/rvg/__1.html

3. Bundesministerium der Justiz, Rechtsanwaltsvergütungsgesetz (RVG), § 3a Vergütungsvereinbarung, gesetze im internet, https://www.gesetze-im-internet.de/rvg/__3a.html

4. HM Courts and Tribunals Service, Solicitors' guideline hourly rates, guideline hourly rates in force from 1 January 2026, GOV.UK, aktualisiert am 1. Januar 2026, https://www.gov.uk/guidance/solicitors-guideline-hourly-rates

5. Andrej Karpathy, Beitrag auf X, der "vibe coding" einführt, 2. Februar 2025, https://x.com/karpathy/status/1886192184808149383

6. Joel Becker, Nate Rush, Elizabeth Barnes und David Rein, Measuring the Impact of Early 2025 AI on Experienced Open Source Developer Productivity, METR, arXiv:2507.09089, 2025, https://arxiv.org/abs/2507.09089

7. Hammond Pearce und andere, Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions, IEEE Symposium on Security and Privacy 2022, arXiv:2108.09293, https://arxiv.org/abs/2108.09293

8. Nathen Harvey und Derek DeBellis, Highlights from the 10th DORA report, Google Cloud Blog, 23. Oktober 2024, https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report

9. Martin Fowler, Test Driven Development, martinfowler.com, aktualisiert am 11. Dezember 2023, https://martinfowler.com/bliki/TestDrivenDevelopment.html

10. Dan North, Introducing BDD, zuerst erschienen im Magazin Better Software, März 2006, https://dannorth.net/blog/introducing-bdd/