KI-Coding-Assistenten: welches Werkzeug wofür

Artikel-Übersicht

Programmieren mit Assistenz ist innerhalb weniger Jahre vom Experiment zum Alltag geworden, und die Werkzeuglandschaft ist unübersichtlich. Dieser Artikel unterscheidet zuerst drei Bauarten, die ständig in einen Topf geworfen werden: Autovervollständigung im Editor, Chat im Editor und agentische Werkzeuge, die selbst Dateien ändern und Befehle ausführen. Danach ein Vergleich mit einer Spalte, die in keinem anderen Vergleich steht — ob sich das Werkzeug mit einem lokalen Modell betreiben lässt. GitHub Copilot und Claude Code bekommen eigene Abschnitte inklusive Modellwechsel und Abrechnungsmodell. Ein Abschnitt beantwortet die Frage, ob sich Programmierenlernen noch lohnt. Der wichtigste behandelt, was sich an der Arbeit tatsächlich ändert. Zum Schluss Datenabfluss, Lizenzfragen und Mitbestimmung.

Was diese Werkzeuge tun

Ein Coding-Assistent schlägt Code vor, der zum Zusammenhang passt — er versteht das Vorhaben nicht, er setzt Muster fort.

Das ist keine Herabsetzung, sondern die Grundlage für alles Weitere: Ein Assistent kann nicht wissen, ob dein Entwurf sinnvoll ist. Er kann sehr gut fortsetzen, was üblich ist.

Drei Bauarten, die sich deutlich unterscheiden:

Autovervollständigung im Editor. Während du tippst, erscheint ein grauer Vorschlag. Reaktionsschnell, kleiner Kontext, geringes Risiko — man sieht jeden Vorschlag, bevor man ihn übernimmt. Welche Entwicklungsumgebung dabei welche Unterstützung mitbringt, steht in Java-IDEs im Vergleich.

Chat im Editor. Ein Dialogfenster mit Zugriff auf offene Dateien oder das Projekt. Gut für Erklärungen, größere Umformungen und Fragen zum Bestand.

Agentische Werkzeuge. Sie ändern Dateien selbstständig, führen Befehle aus, lesen Ergebnisse und arbeiten in mehreren Schritten auf ein Ziel hin. Der größte Nutzen und das größte Risiko liegen hier — deshalb gehört zu ihnen zwingend eine Bestätigungspflicht für wirksame Aktionen.

Die Werkzeuge im Vergleich

Werkzeug	Bauart	Modelle	IDE-Anbindung	Lokal möglich	Kostenlos nutzbar
GitHub Copilot	Vervollständigung, Chat, agentisch	mehrere zur Auswahl	VS Code, JetBrains, Neovim u. a.	nein	eingeschränkter Tarif
Claude Code	agentisch, Terminal	Anthropic-Modelle	über Erweiterungen	über Umwege	nein
Cursor	eigener Editor, alle drei Bauarten	mehrere zur Auswahl	eigener Editor (VS-Code-basiert)	teilweise	eingeschränkter Tarif
JetBrains AI	Vervollständigung, Chat	mehrere	JetBrains-Produkte	teilweise	eingeschränkter Tarif
Continue	Vervollständigung, Chat	frei wählbar	VS Code, JetBrains	ja, vollständig	ja, quelloffen
Aider	agentisch, Terminal	frei wählbar	keine, arbeitet auf dem Repository	ja, vollständig	ja, quelloffen
Codeium / Windsurf	Vervollständigung, Chat, agentisch	eigene und fremde	mehrere	teilweise	eingeschränkter Tarif

Stand 05/2027. Dieses Feld ändert sich monatlich — Funktionsumfang und Tarife vor einer Entscheidung prüfen.

Die Spalte „Lokal möglich" ist der Unterschied zu jedem anderen Vergleich. Für Umgebungen, in denen Quellcode das Haus nicht verlassen darf — Auftragsentwicklung mit Verschwiegenheitspflicht, regulierte Branchen, Behörden —, ist sie die einzige Spalte, die zählt. Die beiden quelloffenen Werkzeuge lassen sich vollständig gegen ein lokales Modell betreiben; wie man das aufsetzt, steht in Ollama: lokale Sprachmodelle betreiben.

GitHub Copilot

Das Werkzeug mit der größten Verbreitung und der breitesten IDE-Unterstützung.

Es deckt inzwischen alle drei Bauarten ab: Vervollständigung während des Tippens, Chat im Editor und einen agentischen Modus, der Aufgaben selbstständig bearbeitet. Die Einbindung in die Entwicklungsumgebungen ist die ausgereifteste im Feld.

Modelle und Abrechnung

Copilot lässt inzwischen die Wahl zwischen mehreren Modellen verschiedener Anbieter. Das ist praktisch relevant, weil sie sich unterscheiden — bei längeren Zusammenhängen deutlich.

Zum Abrechnungsmodell, ohne Preise, weil sie veralten: Die Nutzung wird über ein Kontingent an Anfragen abgerechnet, und verschiedene Modelle verbrauchen dieses Kontingent unterschiedlich schnell. Ein leistungsfähigeres Modell zählt mit einem höheren Faktor als das Standardmodell.

Praktisch heißt das: Wer immer das stärkste verfügbare Modell einstellt, verbraucht sein Kontingent um ein Vielfaches schneller — oft ohne Gegenwert, weil die meisten Anfragen im Alltag einfach sind. Die vernünftige Arbeitsweise ist, das Standardmodell zu nutzen und für schwierige Aufgaben bewusst umzuschalten.

Die aktuellen Faktoren stehen in der Herstellerdokumentation; sie ändern sich.

Claude Code

Ein agentisches Werkzeug, das im Terminal arbeitet statt in einer Entwicklungsumgebung. Es liest und ändert Dateien, führt Befehle aus, wertet die Ausgabe aus und arbeitet in mehreren Schritten.

Der Unterschied zu editorgebundenen Werkzeugen: Es sieht das Projekt als Ganzes und kann eine Aufgabe über mehrere Dateien hinweg bearbeiten. Der Preis ist, dass man ihm mehr zutraut — und deshalb die Bestätigungsnachfragen aktiv lassen sollte.

Das Modell wechseln

Eine Frage, die häufig gestellt und selten deutschsprachig beantwortet wird.

Der Wechsel geht über einen Befehl in der laufenden Sitzung:

/model

Damit lässt sich zwischen den verfügbaren Modellen umschalten. Dauerhaft setzen kann man das Modell über die Konfiguration oder eine Umgebungsvariable:

export ANTHROPIC_MODEL=<modellbezeichnung>

Wann sich der Wechsel lohnt: Ein schnelleres, kleineres Modell reicht für Routinearbeiten — Umbenennungen, Testgerüste, Formatanpassungen — und antwortet spürbar zügiger. Für Entwurfsfragen und schwierige Fehlersuche lohnt das stärkere.

Die genauen Modellbezeichnungen ändern sich; sie stehen in der Herstellerdokumentation.

Mit lokalen Modellen betreiben

Der Wunsch ist verbreitet, und die Nachfrage danach ist erheblich größer, als die Suchvolumina vermuten lassen. Die ehrliche Antwort in drei Punkten:

Technisch möglich ist es über die OpenAI-kompatible Schnittstelle eines lokalen Servers — dafür setzt man die Basis-URL auf den lokalen Endpunkt.

Die Hürde ist das Modell, nicht die Anbindung. Agentisches Arbeiten verlangt zuverlässige Werkzeugaufrufe über viele Schritte. Kleinere Modelle erfinden Parameter, liefern falsches Format oder laufen in Schleifen.

Die Faustregel: Unter etwa 14 Milliarden Parametern funktioniert es nicht verlässlich, und auch darüber braucht es ein Modell mit ausgewiesener Tool-Calling-Unterstützung. Für Codeergänzung und Erklärungen reichen lokale Modelle gut; für mehrschrittige agentische Arbeit auf einem Arbeitsplatzrechner noch nicht. Welche Modelle in Frage kommen, steht in Welches Ollama-Modell?.

Mit KI programmieren lernen

Hinter der Frage „lohnt sich Programmierenlernen noch?" steckt eine echte Sorge, und sie verdient eine ehrliche Antwort.

Ja, es lohnt sich weiterhin — weil Prüfen schwerer ist als Schreiben.

Ein Assistent erzeugt in Sekunden Code, der plausibel aussieht. Ob er richtig ist, ob er die Randfälle abdeckt, ob er zum Rest des Systems passt, ob er ein Sicherheitsproblem enthält — das muss jemand beurteilen. Und beurteilen kann nur, wer es selbst könnte.

Aus der Ausbildungspraxis kommt eine Beobachtung dazu: Man merkt sehr deutlich, wenn jemand einen Vorschlag übernommen hat, den er nicht versteht. Nicht am Code selbst, sondern an der Reaktion auf Rückfragen. „Warum steht hier if statt while?" ist eine Frage, die sofort zeigt, ob jemand nur eingefügt oder auch gelesen hat.

Was sich für Lernende praktisch geändert hat:

• Der Einstieg ist leichter geworden. Ein Assistent erklärt Fehlermeldungen geduldiger als jedes Forum.
• Die Gefahr ist größer geworden, Verstehen durch Übernehmen zu ersetzen — und das fällt erst später auf.
• Prüfen muss ausdrücklich gelernt werden. Es war früher ein Nebenprodukt des Schreibens, heute ist es eine eigene Fähigkeit.

Der Rat, den ich Auszubildenden gebe: In den ersten Monaten den Assistenten zum Erklären benutzen, nicht zum Schreiben. Frag ihn, was dein Code tut, nicht, wie man ihn schreibt. Die Reihenfolge macht den Unterschied.

Was sich an der Arbeit ändert

Der Abschnitt, der den Artikel trägt.

Der Engpass verschiebt sich vom Schreiben zum Prüfen. Das ist die eine Aussage, aus der alles Weitere folgt.

Fünf konkrete Auswirkungen:

Codereviews werden länger und wichtiger. Wenn mehr Code entsteht, muss mehr geprüft werden — und der Code ist nicht mehr automatisch von jemandem geschrieben, der ihn versteht.

Die Versuchung, Unverstandenes zu übernehmen. Ein Vorschlag, der funktioniert, wird selten hinterfragt. Er kann trotzdem eine Randbedingung verletzen, die erst in sechs Monaten auffällt.

Wissenslücken werden später sichtbar. Früher scheiterte man an einer Stelle, die man nicht verstand. Heute kommt man daran vorbei — und merkt es erst, wenn etwas nicht funktioniert.

Tests werden wichtiger, nicht unwichtiger. Sie sind das einzige Mittel, das mit der Geschwindigkeit mithält. Ein Testsatz prüft in Sekunden, was ein Mensch in Minuten liest.

Technische Schulden entstehen schneller. Mehr Code in derselben Zeit bedeutet auch: mehr Struktur, die niemand bewusst entworfen hat. Wer die Prüfzeit nicht einplant, nimmt Schulden in einem Tempo auf, das vorher nicht möglich war — wie man sie sichtbar macht, steht in Technische Schulden und Refactoring.

Und die Konsequenz für die Planung: Wenn das Schreiben doppelt so schnell geht, wird das Vorhaben nicht doppelt so schnell fertig. Prüfen, Abstimmen, Verstehen und Betreiben bleiben, was sie waren.

Wo sie zuverlässig gut sind — und wo nicht

Aufgabe	Eignung	Anmerkung
Testgerüste erzeugen	sehr gut	wiederkehrende Struktur, leicht prüfbar
Boilerplate und Zuordnungen	sehr gut	mechanisch, fehleranfällig für Menschen
Umformungen und Umbenennungen	gut	Umfang begrenzt halten
Sprachwechsel	gut	Idiome der Zielsprache prüfen
Fehlermeldungen erklären	sehr gut	oft schneller als Suchmaschinen
Fremden Code erschließen	gut	„was tut das" ja, „warum" nein
Entwurfsentscheidungen	schlecht	fehlender Zusammenhang, keine Abwägung
Unbekannte Fachlichkeit	schlecht	die Sonderfälle stehen nirgends
Subtile Nebenläufigkeit	schlecht	plausibel aussehender, falscher Code
Bibliotheks-Schnittstellen	Vorsicht	erfindet Methoden, die es nicht gibt

Die letzte Zeile verdient eine Warnung: Erfundene Schnittstellen sind die häufigste Fehlerquelle im Alltag. Ein Modell schlägt eine Methode vor, die es in der Bibliothek nicht gibt — der Code sieht richtig aus und übersetzt nicht. Ärgerlich, aber harmlos. Gefährlicher ist der Fall, in dem eine Methode existiert, aber anders funktioniert als angenommen.

Datenabfluss, Lizenzen und Mitbestimmung

Drei Punkte, die vor dem betrieblichen Einsatz geklärt gehören.

Was an den Anbieter geht. Je nach Werkzeug: der Code im Kontext, offene Dateien, Projektstruktur, teils Repository-Inhalte. Bei agentischen Werkzeugen zusätzlich Befehlsausgaben, die Zugangsdaten enthalten können. Ob diese Daten zum Training verwendet werden, unterscheidet sich je Anbieter und Tarif — in Geschäftstarifen ist die Nichtnutzung meist zugesichert, in kostenlosen Tarifen häufig nicht.

Die Lizenzfrage bei generiertem Code ist nicht abschließend geklärt. Die Modelle wurden auf öffentlichem Code trainiert, der unter verschiedenen Lizenzen steht. Ob und wann ein erzeugter Ausschnitt urheberrechtlich problematisch ist, ist Gegenstand laufender Verfahren. Einige Anbieter bieten Filter gegen wörtliche Übernahmen und teils Freistellungszusagen an. Das ist eine offene Frage, keine gelöste — mehr dazu in KI, Datenschutz und Recht.

Mitbestimmung. Der Punkt, der im DACH-Raum regelmäßig übersehen wird: Werkzeuge, die laufend Eingaben an einen Anbieter senden, sind in Deutschland und Österreich in aller Regel mitbestimmungspflichtig, weil sie zur Verhaltens- und Leistungskontrolle geeignet sind. Eine Betriebsvereinbarung ist keine Formalie, sondern die Voraussetzung für den Einsatz. In der Schweiz gilt anderes, aber auch dort ist die Einbindung der Belegschaft ratsam.

Die technische Absicherung — Prompt Injection über Rückgabewerte, Rechte agentischer Werkzeuge — behandle ich in KI-Sicherheit: Prompt Injection und Datenabfluss.

Häufige Fragen

Welche KI für Coding? Für längere Zusammenhänge über mehrere Dateien Claude, für breiteste IDE-Unterstützung Copilot, für vollständig lokalen Betrieb Continue oder Aider mit einem lokalen Modell.

Welche KI für Coding ist kostenlos? Continue und Aider sind quelloffen und mit lokalen Modellen kostenfrei nutzbar. Die kommerziellen Werkzeuge haben eingeschränkte Tarife — dort ist zu prüfen, ob Eingaben zum Training verwendet werden.

Wie kann man mit KI programmieren? Über drei Bauarten: Autovervollständigung im Editor, Chat im Editor und agentische Werkzeuge, die selbst Dateien ändern. Für den Einstieg ist die erste die risikoärmste.

Kann ChatGPT gut programmieren? Für abgegrenzte Aufgaben ja. Bei Entwurfsentscheidungen, unbekannter Fachlichkeit und subtiler Nebenläufigkeit ist die Zuverlässigkeit gering — dort entsteht plausibel aussehender, falscher Code.

Kann KI sich selbst programmieren? Modelle erzeugen Code, auch für KI-Systeme. Von eigenständiger Weiterentwicklung ohne menschliche Zielsetzung und Prüfung ist das weit entfernt.

Wie wechselt man das Modell in Claude Code? Über den Befehl /model in der laufenden Sitzung oder dauerhaft über die Konfiguration beziehungsweise eine Umgebungsvariable.

Lohnt es sich noch, programmieren zu lernen? Ja. Prüfen ist schwerer als Schreiben, und prüfen kann nur, wer es selbst könnte.

Zusammenfassung und praktische Tipps

Die Werkzeuge sind nützlich, und sie verschieben die Arbeit, statt sie zu ersparen. Die wichtigsten Punkte:

• Drei Bauarten mit sehr unterschiedlichem Risiko. Agentische Werkzeuge brauchen Bestätigungsnachfragen.
• Nur zwei Werkzeuge im Vergleich laufen vollständig lokal — für Umgebungen mit Verschwiegenheitspflicht ist das die einzige Option.
• Modellwahl kostet Kontingent. Immer das stärkste Modell einzustellen verbraucht es um ein Vielfaches, meist ohne Gegenwert.
• Der Engpass verschiebt sich vom Schreiben zum Prüfen — und Prüfzeit gehört eingeplant.
• Erfundene Bibliotheksschnittstellen sind die häufigste Fehlerquelle.
• Programmierenlernen lohnt weiterhin, weil Prüfen die schwerere Fähigkeit ist.
• Mitbestimmung ist im DACH-Raum Voraussetzung, keine Formalie.

Mein Rat für den Einstieg: Nutze eine Woche lang ausschließlich die Erklärfunktion — lass dir deinen eigenen Code erklären, statt neuen erzeugen zu lassen. Du siehst dabei sehr schnell, wo das Werkzeug gut ist und wo es überzeugend danebenliegt. Diese Kalibrierung ist mehr wert als jede Funktionsliste, und sie ist die Grundlage dafür, den Vorschlägen später angemessen zu misstrauen.

Ressourcen

• GitHub Copilot – Dokumentation – Funktionsumfang, Modellwahl und Abrechnung
• Claude Code – Dokumentation – Befehle, Konfiguration und Modellwechsel
• Continue – quelloffene Erweiterung mit frei wählbarem Modell
• Aider – agentisches Werkzeug im Terminal, quelloffen