Die Maschine ist der billigste Posten: Was KI-Einführung wirklich verlangt

Zwei Monatsabrechnungen liegen nebeneinander, dieselbe Organisation, dieselben Modelle. Die eine, für den Juni, bleibt unter zehn Dollar. Die andere, für den Juli, liegt im mittleren dreistelligen Bereich.

Dazwischen ist kein Preis gestiegen. Dazwischen sind Funktionen dazugekommen.

Was die Maschine kostet, und warum es trotzdem mehr wird

Auf der Ebene des einzelnen Arbeitsschritts sind die Beträge lächerlich klein. Ein vollständiger Fachartikel, geschrieben und mit Quellen versehen, kostet in meinem Redaktionssystem etwa so viel wie ein Brötchen. Die Überarbeitung dasselbe, die Analyse für Suchmaschinen und KI-Antwortdienste weniger, die Ableitung eines LinkedIn-Beitrags noch weniger.

Größer wird die Rechnung nicht dadurch, dass diese Schritte teurer werden, sondern dadurch, dass es mehr davon gibt. Eine Funktion, die Studien sucht und Quellen prüft, liest ganze Dokumente ein und kostet damit ein Vielfaches eines Schreibvorgangs; kommt eine zweite Anwendung dazu, verdoppelt sich die Grundlast; kommt ein Agent dazu, der selbstständig arbeitet, steigt sie noch einmal.

Das Schreiben ist billig. Das Nachschlagen ist teuer. Umgekehrt hätte ich es geschätzt, und ich vermute, den meisten geht es genauso.

Diese Richtung wird sich nicht umkehren. Wer heute mit einem zweistelligen Monatsbetrag anfängt, sollte damit rechnen, in einem Jahr über einen anderen zu reden. Nur bleibt das selbst dann der kleinste Posten der Rechnung.

Der Posten, über den nicht gesprochen wird

Denn die Rechnung, die tatsächlich per Mail kommt, ist die harmlose. Die drei Posten, die zählen, stellt niemand in Rechnung, weil sie im eigenen Haus anfallen.

Die Einrichtung: den Ablauf beschreiben, Regeln festlegen, Quellen anbinden, prüfen, ob das Ergebnis taugt. Ein guter Teil davon geht für Dinge drauf, die hinterher wieder verschwinden.

Die Prüfung: sie fällt dauerhaft an, nicht einmalig. Ein Text, den niemand gegenliest, spart Prüfzeit genau so lange, bis der erste Fehler nach außen geht.

Der Betrieb: am 27. Juli hat ein einziger fehlerhafter Suchausdruck in meinem eigenen Code diese Website eine Weile blockiert. Reparatur an einem Vormittag, Absicherung danach deutlich länger. Solche Tage stehen in keiner Kalkulation und kommen trotzdem.

Vibe Coding heißt nicht, dass man nichts wissen muss

Für die Art, wie diese Anwendungen entstanden sind, gibt es seit Anfang 2025 einen Namen. Andrej Karpathy, früher bei Tesla und OpenAI, prägte ihn in einem Beitrag, den IBM in seiner Begriffserklärung zitiert: sich ganz den Eingebungen hingeben und vergessen, dass der Code überhaupt existiert. Man beschreibt, was man will, die Maschine schreibt es, Fehlermeldungen wandern zurück in den Chat.

Für ein Wochenendprojekt ist das großartig. Für eine Anwendung, die Kundendaten verarbeitet und jeden Tag laufen muss, ist es der sichere Weg in einen Klumpen, den am Ende niemand mehr anfassen will, auch die Maschine nicht.

Der Unterschied zwischen beidem liegt nicht im Werkzeug. Er liegt darin, wie viel man versteht und wie viel man aufschreibt.

Was man verstehen muss, ohne programmieren zu können

Ich bin kein Entwickler und behaupte das auch nicht. Was man aber braucht, ist ein Bild davon, wie so ein System gebaut ist: dass Daten in einer Datenbank liegen und nicht in der Anwendung; dass eine Adresse im Browser irgendwo im Code eine Stelle hat, die antwortet; dass ein Neustart etwas anderes ist als eine neue Version; dass ein Test nicht prüft, ob etwas schön aussieht, sondern ob eine bestimmte Sache noch funktioniert.

Wer diese Unterscheidungen nicht trifft, kann den Vorschlag einer Maschine nicht beurteilen, sondern nur annehmen. Und dann entscheidet nicht mehr der Mensch, was gebaut wird, sondern das Modell, das gerade den plausibelsten Satz gebildet hat.

Man muss nicht programmieren können. Man muss beurteilen können, was da gerade gebaut wird, und Nein sagen können, wenn es der falsche Weg ist.

Ohne Dokumentation der einzelnen Schritte verliert man den Überblick

Der zweite Teil ist unspektakulärer und entscheidet trotzdem über alles. Jeder Arbeitsabschnitt endet bei mir mit einem Übergabedokument: was geändert wurde, warum, was offen blieb, was bewusst nicht gemacht wurde. Dazu ein Verzeichnis der Fehler, die aufgetreten sind, und der Lehren daraus.

Das klingt nach Bürokratie und ist das Gegenteil. Nach drei Wochen weiß niemand mehr, warum eine Einstellung so gesetzt ist, wie sie gesetzt ist, und das gilt für die Maschine noch mehr als für den Menschen: Sie beginnt jede Sitzung ohne Erinnerung an die letzte. Was nicht aufgeschrieben ist, existiert für sie nicht.

Genau deshalb ließ sich der blockierte Vormittag im Juli überhaupt aufklären. Nicht weil jemand sich erinnerte, sondern weil nachlesbar war, was zuletzt geändert worden war.

Damit später ein Mensch übernehmen kann

Der eigentliche Zweck dieser Schreibarbeit zeigt sich erst später. Eine Anwendung, die nur im Dialog mit einem Sprachmodell verständlich ist, gehört niemandem. Sie lässt sich nicht übergeben, nicht prüfen, nicht bewerten, und beim Verkauf des Unternehmens steht sie mit null in den Büchern.

Eine dokumentierte Anwendung dagegen kann ein Entwickler übernehmen, den man nie getroffen hat. Er liest die Architekturnotiz, den Änderungsverlauf, die Übergaben, und weiß nach einem Vormittag, woran er ist.

Für mich ist das die Bedingung, unter der ich so arbeite. Wer sich auf diese Weise Werkzeuge bauen lässt, sollte im Vertrag stehen haben, dass die Dokumentation Teil der Lieferung ist.

Eine Anwendung, die nur ihr Erbauer und ein Sprachmodell verstehen, ist keine Lösung. Sie ist eine Abhängigkeit mit freundlicher Oberfläche.

Kuratieren heißt vor allem aussortieren

Die zweite Hälfte dieser Arbeit betrifft nicht den Code, sondern den Inhalt, und sie lässt sich an dieser Artikelserie zeigen, denn sie ist mit demselben System entstanden.

Vierzehn externe Quellen stehen am Ende in den Texten. Geprüft wurden mehr. Eine Studie flog raus, weil sie nicht mehr frei zugänglich ist. Eine Quelle aus der ursprünglichen Planung war einem prominenten Namen zugeschrieben, stammt aber nachweislich von zwei anderen Personen; wer das nicht nachschlägt, veröffentlicht eine Fehlzuschreibung. Ein Bericht, der ein ganzes Kapitel tragen sollte, war schlicht nicht erreichbar.

Am aufschlussreichsten war die Suche nach einer belastbaren Untersuchung zu den Gesamtkosten von KI-Projekten. Zu finden waren Beiträge, die einander zitieren, mit Prozentzahlen ohne Fundstelle, zugeschrieben an große Beratungshäuser, die man vorsichtshalber nicht verlinkt. Deshalb steht in diesem Text keine solche Zahl.

Eine Maschine liefert in Sekunden zehn Quellen. Ob eine davon trägt, entscheidet weiterhin jemand, der die Fundstelle aufschlägt.

Die Zeit, die in keiner Abrechnung steht

Und dann ist da noch der Teil, den man am wenigsten greifen kann und ohne den nichts von alldem existieren würde.

Kein Sprachmodell kommt von selbst auf die Idee, fünfzehnhundert handgeschriebene Familienbriefe aus der ersten Hälfte des vorigen Jahrhunderts erschließbar zu machen. Keines schlägt vor, dass ein Wochenbericht nicht schneller, sondern überflüssig sein könnte. Die Maschine baut, was man ihr beschreibt; worauf man sie ansetzt, entsteht vorher, beim Spazierengehen, im Halbschlaf oder in einem Gespräch, das mit der Sache scheinbar nichts zu tun hat.

Diese Zeit lässt sich nicht protokollieren und nicht in Rechnung stellen. Sie ist trotzdem der wertvollste Teil der ganzen Rechnung.

Wer eine KI-Einführung plant, sollte sie einplanen, statt sie für Leerlauf zu halten.

Was sich messen lässt, ohne sich zu belügen

Für die Rechnung selbst genügen am Ende vier Werte, die nach der Diagnose aus dem ersten Serienteil ohnehin vorliegen: die Durchlaufzeit eines Vorgangs von Anfang bis Ende; die Wartezeit darin; die Zahl der Schleifen, bis etwas freigegeben ist; und der Anteil der Ergebnisse, die unverändert durchgehen. Was absichtlich fehlt, ist die Zahl der erzeugten Texte. Menge steigt immer, sobald das Schreiben schneller wird, und sagt nichts darüber, ob etwas besser geworden ist.

Dass Effizienz allein an eine Grenze stößt, zeigt eine Gartner-Erhebung unter zweihundertvier Finanzverantwortlichen vom März 2026, über die der CPA Practice Advisor berichtete: Sobald eine Aufgabe schneller läuft, ist der Gewinn ausgereizt, solange sich an der Entscheidung dahinter nichts ändert. Der Stanford AI Index 2026 nennt dazu Produktivitätsgewinne aus kontrollierten Studien, von rund 26 Prozent in der Softwareentwicklung bis zur Hälfte bei einzelnen Marketingaufgaben; übertragen lassen sich solche Werte auf eine ganze Abteilung nicht. Und die MIT-Untersuchung, über die Fortune berichtete, findet bei rund 95 Prozent der Pilotprojekte keinen messbaren Ertrag in der Gewinn- und Verlustrechnung.

Die Messung, die vorher stattfinden muss

Der Grund dafür ist unspektakulär. Niemand hat vorher gemessen.

Ohne Ausgangswert lässt sich nachher nichts vergleichen. Alle finden, es laufe besser, niemand kann es belegen, und beim nächsten Budgetgespräch steht die Investition ohne Argument da. Vier Wochen Rückschau vor dem Start kosten fast nichts; danach sind sie nicht mehr zu haben. Wer die Reihenfolge aus dem Serienrahmen eingehalten hat, hat diese Werte für die Diagnose ohnehin erhoben und muss sie nur aufheben; die Vorgänge, mit denen man anfängt, benennt der vierte Teil.

Bleibt die Frage vom Anfang, warum aus wenigen Dollar im Juni ein Vielfaches im Juli wurde. Weil in diesem Monat drei Anwendungen liefen statt einer, weil eine davon recherchiert statt nur schreibt, und weil jede neue Funktion ihren eigenen kleinen Verbrauch mitbringt. Das ist keine beunruhigende Entwicklung. Beunruhigend wäre, wenn jemand diese Rechnung für die eigentliche hielte.