Was mir ein Tag mit DeepSeek über mein Coding beigebracht hat
Vierzig Gigabyte, ein großes Aufräumen und eine strukturelle Änderung, die ich schon vor Monaten hätte vornehmen sollen.
Ich habe einen Tag lang mit DeepSeek via Cline gearbeitet — teils aus Neugier, teils weil ich mein monatliches Budget von 217 $ für Claude Code in einer Woche aufgebraucht hatte und die zusätzlichen 300 $, die ich draufgelegt habe, innerhalb von 30 Minuten weg waren. Dabei sind mir sechs Dinge klargeworden. Die meisten davon hatten gar nichts mit DeepSeek zu tun.
Mein Speicher ist still und leise in Cline-Terminal-Chats ertrunken
Ich habe es nur gemerkt, weil iCloud meine Desktop-Dateien synchronisieren wollte und meldete, dass der Speicher voll sei. Vierzig Gigabyte über vier Cline-Chat-Sessions. Cline sammelt Arbeitsspeicher aggressiv, wenn man Terminal-Fenster nicht schließt — und ich hatte sie nicht geschlossen. Ich hatte nicht mal daran gedacht, nachzusehen.
Ich habe Claude gebeten, das zu analysieren. Es fand die Ursache schnell: offene Terminals, die Kontext hielten, der nie freigegeben wurde. Ich habe sie geschlossen, zugeschaut, wie der Speicher sank, und dann weitergemacht. Dabei habe ich gleich .venv-Ordner, Cache-Verzeichnisse und node_modules über 88+ Codebases gelöscht, die ich nicht täglich betreibe. Alte Downloads. iOS-Simulatoren, die ich seit Monaten nicht mehr genutzt hatte.
Das Aufräumen hat ein paar Stunden gedauert und mehr Speicher freigegeben, als ich erwartet hatte. Es hat mich auch gezwungen, mir anzusehen, was ich eigentlich alles gebaut habe — 88+ Codebases — und zu fragen, welche davon überhaupt noch existieren müssen.
DeepSeek ist nicht Claude, und dieser Unterschied zählt bei echter Arbeit
Für einfache Dinge — Boilerplate generieren, kleine isolierte Aufgaben, schnelle Nachschläge — hat DeepSeek gut mitgehalten. Es war brauchbar. Aber sobald ich mich in codebase-übergreifende Arbeit vorwagte, wurde es schlechter, nicht besser. Es leitet Absichten nicht so ab wie Claude. Es braucht vorhandene Code-Snippets zum Kopieren, sonst driftet es ab. Es erfordert an jedem Schritt mehr manuelle Aufsicht.
Codebase-übergreifende Arbeit mit DeepSeek hat die Dinge aktiv verschlechtert. Nicht auf eine katastrophale Art, sondern auf die langsame, frustrierende Art, bei der man mehr Zeit mit Rückgängigmachen als mit Bauen verbringt. Ich musste den Output viel genauer im Auge behalten, mehr Fehler abfangen, Kontext erneut erklären, den ich mit Claude kein zweites Mal hätte erklären müssen.
Das ist kein Vorwurf — es ist einfach ein anderes Werkzeug auf einem anderen Fähigkeitsniveau. Zu wissen, wo der Unterschied liegt, ist wichtig. Es für Dinge zu nutzen, die es bewältigen kann, und nicht zu verlangen, was es nicht kann — das ist eine vernünftige Strategie. Aber es ist kein gleichwertiger Ersatz für alles, was Reasoning über mehrere Dateien hinweg oder ein größeres mentales Modell des Gesamtprojekts erfordert.
Der überraschend gute Teil: langsamer werden im Code
Das hatte ich nicht erwartet. Weil DeepSeek mehr von mir verlangte — mehr Kontext, mehr Aufsicht, mehr Korrekturen — habe ich am Ende mehr Zeit tatsächlich im Code verbracht. Ihn gelesen. Verstanden, was passiert. Befehle selbst ausgeführt, statt einen Agenten dabei zuzuschauen.
Es fühlte sich an wie ein Jahr zurückgehen. Und für einen Tag war das wirklich gut.
Ich war schnell genug unterwegs gewesen, dass ich anfing, den Überblick über meine eigenen Systeme zu verlieren. Ich hatte zu viel Verständnis an die KI ausgelagert, damit ich es nicht selbst vorhalten musste. Das geht so lange gut, bis etwas kaputt ist und man nicht weiß, wo man suchen soll. Ein Tag des Langsamwerdens, des Boilerplate-Lesens, des tatsächlichen Nachvollziehens der Logik — das hat mich wieder daran erinnert, wie es sich anfühlt, zu wissen, was man baut, nicht nur, dass es funktioniert.
Dauerhaft so zu arbeiten wäre nichts für mich. Aber allein dafür hat sich der Tag gelohnt.
Das strukturelle Problem: 200 $ in sieben Tagen sind nicht skalierbar
Das eigentliche Problem ist nicht, welches Modell ich nutze. Es ist, wie ich sie genutzt habe.
Ein endloses Kontextfenster pro Codebase, Session für Session, bis Claude den Faden verliert oder ich an eine Abrechnungsgrenze stoße. Ich habe dokumentiert, strukturiert, Pläne geschrieben. Aber das sich aufbauende Gespräch wurde mit jedem Text, den ich hineintippte, länger.
Dieser Ansatz hat für mich perfekt und sehr erfolgreich funktioniert. Aber die Kosten haben es mir leider unmöglich gemacht, so weiterzumachen :D.
Worauf ich umsteige: richtige .claude-Dateien als strukturelle Rahmenwerke pro Codebase. Regeln, Pläne, Fehler, Erkenntnisse, Fortschrittsnotizen, Dokumentation — von der KI bei jeder relevanten Änderung geschrieben, damit die nächste Session mit echtem Kontext starten kann, statt ihn aus einem 40.000-Token-Gespräch rekonstruieren zu müssen. Sessions, die enden, wenn ein Feature fertig ist — nicht wenn ich Lust bekomme, eine neue Session anzufangen oder mir die Credits ausgehen. Die feste Gewohnheit, Terminals zu schließen und zwischen Sessions neu anzufangen.
Ich konsolidiere auch, wo es sinnvoll ist. Einige dieser 88+ Codebases sollten zusammengeführt werden. Einige sollten mit separat gespeicherten Secrets auf GitHub archiviert und dann lokal gelöscht werden. Tote Projekte auf der Festplatte zu halten kostet Aufmerksamkeit, nicht nur Speicherplatz.
Was das konkret an meiner Arbeitsweise ändert
Es fühlt sich jetzt mehr nach Arbeit an. Mehr Setup pro Projekt. Mehr Bewusstsein darüber, wann ich eine Session starte und wann ich sie beende. Mehr Zeit für Dokumentation, die ich früher übersprungen hätte, weil die KI den Kontext aus dem Gespräch darüber ja „schon kannte" und ich es ohnehin noch woanders gespeichert hatte.
Aber das ist die Anpassung. Diese Werkzeuge verändern sich ständig — Preise, Fähigkeiten, Kontextlimits, wie Agenten mit Speicher umgehen. Die Builders, die effektiv bleiben, sind nicht die, die einen Workflow gefunden haben, der funktioniert. Es sind die, die sich anpassen, wenn sich der Boden verschiebt.
Der Boden hat sich verschoben. Vierzig Gigabyte haben mir das ziemlich klar gesagt.
Diese Woche: Ich richte .claude-Dateien in den Codebases ein, an denen ich aktiv arbeite. Ich wähle eine Session-Länge, die zu einem Feature passt, nicht zu einer Woche. Und ich behalte die Terminal-Gewohnheit — schließen, wenn die Session endet. Jedes Mal. Ohne Ausnahme. Und dann — schauen wir, wie diese Neustrukturierung die Kosten senkt, mir weiterhin Spaß macht und mich die Ergebnisse erzielen lässt, die ich vorher gesehen habe.