Die Kathedrale, der Basar und das Winchester Mystery House — Das dritte Modell der Softwareentwicklung im Zeitalter der KI

The Cathedral, the Bazaar, and the Winchester Mystery House

„Die Kathedrale und der Basar“, 1998 von Eric Raymond veröffentlicht, ist ein Text, der zum Ausgangspunkt der Open-Source-Bewegung wurde. Indem er die geschlossene und kontrollierte „Kathedrale“ der offenen und verteilten „Basar“-Methode gegenüberstellte, nahm dieser Text vorweg, dass das Basar-Modell eine ganze Generation prägen würde, weil das Internet die Kosten der Zusammenarbeit am Code senkte. Mit dem Aufkommen von KI-Coding-Agenten sind jedoch die Kosten der Codeproduktion selbst drastisch gefallen, und der Autor Drew Breunig diagnostiziert, dass damit ein drittes Modell entstanden ist: das „Winchester Mystery House“. Dieses real existierende Anwesen in San José ist ein bizarrer und gewaltiger Bau, den Sarah Winchester mit unbegrenzten finanziellen Mitteln und persönlicher Leidenschaft ihr Leben lang erweitern ließ; heute dient es als Metapher für die Arbeitsweise von Entwicklern, die mit KI unablässig ihre ganz eigenen Werkzeuge anbauen.

Kernzusammenfassung

• Drei Modelle der Softwareentwicklung: Kathedrale (geschlossen, planungsgetrieben), Basar (offen, kollaborativ) und das neu entstandene Winchester Mystery House (persönlich zugeschnittener Ausbau).
• Der Preis von Code ist eingebrochen: Den im Text zitierten Daten zufolge erzeugt Claude Code pro Commit netto etwa 1.000 Zeilen zusätzlichen Code. Laut dem Autor ist das um etwa eine Größenordnung mehr als die Menge Code, die ein menschlicher Entwickler pro Tag schreibt (rund 10 bis 30 Zeilen, zitiert aus Brooks’ „The Mythical Man-Month“).
• Die Kosten des Feedbacks bleiben gleich: Während die Implementierungskosten eingebrochen sind, hat sich die Geschwindigkeit menschlicher Arbeit bei Review, Diskussion und Tests nicht verändert; der Engpass hat sich also verlagert.
• Der Entwicklungsstil des „Mystery House“: Der Autor nennt Steve Yegges Gas Town, Jeffrey Emanuels Agent Flywheel·FrankenSuite und Gary Tans gstack als Beispiele und beobachtet, dass der Aufbau privater, riesiger Werkzeuge für den Eigenbedarf zunimmt.

Charakteristische Merkmale

• Eigenwillig (Idiosyncratic): Da Entwickler mit Coding-Agenten direkte Feedback-Schleifen nach ihren eigenen Vorlieben und Bedürfnissen fahren, sind Strukturen, die für Außenstehende schwer zu entschlüsseln sind, und fehlende Dokumentation häufig.
• Ausufernd (Sprawling): Da die Kosten für zusätzlichen Code praktisch bei null liegen, geht die Entwicklung eher in Richtung ständiger Erweiterung statt Kürzung. Patches werden direkt an Ort und Stelle vorgenommen, und ungenutzte Anbauten bleiben einfach bestehen.
• Spaß (Fun): Weil Agenten jede Arbeit in eine Art Nebenquest verwandeln, wird schon das Feintuning des eigenen Workflows selbst zum Hobby.

Unterschiede zum Basar

• Struktur der Feedback-Schleife: Der Basar nutzt die vielen Augen vieler Menschen (hoher throughput, hohe latency), während das Mystery House die Schleife auf einen einzelnen Entwickler komprimiert; dadurch ist die Verzögerung (latency) nahezu null, aber die Sicht bzw. Kapazität (throughput) verengt sich auf diese eine Person.
• Konflikt mit gemeinsamer Infrastruktur: Erwähnt werden Fälle, in denen die große Menge agentenerzeugter PRs die Review-Kapazität von Projekten wie curl lahmlegt. curl hat sein Bug-Bounty-Programm eingestellt, und GitHub hat eine Option hinzugefügt, um PR-Beiträge zu blockieren.

Die Lehren, die der Autor daraus zieht

• Möglichkeit der Koexistenz: An Beispielen wie OpenClaw zeigt sich aus Sicht des Autors, dass Basar und Mystery House nebeneinander bestehen können, wenn sich die Community um einen gemeinsamen Kern kümmert und individuelle Erweiterungen den Nutzern überlassen bleiben.
• Die „spaßigen Teile“ nicht verkaufen: Chancen für Tools und Services sieht er nicht in den Teilen, die Entwickler selbst bauen möchten, sondern in Bereichen wie Sicherheit, Infrastruktur und Plumbing, für die man ungern Verantwortung trägt und in denen das Scheitern teuer ist.
• Was jetzt fehlt, ist „Aufmerksamkeit (attention)“: Nachdem erst Code und dann Koordinationskosten billig geworden sind, lautet die Diagnose, dass die nächste Aufgabe in Werkzeugen und Praktiken besteht, mit denen sich aus der Flut von Beiträgen gute Ideen herausfiltern lassen.

Die These des Autors läuft letztlich auf eine einzige Frage hinaus. Wenn das Internet den Basar möglich gemacht hat, indem es Zusammenarbeit billig machte, und Coding-Agenten das Mystery House ermöglicht haben, indem sie Implementierung billig machten, dann brauchen wir jetzt Werkzeuge, die „Aufmerksamkeit“ billig machen. Solange es die nicht gibt, wird das Open-Source-Ökosystem zwar immer lauter, aber nicht klüger werden, und gute Ideen, die in den jeweiligen Mystery Houses vergraben sind, werden in dem Moment mit verschwinden, in dem ihre Wartung aufhört — mit dieser Warnung endet der Text.

[superdorai]

Dem kann ich total zustimmen, haha. Ich lasse auch mein Mystery House hier: ein ultrasicheres Harness für Nicht-Entwickler.

https://github.com/lbk0523/samantha

[youknowone]

Ich baue ebenfalls ein Winchester Mystery House. Mein Ziel ist es, noch innerhalb dieses Jahres ein in Rust geschriebenes PyPy zu veröffentlichen.

https://github.com/youknowone/pyre/

[youknowone]

Nicht Kathedrale und Basar, sondern https://ko.wikipedia.org/wiki/Seongdanggwa_Sijang