Eine KI-generierte Codebasis für Web, Mobile und APIs

Was „eine KI-generierte Codebasis“ bedeutet

„Eine Codebasis“ heißt selten eine UI, die überall gleich läuft. Praktisch bedeutet es meist ein Repository und ein gemeinsamer Satz von Regeln — mit separaten Auslieferungsflächen (Web-App, Mobile-App, API), die alle von denselben zugrunde liegenden Geschäftsentscheidungen abhängen.

Geteilte Logik vs. geteilte UI

Ein nützliches Denkmodell ist, die Teile zu teilen, die niemals widersprüchlich sein sollten:

• Domain-Regeln: Berechnungen, Eligibility-Checks, Preisbildung, Workflows, Invarianten.
• Use Cases: „Bestellung erstellen“, „Abo kündigen“, „Rückerstattung ausstellen“ usw.
• Datenverträge: Request-/Response-Formen, Validierungsregeln, Fehlercodes.

Gleichzeitig teilst du normalerweise nicht die UI-Schicht vollständig. Web und Mobile haben unterschiedliche Navigationsmuster, Accessibility-Erwartungen, Performance-Einschränkungen und Plattformfeatures. UI-Sharing kann in manchen Fällen sinnvoll sein, ist aber nicht die Definition einer „einzigen Codebasis“.

Was KI ändert (und was nicht)

KI-generierter Code kann die Geschwindigkeit immens erhöhen bei:

• Projektscaffolds (Ordner, Build-Skripte, Basiskomponenten)
• Generieren von CRUD-Endpunkten und Clients
• Erstellen von Tests und Fixtures aus Beispielen

Aber KI produziert nicht automatisch eine kohärente Architektur. Ohne klare Grenzen tendiert sie dazu, Logik zu duplizieren, Anliegen zu vermischen (UI ruft direkt DB-Code) und „fast gleiche“ Validierungen mehrfach zu erzeugen. Der Hebel liegt darin, zuerst die Struktur zu definieren — und KI dann für repetitive Teile zu nutzen.

Ergebnisse, auf die du hinarbeiten solltest

Eine erfolgreiche, KI-unterstützte Codebasis liefert:

• Konsistenz: Web, Mobile und API erzwingen dieselben Regeln.
• Geschwindigkeit: Neue Features werden einmal implementiert und überall verfügbar gemacht.
• Wartbarkeit: Änderungen sind lokalisiert, werden reviewt, getestet und vorhersehbar releast.

Ziele und Beschränkungen für Web-, Mobile- und API-Auslieferung

Eine gemeinsame Codebasis funktioniert nur, wenn klar ist, was sie erreichen muss — und was sie nicht standardisieren sollte. Web, Mobile und APIs bedienen unterschiedliche Zielgruppen und Nutzungsarten, auch wenn sie dieselben Geschäftsregeln teilen.

Wen du bedienst (und wie)

Die meisten Produkte haben mindestens drei „Eingangstüren“:

• Web-App-Nutzer (Kunden, Admins, Support), die schnelle Navigation, Accessibility und einfache Updates erwarten.
• Mobile-Nutzer, die native-gefühlte Interaktionen, Offline-Unterstützung und effiziente Nutzung von Batterie/Netzwerk erwarten.
• Third-Party-Integrationen (Partner, interne Systeme, Automatisierung), die stabile APIs, klare Verträge und vorhersehbares Fehlerverhalten benötigen.

Das Ziel ist Konsistenz im Verhalten (Regeln, Berechtigungen, Berechnungen) — nicht identische Erlebnisse.

Nicht-Ziele: erzwinge nicht identische UX

Ein häufiger Fehler ist, „ein Codebasis“ als „eine UI“ zu behandeln. Das liefert meist eine web-ähnliche Mobile-App oder eine mobile-ähnliche Web-App — beides frustrierend.

Strebe stattdessen an für:

• Geteilte Domain-Logik und Validierung
• Geteilte Datenmodelle und API-Verträge
• Plattform-spezifisches Präsentations- und Interaktionsdesign

Wichtige Beschränkungen, die früh geplant werden sollten

Offline-Modus: Mobil braucht oft Lesezugriff (und manchmal Schreiben) ohne Netzwerk. Das impliziert lokalen Speicher, Sync-Strategien, Konfliktbehandlung und klare „Source-of-Truth“-Regeln.

Performance: Web achtet auf Bundle-Größe und Time-to-Interactive; Mobile auf Startzeit und Netzwerkeffizienz; APIs auf Latenz und Durchsatz. Code-Sharing darf nicht bedeuten, unnötige Module an jeden Client auszuliefern.

Sicherheit und Compliance: Authentifizierung, Autorisierung, Audit-Trails, Verschlüsselung und Datenaufbewahrung müssen über alle Oberflächen konsistent sein. In regulierten Bereichen sollten Anforderungen wie Logging, Einwilligung und Least-Privilege-Access von Anfang an eingeplant werden — nicht als Nachtrag.

Referenzarchitektur: Schichten und Verantwortlichkeiten

Eine gemeinsame Codebasis funktioniert am besten, wenn sie in klare Schichten mit strikten Verantwortlichkeiten organisiert ist. Diese Struktur macht es auch einfacher, KI-generierten Code zu prüfen, zu testen und zu ersetzen, ohne Unbekanntes zu brechen.

Großer Ablauf

Hier ist die grundlegende Form, auf die die meisten Teams zusteuern:

Clients (Web / Mobile / Partners)
          ↓
     API Layer
          ↓
    Domain Layer
          ↓
 Data Sources (DB / Cache / External APIs)

Die Kernidee: Benutzeroberflächen und Transportdetails sitzen am Rand, während Geschäftsregeln im Zentrum verbleiben.

Was geteilt wird

Der „teilbare Kern“ umfasst alles, was überall gleich funktionieren sollte:

• Domain (Geschäftslogik): Preisregeln, Eligibility-Checks, Bestellzustandsübergänge usw.
• Validierung: Eingaberegeln und Fehlermeldungen, gemappt auf konsistente Fehlercodes.
• Netzwerk + Schemata: API-Request/Response-Typen, Serialisierung und Contract-Tests.

Wenn KI neue Features generiert, ist das beste Ergebnis: die Domain-Regeln werden einmal aktualisiert und alle Clients profitieren automatisch.

Was unterschiedlich bleiben sollte

Einige Teile sind zu teuer oder riskant, um sie in eine gemeinsame Abstraktion zu zwingen:

• UI-Komponenten: Web-Designsysteme vs. native Controls.
• Navigation und Nutzerflüsse: Browser-Routing vs. Mobile-Stacks.
• Gerätefähigkeiten: Push, Biometrie, Kamera, Offline-Speicherung.

Praktische Regel: Wenn der Nutzer es sehen kann oder das OS es brechen kann, halte es app-spezifisch. Wenn es eine Geschäftsentscheidung ist, behalte es in der Domain.

Verantwortlichkeiten pro Schicht

• API-Schicht: Authentifizierung, Rate-Limiting, Mapping HTTP/GraphQL zu Domain-Commands.
• Domain-Schicht: Pure Regeln und Use Cases, minimale Abhängigkeiten.
• Datenquellen: Datenbanken und Drittsysteme hinter Interfaces, sodass Implementierungen geändert werden können, ohne Geschäftslogik umzuschreiben.

Gemeinsame Domain-Schicht (Geschäftslogik)

Die gemeinsame Domain-Schicht sollte sich „langweilig“ anfühlen — im besten Sinn: vorhersehbar, testbar und wiederverwendbar. Wenn KI euch beim Aufbau hilft, ist diese Schicht der Anker: Web-Screens, Mobile-Flows und API-Endpunkte spiegeln dieselben Regeln wider.

Beginne mit Nomen und Verben

Definiere Kerntypen als Entities (Identität über Zeit, z. B. Account, Order, Subscription) und Value Objects (durch ihren Wert definiert, z. B. Money, EmailAddress, DateRange). Erfasse Verhalten als Use Cases (Application Services): „Create order“, „Cancel subscription“, „Change email“.

Diese Struktur macht die Domain verständlich für Nicht-Spezialisten: Nomen beschreiben was existiert, Verben beschreiben was das System tut.

Halte Geschäftsregeln UI-agnostisch

Die Geschäftslogik sollte nicht wissen, ob sie durch einen Button-Tap, ein Web-Formular oder eine API-Anfrage ausgelöst wird. Praktisch heißt das:

• Keine Framework-Imports (keine Web-Controller, Mobile-Views oder ORM-Annotationen in Domain-Code)
• Keine UI-Strings (Fehlercodes oder Keys statt fest codierter Nachrichten)
• Keine Netzwerkannahmen (die Domain sollte nicht „die API aufrufen“, sondern Regeln ausdrücken)

Wenn KI Code erzeugt, geht diese Trennung leicht verloren — behandel das als Refactor-Trigger, nicht als Präferenz.

Ein Satz Validierungsregeln für überall

Validierung ist ein häufiger Drift-Punkt: Web erlaubt etwas, das die API ablehnt, oder Mobile validiert anders. Lege konsistente Validierung in die Domain-Schicht (oder ein gemeinsames Validierungsmodul), sodass alle Oberflächen dieselben Regeln durchsetzen.

Beispiele:

• EmailAddress validiert das Format einmal und wird in Web/Mobile/API wiederverwendet
• Money verhindert negative Totale, egal woher der Wert kommt
• Use Cases erzwingen feldübergreifende Regeln (z. B. „Enddatum muss nach Startdatum liegen“)

Wenn du das gut machst, wird die API-Schicht zum Übersetzer und Web/Mobile zu Präsentationsschichten — während die Domain die einzige Quelle der Wahrheit bleibt.

API-Schicht: Verträge, die alles treiben

Die API-Schicht ist das "öffentliche Gesicht" deines Systems — und in einer gemeinsamen, KI-unterstützten Codebasis sollte sie der Teil sein, der alles andere ankert. Wenn der Vertrag klar ist, können Web-App, Mobile-App und interne Services vom selben Wahrheitsquell generiert und gegen ihn validiert werden.

Beginne mit einem API-first-Vertrag

Definiere den Vertrag, bevor du Handler oder UI-Wiring generierst:

• Endpoints und Ressourcen: konsistente Nomen (z. B. /users, /orders/{id}), vorhersehbare Filter- und Sortierparameter.
• Fehler: stabile Fehlerform (code, message, details) mit dokumentierter Nutzung von HTTP-Status.
• Pagination: wähle einen Ansatz (Cursor-basiert ist oft leichter erweiterbar) und standardisiere Antwortfelder.
• Versionierung: entscheide früh (z. B. Pfad /v1/... oder Header-basiert) und dokumentiere Deprecation-Regeln.

Generiere Typen und Clients aus einem Schema

Nutze OpenAPI (oder ein schema-first-Tool wie GraphQL SDL) als kanonisches Artefakt. Davon generiere:

• Server-Stubs (Routen, Validierungs-Scaffolding)
• Typisierte Clients für Web und Mobile
• Gemeinsame Request/Response-Modelle, die Drift reduzieren

Das ist wichtig für KI-generierten Code: Modelle können viel Code schnell erstellen, aber das Schema hält alles in Einklang.

Konsistenzregeln, die subtile Fehler verhindern

Setze ein paar Nicht-Verhandelbares:

• Benennung: snake_case oder camelCase, nicht beides; gleiche Benennung in JSON und generierten Typen.
• Statuscodes: 200/201/204 für Erfolg, 400 für Validierung, 401/403 für Auth, 409 für Konflikte.
• Idempotenz: fordere ein Idempotency-Key für riskante Operationen (Zahlungen, Bestell-Erstellung) und definiere Retry-Verhalten.

Behandle den API-Vertrag als Produkt. Ist er stabil, wird alles andere leichter zu generieren, zu testen und zu releasen.

Web-App: Geteilte Logik integrieren ohne Koppelung

Eine Web-App profitiert stark von geteilter Geschäftslogik — und leidet, wenn diese Logik mit UI-Anliegen verknüpft wird. Die Schlüsselidee ist, die gemeinsame Domain-Schicht als "headless" Engine zu behandeln: Sie kennt Regeln, Validierungen und Workflows, aber nichts über Komponenten, Routen oder Browser-APIs.

Rendering-Entscheidungen: SSR vs CSR (und warum es wichtig ist)

Bei SSR (server-side rendering) muss geteilter Code sicher auf dem Server laufen: kein direktes window, document oder Browser-Storage. Das ist ein guter Disziplinfaktor: browserabhängiges Verhalten gehört in eine dünne Web-Adapter-Schicht.

Bei CSR (client-side rendering) hat man mehr Freiheit, aber dieselbe Disziplin zahlt sich aus. CSR-only-Projekte importieren oft versehentlich UI-Code in Domain-Module, weil alles im Browser läuft — bis SSR, Edge-Rendering oder Node-Tests hinzugefügt werden.

Praktische Regel: Gemeinsame Module sollten deterministisch und umgebungsagnostisch sein; alles, was Cookies, localStorage oder die URL berührt, gehört in die Web-Schicht.

Zustandsgrenzen: Domain-State vs UI-State

Geteilte Logik kann Domain-State exponieren (z. B. Bestell-Totale, Eligibility, abgeleitete Flags) über Plain-Objekte und pure Funktionen. Die Web-App sollte UI-State besitzen: Lade-Indikatoren, Formular-Fokus, optimistische Animationen, Modal-Visibility.

Das hält React/Vue-State-Management flexibel: Bibliotheken lassen sich wechseln, ohne Geschäftsregeln umzuschreiben.

Web-spezifische Anliegen, die du isolieren solltest

Die Web-Schicht sollte übernehmen:

• Accessibility (semantisches Markup, Tastaturnavigation, ARIA)
• Routing (URL-Struktur, Deep Links, Server-Redirects)
• Browser-Speicher (Cookies/Session, localStorage, Caching)

Denk an die Web-App als Adapter, der Nutzerinteraktionen in Domain-Commands übersetzt — und Domain-Ergebnisse in zugängliche Screens überführt.

Mobile-App: Geteilte Logik mit nativen Fähigkeiten

Mobile profitiert am meisten von einer gemeinsamen Domain-Schicht: Regeln für Preisbildung, Eligibility, Validierung und Workflows sollten auf Mobile genauso funktionieren wie auf Web und API. Die Mobile-UI wird zur „Hülle“ um diese gemeinsame Logik — optimiert für Touch, intermittierende Konnektivität und Gerätefunktionen.

Plattformmuster, für die du designen solltest

Auch mit geteilter Geschäftslogik hat Mobile Muster, die selten 1:1 auf Web abgebildet werden:

• Navigation: Modelliere Navigationszustand in der App-Schicht (Screens, Tabs, Modals), während Domain-Entscheidungen (z. B. „User muss E-Mail verifizieren vor Checkout“) in gemeinsamem Code bleiben.
• Hintergrundaufgaben: Behandle Syncs, Uploads und Refreshes als explizite Jobs mit Zeitlimits und Wiederaufnahmefähigkeit.
• Push-Nachrichten: Parse Payloads in der App-Schicht und übergebe dann an die gemeinsame Logik, um die nächste Aktion zu entscheiden.
• Deep Links: Route Links in der App-Schicht, benutze aber gemeinsame Logik zur Berechtigungsprüfung und zum Laden notwendiger Daten.

Offline-first: Caching, Sync und Konfliktstrategie

Wenn echte Mobile-Nutzung erwartet wird, geh von Offline aus:

• Cache Lese-Modelle lokal (Key-Value oder SQLite) mit klarer Staleness-Policy.
• Queue Schreibvorgänge als Intents/Events (z. B. „create order draft“) und sync bei Online.
• Definiere Konfliktregeln im Voraus (Last-write-wins, Server-autoritative Merge oder Nutzerauflösung).
• Implementiere Retries mit Backoff und Idempotency-Keys, damit die API Duplikate sicher akzeptiert.

Mobile-spezifische Anliegen

• App-Größe: Mach die gemeinsame Schicht modular, sodass du nur das lieferst, was die App braucht.
• Battery/Data: Bündle Netzwerkaufrufe und vermeide aggressives Polling.
• Permissions: Fordere nur bei Bedarf (Kamera, Location, Kontakte) und halte Berechtigungsprüfungen außerhalb der Domain, damit Richtlinien plattformabhängig variieren können.

Datenmodelle, Auth und Berechtigungen über alle Oberflächen

Eine Codebasis zerfällt schnell, wenn Web, Mobile und API ihre eigenen Datenformen und Sicherheitsregeln erfinden. Die Lösung: Behandle Modelle, Auth und Autorisierung als geteilte Produktentscheidungen und kodifiziere sie einmal.

Eine Quelle der Wahrheit für Datenmodelle

Wähle einen Ort, an dem Modelle leben, und leite alles andere davon ab. Übliche Optionen:

• Schema-first: Entitäten und Validierungsregeln in Schema-Dateien (z. B. OpenAPI/JSON Schema) definieren und Typen generieren.
• Geteilte Module: Modelltypen und Validatoren in einem gemeinsamen Paket (oft das „domain“-Paket) halten, das alle Apps importieren.
• Hybrid: Schemata für externe Verträge, gemeinsame Module für interne Domain-Regeln.

Der Schlüssel ist Konsistenz. Hat OrderStatus fünf Werte in einem Client und sechs in einem anderen, wird KI-generierter Code zwar kompilieren — aber Bugs ausliefern.

Authentifizierung: Sessions, Tokens und sichere Speicherung

Auth sollte für Nutzer gleich wirken, die Mechanik variiert nach Oberfläche:

• Web bevorzugt oft Cookie-basierte Sessions (gute CSRF-Schutzmöglichkeiten, einfache Browser-Speicherung).
• Mobile und Third-Party-Clients benötigen meist token-basierte Auth (Access + Refresh Token).

Design eines einheitlichen Flows: Login → kurzlebiger Access → Refresh bei Bedarf → Logout, der Server-Status invalidiert. Auf Mobile Secrets im sicheren Speicher (Keychain/Keystore) ablegen; auf Web httpOnly-Cookies bevorzugen, damit Tokens nicht für JS sichtbar sind.

Autorisierung: zentrale Regeln, enforcement auf der API

Berechtigungen sollten einmal definiert werden — idealerweise nah an den Geschäftsregeln — und überall angewendet werden.

• Zentralisiere Checks in der Domain (z. B. canApproveInvoice(user, invoice)).
• Erzwinge sie in der API für echte Sicherheit.
• Spiegle sie in der UI nur, um Aktionen auszublenden/zu deaktivieren, nicht um Daten zu schützen.

Das verhindert „funktioniert auf Mobile, aber nicht auf Web“-Drift und gibt KI Code-Generierung klare, testbare Vorgaben, wer was darf.

Build-, Release- und Deployment-Strategie

Eine einheitliche Codebasis bleibt nur vereinigt, wenn Builds und Releases vorhersehbar sind. Ziel ist es, API, Web-App und Mobile-Apps unabhängig deployen zu können — ohne Logik zu „forken“ oder Umgebungs-Special-Cases zu kreieren.

Monorepo vs. Multi-Repo

Ein Monorepo (ein Repo, mehrere Pakete/Apps) funktioniert oft am besten für eine gemeinsame Codebasis, weil gemeinsame Domain-Logik, API-Verträge und UI-Clients zusammen evolvieren. Du bekommst atomare Änderungen (ein PR updated einen Vertrag und alle Konsumenten) und einfachere Refactors.

Ein Multi-Repo-Setup kann ebenfalls funktionieren, zahlt sich aber in Koordination aus: Versioning gemeinsamer Pakete, Artefakt-Publishing und Synchronisation von Breaking Changes. Wähle Multi-Repo nur, wenn Organisationsgrenzen, Sicherheitsregeln oder Skalierung ein Monorepo unpraktisch machen.

Build-Targets und Artefakte

Behandle jede Oberfläche als separates Build-Target, das gemeinsame Pakete nutzt:

• API-Service-Artefakt: Container-Image oder serverless Bundle aus dem API-Paket.
• Web-Bundle: statische Assets + Server-Runtime (bei SSR) aus dem Web-Paket.
• Mobile-Builds: Android (AAB/APK) und iOS (IPA) aus nativen Pipelines, die gemeinsame Logik als Abhängigkeit ziehen.

Halte Build-Ausgaben explizit und reproduzierbar (Lockfiles, pinned Toolchains, deterministische Builds).

CI/CD-Pipeline und Umgebungs-Trennung

Eine typische Pipeline: lint → typecheck → unit tests → contract tests → build → security scan → deploy.

Trenne Konfiguration vom Code: Environment-Variablen und Secrets liegen in CI/CD und Secret-Manager, nicht im Repo. Nutze env-spezifische Overlays (dev/stage/prod), sodass dasselbe Artefakt über Umgebungen promoted werden kann, ohne neu zu bauen — besonders für API und Web-Runtime.

Testing und Quality Gates für geteilten Code

Wenn Web, Mobile und API aus derselben Codebasis ausgeliefert werden, wird Testing zur Mechanik, die verhindert, dass eine kleine Änderung drei Produkte gleichzeitig kaputt macht. Ziel: Probleme dort entdecken, wo das Beheben am günstigsten ist, und riskante Änderungen vor dem Nutzer blockieren.

Praktische Testpyramide für eine gemeinsame Codebasis

Starte bei der gemeinsamen Domain (Geschäftslogik), weil sie am meisten wiederverwendet wird und leicht ohne langsame Infrastrukturen testbar ist.

• Unit-Tests (Domain): Regeln wie Preisbildung, Eligibility, Berechtigungsentscheidungen, Zustandsübergänge und Randfälle validieren. Schnell laufen, sollten den Großteil der Suite ausmachen.
• Integrationstests (API): Prüfen End-to-End mit echter Serialisierung, Validierung, Authentifizierung und Datenzugriff. Fokussiert auf kritische Flows.
• UI-Tests (pro Client): Einige wenige, hochrelevante Checks für Web und Mobile, die Schlüssel-Journeys verifizieren (Sign-in, Checkout, Formular senden). Diese sind langsamer und sollten als „Smoke-Alarme“ verstanden werden, nicht als exhaustive Beweise.

Diese Struktur legt den meisten Vertrauensaufbau in die gemeinsame Logik, fängt aber dennoch Wiring-Probleme zwischen Schichten ab.

Contract-Testing, um Clients und API in Einklang zu halten

Auch in einem Monorepo ist es leicht, dass die API sich so ändert, dass es zwar kompiliert, aber das Nutzererlebnis bricht. Contract-Tests verhindern schleichenden Drift.

• API-to-Client Contracts: Sichern Request-/Response-Formate, Fehlerformate und Statuscodes. Wenn die API ein neues Required-Feld zurückgibt oder einen Enum ändert, schlagen Contract-Tests vor dem Merge fehl.
• Schema als Gate: Wenn du OpenAPI/GraphQL-Schemata publizierst, behandle Schema-Änderungen als reviewbare Artefakte. Breaking Changes sollten explizite Genehmigung und einen Migrationsplan erfordern.

Quality Gates, die Releases schützen

Tests sind wichtig, aber auch die Regeln darum herum.

• Pull-Request-Gates: Bestehend aus bestandenen Unit- + Integrationstests, Lint/Format und Mindestabdeckung auf Domain-Ebene.
• Feature-Flags: Veröffentliche Code sicher hinter Flags, die pro Environment oder Nutzergruppe aktiviert werden können.
• Gestaffelte Rollouts: Zuerst interne Nutzer, dann ein kleiner Prozentsatz der Prod-Traffic, dann alle.
• Rollback-Plan: Rollback als first-class Outcome — versionierte Releases, reversible DB-Migrationen (oder sichere Forward-Only-Pläne) und klare Stop-the-Line-Kriterien.

Mit diesen Gates können KI-unterstützte Änderungen häufig erfolgen, ohne fragil zu werden.

Wie man KI nutzt, ohne die Architektur zu verlieren

KI kann eine gemeinsame Codebasis beschleunigen, aber nur, wenn sie wie ein schneller Junior-Engineer behandelt wird: gut beim Erzeugen von Entwürfen, unsicher zum direkten Mergen. Menschliche Verantwortung für Architektur, Verträge und langfristige Kohärenz bleibt zentral.

Wo KI am meisten hilft (und geringes Risiko hat)

Nutze KI, um „erste Versionen“ zu erzeugen, die du sonst mechanisch schreiben würdest:

• Projektscaffolds (Ordner, Boilerplate-Module, Feature-Skelette)
• API-Dokumentation und Beispiele basierend auf existierenden Verträgen
• Test-Suites (Unit-Tests für Domain-Regeln, Contract-Tests für Endpunkte)
• Migrationen und Seed-Skripte
• Repetitive Refactors (Felder umbenennen, Module splitten), nachdem der Plan definiert ist

Gute Regel: Lass KI Code erzeugen, der sich leicht per Lesen oder Testen verifizieren lässt — nicht Code, der still Geschäftslogik verändert.

Guardrails, die die Architektur schützen

KI-Ausgaben sollten durch explizite Regeln begrenzt sein, nicht durch Interpretation.

• Coding-Standards: Linter/Formatter, Namensregeln und „kein direkter DB-Zugriff aus der UI“ Style-Constraints.
• Architektur-Regeln: Abhängigkeitsgrenzen (z. B. Domain darf keine API/Web/Mobile importieren), durch Tooling oder Build-Checks erzwungen.
• PR-Checklist: „Vertrag geändert? OpenAPI + Client-Typen + Tests aktualisieren." "Neue Domain-Regel? Domain-Tests ergänzen."

Wenn KI eine Abkürzung vorschlägt, die Grenzen verletzt, ist die Antwort „nein“, auch wenn es kompiliert.

Governance: KI-Ausgaben auditierbar machen

Das Risiko sind nicht nur schlechter Code, sondern ungetrackte Entscheidungen. Pflege eine Audit-Spur:

• Speichere wichtige Prompts und Antworten zusammen mit Tickets/PR-Links.
• Dokumentiere Architekturentscheidungen (ADRs) bei Vertragsänderungen, Auth-Modell-Änderungen oder neuen Domain-Konzepten.
• Fordere explizite API-Änderungen: versioniert, dokumentiert und von Contract-Tests begleitet.

KI ist am wertvollsten, wenn sie reproduzierbar ist: Das Team sieht warum etwas generiert wurde, kann es verifizieren und bei Bedarf sicher regenerieren.

Tooling-Hinweis: KI, die Grenzen respektiert

Wenn du KI-unterstützte Entwicklung systemweit einführst (Web + API + Mobile), ist das wichtigste Merkmal nicht rohe Generationsgeschwindigkeit — es ist die Fähigkeit, Ausgaben an deinen Verträgen und Schichten auszurichten.

Beispielsweise ist Koder.ai eine Plattform, die Teams erlaubt, Web-, Server- und Mobile-Anwendungen über ein Chat-Interface zu bauen — und dabei echten, exportierbaren Quellcode zu erzeugen. Praktisch ist das nützlich für den in diesem Artikel beschriebenen Workflow: Du kannst einen API-Vertrag und Domain-Regeln definieren und dann schnell React-Webflächen, Go+Postgres-Backends und Flutter-Mobile-Apps iterieren, ohne die Möglichkeit zu verlieren, Architekturgrenzen zu prüfen und durchzusetzen. Features wie Planungsmodus, Snapshots und Rollback passen gut zu einem „generieren → verifizieren → promoten“-Release-Disziplin in einer gemeinsamen Codebasis.

Wann man keine gemeinsame Codebasis verwenden sollte (und was stattdessen zu tun ist)

Eine gemeinsame Codebasis reduziert Duplikation, ist aber kein Default-Best-Practice. Sobald gemeinsamer Code unkomfortable UX erzwingt, Releases verlangsamt oder Plattformunterschiede verbirgt, verbringen Teams mehr Zeit mit Architekturverhandlungen als mit Wertlieferung.

Fälle, in denen separate Codebasen besser sind

Separate Codebasen (oder zumindest separate UI-Layers) sind oft gerechtfertigt, wenn:

• Hochgradig angepasste UIs das Produkt sind. Wenn Web- und Mobile-App fundamental unterschiedliche Interaktionsmodelle brauchen (Gestures, offline-first Screens, Kamera-zentrierte Flows, komplexe Animationen), wird gemeinsames UI meist zum Kompromiss.
• Strikte Plattform-Constraints existieren. App-Store-Review-Regeln, Hardware-Permissions, Hintergrundausführungslimits und Accessibility-Anforderungen können plattformspezifische Implementierungen erfordern.
• Unterschiedliche Release-Rythmen wichtig sind. Mobile releast vielleicht monatlich, Web täglich. Ein eng gekoppeltes Monorepo kann jede Änderung zur Koordinationsveranstaltung machen.

Häufige Fehlermodi, auf die man achten sollte

• Übermäßiges UI-Sharing: „Eine UI für alles“ führt zu niedrigstem gemeinsamen Nenner.
• Leaky Abstractions: Ein „geteiltes“ Modul exponiert noch Web/Mobile-Details (Routing, Storage, Auth-Tokens), sodass Konsumenten brüchig werden.
• Version-Drift: Teams kopieren Code, um schneller zu werden, und Fixes landen nur an einer Stelle.

Entscheidungs-Checkliste (und was stattdessen tun)

Stelle diese Fragen, bevor du dich für eine gemeinsame Codebasis entscheidest:

• Kann Domain-Logik sauber geteilt werden, während UI nativ bleibt?
• Brauchen Plattform-Teams Autonomie bei Tooling, Release-Timing und Experimenten?
• Sind APIs stabil genug, damit Clients unabhängig evolvieren können?

Wenn Warnsignale erscheinen, ist eine praktikable Alternative geteilte Domain + API-Verträge mit separaten Web- und Mobile-Apps. Halte geteilten Code auf Geschäftsregeln und Validierung fokussiert und lass jeden Client UX und Plattformschnittstellen besitzen.

Wenn du Hilfe bei der Wahl des Weges willst, vergleiche Optionen auf /pricing oder stöbere verwandte Architekturpattern auf /blog.