KI-Entwickler-Guide: Plattformen, Services, Apps und Multi-Domain-Projekte sauber planen
Wenn ein KI-Coding-Agent an einer ganzen Plattform helfen soll, reicht ein guter Prompt nicht aus. Du brauchst klare Systemgrenzen, Umgebungen, Berechtigungen, Tests, Rollback und eine Quelle der Wahrheit.
Hinweis: Dieser Ratgeber erklaert Architektur- und Workflow-Prinzipien. Er ist keine Anleitung fuer Live-Deploys und enthaelt keine privaten Infrastrukturdetails.
Kurze Antwort: Was muss vor Plattformarbeit stehen?
Ein KI-Coding-Agent kann bei Plattformen, Services und Multi-Domain-Projekten viel Arbeit vorbereiten: Code lesen, Teilaufgaben strukturieren, Tests anstossen, Diffs erklaeren oder wiederkehrende Ablaeufe in Skills auslagern. Gefaehrlich wird es, wenn der Agent ohne Architekturgrenzen, ohne Sandbox, ohne Review-Gate oder ohne Rollback an zu grossen Aufgaben arbeitet.
Der richtige Start ist deshalb nicht "bau alles", sondern ein kleiner, belegbarer Workflow: Ist-Zustand pruefen, Ziel definieren, Scope begrenzen, Draft bauen, Tests laufen lassen, Review durchfuehren und erst dann ueber Deploy sprechen.
Warum Plattformarbeit anders ist als ein kleiner Code-Fix
Ein kleiner Code-Fix hat meist eine klare Grenze: eine Datei, ein Fehler, ein Test. Eine Plattform hat mehrere Grenzen gleichzeitig. Frontend, Backend, Inhalte, Daten, APIs, Tracking, Consent und Deploy-Schritte koennen voneinander abhaengen.
Eine optisch kleine Aenderung kann Suchstruktur, interne Links, Canonicals oder Monetarisierungsmarker beruehren. Ein Agent erkennt diese Abhaengigkeiten nur zuverlaessig, wenn sie lokal dokumentiert und im Auftrag begrenzt sind.
Die Architekturkarte vor dem ersten Agentenauftrag
Eine Architekturkarte muss kein langes Dokument sein. Sie beantwortet die Fragen, die ein Agent sonst erraten wuerde.
| Frage | Warum wichtig? |
|---|---|
| Was ist die Quelle der Wahrheit? | Sonst arbeitet der Agent an einem veralteten Ordner. |
| Welche Domains oder Services sind betroffen? | Sonst werden Nebenwirkungen uebersehen. |
| Welche Dateien duerfen geaendert werden? | Sonst vermischt der Agent unrelated work. |
| Welche Checks sind Pflicht? | Sonst wird nur nach Gefuehl freigegeben. |
| Wo liegt Rollback? | Sonst wird ein Fehler live teuer. |
| Welche Daten sind tabu? | Sonst landen Secrets oder private Details im falschen Kontext. |
Quellen der Wahrheit und Arbeitsbereiche
Ein Agent sollte nie raten, welcher Ordner aktuell ist. Lege fest, welcher Live- oder Repo-Stand gilt, wo Drafts liegen, wo Deploy-Packets entstehen und wohin Reverse-Sync geschrieben wird.
Wenn Live und lokaler Stand auseinanderlaufen, muss zuerst geklaert werden, welcher Stand gewonnen hat. Fuer Content-Projekte bedeutet das: erst Live- oder Sitemap-Zustand pruefen, dann Draft erzeugen, dann Routing und Suche vorbereiten.
Umgebungen, Rechte und Sandbox
Moderne Coding-Agenten koennen mit Sandbox- und Genehmigungsmodellen arbeiten. Das ist eine Sicherheitsfrage, keine reine Komfortfunktion.
- Read-only fuer Recherche, Audit und Planung.
- Beschreibbarer Workspace fuer lokale Diffs und Drafts.
- Explizite Genehmigung fuer Netzwerk, APIs, Deploys oder irreversible Aktionen.
- Harte Stopps fuer Secrets, Live-Schreibzugriffe und riskante Remote-Kommandos.
Multi-Domain: gleiche Plattform, unterschiedliche Risiken
Bei Multi-Domain-Projekten ist die groesste Falle, alle Domains gleich zu behandeln. Eine Kostenratgeber-Seite braucht andere Oberflaechen, Texte und Pruefungen als eine SaaS-App oder eine technische Agenturwebsite.
- Zielgruppe und Ton pro Domain klaeren.
- Primaere Nutzerhandlung festlegen.
- SEO- und Content-Risiken getrennt bewerten.
- Tracking- und Consent-Anforderungen domainbezogen pruefen.
- Template- und Designregeln nicht vermischen.
Gute Aufgabenpakete fuer KI-Coding-Agenten
Gute Plattformaufgaben sind klein genug, um pruefbar zu bleiben, aber gross genug, um echten Fortschritt zu liefern.
| Gutes Paket | Schlechter Auftrag |
|---|---|
| Inventarisiere alle Verifier und mappe sie auf den Shared Runner. | Mach die Automatisierung besser. |
| Baue ein Draft-Packet aus diesem freigegebenen Factlog, ohne Deploy. | Schreib und veroeffentliche den Artikel. |
| Pruefe live alle internen Links und schreibe ein Handoff. | Check mal die Website. |
| Erweitere dieses Profil um Search-Checks, ohne neuen One-off-Runner. | Mach ein neues Audit-Skript. |
Review-Gates, Tests und Rollback
Fuer Plattformen reicht ein einzelner "sieht gut aus"-Check nicht. Architektur, Security, Content/SEO, Frontend/UX und Deploy muessen getrennt pruefbar bleiben.
- Architektur-Gate: Passt die Aenderung zum System?
- Security-Gate: Werden Secrets, Rechte oder externe Quellen riskant behandelt?
- Content/SEO-Gate: Sind Canonical, Sitemap, interne Links und Suchintention sauber?
- Frontend/UX-Gate: Ist das Layout konsistent und mobil nutzbar?
- Deploy-Gate: Ist das Packet exact-allowlisted, aus Live-Origin gestaged und dry-run-clean?
- Rollback-Gate: Gibt es Snapshot und Rueckkehrstrategie?
Wie Skills und Anweisungen helfen
Projektanweisungen wie AGENTS.md, CLAUDE.md oder Copilot Instructions helfen, wiederkehrende Regeln nah am Projekt zu halten. Skills eignen sich fuer wiederkehrende Arbeitsablaeufe: Factlogs bauen, Browser-Audits sequenziell ausfuehren, Draft-Packets erzeugen oder Markdown-Regeln pruefen.
Eine grosse All-in-one-Anweisung ist meistens schlechter als mehrere klare, kleine Bausteine.
Beispielworkflow fuer ein Plattformprojekt
- Read-only Audit des Ist-Zustands.
- Architekturkarte und Quelle der Wahrheit bestaetigen.
- Factlog fuer neue Inhalte oder aktuelle Produktclaims bauen.
- Draft lokal erstellen, ohne Deploy.
- Route, interne Links, Suche und Sitemap-Anforderungen planen.
- Review-Gate mit GO/STOP-Entscheidung.
- Deploy-Packet aus Live-Origin bauen.
- Dry-run mit exact allowlist und 0 Deletes.
- Snapshot/Rollback sichern.
- Apply nur nach Freigabe.
- Live unabhaengig pruefen.
- Reverse-Sync und scoped Commit.
Haeufige Fragen
Kann ein Agent eine ganze Plattform bauen?
Er kann grosse Teile vorbereiten, aber nicht ohne klare Architektur, Rechte, Tests und Review. Je groesser die Plattform, desto wichtiger sind kleine Pakete und harte Stopps.
Wann sollte ich Subagents oder Research Agents nutzen?
Wenn mehrere klar getrennte Recherchen oder Reviews parallel moeglich sind. Sie brauchen klare Aufgaben, Rueckgabeformate und eine Zusammenfuehrung.
Sind Skills besser als lange Prompts?
Fuer wiederkehrende Aufgaben ja. Ein Skill kann Trigger, Referenzen, Validierung und Grenzen stabil speichern.
Was gehoert nie in einen oeffentlichen Artikel?
Private Pfade, Hostnamen, SSH-Kommandos, API-Keys, Publisher-IDs, OAuth-Werte, interne Tokens, Kundendaten und konkrete Live-Operationsdetails.
Redaktionelle Methode
Dieser Ratgeber basiert auf einem Factlog mit offiziellen Quellen zu Codex, GitHub Copilot, Claude Code, OWASP, MCP und NIST sowie lokalen KPR-Workflow-Artefakten. Externe Repositories wurden nur als Referenzmaterial behandelt. Produktpreise, Rankings und konkrete Tool-Limits sind nicht Teil dieses Drafts.