Die geführte Einrichtung ist, wie SuperDevSpace diese Lücke schließt. Der Agent öffnet die Seite im eigenen Browser der App, erledigt die Klicks, die er erledigen darf, und übergibt dir die Seite – mit einem Hinweis und einem Satz – genau dann, wenn der nächste Schritt deiner ist.

Warum „lass doch den Agent machen“ die falsche Antwort ist

Die einfache Version dieser Funktion würde dem Agent den ganzen Browser geben: jedes Feld lesen, in jedes Feld tippen, jeden Button drücken. Das wäre schnell – und eine schlechte Idee. Ein Einrichtungsablauf steckt voller Dinge, die ein Agent nie anfassen sollte:

• dein Passwort und der Einmalcode von deinem Handy;
• Kartennummern, Bankdaten und Ausweisdokumente;
• die Bedingungen, denen du zustimmst, und die Zahlung, die du freigibst.

Deshalb beginnt das Design am anderen Ende. Der Agent macht die Routinearbeit – navigieren, die richtige Seite finden, einen Projektnamen eintragen, auf Erstellen klicken –, und alles Persönliche oder Verbindliche bleibt bei dir.

Wie eine geführte Einrichtung abläuft

Die Schleife ist auf jeder Seite dieselbe, auch auf solchen, für die niemand eine Anleitung geschrieben hat.

Danach kannst du das Ergebnis prüfen, ohne ein Secret auf den Bildschirm zu holen:

$ grep -o '^PADDLE_[A-Z_]*=' .env
PADDLE_API_KEY=
PADDLE_CLIENT_TOKEN=
PADDLE_WEBHOOK_SECRET=
PADDLE_ENVIRONMENT=

Regeln, die die App durchsetzt

Das sind Prüfungen in der App, und der Agent kann sie nicht abschalten:

• Keine Secrets rein, keine Secrets raus. Der Agent kann nicht in Passwort-, Karten-, CVC-, IBAN-, Einmalcode- oder Ausweisfelder tippen. Liest er die Seite oder macht er einen Snapshot, sind diese Werte verborgen und werden aus jedem gelesenen Text entfernt.
• Screenshots werden übermalt. Sensible Felder und jeder Cross-Origin-Frame – ein Karten-Widget, ein „Mit Google anmelden“-Feld – werden abgedeckt, bevor ein Agent ein Bild sieht.
• Keine Skripte auf sensiblen Seiten. JavaScript in der Seite auszuführen wird auf jeder Seite abgelehnt, die ein solches Feld zeigt.
• Zustimmung und Zahlung sind deine Sache. Ein Klick auf eine Bedingungs-Checkbox oder einen „Bezahlen“-/„Bestellen“-Button wird abgelehnt.
• Alles ist sichtbar. Was der Agent im Browser-Panel tut, siehst du in dessen Banner, während es passiert.
• Secrets bleiben aus dem Gespräch. Ein als Secret gelesener Wert wird als sensibel markiert, und der Agent wird angewiesen, ihn nie im Chat, in Berichten, Aufgabennotizen oder Benachrichtigungen zu wiederholen.

Jede Website, keine Liste von Integrationen

Die geführte Einrichtung ist eine Schleife, keine Skriptbibliothek. Sie funktioniert auch auf Seiten, für die niemand einen Hinweis geschrieben hat, weil der Agent die tatsächliche Seite vor sich liest. Für ein paar Dienste liefern wir kurze Hinweisdateien mit – etwa für das Sandbox-Dashboard von Paddle und für RevenueCat –, die dem Agent sagen, wo die Entwicklereinstellungen meistens liegen. Dashboards verschieben ihre Menüs ständig, deshalb sagen die Hinweise klar: Wenn Seite und Hinweis sich widersprechen, gilt die Seite.

Das ist wichtiger, als es klingt. Der Integrationscode, den ein Agent schreibt, ist nur die Hälfte einer Funktion; die andere Hälfte sind Konto, Schlüssel und Webhook auf der Website eines anderen. Mit der geführten Einrichtung passieren beide Hälften in derselben Session, mit demselben Agent – und du verbringst deine Zeit nur mit den Schritten, die nur du erledigen kannst.

Wo sie hingehört

Die geführte Einrichtung ist Teil desselben Arbeitsbereichs wie alles andere in SuperDevSpace: Der Agent, der deine Checkout-Integration schreibt, ist derselbe, der dich durch das Anlegen der Schlüssel führt – in einem Browser-Panel neben seinem Terminal. Wenn du neu hier bist, erklärt warum wir SuperDevSpace gebaut haben den Rest des Teams drumherum.

Ausprobieren

Die Testphase umfasst 14 Tage Premium, ohne Karte. Lade SuperDevSpace herunter, bitte einen Agent, einen Zahlungs- oder Analyseanbieter für dein Projekt einzurichten, und lass ihn dir die Seite übergeben, wenn du dran bist.

SuperDevSpace lässt einen Manager und mehrere Worker gleichzeitig auf einem Repository arbeiten. Dieser Artikel erklärt den Mechanismus, der sie auseinanderhält – Git-Worktrees – und die genauen Regeln, die die App dabei befolgt.

Was ein Git-Worktree ist

Ein Git-Repository hat normalerweise ein Arbeitsverzeichnis. Mit git worktree bekommt ein Repository mehrere, jedes auf einem eigenen Branch ausgecheckt, alle mit derselben Objektdatenbank. Es gibt keinen zweiten Clone und keine zweite Kopie der History: Ein neuer Worktree kostet die Dateien eines Checkouts und sonst nichts.

Du kannst es in jedem Repository von Hand ausprobieren. Die Befehle sind überall gleich, nur die Shell unterscheidet sich:

git worktree add -b agent/frontend-demo ../myrepo-frontend
git worktree list
cd ../myrepo-frontend && git status
cd - && git worktree remove ../myrepo-frontend

git worktree add -b agent/frontend-demo ..\myrepo-frontend
git worktree list
cd ..\myrepo-frontend; git status
cd ..\myrepo; git worktree remove ..\myrepo-frontend

Jeder Worktree hat seinen eigenen HEAD, seinen eigenen Index und seine eigenen Dateien. Zwei Prozesse können in zwei Worktrees gleichzeitig editieren, bauen und testen, ohne die halbfertigen Änderungen des anderen zu sehen. Genau diese Eigenschaft braucht ein Team aus Agents.

Wie SuperDevSpace sie nutzt

Die Regeln sind einfach und für jede Organisation gleich:

• Der Manager arbeitet in deinem Haupt-Checkout. Er plant, prüft und merged; dort kommen die Branches zusammen.
• Jeder Worker bekommt seinen eigenen Worktree auf einem eigenen Branch. Stellt der Manager einen Worker ein, führt die App für ihn git worktree add -b <branch> <pfad> aus. Der Branch heißt agent/<worker-name>-<stempel>, sofern du ihm keinen eigenen Namen gegeben hast.
• Worktrees liegen im Datenordner der App, unter worktrees/<organisation>/<worker>, nie in deinem Repository. Dein Projektordner füllt sich nicht mit Agent-Verzeichnissen.
• Jeder Durchgang wird committet. Beendet ein Worker einen Durchgang, committet die App alles, was sich in seinem Worktree geändert hat (agent(<name>): turn). Nichts, was ein Worker getan hat, existiert nur in einem nicht committeten Arbeitsverzeichnis.
• Gemerged wird per Squash-Merge. Akzeptiert der Manager den Bericht eines Workers, wird der Branch mit git merge --squash als ein Commit in deine Linie gemerged. Gibt es einen Konflikt, bricht die App den Merge ab und hinterlässt das Repository sauber für die nächste Operation, statt dich mitten in einem Konflikt stehen zu lassen.
• Eine Git-Operation pro Repository auf einmal. Die Worktree-Verzeichnisse trennen die Dateien; eine Warteschlange pro Repository serialisiert die Git-Befehle selbst. Zwei Worker, die im selben Moment fertig werden, konkurrieren nie um Gits Metadaten.

Auf dem Board sieht das aus wie mehrere Aufgaben gleichzeitig in Arbeit, jede bei einem anderen Worker, jede mit ihrem eigenen Branch darunter.

Was es praktisch macht

Ein frischer Worktree enthält nur, was Git verfolgt. Das reicht meist nicht, um ein Projekt zu starten: node_modules, eine lokale .env, generierte Dateien. Zwei Details lösen das.

Ein Setup-Skript pro Repository

Hat dein Repository eine .super/scripts/setup-worktree.sh, führt die App sie in jedem neuen Worktree aus, bevor der Worker startet, mit SUPERDEV_MAIN_REPO als Verweis auf deinen Haupt-Checkout. Die Ausgabe wird live gestreamt – eine lange Installation ist also kein Blindflug –, und du kannst sie abbrechen.

#!/usr/bin/env bash
set -euo pipefail
# Nur lokal vorhandene Dateien aus dem Haupt-Checkout kopieren
cp "$SUPERDEV_MAIN_REPO/.env" .env 2>/dev/null || true
# Abhängigkeiten installieren (pnpm verlinkt aus einem gemeinsamen Store, das geht schnell)
pnpm install --frozen-lockfile

Submodules

git worktree add lässt Submodules leer. Hat der neue Worktree eine .gitmodules-Datei, führt die App darin git submodule update --init --recursive aus, damit kein Worker gegen eine stillschweigend fehlende Abhängigkeit baut.

Aufräumen, ohne Arbeit zu verlieren

Worktrees sammeln sich an. Die App räumt sie auf, aber vorsichtig:

Ein Worktree mit nicht committeten Änderungen oder mit einem Branch, dessen Arbeit noch nicht in deiner Linie ist, bleibt, wo er ist. Ein gelöschter Ordner lässt sich neu anlegen; verlorene Arbeit nicht. Dieselbe Vorsicht gilt für Branches: Die App merkt sich die Branches, die sie angelegt hat, und fasst nur diese an.

Was sich für dich ändert

Mit jedem Worker auf einem eigenen Branch ist „vier Agents gleichzeitig laufen lassen“ kein Glücksspiel mehr. Du kannst:

• dem Manager eine Direktive geben, die in unabhängige Aufgaben zerfällt, und die Worker parallel laufen lassen;
• den Diff jedes Workers einzeln lesen, neben dem Gespräch, das ihn erzeugt hat;
• die Änderung eines Workers ablehnen, ohne die anderen zu stören;
• deinen Haupt-Checkout selbst weiter benutzen, während das Team arbeitet.

Es ist dieselbe Disziplin, die ein menschliches Team nutzt – angewandt auf Agents, die dir nicht sagen können, dass sie sich gleich gegenseitig auf die Füße treten. Wenn du dich fragst, warum wir darum eine ganze App gebaut haben, erzählt der erste Artikel die Geschichte.

Ausprobieren

Die 14-tägige Testphase ist Premium, ohne Karte. Lade SuperDevSpace herunter, richte eine neue Organisation auf ein Repository und sieh zu, wie die Worktrees entstehen, während der Manager seine ersten Worker einstellt.

Genau wegen dieser Lücke haben wir SuperDevSpace gebaut. Es ist eine Desktop-App, die aus der CLI, die du schon hast, ein kleines Team macht: ein Manager, der die Arbeit plant, und Worker, die sie erledigen – jeder in seinem eigenen Terminal und seinem eigenen Git-Worktree.

Das Problem mit einem Agent in einem Terminal

Mit einem einzelnen Coding-Agent zu arbeiten fühlt sich bei einer einzelnen Aufgabe großartig an. Es bricht zusammen, sobald du drei Dinge im selben Repository zu erledigen hast:

• Du kannst ein zweites Terminal öffnen, aber dann bearbeiten beide Agents denselben Checkout. Einer lässt die Testsuite laufen, während der andere mitten in einem Refactoring steckt.
• Du wirst zum Projektmanager. Du teilst die Arbeit auf, merkst dir, welches Terminal welche Aufgabe hatte, und trägst Kontext von einer Session in die nächste.
• Niemand schreibt auf, was passiert ist. Wenn du aus der Mittagspause kommst, ist der Scrollback-Puffer das einzige Protokoll.

Nichts davon ist ein Modellproblem. Es ist ein Organisationsproblem – und Organisation ist etwas, das Software gut kann.

Was SuperDevSpace tatsächlich macht

In SuperDevSpace ist jedes Repository eine Organisation. Jede Organisation hat einen Manager: eine echte Agent-CLI-Session in einem echten Terminal, das du siehst und in das du tippen kannst. Du gibst dem Manager eine Direktive in normaler Sprache – getippt oder per Spracheingabe diktiert.

Der Manager macht dann, was ein Teamlead tun würde:

Du kannst jederzeit einsteigen. Jeder Agent hat eine Chat-Ansicht und sein echtes Terminal – eine Session, zwei Blickwinkel –, und jede Änderung erscheint als Diff neben dem Gespräch, das sie erzeugt hat. So prüfst du, bevor etwas auf deiner Hauptlinie landet.

Dein Abo, deine Maschine, dein Code

Die wichtigste Designentscheidung ist zugleich die einfachste: SuperDevSpace steuert eine CLI, die du schon bezahlst. Wir verkaufen keinen Modellzugang weiter, also taucht nichts, was du ausführst, auf einer Rechnung von uns auf – außer dem SuperDevSpace-Abo selbst.

Diese Entscheidung hat Folgen, die uns gefallen:

• Agents laufen als lokale Prozesse auf deiner Maschine, auf deinen lokalen Repositories. Quellcode, Prompts, Terminalausgaben und Dateipfade werden nie an unsere Server geschickt. Unser Account-Service speichert ein Konto, einen Abo-Status und eine Geräteliste.
• Du wählst die CLI pro Organisation. Claude Code, OpenAI Codex, Gemini CLI, Aider, Qwen Code, Cursor CLI und OpenCode sind auswählbar. Claude Code spricht die App heute fließend – Hooks, Resume, MCP-Tools, Berechtigungsantworten. Die anderen sechs starten und laufen; die App kennzeichnet sie als experimentell und sagt dir, welche Extras noch nicht angebunden sind, statt still zu scheitern.
• Nichts ist in unserer Cloud eingesperrt, weil keine Cloud die Arbeit macht.

Vor der ersten Direktive lohnt sich ein kurzer Check, ob CLI und Repository da sind, wo du sie erwartest:

$ claude --version
$ cd ~/code/dein-projekt
$ git status

Was um das Team herum dazugehört

Ein Team braucht mehr als Terminals. Ein paar Dinge, die in jedem Plan enthalten sind:

• Ein Board, das die Wahrheit sagt. Sprints, Aufgaben, Briefings und Berichte. Ein Bericht sagt, was fehlgeschlagen ist, nicht nur, was geklappt hat.
• Inspector. Klick auf ein Element deiner laufenden Webseite und schick es mit Komponente, Datei und Zeile an einen Agent. Funktioniert mit Vite, Next.js und statischen Seiten.
• Freigaben vom Handy. Braucht ein Agent eine Entscheidung, fragt er dich. Die Handy-App zeigt das Board, die Agents und offene Freigaben, sodass du einen Berechtigungs-Prompt auch fern vom Schreibtisch beantwortest.
• Ein Whiteboard pro Organisation (Excalidraw), das Agents lesen und bemalen können.

Premium bringt die Teile, die weiter reichen: einen Designmodus auf Basis von Penpot mit einem Designer-Agent, der in der Datei zeichnet, Zeitpläne, die Direktiven nach Fahrplan ausführen, und einen Peer-Link, mit dem ein Manager auf deinem Mac Arbeit an einen Manager auf deinem Windows-PC übergibt. Den vollständigen Vergleich findest du auf der Preisseite.

Was wir nicht versprechen

Ein Team aus Agents braucht trotzdem einen Chef: Du entscheidest, was gebaut wird, und du gibst frei, was auf deinem Main-Branch landet.

Ausprobieren

Die Testphase umfasst 14 Tage Premium, ohne Karte. Dein CLI-Abo bleibt deins, dein Code auch. Wenn du das Team in deinem eigenen Repository arbeiten sehen willst, lade SuperDevSpace herunter und gib dem Manager seine erste Direktive.