Ich baue mein digitales Leben neu — mit einem KI-Agenten

Vor zwei Tagen sass ich vor einem fabrikneuen Notebook. Frisches Arch Linux, leeres Home-Verzeichnis, keine Altlasten. Der klassische Moment, in dem man sich schwört: Diesmal mache ich alles richtig.

Das habe ich schon öfter geschworen. Was diesmal anders ist: Ich baue nicht alleine — und ich baue nichts, ohne die Entscheidung schriftlich zu begründen.

Das Experiment

Zwei Regeln habe ich mir gegeben:

1. Jede tragende Entscheidung wird schriftlich festgehalten — als Architecture Decision Record, kurz ADR. Das Format kommt aus der Software-Entwicklung und geht auf Michael Nygards Artikel von 2011 zurück. Es ist nichts Kompliziertes: ein kurzes Dokument pro Entscheidung — Kontext, Entscheid, Begründung, Konsequenzen, inklusive der Alternativen, die es nicht geworden sind.
2. Ein KI-Agent ist mein Cockpit. Ich arbeite nicht mit Chat-Fenstern und Copy-Paste, sondern mit einem Agenten im Terminal, der Dateien liest und schreibt, Server konfiguriert, Doku pflegt — und sich über ein persistentes Gedächtnis von Session zu Session erinnert, woran wir arbeiten.

Das Ziel dahinter ist grösser als ein aufgeräumtes Notebook: raus aus Diensten, die mir nicht gehören. Der Passwortmanager ohne Linux-Support, das Postfach bei Exchange, die Fotos bei Google — Stück für Stück ersetzt durch Dienste auf einem eigenen Server. Own your stack, daher der Name dieser Serie.

Was in 48 Stunden passiert ist

Zwölf ADRs sind in den ersten zwei Tagen entstanden:

Eine Auswahl:

• Ordnungssystem: Das Home-Verzeichnis folgt der PARA-Methode (Projects, Areas, Resources, Archive). Klingt banal, ist aber die Grundlage, damit ein Agent — und ich selbst — Dinge wiederfindet.
• Passwörter: Vaultwarden auf einem eigenen VPS bei einem EU-Anbieter statt eines US-Cloud-Abos. Der alte Manager bleibt als Brücke, bis die Migration verifiziert ist. (Für mein eigenes Setup reicht mir EU-Datenhoheit — Kundensysteme betreiben wir in der Schweiz, wenn der Kunde das verlangt. Und das verlangt er meistens, zu Recht.)
• Secrets: Zwei Klassen mit zwei Speicherorten — interaktive Zugänge in den Passwortmanager, Automatisierungs-Tokens verschlüsselt ins Git-Repo (sops + age).
• Zugriff: WireGuard-VPN mit einer internen Service-Zone, zentrales SSO mit Authentik und LLDAP, Passkeys statt SMS-Codes — auch unter Linux.
• Git: Eine eigene leichtgewichtige Forgejo-Instanz statt GitLab-Cloud.

So sieht die Zielarchitektur aus — ein Notebook, ein VPS, eine klare Trennung zwischen öffentlich und VPN-only. Öffentlich ist nur, was von unterwegs ohne VPN erreichbar sein muss (Passwort-Zugriff, Login, Git für CI); Admin-Oberflächen existieren ausserhalb des VPN schlicht nicht. Und die Backups sind gar kein Web-Dienst: Sie laufen verschlüsselt ausser Haus.

Jede dieser Entscheidungen hat ein Dokument mit den Alternativen, die es nicht geworden sind — und warum. Genau dieser Teil zahlt sich schon jetzt aus: Wenn ich in sechs Monaten frage «warum nochmal kein Tailscale?», steht die Antwort im Repo.

Die ehrliche Bilanz

Es lief nicht alles glatt, und das ist der Punkt dieser Serie. Das Beispiel, das mir am meisten zu denken gab: Die erste Version der «internen Zone» — Admin-Oberflächen, die nur im VPN erreichbar sein sollten — hatte ein Loch. Der IP-Filter im Reverse Proxy war wirkungslos, weil Docker die Absender-Adresse durch die eigene Bridge-Adresse ersetzt (dokumentiertes Verhalten, das man nur kennen muss). Die interne Zone war öffentlich erreichbar. Gefunden haben wir es nur, weil zum Prozess gehört, Sperren von aussen gegen sich selbst zu testen. Die Details sind einen eigenen Beitrag wert.

Die Lehre daraus ist eine Prozess-Lehre, keine Tool-Lehre: Ein KI-Agent macht in einer Stunde so viel Infrastruktur, wie ich früher an einem Wochenende gebaut habe. Genau deshalb braucht es das Gegengewicht — dokumentierte Entscheidungen, Runbooks, Tests gegen die eigene Sicherheitsannahme. Tempo ohne Prüfprozess ist keine Produktivität, sondern aufgeschobener Schaden.

Drei Regeln haben sich dabei herauskristallisiert:

1. Kein Datenverlust, nie. Ein Alt-Dienst wird erst gekündigt, wenn der Export verifiziert und der Ersatz produktiv ist — Backups nach der 3-2-1-Regel.
2. Skripte sind die ausführbare Wahrheit. Was einmal ein Setup-Skript hat, wird nie wieder von Hand am Server geändert — erst das Skript anpassen, dann ausführen.
3. Jede Session endet mit einem Commit. Doku, die nicht im Repo liegt, existiert nicht.

Warum öffentlich?

Weil genau das unser Geschäft ist. Bei AnalytikData bauen wir mit Coautra einen revisionssicheren Entwicklungsprozess für KI-Tempo — und diese Serie ist derselbe Anspruch, angewandt auf die eigene Infrastruktur: ehrliche Erfahrungsberichte statt Hochglanz-Demos. Was funktioniert, was schiefgeht, und die Begründung dazu.

Als Nächstes steht die grösste Baustelle an: die Mail-Migration weg von Exchange und Google Workspace — der Moment, in dem «own your stack» ernst wird. Und die Geschichte mit dem Docker-Netzwerk-Loch bekommt ihren eigenen Beitrag.

Fragen, Einwände, eigene Erfahrungen? Schreib mir — ich antworte selbst.