Sim Racing Coach

Die Web-App hatte bereits eine KI-Oberfläche: zehn Dimensionen bewertet, jede mit einem kurzen Coaching-Tipp, alles in einem Modal. Das Desktop-Aufzeichnungstool hatte einen Chat-Agenten, der Kurven-Abfragen ausführte und annotierte Strecken-Visualisierungen zurückgab. Die Analyse-Oberfläche war dicht, präzise, anspruchsvoll.

Das Team hatte in einem agentischen Feature sogar die richtige Absicht ausgeliefert: Klick auf eine niedrig bewertete Dimension, und Punkte erscheinen auf der Strecke, die markieren, wo das Problem auftritt. Die Umsetzung hört auf halbem Weg auf. Die Punkte sind nicht beschriftet. Die Ansicht zoomt nicht. Der Nutzer muss die Kurve manuell finden und sie sich selbst vorlesen.

Der Agent hatte die Daten. Der Arbeitsbereich hatte keinen Agenten, der mit dem Nutzer darin nachdachte. Jede Oberfläche machte ein Stück der Aufgabe, die ein echter Race-Engineer in einem einzigen Gespräch erledigt.

Das Produkt hatte jede Zutat. Sie waren so architektonisch aufgebaut, als gehörten sie zu unterschiedlichen Produkten.

Die Umdeutung war eine einzige architektonische Festlegung. Die Web-App hört auf, ein Analysetool mit einem Chat-Panel zu sein. Sie wird zu einer KI-Agenten-Oberfläche, mit der Analyse-Ansicht als Arbeitsbereich, in dem der Agent operiert.

Nicht Chat-neben-Daten. Nicht drei Modi, zwischen denen der Nutzer wechselt. Drei Zustände eines einzigen, dauerhaft präsenten Agenten-Panels: ruhend, wenn der Nutzer eine Session öffnet und der Agent das Wort hat; untersuchend, wenn der Agent erzählt, während der Arbeitsbereich annotiert; erkundend, wenn der Agent zurücktritt und der Nutzer fährt.

Unter dieser Architektur sitzt die Verhaltensspezifikation. Ein Race-Engineer-Pattern, keine Chat-Persona. Diagnose vor Verschreibung. Eine primäre Korrektur pro Zyklus. Spezifität vor Allgemeinheit. Den Arbeitsbereich annotieren, nicht nur beschreiben. Eine Folgefrage vorschlagen, damit das Gespräch irgendwo hingehen kann.

Die Architektur ist kein Coaching-Tool, das ersetzt werden muss, wenn das nächste Modell kommt. Sie ist die Form des Gesprächs, das der Nutzer am Ende mit dem Produkt führen wird, wohin auch immer es wächst.

Das Pattern ist generalisierbar, aber Generalisierbarkeit braucht Beweise. Vier Archetypen ausgeliefert, jeder mit einer anderen Form von Frage, alle laufen in derselben Hülle.

Räumliche Fragen: Wo auf der Strecke passiert das? Der Agent zoomt die Leinwand, beschriftet die Momente durch eine Kurve, geht durch, was er sieht, und schlägt den nächsten Faden vor, an dem zu ziehen ist.

Zeitliche Fragen: Wo in der Session hat sich etwas verändert, und warum? Gleiche Architektur, andere Leinwand, andere unterstützende Daten, dasselbe untersuchende Pattern drumherum.

Verteilungs-Fragen: Wie konstant ist der Fahrer über die Session, und wo sollte er genauer hinschauen? Der Agent geht die Runde durch, zeigt zuerst, was funktioniert, bevor er das markiert, was nicht funktioniert, und übergibt dann die Tiefen-Navigation an den Nutzer.

Zustands-Entlang-Linie-Fragen: Was hat das Auto gemacht, als es sich durch diesen Moment bewegt hat? Eine andere Visualisierungsform, dieselbe Gesprächs-Hülle drumherum.

Die vier Archetypen waren der Beweis, nicht der Punkt. Der Punkt war, dass die Architektur die Art von Frage tragen kann, die die Produkt-Roadmap impliziert, für die es aber noch keine Oberfläche gibt.

Der Sinn, vier Archetypen auszuarbeiten, war nie, dass es vier sein sollten. Der Sinn war, dass eine Architektur halten kann, was auch immer das Produkt als Nächstes von ihr verlangt.