Holycode
← Zurück zum Blog

Warum Prompting kein Liefermodell ist

9 Min. Lesezeit
Eine erfahrene Entwicklerin prüft Code an zwei Monitoren in einem hellen Schweizer Büro

Jede Engineering-Organisation, mit der wir in Zürich, München, London oder Stockholm sprechen, hat das Experiment bereits gemacht. Lizenzen für einen Coding-Assistenten gekauft, gemessen, und eine reale, aber überschaubare Verbesserung gefunden: irgendwo zwischen 15 und 25 Prozent auf die reine Programmieraufgabe. Danach bewegte sich die Zahl nicht mehr. Die naheliegende Frage: Wenn KI ein derartiger Sprung ist, warum verschiebt sich der Liefertermin kaum?

Die Antwort ist unbequem, aber einfach. Code schreiben war nie der Engpass. Der Engpass ist alles drumherum: Scope abstimmen, ein Geschäftsziel in eine Spezifikation übersetzen, Architektur über ein Dutzend Beitragende konsistent halten, Tests schreiben und pflegen, reviewen, integrieren, dokumentieren — und Entscheidungen erneut treffen, die vor drei Monaten schon getroffen wurden, weil sie niemand maschinenlesbar festgehalten hat.

Prompting ist konstruktionsbedingt nicht deterministisch

Ein Prompt ist eine Anweisung ohne Vertrag. Zwei Entwickler produzieren mit demselben Ticket und demselben Modell zwei verschiedene Architekturen, zwei Teststrategien und zwei Namenskonventionen. Für einen Prototyp ist das in Ordnung, für ein System mit sieben Jahren Lebensdauer fatal. Diese Varianz verschwindet nicht mit besseren Modellen — bessere Modelle liefern lediglich bessere Varianz.

Was eine Plattform verändert

Rapid Development kapselt den Lieferprozess selbst. Statt ein Modell zu bitten, ein Feature zu schreiben, führt die Plattform eine feste Befehlsfolge gegen eine versionierte Spezifikation aus. Jeder Befehl hat definierte Eingaben, definierte Ausgaben und ein Artefakt, das ein Mensch prüft. Das Modell ist eine Komponente im Prozess, nicht der Prozess.

DimensionPromptingPlattform
WiederholbarkeitPro PersonPro Prozess
Typischer Gewinn+15–25 % beim Coden3–5× in der Lieferung
NachvollziehbarkeitChatverlaufVersionierte Artefakte

Was das für Ihre Entscheidung heisst

Wenn Sie zwischen einem klassischen Nearshore-Team und einem KI-nativen Partner wählen, vergleichen Sie weder Stundensätze noch Modellnamen. Fragen Sie, was der Lieferprozess produziert, wenn niemand hinschaut. Lassen Sie sich die Artefakte zeigen. Fragen Sie, was passiert, wenn die zugeteilte Entwicklerin geht. Ein Team, das diese drei Fragen mit Dokumenten statt mit Adjektiven beantwortet, ist ein Team, mit dessen Zeitplan Sie planen können.

Gleicher Scope, gleiche Garantien, gleiche Seniorität — in einem Fünftel bis einem Drittel der Zeit, für weniger als die Hälfte der Kosten.

Discovery dauert Wochen statt Monate und endet mit Scope, Komplexität und einer belastbaren Schätzung.

Verwandte Beiträge