Von der Demo zur Produktion: unser Verifikations-Framework

Jeder, der in den letzten zwei Jahren mit KI-Coding-Tools gearbeitet hat, kennt den Moment: Nach zwei Stunden steht eine Anwendung, die aussieht, als hätte ein Team Wochen daran gearbeitet. Und jeder, der so eine Anwendung dann produktiv betreiben wollte, kennt den zweiten Moment: den, in dem klar wird, wie groß die Lücke zwischen beeindruckend und belastbar ist. Unser Verifikations-Framework existiert, um genau diese Lücke systematisch zu schließen. Es besteht aus vier Schichten, und keine davon ist optional.

Warum die Demo-Produktions-Lücke strukturell ist

Die Lücke ist kein Zeichen schlechter Modelle, sondern folgt aus dem, worauf Modelle optimieren: die beschriebene Anforderung sichtbar zu erfüllen. Eine Demo muss den vorgeführten Pfad beherrschen. Produktion muss alles andere beherrschen: die fehlerhafte Eingabe, den doppelten Klick, den Ausfall der angebundenen Schnittstelle, den Datensatz mit Sonderzeichen, den Nutzer mit abgelaufener Sitzung. Nichts davon kommt in einer typischen Anforderungsbeschreibung vor, also existiert es im generierten Code schlicht nicht. Verifikation heißt, diese unsichtbaren Anforderungen systematisch sichtbar zu machen.

Schicht 1: Spezifikation vor Generierung

Die erste Schicht liegt vor der ersten Zeile Code. Aus dem Erstgespräch mit dem Kunden entsteht eine strukturierte Spezifikation: Datenmodelle, Schnittstellen, Zustände, Berechtigungen und, entscheidend, die explizit benannten Randfälle. Was passiert bei ungültigen Eingaben? Wer darf was sehen? Welche Aktionen müssen nachvollziehbar sein? Die Agenten arbeiten gegen dieses Dokument, nicht gegen eine Gesprächsnotiz. Der Nebeneffekt für unsere Kunden: Diese Spezifikation ersetzt das klassische Pflichtenheft, ohne dessen Bürokratie, und sie bleibt als Dokumentation erhalten.

Schicht 2: Generierung mit Leitplanken

Die Agenten selbst arbeiten nicht auf der grünen Wiese, sondern in einem vorbereiteten Rahmen: eine Projektstruktur mit definierten Architektur-Grenzen, freigegebene Bibliotheken, Vorgaben für Fehlerbehandlung, Logging und Datenzugriff. Das reduziert die Varianz des generierten Codes dramatisch. Zwei Agenten, die an verschiedenen Features arbeiten, produzieren Code, der aussieht, als käme er aus einer Hand, weil der Rahmen es erzwingt.

Schicht 3: Automatisierte Prüfung und menschliche Freigabe

Jede Änderung durchläuft unsere automatisierte Check-Pipeline, von Tests über Typprüfung bis zu Security-Scans. Die Details dieser rund 40 Checks haben wir in einem eigenen Artikel beschrieben. Wichtig ist hier das Prinzip der Arbeitsteilung: Die Maschine prüft vollständig und unbestechlich alles Prüfbare, der Mensch konzentriert seine Urteilskraft auf Architektur, Fachlichkeit und Datenschutz. Keine Zeile erreicht Produktion ohne beide Freigaben.

Schicht 4: Betrieb als Feedback-Schleife

Produktionsreife endet nicht beim Deployment. Jedes System, das wir ausliefern, geht mit Monitoring, Fehler-Alerting und definierten Update-Prozessen live. Fehler, die im Betrieb auftreten, fließen als neue Testfälle zurück in die Pipeline, damit derselbe Fehler kein zweites Mal passieren kann. Bei Vergabepilot.AI, unserem eigenen Produkt mit über 13.000 Nutzern, läuft diese Schleife seit Jahren, und sie ist der Grund, warum wir unsere Methodik mit ruhigem Gewissen verkaufen: Wir müssen jeden Tag selbst mit ihr leben.

Das Ergebnis: Geschwindigkeit, der man trauen kann

Der eigentliche Punkt des Frameworks ist nicht Sicherheit gegen Geschwindigkeit, sondern Sicherheit als Voraussetzung für Geschwindigkeit. Weil die Verifikation automatisiert mitläuft, können die Agenten so schnell arbeiten, wie sie können, ohne dass die Qualität davonläuft. Genau das unterscheidet Vibe Engineering von Vibe Coding: dieselbe Technologie, aber ein System dahinter, das aus Tempo Verlässlichkeit macht.