Coding-Assistant lokal betreiben: Quellcode bleibt im Haus

Ein Coding-Assistant sieht mehr von einem Unternehmen als fast jedes andere Werkzeug. Er liest den Quellcode, die Kommentare, die Konfigurationsdateien, manchmal Zugangsdaten, die versehentlich im Repository liegen. Wer diesen Assistenten in der Cloud betreibt, schickt genau das an einen Dritten. Für viele Teams ist das der Punkt, an dem sie zögern.

Die gute Nachricht: der Assistent muss den Code nicht mehr aus dem Haus lassen. Vorige Woche haben wir beschrieben, wie man mit vLLM oder Ollama eine lokale KI für viele gleichzeitige Nutzer aufstellt. Das war die Serverseite. Diesmal geht es um einen konkreten Anwendungsfall darauf, das Programmieren, und um die Frage, ob ein lokal betriebener Assistent im Alltag wirklich reicht. Neu in diesem Sommer ist vor allem, dass die offenen Coder-Modelle einen Sprung gemacht haben und die Werkzeuge drumherum stabil geworden sind.

Warum Quellcode ein Sonderfall ist

Bei einem Chatbot für den Kundendienst kann man diskutieren, wie heikel die Eingaben sind. Bei Quellcode ist die Sache klarer. Er ist oft das Kernvermögen des Unternehmens, er enthält Geschäftslogik, und in vielen Verträgen mit Kunden steht schwarz auf weiß, dass er nicht an Dritte gehen darf. Eine Kanzlei, ein Zahlungsdienstleister oder ein Zulieferer mit fremdem Konstruktionswissen kann sich das schlicht nicht leisten.

Dazu kommt der Datenschutz. In Testdaten, Fehlermeldungen und Kommentaren stecken oft echte personenbezogene Daten. Landen sie bei einem Anbieter außerhalb der EU, ist die Übermittlung ein eigener Sachverhalt, den man begründen müsste. Ein lokal laufendes Modell umgeht diese Frage, weil die Inhalte den Rechner nie verlassen.

Was heute lokal läuft

Der Aufbau besteht aus zwei Teilen: einem Modell und einem Werkzeug, das es in die Arbeit einbindet.

Als Modell hat sich für Code eine Familie durchgesetzt. Qwen3-Coder-Next, ein offenes Modell des Qwen-Teams von Alibaba, arbeitet nach den veröffentlichten Angaben mit rund 80 Milliarden Parametern, von denen je Token nur etwa 3 Milliarden aktiv sind. Diese Bauweise sorgt dafür, dass das Modell auf eine einzelne Workstation passt und trotzdem laut Berichten nahe an die deutlich größere Variante mit 480 Milliarden Parametern herankommt. Wer weniger Hardware hat, greift zu kleineren Coder-Modellen mit 7 bis 32 Milliarden Parametern.

Als Werkzeug gibt es mehrere Wege, je nach Arbeitsstil:

• Ollama als lokaler Modellserver mit einer OpenAI-kompatiblen Schnittstelle. Das Modell liegt dann als Dienst bereit, ein Aufruf wie aider --model ollama/qwen2.5-coder:32b genügt für einen vollständig lokalen Terminal-Agenten.
• Continue als Erweiterung im Editor. Sie zeigt auf einen beliebigen OpenAI-kompatiblen Server, lokal oder eigen gehostet, und bringt Vervollständigung und Chat direkt in VS Code oder eine JetBrains-Umgebung.
• Tabby als eigener, selbst gehosteter Assistent-Server. Er indexiert das Repository, läuft in VS Code, JetBrains und Vim und bringt Adminrechte mit, was ihn für Teams interessant macht.

Alle drei brauchen keine Cloud, wenn man sie rein lokal betreibt. Die Wahl hängt davon ab, ob Sie lieber im Terminal, im Editor oder mit einem zentralen Server fürs ganze Team arbeiten.

Wie gut ist das wirklich

Ehrlich gesagt: für den täglichen Kleinkram sehr gut, für die ganz großen Aufgaben noch nicht ganz auf Cloud-Niveau, aber der Abstand schrumpft.

Autovervollständigung, das Erklären von fremdem Code, das Schreiben von Tests, kleinere Refactorings, dafür reichen die offenen Coder-Modelle nach Community-Berichten heute aus. Bei den großen agentischen Aufgaben, also einer Änderung, die sich über viele Dateien zieht und mehrere Schritte selbstständig plant, liegen die größten Cloud-Modelle noch etwas vorn. Als Anhaltspunkt nennt die Community für Qwen3-Coder-Next rund 70 Prozent auf dem Prüfstand SWE-Bench Verified, eine Zahl, die man als Richtwert und nicht als Garantie lesen sollte.

Zur Geschwindigkeit: ein kleines Modell mit 7 Milliarden Parametern läuft laut Community-Messungen selbst auf einer reinen CPU mit 8 Gigabyte Arbeitsspeicher, dort mit etwa 10 bis 15 Token je Sekunde. Das ist genug für Vervollständigung, aber zäh für längere Antworten. Mit einer Grafikkarte oder Apple Silicon mit viel Unified Memory wird es flüssig.

Die Falle mit dem Wort lokal

Hier lohnt Genauigkeit, denn lokal ist nicht automatisch privat. Mehrere der genannten Werkzeuge haben inzwischen optionale, teils kostenpflichtige Cloud-Stufen eingeführt. Bei diesen laufen einzelne Funktionen doch über die Server des Anbieters, obwohl das Werkzeug als lokales Werkzeug bekannt ist.

Praktisch heißt das: Nicht die Marke entscheidet über die Vertraulichkeit, sondern die konkret aktivierte Funktion. Ein Modell, das auf Ihrem Rechner liegt, kann privat sein, während eine Zusatzfunktion desselben Programms Ihre Anfrage nach außen schickt. Bevor Sie einem Setup vertrauliche Repositories anvertrauen, prüfen Sie für jede aktive Funktion, ob sie lokal rechnet. Ein einfacher Test hilft: Netzwerk trennen und schauen, was noch funktioniert. Was offline weiterläuft, rechnet lokal.

Für wen sich das lohnt

Am klarsten für Teams, deren Code vertraglich oder rechtlich nicht nach außen darf, also im Finanzbereich, bei kritischer Infrastruktur, in Kanzleien und überall dort, wo fremdes Betriebswissen im Repository steckt. Für sie ist der lokale Assistent kein Verzicht, sondern die einzige Variante, die die Vertraulichkeit gar nicht erst aufs Spiel setzt.

Der Einstieg ist kleiner, als er klingt. Ein Modell, ein Werkzeug, eine Workstation, und ein abgegrenztes Repository als erster Testfall. So sehen Sie in ein paar Tagen, ob Qualität und Tempo für Ihre Arbeit reichen, ohne dass ein einziger Codeschnipsel das Haus verlässt. Wie eine lokale Aufstellung mit Blick auf Datenhoheit aussieht, haben wir unter Datenhoheit beschrieben.

Sie wollen wissen, ob ein lokaler Coding-Assistant für Ihr Team taugt? In einem Pilotprojekt richten wir Modell, Werkzeug und Datenfluss an einem echten Repository ein und messen Qualität und Tempo, bevor Sie sich festlegen.