Claude Code 24 Stunden autonom arbeiten lassen – was dabei wirklich passierte

Ein Python-basiertes Recon-Automatisierungstool war das Testfeld: ein Projekt mit funktionierendem Backend, aber chaotischem Code, inkonsistenten Ausgaben und 15 offenen Aufgaben – von kleinen Refactoring-Schritten bis zu einem kritischen Bug in der Rate-Limiting-Logik. Doch statt selbst Hand anzulegen, ließ ein Entwickler Claude Code diese Aufgaben 24 Stunden lang vollkommen autonom erledigen – ohne Eingriffe, ohne Nachfragen. Das Ergebnis war eine Mischung aus brillanten Lösungen und überraschenden Pannen, die wertvolle Lehren für autonome KI-Workflows liefern.

Die Experimentkonfiguration: Keine Kontrolle, nur Regeln

Der Test erfolgte auf einem headlosen Ubuntu-Server in einer tmux-Sitzung. Als Grundlage diente ein Claude.md-Dokument am Projektstamm, das folgende Vorgaben enthielt:

• Priorisierte Aufgabenliste mit 15 Einträgen
• Verbotene Verzeichnisse für sensible Bereiche
• Ausgabeformat für abgeschlossene Tasks
• Blockierregel: Bei Entscheidungen mit mehr als zwei plausiblen Optionen musste Claude eine BLOCKED.md-Datei erstellen – statt willkürlich zu wählen

Die Berechtigungen waren bewusst eingeschränkt: Lese-/Schreibzugriff nur auf das Projektverzeichnis, Bash-Befehle nur im virtuellen Environment und kein Netzwerkzugriff außer auf localhost. Ein Tool namens OpenClaw hielt die Sitzung auch bei Verbindungstrennungen stabil. Als Modell kam claude-sonnet-4-5 zum Einsatz, mit einer maximalen Token-Anzahl von 8192 pro Aufruf.

Die Erfolge: Effizienz und unerwartete Qualitätssprünge

Nach nur sechs Stunden waren bereits neun der 15 Aufgaben abgeschlossen – und das mit bemerkenswerter Präzision.

• Code-Refactoring: Die Variablennamen folgten plötzlich den bestehenden Konventionen, obwohl keine expliziten Vorgaben gemacht wurden. Offensichtlich hatte Claude den Code-Stil aus dem Projektumfeld abgeleitet.
• Ausgabeformatierung: Ein Problem mit inkonsistenten Ausgaben wurde mit minimalem Aufwand behoben – nur vier Zeilen in zwei Dateien geändert, statt eines kompletten Redesigns.
• Rate-Limiting-Bug: Der kritische Fehler lag in einer veralteten Zeitstempel-Berechnung bei gebündelten Anfragen. Claude identifizierte die Ursache korrekt, schrieb einen Fix und ergänzte gleich drei gezielte Unit-Tests, die genau die Edge Cases abdeckten, die den Bug ausgelöst hatten. Diese Tests hätten den Fehler bereits vor der Auslieferung entdeckt.

Besonders beeindruckend: Nicht nur die ursprüngliche Aufgabe wurde gelöst, sondern der Code wurde nachhaltig robuster zurückgelassen – ein seltenes Ergebnis bei automatisierten Lösungen.

Die Blockaden: Wo die KI an ihre Grenzen stieß

Doch nicht alle Aufgaben verliefen reibungslos. Drei Tasks endeten in BLOCKED.md-Dateien – zum Teil aus berechtigten, zum Teil aus fragwürdigen Gründen.

1. Legitime Blockade: Eine Aufgabe zur „Bereinigung der Konfigurationslogik“ war tatsächlich mehrdeutig, da zwei strukturell unterschiedliche Refactoring-Ansätze möglich waren. Die Begründung in der BLOCKED.md war präzise und nachvollziehbar – und wurde vom Entwickler akzeptiert.

1. Halluzinierte Einschränkung: Bei der Aktualisierung der Abhängigkeiten in requirements.txt blockierte sich Claude selbst mit einer nicht existierenden Versionsbeschränkung. Offensichtlich hatte die KI eine Constraint erfunden, die im Original nicht vorhanden war – ein bekanntes Phänomen bei Unsicherheit.

1. Unklare Aufgabenstellung: Eine schlecht formulierte Aufgabe führte zu einer unnötigen Blockade. Hier lag die Verantwortung klar beim Entwickler.

Die Fehler: Wenn Automatisierung technische Schulden schafft

Von den 12 tatsächlich bearbeiteten Tasks mussten drei nachträglich korrigiert werden – nicht wegen Funktionsfehlern, sondern wegen mangelnder Konformität oder falscher Platzierung.

• Stilistische Abweichungen: Zwei Lösungen folgten zwar den funktionalen Anforderungen, ignorierten aber die bestehenden Fehlerbehandlungsmuster. Statt spezifische Exceptions zu fangen, wurde pauschal Exception abgefangen – ein klarer Verstoß gegen die Projektkonventionen.
• Beobachtungslücken: Eine Logging-Aufgabe platzierte die Debug-Ausgabe in einer bedingten Verzweigung, sodass sie nur in einem von drei möglichen Codepfaden aktiviert wurde. Die Tests deckten diesen Fehler nicht ab, da sie nur den „Happy Path“ abprüften. Die KI verstand die Syntax, nicht aber den operativen Zweck der Anforderung.

Die Erkenntnis: Aufgabenbeschreibungen müssen den Zweck hinter der Funktion klar kommunizieren. „Logging hinzufügen“ ist zu vage. Eine präzise Formulierung wie „Füge einen DEBUG-Log-Eintrag am Anfang von process_batch() hinzu, um jeden Aufruf unabhängig vom Pfad nachverfolgbar zu machen“ vermeidet Missverständnisse.

Das Drift-Problem: Wenn Prioritäten verloren gehen

Nach 18 Stunden zeigte sich ein subtiles, aber folgenreiches Phänomen: Task-Priorisierung driftete ab. Statt der dokumentierten Reihenfolge wählte Claude Aufgaben nach lokale Code-Nähe aus – etwa, weil zwei Tasks im gleichen Modul lagen. Das Ergebnis: Task 12 wurde vor Task 7 abgeschlossen, obwohl letztere für den Entwickler priorisiert war.

Die Lehre: Bei langen unüberwachten Läufen müssen Prioritäten explizit und wiederholt kommuniziert werden. Ein Satz wie „Arbeite Aufgaben in nummerierter Reihenfolge ab. Kein Batchen nach Nähe. Kein Überspringen.“ verhindert solche Abweichungen. Vage Prioritätssignale verschwinden im 24-Stunden-Kontext.

Fazit: Autonome KI-Workflows brauchen klare Grenzen – und menschliche Kontrolle

Das Experiment mit Claude Code lieferte wertvolle Einblicke:

✅ KI kann hochwertigen Code liefern – nicht nur schneller, sondern oft mit zusätzlichen Sicherheitsfeatures wie Unit-Tests.

✅ Klare Aufgabenbeschreibungen sind entscheidend. Je detaillierter der operative Kontext, desto besser die Ergebnisse.

⚠️ Autonome Systeme neigen zu Drift. Prioritäten müssen aktiv durchgesetzt werden.

⚠️ KI erfindet manchmal Einschränkungen – besonders bei Unsicherheit.

⚠️ Technische Schulden werden nicht automatisch vermieden. Stilistische und konzeptionelle Fehler bleiben bestehen, wenn sie nicht explizit adressiert werden.

Für Entwickler, die ähnliche Workflows planen, gilt: Autonomie ist kein Freibrief für Unkontrollierbarkeit. Die beste Strategie kombiniert klare Regeln, regelmäßige Überprüfungen und menschliche Validierung – selbst bei 24-Stunden-Läufen.