A field trip into vibe coding: The SpaceCadetDeck

The idea practically presented itself. After moving and setting up my workspace, I rediscovered my Stream Deck. While it mostly worked, it had constant quirks. The old software is no longer compatible with my system, and the new one, though functional, often dies after my PC goes into deep sleep. Not ideal.

So, I sat down to solve both my Stream Deck problem and learn AI - by building my own solution: the SpaceCadetDeck.

I didn’t want to dive deep into Stream Deck tech, though. Instead, I repurposed my Fairphone 6 (running /e/OS) as a touch-based 4x8 button grid. It’s portable, customizable with icons, labels, and colors, and perfect for the job.

Now, as mentioned earlier, I don’t know Android programming at all. I’ve looked into it before and found that you practically need to know Java for it. A language I could learn, but don’t really like the style of. At some point, I read about a language called Kotlin. With which you can also program this. I looked into it more closely. As a language, I prefer it more, so I decided to learn Kotlin.

But before I learn it, I’m diving into the biggest of the small individual experiments. I want to create a Kotlin project using AI that somehow turns my phone into a Stream Deck. Without me writing a single line of Kotlin myself. That means I can’t control the AI at this point and have to trust it to do the right thing. I give it relatively free rein. I check every command it wants to execute beforehand so it doesn’t mess up my system. But content-wise, I know absolutely nothing and can’t judge what it’s doing except by looking at the result.

The program running on the phone should be relatively simple. It receives a button layout for the 32 buttons it should display from a server on the PC and simply reports back to the server which of these buttons were pressed. So only two tasks: receive layout, send button presses. Everything else happens on the PC that is being controlled.

The AI I chose was Matrix-Vibe. Simply because, unlike many others, it’s a European product, and I can get an insight into the state of the art on my continent.

On the other side, I wanted to create a project in a language I’m familiar with so I can look at the generated code and assess how its quality compares to what I would write myself. That’s why I chose Python for the server, and this server called DeckServer has a few more tasks.

• It provides a WebSocket server for the Android system client to connect to.
• It receives button presses from the Android client and performs the appropriate tasks based on the previously sent layout, such as starting programs, switching layouts, switching to windows, adjusting volume, etc.
• And most importantly, of course, it has to send the configured layouts to the Android client.

I developed both projects in parallel, each in a separate window.

The Android client is very straightforward based on the requirements: I’d like 4x8 buttons. I want to receive the layout and send button presses - all via WebSocket, which I’d like to be configurable at startup. I also want these settings to be remembered between program starts. After a net time of about 45 minutes, it was developed to the point where I could install it on my phone, and it worked right away.

The server’s requirements are naturally a bit more extensive, and I also sought more advice on individual points. The WebSocket connection was changed to a secure connection. For debugging purposes, I added the ability to send the USR1 signal to the server to force it to resend its layout. I also thought about how to configure the button layouts. All in all, it took about four hours.

Then I slept on it overnight, thinking about how I could configure the button layout. I came up with the idea of not writing a program for it at all but storing all layouts in a configuration file. If I write this configuration file in Org-mode - which is built into Emacs, which I already use - then I can simply write the button layout as a table directly in the configuration file.

In the next coding session, I worked with Matrix Vibe to build the exact format of this config.org file. Additionally, I had the code generated that is needed to parse this file format.

The file then looked something like this:

* Global
:PROPERTIES:
:Port:: 8766    
:Host:: 0.0.0.0
:UseSSL:: True
:CertFile::
:KeyFile::
:GenerateCert:: True
:PingInterval:: 20
:PingTimeout:: 60
:END:

** Buttons

*** Home
:PROPERTIES:
:Label: Home    
:Image:    
:Actions: Layout, Dance,Execute  
:Parameters: Home,, Programname
:Color: #FF0000
:END:


*** Bäh
:PROPERTIES:
:Label:    
:Image:    
:Actions: Activate  
:Parameters: Terminal
:Color:
:END:


* Layouts
** Home                                         :default:

|------+------+---+------+-----+---+---+------|
| Home | Link |   | Helm |     |   |   |      |
|------+------+---+------+-----+---+---+------|
|      |      |   | Bumm |     |   |   |      |
|------+------+---+------+-----+---+---+------|
|      |      |   |      | Bäh |   |   |      |
|------+------+---+------+-----+---+---+------|
|      |      |   |      |     |   |   | Test |
|------+------+---+------+-----+---+---+------|

*** Link
:PROPERTIES:
:Label:    
:Image:    
:Actions:   
:Parameters:
:Color:
:END:

*** Helm
:PROPERTIES:
:Label:    
:Image:    
:Actions: Layout  
:Parameters: Emacs
:Color:
:END:

You can already see how easy it is to create a layout here. Emacs helps you keep the table in a nice rectangular format.

After two coding sessions with a total of around 8 to 10 hours, both the server and client were ready for use.

Apart from the fact that some more functions still need to be added to the server, such as D-BUS capability so I can detect context changes in the system and display other layouts accordingly, the software is largely finished.

Now I’ll sit down and take a closer look at both the generated Python code and the generated Kotlin code. The Python code mainly for quality, style, and similar things, the Kotlin code to learn myself how such programs are structured, how they work. Which files I need and how they all work together.

The agent was an incredible help when it came to documenting the entire project. The README was automatically generated for my Git repository. I could have the commit messages generated and all changes were listed without missing a single one.

I can definitely understand why Vibe-coding is so appealing. Fast results when you’re able to describe your project precisely. From experience I’ve had with project managers so far, though, I have to say that’s exactly why you need a programmer for it.

I’m of course aware of the technical and social implications of AI, and each one is enough to deter me from professional use. In the long term, though, I think the problem will solve itself economically. And whether my talent as a normal programmer will still be in demand then remains to be seen.