Warum lokale KI-Code-Assistenten für sensible Projekte immer wichtiger werden

Die Episode war kurz, aber folgenreich: Als der KI-Code-Assistent Claude Code diese Woche in China blockiert wurde, erinnerte das viele Teams plötzlich daran, wie abhängig sie bereits von cloudbasierten KI-Tools geworden sind. Gleichzeitig veröffentlichte die chinesische Regierung eine Warnung vor Datenschutzrisiken durch KI-Coding-Assistenten. Beide Ereignisse lenkten die Aufmerksamkeit auf eine Frage, die in der Euphorie der Effizienzgewinne oft untergegangen war: Wohin fließen eigentlich die Daten, wenn KI-Tools den Code lesen und verarbeiten?

Von Autocomplete zu vollständigen Entwicklungsworkflows

KI-gestützte Code-Assistenten haben sich in den letzten Jahren rasant weiterentwickelt. Was einst mit simplen Autocomplete-Funktionen begann, ist heute ein zentrales Werkzeug für komplexe Aufgaben wie Testautomatisierung, Code-Reviews, Log-Analysen oder sogar architektonische Entscheidungsfindungen. Die Produktivitätssteigerungen sind unbestreitbar – doch der Preis dafür ist eine tiefe Integration in die Arbeitsumgebungen der Entwickler.

Wenn ein Tool wie Cursor, GitHub Copilot oder Claude Code Zugriff auf ein Verzeichnis erhält, beschränkt sich das nicht auf die gerade geöffnete Datei. Stattdessen wird das gesamte Repository indiziert, Konfigurationsdateien wie package.json oder requirements.txt werden analysiert, die .git-Historie wird ausgelesen und ein vollständiges Abbild der Modulabhängigkeiten erstellt. All das ist notwendig, um präzise Code-Vorschläge zu generieren. Doch in denselben Verzeichnissen liegen auch sensible Dateien: .env-Dateien mit Datenbankzugangsdaten, API-Schlüssel oder Deployment-Konfigurationen für Produktionsumgebungen.

Die meisten Tools schließen diese Dateien nicht automatisch aus – es sei denn, der Nutzer konfiguriert dies explizit. Die indizierten Daten und der Code-Kontext werden anschließend an Cloud-Server zur Verarbeitung übertragen. Cursor räumt das in seiner Datenschutzerklärung offen ein: Nutzer können die Datenerfassung zwar deaktivieren, verlieren dann aber Teile der Funktionalität. GitHub Copilot leitet den Kontext über die Server von GitHub und OpenAI weiter. Beide Anbieter betonen in ihren Nutzungsbedingungen, dass privater Code nicht für das Training eigener Modelle verwendet wird – doch die Übertragung findet trotzdem statt.

Der Fall Claude Code und die unterschätzte Abhängigkeit

Die Sperrung von Claude Code in China löste eine stärkere Reaktion aus, als viele erwartet hätten. Der Grund dafür lag weniger in der Unverfügbarkeit eines einzelnen Tools, sondern in der tiefen Abhängigkeit vieler Teams von solchen KI-Assistenten. Wie sich zeigte, nutzten zahlreiche Entwicklerteams den Dienst nicht nur für Autocomplete, sondern für komplexe Aufgaben wie Code-Reviews, Testgenerierung, Debugging und sogar architektonische Diskussionen. Als der Dienst nicht mehr verfügbar war, kamen ganze Workflows zum Erliegen.

In der Folge begannen viele Teams sofort mit der Evaluierung von Alternativen. Die Optionen reichten von lokalen Open-Source-Modellen über selbstgehostete KI-Dienste bis hin zu vollständig lokaler Inferenz. Einmalige Ausfälle haben offenbar Prioritäten verschoben: Die Sorge vor Vendor-Lock-in ist bei vielen Entwicklern plötzlich in den Vordergrund gerückt.

Datenhoheit vs. Produktivität: Wo liegt die Grenze?

Für Unternehmen, die an nicht-sensiblen Projekten arbeiten – etwa in der Webentwicklung oder bei Open-Source-Projekten – ist der Kompromiss zwischen Produktivität und Datenschutz oft einfach zu rechtfertigen. Doch in regulierten Branchen wie Finanzwesen, Gesundheitswesen, öffentlicher Verwaltung oder Industrie gelten andere Maßstäbe. Hier stehen grenzüberschreitende Datentransfers, Auditierbarkeit, Zugriffskontrollen und Compliance-Anforderungen im Vordergrund. Für solche Teams ist die Frage, wohin der Code fließt, nicht verhandelbar – selbst wenn das zu Lasten der Modellleistung geht.

Genau hier setzt der aktuelle Trend zur lokalen Inferenz an. Noch vor wenigen Jahren galten lokale Modelle als zu langsam und leistungsschwach für den produktiven Einsatz. Doch diese Einschätzung hat sich grundlegend gewandelt.

Lokale KI auf dem Mac: Ein Praxisbeispiel

Das Team hinter Mano-P, einem lokalen KI-Assistenten für Entwickler, hat diese Entwicklung am eigenen Leib erfahren. Ihr Ansatz setzt auf ein 4-Milliarden-Parameter-Modell namens Mano-CUA-Thinking, das speziell für Apple Silicon optimiert wurde. Trainiert wurde es mit dem MLX-Framework, kombiniert mit einer eigenen Quantisierungs-Bibliothek namens Cider.

Die Skepsis im Team war anfangs groß. Könnte ein so kleines Modell wirklich mehr als nur Demo-Aufgaben bewältigen? Die Praxis zeigt: Auf einem M5 Pro läuft das Modell mit etwa 80 Token pro Sekunde und einer Prefill-Zeit von unter 3 Sekunden. Die Latenz ist damit so nah an Cloud-APIs, dass der Unterschied im Alltag kaum spürbar ist. Noch wichtiger: Alle Verarbeitungsschritte – von der Bildschirmaufnahme über die Aufgabenbeschreibung bis hin zur Inferenz – finden lokal statt. Keine Daten verlassen das Gerät. Für Teams, die mit internen Systemen, Produktionsumgebungen oder sensiblen Codebasen arbeiten, ist diese Eigenschaft oft entscheidender als die reine Modellleistung.

In einem Test mit 100 realen macOS-GUI-Aufgaben erreichte das lokale 4B-Modell eine Erfolgsquote von 56 % – deutlich vor dem cloudbasierten Qwen3-VL-Plus (39 %) im gleichen Setup. Dass ein kleineres, spezialisiertes Modell hier besser abschneidet, ist auf den ersten Blick überraschend, aber bei genauerem Hinsehen logisch: Spezialisierung schlägt Generalisierung, wenn es um domänenspezifische Aufgaben geht.

Cider: Die unsichtbare Beschleunigung lokaler KI

Die Quantisierungs-Bibliothek Cider spielt dabei eine entscheidende Rolle. Sie ermöglicht INT8-Inferenz auf dem MLX-Framework und beschleunigt die W8A8-Prefill-Phase auf dem M5 Pro um bis zu 1,8x gegenüber W8A16. Ursprünglich als internes Beschleunigungsmodul für Mano-P entwickelt, wurde Cider später als eigenständiges Open-Source-Projekt veröffentlicht – weil viele Entwickler genau nach solchen Tools suchten. Mittlerweile hat das Projekt auf GitHub über 300 Sterne gesammelt, eine Zahl, die die Nachfrage nach lokalen Inferenz-Tools eindrucksvoll unterstreicht.

Der neue Standard: Lokale Inferenz als Ergänzung – nicht als Ersatz

Es wäre ein Fehler zu glauben, dass lokale Modelle cloudbasierte Dienste vollständig ersetzen werden. Cloud-Modelle bleiben in Bereichen wie mehrsprachiger Code-Generierung, komplexen logischen Problemen oder allgemeiner Programmierung weiterhin überlegen. Ihr Einsatzgebiet sind idealerweise nicht-sensible Projekte, Lernumgebungen oder Open-Source-Entwicklung.

Doch der Wandel ist bereits im Gange: Für Code, der das Gebäude nicht verlassen darf – sei es wegen geistigen Eigentums, Compliance-Anforderungen oder Sicherheitsbedenken – wird lokale Inferenz zunehmend zur realistischen Alternative und nicht mehr nur zum Kompromiss. Die Diskussion um KI-Code-Assistenten hat sich verschoben: Sie dreht sich nicht mehr nur um die Frage, welches Modell das intelligenteste oder schnellste ist, sondern darum, wer die Kontrolle über den Code behält – denn das entscheidet letztlich darüber, ob ein Modell überhaupt produktiv eingesetzt werden kann.

Mano-P steht unter der Apache-2.0-Lizenz zur Verfügung. Das 4B-Modell, die Cider-Bibliothek und der autonome Builder Mano-AFK können unter github.com/Mininglamp-AI/Mano-P heruntergeladen werden. Die Installation auf einem Mac mit M4+ und 32 GB RAM erfolgt über:

brew install mano-cua

Anschließend lässt sich der Assistent mit dem Flag --local vollständig offline nutzen.