Warum ich nicht einen KI-Assistenten gebaut habe, sondern einen Baukasten — und warum der größte Hebel nicht bei der Implementierung liegt.

Der größte Hebel liegt nicht am Ende der Kette

Wenn heute über KI in der Softwareentwicklung gesprochen wird, geht es fast immer um dasselbe: schneller Code schreiben. Coding-Assistenten, Agenten, Autovervollständigung mit Kontextverständnis. Das funktioniert — ich arbeite selbst so und habe eine ganze Serie darüber geschrieben.

Nur ist die Implementierung der letzte Schritt einer langen Kette.

Davor liegen eine Idee, eine Anforderung, ein Konzept, Abstimmungen, eine Zerlegung. Wenn an einer dieser Stellen etwas schiefgeht, hilft es wenig, den letzten Schritt zu beschleunigen. Man baut dann schneller das Falsche — und zwar mit erhöhter Geschwindigkeit an der teuersten Stelle.

Barry Boehm hat 1981 beschrieben, dass ein Fehler in der Anforderungsphase um Größenordnungen billiger zu beheben ist als in der Implementierung. In meiner Agentic-Coding-Serie habe ich das als Argument für frühe Prüfpunkte verwendet. Man kann es aber auch umdrehen:

Wenn ein Fehler vorne billiger zu beheben ist, dann ist auch eine Verbesserung vorne mehr wert.

Genau das war meine Motivation. Die Frage war nicht, wie ich schneller Code schreibe, sondern wo im gesamten Prozess der Aufwand entsteht, den niemand auf der Rechnung hat. Im Zeitalter von KI und Agentic Coding liegt die Antwort für mich eindeutig nicht bei der Implementierung.

Das Problem: Anforderungen kommen nicht so an, wie sie gebraucht werden

In vielen Unternehmen gibt es Abteilungen, die ausschließlich Anforderungen erstellen. In anderen kommen Anforderungen von vielen verschiedenen Stakeholdern. Beide Konstellationen haben dasselbe Problem, aber aus unterschiedlichen Richtungen.

Im ersten Fall kommt eine Anforderung auf hoher Flughöhe herein und muss ausformuliert werden. Wer das tut, muss die Idee verstehen, die eigenen Prozesse kennen und die Anforderung so andocken, dass nichts Bestehendes zerbricht. Das ist anspruchsvolle Arbeit, und sie hängt an Erfahrung. Danach muss das Ergebnis in eine unternehmensspezifische Struktur, damit die nächste Abteilung weiterarbeiten kann.

Im zweiten Fall liefert ein externer Stakeholder etwas, das in dieser Struktur nicht existiert. Nicht aus Nachlässigkeit — er kennt sie schlicht nicht. Die Lücken füllt dann jemand anderes, und zwar in Rückfragen.

Beides kostet Zeit an der teuersten Stelle: ganz vorne, bevor eine Zeile Code entsteht.

Warum ein Chatfenster das nicht löst

Dass ein Sprachmodell Anforderungen ordentlich formulieren, auf Widersprüche prüfen und logisch strukturieren kann, war schnell klar. Ich habe es an meinen eigenen Projekten ausprobiert, am Prompt gefeilt, genug Informationen bereitgestellt (Stichwort: Context Engineering) — und die Ergebnisse wurden mit jedem Durchgang besser.

Nur ließ sich davon nichts übertragen. Was privat funktioniert, scheitert im Unternehmen an drei Stellen:

Die Ausgabestruktur schwankt. Dieselbe Aufgabe, zweimal gestellt, liefert zwei verschiedene Formate. Ich habe das zunächst gelöst, indem ich die gewünschte Struktur in den Prompt geschrieben habe — für mich allein eine Minute Arbeit, für eine Abteilung ein unlösbares Problem.

Die Qualität hängt am Prompt. Wer weiß, wie man fragt, bekommt gute Ergebnisse. Wer es nicht weiß, bekommt mittelmäßige und hält sie für das Maximum. Prompt-Kompetenz lässt sich nicht in einer Schulung ausrollen.

Dem Modell fehlt der Zugang zu allem, was das Unternehmen bereits weiß.

Die naheliegende Konsequenz wäre gewesen, den Fachbereich zu schulen. Ich halte das für den falschen Weg:

Niemand sollte zum Prompt Engineer umgeschult werden müssen, um seinen eigentlichen Job zu machen — jedenfalls nicht, wenn man eine gute Arbeitsumgebung mitdenkt.

Die Entscheidung: kein Werkzeug, sondern ein Baukasten

Also habe ich nicht einen Assistenten gebaut, sondern die Möglichkeit, sich welche anzulegen.

Der Ausgangspunkt war eine Beobachtung: Das Erzeugen einer Anforderung ist ein strukturierter Vorgang. Es gibt einen Input, eine Verarbeitung und einen Output in definierter Form. Was für Anforderungen gilt, gilt für Lösungskonzepte, Testfälle und Fehlerbeschreibungen genauso — nur mit anderen Regeln.

Der Ablauf ist für jeden Assistenten identisch. Was sich unterscheidet, sind Aufgabe, Quellen und Schema.

Ein Assistent besteht damit aus vier konfigurierbaren Teilen:

Wer einen Assistenten anlegt, beschreibt sein Fachwissen — nicht sein Prompt-Wissen. Genau darin liegt der Unterschied zwischen einem Werkzeug und einer Befähigung. Ein Werkzeug löst den Fall, für den es gebaut wurde. Ein Baukasten löst die Fälle, an die beim Bauen niemand gedacht hat.

Was damit abgedeckt ist

Es sind nicht sieben Funktionen, sondern vier Operationen über verschiedene Artefakttypen:

Dazu ein offener Chat für alles, was keinem Prozess folgt — und für die Verfeinerung eines erzeugten Ergebnisses.

Diese vier Operationen sind nicht an Softwareentwicklung gebunden. Jeder dokumentgetriebene Prozess kennt sie: etwas entsteht, wird in die nächste Form überführt, geprüft und zurückverfolgt. Was sich ändert, sind die Artefakte und die Regeln — nicht die Architektur.

Die Entscheidungen, die ich unterwegs getroffen habe

Struktur als Governance-Mechanismus

Sprachmodelle sind nicht-deterministisch. Der Inhalt schwankt, und daran ändert kein Schema etwas. Aber die Form muss nicht schwanken — und eine gleichbleibende Form ist die Voraussetzung dafür, dass jemand ohne KI-Kenntnisse zuverlässig prüfen kann.

„Ist diese Anforderung gut?" ist eine offene Frage. Sie verlangt zu wissen, was gut heißt, und gleichzeitig zu erkennen, was fehlt, obwohl es nicht dasteht. Unter Zeitdruck wird das oberflächlich beantwortet. „Sind alle Felder gefüllt, und passt der Inhalt jeweils?" ist eine geschlossene Frage. Sie lässt sich abarbeiten.

Das ist der eigentliche Grund für feste Ausgabeschemata: nicht Ordnungsliebe, sondern die Bedingung dafür, dass Human-in-the-Loop überhaupt skaliert.

Der Nebeneffekt ist mindestens so wichtig: Was strukturiert herauskommt, kann direkt weiterverarbeitet werden. Ohne Struktur verschiebt sich der Aufwand nur vom Schreiben zum Nachformatieren — und die Zeitersparnis ist wieder weg.

Kontext war der eigentliche Engpass

Zunächst wurden Anforderungen über direkte Links geladen. Das reichte für Formulierung und Formprüfung — aber nicht für die Fragen, auf die es ankommt: Widerspricht diese Anforderung einer bestehenden Funktion? Erweitert sie eine? Gibt es sie vielleicht schon?

Gelöst hat das nicht ein besserer Prompt, sondern zusätzliche Quellen: automatisches Folgen der Verweise im geladenen Artefakt, dazu ein vorgelagerter Dienst, der Lösungskonzepte, Dokumentation und Codebase bereitstellt.

Das ist derselbe Befund wie bei einer Framework-Migration, die ich parallel begleitet habe — zwei völlig verschiedene Aufgaben, dieselbe Ursache. Warum ich daraus eine Arbeitsregel gemacht habe und was das praktisch heißt, steht in einem eigenen Beitrag:

→ Warum KI-Assistenten im Unternehmen an Kontext scheitern

Multimodalität: bewusst weggelassen

Lösungskonzepte enthalten Diagramme, und oft steckt genau dort die entscheidende Information. Das System liest sie nicht.

Der direkte Weg wäre gewesen, Bilder mitzuschicken und ein multimodales Modell zu befragen. Das ändert allerdings die Kostenstruktur des gesamten Systems: Was vorher ein Textaufruf war, wird deutlich teurer — bei jedem Dokument, nicht nur bei den wenigen, wo es etwas bringt. Bei einem Werkzeug, das dauerhaft und von vielen genutzt werden soll, entscheiden laufende Kosten pro Aufruf darüber, ob es im Betrieb bleibt oder nach dem Pilotjahr abgeschaltet wird.

Die Alternative wäre, Diagramme als Code zu hinterlegen — Mermaid oder PlantUML statt Bilddateien. Für neue Dokumente ist das der richtige Weg. Für einen über Jahre gewachsenen Bestand bedeutet es, alles Vorhandene zu überführen. Der Aufwand steht in keinem Verhältnis.

Also bleibt der blinde Fleck. Dokumentiert, nicht versteckt.

Struktur und Gespräch gehören zusammen

Ein System, in dem sich Abläufe konfigurieren lassen, verführt dazu, alles konfigurieren zu wollen. Das funktioniert genau so lange, wie die Wirklichkeit mitspielt — und in einem über Jahre gewachsenen Umfeld tut sie das nicht.

Warum wurde das damals so entschieden? Welche Komponente ist eigentlich zuständig? Was bedeutet dieser Begriff bei uns? Solche Fragen tauchen einmal auf und nie wieder. Sie sind keine Ausnahme vom Prozess — sie sind der Alltag. Nicht alles ist nach Schema F lösbar, und ein System, das so tut, verliert gegen die Realität.

Das ist der eine Grund für den Chat. Der zweite ist mir erst in der Nutzung klar geworden, und er ist der wichtigere.

Der Assistent löst das Anfangsproblem, der Chat den Rest

Beim Prompten ist nicht das Nachfragen schwer. Schwer ist der Anfang.

Wer eine gute erste Anfrage stellen will, muss die Aufgabe präzise fassen, die richtigen Quellen benennen, eine Ausgabestruktur vorgeben und wissen, wogegen geprüft werden soll. Das ist die Kompetenz, die man nicht in einer Schulung vermittelt — und es ist der Punkt, an dem die meisten aufgeben und sich mit einem mittelmäßigen Ergebnis zufriedengeben, weil sie es für das Maximum halten.

Nachfragen dagegen kann jeder aus dem Fachbereich. „Der zweite Fehlerfall fehlt." „Formuliere das Akzeptanzkriterium so, dass es prüfbar ist." „Was passiert, wenn die Buchung bereits storniert wurde?" Das ist normales Fachgespräch, kein Prompt Engineering.

Genau hier teilen sich die Rollen. Der Assistent übernimmt den Teil, der Expertise verlangt: vorbereitete Aufgabe, vorbereitete Quellen, vorbereitetes Schema, vorbereitete Regeln. Was herauskommt, ist selten perfekt — aber es ist ein Ergebnis, an dem man arbeiten kann, statt eines leeren Eingabefeldes.

Und ab da übernimmt der Chat. Nicht als Rückfallebene, sondern als zweiter Schritt desselben Vorgangs: verfeinern, zuspitzen, ergänzen, bis es passt.

Der Assistent liefert den Startpunkt, der Chat die letzten zwanzig Prozent. Wiederholt sich eine Chatfrage, ist das der Hinweis auf einen fehlenden Assistenten.

Damit ist die Frage vom Anfang beantwortet: Niemand muss Prompt Engineer werden — weil der schwierige Teil im Assistenten steckt und der leichte im Gespräch.

Die Regel dahinter

Struktur, wo etwas wiederkehrt. Gespräch, wo es einmalig ist. Und die Grenze ist nicht ein für alle Mal gezogen: Taucht im Chat immer wieder dieselbe Art von Frage auf, fehlt dort ein Assistent. Umgekehrt war ein Assistent, den kaum jemand benutzt, eine Fehleinschätzung. Die Nutzung des Chats ist damit gleichzeitig die Anforderungsliste für den nächsten Baustein.

Ein Nebeneffekt, den ich unterschätzt hatte: Wer mit seiner Frage nirgends hinkann, geht trotzdem irgendwohin — in ein beliebiges Chatfenster, mit Inhalten, die dort nicht hingehören. Ein Werkzeug, das den Alltag nicht abdeckt, erzeugt Schatten-IT, und zwar zuerst bei den Kooperativen. Der offene Chat verhindert das nicht als Verbot, sondern indem der richtige Weg der bequemste ist.

Grenzen

Kein Schreiben ohne Prüfung. Das System erzeugt und analysiert, es entscheidet nicht. Jedes Ergebnis geht durch einen Menschen, bevor es weiterläuft.

Struktur schützt vor Formfehlern, nicht vor falschen Inhalten. Ein Assistent kann alle Felder korrekt füllen und trotzdem etwas behaupten, das nicht stimmt.

Keine belastbare Wirkungsmessung — aber ein Signal. Was ich sagen kann, ist nicht meine eigene Einschätzung: Seit der Kontext erweitert wurde, spiegeln mir Nutzer zurück, dass die Ergebnisse besser geworden sind. Vorher kam diese Rückmeldung nicht.

Das ist etwas wert, und es ist trotzdem kein Messwert. Es gab keine Vorher-Nachher-Erhebung, die Rückmeldungen sind unsystematisch entstanden, und wer nach Monaten noch mit einem Werkzeug arbeitet, ist ohnehin die wohlwollendere Hälfte. Im SPACE-Framework wäre das die Satisfaction-Dimension — allein stehend die schwächste der fünf, aber die einzige, die ich hier tatsächlich habe.

Eine Prozentzahl behaupte ich deshalb nicht. Warum ich das für wichtiger halte als eine gut klingende Angabe, steht in meinem Beitrag zur Wirkungsmessung.

Die Assistenten im Detail

Jeder Assistententyp bekommt einen eigenen Beitrag — mit Aufgabe, Quellen, Ausgabeschema und dem, was jeweils nicht auf Anhieb funktioniert hat:

1. Die Ersteller — von der Idee zum vollständigen Artefakt
2. Der Transformer — vom Epic zu den User Stories
3. Die Kritiker — Prüfung gegen Regeln und gegen den Bestand
4. Der Spurenleser — Fehlerlokalisierung in einer verteilten Landschaft
5. Warum KI-Assistenten im Unternehmen an Kontext scheitern