Wenn ich ein Linux-System administriere, besteht die klassische Arbeitsweise aus einer Kette relativ konkreter Schritte: per SSH verbinden, den aktuellen Zustand untersuchen, passende Befehle recherchieren oder aus dem Gedächtnis abrufen, Konfigurationsdateien bearbeiten, Dienste neu starten und anschließend prüfen, ob alles funktioniert. Daran ist grundsätzlich nichts falsch, und genau so habe ich Linux-Systeme lange administriert.
Mit Codex verändert sich bei mir inzwischen weniger das technische Ziel als die Ebene, auf der ich die Aufgabe formuliere. Statt jeden einzelnen Shell-Befehl selbst vorzugeben, kann ich häufiger beschreiben, welchen Zustand ich erreichen möchte, und Codex die notwendigen Schritte innerhalb des Systems selbst ermitteln lassen.
Das ist für mich eine ähnliche Veränderung wie bei der Softwareentwicklung. Dort frage ich immer seltener, wie ich eine bestimmte Methode programmieren muss, und immer häufiger, welches Verhalten die fertige Funktion haben soll. Bei Linux verschiebt sich die Frage entsprechend von „Welchen Befehl brauche ich?“ zu „Wie muss dieses System anschließend aussehen?“.
Meine Debian-VM ist dafür ein gutes Beispiel
Ich betreibe unter anderem eine Debian-VM, auf der verschiedene technische Aufgaben laufen. Der manuelle Zugriff darauf ist für mich nicht besonders komfortabel, und genau deshalb ist sie ein gutes Beispiel dafür, wie sich meine Arbeitsweise verändert.
Früher hätte ich mich zunächst selbst mit dem System verbunden, den aktuellen Zustand geprüft und danach Schritt für Schritt die notwendigen Änderungen durchgeführt. Heute kann Codex einen erheblichen Teil dieses Weges übernehmen, sofern der technische Zugriff vorhanden und die Aufgabe ausreichend klar beschrieben ist.
Ich muss beispielsweise nicht unbedingt wissen, welche konkrete Konfigurationsdatei an welcher Stelle angepasst werden muss, wenn das Ziel eindeutig ist. Codex kann den vorhandenen Zustand untersuchen, die relevante Konfiguration finden, Änderungen vornehmen und anschließend prüfen, ob der gewünschte Zustand tatsächlich erreicht wurde.
Das spart mir nicht nur Tipp- und Recherchearbeit, sondern reduziert auch die Anzahl der Ebenen, durch die ich mich für eine vergleichsweise kleine Administrationsaufgabe selbst bewegen muss.
Natürliche Sprache ersetzt dabei nicht mein technisches Verständnis
Der entscheidende Punkt ist für mich allerdings, dass die höhere Abstraktionsebene technisches Verständnis nicht überflüssig macht.
Wenn ich Codex sage, dass ein bestimmter Dienst von außen erreichbar sein soll, muss ich trotzdem beurteilen können, ob das überhaupt sinnvoll und sicher ist. Wenn eine Anwendung mehr Rechte benötigt, sollte ich verstehen, welche Auswirkungen diese Rechte haben. Und wenn Codex eine bestehende Firewallregel oder Systemkonfiguration verändern möchte, muss ich einordnen können, ob die vorgeschlagene Änderung zum gewünschten Sicherheitsmodell passt.
Die KI kann viele technische Details übernehmen, aber sie übernimmt nicht automatisch die Verantwortung für das Ergebnis.
Das ist bei Linux nicht anders als bei meiner Arbeit mit realer Hardware und Netzwerkinfrastruktur. Je näher eine automatisierte Änderung an produktive Systeme und deren Erreichbarkeit kommt, desto wichtiger wird eine klare Grenze zwischen ausführbarer Technik und bewusster Entscheidung.
Zielzustände sind für mich oft sinnvoller als Befehlsfolgen
Der klassische Administrationsauftrag lautet häufig in etwa: Führe Befehl A aus, ändere Datei B und starte anschließend Dienst C neu.
Das funktioniert, setzt aber voraus, dass ich bereits weiß, welcher technische Weg der richtige ist. Gerade bei Systemen, mit denen ich nicht täglich arbeite, entsteht ein erheblicher Teil des Aufwands deshalb schon bei der Recherche.
Mit Codex kann ich die Aufgabe anders formulieren. Ich kann beschreiben, welcher Dienst verfügbar sein soll, welche Schnittstelle verwendet werden darf, welche Rechte gelten und welche Randbedingungen nicht verändert werden sollen.
Damit erhält Codex mehr Freiheit bei der technischen Umsetzung, während das eigentliche Ziel trotzdem klarer beschrieben wird.
Diese Trennung gefällt mir, weil sie besser zu der Art passt, wie ich inzwischen auch größere Softwarethemen angehe: möglichst präzise beschreiben, was gelten soll, und technische Detailentscheidungen dort delegieren, wo sie aus dem vorhandenen System zuverlässig ableitbar sind.
Der vorhandene Zustand muss trotzdem zuerst verstanden werden
Gerade bei Infrastruktur halte ich es für gefährlich, direkt mit Änderungen zu beginnen.
Ein Linux-System besitzt meistens eine Geschichte. Dienste wurden irgendwann installiert, Konfigurationen angepasst, Benutzer angelegt und vielleicht Workarounds eingebaut, deren Grund Monate später nicht mehr sofort erkennbar ist.
Codex sollte deshalb nicht einfach von einer idealisierten Standardinstallation ausgehen.
Bevor eine relevante Änderung vorgenommen wird, muss der aktuelle Zustand analysiert werden. Welche Distribution und Version läuft tatsächlich? Welche Dienste sind aktiv? Welche Pakete wurden installiert? Welche Konfigurationen existieren bereits, und gibt es Abhängigkeiten, die durch eine scheinbar einfache Änderung beeinflusst werden könnten?
Genau dieses Problem kenne ich bereits aus dem Bereich Projektwissen. Der heutige Zustand eines Systems zeigt zwar viel, aber nicht immer, warum er so entstanden ist.
Bei Infrastruktur kommt hinzu, dass falsche Annahmen sehr schnell die Erreichbarkeit beeinträchtigen können.
Bei Linux sind Rollbacks nicht immer so bequem wie bei Code
In einem Git-Repository kann ich eine problematische Änderung häufig relativ bequem nachvollziehen und zurücknehmen. Auf einem laufenden Linux-System ist das je nach Aufgabe deutlich schwieriger.
Eine veränderte Konfigurationsdatei lässt sich problemlos sichern und wiederherstellen, sofern daran vorher gedacht wurde. Ein Paketupdate, eine Datenmigration oder eine komplexere Systemänderung kann dagegen wesentlich mehr Nebenwirkungen besitzen.
Deshalb möchte ich auch hier stärker mit vorbereiteten Rückfallwegen arbeiten.
Vor einer riskanteren Änderung sollte klar sein, welche Dateien gesichert werden, wie der bisherige Zustand dokumentiert wird und auf welchem Weg die Änderung wieder rückgängig gemacht werden kann.
Beim automatisierten Deployment beschäftige ich mich mit genau derselben Frage. Automatisierung ist für mich erst dann wirklich belastbar, wenn sie nicht nur den glücklichen Weg kennt, sondern auch mit einem fehlgeschlagenen Ergebnis umgehen kann.
Codex kann nach der Änderung direkt prüfen
Ein großer Vorteil agentischer Administration liegt für mich darin, dass die Arbeit nicht mit dem letzten ausgeführten Befehl enden muss.
Wenn Codex eine Konfiguration ändert, kann es anschließend den Dienststatus prüfen, Logs auswerten, eine Verbindung testen oder kontrollieren, ob die erwartete Einstellung tatsächlich aktiv ist.
Damit wird aus einer Befehlsfolge ein kleiner Regelkreis:
Zustand analysieren, Änderung planen, Änderung durchführen, Ergebnis prüfen und bei einem eindeutigen technischen Fehler gegebenenfalls korrigieren.
Genau diese Schleife ist für mich wesentlich interessanter als die reine Fähigkeit einer KI, einen korrekten Linux-Befehl zu nennen.
Der eigentliche Nutzen entsteht dort, wo das System nicht nur erklärt, was ich tun könnte, sondern innerhalb klarer Grenzen überprüft, ob das gewünschte Ergebnis tatsächlich erreicht wurde.
Trotzdem möchte ich nicht jede Änderung vollständig autonom ausführen lassen
Bei ungefährlichen administrativen Aufgaben kann ein hoher Automatisierungsgrad sinnvoll sein. Wenn beispielsweise ein eindeutig definierter Dienst neu gestartet oder eine bekannte Konfiguration innerhalb einer Testumgebung angepasst werden muss, sehe ich wenig Nutzen darin, jeden einzelnen Schritt erneut manuell zu bestätigen.
Bei Änderungen an Netzwerkzugängen, Firewallregeln, Benutzerrechten, Paketquellen oder anderen zentralen Komponenten möchte ich dagegen stärker eingebunden bleiben.
Ein falscher Schritt kann genau den Zugang abschneiden, über den Codex anschließend den Fehler beheben sollte.
Das ist eine interessante Besonderheit agentischer Infrastrukturarbeit: Das System kann während seiner eigenen Arbeit die Voraussetzungen zerstören, die es für die weitere Arbeit benötigt.
Deshalb gehören Erreichbarkeit und Rückfallwege für mich zu den Randbedingungen einer Aufgabe und nicht erst zur Fehlerbehandlung danach.
Für Netzwerke gilt dasselbe Prinzip in größerem Maßstab
Der Schritt von einer Debian-VM zu einem Router oder einer Firewall ist technisch größer, folgt gedanklich aber demselben Muster.
Bei meinem geplanten Aufbau mit MikroTik- und OPNsense-Hardware möchte ich ebenfalls nicht jeden einzelnen Konfigurationsbefehl vorher selbst formulieren. Interessanter ist für mich, Anforderungen wie Segmentierung, erlaubte Kommunikationswege, Managementzugänge und Sicherheitsgrenzen sauber zu beschreiben.
Codex kann daraus anschließend die konkrete Konfiguration ableiten.
Für praktische Themen rund um kleine Unternehmensnetze und deren Betrieb gibt es bei mir mit felderhoff.it ohnehin eine eigene Perspektive. Dort interessiert weniger mein persönlicher KI-Workflow, sondern vielmehr, was eine technische Lösung für den zuverlässigen Betrieb eines Unternehmens bedeutet.
Hier auf endlich-montag.it interessiert mich dagegen vor allem, wie sich meine eigene technische Arbeit verändert, wenn natürliche Sprache zunehmend zur Steuerungsebene über klassischen Administrationswerkzeugen wird.
Ich muss weniger Syntax kennen, aber mehr Zusammenhänge verstehen
Das ist wahrscheinlich die wichtigste Verschiebung für mich.
Früher war es hilfreich, viele konkrete Befehle auswendig zu kennen. Natürlich ist dieses Wissen immer noch nützlich, insbesondere wenn etwas schiefläuft oder schnell geprüft werden muss. Trotzdem wird es für meine tägliche Arbeit weniger entscheidend, die exakte Syntax jeder selten verwendeten Option sofort parat zu haben.
Wichtiger wird die Fähigkeit, einen sinnvollen Zielzustand zu definieren und anschließend zu beurteilen, ob die vorgeschlagene Umsetzung tatsächlich dorthin führt.
Ich muss verstehen, wie Dienste zusammenhängen, welche Rechte notwendig sind, welche Netzwerke erreichbar sein sollen und welche Sicherheitsgrenzen gelten.
Die Abstraktionsebene steigt.
Der technische Anspruch verschwindet dadurch nicht, sondern verändert sich.
Genau darin sehe ich die Verbindung zu agentischen Systemen
Mein Weg hin zur Entwicklung agentischer Systeme besteht zu einem großen Teil aus genau solchen Veränderungen.
Ein Agent soll nicht nur eine Antwort formulieren, sondern innerhalb definierter Grenzen handeln, den Zustand seiner Umgebung berücksichtigen und das Ergebnis seiner Arbeit selbst prüfen können.
Eine Linux-VM ist dafür ein sehr anschauliches Beispiel, weil die Aktionen unmittelbar sichtbar sind. Ein Paket ist installiert oder nicht, ein Dienst läuft oder läuft nicht, eine Schnittstelle ist erreichbar oder nicht.
Damit lassen sich agentische Arbeitsweisen an einem realen System ausprobieren, ohne dass alles zwangsläufig Softwareentwicklung sein muss.
Langfristig könnte Agenda solche administrativen Aufgaben genauso verwalten wie Entwicklungsaufgaben. Eine vorbereitete Aufgabe würde freigegeben, ein geeigneter Agent übernimmt sie, Änderungen werden ausgeführt und geprüft, und nur bei einem echten Entscheidungsbedarf lande wieder ich im Prozess.
Die Shell verschwindet deshalb nicht
Ich glaube nicht, dass Kommandozeilen und klassische Administration plötzlich überflüssig werden.
Im Gegenteil: Codex arbeitet letztlich mit genau diesen Werkzeugen. Der Unterschied besteht darin, dass ich sie nicht mehr bei jeder Aufgabe selbst direkt bedienen muss.
Für mich wird die Shell dadurch zunehmend zu einer Ausführungsebene, während natürliche Sprache eine Ebene darüber entsteht.
Ich sage, welches Ergebnis ich brauche.
Codex entscheidet innerhalb der gesetzten Grenzen, welche technischen Werkzeuge dafür notwendig sind.
Und ich prüfe, ob Ziel, Risiken und Ergebnis zusammenpassen.
Das ist für mich eine wesentlich interessantere Entwicklung als die Frage, ob KI den besseren Bash-Befehl kennt.
Wenn du selbst mit Codex oder anderen Agenten an Linux-Systemen experimentierst, interessiert mich besonders, an welcher Stelle du die Grenze zwischen selbstständiger Ausführung und manueller Freigabe ziehst. Genau diese Grenze halte ich derzeit für eine der spannendsten Fragen bei KI-gestützter Administration.