Infrastruktur & Technik

Warum ich Codex irgendwann durch eine lokale KI ersetzen möchte

Je stärker KI in meine tägliche Arbeit hineinwächst, desto häufiger stelle ich mir eine ziemlich grundsätzliche Frage: Möchte ich diese Arbeitsweise langfristig wirklich vollständig von externen Diensten abhängig machen?

Im Moment ist die Antwort pragmatisch. ChatGPT und Codex funktionieren für mich, ich kann damit produktiv arbeiten und viele Dinge umsetzen, die ohne diese Werkzeuge deutlich länger dauern würden. Gleichzeitig wächst aber auch mein Wunsch, zumindest einen erheblichen Teil dieser Arbeit irgendwann lokal auf eigener Hardware betreiben zu können.

Dabei geht es mir nicht darum, aus Prinzip alles in den eigenen Keller zu holen. Lokale KI ist für mich kein Selbstzweck und auch kein romantischer Gegenentwurf zur Cloud. Sie wird erst dann interessant, wenn sie meine bestehende Arbeitsweise tatsächlich sinnvoll ersetzen oder ergänzen kann.

Genau an diesem Punkt bin ich heute noch nicht.

Mein Ziel ist nicht einfach ein lokaler Chatbot

Eine lokale KI wäre für mich nur dann wirklich interessant, wenn sie deutlich mehr kann, als auf Fragen zu antworten oder kleine Codebeispiele zu erzeugen.

Ich brauche keinen zusätzlichen Chat, der mir erklärt, wie eine Schleife funktioniert. Ich brauche ein System, das große Projekte versteht, Dateien bearbeiten kann, Builds ausführt, Fehler analysiert, Tests startet und über längere Aufgaben hinweg einen belastbaren technischen Kontext behält.

Im Idealfall müsste eine lokale KI deshalb einen erheblichen Teil dessen übernehmen können, was ich heute mit Codex erledige.

Meine heutige Arbeitsweise verteilt Aufgaben bereits auf mehrere KI-Systeme und Arbeitsstränge. Eine lokale Lösung wäre für mich besonders dann spannend, wenn sie sich in diese bestehende Struktur einfügt und nicht wieder einen völlig getrennten Inselprozess erzeugt.

Langfristig möchte ich also nicht einfach „eine KI auf meinem Rechner“ haben.

Ich möchte einen lokalen technischen Arbeiter, der mit meinen Projekten, meiner Infrastruktur und Agenda zusammenarbeiten kann.

Agenda macht lokale KI für mich besonders interessant

Mit Agenda versuche ich Entwicklungsarbeit zunehmend so zu organisieren, dass vorbereitete Aufgaben selbstständig abgearbeitet werden können. Genau dort wird die Frage nach eigener Rechenleistung für mich spannend.

Solange jede Aufgabe externes Kontingent verbraucht, ist die verfügbare Kapazität immer auch eine wirtschaftliche Grenze. Wenn mehrere Aufgaben parallel vorbereitet sind, könnte ich sie technisch vielleicht ausführen lassen, muss aber trotzdem im Blick behalten, wie viel externes Kontingent dadurch verbraucht wird.

Bei einer eigenen KI-Hardware verschiebt sich diese Grenze.

Dann kostet eine zusätzliche Aufgabe nicht plötzlich zusätzliche Tokens oder ein weiteres Kontingent. Natürlich entstehen weiterhin Kosten durch Anschaffung, Strom, Wartung und irgendwann neue Hardware, aber die Nutzung fühlt sich wirtschaftlich anders an.

Wenn der Rechner ohnehin läuft, kann Agenda Arbeit verteilen, solange genügend lokale Rechenleistung vorhanden ist.

Für meine Vorstellung von langfristig automatisierter Arbeit ist das sehr attraktiv.

Datenschutz spielt ebenfalls eine Rolle

Ein zweiter wichtiger Punkt ist die Frage, welche Daten ich überhaupt an externe Systeme geben möchte.

Bei eigenen Projekten kann ich relativ frei entscheiden, was ich mit ChatGPT oder Codex bearbeite. Schwieriger wird es, sobald echte Kundendaten, interne Konfigurationen oder sensible Informationen Teil einer Aufgabe werden.

Je stärker Codex nicht nur Software entwickelt, sondern auch Linux-Systeme, Hardware und Infrastruktur in meine Arbeit einbezogen werden, desto häufiger entstehen technische Informationen, die ich nicht automatisch an irgendeinen externen Dienst geben möchte.

Eine lokale KI würde dieses Problem nicht vollständig lösen. Auch dort müsste ich Zugriffsrechte, Protokollierung, Datensicherung und Sicherheit sauber gestalten.

Ich hätte aber deutlich mehr Kontrolle darüber, wo die Daten verarbeitet werden und welche Systeme überhaupt Zugriff darauf erhalten.

Für geschäftliche Nutzung ist das für mich ein wichtiger Unterschied.

Der schwierigste Punkt ist heute die Hardware

Technisch gibt es bereits viele interessante lokale Modelle und Werkzeuge. Ich experimentiere auch mit lokalen Lösungen, aber zwischen „ein Modell läuft“ und „ich kann Codex damit ernsthaft ersetzen“ liegt eine ziemlich große Lücke.

Ein lokaler Coding-Agent muss nicht nur gute Antworten erzeugen. Er muss ausreichend schnell sein, große Kontexte verarbeiten können und über längere Aufgaben hinweg zuverlässig arbeiten.

Genau dafür braucht es viel Rechenleistung.

Und diese Rechenleistung kostet Geld.

Das ist aktuell der Hauptgrund, warum mein Ziel noch nicht umgesetzt ist. Ich könnte mir irgendeinen Rechner hinstellen, auf dem ein lokales Modell läuft, aber damit wäre mein eigentliches Problem nicht gelöst. Wenn eine normale Entwicklungsaufgabe anschließend mehrere Stunden dauert oder das Modell bei größeren Projekten deutlich schlechter arbeitet als Codex, wäre die Lösung zwar lokal, aber nicht wirklich brauchbar.

Ich möchte nicht lokal um jeden Preis.

Ich möchte lokal auf einem Niveau arbeiten können, das für meinen Alltag ausreicht.

Ein lokales Modell müsste große Projekte verstehen können

Gerade Kosmos zeigt ziemlich gut, warum kleine lokale Experimente für mich nicht genügen.

Das Projekt besteht aus mehreren Modulen, gemeinsamen Komponenten, Schnittstellen und vielen Entscheidungen, die über längere Zeit entstanden sind. Ein Coding-Agent muss deshalb mehr können, als eine einzelne Datei zu lesen und darin eine Methode zu ergänzen.

Er muss erkennen, welche Bereiche von einer Änderung betroffen sind, vorhandene Strukturen berücksichtigen und möglichst vermeiden, an einer Stelle eine Lösung einzubauen, die an anderer Stelle neue Probleme erzeugt.

Der Unterschied zwischen Sara, Kosmos und Linea zeigt bereits, wie stark sich meine Entwicklung durch KI verändert hat. Wenn ich Codex lokal ersetzen möchte, muss die neue Lösung genau in diesem komplexeren Arbeitsmodell bestehen können.

Ein Modell, das nur bei kleinen Einzelaufgaben gut funktioniert, wäre für mich deshalb eher Ergänzung als Ersatz.

Agentisches Arbeiten ist wichtiger als reine Modellqualität

Ein weiterer Punkt wird bei Diskussionen über lokale KI aus meiner Sicht häufig unterschätzt: Das Sprachmodell allein ist nur ein Teil des Systems.

Für meine Arbeit brauche ich Werkzeuge rundherum.

Die KI muss Dateien lesen und verändern können, Shell-Befehle ausführen, Builds starten, Testergebnisse auswerten und bei Fehlern mehrere Lösungsversuche durchführen können. Sie muss außerdem in der Lage sein, mit Agenda zu kommunizieren, Aufgaben zu übernehmen und Ergebnisse sauber zurückzumelden.

Das bedeutet, dass die Frage nicht nur lautet:

Welches lokale Modell ist intelligent genug?

Sondern auch:

Wie baue ich darum eine Arbeitsumgebung, die ähnlich zuverlässig funktioniert wie mein heutiger Codex-Prozess?

Gerade dieser zweite Teil dürfte mindestens genauso interessant werden wie die Auswahl des eigentlichen Modells.

Lokale KI würde mein Testproblem nicht automatisch lösen

Bei meinen automatisierten Tests beschäftigt mich die Frage, wie unabhängig die Prüfung von der Implementierung sein muss. Eine lokale KI würde dieses Problem zunächst nicht lösen.

Wenn dieselbe lokale Modellinstanz Code erzeugt und anschließend die Tests schreibt, bleibt die grundlegende Abhängigkeit bestehen.

Im Gegenteil: Wenn ich irgendwann vollständig lokal arbeite, müsste ich wahrscheinlich sogar bewusster darüber nachdenken, ob ich mehrere unterschiedliche Modelle für unterschiedliche Aufgaben betreibe.

Eine lokale Entwicklungs-KI und eine davon unabhängige Test-KI wären fachlich reizvoll, erhöhen aber natürlich die Hardwareanforderungen erneut.

Damit wird schnell klar, dass lokale KI nicht einfach nur eine Frage nach einer einzelnen Grafikkarte ist.

Sie verändert die gesamte technische Architektur meiner KI-Arbeitsweise.

Wirtschaftlich ist die Rechnung nicht trivial

Auf den ersten Blick lässt sich die Rechnung einfach formulieren: Wenn externe KI jeden Monat Geld kostet, lohnt sich irgendwann ein eigener Rechner.

Ganz so einfach ist es natürlich nicht.

Eigene Hardware muss gekauft, betrieben und irgendwann ersetzt werden. Stromkosten spielen eine Rolle. Leistungsfähige GPUs sind teuer. Gleichzeitig entwickeln sich Modelle und Hardware schnell weiter, sodass heute gekaufte Technik in einigen Jahren vielleicht nicht mehr attraktiv ist.

Auf der anderen Seite steht die Möglichkeit, die eigene Hardware praktisch rund um die Uhr zu nutzen, ohne jede zusätzliche Aufgabe einzeln gegen ein Kontingent abzuwägen.

Für mich wird deshalb irgendwann ein eigener Vergleich notwendig sein:

Was kostet mich meine aktuelle externe KI-Nutzung tatsächlich pro Jahr?

Welche Hardware würde ich brauchen, um meine reale Arbeit lokal abzubilden?

Wie schnell wäre sie?

Welche Modelle wären qualitativ ausreichend?

Und wie viele Jahre müsste die Hardware laufen, bis sich die Anschaffung wirtschaftlich rechnet?

Heute kann ich diese Fragen noch nicht seriös beantworten.

Im Moment bleibt lokale KI ein Ziel

Ich finde es wichtig, diesen Punkt so klar zu formulieren, weil lokale KI schnell größer dargestellt wird, als sie in der eigenen Praxis tatsächlich ist.

Ich betreibe heute noch keinen lokalen Codex-Ersatz.

Ich habe auch noch keine Hardware, mit der ich meinen gesamten Entwicklungsprozess auf demselben Niveau lokal abbilden könnte.

Das Ziel ist aber ziemlich eindeutig.

Langfristig möchte ich weniger abhängig von externen Kontingenten sein, mehr Kontrolle über sensible Daten haben und die Möglichkeit bekommen, Agenda-Aufgaben auf eigener Rechenleistung abarbeiten zu lassen.

Ob das wirtschaftlich und technisch wirklich sinnvoll funktioniert, muss ich erst noch herausfinden.

Und genau deshalb gehört das Thema für mich in diesen Wissensbereich.

Nicht als Erfolgsgeschichte darüber, wie problemlos ich Codex bereits ersetzt habe, sondern als offener Entwicklungsschritt, bei dem das gewünschte Ziel schon ziemlich klar ist, der Weg dorthin aber noch nicht.