Sechs Werkzeuge auf meinem Schreibtisch, die du nicht kaufen kannst: was ich in acht Monaten mit Claude gebaut hab

Auf meinem Schreibtisch steht kein einziges Gerät, das noch so läuft, wie es geliefert wurde. Die Leiste am Monitor, der Roboter, die LED-Anzeige, der Zweitbildschirm, das Stream Deck und das Radio im Browser: alles in den letzten acht Monaten mit Claude gebaut oder umgebaut. Meine These: Wer heute eigene Tools mit Claude baut, bekommt nicht die billigere Version eines Produkts, sondern das Produkt, das es am Markt gar nicht gibt.

Ich arbeite seit 1989 in der Kommunikationsbranche und berate EPU und KMU zu KI, programmieren gelernt hab ich auf dem C64. Nach diesem Artikel weißt du, was jedes der sechs Projekte kann, wo es gehakt hat und wie du dein erstes eigenes Werkzeug angehst. Fangen wir bei der Frage an, warum ich überhaupt selbst baue.

Warum baue ich Werkzeuge, die es angeblich schon gibt?

Weil es sie eben nicht gibt. Es gibt Taskleisten-Tools, Statusseiten, Stream-Deck-Plugins und Desktop-Roboter. Aber keines davon weiß, dass meine n8n-Workflows auf einem eigenen Server laufen, dass mein Balkonkraftwerk in Home Assistant hängt und dass ich wissen will, ob Claude gerade arbeitet, ohne das Fenster zu suchen. Fertige Software ist für den Durchschnitt gebaut. Und den Durchschnitt gibt es an keinem einzigen Schreibtisch.

Was sich verändert hat, ist der Preis für das Passende. Früher hätte jedes dieser Projekte einen Entwickler und ein paar Wochen gekostet. Heute kostet es einen Abend, manchmal ein Wochenende, und die Bereitschaft, präzise zu beschreiben, was ich will. Genau darum geht es beim Vibe Coding, also Apps in Klartext zu bauen: Die Idee und die Qualitätskontrolle kommen von mir, das technische Handwerk von der KI.

Ich baue mir keine billigere Version von etwas, das es schon gibt. Ich baue mir das Werkzeug, das kein Hersteller für einen einzigen Schreibtisch in Salzburg entwickeln würde.

Alex Januschewsky

Umgesetzt hab ich die meisten Projekte mit Claude Code, einem Coding Agent, der nicht nur Vorschläge macht, sondern selbst baut, testet und Fehler sucht. Mein Teil bleibt trotzdem groß: entscheiden, was das Ding können soll, und merken, wann es das nicht tut.

Was zeigt die WinBar, was die Windows-Taskleiste nicht kann?

Die Leiste unten am Hauptbildschirm ist keine Windows-Taskleiste. Es ist eine schwebende, randlose Widget-Leiste, ursprünglich als macOS-App gebaut und im Juli nach Windows portiert, in C# mit WPF und .NET 8. Sie zeigt fünfzehn Widgets, die ich einzeln ein- und ausschalte und sortiere: Uhr, Datum, CPU, RAM und SSD als Ringe, Netzwerkdurchsatz, eine Erreichbarkeits-Ampel mit Latenz, Wetter, Sonnenauf- und -untergang, den nächsten Termin aus mehreren Kalender-Abos, einen Pomodoro-Timer, einen App-Starter, den Status von Home Assistant und meine Claude-Nutzung.

Das klingt nach Spielerei. Der Moment, der mich überzeugt hat, war ein anderer. Die Leiste zeigte eine PC-Laufzeit von mehreren Tagen, obwohl ich den Rechner jeden Abend herunterfahre. Grund: Der Schnellstart von Windows fährt den Kernel gar nicht wirklich herunter. Claude hat die Laufzeit danach aus dem Ereignisprotokoll gelesen, ab dem letzten echten Start oder Aufwachen. Diese Art Detail findest du in keinem fertigen Tool, weil sie nur jemanden stört, der genau hinschaut.

Ausgeliefert wird die WinBar als eine einzige exe-Datei mit rund 154 MB, ohne Installation. Doppelklick, läuft.

Wie wird aus einem Kickstarter-Roboter eine Assistentin mit Kopf?

Der kleine Roboter auf dem Monitorständer ist ein M5Stack StackChan, rund 110 Euro, von Kickstarter. Im Mai hab ich ihm über einen eigenen Server meine Assistentin Vinci beigebracht: österreichisch, frech, mit Zugriff auf Home Assistant, Kalender und Websuche. Wie das angefangen hat, steht im Artikel über neun Stunden Kampf mit meinem Desktop-Roboter. Damals bewegte sich der Kopf nicht, weil eigene Firmware unmöglich schien.

Im September stellte sich heraus: Die Diagnose war falsch. Gescheitert war ich an einer zu alten Version der Entwicklungsumgebung, die Firmware verlangte inzwischen eine neuere. Mit der passenden Version lief der Build auf Anhieb. Seither hört Vinci auf das Wort „Jarvis“, zeigt 21 animierte Augenpaare, bewegt den Kopf und verfolgt mein Gesicht über die eingebaute Kamera. Steh ich auf, sucht sie mich. Komm ich ins Büro, begrüßt sie mich. Fünfzehn Minuten vor einem Termin erinnert sie mich, außer ich sitze gerade in einem Call.

Ganz rund läuft es nicht. Die Gesichtserkennung stürzt gelegentlich ab, Ursache ist ein offener Fehler in der Bildverarbeitungsbibliothek esp-dl von Espressif. Ich hab die Rechenkerne so aufgeteilt, dass es deutlich seltener passiert. Weg ist es nicht. Die Firmware liegt öffentlich auf GitHub, damit andere daran weiterbauen können.

Wozu braucht ein Schreibtisch eine LED-Leiste mit 72 mal 16 Pixeln?

Hinter der Laufschrift mit dem roten Thermometer steckt eine BUSY Bar, ein Gerät mit 72 mal 16 RGB-LEDs und offener HTTP-Schnittstelle. Ab Werk zeigt sie im Wesentlichen an, ob du gerade beschäftigt bist. Bei mir zeigt sie 18 Module im Wechsel: Uhr, Termine, Wetter und Regenalarm, Temperaturen aus mehreren Räumen, PV-Leistung, Claude-Limits, einen RSS-Ticker, Fußballergebnisse. Jedes Modul kann auf Wunsch auch sprechen, mit einer österreichischen Stimme.

Geschrieben ist das Ganze in reinem Python ohne Zusatzpakete. Alle Daten kommen aus Home Assistant, die Leiste selbst rechnet nichts.

Hier ist, was ich dabei gelernt hab: Herstellerdokumentation ist oft ein Versprechen, keine Beschreibung. Wir haben mit Claude siebzehn Eigenheiten der Schnittstelle gefunden, die nirgends dokumentiert sind. Farben brauchen einen Alphawert, sonst kommt nur ein Fehler 400. Eine Füllfarbe an der falschen Stelle lässt die Firmware still hängen. Animationen liefern derzeit nur ein magentafarbenes Platzhalterquadrat. Jede dieser Erkenntnisse hat eine Stunde gekostet. Zusammen sind sie der Grund, warum die Leiste jetzt stabil läuft.

Was überwacht der PC Monitor, das kein fertiges Dashboard kann?

Das breite Display vor der Tastatur ist ein 10,3-Zoll-Zweitmonitor mit 1920 mal 720 Pixeln. Darauf läuft seit Ende September eine selbst gebaute Windows-App, im Grunde eine Leitstelle für alles, was ich betreibe: der letzte Fehler je aktivem n8n-Workflow, meine Websites mit Antwortzeit und Verfügbarkeit über sieben Tage, der Status von Claude, Gemini und Higgsfield, Geräte aus Home Assistant und die PV-Leistung. Gibt es ein neues Problem, kommt eine Windows-Benachrichtigung, ist es behoben, die nächste.

Zwei Entscheidungen machen den Unterschied zu einem Standard-Dashboard. Erstens fragt die App n8n pro Workflow ab, nicht global. Bei der globalen Abfrage blieben behobene Fehler stehen, weil der erfolgreiche Lauf aus dem Abfragefenster fiel. Zweitens gibt es keine falsche Entwarnung: Ist eine Statusseite nicht erreichbar, gilt ein Problem nicht als gelöst. Das klingt banal. Es ist genau der Fehler, der ein Monitoring wertlos macht.

Und ehrlich gesagt: Die Zugangsdaten für n8n und Home Assistant liegen derzeit unverschlüsselt in einer Konfigurationsdatei auf meinem Rechner. Für ein Werkzeug, das nur ich nutze, vertretbar. Auf meiner Liste steht es trotzdem.

Warum zeigt mein Stream Deck um sechs Uhr früh 0 Watt?

Weil es draußen noch dunkel ist. Mein Stream Deck Neo war früher ein reiner Programmstarter. Seit Anfang Oktober hat es ein eigenes Plugin mit vier Live-Tasten. Die erste zeigt, was Claude gerade tut: aus, bereit, arbeitet oder fertig, als Stern mit laufendem Ring. Gespeist wird sie aus sechs Hooks von Claude Code, die bei jedem Sitzungsereignis den Zustand in eine kleine Datei schreiben. Die zweite Taste prüft fünf Websites, die dritte zeigt die Leistung des Balkonkraftwerks als Tacho, die vierte die RAM-Auslastung.

Zwei Dinge hab ich dabei gelernt. Der Grafik-Renderer des Stream Decks zeichnet Text deutlich breiter als ein Browser. Was am Bildschirm drei Pixel Rand hatte, war am Gerät abgeschnitten. Die Lösung: Text als Vektorpfade, deren Breite das Plugin exakt kennt. Getestet wird seither am Gerät, nicht im Browser.

Der zweite Punkt hat mich mehr erschreckt. Beim Einrichten fiel auf, dass meine bestehenden Hooks auf diesem PC nie gelaufen sind, weil ein Windows-Pfad in der Shell nicht aufgelöst wurde. Darunter ein Sicherheits-Scan nach versehentlich eingefügten Zugangsdaten. Ich dachte, er schützt mich. Er hat keine einzige Zeile geprüft, und aufgefallen ist es niemandem. Ein Statuslicht auf einer Taste hat mir das gezeigt.

Wie läuft ein Radio, das niemand moderiert?

Das sechste Projekt sieht man nur auf dem Hauptbildschirm: digitalhandwerk Radio, ein Webradio ohne menschlichen Eingriff. Jede Nacht produziert ein Worker auf meinem Server die Sendung für den nächsten Tag. Ein KI-Moderator stellt alle rund fünfzehn Minuten einen Artikel aus diesem Blog vor, zur vollen Stunde laufen KI-Nachrichten aus fünf Fachmedien, einmal pro Stunde ein Interview mit einem bewusst namenlosen Gast. Dazwischen spielen 80 Titel aus meiner eigenen Suno-Produktion. Die Moderationen kosten mich rund 0,12 Dollar im Monat.

Ohne Freigabe durch mich braucht es eine andere Absicherung. Ein zweites Sprachmodell prüft jeden Beitrag gegen den Originalartikel, das klassische Grounding. Besteht ein Beitrag nicht, fällt er aus der Sendung. Lieber kürzer als eine falsche Behauptung unter meinem Namen.

Die teuerste Lektion des ganzen Projekts hab ich im Artikel über KI-Nachrichten im Webradio beschrieben: Ich ließ das Modell Zahlen für die Sprachausgabe ausschreiben. Aus 29 Märkten wurden zweiunddreißig, aus 12,9 Milliarden zwölfeinhalb. Jetzt schreibt das Modell Ziffern, und erst ein Stück normaler Code macht daraus Wörter.

Was haben sechs Projekte gemeinsam, das du für dein eigenes brauchst?

Ich würde es eigentlich anders formulieren, aber so trifft es den Kern: Keines der Projekte ist an der Programmierung gescheitert. Gehakt hat es immer an Annahmen. An einer falschen Diagnose beim Roboter, an einer Dokumentation, die nicht stimmte, an einem Test, der im Browser grün war und am Gerät nicht.

Drei Regeln hab ich mir daraus abgeleitet:

• Was berechenbar ist, gehört nicht ins Modell. Zahlen, Zeiten, Abstände rechnet Code, nicht die KI.
• Getestet wird dort, wo es laufen soll. Am Gerät, am echten Bildschirm, mit echten Daten.
• Ein Werkzeug darf nicht lügen. Lieber „weiß ich nicht“ anzeigen als grün.

Bin ich mir sicher, dass das für jedes Projekt gilt? Nicht ganz. Mein Eindruck nach acht Monaten ist aber, dass die meisten Abbrüche genau an diesen drei Stellen passieren.

Wie fängst du mit deinem ersten eigenen Tool an?

Nicht mit einem Roboter. Fang mit etwas an, das dich jeden Tag ein bisschen nervt. Ein Wert, den du immer in drei Apps suchst. Eine Statusseite, die du fünfmal am Tag öffnest. Vielleicht hast du sogar irgendwo einen API-Schlüssel, von dem du nichts weißt. So hat bei mir das Strom-Dashboard mit einem zufällig gefundenen API-Key angefangen.

Beschreib Claude dann nicht die Technik, sondern das Ergebnis: was du sehen willst, wann, und was passieren soll, wenn etwas schiefgeht. Die Technik schlägt Claude vor, und du fragst nach, warum. Das macht Sinn, weil du danach verstehst, was du betreibst.

Und ein Satz zur Sicherheit, weil er in den meisten Anleitungen fehlt: Sobald dein Werkzeug Zugangsdaten braucht, gehören sie nicht in den Code und nicht in einen öffentlichen Ordner. Lass Claude erklären, wo sie liegen, und prüf, ob deine Schutzmechanismen wirklich laufen. Meine haben es nicht getan, ohne dass ich es bemerkt hätte.

Häufige Fragen zu eigenen Tools mit Claude

Was steht als Nächstes auf dem Schreibtisch?

Eh klar, die Liste wird nicht kürzer. Die BUSY Bar soll über ihre eigenen Tasten bedienbar werden, Vinci braucht eine Gesichtserkennung, die nicht mehr abstürzt, und der PC Monitor braucht verschlüsselte Zugangsdaten. Schauen wir mal, was davon im nächsten Showcase steht.

Was ich dir mitgeben will: Das Werkzeug, das du dir wünschst, existiert vermutlich nicht. Du kannst warten, bis es jemand für den Durchschnitt baut. Oder du beschreibst es heute Abend Claude und hast es morgen früh auf deinem Schreibtisch.