Ein Kunde kam mit einem Vermittlungsproblem zu mir. Auf der einen Seite: Unternehmen, die Mitarbeiterschulungen in bestimmten Bereichen benötigen, also Compliance-Kurse, technische Zertifizierungen, Spezialkompetenzen. Auf der anderen Seite: Unternehmen, die genau diese Schulungen anbieten, massgeschneidert auf Anfrage. Beide Seiten operierten noch immer über Telefonanrufe und Website-Suchen. Keine Plattform brachte sie zusammen. Und die Schulungsanbieter, obwohl sie mehr potenzielle Nachfrage hatten als sie bewältigen konnten, konkurrierten um dieselben Anfragen.

Die Idee war konzeptionell unkompliziert: Anbieter-Websites scrapen, ein LLM verwenden, um strukturierte Schulungsdaten zu extrahieren (Themen, Termine, Formate, Kapazitäten), das Ganze durch einen Human-in-the-Loop-Qualitätsprozess führen und auf einem durchsuchbaren Frontend veröffentlichen. Bevor wir uns auf Architektur, Teamstruktur und einen echten Lieferzeitplan festlegten, mussten wir wissen, welche Teile tatsächlich schwierig waren.

Also bauten wir einen Prototyp. Fünf bewegliche Teile: Tech-Scouting, Datenbankaufbau und Schema-Definition, ein Frontend, ein Backend und eine LLM-Pipeline zur Verarbeitung unstrukturierter Eingaben. Kaum eine Woche. Kein perfekter Code. Keine optimalen Architekturentscheidungen. Kein massgeschneidertes UX. Das war auch nicht der Punkt.

Was der Prototyp tatsächlich gefunden hat

Ein Planungsdokument hätte keines dieser vier Dinge gefunden.

Das LLM musste sein eigenes Konfidenz-Scoring übernehmen. Ohne menschliche Überprüfung produzierte die Pipeline Schulungsveranstaltungen mit falschen Terminen und fehlerhaften Details. Das Modell füllte Lücken, für die es nicht genug Signal hatte, um sie zuverlässig zu füllen. Aber das LLM konnte seine eigene Unsicherheit markieren: Extraktionen mit geringer Konfidenz konnten zur Überprüfung zurückgehalten werden, solche mit hoher Konfidenz konnten automatisch veröffentlicht werden. Diese eine Erkenntnis veränderte die gesamte Qualitätsarchitektur. Statt einer binären Entscheidung Mensch/kein Mensch hatten wir ein gestuftes System, das durch die eigene Einschätzung des Modells gesteuert wurde.

Reine Code-Extraktion war keine Lösung. Anbieter-Websites gibt es in allen erdenklichen Formaten: PDFs, ungewöhnlich strukturiertes HTML, eingebettete Tabellen, Inhalte über mehrere Seiten verteilt. Ein fest kodierter Extraktionsansatz hätte Hunderte von Sonderfällen erfordert: Monate an Arbeit, die dennoch fragil geblieben wäre. Das LLM machte die Extraktion nicht nur schneller, sondern überhaupt erst machbar. Es konnte über Struktur nachdenken, anstatt Muster dagegen abzugleichen. Das ist eine qualitativ andere Fähigkeit, kein bloss quantitativer Produktivitätsgewinn.

Menschliche Überprüfung führte zu einem Geschwindigkeits-Kompromiss. Die Datenqualität verbesserte sich, aber die Veröffentlichung verlangsamte sich. Neu gecrawlte Anbieter warteten in einer Queue auf die Überprüfung. Das Konfidenz-Scoring wurde zum Mechanismus zur Steuerung dieses Kompromisses: nur unsichere Fälle wurden an einen Menschen weitergeleitet, der Rest wurde automatisch durchgelassen. Dieses spezifische Design wurde erst sichtbar, als wir es gegen echte Daten messen konnten. Es stand nicht im ursprünglichen Plan, weil es nicht stehen konnte.

Die Infrastruktur war wichtiger als erwartet. Alles, was durch die Pipeline verarbeitet wurde, berührte persönliche und organisatorische Daten, was bedeutete, dass DSGVO-Konformität keine Option war. Der Prototyp zeigte, dass Infrastructure as Code kein Nice-to-have war, sondern eine erstklassige Architekturanforderung. Die Compliance im grossen Massstab durch manuelle Infrastruktur zu verwalten wäre ein Haftungsrisiko gewesen. Das fanden wir in Woche eins heraus, nicht in Monat vier.

Das Gespräch danach

Nach dieser Woche diskutierten wir nicht mehr über das Konzept. Wir sprachen über spezifische Probleme mit spezifischen Lösungen. Nicht "wie gehen wir mit Datenqualität um?" sondern "was ist der richtige Konfidenz-Schwellenwert für die automatische Veröffentlichung, und wie stellen wir Grenzfälle den Prüfern zur Verfügung, ohne einen Engpass zu schaffen?" Der Prototyp hatte Hypothesen in Probleme umgewandelt. Und Probleme lassen sich tatsächlich lösen.

Der Code war in den Hintergrund getreten. Nicht weil die technischen Erkenntnisse keine Rolle gespielt hätten. Sie prägten jede nachfolgende Architekturentscheidung. Aber sie waren nicht mehr das Lauteste im Raum. Die Session hatte die eigentlichen Probleme gefunden: die Qualitätsarchitektur, den menschlichen Workflow, die Infrastrukturanforderungen, die Sonderfälle, die die Implementierung definieren würden. Die Gespräche nach dem Prototyp waren auf eine Weise fundiert, die keine Menge vorab geleisteter Planung erreicht hatte.

Wo das anknüpft

Ich begann meine Karriere bei frog und später bei Intuity Media Lab. Fünfzehn Jahre und mehrere grosse Plattformen später (Siemens, Deutsche Telekom, Mercedes-Benz) habe ich ein beständiges Muster beobachtet: Das Technologiegespräch verdrängt das Kundengespräch. Framework-Debatten. Architektur-Auseinandersetzungen. Tool-Entscheidungen, die zum Hauptereignis werden, obwohl sie Infrastruktur sein sollten. Ich habe zu diesen Gesprächen beigetragen. Es ist eine branchenweite Gewohnheit.

Was sich mit AI verändert, ist nicht das Prinzip: Rapid Prototyping gab es lange vor LLMs, und die Philosophie, zu bauen um zu lernen statt zu planen bis zur Gewissheit, ist Jahrzehnte alt. Was sich verändert, ist das Kostenmodell. Das LLM ersetzte Monate an Edge-Case-Parser-Entwicklung durch Tage an Prompt-Iteration. Die Konfidenz-Scoring-Architektur entstand aus dem Prototyp, weil wir echte Daten hatten, gegen die wir scoren konnten. Die DSGVO-Infrastrukturanforderung tauchte früh genug auf, um dafür zu designen, nicht um sie nachzurüsten. Das ist, was "kaum eine Woche" bedeutet: nicht dass das Bauen im Allgemeinen schneller geworden ist, sondern dass die spezifischen Teile, die funktionieren mussten, funktionierten, und alles andere konnte roh sein.

Wenn Bauen teuer ist, wird das Argument über den Ansatz zur Kultur. Man debattiert Frameworks, weil man lange mit der Entscheidung leben wird, bevor man weiss, ob sie richtig war. Wenn Bauen günstig genug wird, findet man es heraus. Das Vorab-Gespräch kann über die richtigen Dinge sein: das Problem, der Nutzer, das Ergebnis.

Der Plan für die eigentliche Implementierung verbesserte sich dramatisch. Nicht weil der Prototyp guter Code war. Weil er die schwierigen Teile gefunden hatte.

Code im Hintergrund. Dort gehört er hin. Er sollte immer dort sein.

Verwandte Artikel: AI hat verändert, wie ich arbeite, nicht was ich tue · Wo AI in der Enterprise-Architektur wirklich hilft