29. Okt. 2025·8 Min
Eine KI-generierte Codebasis für Web, Mobile und APIs
Sieh, wie eine einzige, KI-generierte Codebasis Web‑Apps, Mobile‑Apps und APIs mit geteilter Logik, konsistenten Datenmodellen und sichereren Releases antreiben kann.
Sieh, wie eine einzige, KI-generierte Codebasis Web‑Apps, Mobile‑Apps und APIs mit geteilter Logik, konsistenten Datenmodellen und sichereren Releases antreiben kann.
„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.
Ein nützliches Denkmodell ist, die Teile zu teilen, die niemals widersprüchlich sein sollten:
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“.
KI-generierter Code kann die Geschwindigkeit immens erhöhen bei:
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.
Eine erfolgreiche, KI-unterstützte Codebasis liefert:
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.
Die meisten Produkte haben mindestens drei „Eingangstüren“:
Das Ziel ist Konsistenz im Verhalten (Regeln, Berechtigungen, Berechnungen) — nicht identische Erlebnisse.
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:
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.
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.
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.
Der „teilbare Kern“ umfasst alles, was überall gleich funktionieren sollte:
Wenn KI neue Features generiert, ist das beste Ergebnis: die Domain-Regeln werden einmal aktualisiert und alle Clients profitieren automatisch.
Einige Teile sind zu teuer oder riskant, um sie in eine gemeinsame Abstraktion zu zwingen:
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.
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.
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.
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:
Wenn KI Code erzeugt, geht diese Trennung leicht verloren — behandel das als Refactor-Trigger, nicht als Präferenz.
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 wiederverwendetMoney verhindert negative Totale, egal woher der Wert kommtWenn 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.
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.
Definiere den Vertrag, bevor du Handler oder UI-Wiring generierst:
/users, /orders/{id}), vorhersehbare Filter- und Sortierparameter./v1/... oder Header-basiert) und dokumentiere Deprecation-Regeln.Nutze OpenAPI (oder ein schema-first-Tool wie GraphQL SDL) als kanonisches Artefakt. Davon generiere:
Das ist wichtig für KI-generierten Code: Modelle können viel Code schnell erstellen, aber das Schema hält alles in Einklang.
Setze ein paar Nicht-Verhandelbares:
snake_case oder camelCase, nicht beides; gleiche Benennung in JSON und generierten Typen.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.
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.
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.
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.
Die Web-Schicht sollte übernehmen:
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 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.
Auch mit geteilter Geschäftslogik hat Mobile Muster, die selten 1:1 auf Web abgebildet werden:
Wenn echte Mobile-Nutzung erwartet wird, geh von Offline aus:
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.
Wähle einen Ort, an dem Modelle leben, und leite alles andere davon ab. Übliche Optionen:
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.
Auth sollte für Nutzer gleich wirken, die Mechanik variiert nach Oberfläche:
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.
Berechtigungen sollten einmal definiert werden — idealerweise nah an den Geschäftsregeln — und überall angewendet werden.
canApproveInvoice(user, invoice)).Das verhindert „funktioniert auf Mobile, aber nicht auf Web“-Drift und gibt KI Code-Generierung klare, testbare Vorgaben, wer was darf.
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.
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.
Behandle jede Oberfläche als separates Build-Target, das gemeinsame Pakete nutzt:
Halte Build-Ausgaben explizit und reproduzierbar (Lockfiles, pinned Toolchains, deterministische Builds).
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.
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.
Starte bei der gemeinsamen Domain (Geschäftslogik), weil sie am meisten wiederverwendet wird und leicht ohne langsame Infrastrukturen testbar ist.
Diese Struktur legt den meisten Vertrauensaufbau in die gemeinsame Logik, fängt aber dennoch Wiring-Probleme zwischen Schichten ab.
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.
Tests sind wichtig, aber auch die Regeln darum herum.
Mit diesen Gates können KI-unterstützte Änderungen häufig erfolgen, ohne fragil zu werden.
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.
Nutze KI, um „erste Versionen“ zu erzeugen, die du sonst mechanisch schreiben würdest:
Gute Regel: Lass KI Code erzeugen, der sich leicht per Lesen oder Testen verifizieren lässt — nicht Code, der still Geschäftslogik verändert.
KI-Ausgaben sollten durch explizite Regeln begrenzt sein, nicht durch Interpretation.
Wenn KI eine Abkürzung vorschlägt, die Grenzen verletzt, ist die Antwort „nein“, auch wenn es kompiliert.
Das Risiko sind nicht nur schlechter Code, sondern ungetrackte Entscheidungen. Pflege eine Audit-Spur:
KI ist am wertvollsten, wenn sie reproduzierbar ist: Das Team sieht warum etwas generiert wurde, kann es verifizieren und bei Bedarf sicher regenerieren.
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.
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.
Separate Codebasen (oder zumindest separate UI-Layers) sind oft gerechtfertigt, wenn:
Stelle diese Fragen, bevor du dich für eine gemeinsame Codebasis entscheidest:
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.
Es bedeutet meist ein Repository und ein gemeinsamer Satz von Regeln, nicht eine identische App für alle Plattformen.
In der Praxis teilen Web, Mobile und API eine Domain-Schicht (Geschäftsregeln, Validierung, Use Cases) und oft einen gemeinsamen API-Vertrag, während jede Plattform ihre eigene UI und Plattform-Integrationen behält.
Teile, was niemals widersprüchlich sein darf:
Behalte UI-Komponenten, Navigation und Geräte-/Browser-Integration plattformspezifisch.
KI beschleunigt Scaffold- und repetitive Aufgaben (CRUD, Clients, Tests), aber sie schafft nicht automatisch saubere Grenzen.
Ohne eine bewusste Architektur erzeugt KI-Code oft:
Nutze KI, um klar definierte Schichten zu füllen, nicht um die Schichtung zu erfinden.
Ein einfacher, zuverlässiger Ablauf ist:
So bleiben Geschäftsregeln zentral und sowohl Tests als auch KI-generierte Erweiterungen sind leichter überprüfbar.
Lege Validierung an einer Stelle ab (Domain oder ein gemeinsames Validierungsmodul) und verwende sie überall wieder.
Praktische Muster:
EmailAddress und Money einmal validieren und wiederverwendenSo verhinderst du, dass „Web akzeptiert es, API lehnt es ab“ passieren kann.
Verwende ein kanonisches Schema wie OpenAPI (oder GraphQL SDL) und generiere davon:
Ergänze das mit Contract-Tests, damit Schema-Änderungen in CI vor dem Merge scheitern können.
Offline bewusst designen statt auf zufälliges Caching zu hoffen:
Bewahre Offline-Speicher und Sync-Logik in der Mobile-App-Schicht; Geschäftsregeln bleiben in der gemeinsamen Domain-Schicht.
Nutze einen einheitlichen konzeptionellen Ablauf, implementiert passend pro Oberfläche:
Autorisierungsregeln zentral definieren (z. B. canApproveInvoice) und ; die UI spiegelt sie nur wider, um Aktionen auszublenden/zu deaktivieren.
Behandle jede Oberfläche als eigenes Build-Target, das gemeinsame Pakete konsumiert:
In CI/CD: lint → typecheck → Unit-Tests → Contract-Tests → Build → Security-Scan → Deploy, und bewahre Secrets/Config außerhalb des Repos auf.
Behandle KI wie einen schnellen Junior-Entwickler: gut für Entwürfe, unsicher zum direkten Mergen.
Gute Guardrails:
Wenn KI-Code Architekturregeln verletzt, lehne ihn ab — selbst wenn er kompiliert.