KI und Vibe-Coding: was davon Produktion trägt

Wir setzen KI täglich ein. Das ist kein Bekenntnis, sondern der Grund, warum wir ziemlich genau sagen können, wo sie nicht trägt.

Fünf Behauptungen

„KI ersetzt Entwickler“

Was sie ersetzt, ist das Tippen. Was sie nicht ersetzt, ist die Verantwortung. Wer die Architektur entscheidet, den Code freigibt und nachts den Pager trägt, ist ein Mensch. Ein Modell haftet nicht.

„Juniors brauchen wir nicht mehr“

Seniors entstehen aus Juniors. Wer heute keine ausbildet, kauft dieselbe Erfahrung in fünf Jahren am Markt zurück, teurer und in einem dünneren Angebot. Das ist keine Sozialromantik, das ist Kapazitätsplanung.

„Vibe-Coding reicht für Produktion“

Für den Prototyp ist es großartig, und genau so nutzen wir es. Für den Code, der um drei Uhr nachts eure Zahlungen abwickelt, lautet die Frage nicht, ob er läuft, sondern ob im Fehlerfall jemand versteht, warum. Generierter Code, den niemand gelesen hat, ist unlesbarer Code mit einem Zwischenschritt.

„Wir machen alles mit KI“

Dann habt ihr eine Abhängigkeit von einem Anbieter, dessen Preise, Modellversionen und Verfügbarkeit ihr nicht kontrolliert. Modelle werden abgekündigt, Preise ändern sich, und dieselbe Anfrage liefert nach einem Versionswechsel eine andere Antwort. Das ist eine Architekturentscheidung und sollte auch als eine getroffen werden.

„KI spart sofort Kosten“

Sie verschiebt Kosten: Weg vom Schreiben, hin zum Prüfen. Ob das günstiger ist, hängt daran, wie oft ein Ergebnis beim ersten Anlauf trägt. Und genau das zählt fast niemand.

Wo wir sie tatsächlich einsetzen

Prototyping

Erste Version in Stunden statt Tagen. Das Modell schreibt den Boilerplate, die Architektur entscheiden wir. Wegwerfbar gebaut und danach auch weggeworfen.

Testgenerierung

Testsuiten aus bestehendem Code. Wir prüfen, ob sie die richtigen Fälle abdecken, nicht ob sie grün sind. Grüne Tests, die nichts prüfen, sind schlechter als keine.

Datenaufbereitung

Unstrukturiertes in nutzbare Formate. Die unsichtbare Arbeit, die früher Tage gedauert hat und heute in Minuten erledigt ist.

Wo wir sie nicht einsetzen: In Migrationen an Systemen, die Geld bewegen, ohne dass ein Mensch jede geänderte Zeile gelesen hat. Nicht aus Prinzip, sondern weil der Fehler dort erst beim Abgleich auffällt und dann nicht mehr billig ist.

Der teuerste Posten steht nicht auf der Rechnung

Die Tokenkosten eines Entwicklungsteams sind selten das Problem. Wehzutun beginnt die Nacharbeit: der Entwurf, der erst im dritten Anlauf trägt, das Review, das länger dauert als das Schreiben gedauert hätte, der Fehler, der in Produktion auffällt, weil niemand die generierte Zeile gelesen hat.

Diese Kosten stehen in keiner Abrechnung, weil sie in Personentagen anfallen und nicht in Tokens. Wer wissen will, ob KI im eigenen Haus rechnet, muss beide Seiten zählen: was ein Aufruf kostet, und wie oft ein Ergebnis beim ersten Mal trägt.

Unser Grundsatz

Für jedes Projekt entscheiden wir neu, wo sie hilft, wo sie ein Risiko ist und wo sie schlicht unnötig ist. Diese Entscheidung trifft kein Modell. Die treffen wir, und wir sagen sie auch dann, wenn die Antwort „nein“ lautet.