Vom MVP zur professionellen Lösung

Wann der MVP-Modus vorbei ist

Ein MVP darf schnell entstehen. Wer eine Idee prüfen will, lässt den Agenten bauen, schaut, ob jemand das Ergebnis haben will, und wirft es im Zweifel wieder weg. Dafür ist es da, und daran ist nichts falsch.

Der Anspruch ändert sich in drei Fällen. Du verkaufst das Ergebnis selbst: Sobald jemand dafür bezahlt, erwartet er, dass seine Daten morgen noch da sind. Du baust es im Auftrag: Ein Kunde nimmt es ab, betreibt es weiter und will wissen, was er bekommen hat. Oder andere verlassen sich darauf: Das interne Werkzeug, das als Experiment begann, hat inzwischen echte Nutzer und echte Daten. Diesen dritten Fall übersieht man am leichtesten, weil ihn weder eine Rechnung noch ein Vertrag ankündigt.

Was sich dann an der Arbeitsweise ändert, beschreibt Von Vibe Coding zu Agentic Engineering. Hier geht es um die konkreten Stellen, an denen ein schnell gebautes System nachgezogen werden muss. Den Anstoß gab ein Beitrag von Abul Kalam Azad auf Level Up Coding, der Empfehlungen für den Schritt vom Prototyp zum Produkt sammelt. Die sechs Bereiche unten betreffen Techniker und Nicht-Techniker gleichermaßen: Die einen setzen um, die anderen müssen wissen, wonach sie fragen.

Daten und Zustand

Im MVP sagt man dem Agenten "füg ein Feld für die Telefonnummer hinzu", und er ändert die Datenbank direkt. Solange nur Testdaten darin liegen, geht das durch. Mit echten Daten nicht mehr, denn eine Änderung, die niemand nachvollziehen kann, lässt sich weder prüfen noch wiederholen.

Deshalb gehört jede Änderung an der Datenstruktur als Migration ins Repository, die versionierte Ablage des Projekts. Eine Migration ist ein kleines Skript, das genau eine Änderung beschreibt, zusammen mit dem Code versioniert wird und erst in einer Testumgebung läuft, bevor es die echte Datenbank anfasst. So beschreiben es Martin Fowler und Pramod Sadalage in "Evolutionary Database Design".

Zwei Dinge sollte jemand an jeder Tabelle ansehen. Schlüssel sorgen dafür, dass jede Zeile eindeutig ist und Verweise zwischen Tabellen nicht ins Leere zeigen. Ein Index funktioniert wie das Stichwortverzeichnis eines Sachbuchs: Ohne ihn liest die Datenbank bei jeder Suche die ganze Tabelle, Zeile für Zeile. Mit hundert Testeinträgen fällt das nicht auf. Weil jeder Index beim Schreiben Aufwand kostet, gehört er dorthin, wo häufig gesucht wird, und nicht an jede Spalte.

Alles, was Geld oder Guthaben bewegt, läuft in einer Transaktion. Das ist ein Vorgang aus mehreren Schritten, der ganz oder gar nicht stattfindet. Die PostgreSQL-Dokumentation erklärt das an einer Überweisung: Abbuchen ohne Gutschreiben darf es nicht geben.

Bleiben zwei Absicherungen. Ein Backup zählt erst, wenn es einmal testweise zurückgespielt wurde. In Googles Buch über den Betrieb großer Systeme, dem SRE-Buch, heißt es dazu: "you only know that you can recover your recent state if you actually do so". Und der Agent bekommt keinen Schreibzugriff auf die Produktionsdatenbank, also die mit den echten Daten. Was er nicht ändern darf, kann er auch nicht versehentlich löschen. Beim Kundenauftrag gehört in die Übergabe, wo die Backups liegen und wer sie zurückspielen kann. Beim internen Werkzeug ist die Frage oft noch offener: Liegt es auf einem Rechner unter dem Schreibtisch, sichert es womöglich niemand.

Anmeldung und Zahlungen

Eine Anmeldung, die der Agent nebenbei gebaut hat, sieht aus wie jede andere. Ob Sitzungen sauber beendet und Passwörter richtig gespeichert werden, erkennt man an der Oberfläche nicht, und ein Fehler betrifft alle Konten zugleich. Die OWASP Top 10, die Standardliste der Sicherheitsrisiken für Webanwendungen, empfehlen deshalb, für Anmeldung, Identität und Sitzungen möglichst ein fertiges, erprobtes System zu nehmen: "Transfer this risk whenever possible by buying and utilizing a hardened and well tested system." Das kann ein Dienst sein oder eine verbreitete Bibliothek, die du selbst betreibst. Ein internes Werkzeug hängt man am besten an die Anmeldung, die das Unternehmen ohnehin hat, statt eine zweite Passwortverwaltung daneben zu stellen.

Für Zahlungen gilt dasselbe, mit einem zusätzlichen Grund. Wer Kartendaten selbst speichert, verarbeitet oder überträgt, fällt unter den Sicherheitsstandard PCI DSS. Deshalb überlässt man die Kartendaten einem Zahlungsanbieter und sorgt dafür, dass sie das eigene System nie berühren.

Ganz ohne eigene Logik geht es trotzdem nicht. Der Anbieter meldet deinem System per Webhook, also per automatischer Benachrichtigung, dass eine Zahlung eingegangen ist. Diese Meldungen können doppelt ankommen und in anderer Reihenfolge als erwartet, das dokumentieren die Anbieter selbst. Die Verarbeitung muss deshalb idempotent sein: Kommt dieselbe Meldung zweimal, wird trotzdem nur einmal gutgeschrieben. Praktisch merkt sich das System, welche Meldungen es schon verarbeitet hat.

Für Nicht-Techniker steckt darin eine geschäftliche Entscheidung. Jeder ausgelagerte Dienst verarbeitet personenbezogene Daten deiner Nutzer. Dafür ist in der Regel ein Auftragsverarbeitungsvertrag nötig, und du solltest wissen, wo die Daten liegen. Was hinter diesen Begriffen steckt, erklärt DSGVO und KI-Tools. Beim Kundenauftrag sollten die Konten bei diesen Diensten von Anfang an dem Kunden gehören. Sonst hängt sein Produkt an deinem Zugang.

Kosten

Eine KI-Funktion kostet bei jeder einzelnen Nutzung, denn jede Anfrage an ein Sprachmodell wird abgerechnet. Im MVP mit fünf Testern fällt das nicht auf. Mit zahlenden Kunden wächst die Rechnung mit jedem, der das Produkt gern benutzt. Beim internen Werkzeug zahlt niemand pro Nutzung, die Rechnung kommt trotzdem.

Daraus folgen zwei Grenzen. Die erste liegt beim Anbieter: eine Obergrenze für die monatlichen Ausgaben. Nicht jedes Budget stoppt Ausgaben, manche warnen nur. Wo es eine harte Grenze gibt, muss man sie meist eigens einrichten, und sie greift nicht auf die Sekunde. Prüf vor dem Start, was bei deinem Anbieter gilt, und entscheide, was im Ernstfall passieren soll: ob lieber eine Funktion ausfällt oder die Rechnung weiterläuft.

Die zweite Grenze liegt in der eigenen Anwendung: wie viel ein einzelner Nutzer in einem Zeitraum verbrauchen darf. Die API-Sicherheitsliste von OWASP führt beides als Schwachstelle, das fehlende Ausgabenlimit bei Drittanbietern und die fehlende Begrenzung je Nutzer.

Für Techniker ist der geschäftliche Teil ungewohnt. Bei einem Pauschalpreis auf variable Kosten ist der fleißigste Kunde der teuerste, und sein Tarif bildet das nicht ab. Das Preismodell muss zur Kostenstruktur passen, über Kontingente, Stufen oder nutzungsabhängige Preise. Beim Kundenauftrag gehört vor den Start die Frage, wer die laufenden Kosten für Modell und Cloud zahlt und in welcher Größenordnung sie liegen werden. Wie sich die Rechnung selbst senken lässt, zeigen die sechs Hebel in KI-Kosten im Team senken.

Review und Abnahme

Vieles lässt sich automatisch prüfen, und das sollte man auch tun, etwa mit Quality-Gates. Drei Fragen bleiben vor dem Start bei einem Menschen, weil ein Fehler dort lange unbemerkt bleibt.

Hält die Datenstruktur Last aus? Was mit zehn Testnutzern schnell ist, kann mit tausend stehen bleiben, etwa weil ein Index fehlt oder weil die Anwendung mehr gleichzeitige Verbindungen zur Datenbank öffnet, als diese verkraftet.

Kann ein Nutzer die Daten eines anderen sehen? Die Anmeldung kann einwandfrei funktionieren, und trotzdem zeigt eine geänderte Zahl in der Adresszeile den Datensatz eines Fremden. Fehlerhafte Zugriffskontrolle steht auf Platz eins der OWASP Top 10 von 2025. Jede Stelle, die eine Kennung entgegennimmt, muss prüfen, ob der angemeldete Nutzer genau diesen Datensatz sehen darf.

Was passiert, wenn zwei Anfragen gleichzeitig dasselbe ändern? Zwei Klicks im selben Moment dürfen ein Guthaben nicht zweimal ausgeben. Hier zeigt sich, ob die Transaktionen und der Umgang mit doppelten Meldungen aus den Abschnitten oben wirklich funktionieren.

Wer niemanden mit Erfahrung im Team hat, holt sich für genau diese drei Fragen jemanden dazu. Der Auftrag ist klein und klar umrissen. Beim Kundenauftrag sind die Fragen zugleich die Abnahme: Der Kunde kann sie stellen, auch wenn er die Antwort nicht selbst prüfen kann, und sich zeigen lassen, wie getestet wurde. Vorher sollte geklärt sein, wer wofür einsteht, falls später doch etwas schiefgeht. Worauf ein Review bei generiertem Code sonst achtet, haben wir in KI-Code: Fast richtig reicht nicht beschrieben.

Betrieb nach dem Start

Nach dem Start zählt, dass du einen Ausfall bemerkst, bevor der Kunde anruft. Dafür braucht es keine große Überwachung. Das SRE-Buch nennt vier Messgrößen für den Fall, dass man nur wenige erheben kann: Antwortzeit, Last, Fehler und Auslastung. Für eine kleine Lösung heißt das: Ist sie erreichbar, wie schnell antwortet sie, wie viele Anfragen scheitern, und wie nah ist sie an ihrer Grenze?

Dazu kommen die Kosten pro Tag. Eine Rechnung, die du erst am Monatsende siehst, lässt sich nicht mehr bremsen. Ein Alarm, der anschlägt, wenn der Tageswert aus dem Rahmen fällt, ergänzt die Obergrenze aus dem Kostenabschnitt.

Technisch gesund heißt aber nicht, dass jemand die Lösung nutzt. Zwei oder drei Geschäftskennzahlen zeigen das: wie viele Nutzer in der Woche aktiv sind, wie viele die Kernfunktion bis zum Ende durchlaufen, wie viele wiederkommen. Welche es sind, hängt vom Produkt ab. Wichtig ist, dass jemand regelmäßig hinsieht und dass ein Alarm bei einem Menschen ankommt. Beim Kundenauftrag muss vor dem Start feststehen, bei wem. Für das interne Werkzeug gilt das genauso, und dort fehlt diese Person am häufigsten: Gebaut hat es jemand nebenher, zuständig fühlt sich keiner.

Den Faden aufnehmen können

Eine Übergabe hat drei mögliche Empfänger. Der Kunde muss das System ohne dich und ohne deine Agenten-Sitzung betreiben und weiterentwickeln können. Ein anderer Agent oder ein anderes Werkzeug übernimmt, wenn du wechselst. Und du selbst sitzt in drei Monaten wieder davor, wenn das Projekt nur unregelmäßig weiterläuft. Für alle drei gilt dasselbe: Das Wissen muss im Repository stehen und nicht im Chatverlauf.

Dorthin gehören zuerst die Entscheidungen mit ihrer Begründung. Michael Nygard beschreibt, was sonst passiert: Wer neu dazukommt und den Grund nicht kennt, kann eine Entscheidung nur blind hinnehmen oder blind ändern. Dazu kommt eine Anweisungsdatei für Agenten, die nicht an ein Werkzeug gebunden ist. AGENTS.md ist dafür ein offenes Format, das mehrere Hersteller gemeinsam entwickelt haben. Außerdem braucht es den aktuellen Stand mit den nächsten Schritten und eine Beschreibung, wie man das Projekt startet und ausliefert, ohne etwas vorher zu wissen.

Ob das reicht, lässt sich ausprobieren. Öffne das Repository mit einem frischen Agenten ohne Chatverlauf und lass ihn das Projekt starten und eine kleine Änderung machen. Wo er nachfragen muss oder rät, fehlt etwas.

Warum eine ausgeschriebene Spezifikation mehr ist als Dokumentation, steht in Spec-driven Development: die zweite Schuld. Wie man die Anweisungsdatei kurz hält, zeigt Harness Engineering.

Was der Agent kann und was ein Mensch prüfen muss

Ein Coding-Agent kann jeden dieser Punkte umsetzen. Er legt Migrationen an, bindet einen Anmeldedienst ein und fängt doppelte Zahlungsmeldungen ab. Verlassen solltest du dich nur nicht darauf, dass er es ungefragt tut oder von sich aus meldet, was fehlt. Ein Auftrag wie "bau eine Bezahlfunktion" sagt nichts über doppelte Meldungen.

Die Vorgaben gehören deshalb an zwei Stellen. Was immer gilt, steht in der Anweisungsdatei: Schemaänderungen nur als Migration, kein Schreibzugriff auf Produktionsdaten, Anmeldung und Zahlung nur über die festgelegten Dienste. Was für eine einzelne Aufgabe gilt, steht im Auftrag. Bei Fehlern hilft eine feste Reihenfolge: erst ein Test, der den Fehler zeigt, dann die Korrektur. Der Agent braucht eine Prüfung, die er selbst ausführen kann, sonst ist "sieht fertig aus" sein einziges Signal.

Das Ergebnis prüft ein Mensch. Bei Anmeldung, Zahlungen und Datenstruktur gilt das immer, und die drei Fragen aus dem Review-Abschnitt sind das Minimum. Dass ein Klick auf "Freigeben" noch keine Prüfung ist, ist das Thema von Die 79-Prozent-Falle.

Prüfliste

Jede Frage lässt sich mit Ja oder Nein beantworten. Wo du die Antwort nicht kennst, ist das auch eine.

Daten und Zustand

• Liegt jede Schemaänderung als Migrationsdatei im Repository?
• Haben die Tabellen Schlüssel und Indizes auf den Spalten, nach denen häufig gesucht wird?
• Läuft alles, was Geld oder Guthaben bewegt, in einer Transaktion?
• Wurde ein Backup schon einmal testweise zurückgespielt?
• Ist dem Agenten der Schreibzugriff auf die Produktionsdatenbank entzogen?

Anmeldung und Zahlungen

• Läuft die Anmeldung über ein erprobtes System statt über selbst generierten Code?
• Bleiben Kartendaten vollständig beim Zahlungsanbieter?
• Wird eine doppelt zugestellte Zahlungsmeldung nur einmal verarbeitet?
• Gehören die Konten bei externen Diensten dem, der die Lösung später betreibt?

Kosten

• Gibt es beim Anbieter eine Ausgabenobergrenze, die stoppt und nicht nur warnt?
• Ist begrenzt, wie viel ein einzelner Nutzer verbrauchen kann?
• Deckt das Preismodell auch den Kunden mit dem höchsten Verbrauch?
• Steht fest, wer die laufenden Kosten für Modell und Cloud trägt?

Review und Abnahme

• Hat ein Mensch geprüft, ob ein Nutzer fremde Daten abrufen kann?
• Ist getestet, was bei zwei gleichzeitigen Anfragen auf dasselbe Guthaben passiert?
• Hält die Datenbank die erwartete Zahl gleichzeitiger Nutzer aus?
• Verlangen eure Vorgaben bei Fehlern erst einen Test und dann die Korrektur?

Betrieb nach dem Start

• Erfährst du von einem Ausfall, bevor ein Nutzer ihn meldet?
• Schlägt ein Alarm an, wenn die Tageskosten aus dem Rahmen fallen?
• Kommt jeder Alarm bei einem Menschen an, der zuständig ist?
• Gibt es zwei oder drei Kennzahlen, die zeigen, ob die Lösung genutzt wird?

Übergabe

• Stehen die wichtigen Entscheidungen mit Begründung im Repository?
• Gibt es eine Anweisungsdatei für Agenten, die nicht an ein Werkzeug gebunden ist?
• Ist beschrieben, wie man das Projekt ohne Vorwissen startet und ausliefert?
• Kommt ein frischer Agent ohne Chatverlauf mit dem Repository allein zurecht?