Wer beim Programmieren schon einmal richtig im Tunnel war, kennt das: Oben rechts ploppt die Kalender-Mitteilung auf, „Daily in 10 Minuten“. Ich nehme sie wahr, denke mir „ja, gleich“, schiebe sie weg – und tauche wieder ab in den Bug, den ich fast schon eingekreist habe. Zwanzig Minuten später fällt mir siedend heiß ein, dass da doch noch was war. Manchmal erscheint die Mitteilung auch, während ich gerade in einem ganz anderen Fenster stecke, und ich sehe sie schlicht nicht. Die Gründe wechseln, das Ergebnis bleibt dasselbe: Ich komme zu spät. Oder gar nicht.
Das Problem kennen sicherlich viele von euch. Also brauchte ich eine Lösung. Die Idee, die da bei mir aufkam: irgendetwas, das mich kurz vor dem Meeting direkt und sehr aufdringlich erinnert. So knapp vor dem Meeting, dass ich sofort beitreten will, aber noch mit so viel Puffer, dass ich von der Kaffeemaschine zurück an den Rechner sprinten kann. Gebaut hat ihn Claude Code, an zwei Abenden.
Die Idee: ein Wecker, der nicht aufgibt
Mein erster Prompt war im Grunde ein Wunschzettel, frei ins Mikrofon gesprochen. Sinngemäß stand da:
Ein paar Minuten später habe ich nachgeschärft: Die App soll eigenständig laufen, ohne Backend irgendwo. Sie soll kaum Systemressourcen brauchen – nicht alle zwei Minuten den Kalender abklappern, alle halbe Stunde muss reichen. Vielleicht, so meine vage Idee, kann der Kalender neue Termine ja auch von sich aus melden … ob das geht, wusste ich nicht. Der Ton soll möglichst laut sein, ich will ihn auf keinen Fall überhören. Und natürlich soll der Alarm nur losgehen, wenn der Rechner gerade aufgeklappt ist.
Das war’s. Kein Pflichtenheft, keine Architekturskizze. Wie man unter macOS an Kalenderdaten kommt oder die Systemlautstärke hochdreht, musste ich an dieser Stelle nicht wissen.
Die wichtigste Entscheidung: weglassen
Ursprünglich hatte ich an meinen Google-Kalender gedacht. Das hätte bedeutet: Google-API, OAuth, ein Cloud-Projekt, Tokens, Netzwerkcode. Claude schlug im Designgespräch etwas viel Einfacheres vor: Die App liest einfach den lokalen macOS-Kalender. Der synchronisiert meine Google-Termine ohnehin schon, warum das Rad also ein zweites Mal erfinden?
Damit ist auch die größte Einschränkung von alarmooh – so heißt das Ding – gleich benannt: Es läuft nur auf macOS, und es sieht nur die Termine, die in der Kalender-App des Macs landen. Für ein Produkt wäre das ein Ausschlusskriterium. Für mich ist es völlig egal, denn genau so arbeite ich.
Und das ist für mich die eigentliche Lektion des ganzen Projekts: Ein Tool, das ein Alltagsproblem lösen soll, muss am Anfang nicht alles können. Es muss mein Problem lösen, auf meinem Rechner, in meinem Setup. Ob ich irgendwann Windows, Outlook oder den Kalender der Kollegin brauche, kann ich später entscheiden; oder eben nie, weil es nie nötig wird. Die Google-API steht bis heute auf der Liste „bewusst weggelassen“.
Dieselbe Haltung zieht sich durch die anderen Punkte. Meine vage Idee mit dem Melden gab es tatsächlich: macOS sagt der App von sich aus Bescheid, wenn sich im Kalender etwas ändert. Die App stellt dann genau einen Timer auf den nächsten Alarm und tut dazwischen nichts, mein Halbstundentakt bleibt nur als Sicherheitsnetz. Und die Tokioter Bahnhofsmelodie? Die ist ein komponiertes, geschütztes Werk. Privat abspielen geht, ins Repository legen eher nicht. Also erzeugt die App ihren Ton selbst, im Code.
Wie das Ganze entstanden ist
Claude Code ist ein Coding-Agent: Er läuft im Terminal, schreibt den Code direkt auf meinem Rechner, führt ihn aus und testet ihn. Der Ablauf war erstaunlich unspektakulär. Erst haben Claude und ich das Design besprochen, dann hat Claude das Design-Dokument geschrieben und das Repo angelegt, danach einen Implementierungsplan mit fünfzehn Aufgaben. Meine Anweisung dazu: „mache Dinge gerne parallel, wenn das möglich ist“. Knapp eine Stunde nach dem ersten Prompt lag der Plan vor, noch am selben Abend die erste Version.
Am zweiten Abend kam der Feinschliff: die App richtig installieren, so wie ein anderes kleines Tool von mir, ein freundlicherer Alarm-Ton und alles, was mir beim ersten Ausprobieren aufgefallen war. Am nächsten Morgen um kurz vor zehn hat mich alarmooh dann zum ersten Mal an mein Daily erinnert.
Insgesamt waren es 35 Prompts, viele davon nicht länger als „passt“ oder „perfekt“. Am Ende stehen gut 3000 Zeilen Swift und knapp 90 automatisierte Tests. Meine Rolle war dabei weniger die des Entwicklers als die des Product Owners: sagen, was ich will, ausprobieren, meckern.
Wo es gehakt hat
Ganz glatt lief es natürlich nicht.
Der erste Wecker klang wie ein Feueralarm – für eine Alarm-App vielleicht konsequent, zwei Minuten vor dem Daily aber eher ein Herzinfarktrisiko. Also hat Claude mir ein paar Alternativen vorgespielt, bis ich „Nummer eins ist es“ sagen konnte: fünf sanft aufsteigende Töne. Dass mir ein Coding-Agent Klangvarianten vorspielt, hatte ich so auch noch nicht erlebt.
Kniffliger war ein Morgen drei Tage später. Nach einem macOS-Update meldete alarmooh plötzlich „Kein Kalenderzugriff“, obwohl die Systemeinstellungen den Zugriff als erlaubt anzeigten. Naheliegender Verdacht: das Update. Falsch gedacht. Den Fehler hatten wir uns selbst eingebrockt: Kurz vorher hatten wir die App gegen fremde Zugriffe abgesichert, und dafür muss sie ihren Kalenderzugriff ausdrücklich anmelden. Genau das fehlte. Beim Testen war es nicht aufgefallen, weil die App dabei aus dem Terminal lief und macOS die Anfrage dann dem Terminal zurechnet. Erst der Neustart hat den Fehler sichtbar gemacht. Die Ursache hat Claude selbst gefunden, die Lösung war eine einzige Zeile, und die Absicherung blieb erhalten.
Und die meisten Anforderungen kamen erst im Alltag. Ich bin schon fünf Minuten vor dem Meeting drin … dann soll natürlich nichts mehr klingeln. Der Termin jeden zweiten Freitag soll gar nicht klingeln. Ein Meeting, das seit einer Viertelstunde läuft, stand noch als „nächster Termin“ im Menü. Nichts davon stand in meinem ersten Prompt. Alles davon ist mir aufgefallen, weil ich die App benutzt habe.
Wie sich mein Alltag verändert hat
In meiner Menüleiste hängt jetzt eine kleine japanische Tempelglocke. Zwei Minuten vor einem Termin wird sie rot, die Lautstärke geht hoch, die Melodie läuft in Schleife, und unter dem Icon erscheint ein kleines Fenster mit dem Terminnamen und einem „Beitreten“-Knopf. Ein Klick, ich bin im Meeting, Ruhe. Und wenn ich einen Tag lang keine Unterbrechung will, pausiere ich die Alarme einfach.
Die zehn Minuten Vorlauf aus dem Kalender gibt es weiterhin. Aber zwei Minuten sind zu kurz, um es wieder zu vergessen. Und ein Ton, der nicht aufhört, lässt sich nicht einfach wegschieben.
Was ich daraus mitnehme
Erstens: Vorgaben machen, aber offen bleiben. Ich wollte den Google-Kalender und einen Halbstundentakt. Bekommen habe ich den lokalen Kalender und eine App, die sich von macOS Bescheid geben lässt. Beides besser als meine Idee, weil ich dazugesagt hatte, worauf es mir ankommt: kein Backend und möglichst ressourcenschonend.
Zweitens: So einfach wie möglich anfangen. macOS only, nur ein Kalender, keine Konten, keine Synchronisation. Erweitern kann ich immer noch, wenn ich merke, dass mir etwas fehlt.
Drittens: Benutzen und meckern. Die wirklich nützlichen Features kamen nicht aus dem ersten Prompt, sondern aus dem ersten Tag im Einsatz. Jede Kleinigkeit, die nervt, ist der nächste Prompt.
Das Ganze geht natürlich mit jedem Coding-Agent, nicht nur mit Claude Code. Swift hatte ich vorher noch nie verwendet. Die Hürde ist also nicht mehr, ob ich eine Sprache kann, sondern ob ich mein Problem gut genug beschreiben kann.
Fazit
Die meisten Alltagsprobleme brauchen keine Plattform, sondern ein kleines Tool, das genau eine Sache gut macht. Früher war der Aufwand, es selbst zu bauen, fast immer größer als der Leidensdruck. Heute reichen zwei Abende und eine gute Beschreibung. If you can dream it, you can Claude it.
Den Code von alarmooh gibt es auf GitHub: github.com/LorAutumn/alarmooh
Schreibe einen Kommentar