Lerne, wie du Quellcode aus einer Vibe‑Coding‑Plattform exportierst und sauberen Besitz übernimmst: lokal ausführen, CI einrichten, Secrets verwalten und ein übergabebereites Repo vorbereiten.
Besitz des Codes ist mehr, als nur eine ZIP‑Datei von einer Plattform zu bekommen. Es bedeutet, dass du die App bauen, ausführen, ändern und ausliefern kannst, ohne die ursprüngliche Arbeitsumgebung, spezielle Buttons oder versteckte Einstellungen zu benötigen. Ein Projekt, das du wirklich besitzt, verhält sich wie ein normales Repo: ein neues Teammitglied kann es klonen, lokal starten und über eine Standard‑Pipeline deployen.
Die meisten Sorgen wegen Lock‑in kommen von wenigen Lücken:
Eine weitere Überraschung ist, dass die App auf der gehosteten Version läuft, lokal aber fehlschlägt, weil Umgebungsvariablen, Datenbank‑Setup oder Secrets nie explizit gemacht wurden.
Ein sauberer Export aus einer Vibe‑Coding‑Plattform sollte zu vier Ergebnissen führen:
Das ist wichtig, selbst wenn du nie vorhast, die Plattform zu verlassen. Eine solide Ownership‑Haltung ist Versicherung: sie reduziert Risiken, erleichtert Audits und vereinfacht Verhandlungen, wenn du eine Agentur beauftragst, Finanzierung aufnimmst oder Teams wechselst.
Wenn du Koder.ai genutzt hast, kann dein Export vertraute Stacks enthalten wie eine React‑Webapp, ein Go‑Backend, PostgreSQL oder eine Flutter‑Mobile‑App. Der Stack ist weniger wichtig als das Prinzip: alles, was zum Ausführen benötigt wird, sollte im Repository sichtbar sein und nicht in einer gehosteten Umgebung gefangen sein.
Stell dir eine Gründerin vor, die eine App an einen Auftragnehmer übergibt. „Hier ist das Repo“ sollte ausreichen. Der Auftragnehmer sollte keinen Zugang zum ursprünglichen Plattformprojekt brauchen, um die API‑Basis‑URL zu finden, das Datenbankschema zu erstellen oder zu lernen, wie das Frontend gebaut wird.
Nach dem Export solltest du ein normales Repository haben, das du in einem Editor öffnen, auf deinem Laptop ausführen und an ein anderes Team weitergeben kannst, ohne die originäre Plattform zu benötigen.
Bei Koder.ai‑Projekten mappt der Export oft auf vertraute Strukturen: eine React‑Webapp, ein Go‑Backend und (falls vorhanden) eine Flutter‑Mobile‑App. Ordnernamen variieren, aber das Repo sollte klar machen, wo jeder Teil lebt und wie sie zusammenhängen.
Beginne damit, die Einstiegspunkte und den vorgesehenen Workflow zu finden. Du willst die erste Datei, die jede App bootet, plus die Skripte, die zeigen, wie die Entwicklung und Ausführung gedacht ist.
Typische Hinweise:
package.json plus ein src/‑Ordner (oft mit main.tsx oder ähnlichem)go.mod und ein cmd/‑Ordner oder main.gopubspec.yaml und lib/main.dartREADME oder Makefile, das beschreibt, wie alles läuftdocker-compose.yml, wenn der Export als Service‑Set laufen sollAbhängigkeiten sollten fixiert sein. Bei JavaScript bedeutet das ein Lockfile (package-lock.json, yarn.lock oder pnpm-lock.yaml). Bei Go heißt das go.mod und go.sum. Fehlende Lockfiles machen das Projekt nicht unmöglich lauffähig, erschweren aber reproduzierbare Builds.
Konfiguration sollte vom Code getrennt sein. Suche nach Beispielen wie .env.example oder config.example.yaml. Du solltest keine echten Secrets (API‑Keys, Produktionspasswörter) im Export sehen. Falls doch, behandle das als Leak und rotiere die Secrets.
Für die Datenbank suche einen Migrationsordner (migrations/, db/migrations/) oder SQL‑Dateien mit Zeitstempeln. In einer Go + PostgreSQL‑App siehst du möglicherweise auch einen kleinen Migration‑Runner oder ein Skript, das Migrationen anwendet.
Ein schneller Sanity‑Check: finde zuerst die Build‑ und Run‑Befehle (npm run dev, go run, make und ähnliche). Wenn ein Skript von einer plattform‑spezifischen Aktion abhängt, ersetze sie durch Standard‑Tools, bevor du das Repo als unabhängig deklarierst.
Behandle den Export wie ein Release‑Artefakt. Bevor du irgendwas ausführst, mache einen kurzen „ist alles da?“‑Durchlauf. Fehlende Teile lassen sich jetzt leichter finden als nachdem du begonnen hast, Dinge zu ändern.
Eine praktische Vollständigkeitsprüfung ist, die „Wurzeln“ jedes Teils zu suchen: eine package.json für eine React‑Webapp, ein go.mod für ein Go‑Backend und Migrations/Seed‑Dateien für PostgreSQL.
Erstelle ein frisches Git‑Repository aus dem exportierten Ordner und committe genau das, was du erhalten hast, bevor du etwas reparierst. Das gibt dir eine klare Basis und macht spätere Änderungen leicht überprüfbar.
git init
# Optional: Standardbranch setzen
# git branch -M main
git add -A
git commit -m "Initial export"
Führe nun lokal in kleinen, verifizierbaren Schritten aus. Installiere Abhängigkeiten, erstelle lokale Konfiguration, starte zuerst die Datenbank, dann das Backend und zuletzt das Frontend. Schreibe währenddessen jeden Befehl auf, den du tatsächlich benutzt. Diese Notizen werden dein README.
Hier ist eine einfache Befehlsfolge, die du an deine exportierte Struktur anpassen kannst:
# Frontend
cd web
npm install
npm run dev
# Backend
cd ../server
go mod download
go run ./cmd/server
Ein Server kann booten, während die App trotzdem kaputt ist. Bestätige, dass sie lesen und schreiben kann.
Wähle schnelle Checks, die zum Produkt passen:
Sobald du einen funktionierenden lokalen Ablauf hast, verwandle deine Notizen in ein echtes README.md mit Copy‑Paste‑Schritten: von wo aus Befehle laufen, in welcher Reihenfolge die Services starten und welche Umgebungsvariablen nötig sind.
Ein Export kann zwar laufen, sich aber weiterhin „generiert“ statt „gehört“ anfühlen. Ein übergabebereites Repo macht klar, wo Dinge liegen, wie das Projekt ausgeführt wird und wie Konsistenz gewährleistet bleibt.
Beginne mit einem klaren Top‑Level‑Layout. Namen sind weniger wichtig als Konsistenz.
apps/ für benutzerseitige Frontends (Web, Mobile)services/ für Backend‑APIs, Worker und Jobsshared/ für geteilte Typen und Utilitiesinfra/ für Deployment‑Templates, Skripte und Umgebungsbeispieledocs/ für Architektur‑Notizen und RunbooksFüge dann eine kleine Menge Dateien hinzu, die Rätselraten reduzieren:
README.md mit Voraussetzungen und exakten BefehlenCONTRIBUTING.md mit ein paar Regeln (Branches, PRs, keine Secrets).gitignore, um lokale Env‑Dateien und Build‑Outputs aus Git zu haltenHalte das README praktisch. Wenn das Repo mehrere Teile enthält (React‑Frontend, Go‑API, PostgreSQL), nenne die Reihenfolge, in der sie gestartet werden müssen, und wo die Konfiguration liegt (zum Beispiel: „kopiere .env.example nach .env“).
Führe einen Frisch‑Maschinen‑Check durch: klone in einen neuen Ordner und folge deinem README. Wenn du aus Koder.ai exportiert hast, behandle den Export als den ersten Commit eines neuen unabhängigen Projekts und lade erst dann andere ein.
Ein gutes lokales Setup beantwortet schnell eine Frage: Kann eine neue Person die App in unter 15 Minuten ohne Raten starten?
Wähle einen Standard‑Ansatz und sei explizit. Native Installationen sind schnell für jene, die bereits die richtigen Tools haben. Container sind konsistenter über Maschinen hinweg, bringen aber Overhead. Wenn du beides unterstützt, markiere eines als Standard und das andere als optional.
Ein einfaches Muster, das gut funktioniert: eine README‑Seite, eine Beispiel‑Env‑Datei und ein Bootstrap‑Kommando.
Committe eine Beispiel‑Datei mit fiktiven Werten, damit Leute wissen, was sie setzen müssen, ohne Secrets zu leaken.
# .env.example (Beispielwerte)
APP_ENV=local
PORT=8080
DATABASE_URL=postgres://app_user:app_pass@localhost:5432/app_db?sslmode=disable
JWT_SECRET=change-me
API_BASE_URL=http://localhost:8080
Erläutere im README, wo die echte Datei lebt (z. B. „kopiere nach .env“) und welche Variablen erforderlich vs. optional sind.
Füge ein kleines Skript hinzu, das die langweiligen Schritte in der richtigen Reihenfolge ausführt. Halte es lesbar.
#!/usr/bin/env bash
set -euo pipefail
cp -n .env.example .env || true
# Backend deps
cd backend
go mod download
# Database: create, migrate, seed
./scripts/db_create.sh
./scripts/db_migrate.sh
./scripts/db_seed.sh
# Frontend deps
cd ../web
npm install
Für den Datenbankplan dokumentiere drei Dinge: wie die DB erstellt wird, wie Migrationen ausgeführt werden und wie man Seed‑Daten für einen realistischen ersten Lauf bekommt.
Zuletzt: füge eine schnelle Health‑Check‑Route hinzu, damit Leute bestätigen können, dass die App funktioniert, bevor sie klicken. Ein kleines Endpoint wie GET /health, das ok zurückgibt (und Datenbankverbindung prüft), reicht oft aus.
Beim Export gehört dir zwar der Code, die Secrets aber müssen privat bleiben. Gehe davon aus, dass das Repo mit neuen Teammitgliedern geteilt wird.
Beginne damit, aufzulisten, was die App zum Laufen braucht. Raten hilft nicht. Scanne den Code nach Konfigurationszugriffen (Umgebungsvariablen, Config‑Dateien) und prüfe alle Integrationen, die du aktiviert hast.
Eine grundlegende Secrets‑Inventarliste umfasst normalerweise Datenbankzugänge, Drittanbieter‑API‑Keys, Auth‑Einstellungen (OAuth oder JWT), Storage‑Zugangsdaten und app‑spezifische Secrets wie Verschlüsselungs‑ oder Webhook‑Signing‑Schlüssel.
Entscheide, wo jedes Secret in jeder Umgebung lebt. Eine sinnvolle Standardregel ist:
.env (nicht committed)Wenn du aus einer Vibe‑Coding‑Plattform wie Koder.ai exportiert hast, gehe davon aus, dass alles, was in Chats, Logs oder Einstellungen angezeigt wurde, kopiert worden sein könnte. Entferne Secrets sofort aus dem Repository.
Ein praktikabler Ansatz ist, eine sichere Vorlage zu committen (z. B. .env.example), echte Werte aus Git herauszuhalten (.env in .gitignore) und Produktionssecrets zur Deploy‑Zeit zu injizieren.
Wenn es auch nur eine Chance gibt, dass Secrets beim Export offengelegt wurden, rotiere sie. Priorisiere Datenbankpasswörter, OAuth‑Client‑Secrets und Webhook‑Signing‑Keys.
Füge ein paar Guardrails hinzu, damit es nicht wieder passiert: Pre‑Commit‑Checks auf offensichtliche Secret‑Patterns, ein Secret‑Scan in CI, striktes Config‑Loading, das bei fehlenden Pflichtvariablen schnell fehlschlägt, und getrennte Anmeldeinformationen pro Umgebung.
Eine kurze SECRETS.md hilft bei Übergaben. Halte sie einfach: erforderliche Variablen, wo sie pro Umgebung gespeichert sind und wer sie rotieren darf.
Sobald du Besitz übernommen hast, ist CI dein Sicherheitsnetz. Halte die erste Version klein. Jeder Push sollte beweisen, dass das Projekt noch gebaut wird, grundlegende Checks passen und Tests (falls vorhanden) laufen.
CI sollte eine Frage schnell beantworten: „Ist diese Änderung sicher zu mergen?“ Für die meisten Repos bedeutet das: Dependencies installieren, bauen, linten und Unit‑Tests ausführen.
Teile Jobs nach Projektteilen auf, damit Fehler eindeutig sind:
Nutze Caching, aber lass Cache‑Fehler die Arbeit nicht verdecken. Wenn Caches fehlen, muss CI noch funktionieren, nur langsamer.
Bevorzuge einen einzigen Befehl pro Schritt (make test, npm run test), sodass derselbe Befehl lokal und in CI funktioniert. Das reduziert Verwirrung und hält Logs kurz.
Beispiel‑Form (anpassbar an dein Repo):
jobs:
web:
steps:
- run: npm ci
- run: npm run lint
- run: npm run build
api:
steps:
- run: go test ./...
- run: go build ./...
Wenn die Basics stabil sind, füge einen einfachen Release‑Flow hinzu: Releases taggen, Artefakte bauen und sie als CI‑Artefakte speichern. Selbst wenn du heute noch von einer Plattform deployst, machen reproduzierbare Artefakte den Host‑Wechsel später deutlich einfacher.
Code zu exportieren ist nur die halbe Miete. Die andere Hälfte ist sicherzustellen, dass das Projekt außerhalb der Plattform genauso funktioniert.
Exporte hängen oft von Umgebungsvariablen, Migrationen, Seed‑Daten und Build‑Schritten ab, die für dich erledigt wurden. Ein leerer Bildschirm oder ein Datenbankfehler beim ersten Start ist normal.
Führe einen Baseline‑Lauf durch, bevor du irgendetwas änderst: deps installieren, env‑Variablen setzen, Migrationen ausführen, Services in der richtigen Reihenfolge starten. Behebe nur das Nötigste, um die erwartete Einrichtung herzustellen.
Der häufigste Unfall ist, echte API‑Keys oder Passwörter zu committen, meist durch eine kopierte .env‑Datei oder ein tool‑generiertes Config. Committe nur Vorlagen. Halte echte Werte in der lokalen Umgebung oder im Secret‑Store.
Pakete zu aktualisieren oder Ordner neu zu organisieren, bevor das Projekt läuft, macht es schwer zu erkennen, ob Probleme vom Export oder von deinen Änderungen stammen.
Bring es erst zum Laufen, dann verbessere es in kleinen, getrennten Commits.
„Läuft auf meinem Rechner“ kommt oft von nicht fixierten Tool‑Versionen (Node, Go, Flutter, sogar Paketmanager). Fixiere Runtime‑Versionen an einer klaren Stelle (Datei oder README), behalte Lockfiles (package-lock, go.sum, pubspec.lock) und verifiziere die Einrichtung auf einer zweiten Maschine oder in einem frischen Container.
Übergaben scheitern, weil niemand den einen seltsamen Schritt kennt, um die App zu starten. Schreib es auf, solange es frisch ist: erforderliche Env‑Variablen, wie Migrationen laufen, wo Logs landen und wie du lokalen Zustand zurücksetzt.
Ein Dreier‑Team baut ein Kundenportal in Koder.ai: eine React‑Webapp, eine Go‑API und eine PostgreSQL‑Datenbank. Bei der Übergabe an ein externes Entwicklerteam soll der Export sich wie ein normales Repo anfühlen, das am ersten Tag läuft.
Tag 1: Sie exportieren, erstellen ein frisches Git‑Repo und versuchen lokal zu starten. Das Frontend startet, die API schlägt fehl, weil Umgebungsvariablen fehlen. Sie raten nicht. Sie lesen den Code, identifizieren die exakt benötigten Keys und erstellen ein .env.example mit Platzhaltern. Echte Werte bleiben im Passwortmanager und in lokalen .env‑Dateien.
Sie merken auch, dass Ports und CORS‑Einstellungen auf der Plattform funktioniert haben, lokal aber Standardwerte brauchen. Sie setzen vorhersehbare Defaults (z. B. API auf 8080 und Web auf 3000), sodass neue Rechner gleiches Verhalten zeigen.
Tag 2: Sie fügen Migrationen und ein kleines Seed‑Skript hinzu, das einen Demo‑User und ein paar Reihen erstellt. Dann schreiben sie ein kurzes README mit Voraussetzungen, Befehlen zum Starten und wie man verifiziert, dass es funktioniert (Health‑Endpoint für die API und ein Beispiel‑Login für die UI).
Tag 3: Sie fügen einen Basic‑CI‑Workflow hinzu, der Tests, Linting und Builds für beide Services bei jedem Pull Request ausführt. Für Staging dokumentieren sie einen einfachen Plan: Container bauen, Secrets in der Umgebung setzen, Migrationen beim Deploy ausführen und eine Rollback‑Option behalten.
Ein guter Handoff enthält normalerweise ein Repo, das lokal aus einem frischen Clone läuft, .env.example plus Hinweise, wo Secrets liegen, Migrationen und Seed‑Daten, CI‑Checks, die schnell fehlschlagen, und eine kurze Deploy‑Notiz für Staging und Rollback.
Bevor du den Export als abgeschlossen erklärst, beweise, dass das Projekt außerhalb der Plattform leben kann. Wenn ein anderer Entwickler es ohne Raten starten kann, bist du in guter Verfassung.
Nutze diese Abschluss‑Checkliste:
Nach dem technischen Check mache Besitz explizit. Entscheide, wer für Dependency‑Updates, Infrastrukturänderungen (Datenbanken, Queues, DNS) und Releases verantwortlich ist. Wenn niemand verantwortlich ist, verfällt das Repo langsam, selbst wenn die App heute funktioniert.
Plane ein kurzes Stabilisierungsfenster vor großen Feature‑Arbeiten. Zwei bis fünf Arbeitstage reichen oft, um Export‑Ecken zu glätten, das README zu straffen und „läuft nur auf meinem Rechner“‑Probleme zu beseitigen.
Wenn du Koder.ai (koder.ai) nutzt, machen Exporte plus Features wie Snapshots und Rollback das Iterieren einfacher, während du das Repo härtest. Sobald das Repo stabil ist, behandle Git als Source of Truth und nutze künftige Exporte als Checkpoints, nicht als Haupt‑History.
Definiere das nächste Übergabe‑Meilenstein in klarer Sprache: „Jeder Entwickler kann es in 30 Minuten laufen lassen.“ Teste das, indem du jemand Neues bittest, das README auf einer frischen Maschine zu befolgen. Seine Fragen werden deine finale To‑Do‑Liste.
Behandle Besitz als Unabhängigkeit: du kannst die App bauen, ausführen, ändern und deployen aus einem normalen Repository, ohne das originale Plattformprojekt, spezielle UI‑Einstellungen oder versteckte Build‑Schritte zu benötigen.
Ein guter Test ist: kann ein neues Teammitglied das Repo klonen und es nur mit dem README zum Laufen bringen?
Beginne mit einer schnellen Vollständigkeitsprüfung:
package.json, go.mod, pubspec.yaml).package-lock.json, yarn.lock, pnpm-lock.yaml, go.sum).migrations/ oder ähnlich).docker-compose.yml).Wenn etwas zum Ausführen nur in einer UI oder in Chats beschrieben ist, schreibe es auf und verschiebe es ins Repo.
Arbeite in kleinen, verifizierbaren Schritten:
.env.example → .env.Refaktoriere nicht sofort — beweise zuerst, dass es so läuft wie geliefert, und verbessere dann in getrennten Commits.
Weil in der gehosteten Umgebung oft Dinge vorkonfiguriert sind, die du nicht explizit gemacht hast:
Behebe das, indem du die Einrichtung sichtbar machst: .env.example, Migrationsskripte und ein README mit genauen Kommandos.
Ein Serverstart ist kein Beweis für Datenfluss — prüfe echte Lese/Schreib‑Vorgänge:
Wenn du Datenänderungen lokal nicht reproduzieren kannst, ist die Einrichtung oder die Migration unvollständig.
Standardvorgehen:
.env.example mit Platzhalterwerten..env zu .gitignore hinzu.Wenn du reale Keys im Repo findest, behandle sie als kompromittiert und rotiere sie sofort. Priorisiere Datenbankpasswörter, OAuth‑Client‑Secrets und Webhook‑Signing‑Keys.
Halte das erste CI‑Setup klein und konsistent mit lokalen Befehlen:
go test ./... aus und baue das Backend.Lass CI dieselben Skripte aufrufen, die Entwickler lokal nutzen sollten (z. B. make test oder npm run build). Das reduziert „läuft lokal, aber nicht in CI“.
Ja — für eine verlässliche Übergabe brauchst du Dokumentation. Ein guter Standard ist:
README.md mit Copy‑Paste‑Kommandos..env.example, die erforderliche vs. optionale Variablen erklärt.Ziel: Ein neues Teammitglied kann die App in 15–30 Minuten ohne Raten starten.
Gängige Struktur:
apps/ für Frontends (Web, Mobile).services/ für APIs und Worker.shared/ für geteilte Typen/Utilities.infra/ für Deployment‑Templates und Umgebungsbeispiele.Die genauen Namen sind weniger wichtig als Klarheit darüber, was wo läuft und wie die Teile zusammenhängen.
Praktische Reihenfolge:
Ist alles stabil, behandle Git als Quelle der Wahrheit und nutze zukünftige Plattform‑Exporte nur noch als Checkpoints, nicht als Hauptverlauf.