Die meiste Aufmerksamkeit bekommt die Frage, welches KI-Coding-Tool man anschaffen soll. Am teuersten wird zwei Jahre später eine andere Frage: wie schwer es ist, das gewählte Tool wieder loszuwerden.
Wir begleiten Entwicklungsorganisationen, die KI-Coding-Tools über Hunderte von Entwicklern ausrollen, und am Anfang kommt die Frage nach dem Lock-in so gut wie nie auf. Gemessen am Produktivitätsversprechen ist das Tool günstig, der Test läuft gut, und der Rollout bekommt eine Eigendynamik. Lock-in ist kein einzelner Moment. Es ist das langsame Anwachsen von Abhängigkeiten, deren Auflösung teuer wäre, sobald jemand sie einmal zusammenzählt.
Das ist kein Argument gegen die Festlegung auf einen Anbieter. Sich auf ein Tool zu standardisieren, hat handfeste Vorteile: einheitliche Workflows, ein einziges Sicherheits-Review, eine einzige Supportbeziehung. Das Argument lautet, sich bewusst festzulegen, mit klarem Blick darauf, was Sie aus der Hand geben und was es kosten würde, es zurückzuholen.
Wo das Lock-in tatsächlich entsteht
Das Abonnement ist der Teil, den Sie an einem Nachmittag kündigen können. Das Lock-in steckt überall sonst.
- Abhängigkeit im Workflow. Sobald ein Tool fest darin verankert ist, wie Entwickler Branches anlegen, Tests schreiben und Pull Requests vorbereiten, heißt ein Wechsel, dem ganzen Team eingeübte Routinen wieder abzutrainieren. Das ist kein Umlegen eines Schalters.
- Gewachsene Konfiguration. Eigene Regeln, Prompt-Bibliotheken, Repository-Kontext und Einstellungen pro Team stecken voller Monate an Feinarbeit. Liegen sie in einem proprietären Format, ziehen sie nicht mit um.
- Bindung ans Modell. Teams stimmen ihre Prompts und Erwartungen unmerklich auf das Verhalten eines bestimmten Modells ab. Wechseln Sie zu einem anderen, liefern dieselben Prompts plötzlich andere Ergebnisse, und der gemessene Gewinn ist dahin, bis Sie alles neu justiert haben.
- Tiefe von Agenten und Automatisierung. Je mehr Sie ein Tool selbst steuern lassen (Befehle ausführen, PRs eröffnen, in die CI eingreifen), desto größer wird der Teil Ihrer Pipeline, der voraussetzt, dass genau dieses Tool existiert.
- Daten und Historie. Gesprächsverläufe, generierte Artefakte und Nutzungsstatistiken bleiben oft beim Anbieter. Was Sie nicht exportieren können, können Sie nicht mitnehmen.
Nichts davon taucht auf der Rechnung auf. Alles davon erhöht den Preis eines Ausstiegs.
Was Lock-in kostet, wenn es darauf ankommt
Zum Problem wird Lock-in erst, wenn Sie wechseln müssen und nicht können. Und diese Momente sind absehbar.
| Auslöser | Was mit Lock-in passiert |
|---|---|
| Preis bei Verlängerung | Die Preismacht liegt beim Anbieter. Ein Team, das nicht glaubhaft gehen kann, hat keinen Hebel auf die Zahl. |
| Verschlechterung des Modells | Das zugrunde liegende Modell ändert sich, und Ihre Ergebnisqualität sinkt. Baut Ihr Workflow auf dieses Modell, müssen Sie das ausbaden. |
| Neue Compliance-Vorgabe | Eine neue regulatorische Anforderung oder eine Datenresidenz-Pflicht, die der Anbieter nicht erfüllen kann, erzwingt einen Wechsel, auf den Sie nicht vorbereitet sind. |
| Instabiler Anbieter | Übernahme, Kurswechsel oder Abschaltung. Der Markt für KI-Tooling ist jung; einige der heutigen Anbieter wird es in dieser Form nicht mehr geben. |
| Eine bessere Option taucht auf | Ein deutlich besseres Tool erscheint, und die Wechselkosten sind so hoch, dass Sie beim schlechteren bleiben. |
Die letzte Zeile ist die unauffällige. Die eigentlichen Kosten von Lock-in sind selten ein schlechtes Ergebnis, das Sie erleiden. Es ist das bessere Ergebnis, das Sie ausschlagen, weil der Wechsel zu schmerzhaft wäre.
Beweglich bleiben, ohne Tempo zu verlieren
Beweglichkeit heißt nicht, sich nicht festzulegen. Sie heißt, die Kosten dafür im Griff zu behalten, falls Sie es sich anders überlegen. Ein paar Praktiken erledigen dabei den Großteil der Arbeit.
- Prompts und Absicht in der Hand der Menschen lassen. Das Verständnis, *warum* eine Änderung gemacht wird, gehört in Ihr Team und Ihr Repository, nicht allein in das Kontextfenster eines Anbieters. Genau diese Disziplin hält auch das Review ehrlich, und nebenbei sorgt sie für Beweglichkeit.
- Konfiguration in Formaten ablegen, die Ihnen gehören. Bevorzugen Sie Tools, mit denen Sie Regeln, Prompts und Kontext als einfache Dateien in Ihren eigenen Repositories behalten, gegenüber solchen, die alles in einer proprietären Cloud einsperren.
- Eine Grenze bei kritischer Automatisierung ziehen. Lassen Sie ein Tool ruhig überall assistieren. Aber überlegen Sie genau, wo Sie es tragend werden lassen. Je tiefer es in CI und Deployment sitzt, desto schwerer wird es, es wieder herauszulösen.
- Datenexport zur Bedingung im Einkauf machen. Vergewissern Sie sich vor der Unterschrift, dass Sie Historie, generierte Artefakte und Statistiken in einem brauchbaren Format exportieren können. „Sie können jederzeit gehen“ stimmt nur, wenn Ihre Daten mitgehen können.
- Bewusst irgendwo ein zweites Tool betreiben. Wenn ein, zwei Teams mit einer Alternative arbeiten, bleibt echtes Wissen über den Markt erhalten, und Sie haben einen glaubwürdigen Plan B. Der Aufwand ist gering, der Wert dieser Wahlfreiheit groß.
Den Ausstieg in den Vertrag schreiben
Beweglichkeit ist größtenteils eine technische Frage, aber die günstigste Versicherung ist eine vertragliche. Sie kostet nichts, wenn Sie vor der Unterschrift danach fragen.
| Klausel | Warum sie zählt |
|---|---|
| Recht auf Datenexport | Garantiert, dass Sie Ihre Historie und Artefakte beim Ausstieg in einem Standardformat zurückbekommen. |
| Deckel auf Preiserhöhungen | Begrenzt böse Überraschungen bei der Verlängerung und wahrt Ihre Verhandlungsposition. |
| Kündigungs- und Übergangsfristen | Verschaffen Ihnen Zeit zum Migrieren, statt zur Verlängerung einfach abgeschnitten zu werden. |
| Regeln zu Löschung und Aufbewahrung | Klären, was der Anbieter nach Ihrem Weggang behält, und wie lange. |
Das sind übliche Klauseln für jeden ernsthaften Softwarekauf. Während eines erfolgreichen Tests wirken sie überflüssig. Genau deshalb fallen sie unter den Tisch, und genau dann hätten Sie den Hebel, sie durchzusetzen.
Unsere Sicht
Vendor-Lock-in bei KI-Coding-Tools ist kein Grund zu zögern, und es lässt sich nicht dadurch lösen, dass Sie auf Standardisierung verzichten. Es löst sich, indem Sie bewusst und früh entscheiden, welche Teile Ihres Entwicklungs-Workflows Sie von einem einzelnen Anbieter abhängig machen wollen, und welche nicht.
Behalten Sie das Verständnis Ihres Codes bei Ihren Leuten. Behalten Sie Ihre Konfiguration in Formaten, die Ihnen gehören. Überlegen Sie genau, wie tief Sie ein einzelnes Tool in Ihre Pipeline hineinreichen lassen, und schreiben Sie den Ausstieg in den Vertrag, solange die Beziehung noch jung ist. Tun Sie das, holen Sie sich den vollen Nutzen einer Festlegung, ohne stillschweigend die Möglichkeit zu verspielen, es sich anders zu überlegen.
Das Ziel ist nicht, von keinem Anbieter abhängig zu sein. Es ist, dafür zu sorgen, dass der Ausstieg eine Entscheidung bleibt, die Sie selbst treffen, wenn der Verlängerungspreis, der Modellwechsel oder die bessere Option kommt, und nicht eine, die längst für Sie getroffen wurde.
Quellen
- NIST,
AI Risk Management Framework (AI RMF 1.0), zu Risiken durch Drittanbieter und Lieferketten, abgerufen am 2026-06-11 - DORA,
Accelerate State of DevOps, zu Delivery-Performance und Tooling, abgerufen am 2026-06-11 - Cloud Security Alliance,
AI Resilience, Leitfaden zum Konzentrationsrisiko bei Anbietern, abgerufen am 2026-06-11
Häufige Fragen
- Was erzeugt Vendor-Lock-in bei KI-Coding-Tools?
- Nicht das Abonnement, das Sie schnell kündigen können. Lock-in entsteht in der Workflow-Abhängigkeit, in angesammelter Konfiguration und Prompt-Bibliotheken in proprietären Formaten, in Prompts, die auf das Verhalten eines Modells abgestimmt sind, in tiefer Automatisierung in CI und Deployment sowie in Historie und Analysen, die der Anbieter behält. Nichts davon steht auf der Rechnung, alles erhöht die Kosten des Verlassens.
- Wie vermeidet man Lock-in bei einem KI-Coding-Tool?
- Behalten Sie das Verständnis Ihres Codes bei Ihren Leuten, legen Sie Regeln und Prompts als einfache Dateien in Ihren eigenen Repositories ab, seien Sie bewusst darin, wie tief Sie ein Tool in kritische Automatisierung reichen lassen, machen Sie Datenexport zur Beschaffungsanforderung und halten Sie ein oder zwei Teams auf einer Alternative, um einen glaubwürdigen Rückfall zu behalten.
- Ist die Standardisierung auf ein KI-Coding-Tool eine schlechte Idee?
- Nein. Standardisierung bringt gemeinsame Workflows, ein Sicherheits-Review und eine einzige Supportbeziehung. Das Risiko ist nicht die Festlegung, sondern die unbewusste Festlegung – in Abhängigkeit zu driften, ohne zu entscheiden, welche Teile des Workflows Sie aus der Hand geben. Legen Sie sich bewusst fest, mit klarem Blick darauf, was ein Ausstieg kosten würde.
- Welche Vertragsklauseln schützen vor Lock-in bei KI-Coding-Tools?
- Rechte auf Datenexport in einem Standardformat, Deckel auf Preiserhöhungen, Kündigungs- und Übergangsfristen vor der Verlängerung sowie klare Klauseln zu Löschung und Aufbewahrung. Das sind gewöhnliche Klauseln für ernsthafte Software, die Frage danach kostet nichts, und der Hebel, sie durchzusetzen, ist während eines erfolgreichen Tests am größten – genau dann werden sie übersprungen.
