DeepSeek Harness Plan Mode: Planen oder direkt ausführen?

Die zentrale Frage lautet nicht, ob ein Plan „professioneller“ wirkt, sondern ob die geplante Änderung bereits ausreichend verstanden und sicher rückgängig zu machen ist. Für die Auswahl gelten vier Prüfgrößen:

• Änderungsumfang: Betrifft die Aufgabe eine Datei oder mehrere Module?
• Repository-Vertrautheit: Sind Einstiegspunkt, Abhängigkeiten und Prüfkommandos bekannt?
• Rückbaukosten: Kann der Zustand mit einem kleinen Diff, einem Commit oder einem definierten Rollback wiederhergestellt werden?
• Verantwortung: Darf dieselbe Person planen, schreiben, testen und freigeben?

Eine einzelne Umbenennung in einer bekannten Datei, eine kleine Dokumentationskorrektur oder eine lokale Änderung mit vorhandenen Tests kann direkt ausgeführt werden, sofern der Arbeitsbereich sauber ist und kein ungesicherter Nebenprozess läuft. Dagegen sollte eine Änderung zunächst geplant werden, wenn mehrere Verzeichnisse verbunden sind, Datenmodelle betroffen sind, Konfigurationen verändert werden oder ein fehlerhafter Eingriff nur mit manueller Rekonstruktion zurückzubauen wäre.

Das gilt besonders für Code-Refactoring. Ein Refactoring kann im Diff klein aussehen, obwohl sich Laufzeitverhalten, Importpfade, Testdaten oder Berechtigungen verändern. Der Planungsmodus schafft hier eine nachvollziehbare Zwischenstufe: Erst werden Abhängigkeiten und Annahmen gesammelt, danach entscheidet eine verantwortliche Person über den Schreibzugriff.

Die grundlegende Zustandsprüfung sollte nicht aus dem Gesprächsverlauf abgeleitet werden. Mit git status lässt sich feststellen, ob der Arbeitsbereich bereits Änderungen enthält; mit git diff kann anschließend geprüft werden, welche Inhalte tatsächlich voneinander abweichen. Die offizielle Dokumentation zu git status und die Dokumentation zu git diff bilden dafür eine belastbare technische Grundlage.

Die offizielle Projektbeschreibung bezeichnet DeepSeek Harness derzeit als Developer Preview und weist ausdrücklich auf mögliche inkompatible Änderungen hin. Deshalb dürfen Oberfläche, Einstiegspunkt und automatische Umschaltregeln nicht aus einer älteren Anleitung übernommen werden. Maßgeblich sind die am Arbeitstag geprüfte Version, der aktuelle Quellcode und die eigene Umgebung. (offizielles DeepSeek-Harness-Repository)

Für unabhängige Entwickler ist die direkte Ausführung sinnvoll, wenn der Prozess nicht durch eine zusätzliche Planungsrunde verlangsamt wird. Das setzt jedoch einen Mindeststandard voraus. Die folgenden Bedingungen sollten vor dem ersten Schreibzugriff erfüllt sein:

• [ ] Der aktuelle Branch und der Ausgangs-Commit sind eindeutig dokumentiert.
• [ ] Der Arbeitsbereich enthält keine fremden oder ungesicherten Änderungen.
• [ ] Die betroffenen Dateien und ihr Zweck sind bekannt.
• [ ] Der erwartete Diff lässt sich in wenigen klaren Sätzen beschreiben.
• [ ] Ein vorhandener Test-, Lint- oder Build-Befehl ist bekannt.
• [ ] Eine fehlerhafte Änderung kann über Git, einen Patch oder einen definierten Wiederherstellungspunkt zurückgenommen werden.
• [ ] Es werden keine Produktionsgeheimnisse, Zugangsdaten oder produktiven Konfigurationsdateien benötigt.

Sind diese Bedingungen erfüllt, kann ein Auftrag direkt formuliert werden: Ziel, betroffene Dateien, verbotene Nebenänderungen und Prüfkommando gehören in dieselbe Aufgabenbeschreibung. Eine knappe Anweisung wie „Verbessern Sie den Code“ lässt zu viel Interpretationsspielraum. Besser ist eine Begrenzung auf den betroffenen Bereich mit einem expliziten Abbruch, falls weitere Module erforderlich werden.

Direkte Ausführung bedeutet außerdem nicht, dass jede Aktion ohne Zustimmung stattfinden muss. Arbeitsbereichsberechtigungen, Shell-Freigaben und Schreibrechte bleiben separate Kontrollpunkte. Ein Agent kann eine Aufgabe inhaltlich verstanden haben und trotzdem nicht über die erforderlichen Rechte verfügen. Umgekehrt kann eine weitreichende Berechtigung dazu führen, dass ein plausibler, aber falscher Plan unmittelbar im Repository umgesetzt wird.

Für besonders kleine Aufgaben genügt ein dreiteiliger Auftrag:

1. Zielzustand nennen.
2. Erlaubte Dateien oder Verzeichnisse nennen.
3. Prüfung und Abbruchbedingung nennen.

Fehlt eine dieser drei Angaben, sollte die Aufgabe nicht automatisch in den direkten Schreibmodus gelangen. Bei einer Änderung an Build-Konfiguration, Authentifizierung, Datenmigration oder gemeinsam genutzten Schnittstellen ist diese Kurzform in der Regel zu knapp.

Wer ein Repository zum ersten Mal übernimmt, sollte zunächst eine nur lesende Bestandsaufnahme erzwingen. In dieser Phase geht es nicht darum, möglichst schnell eine Lösung zu erzeugen, sondern belastbare Belege für die spätere Ausführung zu sammeln.

Die erste Prüfung sollte mindestens folgende Punkte klären:

1. Wo liegt der tatsächliche Anwendungseinstieg?
2. Welche Pakete, Arbeitsbereiche oder Unterprojekte sind miteinander verbunden?
3. Welche Dateien enthalten lokale Arbeitsanweisungen?
4. Welche Test-, Lint-, Build- und Startkommandos gelten tatsächlich?
5. Welche Umgebungsvariablen oder Dienste werden für die Prüfung benötigt?
6. Welche Bereiche dürfen nicht verändert werden?

Ein erzeugter Plan ist dabei weder ein Commit noch eine technische Freigabe. Er beschreibt eine beabsichtigte Vorgehensweise auf Grundlage der bisher gelesenen Informationen. Wenn ein Plan behauptet, ein bestimmtes Modul sei unabhängig, muss diese Annahme anhand von Imports, Schnittstellen, Tests oder Laufzeitkonfiguration belegt werden. Fehlt dieser Nachweis, darf die Planung nicht als umsetzungsreif gelten.

Die Frage, ob DeepSeek Harness Plan Mode den Code verändert, ist deshalb zweistufig zu beantworten: Der Planungsstatus soll nach der dokumentierten Implementierungslogik die Ausführung von Schreibaktionen begrenzen beziehungsweise auf die Planartefakte beschränken; die konkrete Wirkung hängt jedoch von der geprüften Version, den aktivierten Plugins und den Arbeitsbereichsberechtigungen ab. Die offizielle Dokumentation und der Quellcode müssen daher vor dem Einsatz kontrolliert werden. Nicht bestätigte automatische Regeln dürfen nicht als Standardverhalten behandelt werden.

Vor dem Übergang in die Ausführung müssen mindestens diese Belege vorliegen:

• der geprüfte Branch mit Commit-Kennung,
• eine Liste der betroffenen Dateien oder Verzeichnisse,
• die erkannte Abhängigkeitsrichtung,
• die geplanten Tests und ihre erwarteten Ergebnisse,
• offene Fragen mit verantwortlicher Person,
• ein Rückbaupunkt einschließlich möglicher Daten- oder Konfigurationsänderungen.

Bei parallelen Arbeitszweigen sollte der Plan zusätzlich festhalten, aus welchem Arbeitsbaum er entstanden ist. Git beschreibt mit git worktree einen Mechanismus, bei dem mehrere Arbeitsverzeichnisse mit demselben Repository verbunden werden können. Das ist für Agent-Aufgaben nützlich, verhindert aber nicht automatisch, dass ein Plan im falschen Arbeitsbaum umgesetzt wird. Vor dem Schreiben müssen Pfad, Branch und Commit erneut abgeglichen werden. (offizielle Dokumentation zu Git Worktree)

In einem Team ist der entscheidende Wechselpunkt nicht „Plan fertig“, sondern „Aufgabenvertrag erfüllt“. Ein guter Aufgabenvertrag legt fest, was geändert wird, was ausdrücklich unverändert bleiben muss, wie die Änderung geprüft wird und wer die Entscheidung dokumentiert.

Die Verantwortlichkeiten sollten getrennt betrachtet werden:

• Planprüfung: Bewertet technische Annahmen, Abhängigkeiten und Alternativen.
• Schreibfreigabe: Erlaubt die Änderung im vorgesehenen Arbeitsbereich.
• Testverantwortung: Führt die vereinbarten Prüfungen aus und bewertet Abweichungen.
• Rückbauverantwortung: Entscheidet, wann ein Rollback nötig ist und welcher Zustand wiederhergestellt wird.

Ein zu detaillierter Plan erhöht die Übergabekosten. Wenn jede triviale Dateioperation vorab einzeln genehmigt werden muss, entsteht ein Prozess, der bei kleinen Aufgaben mehr Wartezeit als Schutz erzeugt. Ein zu grober Plan ist dagegen kein verlässliches Übergabeartefakt. „Authentifizierung modernisieren“ reicht nicht aus, wenn unklar bleibt, ob Middleware, Datenbankmigration, Session-Verwaltung und Tests betroffen sind.

Der Wechsel in die direkte Ausführung ist vertretbar, sobald der Vertrag folgende Fragen beantwortet:

• Welcher Zielzustand muss nach der Änderung gelten?
• Welche Dateien dürfen verändert werden?
• Welche Seiteneffekte sind ausgeschlossen?
• Welcher Test muss erfolgreich sein?
• Wer darf bei einer Abweichung stoppen?
• Welcher Commit, Patch oder Snapshot dient als Rückfallpunkt?

Bleibt eine dieser Fragen offen und betrifft die Lücke eine Sicherheits-, Daten- oder Betriebsentscheidung, sollte der Plan zurück in die Überarbeitung gehen. Bei einer rein technischen Unklarheit innerhalb des bereits freigegebenen Umfangs kann die Umsetzung pausieren und eine gezielte Rückfrage stellen, ohne den gesamten Prozess neu zu starten.

Für ein Team empfiehlt sich ein Freigabeprotokoll mit mindestens zwei getrennten Zustimmungen, wenn Schreibzugriff und fachliche Abnahme nicht bei derselben Person liegen. Das ist keine Aussage über eine feste Produktfunktion von DeepSeek Harness, sondern eine organisatorische Kontrollregel. Sie lässt sich unabhängig davon umsetzen, ob der Planungsmodus über eine Oberfläche, eine Konfiguration oder einen Sitzungsstatus aktiviert wird.

Der Planungsmodus darf nicht dazu führen, dass Sicherheitsmaßnahmen gelockert werden. Eine lesende Untersuchung kann bereits sensible Informationen offenlegen, wenn das Repository Zugangsdaten, interne Endpunkte, Kundendaten oder Produktionskonfigurationen enthält. Planung und Ausführung müssen daher nicht nur logisch, sondern auch technisch getrennt werden.

Für die Planungsphase empfiehlt sich ein Arbeitsbereich mit:

• minimal notwendigem Leseumfang,
• redigierten Geheimnissen,
• getrennten Umgebungsvariablen,
• deaktivierten Schreibwerkzeugen,
• nachvollziehbaren Sitzungs- und Tool-Protokollen,
• keinem direkten Zugriff auf produktive Systeme.

Erst nach der Freigabe darf der Ausführungsbereich temporär erweitert werden. Auch dann sollte die Freigabe auf Branch, Verzeichnis und Aufgabe begrenzt bleiben. „Voller Zugriff für die gesamte Sitzung“ ist keine präzise Sicherheitsstrategie, sondern eine dauerhafte Ausnahme.

Sitzungspersistenz verdient besondere Aufmerksamkeit. Ein gespeicherter Plan kann nach einer Unterbrechung weiterhin sichtbar sein, ohne dass Branch, Arbeitsverzeichnis, Abhängigkeiten oder Berechtigungen unverändert sind. Ein fortgesetzter Dialog ist deshalb kein Beweis dafür, dass die ursprüngliche Ausführungssituation wiederhergestellt wurde.

Geheimnisse sollten weder in Planartefakten noch in Debug-Ausgaben landen. Die OWASP-Empfehlungen für Secrets Management unterscheiden ausdrücklich zwischen dem Schutz von Geheimnissen, ihrer Speicherung, Rotation und Zugriffskontrolle. Für DeepSeek Harness bedeutet das: Ein Plan darf benennen, dass ein Dienstzugang benötigt wird, sollte aber weder den Wert noch unnötige Umgebungsdetails ausgeben.

Die belastbaren Eckdaten des aktuellen Projektrahmens sind:

• DeepSeek Harness wird offiziell als Developer Preview mit möglichen inkompatiblen Änderungen beschrieben.
• Die Web-Oberfläche wird laut offizieller README standardmäßig lokal unter 127.0.0.1:3080 gestartet.
• Das Projekt steht unter der MIT-Lizenz.
• Für die Ausführung aus dem Quellcode nennt die README die Abfolge pnpm install, pnpm run build und pnpm dsh web.

Diese Angaben stammen aus der offiziellen Repository-Beschreibung; sie sind keine Zusicherung, dass jede Plan- oder Rechtefunktion in jeder Vorschauversion identisch arbeitet. Die Angaben sollten vor dem produktiven Einsatz am 18.08.2026 erneut gegen den aktuellen Master-Stand, die Release-Notizen und die betroffenen Konfigurationsdateien geprüft werden. (Repository-README und Installationshinweise)

Remote-Mac-Umgebungen erleichtern den Zugriff auf eine konsistente Entwicklungsumgebung, führen aber eine zusätzliche Fehlerklasse ein: Die Sitzung kann abbrechen, während der Plan sichtbar bleibt und der Arbeitsbereich sich bereits verändert hat. Ein erneuter Verbindungsaufbau darf daher nicht automatisch als Fortsetzung der Ausführung behandelt werden.

Vor dem Wiederanlauf sollte die verantwortliche Person in dieser Reihenfolge prüfen:

1. Die Remote-Mac-Verbindung ist neu hergestellt und der richtige Rechner ausgewählt.
2. Das Arbeitsverzeichnis zeigt auf das erwartete Repository.
3. Branch und Ausgangs-Commit entsprechen dem Plan.
4. git status zeigt keine unerwarteten Änderungen.
5. Lock-Dateien, Abhängigkeiten und lokale Werkzeuge sind verfügbar.
6. Die erforderlichen Umgebungsvariablen sind vorhanden, ohne Geheimnisse in Protokolle zu schreiben.
7. Der Plan verweist noch auf dieselben Dateien und Annahmen.
8. Ein kleiner, lesender Prüfauftrag bestätigt den Zustand.
9. Erst danach wird die Schreibfreigabe erneut erteilt.
10. Nach der Ausführung werden Diff, Tests und Arbeitsbereich separat dokumentiert.

Für Remote-Aufgaben ist Plan Mode damit nicht automatisch sicherer. Er kann die Schreibphase begrenzen, aber nicht verhindern, dass sensible Dateien gelesen, falsche Berechtigungen vergeben oder veraltete Pläne weiterverwendet werden. Die Sicherheit entsteht erst durch minimale Rechte, eine getrennte Ausführungsumgebung und eine erneute Zustandsprüfung nach jedem Wiederanlauf.

Die Remote-Verbindung selbst sollte ebenfalls als Teil der Betriebsumgebung betrachtet werden. Apple beschreibt in der Dokumentation zur sicheren Nutzung von Remote Login auf dem Mac, dass der Fernzugriff über Systemeinstellungen aktiviert und auf bestimmte Benutzer begrenzt werden kann. Für einen Agent-Arbeitsplatz reicht es daher nicht, nur die Anwendung zu konfigurieren; auch Benutzerkreis und Fernzugriff müssen zum Freigabemodell passen.

Eine geeignete Remote-Mac-Umgebung für Entwicklungsaufgaben sollte deshalb nicht nur nach Rechenleistung ausgewählt werden. Entscheidend sind ebenso Zugriffskontrolle, Arbeitsbereichsreinigung, Wiederherstellbarkeit und die Möglichkeit, einen unterbrochenen Auftrag ohne unklare Zustandsübernahme fortzusetzen.

Die folgende Matrix trennt nicht nach persönlicher Vorliebe, sondern nach Risiko und Verantwortlichkeit:

Als Teamregel eignet sich folgende Bedingungsliste:

• Wenn der Änderungsumfang klein, die Rückgabe schnell möglich und der Test eindeutig ist, dann direkte Ausführung.
• Wenn das Repository unbekannt ist oder mehrere Abhängigkeiten erst verstanden werden müssen, dann zuerst Planungsmodus.
• Wenn eine Freigabe durch eine zweite Person erforderlich ist, dann Planungsmodus bis zur dokumentierten Zustimmung.
• Wenn der Zugriff auf Geheimnisse, Produktionsdaten oder sensible Konfigurationen nötig wäre, dann Planungs- und Ausführungsumgebung trennen.
• Wenn die Remote-Sitzung unterbrochen wurde, dann nicht aus dem Gesprächsverlauf auf einen unveränderten Zustand schließen, sondern den Arbeitsbereich neu validieren.
• Wenn der Plan nach der Erkundung neue Module, Migrationen oder nicht getestete Annahmen enthält, dann die Freigabe zurückstellen und den Plan überarbeiten.
• Wenn nur eine kleine, bereits freigegebene Teilaufgabe offen ist, dann kann die Ausführung fortgesetzt werden, sofern Branch und Diff weiterhin dem Vertrag entsprechen.

Für den laufenden Betrieb sollte die Entscheidung nicht als „Plan Mode immer aktiv“ oder „Plan Mode niemals aktiv“ umgesetzt werden. Ein fester Modus passt weder zu einem unabhängigen Entwickler mit kleinen Korrekturen noch zu einem Team, das zwischen Architekturprüfung, Implementierung und Abnahme übergibt.

Der Übergang aus dem Planungsmodus in die Ausführung sollte als überprüfbarer Ablauf behandelt werden:

1. Plan lesen: Ziel, betroffene Bereiche, Annahmen und Alternativen vollständig prüfen.
2. Repository-Zustand einfrieren: Branch, Commit und bestehende Änderungen dokumentieren.
3. Verantwortung bestätigen: Planprüfung, Schreibfreigabe, Tests und Rückbau einer Person oder Rolle zuordnen.
4. Berechtigungen reduzieren: Nur die für die freigegebene Aufgabe benötigten Schreib- und Shell-Rechte aktivieren.
5. Ausführung begrenzen: Den Agent auf Planumfang, erlaubte Dateien und Abbruchbedingungen festlegen.
6. Änderung prüfen: Diff auf unerwartete Dateien, Konfigurationsänderungen und Geheimnisse kontrollieren.
7. Tests ausführen: Nicht nur den schnellsten Test, sondern den im Plan vereinbarten Nachweis verwenden.
8. Ergebnis dokumentieren: Commit oder Patch, Testausgabe, offene Risiken und Rückbauoption festhalten.

Nach diesem Ablauf ist klar, ob die Aufgabe tatsächlich erledigt wurde. Ein Plantext allein ist kein Abnahmeprodukt; ebenso ist ein grüner Einzeltest kein Beleg dafür, dass keine ungewollten Dateien verändert wurden.

Die Dokumentation sollte mindestens drei getrennte Nachweise enthalten: den Zustand vor der Ausführung, den tatsächlichen Diff und das Ergebnis der vereinbarten Tests. Bei sicherheitskritischen Änderungen kommen die Freigabe und der Rückbauplan hinzu. Diese Trennung macht die Entscheidung später nachvollziehbar, selbst wenn die Sitzung nicht mehr verfügbar ist.

Wer den Wechsel auf einem Remote-Mac-Arbeitsplatz organisiert, sollte zusätzlich die Auswahl zwischen lokalem und entferntem Mac-Arbeitsplatz und die Übergabe eines laufenden Entwicklungsarbeitsplatzes an die eigenen Wiederanlaufregeln anpassen. Die technische Umgebung muss zum Zustandsmodell des Teams passen, nicht nur zum bevorzugten Modell oder Agenten.

Eine lokale Einzelplatzlösung ist für kleine, dauerhaft kontrollierte Aufgaben oft einfacher. Sie stößt jedoch an Grenzen, sobald mehrere Personen dieselbe Umgebung benötigen, der Rechner ausgeschaltet oder nicht erreichbar ist oder ein Auftrag nach einer Unterbrechung reproduzierbar übernommen werden soll. Andere Ausführungsumgebungen können zwar kurzfristig genügen, bringen aber häufig wechselnde Betriebssystemzustände, unklare Dateisynchronisation, zusätzliche Rechtepfade und eine weniger verlässliche Übergabe mit sich. Für zeitlich begrenzte Tests, parallele Entwicklungszweige oder eine kontrollierte Remote-Abnahme kann die Miete eines Mac-Arbeitsplatzes über NUKCLOUD deshalb die bessere praktische Lösung sein, sofern Rechte, Branch und Rückbau vor dem Start festgelegt werden. Für dauerhaft gleichförmige Schwerlastaufgaben oder Projekte mit zwingend benötigten physischen Schnittstellen bleibt ein eigener Rechner die ehrlichere Wahl.

Nach der Modusentscheidung sollte die technische Umgebung anhand eines Leitfadens zur Remote-Mac-Abnahme geprüft werden: Arbeitsbereich, Branch, Berechtigungen, Wiederanlauf und Testnachweis müssen gemeinsam stimmen. Erst wenn diese Punkte dokumentiert sind, ist zu entscheiden, ob die Aufgabe nur einmalig ausgeführt oder in einen länger laufenden Remote-Prozess überführt wird.