PullMD Teil 5: Reddit-Tag und die ersten Issues – Einfach erklärt
Am 27. April morgens war das Repo öffentlich. Über Nacht passierte: fast nichts. Ein paar Sterne, vierzehn Leute, die sich das Projekt heruntergeladen hatten, aber niemand, der etwas dazu schrieb.
Das war das erste Mal, dass ich beim Frühstück nebenbei auf ein Projekt schaute, das nicht mehr nur meins war — und dass nichts Unerwartetes passiert war.
Der Reddit-Post
Am Tag danach, kurz nach Mittag, schrieb ich einen kurzen Beitrag in einem großen Reddit-Forum für Leute, die mit Claude arbeiten. Der Titel sagte sinngemäß: „Ich habe Claude einen kleinen Helfer gebaut, damit er beim Lesen von Webseiten nicht mehr so viel Energie verschwendet.“
Zwei Frustrationen waren der Aufhänger — echte, nicht erfundene:
Erstens: Auf dem Handy einen langen Artikel zu kopieren ist eine Plackerei. Lange auf den Text drücken, die kleinen Auswahl-Anker vorbei an Werbebannern und Menüleisten ziehen, kopieren, App wechseln, einfügen. Nichts davon ist schwer. Aber es nervt jeden einzelnen Tag.
Zweitens: Wenn man eine Webseite an einen KI-Assistenten gibt, sind etwa 80 Prozent davon Navigation, Cookie-Hinweise und Fußzeilen. Nur 20 Prozent sind der eigentliche Inhalt. Den Assistenten dazu zu zwingen, sich da erstmal durchzukämpfen, ist Verschwendung.
Ich hatte keine besonderen Erwartungen. Ein Post unter Tausenden, mitten am Werktag.
Was über den Tag passierte
Am Ende waren es 387 Daumen-hoch und 58 Kommentare. Das war mehr als alles, was ich vorher auf Reddit gepostet hatte.
Der erste Kommentar, den ich morgens las, war so etwas wie ein freundliches Schulterklopfen:
“What is this!? A useful and novel tool on an AI sub? Amazing!” — u/CloisteredOyster (+108)
„Was ist das!? Ein nützliches und neues Tool in einem AI-Sub? Erstaunlich!“ — u/CloisteredOyster (+108)
Das war früh genug am Tag, dass ich mich freuen konnte, ohne zu wissen, ob noch mehr kommt.
Was die Kommentare mir über mein eigenes Tool beibrachten
Der spannendste Kommentar kam von jemandem mit dem Namen u/blin787. Er erklärte ruhig, wie eine ähnliche Funktion in Claude selbst schon eingebaut ist:
“Claude code’s webfetch works differently. It passes page to Haiku model which then returns very small result which is actually added to context of Opus/Sonnet. So the reduction is not as drastic as it seems when using with agents which solved this problem.” — u/blin787 (+35)
„Claude Codes WebFetch funktioniert anders. Es leitet die Seite an ein Haiku-Modell weiter, das ein sehr kleines Ergebnis zurückgibt, welches dem Kontext von Opus/Sonnet hinzugefügt wird. Die Reduktion ist also nicht so drastisch, wie sie wirkt, wenn man Agents nutzt, die dieses Problem schon gelöst haben.“ — u/blin787 (+35)
Auf Deutsch: Claude hat schon einen eingebauten Weg, Webseiten zu lesen. Dabei schickt er die Seite kurz an ein kleineres, günstigeres KI-Modell, das eine knappe Zusammenfassung zurückgibt. Diese Zusammenfassung sieht dann das große Modell.
Ich hatte mir das nie tief angesehen — ich löste ja ein anderes Problem. Nach dem Hinweis schaute ich nach. Und da wurde der Unterschied klar.
Die eingebaute Variante ist günstiger und schneller. Aber sie zeigt dem großen Modell nicht die Seite selbst, sondern nur die Zusammenfassung eines kleineren Modells.
Mein Tool, PullMD, gibt den echten Seiteninhalt zurück — wortgetreu, sauber als Text. Kein zwischengeschaltetes Modell, das vielleicht etwas wegkürzt.
Beide Wege haben ihren Platz. Wenn du den genauen Wortlaut brauchst — Listen, Tabellen, Zitate — ist mein Tool die bessere Wahl. Wenn dir die grobe Aussage reicht, tut es die eingebaute Variante auch.
Vergleichsfragen als Geschenk
Zwei weitere Kommentare las ich als ehrliche Vergleichsfragen, nicht als Angriffe.
Der erste:
“Isn’t that just like firecrawl?” — u/KnackeHackeWurst (+11)
„Ist das nicht einfach wie firecrawl?“ — u/KnackeHackeWurst (+11)
Firecrawl ist ein größerer Werkzeugkasten — es kann eine ganze Webseite mitsamt allen Unterseiten herunterladen, dazu kommen noch KI-Funktionen, die je nach Einsatz einen externen KI-Zugang brauchen.
Mein Tool ist eine einzelne Adresse, eine einzelne Antwort, keine KI dazwischen. Wenn jemand eine komplette Dokumentation in Stücke zerlegen will — Firecrawl. Wenn jemand eine einzelne Adresse in dreißig Sekunden in sauberen Text verwandeln will, ohne Konto, ohne Schlüssel — mein Tool.
Der zweite:
“Would not it be better to run a bash script as a skill which operates on your browser or headless or even with wget rather than on a server?” — u/ardicli2000 (+3)
„Wäre es nicht besser, ein Bash-Skript als Skill zu betreiben, das mit deinem Browser, Headless oder sogar mit wget arbeitet, statt auf einem Server?“ — u/ardicli2000 (+3)
Auf Deutsch: Wäre es nicht einfacher, ein kleines Skript direkt auf dem eigenen Rechner laufen zu lassen, statt einen Server dafür aufzusetzen?
Die Frage ist berechtigt. Für eine einzelne Person auf einem einzelnen Rechner reicht ein kleines Skript völlig. Ein Server lohnt sich erst, sobald mehr ins Spiel kommt: derselbe Cache für mehrere Geräte, Handy und Laptop greifen auf dieselbe Datenbasis zu, und der Browser, der die Webseiten unsichtbar lädt, läuft einmal an einem Ort statt zigfach lokal. Sobald man einen Link teilen will, der auch in zwei Tagen noch funktioniert, braucht es sowieso eine stabile Adresse irgendwo im Netz.
Reddit fragte nach Zahlen
Mehrere Leute wollten konkrete Zahlen sehen. Wie viel sparen wir eigentlich?
Ich habe abends ein paar Vergleiche an den Post angehängt. Drei Beispiele, jeweils die Roh-Webseite gegen das, was mein Tool daraus macht:
| Quelle | Roh | PullMD | Reduktion |
|---|---|---|---|
| GitHub README | 141.599 | 3.125 | 97,8% |
| MDN Reference | 63.979 | 16.093 | 74,8% |
| Reddit Thread | 3.264 | 320 | 90,2% |
Die Zahlen sind Schätzwerte mit einem Standard-Verfahren, keine perfekt exakten Werte. Aber die Größenordnung stimmt: Drei Viertel bis 98 Prozent weniger Datenmenge. Genau darum geht es bei dem Tool.
Das erste Issue von außen
Abends, um 22:56, öffnete jemand namens andrewthetechie das erste Issue. (Ein Issue ist eine Art Beschwerde-Zettel auf GitHub — jemand meldet einen Fehler oder einen Wunsch.)
Sein Befund: Eine bestimmte technische Antwort meines Tools wird vom KI-Assistenten anders angezeigt, als ich es vorgesehen hatte.
Zum ersten Mal hatte jemand Fremdes sich die Mühe gemacht, einen Fehlerbericht zu schreiben — weil mein Code etwas falsch macht. Das fühlt sich anders an als ein Daumen-hoch. Ein Issue ist Arbeit. Jemand hat das Tool installiert, das Problem nachgestellt, formuliert, abgeschickt.
Gut eine halbe Stunde später, um 23:29, kam Issue Nummer zwei von jemand anderem: ein Problem mit der Installation per Docker. Zwei Issues am selben Abend. Das Repo war seit weniger als 48 Stunden öffentlich.
Die Welle am Tag danach
In den nächsten 24 Stunden: dreizehn Issues im Tracker. Kein gleichmäßiger Strom, sondern ein Block, der entstand, solange der Reddit-Beitrag noch sichtbar war. Die meisten kamen von fremden Nutzern — zwei davon habe ich selbst angelegt, dazu gleich mehr.
Eine Auswahl der Meldungen von außen, um zu zeigen, wie breit das Spektrum war:
- Funktion: Eine Schalter-Option, um die öffentliche Verlauf-Liste auf geteilten Servern auszublenden
- Fehler: Manche älteren Webseiten zeigen kaputte Sonderzeichen, weil die Zeichenkodierung nicht erkannt wird
- Fehler: Reddit-Threads mit Bildern verschluckten Überschrift und Kommentare
- Fehler: Die fertigen Container-Pakete waren nicht an der erwarteten Stelle abrufbar
Einer der Melder — er taucht in dieser Serie noch öfter auf — brachte einen ganz konkreten Fall aus einem deutschsprachigen Nachrichtenportal mit. Ohne diesen Hinweis hätte ich das Problem mit den Sonderzeichen vermutlich noch wochenlang nicht entdeckt.
Die Statistik-Seite von GitHub für diese zwei Wochen: rund 400 verschiedene Besucher, gut 300 Leute, die das Repo heruntergeladen haben. Reddit war mit Abstand die häufigste Quelle.
Wie das Feedback meine Reihenfolge umwarf
Zwei der Issues kamen nicht von außen — die habe ich selbst angelegt, mit Claude Code, um all die Hinweise und Wünsche aus dem Reddit-Thread zu bündeln. Das wichtigere davon: „mehrere Menschen sollen das Tool gleichzeitig nutzen können“ — Sitzungen, Zugangsschlüssel, getrennte Daten pro Person. Eine ganze kleine Architektur, nüchtern als „Phase 1“ notiert.
Mehrere Nutzer waren für mich eigentlich Phase 2 oder 3, irgendwo auf der Liste für später. Aber das Feedback aus dem Thread machte klar, dass „später“ nicht mehr stimmte. Also schrieb ich es auf und sortierte es nach oben.
Genau das passiert, wenn man eine Software öffentlich macht: die Reihenfolge der Features bestimmt man nicht mehr allein. Nicht weil Fremde sie vorschreiben, sondern weil ihr Feedback die eigene Einschätzung verschiebt.
Was daraus wurde, ist Teil 6.
Teil 5 von 9 der PullMD Serie.
← PullMD Teil 4: Vom Tool für mich zum OSS-Projekt | PullMD Teil 6: Multi-User-Pivot →