Im November 2025 kürte Collins Dictionary „vibe coding“ zum Wort des Jahres und definierte es als den Einsatz von KI, gesteuert in natürlicher Sprache, um beim Schreiben von Code zu helfen. Der Begriff hat sich gehalten, weil die Erfahrung real ist. Man beschreibt eine App, übernimmt, was das Modell schreibt, und hat am Sonntagabend einen funktionierenden Bildschirm. Eine Gründerin oder ein Gründer kann heute Kunden eine Demo zeigen, bevor ein Engineer eingestellt ist.
Nicht billiger geworden ist der Teil, der Software verlässlich macht. In der Stack Overflow Developer Survey 2025 nannten 66% der Entwickler „KI-Lösungen, die fast richtig sind, aber nicht ganz“ als größtes Ärgernis mit KI-Tools, und 45% sagten, dass das Debuggen von KI-generiertem Code mehr Zeit kostet. Ein Prototyp ist der Ort, an dem fast richtig in Ordnung ist. Produktion ist der Ort, an dem es das nicht ist.
Diese Notiz listet auf, was Produktion zu einem Prototyp hinzufügt, gibt eine grobe Aufteilung des Aufwands und schlägt vor, wie Budgetverantwortliche mit der Demo umgehen sollten, die man ihnen gerade gezeigt hat.
Die Beschleunigung ist real und trotzdem nicht gemessen
Die sorgfältigste Messung der KI-Coding-Geschwindigkeit stammt von METR, einer gemeinnützigen Forschungsorganisation. Ihre randomisierte Studie von 2025 ergab, dass erfahrene Open-Source-Entwickler 19% länger für Aufgaben brauchten, wenn KI erlaubt war, mit einem Konfidenzintervall von +2% bis +39%.
Am 24. Februar 2026 veröffentlichte METR eine Folgestudie: 57 Entwickler, 143 Repositories, mehr als 800 Aufgaben, durchgeführt ab August 2025. Auf derselben Skala der Zeitveränderung, auf der das Ergebnis von 2025 bei +19% lag, betragen die neuen Punktschätzungen -18% für Entwickler, die aus der ersten Studie zurückkehrten (Intervall -38% bis +9%), und -4% für neu rekrutierte Entwickler (Intervall -15% bis +9%). Beide Punktschätzungen deuten nun darauf hin, dass KI Zeit spart. Beide Intervalle schließen null ein.
METR selbst bezeichnet die neuen Daten als unzuverlässiges Signal. Zwischen 30% und 50% der Entwickler gaben an, einige Aufgaben bewusst nicht eingereicht zu haben, weil sie sie nicht ohne KI erledigen wollten. Gerade die Aufgaben, bei denen KI am meisten hilft, fehlen also in der Stichprobe, und METR hält die tatsächliche Beschleunigung wahrscheinlich für größer als die eigene Schätzung.
Für Käufer ist die Schlussfolgerung eng. KI macht manches Programmieren schneller, um einen Betrag, den sorgfältige Forscher nicht genau bestimmen konnten. Sie ändert nichts daran, was ein System braucht, bevor Menschen sich darauf verlassen können.
Was ein Prototyp beweist und was nicht
Ein Wochenend-Prototyp beweist drei nützliche Dinge: Die Idee funktioniert mit den Eingaben, die jemand ausprobiert hat, die Oberfläche ergibt für die Menschen Sinn, die sie gesehen haben, und jemand will das Ergebnis.
Er beweist nicht, dass das System mit Eingaben funktioniert, die niemand ausprobiert hat, dass es für zweihundert Menschen gleichzeitig funktioniert, dass es jeder Person nur zeigt, was sie sehen darf, dass es pro Monat kostet, was Sie erwarten, oder dass irgendjemand es reparieren kann, wenn es nachts ausfällt. Das sind die Fragen, die Produktion beantwortet.
Es gibt einen zweiten Unterschied, der leicht übersehen wird. Ein Prototyp wird von der Person beurteilt, die ihn gebaut hat, am Tag, an dem er gebaut wurde, mit Eingaben, die sie selbst gewählt hat. Ein Produktionssystem wird von Menschen beurteilt, die die Demo nie gesehen haben, Monate später, mit Daten, die es beim Schreiben des Codes noch nicht gab. Der größte Teil der Arbeit in der nächsten Tabelle existiert, damit das zweite Urteil gut ausfällt.
Was Produktion hinzufügt
Die folgenden Anteile sind eine illustrative Aufteilung für ein internes LLM-Tool, etwa einen Copilot für die Dokumentensuche, auf dem Weg von einem funktionierenden Prototyp zu einigen hundert täglichen Nutzern. Es sind Planungsannahmen, keine Messungen. Passen Sie die Gewichte an Ihren Fall an; es geht um die Form.
| Arbeitspaket | Was es bedeutet | Ohne es | Illustrativer Anteil |
|---|---|---|---|
| Kernlogik | Was der Prototyp bereits zeigt | Kein Produkt | 20% |
| Datenverträge und Pipelines | Schemaprüfungen für jeden Eingangsdatenstrom; geplante, idempotente Ladevorgänge | Ein vorgelagerter Export ändert sich, und die Antworten werden ohne Fehlermeldung schlechter | 15% |
| Evaluationsset und Quality Gates | Echte Fragen mit erwarteten Antworten, ausgeführt bei jeder Prompt- oder Modelländerung | Niemand kann sagen, ob eine Änderung etwas besser oder schlechter gemacht hat | 12% |
| Authentifizierung und Berechtigungen | Single Sign-on; Zugriffsregeln, die beim Retrieval durchgesetzt werden | Mitarbeitende sehen Dokumente, die sie nicht sehen sollten | 8% |
| Eingabevalidierung und Fehlerbehandlung | Größen- und Formatgrenzen; Umgang mit feindseligem Text in Uploads und abgerufenen Dokumenten | Eine seltsame Datei legt den Dienst lahm oder lenkt das Modell | 8% |
| Monitoring und Alerting | Latenz, Fehlerrate, Kosten pro Anfrage, Anteil leerer Retrievals, Nutzerfeedback | Probleme werden von Nutzern gemeldet, Tage später | 8% |
| Security-Review und Fixes | Secrets, Abhängigkeiten, an Drittanbieter-APIs gesendete Daten | Ein geleakter Schlüssel oder ein Verstoß beim Datenumgang | 8% |
| Rufbereitschaft und Runbooks | Eine benannte verantwortliche Person und schriftliche Schritte für die häufigen Ausfälle | Die einzige Person, die Bescheid weiß, ist im Urlaub | 7% |
| Rollback und Release-Prozess | Versionierte Prompts, Modelle und Indizes; ein Schalter zurück zur letzten guten Version | Ein schlechtes Release bleibt live, während jemand debuggt | 5% |
| Dokumentation und Übergabe | Wie es funktioniert, wie man es ändert, wie man es betreibt | Das System überlebt seinen Autor nicht | 5% |
| Kostenlimits | Kontingente pro Nutzer, Token-Obergrenzen, ein Circuit Breaker für Ausgaben | Eine Schleife oder ein Vielnutzer erzeugt eine überraschende Rechnung | 4% |
Die erste Zeile ist der Prototyp. In dieser Aufteilung ist er ein Fünftel der Arbeit. Die anderen vier Fünftel sind in einer Demo unsichtbar, und deshalb ist eine Demo ein so schlechter Maßstab für ein Budget.
Für Engineers: wohin die Zeit geht
Einige Zeilen verdienen mehr Details, weil Schätzungen gerade dort meist danebenliegen.
Berechtigungen gehören ins Retrieval, nicht in die Antwort. In einem Retrieval-Augmented-System muss die Zugriffsprüfung Dokumente filtern, bevor sie das Modell erreichen. Filtern nach der Generierung funktioniert nicht: Das Modell hat den gesperrten Text bereits gelesen und kann ihn paraphrasieren. Das bedeutet, dass der Index Zugriffsmetadaten trägt, mit dem Quellsystem synchron bleibt und jemand ihn mit Konten testet, die unterschiedliche Rechte haben.
Das Evaluationsset ist die Spezifikation in ausführbarer Form. Es ist eine versionierte Datei mit echten Eingaben und erwarteten Ausgaben oder Bewertungsregeln, die in der CI bei jeder Änderung an Prompts, Modellen, Chunking oder Retrieval-Einstellungen läuft. Um es zu bauen, setzt man sich mit den künftigen Nutzern des Systems zusammen und schreibt auf, was eine richtige Antwort ist. Das ist langsam, und kein Assistent kann es Ihnen abnehmen, weil das Wissen bei den Nutzern liegt.
Eingabevalidierung umfasst jetzt auch Text, der das Modell angreift. Ein Dokument im Index kann Anweisungen enthalten. Uploads können riesig, leer, gescannte Bilder oder falsch kodiert sein. Jeder Fall braucht ein definiertes Verhalten und einen Test.
Rollback setzt voraus, dass alles gemeinsam versioniert ist. Ein Release besteht aus einem Prompt, einer Modellversion, einem Index-Build und Code. Liegt nur der Code in git, setzt ein Rollback des Codes das Verhalten nicht zurück.
Kostenlimits sind ein Produktionsfeature. Ein Prototyp hat einen Nutzer. Ein Produktionssystem hat einige hundert, dazu Skripte und Wiederholungsversuche. Kontingente pro Nutzer, maximale Token-Zahlen und ein Alarm auf die täglichen Ausgaben sind billig zu bauen und verhindern die häufigste unangenehme Überraschung.
Wie Budgetverantwortliche mit einem Prototyp umgehen sollten
Behandeln Sie ihn als Spezifikation. Ein funktionierender Prototyp ist die klarste Beschreibung dessen, was Sie wollen, die die meisten Projekte je bekommen. Geben Sie ihn den Engineers zusammen mit der Liste der Eingaben, mit denen er ausprobiert wurde, und der Fälle, in denen er versagt hat.
Behandeln Sie ihn nicht als 80% des Produkts. Ist ein Angebot klein, weil der Prototyp existiert, fragen Sie, welche der Zeilen oben es abdeckt. Lautet die Antwort nur die erste Zeile, ist das Angebot für einen zweiten Prototyp.
Testen Sie damit die Nachfrage, bevor Sie Produktion finanzieren. Stellen Sie ihn zwei Wochen lang den vorgesehenen Nutzern zur Verfügung. Kommen sie nicht darauf zurück, haben Sie das Produktionsbudget gespart, und das ist das Nützlichste, was ein Prototyp leisten kann.
Wann man den Prototyp wegwerfen sollte
Schreiben Sie neu, statt zu erweitern, wenn mindestens einer dieser Punkte zutrifft:
- Secrets stehen im Code oder in der Repository-Historie;
- Daten werden über ein persönliches Konto oder einen persönlichen API-Schlüssel abgerufen;
- Oberfläche, Logik und Datenzugriff sind miteinander vermischt, sodass Berechtigungen nicht an einer Stelle durchgesetzt werden können;
- niemand kann erklären, wie eine bestimmte Antwort entstanden ist;
- er läuft auf einem gehosteten Builder, der sich nicht in Ihrer Umgebung betreiben lässt oder Ihre Datenregeln nicht erfüllt;
- die Logik ist lang und hat keine Tests.
Behalten Sie ihn, wenn die Kernlogik kurz, lesbar und abtrennbar ist, bereits einige Tests existieren und der Datenfluss dem in Produktion ähnelt.
Code wegzuwerfen kostet weniger, als es klingt. Der Prototyp hat seine Aufgabe bereits erfüllt: Die Entscheidungen sind getroffen, die Beispiele gesammelt, die Oberfläche ausprobiert. Prompts, Beispieleingaben und Screenshots überleben ein Neuschreiben meist, auch wenn der Code es nicht tut.
Wie die Lücke in Geld aussieht
Unsere eigenen veröffentlichten Preisspannen zeigen dasselbe Verhältnis. Ein Proof of Concept kostet 14k–38k € über 4–7 Wochen. Ein Produktionssystem kostet 45k–120k € über 10–20 Wochen. An beiden Enden der Spanne ist Produktion etwa dreimal so teuer wie der Proof of Concept: 45 / 14 ≈ 3,2 und 120 / 38 ≈ 3,2. Dieser Faktor sind die Kosten der Zeilen oben, die nicht die erste sind. Aus demselben Grund liefern wir Monitoring und Rollback vor der Übergabe aus: Sie ermöglichen es einem Kunden, das System ohne uns zu betreiben.
Wenn Sie bereits einen Prototyp haben und wissen wollen, welche Zeilen er abdeckt, ist der kostenlose Teardown eine erste Prüfung in sechs Fragen, und eine kurze bezahlte Discovery beantwortet es vollständig. Dieselbe Liste gilt für interne Dokumenten-Copilots, bei denen Berechtigungen und das Evaluationsset meist die meiste Zeit kosten.
Quellen
- CNN, 'Vibe coding' named Collins Dictionary's Word of the Year, November 2025 — https://www.cnn.com/2025/11/06/tech/vibe-coding-collins-word-year-scli-intl
- Stack Overflow, 2025 Developer Survey: AI, Juli 2025 — https://survey.stackoverflow.co/2025/ai
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, Juli 2025 — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR, We are Changing our Developer Productivity Experiment Design, Februar 2026 — https://metr.org/blog/2026-02-24-uplift-update/