Drei Merkmale unterscheiden gutes KI-Pair-Programming von bloßer Werkzeugnutzung:
Pair Programming wurde vor allem durch Extreme Programming bekannt. Zwei Personen arbeiten an einem Rechner: Die eine Person, der Driver, schreibt den Code, die andere, der Navigator, denkt voraus, achtet auf Struktur, entdeckt Fehler und stellt Fragen. Die Rollen wechseln regelmäßig. Der Nutzen liegt weniger in der Geschwindigkeit als in der Qualität, im Wissenstransfer und darin, dass Entscheidungen laut ausgesprochen und damit überprüfbar werden.
Ein KI-Assistent kann beide Rollen einnehmen, allerdings mit Einschränkungen. Als Driver schreibt er schnell und unermüdlich, kennt viele Bibliotheken und Muster und produziert in Sekunden, wofür ein Mensch Minuten bräuchte. Als Navigator kann er Fragen stellen, Alternativen aufzeigen und auf Fehler hinweisen. Was ihm fehlt, ist das Verständnis für das Unternehmen, die Fachdomäne, die Geschichte des Systems und die unausgesprochenen Erwartungen der Kunden. Er stellt selten die Frage, ob eine Aufgabe überhaupt sinnvoll ist. Und er widerspricht zu selten, wenn der Mensch einen schlechten Plan vorgibt. Ein menschlicher Partner würde sagen: „Lass uns das anders machen.“ Ein KI-Assistent setzt die Anweisung meist einfach um.
In der Praxis haben sich zwei Grundkonstellationen herausgebildet. Im ersten Fall bleibt der Mensch Driver: Er schreibt den Code selbst, nutzt Autovervollständigung für Routinezeilen und fragt im Chat nach, wenn er unsicher ist. Die KI ist hier ein schneller, gut informierter Navigator, der Vorschläge macht, aber nichts ohne Zustimmung verändert. Diese Konstellation eignet sich für Kernlogik, sicherheitskritische Stellen und Code, den man in der Tiefe verstehen muss.
Im zweiten Fall wird die KI zum Driver: Der Mensch beschreibt eine Aufgabe, die KI setzt sie um, und der Mensch übernimmt die Rolle des Navigators, der plant, prüft, korrigiert und abnimmt. Mit agentischen Werkzeugen ist diese Konstellation alltäglich geworden. Sie spart viel Schreibarbeit, verlagert die Anstrengung aber auf das Lesen und Bewerten. Und Lesen ist anstrengender, als es klingt. Wer fremden Code nur überfliegt, übersieht Fehler, die er beim Selbstschreiben nie gemacht hätte. Gutes KI-Pair-Programming bedeutet deshalb, bewusst zwischen beiden Konstellationen zu wechseln, je nachdem, wie kritisch und wie gut verstanden die Aufgabe ist.
Abzugrenzen ist KI-Pair-Programming vom sogenannten Vibe Coding, bei dem man der KI weitgehend freie Hand lässt, den erzeugten Code kaum liest und sich am sichtbaren Ergebnis orientiert. Für Prototypen, Wegwerfskripte und Experimente kann das legitim sein. Für Software, die im Unternehmen produktiv läuft, gewartet werden muss und mit Kundendaten arbeitet, ist es keine tragfähige Arbeitsweise. KI-Pair-Programming ist auch kein Ersatz für Code-Review durch Kolleginnen und Kollegen. Die KI ist ein zusätzlicher Partner im Entstehungsprozess, nicht die Instanz, die am Ende freigibt. Und schließlich ist es kein Weg, fehlende Grundkenntnisse dauerhaft zu überspringen. Wer nicht beurteilen kann, ob ein Vorschlag richtig ist, hat keinen Partner, sondern eine Blackbox.
IDE-Erweiterungen legen eine Zusammenarbeit nahe, in der der Mensch Driver bleibt. Die KI sitzt am Rand des gewohnten Arbeitsplatzes, schlägt vor und antwortet, und wer will, kann einen Agentenmodus zuschalten. Für Teams, die ihre Werkzeuge nicht wechseln wollen oder in spezialisierten Umgebungen arbeiten, ist das oft der pragmatischste Einstieg. KI-native Editoren gehen einen Schritt weiter. Sie behandeln die KI als festen Bestandteil des Editors, zeigen Mehrdatei-Änderungen als zusammenhängende Diffs, verwalten Kontext automatisch und machen den Wechsel zwischen Chat und Agent fließend. Das fördert eine Arbeitsweise, in der die KI häufiger schreibt und der Mensch häufiger navigiert.
Terminal-Agenten verschieben den Schwerpunkt noch deutlicher. Hier gibt der Mensch eine Aufgabe in natürlicher Sprache vor, der Agent erkundet das Repository, plant, ändert Dateien, führt Tests und Build aus und berichtet. Der Editor wird zum Ort, an dem man die Ergebnisse liest. Diese Klasse eignet sich besonders für umfangreichere, gut beschriebene Aufgaben und für Automatisierung, verlangt aber eine klare Rechteverwaltung, weil der Agent Befehle auf dem Rechner ausführt. Offene und selbst betriebene Lösungen schließlich sind weniger eine eigene Arbeitsweise als eine Antwort auf die Frage, wo der Code verarbeitet wird. Sie können jede der drei anderen Arbeitsweisen abbilden, aber mit einem Modell, das das Unternehmen selbst wählt und kontrolliert.
Funktionslisten gleichen sich in diesem Markt schnell an, weil fast jeder Anbieter innerhalb weniger Monate nachzieht, was ein anderer vorgemacht hat. Für die Wahl der Werkzeugklasse sind deshalb andere Fragen aussagekräftiger. Wie viel Umstellung ist das Team bereit zu tragen? Welche Sprachen, Frameworks und Entwicklungsumgebungen sind gesetzt, etwa bei Embedded-Entwicklung, SPS-nahen Projekten oder Branchenlösungen mit eigener Toolchain? Wo darf der Code verarbeitet werden, und welche Repositorys sind besonders schutzbedürftig? Wie wichtig ist die freie Wahl des Sprachmodells, um nicht von einem Anbieter abhängig zu werden? Und wie gut lässt sich das Werkzeug zentral verwalten, also Lizenzen zuweisen, Funktionen freigeben oder sperren und Nutzung protokollieren? Wer diese Fragen beantwortet hat, kann die Auswahl meist auf zwei oder drei Kandidaten eingrenzen, die dann im Pilot gegeneinander antreten.
Die Autovervollständigung ist der älteste und zugleich unauffälligste Modus. Während man tippt, schlägt die KI die Fortsetzung vor, oft eine ganze Zeile, manchmal eine komplette Funktion. Ein Tastendruck übernimmt den Vorschlag, Weitertippen verwirft ihn. Der Mensch bleibt eindeutig Driver, die KI liest mit und rät, was als Nächstes kommt. Moderne Varianten sagen nicht nur die nächste Zeile voraus, sondern auch die nächste Bearbeitungsstelle, etwa wenn eine Umbenennung an mehreren Stellen nachgezogen werden muss.
Die Stärke dieses Modus liegt bei Routinearbeit: Datenklassen, Mapping zwischen Strukturen, wiederkehrende Fehlerbehandlung, Testgerüste, Konfigurationsdateien. Seine Schwäche ist die Beiläufigkeit. Weil Vorschläge so schnell übernommen werden, entsteht leicht eine Gewohnheit, sie nur noch zu überfliegen. Gerade bei Grenzwerten, Vorzeichen, Indexrechnungen oder Zeitzonen schleichen sich so Fehler ein, die beim Selbstschreiben aufgefallen wären. Eine bewährte Regel lautet deshalb: Vorschläge, die länger als ein paar Zeilen sind, werden gelesen, als hätte sie ein Kollege eingereicht.
Der Chat ist der Modus, der dem klassischen Navigator am nächsten kommt. Er eignet sich hervorragend, um laut zu denken: Man beschreibt, was man vorhat, und lässt sich Einwände, Randfälle und Alternativen nennen. Besonders wertvoll ist er beim Einarbeiten in fremden oder alten Code, bei der Fehlersuche und beim Lernen neuer Bibliotheken. Seine Grenze liegt im Kontext: Was die KI nicht sieht, kann sie nicht berücksichtigen. Wer im Chat gute Antworten will, muss gezielt die relevanten Dateien, Schnittstellen und Anforderungen mitgeben, statt auf eine pauschale Frage eine pauschale Antwort zu erhalten.
Im Agentenmodus erhält die KI eine Aufgabe und arbeitet sie in mehreren Schritten selbstständig ab. Sie durchsucht das Repository, plant die Änderungen, bearbeitet mehrere Dateien, führt Befehle wie Tests, Linter oder Build aus, liest die Ergebnisse und korrigiert sich. Am Ende steht ein Diff oder ein Pull Request, den der Mensch prüft. Je nach Werkzeug lässt sich einstellen, ob jeder Schritt einzeln bestätigt werden muss oder ob der Agent innerhalb definierter Grenzen frei arbeitet. Über Standardschnittstellen wie das Model Context Protocol können Agenten zudem externe Werkzeuge nutzen, etwa ein Ticketsystem, eine Dokumentation oder eine Datenbank.
Agenten sind mächtig, aber sie verändern die Rolle des Menschen grundlegend. Statt viele kleine Entscheidungen während des Schreibens zu treffen, trifft man wenige große: bei der Aufgabenbeschreibung und bei der Abnahme. Fehler in der Beschreibung pflanzen sich durch die gesamte Umsetzung fort, und die Abnahme eines großen Diffs ist anspruchsvoll. Deshalb gilt für den Agentenmodus mehr als für jeden anderen: kleine, klar abgegrenzte Aufgaben, ein Plan vor der Umsetzung, Tests als Abnahmekriterium und knapp bemessene Rechte. Ein Agent, der Befehle ohne Rückfrage ausführen, Pakete installieren oder auf Produktionssysteme zugreifen darf, ist ein Sicherheitsrisiko, das bewusst begrenzt werden muss.
Der wirksamste einzelne Hebel im KI-Pair-Programming ist die Trennung von Planung und Umsetzung. Statt der KI sofort den Auftrag zu geben, ein Feature zu bauen, bittet man sie zunächst um einen Plan: Welche Dateien sind betroffen, welche Schritte sind nötig, welche Risiken und offenen Fragen gibt es? Viele Werkzeuge bieten dafür inzwischen einen eigenen Planungsmodus, in dem die KI nur liest und nichts ändert. Der Plan ist kurz genug, um ihn in wenigen Minuten zu prüfen, und er macht Missverständnisse sichtbar, bevor sie sich in hunderten Zeilen Code niederschlagen.
Tests sind die präziseste Sprache, in der man einer KI sagen kann, was sie tun soll. Eine bewährte Variante der testgetriebenen Entwicklung mit KI sieht so aus: Der Mensch beschreibt das gewünschte Verhalten, die KI schlägt Testfälle vor, der Mensch prüft und ergänzt diese Testfälle, und erst dann wird die Implementierung erzeugt, bis alle Tests grün sind. Der entscheidende Punkt ist die menschliche Prüfung der Tests. Sie legen fest, was als richtig gilt. Werden sie unkritisch übernommen, schreibt die KI im Zweifel einfach die Tests so um, dass sie zur eigenen Implementierung passen.
Für Agenten haben Tests eine zweite Funktion: Sie sind das Abnahmekriterium, an dem der Agent selbst erkennt, ob er fertig ist. Ein Agent, der Tests ausführen und deren Ergebnis lesen kann, korrigiert viele Fehler selbstständig, bevor der Mensch den Diff überhaupt sieht. Das funktioniert allerdings nur, wenn eine brauchbare Testbasis existiert und der Agent sie schnell ausführen kann. Teams mit dünner Testabdeckung sollten deshalb vor einer breiten Agentennutzung in Tests investieren, gegebenenfalls ebenfalls mit KI-Unterstützung. Ausdrücklich verboten werden sollte, dass ein Agent fehlschlagende Tests löscht oder abschwächt, um sein Ziel zu erreichen; solche Änderungen müssen im Review sofort auffallen.
Die Qualität der Antworten hängt stark davon ab, welchen Kontext die KI erhält. Neben den offenen Dateien und dem, was das Werkzeug selbst im Repository findet, haben sich projektbezogene Regeldateien etabliert. Je nach Werkzeug heißen sie unterschiedlich, das Prinzip ist gleich: Eine Textdatei im Repository beschreibt Architektur, Konventionen, Befehle für Build und Tests, verbotene Muster und Besonderheiten des Projekts. Die KI liest diese Datei bei jeder Aufgabe mit.
Eine gut gepflegte Regeldatei ist zugleich ein Nebenprodukt mit eigenem Wert: Sie macht ungeschriebenes Teamwissen explizit und hilft auch neuen Kolleginnen und Kollegen beim Einstieg. Sie sollte versioniert, im Review geändert und regelmäßig aufgeräumt werden. Ebenso wichtig ist es, Kontext zu begrenzen. Lange Chatverläufe mit vielen Richtungswechseln verschlechtern die Ergebnisse spürbar. Wer eine neue Teilaufgabe beginnt, startet besser eine neue Sitzung und gibt den abgestimmten Plan und die relevanten Dateien gezielt mit, statt die KI durch eine stundenlange Unterhaltung zu schleppen.
Die meisten Werkzeuge unterstützen Visual Studio Code und die JetBrains-Familie, viele auch Visual Studio, Vim oder Neovim. Für Teams im Mittelstand ist diese Breite wichtig, weil selten alle mit derselben Umgebung arbeiten: Die Webentwicklung nutzt Visual Studio Code, das ERP-Team eine JetBrains-IDE, die Steuerungsentwicklung eine herstellerspezifische Umgebung. Für Letztere gibt es oft keine direkte Integration. Hier können Terminal-Agenten oder ein separates Chat-Fenster mit gezielt eingefügtem Kontext eine Lösung sein, wenn auch mit weniger Komfort.
Das Model Context Protocol, kurz MCP, hat sich als offener Standard etabliert, über den KI-Assistenten externe Werkzeuge und Datenquellen ansprechen. Für das Paar bedeutet das: Die KI kann das Ticket lesen, zu dem sie gerade Code schreibt, in der internen Dokumentation nachschlagen, das Datenbankschema abfragen oder die Ergebnisse einer Testumgebung auswerten. Das verbessert die Treffsicherheit erheblich, weil die KI nicht mehr raten muss, was gemeint ist.
Jede zusätzliche Anbindung erweitert aber auch die Angriffsfläche. Inhalte aus Tickets, Webseiten oder Dokumenten können versteckte Anweisungen enthalten, die einen Agenten zu unerwünschten Aktionen verleiten, ein Risiko, das unter dem Begriff Prompt-Injection bekannt ist. MCP-Server aus unbekannten Quellen können zudem selbst Schadcode enthalten. Unternehmen sollten deshalb eine Liste freigegebener Server pflegen, Zugriffe nur lesend erlauben, wo das genügt, und Agenten mit Zugriff auf externe Inhalte keine weitreichenden Schreibrechte geben.
Was im Paar entsteht, muss denselben Weg gehen wie jeder andere Code: über einen Pull Request, durch automatische Prüfungen und durch ein menschliches Review. Das klingt selbstverständlich, wird aber unter Zeitdruck gern abgekürzt, gerade wenn die KI den Eindruck vermittelt, alles sei bereits geprüft. Eine robuste Pipeline mit Linter, statischer Analyse, Abhängigkeitsprüfung, Tests und gegebenenfalls einem Scan auf Geheimnisse ist die wichtigste Absicherung für KI-generierten Code. Ergänzend können KI-Review-Dienste eine Vorprüfung übernehmen. Sie ersetzen den menschlichen Reviewer nicht, entlasten ihn aber von offensichtlichen Befunden. Hilfreich ist zudem, in der Beschreibung eines Pull Requests offen anzugeben, welche Teile mit KI-Unterstützung entstanden sind. Das ist keine Schuldzuweisung, sondern ein Hinweis für den Reviewer, wo besonders genau hingesehen werden sollte.
GitHub Copilot ist für viele Teams der naheliegende Einstieg, weil es in vorhandene Entwicklungsumgebungen passt, eng mit GitHub verzahnt ist und über Microsoft-Verträge oft einfach beschafft werden kann. Inzwischen bietet es neben Autovervollständigung und Chat auch einen Agentenmodus im Editor und einen Cloud-Agenten, der Aufgaben aus Issues bearbeitet. Ähnlich aufgestellt sind JetBrains AI für die JetBrains-Welt, Gemini Code Assist im Google-Umfeld, Amazon Q Developer im AWS-Umfeld und GitLab Duo für Teams, die auf GitLab setzen. Der Vorteil dieser Werkzeuge liegt in der Einbettung in bestehende Plattformen und Verträge. KI-native Editoren wie Cursor oder Windsurf integrieren Agenten tiefer, verlangen aber einen Editorwechsel und eine gesonderte Prüfung der Datenflüsse.
Claude Code und vergleichbare Terminal-Agenten sind auf agentisches Arbeiten ausgelegt. Sie eignen sich besonders für Aufgaben, bei denen der Agent das Repository erkunden, mehrere Dateien ändern und Tests ausführen soll, und lassen sich in eigene Skripte und Pipelines einbinden. Nach unserem Kenntnisstand können die Modelle solcher Anbieter teilweise auch über große Cloud-Plattformen mit wählbarer Region bezogen werden, was die Datenschutzbewertung verändern kann. Welche Kombinationen aktuell möglich sind, sollten Sie beim Anbieter prüfen.
Quelloffene Werkzeuge wie Continue, Cline oder Aider bieten ähnliche Arbeitsweisen, lassen aber die Wahl des Modells offen. Damit lässt sich ein Modell über eine EU-Cloud-Region oder ein lokal betriebenes Modell mit offenen Gewichten nutzen. Tabby ist als selbst gehosteter Server konzipiert, der Autovervollständigung und Chat vollständig in der eigenen Infrastruktur bereitstellt. Diese Varianten sind die datenschutzfreundlichste Option, verlangen aber Betriebsaufwand und eine realistische Erwartung: Lokal betriebene Modelle sind je nach Hardware und Modellgröße in komplexen Agentenaufgaben oft schwächer als die führenden Cloud-Modelle. Für Autovervollständigung und Chat reichen sie in vielen Fällen aus.
Mit DeepSeek und der von ByteDance entwickelten Entwicklungsumgebung Trae sind auch Anbieter mit Sitz in China im Markt präsent, teils mit sehr günstigen oder kostenlosen Angeboten. Bei der Cloud-Nutzung solcher Dienste wird Quellcode an Server übertragen, die chinesischem Recht unterliegen können, einschließlich weitreichender staatlicher Zugriffsbefugnisse. Für Unternehmenscode raten wir von der Cloud-Nutzung dieser Dienste ab. Wo Modelle mit offenen Gewichten verfügbar sind, etwa bei DeepSeek, ist ein Betrieb in der eigenen Infrastruktur ohne Datenabfluss an den Hersteller denkbar; auch dann sollten Lizenzbedingungen, Herkunft und Verhalten des Modells geprüft werden. Für besonders sensiblen Code ist der Verzicht die sicherste Wahl.
Der Cloud-Dienst eines Anbieters ist der schnellste Weg zu ersten Erfahrungen. Für einen Pilot mit unkritischem Code ist das vertretbar, sofern ein Tarif gewählt wird, der die Nutzung des Codes für das Training von Modellen ausschließt. Für die breite Nutzung mit Kerncode sollten Auftragsverarbeitung, Speicherdauer und Subprozessoren vorher geklärt sein. Business- und Enterprise-Tarife der großen Anbieter enthalten in der Regel weitergehende vertragliche Zusagen, eine zentrale Verwaltung und Protokollierung. Welche Zusagen das konkret sind und ob eine Datenverarbeitung in der EU wählbar ist, unterscheidet sich je Anbieter und sollte aktuell geprüft werden.
Wer offene Werkzeuge nutzt, kann das Modell über einen Cloud-Anbieter mit EU-Region beziehen oder vollständig selbst betreiben. Self-Hosting bietet die größte Kontrolle, verlangt aber passende Hardware mit leistungsfähigen Grafikprozessoren, Betriebserfahrung und die Bereitschaft, bei der Modellqualität Abstriche zu machen. Ein hybrider Ansatz ist oft am praktikabelsten: Self-Hosting oder EU-Region für sensible Repositorys, ein vertraglich abgesicherter Cloud-Dienst für den übrigen Code.
Mindestens so wichtig wie das Betriebsmodell sind gemeinsame Regeln. Sie müssen nicht lang sein, aber schriftlich, bekannt und im Team vereinbart. Folgende Punkte gehören nach unserer Erfahrung in jede Teamvereinbarung zum KI-Pair-Programming:
Ein typisches Bild: Ein Maschinenbauer mit acht Personen in der Softwareentwicklung betreut ein Kundenportal, Schnittstellen zum ERP, eine Servicedatenbank und die Bedienoberfläche der Maschinen. Jede Person ist für mehrere Systeme zuständig, und Wissen ist ungleich verteilt. In einem solchen Team bringt KI-Pair-Programming vor allem dort Nutzen, wo Kolleginnen und Kollegen in Bereichen arbeiten müssen, die sie nicht täglich anfassen. Die KI erklärt die Struktur, schlägt einen Plan vor und hilft bei der Umsetzung, während der Mensch die fachlichen Entscheidungen trifft und die erfahrene Kollegin im Review den letzten Blick behält.
Eine der wichtigsten und am häufigsten unterschätzten Fragen ist, was KI-Pair-Programming mit den Fähigkeiten des Teams macht. Erfahrene Entwicklerinnen und Entwickler profitieren meist, weil sie Vorschläge schnell beurteilen können und Routinearbeit abgeben. Bei Berufseinsteigern besteht dagegen das Risiko, dass sie Ergebnisse übernehmen, die sie selbst nicht hätten erarbeiten können, und dadurch Grundlagen nie richtig lernen. Mittelfristig fehlt dann genau die Kompetenz, die man braucht, um KI-Vorschläge zu prüfen.
Bewährt haben sich einfache Gegenmaßnahmen. Erstens Lernphasen, in denen bewusst ohne Agent und mit KI nur als erklärendem Tutor gearbeitet wird. Zweitens die Regel, dass jede übernommene Lösung im Review in eigenen Worten erklärt werden kann. Drittens klassisches Pair Programming zwischen Menschen, das weiterhin seinen Platz hat, gerade für Architekturentscheidungen und Fachlogik. Viertens regelmäßige Übungen ohne KI, etwa bei der Fehlersuche, damit das eigene Debugging nicht verkümmert. Und fünftens eine Führungskultur, die Verstehen höher bewertet als bloße Geschwindigkeit. Ein Team, das seinen Code versteht, bleibt handlungsfähig, auch wenn ein Werkzeug ausfällt, teurer wird oder vom Markt verschwindet.
Die Frage nach dem Nutzen wird oft mit Eindrücken beantwortet. Das ist riskant, denn gefühlte und tatsächliche Produktivität können auseinanderliegen. Eine vielbeachtete kontrollierte Studie aus dem Jahr 2025 mit erfahrenen Open-Source-Entwicklern fand bei der Arbeit an vertrauten, komplexen Projekten sogar eine Verlangsamung mit KI-Werkzeugen, obwohl die Teilnehmenden selbst von einer Beschleunigung ausgingen. Andere Untersuchungen berichten deutliche Zeitgewinne bei klar abgegrenzten Aufgaben. Beides kann gleichzeitig stimmen. Der Nutzen hängt stark von Aufgabe, Erfahrung, Codebasis und Arbeitsweise ab und sollte deshalb im eigenen Umfeld gemessen werden.
Ungeeignet sind Kennzahlen wie die Zahl erzeugter Zeilen oder die Annahmequote von Vorschlägen. Sie messen Aktivität, nicht Wirkung, und belohnen im Zweifel mehr statt besseren Code. Aussagekräftiger ist ein Bündel aus Fluss-, Qualitäts- und Teamgrößen, wie es etwa die DORA-Kennzahlen und das SPACE-Framework nahelegen: Durchlaufzeit vom ersten Commit bis zur Auslieferung, Größe und Wartezeit von Pull Requests, Änderungsfehlerrate und Zahl nachträglich gefundener Fehler, Zeit bis zur Produktivität neuer Teammitglieder sowie regelmäßige kurze Befragungen zu Zufriedenheit und Belastung. Wichtig ist der Vergleich mit einem Ausgangswert und ein Zeitraum von mehreren Monaten. Und wichtig ist auch, was nicht gemessen wird: Individuelle Leistungsauswertungen auf Basis von KI-Nutzungsdaten sind weder methodisch sinnvoll noch mitbestimmungsrechtlich unproblematisch.
Kostenmodell realistisch einschätzen. Die meisten Anbieter rechnen pro Nutzer und Monat ab, mit gestaffelten Tarifen für Einzelpersonen, Teams und Unternehmen. Zunehmend kommen nutzungsabhängige Bestandteile hinzu, etwa Kontingente für besonders leistungsfähige Modelle oder Agentenläufe, deren Überschreitung zusätzlich berechnet wird. Gerade intensive Agentennutzung kann die Kosten deutlich über den Grundpreis heben. Bei offenen Werkzeugen entfallen Lizenzkosten, dafür entstehen Kosten beim Modellanbieter oder für eigene Hardware und Betrieb. Konkrete Preise und Kontingente ändern sich in diesem Markt häufig; prüfen Sie die aktuellen Konditionen direkt beim Anbieter.
Die führenden Anbieter von Coding-Assistenten und Sprachmodellen haben ihren Sitz überwiegend in den USA. Bei der Cloud-Nutzung werden Code-Ausschnitte, oft auch größere Teile des Repositorys für die Indizierung, an deren Infrastruktur übertragen. Damit stellen sich die bekannten Fragen nach Auftragsverarbeitung, Subprozessoren und der Rechtsgrundlage für den Transfer in die USA, etwa über das EU-US Data Privacy Framework oder Standardvertragsklauseln. Hinzu kommt, dass US-Anbieter auch bei Verarbeitung in europäischen Rechenzentren grundsätzlich US-Recht unterliegen können, was Zugriffsmöglichkeiten von Behörden betrifft. Für Anbieter mit Sitz in China gelten diese Bedenken in verschärfter Form, wie in Kapitel 06 beschrieben.
Besonders genau ist die Trainingsnutzung zu prüfen. Kostenlose und private Tarife erlauben teils die Verwendung von Eingaben zur Verbesserung der Modelle, Business- und Enterprise-Tarife schließen das in der Regel aus. Das muss für den konkreten Tarif und für die beteiligten Modellpartner schriftlich bestätigt sein. Die datenschutzfreundlichsten Varianten sind Modelle über eine EU-Region mit entsprechenden vertraglichen Zusagen und vor allem der Betrieb offener Modelle in der eigenen Infrastruktur. Sie verlangen mehr Eigenleistung, reduzieren den Code-Abfluss aber auf null oder auf vertraglich klar begrenzte Verarbeitung.
Quellcode ist für viele mittelständische Unternehmen ein zentrales Geschäftsgeheimnis. Der Schutz nach dem Geschäftsgeheimnisgesetz setzt angemessene Geheimhaltungsmaßnahmen voraus. Wer Code ohne vertragliche Absicherung an Cloud-Dienste gibt, schwächt im Zweifel diese Position. Klare Freigaben, ausgeschlossene Repositorys und dokumentierte Verträge sind deshalb auch eine Frage des Know-how-Schutzes. Personenbezogene Daten, Zugangsdaten und Kundendaten haben im Kontext der KI ohnehin nichts verloren; ein Scan auf Geheimnisse und der Ausschluss sensibler Pfade gehören zur Vorbereitung.
Auf der Ausgabeseite stellt sich die Frage nach Rechten am erzeugten Code. Die Nutzungsbedingungen der Anbieter räumen die Rechte am Ergebnis meist dem Kunden ein. Ob an rein KI-generiertem Code ein Urheberrecht entsteht, ist rechtlich jedoch nicht abschließend geklärt. Hinzu kommt das Risiko, dass ein Vorschlag geschützten Code aus öffentlichen Quellen nahezu wörtlich wiedergibt. Mehrere Anbieter bieten Filter gegen solche Übereinstimmungen und teils vertragliche Freistellungen an; deren Reichweite sollte geprüft werden. Bei ausgeliefertem Code empfiehlt sich zudem eine Lizenzprüfung der Abhängigkeiten, die durch KI-Vorschläge ins Projekt gelangen.
Coding-Assistenten erfassen Nutzungsdaten, die Rückschlüsse auf das Arbeitsverhalten einzelner Personen zulassen können. In Unternehmen mit Betriebsrat ist deshalb regelmäßig das Mitbestimmungsrecht bei technischen Einrichtungen berührt, die zur Leistungs- oder Verhaltenskontrolle geeignet sind. Eine Betriebsvereinbarung, die Zweck, Datenumfang und den Ausschluss individueller Leistungsauswertungen regelt, schafft Klarheit und Vertrauen. Soweit personenbezogene Daten verarbeitet werden, gehört die Nutzung in das Verzeichnis von Verarbeitungstätigkeiten. Und schließlich verlangt der EU AI Act von Unternehmen, die KI-Systeme einsetzen, eine angemessene KI-Kompetenz ihrer Mitarbeitenden. Eine Schulung zu Arbeitsweisen, Grenzen und Risiken des KI-Pair-Programmings ist dafür ein naheliegender Baustein.
