Local-First Engineering Assistant

01

Warum ich ihn baue

Ich möchte verstehen, wie solche Systeme funktionieren, und herausfinden, wie viel meiner Arbeit auf dem eigenen Rechner bleiben kann.

KI gehört inzwischen zur technischen Arbeit und zum Programmieren, auch bei mir. Ich möchte nicht nur fertige Cloud-Produkte nutzen und auf ihr Verhalten vertrauen. Ich will solche Systeme gut genug verstehen, um eines selbst entwickeln und kontrollieren zu können. Ein vollständiger Assistent ist für mich ein guter Weg, lokale Inferenz, Agentenarchitektur, Retrieval, Routing und Berechtigungen gründlich zu lernen. Ich muss jede Entscheidung selbst treffen und dann mit ihr leben.

Der zweite Grund ist praktischer. Eine Menge kleiner, routinemäßiger KI-gestützter Arbeit wird derzeit zu einer Anfrage an ein entferntes Rechenzentrum. Ich bin nicht überzeugt, dass das für alles nötig ist. Ein Modell lokal laufen zu lassen ist ebenfalls nicht umsonst. Es verbraucht Strom, und die Hardware hat einen eigenen Fußabdruck. Das ist also nicht die Behauptung, lokale Inferenz sei ökologisch automatisch die bessere Wahl, und ich habe nichts gemessen, was mir eine solche Aussage erlauben würde. Mich interessiert eine konkretere Frage: Wie viel meiner täglichen Arbeit mit KI lässt sich sinnvoll lokal erledigen, sodass ich externe Modelle nur für Aufgaben brauche, die ihre zusätzliche Leistungsfähigkeit erfordern?

02

Lokal zuerst

Entscheidend ist die Reihenfolge: erst das lokale Modell, dann seine Tools. Ein externes Modell kommt nur hinzu, wenn beides nicht ausreicht.

Der Aufbau folgt einem Ablauf, nicht der Wahl einer einzelnen Komponente:

Ein kleines Modell wird dadurch nicht so leistungsfähig wie die größten Cloud-Modelle. Das ist auch nicht mein Ziel. Ich möchte es so in ein System einbinden, dass es für jede Aufgabe die passende Ressource nutzen kann. Dann hängt nicht mehr alles allein von der Modellgröße ab.

03

Werkzeuge statt Modellgröße

Ein Modell, das einen Taschenrechner aufrufen kann, muss nicht im Kopf rechnen können. Dieser Gedanke, überall angewendet, wo er trägt, ist der Kern des Projekts.

Die zentrale technische Frage dieses Projekts lautet: wie weit können gute Werkzeuge und ein guter Systementwurf die Grenzen eines kleineren Sprachmodells ausgleichen?

Ein großes Modell kann eine Frage beantworten, weil es mehr weiß. Ein gut aufgebautes System kann stattdessen die passende Informationsquelle oder das passende Werkzeug nutzen. Folgende Funktionen sind geplant; keine davon ist bisher umgesetzt:

• Berechnung Ein Rechnerwerkzeug, damit Arithmetik berechnet und nicht vorhergesagt wird
• Python Python-Ausführung für Datenverarbeitung, Analyse und Skriptarbeit
• Code Code ausführen und das Ergebnis nutzen, statt es zu raten
• Webrecherche Ein Web-Tool für aktuelle Informationen, die nicht im Wissensstand des Modells enthalten sind
• Dokumentsuche Retrieval über meine eigenen indexierten Projektdokumente
• Dateien Lokale Dateien lesen und, wo erlaubt, anlegen und ändern
• Desktop Interaktion mit ausgewählten Anwendungen, unter ausdrücklicher Erlaubnis

Wenn das System eine Zahl braucht, soll es sie berechnen. Wenn es die Information von heute braucht, soll es nachsehen. Wenn es etwas aus einem meiner Projekte braucht, soll es diese Datei holen. Zu einem größeren Modell zu greifen soll die letzte Option sein, nicht die erste.

04

Lokaler Kontext

Der Assistent soll meine Projekte verstehen können, ohne dass ich dafür die Dateien an einen externen Dienst senden muss.

Das meiste, was einen Assistenten für mich wirklich nützlich machen würde, liegt schon auf meinem Rechner: Projektordner, Code, Unimaterial, Notizen, Paper, technische Dokumente. Ein lokales System soll diese Unterlagen nutzen können, ohne sie dafür jeweils an einen externen Dienst zu senden.

Ich will nicht einfach das gesamte Dateisystem in den Modellkontext laden. Das funktioniert nicht und wird bei wachsenden Datenmengen erst recht unpraktikabel. Stattdessen soll das System gezielt auswählen:

Ob das am Ende lokale Suche, Embeddings oder eine andere Retrieval-Architektur wird, ist noch offen. Ich habe weder eine Variante ausgewählt noch eine umgesetzt.

05

Rechtebasierter Zugriff

Computerzugriff durch ein Modell bringt Sicherheitsrisiken mit sich. Die Zugriffsregeln möchte ich deshalb von Anfang an mitplanen.

Wenn der Assistent irgendwann Dateien lesen, Dateien schreiben, Code ausführen, ins Netz gehen und mit externen Diensten sprechen kann, dann ist ein Agent mit uneingeschränktem Systemzugriff der falsche Ansatz. Mich interessiert besonders, wie ich diesen Zugriff sinnvoll begrenzen kann, nicht nur, was der Assistent alles tun könnte.

Das Konzept, das ich erkunden will, trennt Berechtigungen nach Art, sodass ein Werkzeug genau das anfragen muss, was es braucht:

• Lesen Dateien, Dokumente und Systemzustand einsehen
• Schreiben Dateien anlegen oder ändern
• Ausführen Python, Shell-Befehle oder Anwendungen starten
• Netzwerk Das Web oder externe Dienste erreichen
• Externe KI Eine Anfrage an ein entferntes Modell senden

Riskantere Operationen sollen eine ausdrückliche Freigabe von mir verlangen können, bevor sie passieren, statt etwas zu sein, das ich hinterher in einem Log entdecke. Daten an ein externes Modell zu senden gilt als eigene Berechtigung, auf derselben Ebene wie das Ausführen von Code. Gemessen daran, was die Maschine verlässt, ist es das auch.

Das ist eine geplante Architektur. Nichts davon ist umgesetzt, und der Mechanismus zur Durchsetzung dieser Regeln ist noch nicht entwickelt.

06

Externe Modelle bei Bedarf

Externe Modelle sollen gezielt helfen, wenn das lokale System nicht weiterkommt. Sie sollen nicht unbemerkt die gesamte Arbeit übernehmen.

Manche Aufgaben werden ein kleines lokales Modell überfordern. Das zu ignorieren würde das System nur schlechter machen. Es soll also einen Ausweg geben: eine kontrollierte Anbindung, die eine Frage über eine API an ein stärkeres externes Modell stellen kann, etwa an Modelle von OpenAI, an Claude oder an Gemini.

Entscheidend ist, wann diese Anbindung genutzt wird. Der Assistent soll Aufgaben zuerst lokal mit seinen Tools bearbeiten. Wenn er nicht weiterkommt, soll er erkennen können, dass er die Unterstützung eines stärkeren Modells braucht. Mit dessen Antwort soll er lokal weiterarbeiten.

Eine Idee, die ich untersuchen will, ist, ob es sich bei einem wirklich schweren Problem lohnt, mehr als ein externes Modell zu befragen und die Antworten zu vergleichen. So könnte ich mehrere Einschätzungen vergleichen, statt mich auf eine einzige zu stützen. Das ist eine Idee, die ich untersuchen möchte, noch keine vorhandene Komponente.

Nichts von diesem Routing ist umgesetzt. Zu entscheiden, wann ein System zu dem Schluss kommen sollte, dass es feststeckt, ist vermutlich schwerer, als den API-Aufruf einzubinden.

07

Technische Fragen

Diese Fragen halte ich vor der Umsetzung fest. So kann ich die Ergebnisse später daran prüfen, statt die Fragen nachträglich anzupassen.

• Wie weit können gute Werkzeuge und ein guter Systementwurf die Grenzen eines kleineren Sprachmodells ausgleichen?
• Welche Aufgaben brauchen wirklich ein größeres entferntes Modell, und welche sehen nur so aus?
• Woran soll ein Agent merken, dass er feststeckt? Zu erkennen, wann externe Hilfe nötig ist, scheint schwieriger als die Anfrage selbst.
• Wie kann lokaler Datei- und Computerzugriff nützlich sein, ohne dem Agenten uneingeschränkte Kontrolle zu geben?
• Was sollte eine ausdrückliche Freigabe durch einen Menschen verlangen, und was würde so oft eine Freigabe verlangen, dass ich irgendwann ungelesen zustimme?
• Wie viel von meinem Projektkontext kann realistisch vollständig lokal bleiben?
• Was ist das praktische Gleichgewicht zwischen Leistungsfähigkeit des Modells, Latenz, Stromverbrauch und Hardwarekosten?
• Wann ergibt lokale Inferenz wirklich Sinn, und wann ist ein entferntes Modell einfach die bessere technische Entscheidung?

08

Aktueller Stand

So weit ist das Projekt im September 2026.

• Architekturrecherche und Planung laufen. Nichts ist umgesetzt.
• Die Werkzeugarchitektur wird definiert: welche Tools nötig sind, wie das Modell sie aufruft und worauf jedes zugreifen darf.
• Optionen für lokales Modell und Runtime werden untersucht. Weder Modell noch Quantisierung, Kontextlänge oder Runtime sind ausgewählt.
• Eigene Edge-Hardware wird erwogen, ist aber nicht gekauft. Ein NVIDIA Jetson Orin Nano ist eine mögliche Plattform; ebenso gut kann das System auf dem Rechner laufen, den ich schon habe.
• Umsetzung und Benchmarks stehen noch aus. Es gibt bisher keine Zahlen zu Latenz, Leistungsfähigkeit oder Stromverbrauch.

Ich aktualisiere diese Seite, während das Projekt vorankommt. Werte zu Latenz, Leistungsfähigkeit und Stromverbrauch ergänze ich, sobald es ein laufendes System gibt, das ich vermessen kann.