PullMD Teil 2: Vom Spec zum laufenden Container – Einfach erklärt

Im ersten Teil hatte ich aufgeschrieben, was das Werkzeug können soll. Architektur durchdacht, Schnittstellen geklärt, Kommentarformat entschieden. Eine vollständige Spezifikation, quasi ein Bauplan.

Am Abend des 2. März habe ich das alles an Claude Code weitergegeben. Claude Code ist eine Software, mit der man sich unterhalten kann und die dann Programmcode schreibt. Meine Erwartung: der Assistent fängt an, die eigentliche Arbeit zu programmieren. Also den Teil, der Reddit aufruft, die Texte herausholt und in sauberes Markdown verwandelt. Markdown ist ein einfaches Textformat: Text mit Struktur, aber ohne Schnickschnack.

Was stattdessen passierte: Es schrieb zuerst vier Tests. Kein Server, keine Reddit-Logik. Nur Tests.

Was ein Test ist

Ein Test ist eine kleine Prüfvorschrift. Er legt vorher fest, was bei einer bestimmten Eingabe herauskommen soll. Man kann sich das vorstellen wie beim Hausbau: Erst schreibt man auf, wie hoch die Türen sein müssen und wo die Fenster sitzen sollen. Dann wird gebaut. Und am Ende prüft man gegen die Liste.

Normalerweise baut man erst und testet danach. Hier war es andersherum: die Prüfvorschriften standen, bevor auch nur eine Zeile vom eigentlichen Programm existierte.

Was die vier Tests prüften

Die Tests deckten genau das ab, was später die Architektur des Werkzeugs ausmachen sollte:

Werden die eingegebenen Reddit-Adressen sauber aufbereitet?
Kann das Werkzeug Reddit-Daten abrufen? (Geprüft mit Beispieldaten, ohne wirklich bei Reddit anzuklopfen.)
Funktioniert der Notfall-Plan, falls Reddit den schnellen Weg blockiert?
Klappt das Ganze auch mit einem echten Reddit-Aufruf?

Die Tests beschrieben also nicht einfach „ein Werkzeug, das Reddit holt“. Sie beschrieben ein Werkzeug mit mehreren Ausweichstufen, das vorher die Adressen aufräumt und schnelle Prüfungen klar von langsamen trennt. Die Architektur stand damit im Grunde schon fest, bevor die eigentliche Programmierung begann.

Warum das kein Zufall war

In den Protokollen dieser Nacht kann man nachvollziehen, was Claude Code eigentlich gemacht hat. Es lief ja nicht ein einziger großer Durchlauf. Die Arbeit war in eine Kette aus mehreren Schritten zerlegt:

Die Spezifikation wurde in nummerierte Aufgaben aufgeteilt: „Aufgabe 1: Grundlagen einrichten“, „Aufgabe 2: Adress-Aufbereitung“, „Aufgabe 3: Weiterleitungen auflösen“ und so weiter.
Für jede Aufgabe wurde ein frischer Helfer gestartet. Der bekam nur seine eigene Aufgabenbeschreibung, nicht den ganzen Rest.
Jeder Helfer hatte eine klare Anweisung: zuerst einen Test schreiben, der fehlschlägt. Dann das Minimum bauen, damit der Test besteht.
Nach jeder Aufgabe prüfte ein weiterer Helfer, ob das Ergebnis tatsächlich der Spezifikation entspricht.

In den Protokollen steht ziemlich genau, was jeder Helfer als Briefing bekam:

You are implementing Task 2: URL Normalization Module … with TDD

(Auf Deutsch etwa: „Du setzt Aufgabe 2 um: das Modul für die Adress-Aufbereitung. Mit Tests zuerst.“)

Das war also kein Geistesblitz des Assistenten. Der Arbeitsablauf selbst hat „Tests zuerst“ in jedem einzelnen Schritt erzwungen.

Der Container

Noch in derselben Nacht wanderte der Dienst in einen Container. Ein Container ist in der Software-Welt ein abgeschlossenes Päckchen. Das Programm läuft darin zusammen mit allem, was es braucht. Man kann so ein Päckchen auf jeden beliebigen Server stellen, und es läuft sofort, ohne dass dort vorher irgendetwas eingerichtet werden müsste.

Der Container für dieses Werkzeug war klein und schlicht. Er musste nur drei Dinge können: Reddit-Daten abrufen, Text umwandeln, Ergebnis ausgeben. Dazu kam eine Konfiguration, die dem Server sagt: „Mach den Dienst unter einer bestimmten Adresse erreichbar und kümmere dich um das Sicherheitszertifikat.“ Das ist derselbe Aufbau, den ich auch für meine anderen selbst betriebenen Dienste verwende. Container starten, und er läuft.

Die Handy-Variante

Die PWA (Progressive Web App) war schon in derselben Nacht dabei. Und genau für diesen Teil hatte ich das Werkzeug eigentlich gebaut. Eine PWA ist eine Webseite, die sich auf dem Handy wie eine echte App verhält. Man installiert sie, und sie bekommt ein eigenes Symbol auf dem Startbildschirm.

Das Entscheidende hier war das Teilen-Menü. Sobald die PWA installiert ist, taucht sie im Android-Teilen-Menü auf, dort, wo sonst WhatsApp, Signal und die anderen Apps stehen. Ein kleiner Eintrag in den PWA-Einstellungen sagt dem Handy: „Wenn jemand einen Link mit mir teilt, nimm ihn entgegen und starte die Verarbeitung.“ Mehr braucht es nicht.

In der Praxis: Reddit-App öffnen, einen Beitrag aufrufen, auf „Teilen“ tippen. Das Werkzeug erscheint als Ziel. Antippen, kurz warten. Sauberer Text auf dem Bildschirm. Kopier-Knopf. Fertig.

Der Aha-Moment auf dem Handy

Ich weiß noch ziemlich genau, wann es zum ersten Mal vollständig funktioniert hat. Ich hatte in der Reddit-App einen längeren Thread geöffnet, über den ich mit Claude reden wollte. Also auf „Teilen“ getippt, das Werkzeug ausgewählt. Und dann stand da einfach der saubere Text. Kein Cookie-Banner, keine Seitenleiste. Nur der Beitrag und die Kommentare, eingerückt nach Antwort-Tiefe.

Mein erster Gedanke war nicht „cool, es funktioniert“. Es war eher: Das ist deutlich schneller, als ich erwartet hatte.

Der alte Ablauf: Adresse kopieren, Tab wechseln, einfügen, warten. Der neue: ein Tippen im Teilen-Menü, und der Text ist da. Das klingt nach ein paar eingesparten Handgriffen. In der Praxis ist es genau der Unterschied zwischen einem Werkzeug, das man tatsächlich benutzt, und einem, bei dem man jedes Mal denkt: Ach, dafür müsste ich jetzt erst wieder …

Warum sich die Tests ausgezahlt haben

In den folgenden Wochen wuchs das Projekt weiter. Jedes Mal, wenn etwas Größeres geändert wurde, schlugen zuerst die Tests an. Sie zeigten, welche bisher funktionierenden Fälle eine Änderung nebenbei kaputtgemacht hätte, bevor sie überhaupt auf dem Server landete.

Gerade weil die Prüfvorschriften nicht nachträglich an das fertige Programm geklebt wurden, bildeten sie die ursprünglichen Architekturentscheidungen ziemlich genau ab. Sie waren ja gleichzeitig mit der Architektur entstanden.

Was danach kam

Danach lief der Dienst einfach vor sich hin. Hauptsächlich auf dem Handy und erst mal nur für mich.

Was dabei die ganze Zeit nirgends stand: was man an dem Ding eigentlich aufrufen kann.

→ PullMD Teil 3: Die API, und wie aus Reddit jede URL wurde

Teil 2 von 15 der PullMD Serie.

← PullMD Teil 1: Strg+A und der Junk-Kontext | PullMD Teil 3: Die API, und wie aus Reddit jede URL wurde →