Computer, …

TL;DR: Moderne Sprachmodelle machen es möglich, mit dem Computer fast wie in Star Trek zu diskutieren. Statt komplizierter Programme könnte ein Chatbot die Mitglieder verwalten, Daten importieren und Auswertungen machen. So werden Aufgaben einfacher, weil man nur noch in klarer Sprache beschreiben muss, was man braucht. Ob das im Alltag wirklich zuverlässiger und produktiver ist als klassische Oberflächen, muss sich erst noch zeigen.

🔗 Source Code zu meinem Experiment: https://codeberg.org/gurix/clubber

Vom Science-Fiction zum Durchbruch: Wie Sprachmodelle die Computer-Interaktion revolutionieren

Seit meiner Kindheit hat mich die Serie Star Trek: The Next Generation in den Bann gezogen. Die Interaktion mit dem Bordcomputer in menschlicher Sprache war einer der Aspekte, die mich faszinierten und an die ich mich gut erinnere. Mit dem Stichwort „Computer, …" konnte die Besatzung mit dem System in Dialog treten, um beispielsweise Analysen des Schiffszustands abzufragen, nach Lebensformen zu scannen oder eine andere Besatzung zu kontaktieren.

Für mich war das bis heute Science-Fiction. Zwar gab es immer mal wieder Versuche, solche Sprachassistenten zu bauen – eines der ersten, mit denen ich anno 2003 herumexperimentiert habe, war A.L.I.C.E. – aber wirklich brauchbar waren meinem Gusto nach nicht einmal Siri, Alexa und Co. Mit dem ersten öffentlichen Sprachmodell von OpenAI kam nun der Durchbruch. Plötzlich war es möglich, selbst in komplexer Sprache mit dem Computer zu interagieren. Es fühlt sich für mich schon fast ein bisschen wie das Sprechen mit dem Bordcomputer an, vielleicht sogar etwas natürlicher – in Star Trek wurde das Sprachinterface weniger im Dialog, sondern eher in Befehlsform bedient.

Warum Chatbots die bessere Benutzeroberfläche sein könnten

Seit Sprachmodelle Schnittstellen mit Tools besitzen und sozusagen mit der Aussenwelt kommunizieren können, frage ich mich, ob man das nicht auch einfach nutzen kann, um effektiv eine Produktivitätsanwendung zu bauen. Wieso brauche ich eine komplexe Bedienungsoberfläche, wenn ich auch einfach mit einem Chatbot sprechen kann und so die Daten verwalte? Das hat einige Vorteile. Man muss keine UI erstellen, sondern kann sich ganz auf die Verwaltung der Daten konzentrieren. Die Anwender müssen das System nicht visuell erlernen, keine Dialoge und Oberflächen studieren und sich nicht um den „richtigen" Arbeitsablauf kümmern. Im Gegenteil: Das System denkt mit und assistiert bei der Arbeit. Die Sprache der Eingabe ist irrelevant, ich kann das System sogar auf Schweizerdeutsch mit Appenzeller Dialekt bedienen. Kleinere sprachliche Fehler werden erkannt und ausgeglichen. Die komplett dialogbasierte Bedienung von Business-Applikationen findet man aber eigentlich nicht. Zwar verbaut Microsoft in jedem Produkt einen Copilot, aber wenn man das Ding in Teams aufruft, kann es nicht auf die Chats zugreifen, und Outlook kann auch keine Mails schreiben – zumindest nicht, als ich es im Herbst 2025 das letzte Mal versucht habe.

Ein sehr vereinfachtes dialogbasiertes Mitgliederverwaltungssystem als Experiment

Nun frage ich mich seit etwas über einem Jahr immer wieder, ob man so eine dialogbasierte Anwendung bauen könnte – und wie. Zuerst spielte ich mit dem Gedanken, es mit dem Online-Anmeldeformular für die Spielgruppe im Dorf zu testen: Also, dass man einfach mit einem Chatbot redet, der den Eltern, die ihr Kind anmelden wollen, alle Fragen stellt. Damals versuchte ich es mit ChatGPT und den Tools-Funktionen. Die Implementation war mir aber zu komplex und langwierig.

Mit den aktuellen Modellen und dem von Anthropic entwickelten Model Context Protocol (MCP) ergeben sich nun neue Möglichkeiten. Zeit für einen zweiten Anlauf. Diesmal habe ich ein simples Szenario gewählt: eine Mitgliederverwaltung. Der Code für dieses Experiment findet sich unter https://codeberg.org/gurix/clubber. Die Idee ist, dass man das Modell und den Chatbot seiner Wahl nimmt, der MCP-Calls unterstützt, und damit die Schnittstelle zur Datenbank bedient. In einem ersten Schritt habe ich eine simple Tabelle für Mitglieder in einer SQLite-Datenbank definiert. Die Datenbank kann später ausgetauscht werden, beispielsweise mit PostgreSQL. Der MCP-Server ist nicht direkt mit der Datenbank verbunden, sondern kommuniziert mit einer GraphQL-API, die ihrerseits die Datenbankoperationen ausführt. Dies hat den Vorteil, dass man zu einem späteren Zeitpunkt auch problemlos eine andere Applikation, beispielsweise eine Webapplikation, an die API anbinden könnte. GraphQL hat darüber hinaus den Vorteil, dass das Schema jederzeit dokumentiert ist und wieder via MCP einem Chatbot zur Verfügung gestellt werden kann, um selbst Abfragen zu definieren.

Die schöne neue Welt mit vielen Möglichkeiten?

Nun sind einige ganz konkrete Anwendungen denkbar, die so mit einem klassischen User Interface nicht oder nur schwer umsetzbar wären, wenn man sie konsequent auf Sprachinteraktion optimiert:

• „Im Anhang befindet sich eine Excel-Liste mit Mitgliedern, die zu erfassen sind. Öffne die Liste und speichere diese in der Datenbank."
• „Exportiere mir eine CSV-Liste mit E-Mail-Adresse und Nachname der Mitglieder, die in den letzten 6 Monaten erfasst wurden. Da wir das Geschlecht nicht erfassen, versuche anhand des Vornamens die Anrede zu definieren. Ist dies nicht möglich, wähle eine neutrale Anrede mit Vor- und Nachname. Die finale CSV-Liste soll beinhalten: Erstelldatum, Anrede, Nachname, E-Mail-Adresse."
• „Zähle, wie viele Mitglieder über die Schweiz nach Kantonen verteilt sind. In welchem Kanton leben die meisten Mitglieder?"

Damit sind wir dem Beispiel mit der verbalen Kommunikation mit dem Bordcomputer des Raumschiffs Enterprise schon sehr nahe.

Doch ist dies in der Realität auch praktikabel? Ergibt sich daraus ein Produktivitätsgewinn, und wie zuverlässig ist die Zusammenarbeit? Das sind Fragen, die wir hoffentlich bald beantwortet bekommen. Ich persönlich sehe es als Motivation, denn Menschen finden es auf Dauer angenehmer, mit jemandem auf Augenhöhe zu diskutieren und zusammenzuarbeiten, als anonyme Oberflächen durchzuklicken.