Conway's AI-Inverse: Kleine Teams, große Monolithen

Melvin Conway reicht Ende der 1960er ein Paper über Computerhersteller und Compiler-Design bei der Harvard Business Review ein. Die lehnt ab — mangels Beweis. 1968 erscheint es in Datamation. Für die nächsten Jahrzehnte nimmt es kaum jemand wahr.

Dann entsteht das Microservices-Paradigma der 2010er Jahre, und plötzlich zitiert jeder Conway. "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."¹ Das klingt jetzt nicht mehr nach Soziologie. Das klingt nach Erklärung.

Was mich interessiert: Was passiert mit diesem Gesetz, wenn AI die Kommunikationsstruktur von Entwicklungsteams verändert?

Was Conway eigentlich sagt — und was er nicht sagt

Martin Fowler formuliert die operative Konsequenz so: Ein Dutzend bis zwanzig Leute können tief und informell kommunizieren, also prognostiziert Conway's Law für sie einen Monolithen. Das sei in Ordnung.²

Das ist kein nostalgisches Plädoyer für alte Architekturmuster. Es ist eine Kausalitätsaussage. Microservices entstehen nicht, weil Ingenieure sie schöner finden. Sie entstehen, weil Organisationen so groß werden, dass informelle Kommunikation zusammenbricht. Du brauchst harte API-Grenzen, weil du harte Team-Grenzen brauchst. Die Architektur folgt der Kommunikationsstruktur — nicht umgekehrt.

2015 war das die passende Antwort auf skalierte Tech-Organisationen: hunderte Engineers, dutzende Teams, verteiltes Ownership. Separate Deployment-Zyklen pro Service ergaben Sinn, weil die Teams ohnehin getrennt arbeiteten. Conway war nicht das Argument für Microservices. Conway war die Beschreibung, warum sie naheliegend wurden.

Matthew Skelton und Manuel Pais haben diese Beobachtung in Team Topologies zu einem Designwerkzeug gemacht: dem Inverse Conway Maneuver³. Die Idee: Wenn Architektur der Teamstruktur folgt, dann gestalte die Teamstruktur bewusst, um die gewünschte Architektur zu bekommen. Das dreht Conway von einer Diagnose in eine Handlungsanweisung. Und es bedeutet auch: Wenn sich die Teamstruktur ändert, durch AI, durch Marktdruck, durch bewusste Entscheidung, ändert sich der architektonische Zielzustand mit.

Jetzt kommt die AI-Frage.

Der Fall für Team-Kompression — und die stärkste Antwort darauf

Bolt.new: 15 Engineers, 40 Millionen Dollar ARR.⁴ Cursor: rund 300 Mitarbeitende, über eine Milliarde Dollar annualized revenue.⁵ Das sind Zahlen, die klassisch skalierte SaaS-Unternehmen mit Tausenden Personen nicht erreichen. Beide bauen mit intensivem AI-Einsatz. Beide sind radikal klein für das, was sie leisten.

Das beste Argument dagegen, daraus eine allgemeine These zu machen, lautet so: Bolt.new und Cursor sind Greenfield-Builds ohne Legacy, ohne Compliance-Overhead, ohne die regulatorischen Anforderungen eines österreichischen Finanzinstituts. Die radikalen Effizienzgewinne dieser Unternehmen sind keine repräsentative Stichprobe. Sie sind Ausreißer, nicht der Durchschnitt.

Das ist richtig. Und trotzdem.

Die METR-Studie⁶ misst mit erfahrenen Open-Source-Entwicklern im randomisierten kontrollierten Experiment: AI-Tools haben die gemessene Arbeitszeit um 19% erhöht, nicht reduziert (n=16, 246 Tasks). Das Verblüffende: Die Teilnehmer glaubten, sie wären schneller. Gefühlte und gemessene Produktivität lagen weit auseinander. DORA 2024⁷ zeigt: Steigt die AI-Adoption in Teams um 25 Prozentpunkte, sinkt der geschätzte Throughput um 1,5% und die Stabilität um 7,2%.

Ich lese das nicht als Widerlegung der Kompressionsthese, sondern als Präzisierung: AI verschiebt den Engpass. Code wird billiger. Review, CI, Koordination und Verifikation werden teurer. Kent Beck, Laura Tacho und Steve Yegge haben das 2026 bei einem Treffen rund um den 25. Jahrestag des Agile Manifesto so formuliert: "We remain skeptical of the promise of any technology to improve organizational performance without first addressing human and systems-level constraints."⁸ Teams, die das nicht explizit adressieren, gewinnen auf dem einen Ende und verlieren auf dem anderen.

Was bedeutet das für Conway? Team-Kompression durch AI passiert, aber nicht gleichmäßig, und nicht überall gleichzeitig. Der Effekt ist real und nachweisbar bei Greenfield-Startups. Wie er sich bei Enterprise-Legacy mit Compliance-Anforderungen verhält, ist noch offen. Ab hier wird es etwas spekulativer.

Was Cursor gebaut hat — und warum das nicht zufällig ist

Gergely Orosz hat recherchiert, wie Cursor intern aufgebaut ist. Die Antwort: "mostly a large monolith… deployed as one."⁹

Man könnte das als isolierte Architekturentscheidung lesen. Ich lese es als Conway-Bestätigung. Cursor ist ein eng kommunizierendes Team, das eng gekoppelte Systeme baut. Conway würde das vorhersagen für ein Team dieser Größe. Das beweist nicht, dass der Monolith der Grund für den Erfolg ist. Aber es passt zur These.

Die DX-Forschung liefert dazu eine operationalisierbare Heuristik: Microservices "excel when teams grow beyond 10-15 developers."¹⁰ Darunter überwiegt der Overhead in den meisten Kontexten die Vorteile: eigene Deployment-Pipelines, Service Discovery, Netzwerklatenz, verteiltes Tracing. Das ist kein Absolutum, aber es ist ein brauchbarer Schwellenwert für die erste Abwägung.

Die Arithmetik ist dann folgende: Wenn AI Teams effektiv halbiert, durch Produktivitätssteigerung oder durch bewusste Teamverkleinerung, rutschen Organisationen unter diese Schwelle. Und Conway sagt: dann baut ihr Monolithen, ob ihr wollt oder nicht.

Die verschobene Beweislast

2015 brauchte man eine Begründung für den Monolithen. "Wir fangen klein an." "Noch kein sauberer Schnitt gefunden." "Erst Product-Market-Fit, dann Architektur." Das waren die Rechtfertigungen. Microservices galten als Zielzustand. Der Monolith war technische Schuld in Wartestellung.

Das hat sich gedreht. Für Teams, die tatsächlich kleiner werden oder bleiben.

Das ist kein neues Argument. DHH plädiert seit Jahren für den "Majestic Monolith"¹¹ und hat 2023 eine konkrete Anleitung veröffentlicht, wie Organisationen sich von voreilig eingeführten Microservices erholen können¹². Amazon Prime Video hat 2023 einen Monitoring-Service von Microservices auf Monolith umgestellt — 90% Kostenreduktion¹³. Kelsey Hightower formuliert den Kern seit 2020 so: Microservices sind keine Best Practice, sie sind ein Tradeoff — und der muss ehrlich evaluiert werden, basierend auf den tatsächlichen Bedingungen, nicht auf Branchenmode¹⁴.

Dieses "re-evaluate on schedule" ist der eigentliche Punkt. Und genau deshalb ist jetzt der richtige Zeitpunkt: AI verändert Teamgrößen. Wer seine Architekturentscheidung auf Annahmen über Teamstruktur gebaut hat, und das haben die meisten, muss prüfen, ob diese Annahmen noch gelten. Nicht weil Monolithen besser sind. Sondern weil sich die Eingabevariable geändert hat.

Die DX-Heuristik ist operationalisierbar¹⁰: Unter zehn bis fünfzehn Personen im Entwicklerteam ist Microservices als Default durch die Teamstruktur allein nicht gerechtfertigt. Es braucht andere Gründe: stark unterschiedliche Deployment-Frequenzen, unterschiedliche Skalierungsanforderungen, organisatorisch getrenntes Ownership. Die gibt es. Aber sie müssen jetzt erklärt werden.

Die Frage ist nicht mehr "Welche Services brauchen wir?", sondern "Wie groß ist unser Team wirklich, und wie kommuniziert es intern?" Conway kennt die Antwort, wenn man ihm die Teamgröße nennt.

Meine Perspektive

Was ich in Trainings und Kundengesprächen beobachte: Die Frage "Monolith oder Microservices?" wird selten explizit gestellt. Sie wird implizit durch die Teamgröße beantwortet. Manchmal bewusst, meistens nicht. Das Problem ist der Distributed Monolith, der dabei entsteht, wenn die Entscheidung unbewusst bleibt.

Technisch getrennt deployed, fachlich so eng gekoppelt, dass kein Service geändert werden kann, ohne fünf andere zu berühren. Das Schlimmste aus beiden Welten. Kelsey Hightower hat das 2017 vorhergesagt: "Monolithic applications will be back in style after people discover the drawbacks of distributed monolithic applications."¹⁵ Conway hätte dasselbe gesagt, nur formaler: Man wählt die Microservices-Form, behält aber die Monolith-Kommunikationsstruktur. Das Ergebnis ist kein Kompromiss. Es ist ein Anti-Pattern.

Was das für Architektinnen und Tech Leads bedeutet

Die eigentliche Handlungsempfehlung ist keine Architekturentscheidung. Es ist eine Diagnosefrage: Passt eure Architektur noch zu eurer Teamgröße?

Drei Schritte für Montag früh.

Erstens, die Kommunikationsstruktur kartieren. Wer spricht täglich mit wem? Wo sind die informellen Wissensträger? Wo entstehen Flaschenhälse, weil jemand auf eine andere Person warten muss? Das ist Conways Law als Diagnosewerkzeug.

Zweitens, die DX-Schwelle anwenden. Wenn das Entwicklungsteam unter zehn bis fünfzehn Personen liegt, durch AI-Effizienz, durch Wahl, durch Marktdruck, ist Microservices nicht der automatische Default mehr. Microservices brauchen jetzt eine aktive Begründung, keinen Freifahrtschein.

Drittens, auf den Distributed Monolith achten. Wenn Deployment-Einheiten technisch getrennt sind, die Änderungsfrequenz aber synchron bleibt, wenn ein Deployment drei Koordinationsmeetings erfordert, dann habt ihr keinen Microservices-Vorteil. Ihr habt Microservices-Overhead ohne Microservices-Nutzen.

Ein gut geschriebener Monolith, der für ein kleines Team verständlich und änderbar ist, schlägt ein schlecht verwaltetes Microservices-System. Definitiv. Die Frage ist, ob ihr das explizit entschieden habt, oder ob Conway's Law die Entscheidung für euch trifft.

Dieser Post ist Teil einer Serie über AI und Software-Architektur. Die vorherigen Teile behandeln die Fünf Stufen der KI-Entwicklung, Dark Factory Architektur und den Dark Factory Gap.

Wie dieser Artikel entstanden ist

Texterstellung mit Claude Opus 4.6. Das heißt in der Praxis nicht "AI schreibt, Mensch nickt ab", sondern ein iterativer Dialog: Ich liefere die These und die Kernquellen, das Modell schreibt einen ersten Entwurf, ich überarbeite Struktur und Argumentation, und dann gehen wir gemeinsam in die Recherche — welche Stimmen fehlen, welche Gegenargumente nicht stark genug adressiert sind, welche Referenzen den Artikel verbessern.

Den vollständigen Workflow beschreibe ich in AI-gestützte Wissensarbeit: Wie ich meinen Recherche- und Schreibprozess neu aufbaue.