Wenn über Codex gesprochen wird, denkt man normalerweise zuerst an Quellcode. Ein Repository wird geöffnet, eine Aufgabe beschrieben und anschließend verändert die KI Dateien, führt Builds aus oder untersucht Fehler.
So hat es bei mir ebenfalls angefangen.
Inzwischen ist diese Grenze allerdings längst verschwommen. Codex arbeitet bei mir nicht mehr ausschließlich an Softwareprojekten, sondern greift auch auf Linux-Systeme zu, hilft bei der Konfiguration realer Geräte und soll künftig komplette Teile meiner Netzwerkinfrastruktur mit aufbauen.
Dadurch verändert sich nicht nur der Umfang dessen, was ich mit KI erledigen kann. Auch die Risiken werden andere, denn eine falsche Änderung an einem Stück Quellcode lässt sich häufig wesentlich einfacher zurücknehmen als eine falsche Konfiguration auf einem Gerät, über das ich anschließend keinen Zugriff mehr habe.
Aus Codearbeit wird zunehmend Systemarbeit
Der entscheidende Unterschied liegt für mich darin, dass ich Codex immer seltener einen konkreten Befehl geben muss und stattdessen beschreiben kann, welchen Zustand ich erreichen möchte.
Bei einer Linux-VM muss ich beispielsweise nicht zwangsläufig selbst jeden einzelnen Shell-Befehl zusammensuchen und eingeben. Ich kann beschreiben, welches Problem besteht oder welche Änderung notwendig ist, und Codex kann den vorhandenen Zustand untersuchen, geeignete Befehle ausführen und das Ergebnis anschließend überprüfen.
Das ist besonders interessant bei Systemen, auf die ich selbst keinen besonders komfortablen manuellen Zugriff habe. Statt mich erst durch mehrere Verbindungen und Konsolen zu arbeiten, kann Codex direkt dort arbeiten, wo der technische Zugriff bereits vorhanden ist.
Meine eigene Aufgabe verschiebt sich dadurch von der konkreten Bedienung stärker hin zur Definition des gewünschten Ergebnisses.
Bei einer Kamera wurde daraus bereits Arbeit an echter Hardware
Ein besonders anschauliches Beispiel ist eine IP-Kamera, an der ich mit Unterstützung von Codex gearbeitet habe.
Spätestens an diesem Punkt endet die Vorstellung, dass ein Coding-Agent nur irgendwelche Dateien in einem Projektordner verändert. Die Softwareseite und das tatsächliche Gerät hängen unmittelbar zusammen, und Änderungen können das Verhalten realer Hardware beeinflussen.
Das macht solche Aufgaben für mich besonders interessant, weil die Grenze zwischen Softwareentwicklung, Administration und Hardwarekonfiguration immer weniger eindeutig wird.
Codex muss verstehen, welches Gerät vorhanden ist, welche Schnittstellen es bietet, welche Konfigurationen möglich sind und welche Folgen eine Änderung haben kann. Gleichzeitig muss ich selbst beurteilen können, ob der vorgeschlagene Weg sinnvoll und sicher ist.
Gerade bei ungewöhnlichen Geräten kann diese Form der Arbeit sehr viel Recherche und manuelle Detailarbeit sparen.
Firmware ist eine andere Risikoklasse
Noch deutlicher wird der Unterschied bei Firmware.
Bei meinen Devolo-Adaptern wäre beispielsweise denkbar, mit Codex eine andere oder neuere Firmware einzuspielen, sofern für das konkrete Modell ein geeigneter und sicherer Weg gefunden wird.
Technisch klingt das zunächst nach einer weiteren Administrationsaufgabe. In Wirklichkeit ist die Risikoklasse aber eine andere.
Wenn eine Konfigurationsdatei fehlerhaft ist, lässt sie sich häufig korrigieren. Wenn ein Dienst nach einer Änderung nicht mehr startet, kann ich Logs lesen, die Konfiguration zurücksetzen oder ein Backup einspielen.
Ein fehlgeschlagenes Firmware-Update kann dagegen dazu führen, dass ein Gerät anschließend gar nicht mehr normal erreichbar ist.
Deshalb kann nicht jede Aufgabe mit demselben Automatisierungsgrad behandelt werden.
Je größer die möglichen Auswirkungen sind, desto wichtiger werden kontrollierte Zwischenschritte, Backups, Wiederherstellungswege und bewusste Freigaben.
Meine Debian-VM zeigt die andere Seite des Problems
Auf einer Debian-VM ist die Situation anders. Dort kann Codex sehr weitgehend arbeiten, weil das System deutlich besser kontrollierbar ist und Änderungen nachvollziehbar durchgeführt werden können.
Gerade dort finde ich die neue Abstraktionsebene spannend.
Früher hätte die typische Frage gelautet:
„Welchen Linux-Befehl brauche ich dafür?“
Heute kann ich eher formulieren:
„Das System soll diesen Zustand erreichen. Prüfe, wie es aktuell aussieht, ändere die notwendigen Dinge und kontrolliere anschließend, ob das Ziel erreicht wurde.“
Das bedeutet nicht, dass ich Linux nicht mehr verstehen muss. Im Gegenteil: Wenn Codex einen problematischen Weg einschlägt, muss ich genügend technisches Verständnis besitzen, um das Ergebnis bewerten zu können.
Ich muss aber nicht mehr zwangsläufig jeden einzelnen Befehl selbst eintippen.
Der nächste Schritt ist ein komplettes Netzwerk
Besonders gespannt bin ich deshalb auf ein geplantes Experiment, bei dem Codex nicht nur ein einzelnes Gerät verändern, sondern einen vollständigen kleinen Netzwerkaufbau begleiten soll.
Geplant ist ein Aufbau mit einem MikroTik hEX, zwei MikroTik-Switches und einer OPNsense-Appliance als echter Hardware. Daraus soll eine realistische kleine Unternehmensstruktur mit mehreren Netzen, VLANs, Managementzugängen, Routing und Firewallregeln entstehen.
Die interessante Frage lautet dabei nicht nur, ob Codex einzelne RouterOS- oder OPNsense-Konfigurationen erzeugen kann.
Spannend wird es an den Übergängen.
Passen die VLANs an beiden Seiten einer Verbindung zusammen?
Sind Routing und Firewallregeln konsistent?
Ist klar, welches Gerät welche Aufgabe übernimmt?
Werden Managementzugänge ausreichend geschützt?
Erkennt Codex, wenn eine geplante Änderung den eigenen Zugriff auf die Infrastruktur unterbrechen könnte?
Genau dort zeigt sich, ob KI nur einzelne Befehle kennt oder tatsächlich einen größeren technischen Zusammenhang beherrscht.
Ein Router ist kein normales Softwareprojekt
Bei Software bin ich inzwischen daran gewöhnt, dass Änderungen über Versionsverwaltung nachvollziehbar bleiben und sich viele Fehler relativ bequem korrigieren lassen.
Bei Netzwerkhardware sieht das anders aus.
Wenn Codex auf einem Router eine falsche Änderung vornimmt, kann die Folge schlicht sein, dass der Router anschließend nicht mehr erreichbar ist.
Besonders interessant wird es, wenn genau dieses Gerät Teil des Zugangswegs ist, über den Codex selbst arbeitet. Dann kann eine technisch falsche Änderung nicht nur die Umgebung beschädigen, sondern gleichzeitig die Möglichkeit beseitigen, den Fehler aus der Ferne wieder zu korrigieren.
Deshalb braucht KI-gestützte Infrastrukturarbeit andere Sicherheitsmechanismen als normale Codearbeit.
Vor riskanten Änderungen muss klar sein, wie ein Rückweg aussieht. Konfigurationen sollten gesichert werden, Änderungen möglichst in kontrollierten Schritten erfolgen und kritische Aktionen eine bewusste Freigabe erhalten.
Das Human Gate wird bei realer Infrastruktur wichtiger
Bei meiner automatisierten Softwareentwicklung möchte ich ohnehin bestimmte Freigabepunkte bewusst bei mir behalten. Bei echter Infrastruktur wird dieser Gedanke noch wichtiger.
Nicht jede Änderung benötigt meine persönliche Zustimmung. Wenn Codex beispielsweise einen ungefährlichen Dienst neu startet oder eine eindeutig fehlerhafte Konfiguration innerhalb einer Testumgebung korrigiert, kann das durchaus automatisch geschehen.
Bei Änderungen an Firewallregeln, Managementzugängen, Routing, Firmware oder anderen zentralen Komponenten möchte ich dagegen sehr genau wissen, was passieren soll.
Der Sinn von Automatisierung besteht für mich nicht darin, Kontrolle vollständig abzugeben.
Sie soll vielmehr die Arbeit zwischen den Entscheidungen übernehmen.
Auch hier müssen die Ergebnisse getestet werden
Eine Konfiguration ist nicht deshalb richtig, weil das Gerät sie akzeptiert hat.
Wenn Codex ein VLAN einrichtet und anschließend keine Fehlermeldung erscheint, beweist das noch nicht, dass die gewünschte Trennung tatsächlich funktioniert. Wenn eine Firewallregel gespeichert wurde, bedeutet das nicht automatisch, dass nur die vorgesehenen Kommunikationswege möglich sind.
Deshalb gilt bei Infrastruktur im Grunde dieselbe Haltung wie bei meinen automatisierten Softwaretests.
Ich möchte nicht nur bestätigen, dass der gewünschte Weg funktioniert.
Ich möchte auch prüfen, dass die unerwünschten Wege nicht funktionieren.
Ein Gastnetz soll beispielsweise ins Internet gelangen können, aber keine internen Systeme erreichen. Ein Managementnetz soll administrative Zugriffe ermöglichen, während dieselben Zugriffe aus normalen Clientnetzen blockiert bleiben. Ein Gerät darf einen bestimmten Dienst erreichen, aber eben nicht automatisch jedes andere System im Netzwerk.
Gerade diese negativen Tests sind bei Netzwerkkonfigurationen entscheidend.
Codex wird damit für mich zu einer allgemeinen technischen Schnittstelle
Je mehr ich mit solchen Aufgaben experimentiere, desto weniger sehe ich Codex ausschließlich als Werkzeug für Softwareentwicklung.
Es wird für mich zunehmend zu einer technischen Arbeitsschicht zwischen meiner Absicht und den Systemen, an denen etwas verändert werden soll.
Bei Software bedeutet das: Ich beschreibe das gewünschte Verhalten und Codex verändert den Code.
Bei Linux bedeutet es: Ich beschreibe den gewünschten Zustand und Codex führt die notwendigen administrativen Schritte durch.
Bei Netzwerkhardware kann es bedeuten: Ich definiere Kommunikationsregeln, Segmentierung und Sicherheitsanforderungen, während Codex daraus konkrete Konfigurationen für unterschiedliche Geräte ableitet.
Und bei anderen Geräten kann derselbe Ansatz wiederum völlig anders aussehen.
Dadurch wird technisches Wissen nicht überflüssig
Die vielleicht wichtigste Erkenntnis daraus ist für mich, dass KI technisches Verständnis nicht ersetzt.
Wenn ich nicht beurteilen kann, ob ein Vorschlag sinnvoll ist, wird aus der höheren Geschwindigkeit schnell ein Risiko. Codex kann sehr überzeugend einen falschen Weg einschlagen, genau wie es sehr überzeugend fehlerhaften Code erzeugen kann.
Meine Arbeit verschiebt sich deshalb zunehmend weg vom Auswendigwissen einzelner Befehle und hin zum Verständnis von Zusammenhängen, Zielen und Risiken.
Ich muss vielleicht nicht mehr jeden RouterOS-Befehl aus dem Kopf kennen.
Ich muss aber sehr wohl verstehen, welche Systeme miteinander kommunizieren dürfen, wie Segmentierung funktionieren soll und welche Auswirkungen eine Änderung an Routing oder Firewall haben kann.
Genau diese Verschiebung finde ich spannend.
Denn sie zeigt, dass KI bei mir längst nicht mehr nur verändert, wie ich programmiere.
Sie verändert zunehmend, wie ich technische Arbeit insgesamt erledige.