Manchmal entstehen kleine Projekte nicht, weil man unbedingt etwas Neues
programmieren möchte, sondern weil einem im Alltag etwas fehlt. Genau so
war es bei meinem neuen KDE-Plasma-Widget für Uptime Kuma.
Ich betreibe bereits seit einiger Zeit Uptime Kuma, um verschiedene
Server und Anwendungen zu überwachen. Wenn irgendwo etwas ausfällt,
bekomme ich eine entsprechende Benachrichtigung in Discord.
Das funktioniert grundsätzlich gut. Allerdings kann eine
Discord-Nachricht auch einmal untergehen. Gerade wenn man nebenbei viele
andere Nachrichten bekommt, ist schnell eine Meldung übersehen.
Da ich den größten Teil des Tages an meinem KDE-Desktop arbeite, kam mir
deshalb eine einfache Idee: Warum sehe ich den aktuellen Zustand
meiner Systeme nicht direkt auf meinem Desktop?
Gibt es dafür nicht schon ein Widget?
Bevor ich selbst etwas baue, habe ich natürlich erst einmal gesucht.
Meine Vorstellung war eigentlich ziemlich simpel: Ein Plasma-Widget
verbindet sich mit meiner bestehenden Uptime-Kuma-Instanz und zeigt mir
auf einen Blick, ob meine Server und Anwendungen erreichbar sind.
Ich habe allerdings kein vorhandenes Widget gefunden, das meinen
Vorstellungen entsprach.
Ganz unbekannt war mir die Entwicklung von Plasma-Widgets dabei nicht.
Vor vielen Jahren hatte ich bereits selbst ein KDE-Plasmoid geschrieben.
Damals natürlich noch ganz klassisch und ohne KI-Unterstützung.
Das Wissen darüber war inzwischen allerdings ziemlich eingerostet.
Gleichzeitig machte genau das die Sache für mich interessant.
Ein guter Anlass, Antigravity CLI auszuprobieren
Ich wollte Antigravity CLI ohnehin einmal intensiver an einem echten
Projekt ausprobieren. Bis dahin hatte ich nur einen kleinen Teil meines
verfügbaren Token-Volumens verwendet.
Also dachte ich mir: Warum nicht?
Das Projekt hatte dafür eine angenehme Größe. Es war kein künstliches
„Hello World", sondern etwas, das ich anschließend tatsächlich verwenden
wollte. Gleichzeitig war es überschaubar genug, um zu beobachten, wie
gut ein Coding Agent mit einem solchen Projekt zurechtkommt.
Zusätzlich wollte ich ausprobieren, wie sich ein schnelles
Gemini-Flash-Modell bei einer solchen agentischen Coding-Aufgabe
schlägt.
Damit wurde aus dem kleinen Widget gleichzeitig ein Experiment:
Wie weit komme ich mit Antigravity CLI und einem schnellen
Flash-Modell bei einem echten KDE-Plasma-Projekt?
Von null zum ersten Widget
Ich habe bei null angefangen.
Natürlich hatte ich durch mein altes Plasma-Widget eine ungefähre
Vorstellung davon, wie ein Plasmoid aufgebaut ist. Die konkrete
Umsetzung für ein aktuelles Plasma 6 hatte ich aber nicht mehr präsent.
Das war für mich auch ein wichtiger Teil des Experiments. Ich wollte
nicht erst stundenlang Dokumentation lesen und mir den aktuellen
KDE-Stack wieder komplett erarbeiten. Stattdessen sollte Antigravity
einen großen Teil dieser Arbeit übernehmen.
Relativ schnell entstand eine erste funktionierende Version.
Von da an bestand die Arbeit vor allem aus Iterationen: Widget
ausprobieren, Problem entdecken oder eine neue Idee haben, Antigravity
beschreiben, was geändert werden soll, und anschließend das Ergebnis
erneut testen.
Genau bei diesem Ablauf fand ich den Einsatz eines Coding Agents
besonders interessant.
Die Git-Historie zeigt die Geschwindigkeit ganz gut
Die gesamte Session habe ich nicht mit einer Stoppuhr gemessen. Wenn ich
sie rückblickend zusammenrechne, waren es ungefähr zwei Stunden.
Einen Teil davon kann man anhand der Git-Historie ziemlich gut
nachvollziehen.
Der erste heute sichtbare Commit entstand um 20:13 Uhr. Zu diesem
Zeitpunkt war allerdings bereits einiges passiert und das Widget
grundsätzlich vorhanden. Ich hatte ungefähr eine Stunde vorher
angefangen.
Danach ging es Schlag auf Schlag.
Innerhalb von nur 43 Minuten entstanden elf Commits. Dabei ging es
längst nicht mehr nur darum, überhaupt Daten auf dem Desktop anzuzeigen.
Unter anderem wurden Probleme mit der Plasma-6-Kompatibilität behoben,
Redirect-Handling und Gruppenfilterung verbessert, verschachtelte
Monitor-Gruppen berücksichtigt und verschiedene Darstellungsoptionen
ergänzt.
Ein schönes Beispiel dafür ist der Header-only-Modus. Die Funktion wurde
ergänzt, ausprobiert und wenige Minuten später direkt noch einmal
korrigiert.
Das beschreibt meinen tatsächlichen Workflow mit Antigravity ziemlich
gut:
Idee → umsetzen lassen → ausprobieren → Problem entdecken → Feedback
geben → korrigieren lassen → nächste Idee.
Nicht nur ein Proof of Concept
Was mich dabei selbst etwas überrascht hat: Nach diesen ungefähr zwei
Stunden hatte ich nicht einfach nur einen technischen Prototyp.
Das Widget war bereits etwas, das ich tatsächlich auf meinem Desktop
einsetzen konnte.
Es zeigt den Zustand der über Uptime Kuma überwachten Dienste,
Antwortzeiten und Uptime-Werte an. Die Monitore können nach Gruppen
dargestellt werden und über Heartbeat-Balken lässt sich auch der Verlauf
erkennen.
Für unterschiedliche Einsatzorte gibt es verschiedene Darstellungen. Auf
dem Desktop kann ich beispielsweise eine ausführlichere Übersicht
verwenden, während sich das Widget im Plasma-Panel deutlich kompakter
darstellen lässt.
Auch mehrere Widget-Instanzen mit unterschiedlichen Monitor-Gruppen sind
möglich.
Man kann das Widget auch in eine Panel (Leiste) klein einfügen:
Dazu kamen im Laufe der Entwicklung noch Dinge, die ich am Anfang gar
nicht unbedingt auf meiner Liste hatte: Suche und Filterung,
unterschiedliche Anzeigevarianten, KDE-Benachrichtigungen bei Ausfällen
und Wiederherstellungen sowie verschiedene Möglichkeiten zur
Authentifizierung gegenüber Uptime Kuma.
Aus einer relativ einfachen Idee wurde damit erstaunlich schnell ein
ziemlich vollständiges Plasma-Widget.
Der Coding Agent ersetzt nicht das Ausprobieren
Interessant fand ich dabei vor allem, wie sich meine eigene Arbeit
verändert hat.
Ich musste nicht jede QML-Komponente und jede Plasma-6-API selbst
recherchieren und implementieren. Meine Aufgabe bestand viel stärker
darin, das Ergebnis zu beurteilen.
Funktioniert das wirklich? Sieht das auf dem Desktop sinnvoll aus?
Welche Informationen fehlen? Was verhält sich anders als erwartet?
Welche Funktion möchte ich als Nächstes haben?
Gerade bei einem visuellen Projekt kann der Agent diese Bewertung nicht
vollständig übernehmen.
Ich musste das Widget immer wieder starten und tatsächlich benutzen.
Wenn etwas nicht funktionierte oder mir nicht gefiel, konnte ich
Antigravity aber ziemlich konkret beschreiben, was geändert werden
sollte.
Dadurch entstand eine sehr schnelle Feedback-Schleife.
Zwei Stunden sind natürlich nicht die ganze Geschichte
„In zwei Stunden entwickelt" klingt schnell danach, als würde die KI die
komplette Arbeit erledigen und man selbst nur daneben sitzen.
So würde ich es nicht beschreiben.
Ich wusste, welches Problem ich lösen wollte. Ich konnte beurteilen, ob
die vorgeschlagene Lösung sinnvoll ist. Durch mein früheres
Plasma-Widget hatte ich zumindest ein grundsätzliches Verständnis davon,
was dort passiert. Und vor allem habe ich während der gesamten
Entwicklung entschieden, was als Nächstes passieren soll.
Antigravity hat mir allerdings sehr viel Implementierungsarbeit und
Recherche abgenommen. Ich habe bewusst kein Agentic Engineering betrieben sondern nebenbein ein bisschen Vibe-Coding gemacht um zu sehen wie weit man auch ohne große Vorkentnisse kommen kann.
An der Konfiguration habe ich mit dem Agenten einiges iterativ optimieren lassen.
Das kann sich glaube ich auch sehen lassen:
Und genau dadurch konnte aus einer Idee, die ich ansonsten vielleicht
auf irgendeine TODO-Liste geschrieben hätte, innerhalb eines Abends ein
Werkzeug werden, das ich tatsächlich benutze.
Mein Fazit
Für mich war das Projekt ein ziemlich guter Test für agentisches Coding.
Nicht weil das Ergebnis besonders riesig oder komplex wäre, sondern
gerade weil es ein echtes kleines Alltagsproblem löst.
Ich brauchte ein Uptime-Kuma-Widget für meinen KDE-Desktop. Ich fand
keines, das meinen Vorstellungen entsprach. Also habe ich Antigravity
CLI gestartet und ausprobiert, wie weit ich damit komme.
Ungefähr zwei Stunden später hatte ich ein Widget auf meinem Desktop,
das meine Server und Anwendungen überwacht und mich sofort erkennen
lässt, wenn irgendwo etwas nicht stimmt.
Dass dabei ein schnelles Gemini-Flash-Modell ausgereicht hat, um mich
durch QML, Plasma 6, Uptime Kuma und zahlreiche kleine Iterationen zu
begleiten, fand ich mindestens genauso interessant wie das eigentliche
Widget.
Das Experiment hat für mich deshalb vor allem eines gezeigt: Coding
Agents machen eigene Ideen nicht automatisch gut. Aber sie können die
Strecke zwischen „Das wäre eigentlich praktisch" und „Das läuft
jetzt auf meinem Rechner" erstaunlich kurz machen.
Den Quellcode des Widgets habe ich auf GitHub veröffentlicht.
https://github.com/muench-dev/uptime-kuma-plasma-widget
Das Widget ist inzwischen auch direkt über den KDE-Store installierbar: