Computer, ...

TL;DR: Modern language models make it possible to interact with computers almost like in Star Trek. Instead of complicated programs, a chatbot could manage members, import data, and generate reports. This makes tasks simpler because you only need to describe what you need in plain language. Whether this is actually more reliable and productive than traditional interfaces in everyday use remains to be seen.

🔗 Source code for my experiment: https://codeberg.org/gurix/clubber

From Science Fiction to Breakthrough: How Language Models Are Revolutionizing Computer Interaction

Since my childhood, I’ve been captivated by Star Trek: The Next Generation. The interaction with the ship’s computer in natural language was one of the aspects that fascinated me and that I remember well. With the keyword “Computer, …” the crew could engage in dialogue with the system, for example to query analyses of the ship’s status, scan for life forms, or contact other crew members.

For me, this was science fiction until recently. While there were always attempts to build such voice assistants – one of the first I experimented with back in 2003 was A.L.I.C.E. – not even Siri, Alexa and Co. were truly usable by my standards. Then came the breakthrough with the first public language model from OpenAI. Suddenly it was possible to interact with the computer even in complex language. For me, it already feels almost a bit like talking to the ship’s computer, perhaps even somewhat more natural – in Star Trek, the voice interface was operated less in dialogue and more in command form.

Why Chatbots Could Be the Better User Interface

Since language models have interfaces with tools and can essentially communicate with the outside world, I’ve been wondering whether you couldn’t simply use this to effectively build a productivity application. Why do I need a complex user interface when I can just talk to a chatbot and manage the data that way? This has several advantages. You don’t have to create a UI, but can focus entirely on data management. Users don’t have to learn the system visually, study dialogs and interfaces, or worry about the “correct” workflow. On the contrary: the system thinks along and assists with the work. The input language is irrelevant; I can even operate the system in Swiss German with an Appenzell dialect. Minor linguistic errors are recognized and compensated for. However, you don’t actually find completely dialog-based operation of business applications. While Microsoft builds a Copilot into every product, when you call it up in Teams, it can’t access chats, and Outlook can’t write emails either – at least not when I last tried it in fall 2025.

A Very Simplified Dialog-Based Member Management System as an Experiment

For over a year now, I’ve been asking myself whether you could build such a dialog-based application – and how. At first, I toyed with the idea of testing it with the online registration form for the playgroup in the village: so that you simply talk to a chatbot that asks all the questions to parents who want to register their child. Back then I tried it with ChatGPT and the tools functions. However, the implementation was too complex and time-consuming for me.

With the current models and the Model Context Protocol (MCP) developed by Anthropic, new possibilities are emerging. Time for a second attempt. This time I chose a simple scenario: member management. The code for this experiment can be found at https://codeberg.org/gurix/clubber. The idea is that you take the model and chatbot of your choice that supports MCP calls and use it to operate the database interface. As a first step, I defined a simple table for members in a SQLite database. The database can be replaced later, for example with PostgreSQL. The MCP server is not directly connected to the database, but communicates with a GraphQL API, which in turn executes the database operations. This has the advantage that you could easily connect another application, such as a web application, to the API at a later time. GraphQL also has the advantage that the schema is documented at all times and can be made available to a chatbot again via MCP to define queries itself.

The Brave New World with Many Possibilities?

Now some very concrete applications are conceivable that would not be possible or only difficult to implement with a traditional user interface if you consistently optimize them for voice interaction:

• “Attached is an Excel list of members to be entered. Open the list and save it to the database.”
• “Export me a CSV list with email address and last name of members who were registered in the last 6 months. Since we don’t record gender, try to define the salutation based on the first name. If this is not possible, choose a neutral salutation with first and last name. The final CSV list should contain: creation date, salutation, last name, email address.”
• “Count how many members are distributed across Switzerland by canton. Which canton has the most members?”

With this, we’re already very close to the example of verbal communication with the ship’s computer of the Starship Enterprise.

But is this also practical in reality? Does it result in a productivity gain, and how reliable is the collaboration? These are questions that we will hopefully get answers to soon. Personally, I see it as motivating, because in the long run, people find it more pleasant to discuss and work together with someone on equal footing than to click through anonymous interfaces.