Mein KI-Entwickler-Setup hat einen einzigen Zweck: Die KI arbeitet weiter, auch wenn ich den Laptop zuklappe und zum Sport fahre. Denn genau daran scheitern die meisten Leute, die ernsthaft mit KI programmieren lassen. Die eigentliche Rechenarbeit passiert zwar in der Cloud, doch die Dateien, die Befehle und die laufende Session hängen am eigenen Rechner. Klappt der zu, ist die Arbeit weg.
Ich habe diesen Bruch monatelang selbst gespürt. Der Agent lief lokal in meinem Editor, arbeitete an einem Feature, und in dem Moment, in dem ich das Notebook zumachte oder kurz das WLAN verlor, brach die Session ab. Daher habe ich mir Stück für Stück ein Setup gebaut, bei dem das nicht mehr passiert. Solche Werkzeuge baue ich mir ohnehin gern selbst, so wie damals mein selbstgebautes KI-Diktiertool. Vier Bausteine tragen das Ganze, und keiner davon ist Raketentechnik.
Das Problem: Warum die meisten KI-Agenten sterben, wenn der Laptop zuklappt
Die Trennung ist unauffällig, aber folgenreich. Die Inferenz, also das Nachdenken des Modells, geschieht auf den Servern des Anbieters. Die Handlung dagegen, das Anlegen von Dateien, das Ausführen von Tests, das Schreiben ins Git, findet dort statt, wo der Agent gestartet wurde. Bei fast allen Entwicklern ist das der Laptop.
Folglich hängt die gesamte Arbeitsfähigkeit an einem Gerät, das man abends zuklappt und in die Tasche steckt. Ein einziger kurzer Tunnel im Zug reicht schon. Sobald die Verbindung wackelt oder der Deckel zugeht, ist der Prozess tot und der Kontext verloren. Wer die KI über Nacht durchrechnen lassen will, kann das schlicht nicht, wenn der Rechner mit nach Hause fährt.
Mein KI-Entwickler-Setup in vier Bausteinen
Das Fundament ist ein eigener Server, der bei mir zu Hause steht. Darauf laufen ohnehin schon PhotoPrism, ein Dutzend Automatisierungen und mein Paperless-Archiv. Also habe ich die KI einfach dazugestellt. Zusammen ergibt das ein KI-Entwickler-Setup, das nie schläft.
Ein reboot-fester Server statt Laptop
Claude Code läuft bei mir dauerhaft als Docker-Container auf dem Heimserver, nicht auf dem Laptop. Der Container ist mit einer Restart-Policy abgesichert, deshalb startet er nach jedem Stromausfall oder Neustart des Servers von allein wieder. Fällt der Agent innerhalb des Containers aus, fängt ihn zusätzlich ein kleiner Watchdog ab, der alle 30 Sekunden prüft, ob die Session noch lebt.
Auf demselben Server arbeiten meine übrigen KI-Helfer weiter, etwa der n8n-Workflow, der mir YouTube-Videos automatisch zusammenfasst. Der Entwickler-Agent reiht sich also nur in eine Maschine ein, die sowieso rund um die Uhr läuft. Verbinden tue ich mich über einen einzigen Befehl im Terminal und hänge mich danach an die laufende Session an, egal von welchem Gerät. Wer keinen Heimserver hat, kann denselben Aufbau natürlich auf einem gemieteten VPS fahren, denn das Prinzip bleibt gleich.
tmux als Lebensversicherung der Session
Der zweite Baustein ist die Schlüsseltechnologie überhaupt. Alles, was auf dem Server passiert, läuft in einem virtuellen Terminal namens tmux. Dieses Terminal existiert unabhängig von meiner Verbindung. Ich kann mich also anhängen, zuschauen, den Deckel zuklappen und wieder abhängen, ohne dass der Prozess darin etwas davon mitbekommt.
Damit ist der klassische Abbruch beim Laptop-Zuklappen erledigt. Die SSH-Verbindung darf jederzeit sterben, denn die eigentliche Arbeit hängt nicht an ihr. Zunächst klingt das nach einer Kleinigkeit, im Alltag ist es aber der Unterschied zwischen „läuft durch“ und „war umsonst“.
Dateisync hält beide Geräte im Gleichschritt
Der dritte Baustein sorgt dafür, dass Laptop und Server immer denselben Stand haben. Syncthing synct meine Projekte, meine Memory-Dateien und meine Skills kontinuierlich und in beide Richtungen zwischen meinem Surface und dem Container. Ändert der Agent auf dem Server eine Datei, liegt sie Sekunden später auch lokal. Tippe ich lokal etwas, ist es im selben Moment auf dem Server.
Der Effekt wirkt subtil, macht im Kopf aber enorm viel aus. Es gibt kein Übergabe-Kommando, keinen vergessenen Push und keine Frage, ob ich gerade auf dem aktuellen Stand bin. Beide Seiten sind immer gleich, deshalb entfällt die ständige innere Buchhaltung komplett. Genau diese Reibungsfreiheit im Tagesgeschäft war von Anfang an mein wichtigstes Ziel.
Steuerung vom Handy aus
Weil die Session dauerhaft auf dem Server lebt, kann ich sie von überall ansteuern. Über die Weboberfläche und die App greife ich vom Handy auf denselben laufenden Agenten zu. Ich stehe an der Bushaltestelle, sehe, dass ein Task fertig ist, gebe die nächste Anweisung und stecke das Telefon wieder ein. Der Agent macht weiter, ob ich online bin oder nicht.
Insbesondere auf Reisen ist das Gold wert. Schlechtes Zugnetz spielt keine Rolle mehr, denn ich steuere nur noch, während die Arbeit auf dem Server geschieht. Falls die Verbindung abreißt, läuft der Prozess einfach ungestört weiter.
Ein gemeinsames Gedächtnis auf beiden Geräten
Ein Detail wird dabei oft übersehen, und es macht bei mir besonders viel aus. Zwischen den Geräten wandert weit mehr als der reine Code, nämlich das komplette Gedächtnis des Agenten. Meine Memory-Dateien und meine selbstgebauten Skills liegen im selben Sync. Der Agent auf dem Server kennt daher exakt dieselben Projektnotizen, Konventionen, Abkürzungen und selbstgebauten Werkzeuge wie der lokale.
Das klingt nach einer Kleinigkeit, verhindert im Alltag aber die typische Zwei-Welten-Falle. Ohne diesen Abgleich wüsste der Server-Agent nichts von einer Entscheidung, die ich morgens lokal getroffen habe. Stattdessen arbeiten beide aus demselben Wissensstand heraus, egal wo ich gerade sitze. Halte ich abends eine neue Konvention fest, ist sie am nächsten Morgen auf beiden Seiten präsent.
Ein Beispiel aus dem Alltag zeigt den Wert. Halte ich am Nachmittag lokal fest, dass ein bestimmter Dienst nur über eine interne Adresse erreichbar ist, dann weiß der Server-Agent das am Abend ganz selbstverständlich. Er stolpert nicht über eine Hürde, die ich lokal längst dokumentiert habe. Ohne den geteilten Speicher würde er blind gegen dieselbe Wand laufen, die ich Stunden zuvor schon umgangen hatte.
Vor allem bei längeren Projekten zahlt sich das aus. Der Kontext wächst über Wochen, und er bleibt konsistent, weil es nur eine Quelle der Wahrheit gibt. Ich muss dem Agenten also nicht ständig neu erklären, was letzte Woche entschieden wurde, denn es steht längst in seinem geteilten Gedächtnis. Genau deshalb fühlt sich die Zusammenarbeit über Tage hinweg an wie mit einem Kollegen, der nie den Faden verliert.
Warum ein eigener Server statt fremder Cloud
Den Agenten hätte ich auch auf einer gemieteten Cloud-Instanz laufen lassen können. Bewusst steht die Maschine aber bei mir im Arbeitszimmer. Denn meine Projekte, meine Notizen und mein Code bleiben so vollständig im eigenen Haus, ohne Umweg über einen fremden Anbieter.
Dazu kommt der praktische Nebeneffekt, dass der Server sowieso schon läuft. Er beherbergt mein Fotoarchiv, meine Automatisierungen und mein Dokumentenmanagement. Die KI erzeugt also keine zusätzliche Grundlast, sondern nutzt eine Infrastruktur, die eh 24 Stunden am Netz hängt. Gleichzeitig behalte ich die volle Kontrolle über Ressourcen und Kosten, denn es gibt keine nutzungsabhängige Rechnung am Monatsende.
Hinzu kommt ein Punkt, der mir wichtig ist: Ich weiß jederzeit, was auf der Maschine passiert. Der Container läuft in einer klar abgegrenzten Umgebung, deshalb kann ich genau steuern, worauf der Agent zugreift. Diese Kontrolle hätte ich bei einer fremden Blackbox so nicht, und gerade bei privaten Projekten und Kundendaten will ich sie nicht abgeben.
Für jemanden ohne eigenen Server ist ein kleiner VPS trotzdem ein guter Einstieg. Das Setup selbst ändert sich dadurch nicht, nur der Ort der Maschine verschiebt sich. Wichtig ist am Ende allein, dass die Kiste zuverlässig durchläuft und der Agent darauf ungestört seine Runden dreht.
Warum dieses KI-Entwickler-Setup im Alltag gewinnt
Am Ende zählt vor allem, was die Technik mir im Alltag zurückgibt. Ein KI-Entwickler-Setup, das rund um die Uhr läuft, verschiebt die eigentliche Arbeit dorthin, wo ich nicht ständig danebensitzen muss. Drei Effekte machen den Unterschied.
Erstens die Ausfallsicherheit. Container-Restart und tmux-Watchdog fangen Neustarts und Abbrüche ab, deshalb überlebt eine Session sowohl einen Stromausfall als auch einen zugeklappten Deckel. Zweitens die fehlende Buchhaltung: Der lückenlose Sync macht jedes Übergabe-Ritual überflüssig, denn beide Geräte sind immer identisch. Und drittens die Erreichbarkeit vom Handy, mit der ich Wartezeiten nutze, statt sie abzusitzen.
Wie das konkret aussieht, zeigt ein ganz normaler Abend. Ich stoße gegen 18 Uhr eine größere Umbauaufgabe an, klappe den Laptop zu und fahre los. Der Container rechnet weiter, während ich beim Sport bin. Zurück am Schreibtisch öffne ich das lokale Projekt, und der Sync hat die Änderungen längst herübergespielt. Ich muss nichts zusammenführen und nichts nachziehen, denn beide Seiten waren die ganze Zeit deckungsgleich.
Für Testen wechsle ich übrigens bewusst wieder auf den lokalen Rechner, denn manche Dinge lassen sich nur dort sinnvoll prüfen. Der Server erledigt die Dauerläufe, das lokale Gerät übernimmt die Handgriffe, die echte Hardware brauchen. Dieser Wechsel kostet mich nichts, weil der Sync im Hintergrund ohnehin alles gleich hält.
Der eigentliche Wandel steckt in der Rolle, die ich dabei einnehme. Ich sorge ich dafür, dass die Umgebung stabil steht, die Aufgaben klar sind und die Agenten ungestört durcharbeiten können. Wer heute mit KI ernsthaft baut, gewinnt vor allem durch ein durchdachtes Setup. Das schnellste Tippen ist zweitrangig geworden. Falls du gerade selbst mit KI programmieren lernst, fang genau hier an: Sorge zuerst dafür, dass deine Agenten weiterlaufen, wenn du gehst. Alles andere baut darauf auf.
