So arbeitest du mit einem Entwickler an einer KI-gebauten App
Um gut mit einem Entwickler an einer App zu arbeiten, die du mit KI gebaut hast, gibst du ihm den Code in einem Git-Repository, eine einseitige Zusammenfassung, was die App macht und warum, und eine klar abgegrenzte Aufgabe mit einer Definition von „fertig“. Vereinbart, wer welche Teile ändert, damit du und die KI seine Arbeit nicht überschreibt. Halte das Repository und die Hosting-Konten auf deinen Namen und teile Geheimnisse über die passenden Einstellungen statt über Nachrichten.
Viele Leute bauen die erste Version einer App mit KI und holen sich dann einen Entwickler dazu: um Zahlungen einzubauen, um etwas zu beheben, das die KI immer wieder falsch macht, um die Sicherheit zu prüfen oder um die App zu übernehmen, wenn sie wächst. Wenn du noch entscheidest, ob du überhaupt jemanden einstellst, siehe einen Entwickler beauftragen oder mit KI bauen. Dieser Leitfaden setzt voraus, dass du dich entschieden hast, und dass die Zusammenarbeit reibungslos läuft.
Wann sich ein Entwickler lohnt
Häufige Gründe, jemanden dazuzuholen:
- Ein Problem, das die KI nicht knackt, nach mehreren klaren Versuchen und Rückgängigmachungen.
- Riskante Bereiche: Zahlungen, Berechtigungen, sensible Daten, Datenbankmigrationen.
- Eine Sicherheits- oder Code-Prüfung vor dem Start oder bevor größere Kunden dazukommen.
- Performance, sobald echter Traffic kommt.
- Wachstum: Die App ist zu einem Geschäft geworden und braucht jemanden, der den Code verantwortet.
Wenn du klar weißt, um welchen dieser Fälle es geht, bestimmt das alles Weitere.
Schritt 1: Den Code an einen teilbaren Ort bringen
Entwickler arbeiten mit Git-Repositories. Bevor du jemanden kontaktierst:
- Verbinde das Projekt mit einem privaten GitHub-Repository (oder einem ähnlichen Dienst) oder exportiere es.
- Stelle sicher, dass keine Geheimnisse im Code oder in der Historie stehen. Siehe wie du API-Schlüssel sicher aufbewahrst.
- Prüfe, ob das Projekt aus einer frischen Kopie läuft. Lass die KI die Einrichtungsschritte schreiben.
Schreibe eine README für einen Entwickler, der dem Projekt beitritt: was die App macht, den Stack, wie man sie lokal installiert und startet, welche Umgebungsvariablen sie braucht (nur die Namen), die Ordnerstruktur und alles, was fragil oder ungewöhnlich ist.
Wenn dir Git neu ist, behandelt wie du Git mit einer KI-gebauten App nutzt die Grundlagen.
Schritt 2: Ein einseitiges Briefing schreiben
Der Entwickler hat deinen Chatverlauf nicht miterlebt. Gib ihm den Kontext auf einer Seite:
- Was die App macht, für wen und wie viele Menschen sie nutzen.
- Was am wichtigsten ist: die Abläufe, die niemals kaputtgehen dürfen.
- Bekannte Probleme und was du schon versucht hast.
- Die Aufgabe und woran du erkennst, dass sie erledigt ist.
- Rahmenbedingungen: Budget, Frist, Dinge, die er nicht ändern sollte.
Eine gute „Definition von fertig“ ist überprüfbar: „Eine angemeldete Nutzerin kann mit Stripe Checkout einen Monatsplan bezahlen, der Plan erscheint auf ihrer Kontoseite, und wer im Kundenportal kündigt, wird zum Ende des Zeitraums herabgestuft.“ Nicht „Zahlungen irgendwie hinkriegen“.
Schritt 3: Zugang sicher vergeben
- Code: Füge den Entwickler als Mitarbeiter im Repository hinzu. Schick nach Arbeitsbeginn keine ZIP-Dateien mehr hin und her.
- Builder: Wenn dein KI-App-Builder Teammitglieder unterstützt, lade sie in einen Arbeitsbereich ein, der nur dieses Projekt enthält.
- Geheimnisse: Trage sie in den Einstellungen deines Hosters ein oder teile sie über einen Passwort-Manager. Füge Schlüssel niemals in E-Mails oder Chats ein.
- Testkonten: Lege sie mit Testdaten an, statt deinen eigenen Login weiterzugeben.
- Produktivdaten: Nur wenn er sie wirklich braucht, und nur die Teile, die er braucht.
Halte das Repository, die Domain und die Hosting-Konten auf deinen Namen. Füge Personen hinzu, gib aber keine Konten aus der Hand.
Schritt 4: Vereinbaren, wer was ändert
Die größte Reibungsquelle sind zwei Parteien, die gleichzeitig denselben Code ändern: du mit einer KI und der Entwickler. Wähle eine Regel:
| Ansatz | So funktioniert er | Passt zu |
|---|---|---|
| Nach Bereichen aufteilen | Du und die KI machen Texte, Seiten und Styling; der Entwickler verantwortet Zahlungen, Daten und die API | Laufende Zusammenarbeit |
| Abwechselnd arbeiten | Du pausierst die KI, während der Entwickler auf einem Branch arbeitet, und holst dann seine Änderungen | Eine einzelne, klar umrissene Aufgabe |
| Komplette Übergabe | Der Entwickler übernimmt; du stellst Anfragen und meldest Fehler | Die App ist dem Builder entwachsen |
Was du auch wählst: Ziehe vor jeder Prompt-Sitzung den neuesten Code, und mach große Änderungen auf Branches, die die andere Seite prüfen kann.
Schritt 5: Schriftlich kommunizieren
- Melde Probleme mit Schritten, erwartetem und tatsächlichem Ergebnis. Siehe wie du einen guten Fehlerbericht schreibst.
- Halte Entscheidungen an einem Ort fest: in einem Issue-Tracker, einem gemeinsamen Dokument oder in den Kommentaren zum Pull Request.
- Bitte ihn, in jedem Pull Request die Änderungen in einfacher Sprache zu erklären.
- Vereinbart, wie oft ihr euch abstimmt.
Schritt 6: Seine Arbeit prüfen
Du musst keinen Code lesen, um Arbeit zu prüfen. Kontrolliere:
- Sie tut, was das Briefing verlangt, in der Vorschau oder einer Staging-Kopie.
- Nichts anderes ist kaputtgegangen. Teste deine kritischen Abläufe.
- Er hat erklärt, was er geändert hat und warum.
- Keine Geheimnisse sind im Code aufgetaucht.
Für einen genaueren Blick hat wie du KI-generierten Code prüfst eine Checkliste, die auch für von Menschen geschriebenen Code funktioniert. Du kannst deinen KI-Builder außerdem bitten, den Pull Request eines Entwicklers in einfachen Worten zu erklären.
Schritt 7: Die Eigentümerschaft klar halten
- Das Repository, das Hosting, die Domain und die Konten bei Drittanbietern bleiben bei dir.
- Halte die Eigentümerschaft an dem Code, den er schreibt, schriftlich fest, bevor die Arbeit beginnt. Kläre vertragliche Fragen mit den lokalen Regeln oder einem Berater.
- Wenn die Arbeit endet, entziehe ihm den Zugang und tausche alle Schlüssel aus, die er gesehen hat.
Beispiel-Prompts
Ein Entwickler hat im letzten Pull den Checkout-Code geändert. Erkläre in einfacher Sprache, was er geändert hat und ob etwas anderes in der App davon abhängt.
Liste die Teile dieser App auf, die am komplexesten oder riskantesten sind, damit ich einem Entwickler sagen kann, wo er die Prüfung ansetzen soll.
Ich übergebe die Zahlungen an einen Entwickler. Ändere ab jetzt keine Dateien unter src/payments oder den Routen /api/billing. Wenn eine Änderung sie braucht, sag es mir stattdessen.
Häufige Fehler
- Kein Briefing. Der Entwickler verbringt bezahlte Stunden damit, rückwärts herauszufinden, was du wolltest.
- Vage Aufgaben wie „die Fehler beheben“ oder „produktionsreif machen“.
- Beide ändern gleichzeitig, ohne vorher zu ziehen, und verlieren dann Arbeit durch Konflikte.
- Den eigenen Login teilen oder Schlüssel in den Chat kopieren.
- Konten auf den Namen des Entwicklers, was eine Trennung erschwert.
- Vergessen, den Zugang zu entziehen und Schlüssel nach dem Auftrag auszutauschen.
Checkliste
- Der Code liegt in einem privaten Repository auf meinen Namen, ohne Geheimnisse darin.
- Eine README erklärt die Einrichtung; ein einseitiges Briefing erklärt die App und die Aufgabe.
- Die Aufgabe hat eine überprüfbare Definition von fertig.
- Der Zugang läuft über Einladungen als Mitarbeiter, Geheimnisse über Einstellungen oder einen Passwort-Manager.
- Wir haben vereinbart, wer was ändert, und ich ziehe vor dem Prompten.
- Die Arbeit wird gegen das Briefing und die kritischen Abläufe geprüft.
- Die Eigentümerschaft ist schriftlich festgehalten; der Zugang wird entzogen und die Schlüssel werden ausgetauscht, wenn die Arbeit endet.
Mit einem Entwickler auf Mythex arbeiten
- Lade ihn in einen Arbeitsbereich ein. Inhaber können unbegrenzt Mitarbeitende ohne Gebühr pro Platz einladen; Mitglieder arbeiten an den Projekten des Arbeitsbereichs. Nutze einen eigenen Arbeitsbereich, damit er nur dieses Projekt sieht. Credits für veröffentlichte Apps werden dem Inhaber des Arbeitsbereichs berechnet. Siehe Einladungen.
- GitHub-Sync und Export (Pro). Verbinde ein Repository und push/pull, oder exportiere das Projekt ohne Geheimnisse. Siehe GitHub, Export und Import.
- Teile einen Vorschau-Link, um Zwischenstände jemandem ohne Mythex-Konto zu zeigen, und lösche ihn, wenn du fertig bist.
- Der Fragemodus beantwortet Fragen zum Code, ohne ihn zu ändern. Das hilft, die Änderungen eines Entwicklers zu verstehen.
Wenn der Entwickler die App woanders betreibt, siehe wie du eine KI-gebaute App exportierst und selbst hostest.
Fragen
Kann ein Entwickler an Code arbeiten, den eine KI geschrieben hat?
In der Regel ja. KI-App-Builder erzeugen überwiegend Standardcode in gängigen Frameworks wie React und TypeScript, den Entwickler schon kennen. Rechne damit, dass sie sich zuerst eine Weile einlesen und stellenweise Aufräumarbeiten vorschlagen.
Sollte ich nach der Beauftragung eines Entwicklers weiter den KI-Builder nutzen?
Du kannst, aber vereinbart vorher Regeln. Die einfachste Aufteilung erfolgt nach Bereichen: Du übernimmst Texte und Seitenanpassungen, während der Entwickler Zahlungen und Daten verantwortet. Ziehe immer den neuesten Code, bevor du promptest, damit keine Seite die Arbeit der anderen überschreibt.
Wie stelle ich sicher, dass mir der Code gehört, den ein Entwickler schreibt?
Halte das Repository und die Hosting-Konten auf deinen Namen und füge den Entwickler als Mitarbeiter hinzu. Halte die Eigentumsrechte an der Arbeit schriftlich fest, bevor er anfängt, und kläre vertragliche Fragen mit den lokalen Regeln oder einem Berater.
Was sollte ich einem Entwickler vor dem Start geben?
Zugang zum Code, eine kurze Beschreibung, was die App macht und wer sie nutzt, die Liste bekannter Probleme, die gewünschte Aufgabe mit deinen Kriterien für „fertig“ und Testkonten. Teile Geheimnisse über die Einstellungen deines Hosters oder einen Passwort-Manager, nicht über den Chat.