Stellen wir uns ein persönliches Software-Repository vor, dessen fortlaufende GitHub-Nummer für Issues und Pull Requests fast vierstellig ist.
Die spontane Reaktion liegt nahe:
„Hat eine Person fast tausend Entwicklungsaufgaben erledigt?“
Fast, aber so lässt sich die Zahl nicht direkt übersetzen. GitHub behandelt für die Nummerierung jeden Pull Request als eine Form von Issue, und Issue- und Pull-Request-Nummern überschneiden sich innerhalb eines Repositorys nicht. Eine Nummer nahe 1000 bedeutet daher nicht, dass 1000 Pull Requests abgeschlossen wurden.[1]
Die interessantere Frage bleibt bestehen:
Wenn ein Mensch dieses Ausmaß an Änderungen, Prüfungen, Reparaturen, Veröffentlichung und Betrieb weitgehend von Hand und ohne KI erledigen müsste, was würde das kosten und wäre es wirtschaftlich?
Genau diese Frage trifft den Kern der Ökonomie KI-gestützter Solo-Entwicklung.
1. Eine GitHub-Nummer ist kein Wiederholungszähler im Fitnessstudio
Die Nummer eines Repositorys ist kein Arbeitslastmesser.
Ein Entwickler kann 2000 geänderte Zeilen in einen Pull Request packen. Ein anderer eröffnet einen Pull Request für eine einzige CSS-Zeile. Dazu kommen Issues für Fehler, Entwurfsnotizen, Funktionswünsche, Untersuchungen und Betriebsaufgaben, die denselben Nummernraum nutzen.
Deshalb gilt:
Fast 1000 in der Reihenfolge bedeutet nicht Arbeit für 1000 Personen.
Es bedeutet auch nicht:
fast 1000 fertige Funktionen.
Die Nummer ähnelt eher einem Drehkreuzzähler als einer Waage.
Wenn sich jedoch in kurzer Zeit viele kleine Änderungen ansammeln, zeigt die Historie trotzdem etwas: Die Schleife Entwurf → Umsetzung → Prüfung → Reparatur wurde immer wieder durchlaufen.
Für menschliche Kosten ist daher nicht die Nummer entscheidend, sondern die durchschnittliche Zeit pro substanzieller Schleife.
2. Menschliche Kosten werden besonders leicht unterschätzt, wenn jede einzelne Aufgabe winzig wirkt
Ein im September 2026 veröffentlichter Bericht auf Basis gelisteter Freelance-Engineering-Projekte in Japan bezifferte den durchschnittlichen monatlichen Projektsatz für August 2026 auf 789.000 Yen.[2]
Das ist weder das Gehalt aller Entwickler noch der Stundenlohn einer bestimmten Person. Es ist ein Durchschnitt des gelisteten Projektmarktes.
Als ein Vergleichswert für Ersatzkosten ist die Zahl dennoch nützlich: Was könnte vergleichbare professionelle Engineering-Kapazität kosten, wenn sie extern eingekauft wird?
Bei 160 Stunden pro Monat entspricht das ungefähr 4930 Yen pro Stunde.
Nehmen wir nun 1000 substanzielle Änderungseinheiten an. Das ist ein Rechenbeispiel und ausdrücklich nicht dasselbe wie GitHub #1000.
| Durchschnittliche Zeit pro Änderung | Gesamtzeit | Personenmonate bei 160 h/Monat | Kosten bei 789.000 Yen/Monat |
|---|---|---|---|
| 15 Min. | 250 h | 1,56 | ca. 1,23 Mio. ¥ |
| 30 Min. | 500 h | 3,13 | ca. 2,47 Mio. ¥ |
| 45 Min. | 750 h | 4,69 | ca. 3,70 Mio. ¥ |
| 1 Std. | 1000 h | 6,25 | ca. 4,93 Mio. ¥ |
| 2 Std. | 2000 h | 12,5 | ca. 9,86 Mio. ¥ |
| 3 Std. | 3000 h | 18,75 | ca. 14,79 Mio. ¥ |
| 4 Std. | 4000 h | 25 | ca. 19,73 Mio. ¥ |
Selbst 1000 Änderungen von jeweils nur 15 Minuten ergeben 250 Stunden.
„Jede Aufgabe ist klein“ bedeutet nicht „die Gesamtkosten sind klein“.
Kleine Aufgaben tragen außerdem fixe Abläufe mit sich: Recherche, Branch-Erstellung, Review, Tests, Merge, Deployment-Prüfung und Rückfallplanung.
Wenn eine Person alles manuell erledigt, wird die Visitenkarte irgendwann zum Faltblatt: Autor, Übersetzer, Frontend, Backend, QA, Infrastruktur und Chefredaktion.
3. „Ich habe es selbst gemacht, also kostet die Arbeit null“ kann in der Kassenrechnung stimmen und im wirtschaftlichen Vergleich falsch sein
Eine private Website kann monatlich 1000 Yen Hosting kosten und 5000 Yen Werbeeinnahmen erzielen.
Auf reiner Kassenbasis sind das 4000 Yen Überschuss.
Wenn der Betreiber jedoch 50 Stunden pro Monat investiert, braucht ein wirtschaftlicher Vergleich eine zweite Sicht.
Mindestens zwei Größen sollten getrennt werden:
Kassengewinn = Einnahmen − tatsächliche Geldkosten
Arbeitsbereinigter Gewinn = Einnahmen − Geldkosten − Arbeitsstunden des Betreibers × gewählter Ersatzstundenwert
Bei einem Hobby kann es völlig sinnvoll sein, die eigene Zeit mit null anzusetzen. Niemand bezeichnet normalerweise 50 Stunden Videospielen als Personalkostenverlust.
Problematisch wird es erst, wenn Hobbyrechnung als Beweis für unternehmerische Rentabilität dient.
Lernen, Spaß, Reputation und die Freude am Bauen sind reale Erträge. Sie sind nur nicht dasselbe wie Unternehmensgewinn.
Im wirtschaftlichen Vergleich verschwindet Zeit nicht, nur weil niemand eine Rechnung gestellt hat.
4. Werbung kann einen überraschend großen Nenner brauchen
Eine vereinfachte Formel lautet:
Werbeerlös = Seitenaufrufe ÷ 1000 × effektiver RPM
Der RPM kann je nach Land, Gerät, Format, Saison, Thema, Publikum und Werbesystem stark schwanken.
Deshalb wird hier kein allgemeingültiger Markt-RPM behauptet. Wir benutzen nur hypothetische Werte, um die Größenordnung zu sehen.
Müssten 789.000 Yen pro Monat ausschließlich über Werbung zurückverdient werden:
| Hypothetischer effektiver RPM | Erforderliche PV für 789.000 Yen/Monat |
|---|---|
| 100 Yen | ca. 7,89 Mio. PV |
| 300 Yen | ca. 2,63 Mio. PV |
| 500 Yen | ca. 1,58 Mio. PV |
| 800 Yen | ca. 0,99 Mio. PV |
Das ist keine Umsatzprognose für irgendeine konkrete Website.
Die Tabelle zeigt: Wenn man manuelle Arbeit mit professionellen Ersatzkosten bewertet, kann eine reine Werbefinanzierung sehr viel Reichweite erfordern.
Darum funktionieren manuell betriebene Websites häufig über eine Mischung aus Werbung, Affiliate-Einnahmen, Produktverkäufen, Kundengewinnung, Mitgliedschaften, Spenden, Markenwert oder schlicht Hobbywert.
5. KI verändert weit mehr als die Schreibgeschwindigkeit
KI auf „sie schreibt in 30 Sekunden einen Artikel“ zu reduzieren, verfehlt einen großen Teil der Ökonomie.
Der Betrieb einer Webpublikation umfasst viele angrenzende Arbeiten:
- Themen finden,
- recherchieren,
- schreiben,
- Fakten prüfen,
- Code ändern,
- testen,
- lokalisieren,
- veröffentlichen,
- das echte Produktionsergebnis prüfen,
- Störungen reparieren,
- über soziale Medien und Newsletter verteilen,
- messen und verbessern.
Bei manueller Arbeit erhöht jeder zusätzliche Prozess typischerweise die variablen Arbeitskosten.
Mit KI und Automatisierung kann der Aufbau des Systems anfangs teurer sein, während die Grenzkosten des zweiten, zehnten und hundertsten Elements sinken können.
Das ist nicht nur „der Autor schreibt schneller“.
Es ist eher:
Eine Person kann das Betriebssystem einer kleinen Redaktion und eines kleinen Engineering-Teams besitzen.
Der Mensch verschwindet nicht.
Seine Rolle verlagert sich zu Eingaben, Entscheidungen, Spezifikationen, Qualitätsregeln, Ausnahmebehandlung und Governance.
Aus der Person, die jedes Artefakt selbst herstellt, wird der Fabrikdesigner und Chefredakteur.
6. KI ist kein magischer Turbo, der Entwicklung immer beschleunigt
Forschungsergebnisse sind gerade deshalb interessant, weil sie nicht alle in dieselbe Richtung zeigen.
Eine 2023 veröffentlichte kontrollierte Studie fand, dass Teilnehmer mit GitHub Copilot eine bestimmte JavaScript-HTTP-Server-Aufgabe 55,8 % schneller erledigten als die Kontrollgruppe.[3]
Eine randomisierte Studie von METR aus dem Jahr 2025 fand dagegen, dass 16 erfahrene Open-Source-Entwickler bei Aufgaben in reifen Repositorys, die sie seit Jahren kannten, im Durchschnitt 19 % länger brauchten, wenn KI-Werkzeuge vom Anfang des Jahres 2025 erlaubt waren.[4]
Im Februar 2026 erklärte METR, dass die spätere Untersuchung schwer zu interpretieren sei. Mehr Entwickler wollten nicht mehr teilnehmen, wenn sie ohne KI arbeiten mussten, und bei parallel eingesetzten Agenten ließ sich die Arbeitszeit schwieriger messen. Neuere Werkzeuge könnten durchaus mehr beschleunigen als die Systeme von Anfang 2025, doch Auswahl- und Messprobleme erlauben keine belastbare präzise Prozentzahl.[5]
Die Schlussfolgerung lautet also nicht:
KI macht Entwicklung immer 55 % schneller.
Und auch nicht:
KI macht Experten 19 % langsamer.
Der Effekt hängt von Aufgabe, Vertrautheit mit dem Code, Agenten-Workflow, Review-Aufwand, Parallelisierung und Testumgebung ab.
KI kann richtige Ergebnisse sehr schnell produzieren. Ein schlechtes System kann Bugs ebenfalls sehr schnell produzieren.
Die relevante Produktivitätszahl ist die im eigenen realen Workflow gemessene.
7. Eine manuelle Website verliert nicht automatisch
Ein stark automatisiertes KI-System ist nicht garantiert profitabler als eine handgefertigte Website.
Manuelle Produktion kann sinnvoll sein, wenn:
- nur wenige Beiträge pro Monat erscheinen,
- die persönliche Stimme des Experten selbst das Produkt ist,
- ein einzelner Artikel ein hochwertiges Produkt oder eine Dienstleistung verkauft,
- keine Mehrsprachigkeit und keine große Distribution nötig sind,
- Aktualisierungen selten sind,
- der Betreiber die Produktion als Hobby genießt,
- oder der Aufbau der Automatisierung mehr kostet als die eingesparte Arbeit.
Automatisierung wird attraktiver, wenn:
- derselbe Prozess ständig wiederkehrt,
- viele Sprachen gepflegt werden,
- der Inhaltsbestand wächst,
- jede Veröffentlichung QA und echte Produktionsprüfung benötigt,
- die Distributionskanäle zunehmen,
- und Menschen dieselben Kontrollen immer wieder durchführen.
Im Kern ist das ein Problem von Fixkosten und variablen Kosten.
Die KI-Fabrik kann am Anfang teuer sein. Die manuelle Werkstatt kann pro Stück teuer sein.
Und ein Hinweis bleibt wichtig: Eine spektakuläre vollautomatische Fabrik ohne Leser ist nicht die Zukunft der Medien. Sie ist ein extrem hoch entwickeltes Lagerhaus.
8. Für die Wirtschaftlichkeit einer manuellen Website ohne KI reichen einige Betriebszahlen
Man muss die Person nicht bewerten.
Für einen Systemvergleich helfen bereits:
- Arbeitsstunden des Betreibers pro Monat
- Monatliche PV oder Unique User
- Monatliche Einnahmen und Geldkosten
- Artikelbestand und neue Artikel pro Monat
- Anzahl der unterstützten Sprachen
- Betriebsjahre und ungefähre anfängliche Aufbauzeit
Daraus lassen sich berechnen:
Kassengewinn = Einnahmen − Geldkosten
Kassenrendite pro Betreiberstunde = Kassengewinn ÷ Arbeitsstunden
Arbeitsbereinigter Gewinn = Kassengewinn − Arbeitsstunden × Vergleichsstundenwert
Grenzkosten pro Artikel = zusätzliche Zeit und Kosten für Schreiben + Übersetzen + QA + Veröffentlichung + Distribution
Die letzte Kennzahl ist besonders wichtig.
Dass früher 1000 Stunden investiert wurden, sagt weniger über die Zukunft als wie viele Stunden der nächste Artikel heute benötigt.
9. Die eigentliche Stärke von KI in Solo-Entwicklung ist nicht Masse, sondern Wiederholbarkeit
Über Nacht einen riesigen Stapel Dateien zu erzeugen, ist heute nicht mehr der schwierigste Teil.
Schwierig ist ein System, in dem:
- beim nächsten Mal dieselben Qualitätsregeln gelten,
- nur der fehlgeschlagene Bereich wiederholt werden muss,
- doppelte Veröffentlichung verhindert wird,
- die aktuelle Revision identifizierbar ist,
- das reale Produktionsergebnis geprüft wird,
- ein blockierter Kanal unabhängige Arbeit nicht einfriert,
- nur Authentifizierung, die wirklich einen Menschen braucht, an einen Menschen zurückgegeben wird,
- und die Historie auditierbar bleibt.
Das ist nicht einfach Erzeugungsmenge.
Es ist ein Betriebsvermögen.
Eine manuelle Website kann dieselbe Art von Vermögen durch Verfahren, Vorlagen, CMS, Backups und Checklisten aufbauen.
Der Unterschied im KI-Zeitalter besteht darin, dass eine einzelne Person solche Betriebsschichten ungewöhnlich tief aufbauen kann.
10. Fazit: Interessanter als „Ist die 1000 erreicht?“ ist „Was kostet die nächste Einheit?“
Eine fortlaufende Issue-/Pull-Request-Nummer nahe vier Stellen wirkt eindrucksvoll.
Sie sollte nicht als Produktivitätsnote benutzt werden.
Nützlicher sind:
menschliche Arbeitsstunden, Kosten pro Änderung, Grenzkosten pro Artikel, Nacharbeitsquote vor Veröffentlichung, Output pro Betreiberstunde, und arbeitsbereinigter Gewinn im Verhältnis zum Umsatz.
Eine manuelle Website kann sehr wohl profitabel sein.
Eine KI-Website kann sehr wohl Verlust machen.
Doch die Kostenkurven unterscheiden sich stark zwischen einem Modell, in dem Menschen Schreiben, Übersetzen, Entwicklung, QA, Veröffentlichung, Überwachung und Distribution bei jedem Durchlauf manuell wiederholen, und einem Modell, das zunächst in Systematisierung investiert und danach die Grenzkosten senkt.
Die Annäherung an 1000 ist nicht deshalb interessant, weil sie eine Medaille wäre.
Die entscheidende Frage lautet:
Wie viele dieser Schleifen aus Versuch und Reparatur wurden zu Mechanismen, die verhindern, dass ein Mensch dieselbe Arbeit beim nächsten Mal wiederholen muss?
Genau dort verändert sich die Wirtschaftlichkeit KI-gestützter Solo-Entwicklung wirklich.
研究注記 / Research notes / Fuentes
読み方の注意 / Interpretation note
The external evidence above supports only the claims it directly measures. The GitHub sequence number is not a workload measure. The ¥789,000 figure is a market-listing average used here only as an illustrative replacement-cost benchmark. The 1000-change tables and RPM tables are explicit scenarios, not observations of an identified site or person. AI productivity effects vary by task, developer, repository, tooling, review burden, parallelization, and measurement method.
Quellen (5)
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
