Warum NX?

Weil Architektur ohne Modell nur Ordnerstruktur ist

„Warum eigentlich Nx?“

Die Frage klingt harmlos. Meistens bekommt man darauf auch harmlose Antworten.

Weil Monorepo. Weil Angular, Nest, React und Libraries zusammenpassen. Weil Builds schneller werden. Weil man damit Apps und Libs besser verwalten kann. Weil moderne Tools das halt so machen.

Das ist nicht falsch.

Aber es ist zu kurz.

Nx lohnt sich nicht, weil alles in einem Repository liegt. Nx lohnt sich, wenn ein Workspace ein Modell braucht.

Ein Modell für Projekte. Ein Modell für Abhängigkeiten. Ein Modell für Tasks. Ein Modell für Inputs und Outputs. Ein Modell für betroffene Änderungen. Ein Modell für CI. Ein Modell für Architekturregeln. Und zunehmend: ein Modell für Agenten, die nicht mehr blind im Dateibaum herumraten sollen.

Oder kürzer:

Nx macht aus Ordnern ein Arbeitsmodell.

Die falsche Antwort: Weil Monorepo

Der häufigste Reflex lautet:

Wir nehmen Nx, weil wir ein Monorepo wollen.

Das ist ungefähr so, als würde man sagen:

Wir bauen Architektur, weil wir Ordner brauchen.

Ein Monorepo ist erst einmal nur eine organisatorische Entscheidung. Es sagt: Mehrere Dinge liegen im gleichen Repository.

Das allein ist noch keine Architektur.

Man kann in einem Monorepo sehr saubere Grenzen haben. Man kann darin aber auch eine hervorragend versionierte Müllhalde bauen. Mit shared, common, utils, wilden Imports, impliziten Abhängigkeiten und einer CI, die bei jeder Änderung einmal den kompletten Maschinenraum anwirft.

Das Repository ist nicht der spannende Teil.

Der spannende Teil ist die Frage:

Versteht dein Workspace, was in ihm passiert?

Weiß er, welche App von welcher Library abhängt? Weiß er, welche Tests relevant sind? Weiß er, welche Änderung welches Deployment betrifft? Weiß er, welche Boundary verletzt wurde? Weiß er, welche Tasks welche Inputs haben? Weiß er, welche Artefakte entstehen?

Wenn die Antwort nein ist, hast du vielleicht ein Monorepo.

Aber noch kein Architekturmodell.

Was Nx eigentlich ist

Nx ist nicht einfach:

• ein Monorepo-Tool
• ein Build-Wrapper
• Angular CLI mit mehr Dateien
• eine Sammlung von Generatoren
• ein Grund, alles in ein Repo zu werfen
• ein magisches CI-Beschleunigungsgerät
• ein Ersatz für Architekturentscheidungen

Nx ist eher ein Werkzeug, das einen Workspace explizit macht.

Es modelliert Projekte, Abhängigkeiten, Targets, Tasks, Inputs, Outputs, Generatoren, Regeln, Caches und Änderungsfolgen.

Nx beschreibt nicht nur Dateien. Nx beschreibt Arbeit, Abhängigkeiten und Änderungsfolgen.

Das klingt zunächst trocken.

Ist es aber nicht.

Denn genau dort beginnt Architektur praktisch zu werden.

Nicht als Diagramm im Wiki. Nicht als PowerPoint mit Kästchen. Nicht als „sollte eigentlich so sein“.

Sondern als ausführbares Modell.

Das Nx-Meta-Modell

Der wichtigste Teil von Nx ist nicht das Monorepo.

Der wichtigste Teil ist der Graph.

Genauer: die Kombination aus Project Graph, Task Graph, Targets, Inputs, Outputs, Tags und Regeln.

Nx modelliert Fragen wie:

• Was ist ein Projekt?
• Wovon hängt es ab?
• Welche Tasks kann es ausführen?
• Welche Inputs beeinflussen diese Tasks?
• Welche Outputs entstehen?
• Welche Projekte sind von einer Änderung betroffen?
• Welche Regeln gelten zwischen Projekten?
• Welche Tags beschreiben Rollen, Schichten oder Domänen?
• Welche Targets sind standardisiert?
• Welche Artefakte entstehen für CI und Deployment?

Das ist das eigentliche Meta-Modell.

Nicht, weil es besonders akademisch klingt. Sondern weil es den Workspace nicht nur als Dateisammlung betrachtet, sondern als System aus Arbeitseinheiten und Abhängigkeiten.

Ein Projekt ist dann nicht einfach ein Ordner unter apps oder libs.

Ein Projekt ist ein Knoten im Arbeitsmodell.

Es hat Aufgaben. Es hat Abhängigkeiten. Es hat Grenzen. Es hat erlaubte und unerlaubte Beziehungen. Es kann betroffen sein. Es kann gebaut, getestet, geprüft, veröffentlicht oder deployed werden.

Das ist architektonisch wertvoll, weil Struktur nicht nur dokumentiert wird.

Sie wird ausführbar.

Der Graph ist unangenehm ehrlich

Architekturdiagramme haben ein Problem.

Sie zeigen oft, wie ein System gemeint war.

Der Code zeigt, was daraus geworden ist.

Der Nx Graph liegt unangenehm nah an der zweiten Wahrheit.

Ein Architekturdiagramm im Wiki zeigt, wie ein System gemeint war. Der Nx Graph zeigt, wie der Workspace tatsächlich gekoppelt ist.

Das kann schön sein.

Es kann aber auch weh tun.

Wenn eine kleine UI-Library plötzlich von halben Feature-Bereichen abhängt. Wenn eine Domain-Lib heimlich Infrastructure importiert. Wenn jede App auf dieselbe shared-Kiste greift. Wenn ein Feature angeblich isoliert ist, aber der Graph aussieht wie gekochte Spaghetti.

Dann ist Nx nicht das Problem.

Nx hält nur den Spiegel hoch.

Der Graph ist unangenehm ehrlich.

Und genau deshalb ist er wertvoll.

Nx als Architekturwerkzeug

Nx ist dann stark, wenn Architektur nicht nur diskutiert, sondern überprüft werden soll.

Zum Beispiel:

• Welche Domäne darf welche andere Domäne importieren?
• Darf eine UI-Library auf eine Data-Access-Library zugreifen?
• Darf ein Feature direkt Infrastructure-Code verwenden?
• Dürfen Apps interne Pfade anderer Libraries importieren?
• Gibt es klare Public APIs?
• Sind vertikale Slices wirklich vertikal geschnitten?
• Sind technische Utilities harmlos oder längst versteckte Domänenlogik?
• Welche Änderung zieht welche Tests, Builds oder Deployments nach sich?

Das ist der Punkt, an dem Nx über „Build Tool“ hinausgeht.

Natürlich kann Nx bauen, testen, linten und cachen.

Aber der interessantere Teil ist:

Nx kann dabei helfen, Architekturregeln maschinenlesbar zu machen.

Nicht perfekt. Nicht vollständig. Nicht als Ersatz für Denken.

Aber als sehr brauchbares Feedbacksystem.

Was Nx gut kann

Nx kann große Workspaces strukturieren.

Aber nicht dadurch, dass es magisch gute Ordner erzeugt. Sondern dadurch, dass es Projekte als zusammenhängende Einheiten sichtbar macht.

Nx kann Abhängigkeiten sichtbar machen.

Das klingt banal, bis man zum ersten Mal sieht, dass der eigene „saubere“ Workspace in Wahrheit über drei shared-Libraries und fünf Direktimporte zusammengehalten wird.

Nx kann Project Graph und Task Graph bereitstellen.

Der Project Graph zeigt, was wovon abhängt. Der Task Graph zeigt, welche Arbeit in welcher Reihenfolge ausgeführt werden muss.

Das ist ein Unterschied.

Eine Library kann fachlich harmlos aussehen, aber für CI teuer sein. Ein Task kann isoliert wirken, aber viele andere Tasks nachziehen. Nx macht solche Zusammenhänge greifbarer.

Nx kann betroffene Projekte berechnen.

Das ist für CI wichtig. Aber es ist auch Architekturfeedback.

Dazu später mehr.

Nx kann Builds, Tests und Lints gezielt ausführen.

In großen Workspaces ist das kein Luxus. Es ist irgendwann die Grenze zwischen „CI ist Teil des Entwicklungsflusses“ und „CI ist der Ort, an dem Pull Requests altern“.

Nx kann teure Checks auf betroffene Bereiche begrenzen.

Nicht jeder Commit muss alles bauen. Nicht jeder Style-Fix muss jedes Deployment anfassen. Nicht jede Änderung an einer isolierten Library sollte den gesamten Workspace in Panik versetzen.

Nx kann Code konsistent generieren.

Generatoren sind nicht nur Komfort. Gute Generatoren transportieren Architekturentscheidungen. Schlechte Generatoren verteilen Sonderfälle schneller.

Nx kann Architekturregeln über Tags und Boundaries prüfbar machen.

Das ist besonders spannend, wenn Tags nicht nur dekorative Etiketten sind, sondern echte Bedeutung tragen:

• Domäne
• Schicht
• Typ
• Runtime
• Ownership
• Deployment-Kontext

Nx kann Migrationen strukturieren.

Gerade in langlebigen Workspaces ist das wichtig. Architektur ist nicht nur initiale Schönheit. Architektur ist Änderbarkeit über Zeit.

Nx kann wiederkehrende Targets standardisieren.

Wenn jedes Projekt build, test, lint, docker:build, serve, e2e oder deploy anders nennt, hat man kein Tooling-Modell mehr. Man hat Folklore.

Nx kann Fullstack-Arbeitsräume verbinden.

Frontend, API, Services, Domain-Libs, UI-Libs, E2E-Tests, Docker Targets und Deployment-Schritte können im gleichen Arbeitsmodell sichtbar werden.

Das ist besonders wertvoll in SCS-, Microfrontend- oder vertikal geschnittenen Fullstack-Workspaces.

Host, Remote, API, Service, Domain-Lib, UI-Lib, Tests und Deployment sind dann nicht lose Artefakte in zufälligen Ordnern.

Sie sind Teile eines modellierten Arbeitsraums.

Und Nx kann Agenten und Tools mit maschinenlesbarem Kontext versorgen.

Das wird wichtiger, als viele gerade wahrhaben wollen.

Was Nx nicht kann

Jetzt der unangenehme Teil.

Nx kann keine fachlichen Boundaries erfinden.

Wenn niemand weiß, wo die Domäne endet, kann Nx das nicht herbeizaubern.

Nx kann schlechte Architektur nicht reparieren.

Es kann sie sichtbar machen. Es kann Regeln prüfbar machen. Es kann Auswirkungen zeigen. Aber es entscheidet nicht für dich, ob etwas App, Feature-Lib, Domain-Lib, Data-Access-Lib oder Utility sein sollte.

Nx kann kein Ownership erzeugen.

Wenn sich niemand für eine Library verantwortlich fühlt, wird sie nicht dadurch besser, dass sie im Graphen hübsch angezeigt wird.

Nx kann keine Teamstruktur klären.

Wenn fünf Teams dieselben Libraries anfassen, dieselben APIs verbiegen und dieselben Workarounds einbauen, dann ist der Workspace nicht das Problem. Er ist nur der Tatort.

Nx kann fehlende Tests nicht ersetzen.

Affected Tests sind nur dann hilfreich, wenn es Tests gibt, die etwas aussagen.

Ein schneller leerer Testlauf ist kein Qualitätsmerkmal. Er ist nur schnell.

Nx kann aus schlechten Generatoren keine gute Architektur machen.

Ein Generator, der schlechte Schnitte erzeugt, skaliert schlechte Schnitte.

Immerhin konsistent. Aber eben konsistent falsch.

Nx kann fehlende Disziplin nicht kompensieren.

Man kann Boundary-Regeln definieren und sie danach umgehen. Man kann Tags pflegen oder verrotten lassen. Man kann Public APIs ernst nehmen oder überall tiefe interne Pfade importieren.

Nx kann eine Müllhalde namens shared nicht retten.

Das muss man selbst tun.

Nx ist kein Ersatz für Architekturarbeit. Es ist ein Werkzeug, um Architekturarbeit sichtbarer und prüfbarer zu machen.

Oder etwas gemeiner:

Nx löst keine schlechte Architektur.

Es macht sie nur schneller sichtbar.

Affected ist Architekturfeedback

Viele Teams betrachten affected zuerst als CI-Performance-Feature.

Das ist verständlich.

Wenn ein Workspace wächst, werden Builds langsam. Tests werden teuer. Lints dauern. Docker Builds stapeln sich. E2E-Tests blockieren. Deployments werden vorsichtig, weil niemand mehr sicher weiß, was eine Änderung wirklich betrifft.

Dann klingt nx affected wie die Erlösung.

Nur betroffene Projekte bauen. Nur betroffene Tests ausführen. Nur betroffene Lints prüfen. Nur betroffene Docker Images bauen. Nur betroffene Deployments anstoßen.

Das ist stark.

Aber es ist mehr als Performance.

Affected ist Architekturfeedback.

Nx kann berechnen, welche Projekte von einer Änderung betroffen sind. Daraus lassen sich gezielt ausführen:

• Builds
• Tests
• Lints
• E2E-Tests
• Docker Builds
• Deployments
• Format-Checks
• Quality Gates
• Release-Schritte

Das verändert die CI-Frage.

Viele Teams reagieren auf langsame CI zuerst mit mehr Technik:

Mehr Runner. Mehr Parallelisierung. Mehr Caching. Mehr Dashboards. Mehr YAML-Akrobatik. Mehr „das läuft nachts“.

Nx dreht die Frage um.

Nicht:

Was können wir alles ausführen?

Sondern:

Was ist von dieser Änderung wirklich betroffen?

Das ist eine andere Denkweise.

Nicht alles bauen, nur weil man es kann.

Affected funktioniert nur, wenn der Graph die Realität beschreibt

Affected Strategies sind nur dann stark, wenn der Graph echte Grenzen kennt.

Das ist der Haken.

Wenn alles mit allem verdrahtet ist, ist am Ende auch alles affected.

Das ist kein Nx-Problem.

Das ist die Architektur, die sich im Graphen räuspert.

Wenn eine kleine Änderung plötzlich den halben Workspace affected macht, ist das keine schlechte Nachricht von Nx. Es ist eine ehrliche Nachricht über Kopplung.

Natürlich kann man dann versuchen, die CI trotzdem schneller zu bekommen. Mehr Cache. Mehr Parallelisierung. Mehr Ausschlüsse. Mehr Sonderregeln.

Kann man machen.

Aber irgendwann optimiert man nicht mehr CI.

Man betäubt Architekturfeedback.

Ein sauber geschnittener Workspace hat einen anderen Effekt:

Eine Änderung in einer isolierten Domain-Lib betrifft wenige Consumer. Eine Änderung in einer UI-Komponente betrifft relevante Apps, aber nicht beliebige Services. Eine Änderung in einem SCS betrifft dessen Remote, API, Service, Tests und Deployment, aber nicht automatisch den gesamten Workspace. Eine Änderung an einer zentralen Basis-Library darf viel betreffen — aber dann sollte allen klar sein, dass diese Library zentral ist.

Affected ist damit nicht nur ein Trick.

Es ist ein Lügendetektor.

Wenn der Graph ständig sagt „alles ist betroffen“, dann ist vielleicht nicht der Graph zu pessimistisch.

Vielleicht ist die Architektur zu ehrlich gekoppelt.

CI ist Nutzer des Architekturmodells

CI wird oft wie ein technischer Nachgedanke behandelt.

Da liegen dann ein paar Jobs. Ein paar Stages. Ein paar npm Scripts. Irgendwo Docker. Irgendwo Tests. Irgendwo Deployments. Und wenn es langsam wird, wird eben noch ein Runner daneben gestellt.

Das kann eine Weile funktionieren.

Aber in größeren Workspaces wird CI selbst zum Architektur-Consumer.

CI muss wissen:

• Welche Projekte gibt es?
• Welche Targets sind relevant?
• Welche Projekte sind deploybar?
• Welche Tests gehören zu welcher Änderung?
• Welche Docker Images müssen gebaut werden?
• Welche Services müssen deployed werden?
• Welche Artefakte entstehen?
• Welche Stacks hängen zusammen?
• Welche Änderung ist harmlos und welche systemrelevant?

Wenn CI diese Dinge nicht aus dem Workspace-Modell ableiten kann, entstehen Sonderwege.

YAML weiß Dinge, die Nx nicht weiß. Shell-Skripte wissen Dinge, die der Graph nicht weiß. Deployment-Matrizen wissen Dinge, die in keiner Architekturregel stehen. Und irgendwann weiß niemand mehr, welches Wissen eigentlich wo liegt.

Nx kann hier helfen, weil Targets, affected analysis und Projektmetadaten eine gemeinsame Sprache liefern.

Aber nur, wenn CI den Graphen auch wirklich nutzt.

Wenn CI Nx nur als komplizierten npm-script-Starter verwendet, ist wenig gewonnen.

Dann steht zwar nx im Log.

Aber das Modell bleibt ungenutzt.

Die Customizing-Falle

Customizing ist verführerisch.

Und manchmal absolut sinnvoll.

Eigene Generatoren können helfen, eine konsistente SCS-Struktur zu erzeugen. Standardisierte Targets können dafür sorgen, dass jedes deploybare Projekt gleich gebaut wird. Tags können Domänen, Schichten, Typen oder Runtime-Kontexte ausdrücken. Deployment-Konventionen können ins Tooling wandern, statt in zehn Confluence-Seiten zu verstauben.

Das ist gutes Customizing.

Es drückt Architekturregeln aus.

Gefährlich wird es, wenn Customizing die Tooling-Konventionen ersetzt oder versteckt.

Dann hat jedes Projekt eigene Target-Namen. Generatoren erzeugen Sonderfälle. Shell-Skripte umgehen den Graphen. CI nutzt Nx nur noch als dünnen Wrapper. Migrationspfade werden schwieriger. Neue Entwickler verstehen das System nicht. Agenten verstehen das System noch schlechter. Wissen wandert in Custom-Skripte. Der Graph zeigt Struktur, aber nicht mehr Verhalten.

Dann baut man sich sein eigenes Build-System.

Nur mit Nx-Logo.

Customizing ist dort sinnvoll, wo es Architekturregeln ausdrückt. Es ist gefährlich, wenn es Tooling-Konventionen ersetzt.

Je stärker man Nx verbiegt, desto weniger Wert hat das gemeinsame Modell.

Und das gemeinsame Modell ist der eigentliche Grund, warum Nx interessant ist.

Nicht die Fähigkeit, beliebige Shell-Skripte unter einem anderen Namen auszuführen.

Anti-Patterns: shared, common, utils und andere Parkplätze

Jeder größere Workspace entwickelt irgendwann Orte, an denen Entscheidungen verschwinden.

Sie heißen meistens:

• shared
• common
• utils
• core
• base
• misc
• helpers

Natürlich ist nicht jede Utility-Library schlecht.

Aber viele dieser Ordner sind keine Architekturkonzepte.

Sie sind Parkplätze für Entscheidungen, die niemand treffen wollte.

shared ist oft kein Architekturkonzept. Es ist ein Parkplatz für Entscheidungen, die niemand treffen wollte.

Das Problem ist nicht der Name allein.

Das Problem ist die Bedeutungslosigkeit.

Wenn alles shared ist, ist nichts mehr geschützt.

Dann importieren Features beliebige Helfer. Apps greifen tief in interne Pfade. Domain-Code landet in technischen Utilities. UI-Logik sickert in Data-Access. Tests hängen an zufälligen Details. Und irgendwann weiß niemand mehr, wem etwas gehört.

Typische Nx-Fallen sehen so aus:

• Alles landet in shared
• Alles landet in common
• Alles landet in utils
• technische Libraries haben keinen fachlichen Schnitt
• Feature-Libs importieren alles
• Apps greifen tief in interne Lib-Pfade
• es gibt keine klaren Public APIs
• Tags existieren, werden aber nicht gepflegt
• Boundary-Regeln sind definiert, werden aber umgangen
• es gibt zu viele Mini-Libraries ohne fachlichen Grund
• es gibt zu wenige Libraries, sodass alles zentral wird
• Generatoren erzeugen Code, aber keine Architektur
• CI ruft Nx auf, nutzt aber keine affected Logik
• affected wird erwartet, aber Abhängigkeiten sind überall
• jedes Team baut eigene Konventionen
• Nx wird als Ersatz für Architekturentscheidungen missverstanden
• der Graph wird ignoriert, bis CI langsam ist

Das Gemeine daran:

Nx macht diese Dinge sichtbar.

Aber es verhindert sie nicht automatisch.

Ein Workspace braucht weiterhin Entscheidungen.

Welche fachlichen Bereiche gibt es? Welche technischen Schichten sind sinnvoll? Welche Libraries dürfen stabil geteilt werden? Welche Dinge gehören bewusst nicht geteilt? Welche Public APIs sind erlaubt? Welche Imports sind verboten? Welche Generatoren transportieren echte Architektur? Welche Targets müssen standardisiert sein?

Ohne diese Entscheidungen wird Nx nicht zum Architekturwerkzeug.

Dann wird es nur zur schnelleren Verwaltung einer größeren Unordnung.

Wann Nx sinnvoll ist

Nx ist sinnvoll, wenn ein Workspace mehr braucht als Ordner und npm Scripts.

Zum Beispiel bei:

• mehreren Apps
• mehreren Libraries
• mehreren Teams
• Frontend + Backend + API + Services in einem Workspace
• Microfrontends
• Module Federation
• Self-contained Systems
• vertikalen Slices
• wiederkehrenden Architekturregeln
• hohen CI-Kosten
• vielen Pull Requests
• Bedarf an affected builds und affected tests
• standardisierten Generierungen
• klaren Boundaries
• langfristiger Produktentwicklung
• Agentic Workflows, die Kontext brauchen
• Workspaces, bei denen Änderungen präzise eingegrenzt werden müssen

Gerade in einem SCS-, Microfrontend- oder Fullstack-Workspace kann Nx sehr stark sein.

Ein fachlicher Bereich besteht dort nicht nur aus einer Backend-API.

Er kann bestehen aus:

• Remote
• API
• Service
• Domain-Libs
• UI-Libs
• Data-Access
• Tests
• E2E
• Docker Targets
• Deployment-Schritten

Das alles kann in Nx als zusammenhängender, aber begrenzter Arbeitsraum modelliert werden.

Nicht, weil alles wild zusammengehört.

Sondern weil die Zusammenhänge explizit sind.

Das ist ein wichtiger Unterschied.

Ein guter Nx-Workspace sagt nicht:

Alles darf alles kennen.

Er sagt:

Wir wissen, was was kennen darf.

Wann Nx Overkill ist

Nx ist nicht immer die richtige Antwort.

Manchmal reicht eine einfache Struktur.

Und das ist völlig in Ordnung.

Nx ist vermutlich Overkill bei:

• einer kleinen Einzel-App
• einem Team
• kaum shared Code
• wenig CI-Komplexität
• Prototypen
• Wegwerfprojekten
• sehr einfachen Repos
• Projekten, bei denen Angular CLI, Vite oder npm Scripts völlig reichen
• Teams, die kein Modell pflegen wollen

Der letzte Punkt ist wichtig.

Wenn niemand den Graphen ernst nimmt, ist Nx nur eine kompliziertere Art, npm scripts auszuführen.

Dann zahlt man die Komplexität, bekommt aber nicht den eigentlichen Nutzen.

Nx braucht Pflege.

Nicht übertrieben. Nicht religiös. Nicht als Tool-Fetisch.

Aber Tags, Boundaries, Targets, Generatoren und Projektstruktur müssen ernst genommen werden.

Sonst ist der Graph irgendwann nur noch ein buntes Bild, das man bei Architekturmeetings kurz öffnet, um danach wieder alles direkt zu importieren.

Nx und Agentic Workflows

Jetzt kommt der Teil, der in den nächsten Jahren deutlich wichtiger wird.

Für Menschen ist der Nx Graph ein Architekturdiagramm.

Für Agenten ist er ein Navigationssystem.

Coding-Agenten brauchen Kontext.

Nicht nur Dateien.

Sie müssen wissen:

• Welche Projekte gibt es?
• Was hängt wovon ab?
• Welche Tests sind relevant?
• Welche Commands existieren?
• Welche Grenzen dürfen nicht verletzt werden?
• Welche Library darf wohin importieren?
• Welcher API-Service gehört zu welchem Frontend?
• Welche Änderung betrifft DB, Backend, API, UI und Tests?
• Welche Targets müssen nach einer Änderung laufen?
• Welche Projekte dürfen überhaupt geändert werden?
• Welche Artefakte entstehen für Build, Test und Deployment?

Ein Mensch kann sich vieles mühsam erschließen.

Er liest Ordner, sucht Imports, fragt Kollegen, klickt durch CI, findet alte Tickets, interpretiert Namen und entwickelt irgendwann ein Gefühl für das System.

Ein Agent hat dieses Gefühl nicht automatisch.

Er braucht ein Modell.

Wenn er nur den Dateibaum sieht, rät er.

Und Agenten, die raten, sind beeindruckend schnell darin, Chaos zu produzieren.

Nx kann hier helfen, weil es den Workspace maschinenlesbar macht.

Der Agent muss nicht blind fragen:

Wo sind die relevanten Tests?

Er kann über Targets und affected analysis näher an die Antwort kommen.

Er muss nicht nur raten:

Welche Projekte hängen zusammen?

Der Graph liefert einen Ausgangspunkt.

Er muss nicht beliebig importieren:

Wird schon passen.

Boundary-Regeln können ihm Grenzen geben.

Aber auch hier gilt:

Nx hilft nur, wenn der Workspace sauber gepflegt ist.

Wenn alles Custom-Skripte, Sonderfälle, wilde Imports und ungepflegte Tags sind, versteht auch ein Agent nur Chaos schneller.

Agenten skalieren nicht nur Produktivität.

Sie skalieren auch Unordnung.

Je mehr Code von Agenten verändert wird, desto wichtiger wird ein maschinenlesbares Architekturmodell.

Nicht, weil Agenten Architektur ersetzen.

Sondern weil sie sonst ohne Architekturmodell arbeiten.

Und das ist ungefähr so beruhigend wie ein Praktikant mit Root-Rechten und sehr viel Selbstvertrauen.

Die bessere Frage

Die bessere Frage ist also nicht:

Sollten wir Nx nehmen?

Die bessere Frage ist:

Braucht unser Workspace ein ausführbares Modell?

Wenn die Antwort nein ist, ist Nx wahrscheinlich nicht nötig.

Wenn die Antwort ja ist, wird Nx interessant.

Dann sollte man aber nicht bei „Monorepo“ stehen bleiben.

Dann geht es um Architektur.

Schneide Projekte bewusst. Definiere klare Public APIs. Nutze Tags nicht als Dekoration. Nutze Boundary-Regeln ernsthaft. Standardisiere Targets. Nutze affected nicht nur für Geschwindigkeit, sondern als Architekturfeedback. Halte Generatoren klein, konsistent und sinnvoll. Vermeide shared als Müllhalde. Behandle CI als Nutzer des Architekturmodells. Behandle Agenten als zukünftige Nutzer des Architekturmodells. Customizing nur dort, wo es Regeln ausdrückt — nicht dort, wo es Konventionen zerstört.

Nx ist kein Zauberstab.

Es ist ein Verstärker.

Es verstärkt gute Struktur.

Und es macht schlechte Struktur lauter.

Merksatz

Der wichtigste Teil von Nx ist nicht das Monorepo.

Der wichtigste Teil ist der Graph.

Nx lohnt sich nicht, weil alles in einem Repo liegt. Nx lohnt sich, wenn dein Workspace ein Modell braucht: für Menschen, CI und Agenten.

Oder noch kürzer:

Nx ist dann stark, wenn der Graph die Architektur beschreibt. Wenn alles mit allem verdrahtet ist, beschreibt er nur ehrlich das Problem.