Langfristig möchte ich einen erheblichen Teil meiner heutigen Codex-Arbeit auf eigener Hardware ausführen. Der Wunsch nach lokaler KI ist bei mir deshalb relativ klar, aber daraus ergibt sich sofort eine wesentlich schwierigere Frage: Was müsste ein lokales System eigentlich können, damit ich Codex tatsächlich abschalten könnte?
Ein Sprachmodell lokal zu starten, reicht dafür bei weitem nicht aus.
Ich brauche keine KI, die mir ein Stück Code in einem Chatfenster erklärt und anschließend darauf wartet, dass ich den Vorschlag selbst in Visual Studio Code kopiere. Meine heutige Arbeitsweise mit Codex geht deutlich weiter, und genau daran müsste sich ein lokaler Ersatz messen lassen.
Die Messlatte ist deshalb nicht: Läuft ein großes Modell auf meinem Rechner?
Die eigentliche Frage lautet: Kann dieses System meine reale Arbeit zuverlässig übernehmen?
Ein lokaler Ersatz müsste ganze Projekte verstehen
Meine Projekte bestehen nicht aus einer einzelnen Datei und auch nicht aus zehn sauber voneinander isolierten Klassen. Gerade ein System wie Kosmos besitzt viele Module, gemeinsame Komponenten, Schnittstellen und Entscheidungen, die sich gegenseitig beeinflussen.
Eine lokale KI müsste deshalb ein größeres Repository ausreichend gut analysieren können, um nicht nur die Datei zu verstehen, die gerade geöffnet ist.
Wenn ich eine neue Funktion beschreibe, muss das System erkennen können, welche bestehenden Bereiche davon betroffen sind, wo bereits ähnliche Strukturen existieren und ob eine scheinbar einfache Änderung Auswirkungen an anderer Stelle hat.
Das ist für mich ein zentraler Unterschied zwischen einem lokalen Coding-Modell und einem echten Codex-Ersatz.
Ein Modell kann hervorragenden C#-Code erzeugen und trotzdem für meine tägliche Arbeit ungeeignet sein, wenn es nicht zuverlässig mit dem Gesamtkontext eines größeren Projekts umgehen kann.
Das Modell müsste nicht nur antworten, sondern handeln
Noch wichtiger ist für mich das agentische Arbeiten.
Codex schreibt bei mir nicht einfach Codeblöcke in einen Chat. Es kann Dateien lesen, verändern, Builds starten, Fehlermeldungen analysieren und darauf reagieren.
Genau diese Schleife brauche ich lokal ebenfalls.
Eine typische Aufgabe sollte nicht nach dem ersten erzeugten Code enden. Die lokale KI müsste eine Änderung umsetzen, das Projekt kompilieren, einen Fehler erkennen, die Ursache untersuchen, den Code korrigieren und den Vorgang erneut prüfen können.
Das bedeutet, dass der eigentliche Ersatz aus wesentlich mehr bestehen muss als nur aus einem Sprachmodell.
Ich brauche eine sichere Ausführungsumgebung, Werkzeuge für Dateien und Shell-Befehle, Zugriffssteuerung, Protokollierung und eine Orchestrierung, die längere Arbeiten zuverlässig zusammenhält.
Das Modell ist dabei nur der denkende Teil.
Agenda müsste mit der lokalen KI sprechen können
Mein Zielprozess von der Idee bis zum Deployment hängt stark von Agenda ab.
Größere Konzepte werden vorbereitet, in konkrete Aufgaben zerlegt und anschließend kontrolliert freigegeben. Codex übernimmt eine Aufgabe, bearbeitet sie und meldet das Ergebnis zurück.
Ein lokaler Ersatz müsste deshalb genau in diesen Ablauf passen.
Ich möchte nicht meine gesamte Arbeitsweise neu bauen, nur weil statt Codex nun ein lokales Modell arbeitet.
Agenda sollte im Idealfall gar nicht besonders stark unterscheiden müssen, welcher technische Arbeiter eine Aufgabe übernimmt.
Eine freigegebene Aufgabe könnte an Codex gehen, an einen lokalen Agenten oder vielleicht später an unterschiedliche Systeme, je nachdem, welche Fähigkeiten und Kapazitäten verfügbar sind.
Damit würde die lokale KI nicht zum neuen Mittelpunkt meines gesamten Systems.
Sie wäre ein weiterer ausführender Bestandteil.
Genau das fände ich langfristig sinnvoll.
Sie müsste auch außerhalb von Quellcode arbeiten können
Codex arbeitet bei mir längst nicht mehr ausschließlich an Software. Ich benutze es auch für Linux-Systeme, Infrastruktur und technische Konfigurationen.
Ein lokaler Ersatz müsste deshalb idealerweise ebenfalls über klassische Codearbeit hinausgehen.
Wenn eine Agenda-Aufgabe lautet, auf einer Debian-VM einen bestimmten Zustand herzustellen, möchte ich nicht zuerst entscheiden müssen, ob dafür ein völlig anderes KI-System zuständig ist.
Dasselbe gilt für spätere Netzwerkaufgaben oder andere Administrationsarbeiten.
Natürlich braucht nicht jede Aufgabe exakt dasselbe Modell. Vielleicht ist es sogar sinnvoll, unterschiedliche lokale Modelle für verschiedene Tätigkeiten einzusetzen.
Die gesamte Umgebung müsste aber so aufgebaut sein, dass nicht jede neue Domäne wieder einen vollständig separaten Prozess benötigt.
Für mich wäre eine lokale KI deshalb am interessantesten als Teil einer allgemeineren technischen Agentenplattform.
Geschwindigkeit ist keine Nebensache
Bei lokalen Modellen wird häufig zuerst über Modellgröße und Qualität gesprochen.
Für meinen praktischen Einsatz ist Geschwindigkeit mindestens genauso wichtig.
Ein Modell kann theoretisch sehr leistungsfähig sein. Wenn eine normale Codex-Aufgabe auf meiner lokalen Hardware anschließend mehrere Stunden benötigt, verändert das meinen gesamten Arbeitsfluss.
Ein wesentlicher Vorteil meiner heutigen Arbeitsweise besteht darin, mehrere Dinge parallel laufen lassen zu können. Wenn eine lokale KI so langsam arbeitet, dass jeder Agent einen großen Teil der Hardware für sich beansprucht, wird genau diese Parallelität schwierig.
Ich brauche also nicht nur ausreichend Qualität für einzelne Aufgaben.
Ich brauche genügend Durchsatz für meine tatsächliche Arbeitsweise.
Das macht die Hardwarefrage deutlich anspruchsvoller.
Mehrere parallele Agenten erhöhen den Hardwarebedarf erheblich
Ein einzelnes großes Modell lokal auszuführen ist eine Sache. Mehrere Arbeiten parallel zu betreiben, ist etwas völlig anderes.
Wenn Agenda irgendwann mehrere voneinander unabhängige Aufgaben gleichzeitig freigibt, wäre es ideal, wenn diese auch tatsächlich gleichzeitig bearbeitet werden können.
Dafür muss entweder ein Modell mehrere Arbeitsstränge effizient bedienen können oder genügend Hardware vorhanden sein, um mehrere Modellinstanzen parallel zu betreiben.
Hinzu kommen möglicherweise separate Modelle für Tests.
Damit wächst die benötigte Rechenleistung sehr schnell.
Genau deshalb fehlt mir aktuell nicht nur irgendein Rechner, sondern ein System, das zu meinem gewünschten Arbeitsmodell passt.
Ich möchte nicht sehr viel Geld ausgeben und anschließend feststellen, dass die Hardware zwar einen beeindruckenden Chatbot betreiben kann, aber meine eigentliche Agenda-Pipeline ausbremst.
Der Kontext müsste dauerhaft besser organisiert werden
Ein weiteres Problem ist Projektwissen.
Eine KI kann nur mit Informationen arbeiten, die ihr tatsächlich zur Verfügung stehen. Bei größeren Projekten reicht es nicht, bei jeder Aufgabe das gesamte Repository und sämtliche bisherigen Entscheidungen vollständig in einen Kontext zu kopieren.
Ein lokales System müsste deshalb sinnvoll mit persistentem Projektwissen umgehen können.
Welche Architekturentscheidungen gelten?
Welche Bereiche gehören zusammen?
Welche Konventionen wurden bewusst festgelegt?
Welche Entscheidungen aus früheren Konzepten sind weiterhin relevant?
Welche Teile einer Aufgabe wurden bereits umgesetzt?
Das sind Fragen, die nicht allein durch ein großes Kontextfenster gelöst werden.
Langfristig brauche ich dafür eine Kombination aus Repository-Analyse, Dokumentation und strukturiertem Projektwissen.
Eine lokale KI hätte an dieser Stelle sogar einen interessanten Vorteil: Sie könnte dauerhaft auf meinen eigenen Daten arbeiten, ohne dass ich ständig überlegen muss, welche Informationen ich an einen externen Dienst übergeben möchte.
Die Tests müssten möglichst unabhängig bleiben
Ein lokaler Codex-Ersatz wirft außerdem mein bisher ungelöstes Testing-Problem erneut auf.
Meine automatisierten Tests sollen möglichst Fehler finden, die bei der Umsetzung übersehen wurden. Wenn dasselbe lokale Modell sowohl entwickelt als auch sämtliche Tests erzeugt, bleibt die Gefahr bestehen, dass dieselbe falsche Annahme beide Seiten beeinflusst.
Ein wirklich interessanter lokaler Aufbau könnte deshalb mehrere Modelle verwenden.
Ein Modell übernimmt beispielsweise die Umsetzung.
Ein anderes erzeugt unabhängig davon Testfälle.
Vielleicht bewertet ein drittes System wiederum, ob die Tests überhaupt ausreichend aussagekräftig sind.
Das klingt nach erheblichem Aufwand, wäre aber genau die Art von Aufbau, die mit eigener Hardware langfristig attraktiv werden könnte.
Nur erhöht sie natürlich erneut den Bedarf an Rechenleistung.
Datenschutz allein reicht mir als Begründung nicht
Lokale Verarbeitung ist für mich aus Datenschutzsicht sehr attraktiv, insbesondere wenn Kundendaten, Konfigurationen oder andere interne Informationen beteiligt sind.
Trotzdem würde ich keinen technisch deutlich schlechteren Prozess nur deshalb lokal betreiben, weil er lokal ist.
Wenn ich für jede Aufgabe wesentlich länger brauche, schlechtere Ergebnisse erhalte oder ständig manuell eingreifen muss, bringt mir die zusätzliche Kontrolle nur begrenzt etwas.
Mein Ziel ist deshalb nicht:
Alles muss lokal sein.
Mein Ziel lautet eher:
Alles, was sinnvoll lokal betrieben werden kann, sollte langfristig nicht unnötig von externen Diensten abhängig sein.
Das lässt durchaus Raum für Mischformen.
Vielleicht bleiben bestimmte besonders anspruchsvolle Aufgaben noch lange bei externen Modellen, während Routinearbeiten lokal laufen.
Damit könnte Agenda irgendwann sogar anhand der Aufgabe entscheiden, welches System am sinnvollsten ist.
Auch Wartbarkeit gehört zu den Anforderungen
Ein eigener KI-Rechner bedeutet zusätzliche Infrastruktur.
Treiber müssen funktionieren, Modelle müssen aktualisiert werden, Speicherplatz wird benötigt und irgendwann fällt Hardware aus.
Wenn ich durch die lokale KI mehr Zeit mit der Administration des KI-Systems verbringe, als ich durch seine Nutzung einspare, habe ich wenig gewonnen.
Der Aufbau müsste deshalb möglichst robust sein.
Gerade weil ich allein arbeite, kann ich mir nicht noch ein komplexes System schaffen, das ständig selbst Aufmerksamkeit benötigt.
Die lokale KI soll Arbeit übernehmen.
Sie soll nicht zur nächsten Vollzeitbaustelle werden.
Wann wäre Codex für mich tatsächlich ersetzbar?
Für mich wäre der Punkt erreicht, wenn eine lokale Lösung den größten Teil meiner normalen Agenda-Aufgaben zuverlässig übernehmen könnte, ohne dass ich meine Arbeitsweise dafür grundlegend vereinfachen muss.
Sie müsste größere Repositories verstehen, selbstständig Dateien bearbeiten, Builds und Tests durchführen, Fehler korrigieren und über längere Aufgaben hinweg stabil arbeiten.
Sie müsste sich in Agenda integrieren lassen, mit Infrastruktur umgehen können und ausreichend schnell sein, dass Parallelisierung weiterhin sinnvoll bleibt.
Außerdem müsste ich einen Weg finden, unabhängige Tests und Projektwissen vernünftig abzubilden.
Das ist eine deutlich höhere Anforderung als:
„Dieses Modell kann programmieren.“
Genau deshalb habe ich Codex heute noch nicht lokal ersetzt.
Bis dahin bleibt es ein Ziel, kein fertiges Projekt
Mich reizt die Vorstellung sehr, einen leistungsfähigen Rechner zu besitzen, auf dem meine eigenen Agenten rund um die Uhr arbeiten können, ohne dass jede zusätzliche Aufgabe externes Kontingent verbraucht.
Ich könnte Agenda Aufgaben freigeben und die verfügbare lokale Rechenleistung entscheiden lassen, wann sie abgearbeitet werden.
Kundendaten könnten innerhalb meiner eigenen Infrastruktur bleiben.
Und ich könnte verschiedene Modelle für unterschiedliche Aufgaben miteinander kombinieren.
Heute fehlt mir dafür allerdings noch die passende Hardware und ein Teil der technischen Architektur.
Deshalb ist die lokale KI für mich momentan vor allem ein Zielbild.
Der interessante Artikel wird wahrscheinlich irgendwann der sein, in dem ich tatsächlich einen ausreichend leistungsfähigen Rechner danebenstelle und dieselben Aufgaben sowohl lokal als auch mit Codex bearbeiten lasse.
Dann muss sich zeigen, ob der lokale Ansatz nur sympathischer klingt.
Oder ob er meine tägliche Arbeit wirklich übernehmen kann.