Code zu schreiben war jahrzehntelang der Engpass. Du hattest eine Idee, und zwischen Idee und lauffähiger Software lagen Wochen Tipparbeit. Diese Zeit ist vorbei. Ein KI-Agent schreibt heute in einer Stunde, wofür ein Team früher einen Sprint gebraucht hat.
Damit verschiebt sich das eigentliche Problem. Wenn Code beliebig billig wird, ist nicht mehr die Frage, wie viel davon entsteht, sondern ob das, was entsteht, zusammenpasst. Die KI kann dir fünf Authentifizierungen bauen, die alle funktionieren und sich alle leicht unterscheiden. Sie kann es nur nicht wissen, dass du schon eine hast.
Genau hier wird das Monorepo interessant. Nicht als Geschmacksfrage unter Entwicklern, sondern als Antwort auf einen Mangel, der gerade erst entsteht: Im KI-Zeitalter ist nicht Code das knappe Gut, sondern der geteilte Kontext, in dem er Sinn ergibt.
Ein Monorepo ist kein Ordner, sondern ein Gedächtnis
Technisch ist die Sache schnell erklärt. Ein Monorepo ist ein gemeinsames Git-Repository, in dem mehrere Anwendungen, Services, Bibliotheken und Konfigurationen zusammen verwaltet werden. Das Gegenteil ist das Polyrepo: jedes Projekt in seinem eigenen, abgeschotteten Repository.
Im Monorepo sieht das so aus:
platform/
├── apps/
│ ├── travel-platform/
│ ├── rss-tool/
│ └── inventory-management/
├── shared/
│ ├── auth/
│ ├── ui/
│ ├── database/
│ └── ai-agents/
└── docs/
├── architecture-decisions/
└── coding-guidelines/Was nach Ordnerstruktur aussieht, ist in Wahrheit eine Aussage darüber, was zusammengehört. Die Reiseplattform und das RSS-Tool greifen auf dieselbe Authentifizierung zu, dieselben UI-Komponenten, denselben Datenbankzugriff. Sie teilen sich nicht nur Code, sie teilen sich eine Art zu bauen.
Ein Polyrepo verteilt dieses Wissen auf Dutzende Inseln, zwischen denen niemand schwimmt. Das Monorepo hält es an einem Ort. Es ist weniger ein Aufbewahrungsplatz für Dateien als das Gedächtnis einer Softwarelandschaft.
KI ist billig im Schreiben, teuer im Vergessen
Der Grund, warum das gerade jetzt zählt, liegt in der Funktionsweise der Werkzeuge. Ein KI-Coding-Agent wie Claude Code, Codex oder Cursor ist nur so gut wie der Kontext, den er sieht. Gib ihm ein leeres Repository, und er erfindet eine Architektur. Gib ihm ein gewachsenes Monorepo, und er liest sie ab.
In einem Monorepo kann ein Agent erkennen: So baut dieses Team APIs. So sieht hier Authentifizierung aus. Diese UI-Komponente gibt es schon. Diese Datenbankstruktur wird in drei Apps verwendet. Das ist kein kosmetischer Vorteil. Es ist der Unterschied zwischen einem Werkzeug, das deine Muster fortschreibt, und einem, das bei jedem Prompt neu anfängt.
Die Gefahr im KI-Zeitalter ist nicht zu wenig Code, sondern zu viel davon ohne Zusammenhang. Ohne gemeinsamen Rahmen entstehen in Wochen doppelte Module, drei UI-Stile, vier Auth-Mechanismen und ein Berg an Prototypen, den niemand mehr warten will. Die KI schreibt schneller, als ein Team vergisst — und das ist das Problem, nicht die Lösung.
Wiederverwendbarkeit ist keine Aufräum-Frage, sondern eine Tempo-Frage
Der naheliegende Einwand lautet: Module zentral zu pflegen kostet Disziplin, und Disziplin kostet Zeit. Stimmt. Nur rechnet diese Rechnung falsch herum.
Wenn deine Authentifizierung einmal in shared/auth liegt, sauber, geprüft, dokumentiert, dann ist die nächste App nicht ein neues Projekt, sondern eine neue Anwendung auf bestehendem Fundament. Du baust nicht wieder User, Rollen und Rechte. Du importierst sie. Was im Polyrepo fünf Mal entsteht und fünf Mal gewartet werden muss, entsteht hier einmal.
Der Tempo-Gewinn zeigt sich nicht beim ersten Projekt, sondern beim dritten. Beim ersten fühlt sich das gemeinsame Modul nach Mehraufwand an. Beim dritten ist es der Grund, warum die App in Tagen statt Wochen steht. Wiederverwendbarkeit sieht aus wie Ordnungsliebe, ist aber Geschwindigkeit auf Kredit.
Ein Monorepo erzwingt keine Ordnung, es macht Unordnung sichtbar
Hier ist die ehrliche Einschränkung, ohne die jeder Architektur-Text zur Werbung wird. Ein Monorepo ist kein Selbstläufer. Es kann groß und unübersichtlich werden. Builds und Tests müssen sauber organisiert sein, sonst wartet das ganze Haus auf eine Änderung in einer App. Zugriffsrechte werden komplizierter, wenn nicht jeder alles sehen soll. Und ohne klare Modulgrenzen entsteht im selben Repository genau das Chaos, das man vermeiden wollte.
Das Monorepo zwingt dich nicht zu guter Architektur. Es macht gute Architektur nur sichtbarer und wiederverwendbarer, und schlechte ebenso. Wenn drei Apps dieselbe Datenbank auf drei Arten ansprechen, siehst du es hier sofort, weil sie nebeneinanderliegen. Im Polyrepo bleibt derselbe Widerspruch unsichtbar, bis er teuer wird.
Das ist kein Argument gegen das Monorepo, sondern eines für die richtige Haltung dazu. Es lohnt sich nur, wenn man es als bewusste Plattform-Entscheidung behandelt, nicht als Ablageort. Ein Monorepo gibt dir keine Ordnung. Es gibt dir den Ort, an dem Unordnung nicht mehr versteckt bleibt.
Was keinen Namen hat, kann die KI nicht wiederfinden
Es gibt einen Hebel, der klein aussieht und groß wirkt: jedes Feature bekommt einen eindeutigen Namen, eine technische Zuordnung und eine kurze Dokumentation. „Smart Travel Highlights" ist dann nicht nur ein Begriff in einem Meeting, sondern eine Adresse.
docs/features/smart-travel-highlights.md
apps/travel-platform/features/smart-travel-highlights/
packages/ai-agents/smart-travel-highlights/Damit ist beantwortet, was sonst in jedem zweiten Gespräch neu geklärt wird: Was gehört zu diesem Feature? Wo liegt der Code? Welche KI-Logik steckt dahinter, welche UI nutzt es? Ein Feature-Katalog ist im KI-Zeitalter kein bürokratisches Beiwerk, sondern die Landkarte, ohne die generierte Funktionen im Wildwuchs verschwinden.
Und er verändert, wie du mit deinem Team und deinen Agenten sprichst. Ein guter Prompt fängt dann nicht bei null an, sondern sagt: Entwickle dieses Feature nach den bestehenden Konventionen, nutze die vorhandenen Shared Modules, dokumentiere es im Katalog. Was einen Namen und einen Platz hat, muss die KI nicht neu erfinden — sie kann es finden.
Vom Einzelprojekt zur Plattform
Am Ende ist die Frage nach dem Monorepo keine technische, sondern eine über das, was du baust. Willst du eine Sammlung einzelner Apps, von denen jede ihre eigene Welt mitbringt? Oder eine gemeinsame Plattform, auf der die nächste Anwendung schon halb fertig ist, bevor du anfängst?
Im ersten Fall ist ein Polyrepo ehrlicher, weil die Projekte wirklich nichts teilen. Im zweiten ist das Monorepo nicht Luxus, sondern Voraussetzung. Sobald mehrere Anwendungen dieselben Bausteine brauchen — Auth, Rollen, Design, Datenbank, KI-Agenten — wird der gemeinsame Ort vom Nice-to-have zur Bedingung dafür, dass die Teile überhaupt zueinanderfinden.
Die KI hat das Schreiben von Code zur leichtesten Disziplin gemacht. Schwer ist geworden, dass alles, was entsteht, dieselbe Sprache spricht. Ein Monorepo löst das nicht von allein. Aber es ist der einzige Ort, an dem die Antwort überhaupt entstehen kann. Code ist im Überfluss da. Knapp ist der gemeinsame Kontext, in dem er mehr wird als die Summe seiner Prompts.