agentic-coding · 2026-05-17
424 GitHub-Repos: Ideen-Hoarding oder Strategie?
TL;DR
Stand 17. Mai 2026: 424 Repos. 367 nicht archiviert. 154 neu in 2026. 15 live auf Cloudflare Pages. Die Zahl ist nicht das Ziel. Sie ist das Sediment einer Arbeitsweise: eine Idee, ein Repo, Reality-Check vor Diskussion. Dieser Post zeigt die Telemetrie, die drei Heuristiken, mit denen ich entscheide welches Repo bleibt, und unter welchen Bedingungen das für jemand anderen Sinn ergibt. Spoiler: für die meisten nicht.
Featured-Image-Platzhalter: stilisierte Grid aus Repo-Karten in Norddeutsch-Palette. Asset folgt — Prompt am Ende des Posts.
Inhaltsverzeichnis
- Die rohe Telemetrie
- Wie sich 424 Repos auf 30 Jahre verteilen
- Drei Heuristiken: wann ein Repo lebt
- Was die meisten falsch verstehen
- Wann ergibt das für dich Sinn?
- Was es wirklich kostet
- FAQ
Die rohe Telemetrie
| Metrik | Wert | Kommentar |
|---|---|---|
| Repos total | 424 | Stand 17.05.2026, alle Sichtbarkeiten |
| Davon nicht archiviert | 367 | ”Lebendig”, auch wenn nicht alle aktiv |
| Neu in 2026 | 154 | bis Mitte Mai → ~ 30 Repos/Monat |
| Live deployed (Cloudflare Pages) | 15 | Produktiv im Web sichtbar |
| Davon mit eigener Domain | 6 | bonblick.app, workbrief.app, kmu.moinsen.dev, moinsen.dev, ulrichdiedrichsen.com, weitere |
| Top-Sprache (Files-Anteil) | Dart 118 | Flutter ist mein primärer Stack |
| Top 2 | TypeScript 80 | Web + Astro-Sites |
| Top 3 | Python 72 | KI-Backends, Daten-Pipelines |
| Top 4 | Swift 15 | iOS, Adventurist-Vorarbeiten |
| Top 5 | Rust 12 | Performance-Experimente |
Die Zahl 424 erschreckt Leute. Die durchschnittliche GitHub-Account-Größe liegt nach Anekdoten aus dem Hacker-News-Thread zu 500+ Repositories bei ~10-30 Repos für aktive Entwickler. 424 ist also Faktor 14-40× über dem typischen Wert. Das ist erklärungsbedürftig.
Wie sich 424 Repos auf 30 Jahre verteilen
Die wichtigste Korrektur zuerst: 154 dieser 424 Repos sind neu in 2026. Nicht in 30 Jahren — in viereinhalb Monaten. Das Muster ist nicht über die Karriere gewachsen, es ist eine Folge des Wechsels von Architekt (15 Jahre IBM/PwC) zu Indie Builder (seit 2024) plus Agentic-Coding-Tools, die das Erstellen eines neuen Repos billiger machen als das Aufmachen eines Branches.
Inline-Image-Platzhalter: Balkendiagramm mit Repo-Anlage pro Jahr 2010-2026. Steile Kurve ab 2024. Asset folgt.
Ein Repo zu erstellen kostet mich heute ca. 30 Sekunden:
gh repo create moinsen-dev/idea-name --private --clone
cd idea-name && cursor . && claude code
Ein Branch kostet mehr mentalen Overhead: er lebt im Kontext eines existierenden Projekts, hat dessen Konventionen, dessen CLAUDE.md, dessen offene Issues. Ein neues Repo ist sauber. Wenn die Idee nach 90 Minuten tot ist, archiviere ich das Repo und der Kontext-Schmutz bleibt draußen.
Das ist die These des Posts. Alles andere ist Konsequenz.
Drei Heuristiken: wann ein Repo lebt
Nicht jedes Repo bleibt aktiv. Die 57 archivierten von 424 sind kein Zufall — sie folgen drei Regeln, die ich nach Schmerz gelernt habe.
Heuristik 1: 7-Tage-Reality-Check
Ein neues Repo bekommt 7 Tage ein Stück tägliche Aufmerksamkeit. Wenn nach Tag 7 kein klares “Ja, hier ist eine echte Frage drin, die ich beantworten will” steht, wird archiviert. Nicht gelöscht — archiviert. (Wichtige Unterscheidung. Mehr dazu in den FAQ.)
Das filtert Vibe-Coding-Eintagsfliegen aus. Andrej Karpathys Vibe-Coding-Konzept ist großartig für Ideenfindung, gefährlich wenn die Idee länger als 7 Tage atmet ohne Substanz.
Heuristik 2: 30-Tage-Stille-Sweep
Jedes nicht-archivierte Repo, das 30 Tage keinen Commit hatte, kommt einmal pro Woche auf eine Liste. Drei Optionen pro Eintrag:
- “Bewusst eingefroren — kommt zurück” → Tag
frozen, raus aus der Liste - “Tot, ich wollte es nur nicht zugeben” → archivieren
- “Lebt nur in meinem Kopf” → README mit 1 Absatz aktualisieren, dann Tag
dormant
Diese Heuristik trennt ehrliche Pausen von schleichendem Bottleneck.
Heuristik 3: Jahres-Sweep im Dezember
Einmal im Jahr — meist zwischen Weihnachten und Silvester — gehe ich durch alle Repos > 12 Monate ohne Commit. Default: archivieren. Ausnahmen müssen aktiv begründet werden.
Inline-Image-Platzhalter: Entscheidungsbaum (neu → 7-Tage-Check → 30-Tage-Sweep → Jahres-Sweep). Asset folgt.
Das Ergebnis nach drei Jahren dieser Heuristiken: 13.4% Archiv-Quote (57 von 424). Das klingt niedrig — ist es auch, weil ich 2026 erst angefangen habe, die Heuristiken konsequent durchzusetzen. Erwartung für 2027: ~25-30% Archiv-Quote, weil dann die 154 frischen 2026er Repos durch die Filter laufen.
Was die meisten falsch verstehen
Die häufigste Reaktion auf “424 Repos” ist eine von zwei Falschannahmen:
Falsch 1: “Das ist Hoarding.” Hoarding hat eine emotionale Komponente — Anhänglichkeit, FOMO, Angst vor Lücken. Das hier ist das Gegenteil. Ein Repo ist ein Wegwerf-Container. Die Bindung ist an die Idee, nicht an den Code. Wenn die Idee falsch war, geht der Code weg. Der Code war billig — die Antwort darauf ist wertvoll: “Diese Idee ist gestorben am 30. Tag, weil das Marktproblem nicht real war.” Diese Lernen-Geschwindigkeit ist der Punkt.
Falsch 2: “Das ist Strategie.” Strategie hat eine vorausschauende Komponente — “in 3 Jahren werde ich 12 dieser Repos zu Produkten gebaut haben”. Das hier ist auch nicht das. Ich weiß heute nicht, welche der 154 Repos von 2026 in 2 Jahren noch leben. Das ist Teil der Methode. Wenn ich es wüsste, müsste ich keine 154 Repos anlegen — drei reichten.
Die richtige Beschreibung liegt dazwischen: eine billige Optionsmaschine. Jeder Repo ist eine 30-Sekunden-Option auf eine mögliche zukünftige Idee. Die Mehrheit verfällt wertlos. Die Wenigen, die nicht verfallen, sind die Produkte. Bonblick, Food Designer, AI Trader, Conductor — alle aus dieser Optionsmaschine entstanden, nicht aus vorausschauender Planung.
Inline-Image-Platzhalter: Loop-Diagramm (Idee oben → Repo → 7d Reality-Check → entweder Produkt-Pfad oder Archiv-Pfad). Asset folgt.
Wann ergibt das für dich Sinn?
Drei Bedingungen müssen alle gleichzeitig zutreffen:
- Du hast Agentic-Coding-Tools im Stack. Ohne Claude Code, Cursor, GitHub Copilot oder ähnliche Tools ist der Repo-Initialisierungs-Overhead zu hoch. Ohne sie kostet ein neues Repo nicht 30 Sekunden, sondern 30 Minuten — und damit ist die ganze Logik kaputt.
- Du bist 100% selbstbestimmt über dein Repo-Setup. Wenn du in einer Firma arbeitest, die Repos zentral genehmigt: vergiss es. Die Heuristik braucht Reibungsfreiheit beim Anlegen UND beim Archivieren.
- Du hast Komfort mit weggeworfenem Code. Wenn du jeden Repo betrauerst, der archiviert wird, baust du eine Hoarding-Schicht über die Heuristik und sabotierst sie. Der norddeutsche Hintergrund hilft hier — “Dat is dood, dann wegg” ist eine kulturelle Disposition.
Wenn auch nur eine der drei Bedingungen fehlt: weniger Repos sind besser. Pieter Levels, wahrscheinlich der bekannteste Solo-Founder mit vielen Mini-Produkten, betreibt ~10-12 aktive Projekte. Das ist die andere Skala — funktioniert für ihn, weil jedes seiner Projekte revenue-aktiv ist. Meine 154 frischen 2026er Repos sind zum überwiegenden Teil Vor-Revenue. Andere Optimierungs-Funktion.
Was es wirklich kostet
Honest cost-Sektion, weil viele die unsichtbaren Kosten unterschätzen.
| Kostenart | Größe | Pro Jahr |
|---|---|---|
| GitHub Pro | $4/Monat | $48 |
| Cloudflare Pages | Free Tier für 15 Sites | $0 |
| Domains (~10 aktiv) | ~€12/Domain/Jahr | ~€120 |
| Mentaler Overhead (Sweeps) | ~2 Stunden/Monat | 24 Stunden |
| Context-Switching-Risiko | hoch in Wochen mit > 5 aktiven | variabel |
Die Geld-Kosten sind irrelevant (~€170/Jahr für die gesamte Infrastruktur). Die echte Kosten ist Context-Switching. Conductor v8.1.0 mit seinem knowhow-Plugin (siehe Vorgänger-Post) ist der primäre Counter — ohne den könnte ich 8 parallele Projekte nicht halten.
Was es nicht kostet: Recruiter-Wahrnehmung. Ich habe in 30 Jahren Senior-Karriere gelernt, dass kein einziger seriöser Tech-Recruiter sich 424 Repos anschaut. Sie schauen sich 1-3 Pinned Repos an. Solange dort echte Substanz ist (READMEs, CI, Tests), spielt die Gesamtzahl keine Rolle. Quelle: gelebte Erfahrung, nicht Studie.
Wo das hingeht
Drei offene Punkte, an denen die Methode aktuell knirscht:
- Cross-Repo-Refactoring. Wenn eine API-Änderung in 12 Repos parallel passieren muss, bricht Heuristik 2 zusammen — keines hat 30 Tage Stille, aber alle brauchen Aufmerksamkeit zur gleichen Zeit. Conductor v9 wird das adressieren.
- Auto-Telemetry. Die Tabelle oben habe ich manuell aus der GitHub-API generiert. Ich habe noch kein Dashboard, das mir täglich zeigt, welches Repo wo im Lifecycle steht.
- Public vs. Private Mischung. Aktuell sind die meisten meiner 367 lebenden Repos privat. Das ist defensiv, vor allem für Experimente. Aber wenn ich Open-Source-Authority ausbauen will (Wikipedia-Notabilität, Citation-Surface in AI-Engines), muss ein größerer Anteil public werden. Plan: in 2026/2027 ~30-50 Repos ausgewählt öffentlich machen.
Wenn du selbst mit vielen Repos arbeitest oder das System angreifen willst: schreib mir auf LinkedIn oder GitHub. Ich tausche gerne Notes.
FAQ
Wie viele GitHub-Repositories sollte ich haben?
Es gibt keine Idealzahl. Die richtige Frage ist: wie schnell ist deine Idee-Reality-Check-Schleife? Wenn du Agentic-Coding-Tools nutzt und ohne Reibung Repos anlegen + archivieren kannst, sind 50-400 normal. Wenn nicht, sind 5-20 normal.
Was kostet GitHub Pro?
$4/Monat (~€48/Jahr). Für die meisten Indie Builder reicht der Free-Tier — Pro brauche ich nur für GitHub Codespaces und unbegrenzte private Repos in Organisations-Accounts. Aktuelle Preise auf github.com/pricing.
Sollte ich alte Repos löschen oder archivieren?
Archivieren, nicht löschen. Archivierung behält die Historie (nützlich, wenn die Idee in 2 Jahren wieder relevant wird) und entfernt das Repo aus der aktiven Liste. Löschen ist destruktiv und löscht Branch-Refs, Stars, Issues. Ich habe seit 2024 kein einziges Repo gelöscht.
Macht es Sinn, kleine Experimente in eigene Repos zu packen statt Branches?
Wenn das Experiment unabhängig vom Hauptprojekt ist: ja, eigenes Repo. Wenn es eine Variation des Hauptprojekts ist: Branch. Heuristik: könnte das Experiment in 6 Monaten ein Produkt werden? → Repo. Ist es eine Feature-Variation? → Branch.
Wie wirkt sich eine hohe Repo-Anzahl auf Bewerbungen aus?
Praktisch gar nicht. Recruiter schauen sich 1-3 Pinned Repos an, nicht die Gesamtzahl. Wichtiger: dass die Pinned Repos einen klaren README + CI + Tests haben. Davids Indie-Dev-Toolkit ist eine gute Referenz dafür, wie ein gepinntes Repo aussehen sollte.
Geschrieben am 17. Mai 2026 in Hamburg. Telemetrie ist ein Snapshot zu diesem Datum — die Zahl wächst weiter. Wenn du diesen Post hilfreich findest, verlinke ihn — das hilft, dass auch andere ihn finden.