Ein Prototyp beantwortet meist eine enge Frage: Kann diese Interaktion grundsätzlich funktionieren? Ein übergebbares System muss mehr beantworten: mit welchen Daten, unter wessen Identität, innerhalb welcher Grenzen, messbar nach welchen Kriterien und mit welchem Rückfallweg?
Der Schritt dazwischen ist keine einzelne „Produktionsreife“-Phase. Er ist eine Folge kleiner technischer Entscheidungen.
Einen vollständigen Ausschnitt wählen
Der erste Ausschnitt sollte klein sein, aber durch den echten Ablauf laufen. Er umfasst Eingabe, Datenzugriff, Modellaufruf, Validierung, menschliche Entscheidung und das Ergebnis im Zielsystem. Ein isolierter Modelltest verschiebt Integrationsrisiken nur nach hinten.
Die Grenze wird schriftlich festgehalten: unterstützte Fälle, nicht unterstützte Fälle, zulässige Quellen und Aktionen. Diese Beschreibung ist später wichtiger als eine lange Funktionsliste.
Verhalten versionieren
Zum Systemverhalten gehören mehr als Quellcode. Modellbezeichnung, Prompt, Werkzeuge, Schemas, Retrieval-Konfiguration und relevante Richtlinien müssen einer Änderung zugeordnet werden können. Wo Anbieter eine Version nicht dauerhaft fixieren, braucht die Änderung zumindest eine erkennbare Evaluation und einen Rückfall.
So wird eine unerwartete Antwort zu einer untersuchbaren Abweichung statt zu einer Vermutung über „das Modell“.
Evaluation als Entwicklungswerkzeug
Ein kleiner, kuratierter Testsatz startet vor dem Ausbau. Er enthält reale Formen von Eingaben, kritische Grenzfälle und ausdrücklich unerwünschtes Verhalten. Automatische Prüfungen eignen sich für Struktur, Pflichtfelder, Zahlenbezug, Berechtigungen und Quellen. Fachliche Qualität benötigt zusätzlich menschliches Urteil.
Das Ziel ist nicht eine universelle Kennzahl. Es ist ein Release-Gate, das für diesen Ablauf erklärt, was eine Änderung schlechter macht und wer eine bewusste Ausnahme verantwortet.
Fehler als Teil des Entwurfs behandeln
Provider-Ausfall, Zeitüberschreitung, ungültige Struktur, fehlende Quelle und abgelehnte Werkzeugaktion brauchen jeweils ein sichtbares Verhalten. Je nach Aufgabe kann das ein erneuter Versuch, eine manuelle Warteschlange, der alte Prozess oder ein klarer Abbruch sein.
Ein Rückfall ist dann gut, wenn er vor einem Zwischenfall geprobt werden kann. „Wir schalten das Modell aus“ reicht nicht, wenn niemand weiß, wie die Arbeit danach weiterläuft.
Für die Übergabe bauen
Die Übergabe beginnt nicht am Projektende. Zuständigkeit, Konfiguration, Geheimnisse, Protokollzugriff, Kosten und Änderungsweg beeinflussen die Architektur von Anfang an.
Ein sinnvoller Abschluss ermöglicht einer anderen verantwortlichen Person:
- den aktuellen Stand reproduzierbar bereitzustellen,
- eine Änderung gegen festgelegte Fälle zu prüfen,
- einen Fehler einzugrenzen,
- auf einen bekannten Stand zurückzugehen,
- offene Grenzen und Entscheidungen zu verstehen.
Das ist weniger spektakulär als eine Demo. Es ist der Unterschied zwischen einem interessanten Prototyp und einem System, das in der Arbeit bestehen kann.
Die Leistungen verbinden Klärung, Bau und Stabilisierung entlang dieser Grenze.
Sie möchten einen konkreten Ablauf einordnen?
Kontakt aufnehmen