Die Ära der KI-Fördermittel neigt sich dem Ende zu: Es ist an der Zeit, über den geschäftlichen Nutzen zu sprechen

GitHub Copilot ist am 1. Juni 2026 auf eine nutzungsbasierte Abrechnung umgestellt worden. Wir haben bereits festgestellt, dass sich die KI-Ausgaben einiger Kunden für Copilot auf das Zweifache oder Dreifache (Median) erhöhen werden, bei einigen sogar auf das Achtfache! Und dies gilt für alle Modellanbieter und Anbieter: Anthropic drängt die Nutzer in seine „Max“-Tarife (200 $/Monat) und eine nutzungsabhängige Abrechnung für Claude Code. Gemini, Cursor, Windsurf und die übrigen Anbieter kommen nach denselben Berechnungen zu demselben Ergebnis. Die Ära, in der KI von Anbietern, die Marktanteile gewinnen wollten, stark subventioniert wurde, neigt sich dem Ende zu, und nun müssen wir den tatsächlichen Preis für das Hosting all dieser GPUs bezahlen.

Einige Unternehmen stehen kurz davor, die Augen zu öffnen und die Welt mit neuen Augen zu sehen.

Einige Berichte aus den letzten Tagen:

Lesen Sie alle vier Quellen, falls Sie dies noch nicht getan haben – darin werden die Zahlen ausführlicher behandelt, als ich es hier tun werde.

Ich möchte darüber sprechen, was nach der Panik kommt.

Die Talsohle, in die wir abrutschen

Wenn Sie sich den Gartner-Hype-Zyklus ansehen, ist dies die Phase unmittelbar nach dem „Höhepunkt überzogener Erwartungen“ – der Abstieg in die „Talsohle der Desillusionierung“. Wir befinden uns gerade mitten darin. Hier ist der Hype-Zyklus des letzten Jahres als Referenz, auch wenn er sich auf KI im Allgemeinen bezieht:

Die negative Stimmung hinsichtlich der Preisgestaltung ist auf LinkedIn, Mastodon, Reddit und in jeder Entwickler-Community dazwischen allgegenwärtig: Einzelne Nutzer wechseln zwischen Editoren und Befehlszeilenumgebungen hin und her, um das nächste Tool zu finden, das KI kostenlos oder nahezu kostenlos bereitstellt, während Unternehmen verzweifelt versuchen, die Kosten unter Kontrolle zu bringen, indem sie den Einsatz von KI einschränken, anstatt ihre Ingenieure dabei zu unterstützen.

Dieser zweite Ansatz ist der falsche Weg. Wenn man den Einsatz von KI darauf beschränkt, die Kosten zu kontrollieren, spart man zwar ein paar Tausend Euro im Monat, lässt aber ein Vielfaches davon an geschäftlichem Mehrwert ungenutzt. Das sehe ich immer wieder in den Zahlen.

Wie die Zahlen tatsächlich aussehen

Bei Xebia haben wir auf Basis der Standarddaten von GitHub ein „Copilot“-Abrechnungs-Dashboard entwickelt, das über zusätzliche Logik verfügt, welche beispielsweise die Berechnung für ein Upgrade von „Business“ auf „Enterprise“ während des aktuellen Aktionszeitraums hervorhebt. Dabei zeigt sich immer wieder das gleiche Muster: Eine kleine Gruppe von Power-Usern verursacht den Großteil der Kosten, während eine weitaus größere Gruppe ihr Kontingent kaum ausschöpft.

Ein Beispiel aus der Praxis: Vier Nutzer waren für rund 50 % der unternehmensweiten Kosten verantwortlich. Der Rest des Unternehmens verfügt jeden Monat über ungenutzte KI-Guthaben. Das ist kein Kostenproblem – das ist ein massives Problem hinsichtlich verpasster Chancen. Hinter diesen ungenutzten Lizenzen stehen Ingenieure, die eigentlich schneller Produkte auf den Markt bringen, technische Schulden abbauen oder MVPs entwickeln könnten, um neue Ideen zu testen – stattdessen nutzen sie vielleicht nur ein Drittel dessen, wofür sie bereits bezahlen. Manche Unternehmen gehen bei der Vergabe von Lizenzen falsch vor. Ich habe meine Ansichten dazu auf zahlreichen Konferenzen dargelegt:

Das AI-Credits-Pooling-Modell im Rahmen der neuen Abrechnungsregelung für GitHub Copilot trägt dem auf dem Papier Rechnung – Vielnutzer schöpfen aus dem gemeinsamen Pool, während Wenignutzer diese effektiv subventionieren. Doch es verschleiert auch die eigentliche Situation: Viele Lizenzen werden bezahlt, aber nicht genutzt. Genau diese Lücke möchte ich, dass die Teams schließen – mithilfe datengestützter Erkenntnisse und proaktiver Verwaltung.

Mein eigener Hockey-Schläger

Seit einiger Zeit verfolge ich meine eigene KI-Nutzung detailliert mit dieser VS-Code-Erweiterung, die ich selbst entwickelt habe. So sieht mein exponentielles Wachstum aus:

Bis Oktober 2025 nahezu null. Ein leichter Anstieg im November und Dezember. Anschließend steigt die Zahl bis zum 1. Quartal 2026 an und verzeichnet im März und April einen steilen Anstieg. Im April wurden etwa 530 Sitzungen und etwa 1,4 Milliarden Token verzeichnet. Für Mai werden etwa 1,8 Milliarden Token prognostiziert. Und um es klar zu sagen: Ich betreibe weder „ /fleet “, noch „Squad“ oder irgendeine andere Multi-Agenten-Armee. Es handelt sich um eine einzige Person, die die meiste Zeit interaktiv arbeitet.

Ich erinnere mich noch sehr gut an Ende März, als ich innerhalb von 30 Tagen meine ersten 100 Millionen Token erreicht hatte. Ich dachte: „Oh, das ist aber viel!“. Dann erreichte ich nur drei Wochen später bereits 1 Milliarde Token. Lassen Sie das einmal auf sich wirken: von 100 Millionen auf 1 Milliarde in drei Wochen.

Was hat sich geändert? Zwei Dinge. Erstens ist der Agent-Modus seit Dezember tatsächlich zu meiner Standardeinstellung für nicht-triviale Aufgaben geworden. Zweitens erhielt ich frühzeitigen Zugriff auf die GitHub Copilot-App, die im Mai 2026 in die technische Vorschau ging, und die von ihrer Konzeption her eine stärker agentenorientierte Erfahrung bietet, was natürlich mehr Token verbraucht: parallele Sitzungen, längere autonome Läufe, die Bearbeitung von CI-Fehlern durch „Agent Merge“, Merge-Konflikte und Kommentare zur Sicherheitsüberprüfung – alles völlig eigenständig. Ich habe hier am Tag der Veröffentlichung über diese Version berichtet.

Ja, meine KI-Kosten werden also deutlich steigen. Die Frage, auf die ich eingehen möchte, ist, ob sich das lohnt und wie ich das sehe.

Ein konkretes Beispiel: 57 Dollar in Tokens für eine JetBrains-Erweiterung

Hier sehen Sie eine Sitzung aus meinem eigenen, individuell angepassten Dashboard, das die Kosten pro Sitzung anzeigt:

Eine Sitzung. Ein paar Stunden meiner Zeit. 57,05 US-Dollar an KI-Kosten für Claude Opus 4.7, Sonnet 4.6, Haiku 4.5 und GPT-5 mini. Ergebnis: eine funktionsfähige JetBrains-Erweiterung – rajbos/ai-engineering-fluency –, die detaillierte Informationen zu Ihrer KI-Nutzung visualisiert: Sitzungen, Tokens, Chat-Runden, verwendete Modelle und sogar einen KI-Flüssigkeitswert. Es handelt sich um dieselben Einblicke, die ich bereits für VS Code und Visual Studio entwickelt hatte und die nun auf das JetBrains-Ökosystem portiert wurden.

Wenn ich das von Grund auf neu entwickeln müsste und mich dabei erst in das JetBrains-Plugin-SDK einarbeiten müsste, würde ich den Arbeitsaufwand auf zwei Wochen schätzen. Vielleicht sogar mehr. Stattdessen hat es mich nur ein paar Stunden und 57 Dollar in Form von Tokens gekostet.

Hat es sich gelohnt? Zwei Wochen Arbeitszeit eines Ingenieurs im Vergleich zu einigen Stunden plus 57 Dollar – da gibt es gar keinen Zweifel. Die Wirtschaftlichkeit liegt auf der Hand.

Das ist die Diskussion, die wir bei jeder sinnvollen KI-Sitzung führen müssen: nicht isoliert die Frage „Wie viel haben die Tokens gekostet?“, sondern „Was haben wir dafür erhalten, und was hätte die Alternative gekostet?“. Und natürlich sind auch bloße Kostenangaben und die Frage „Haben Sie etwas veröffentlicht?“ nicht der richtige Ansatz. Die eigentliche Frage lautet: „Welchen geschäftlichen Nutzen hatte die Sitzung insgesamt, und hat sich das gelohnt?“ Es ist schwierig, diese Sitzungen auf etwas Sinnvolles oder Greifbares zurückzuführen! Wenn ich in der ersten Sitzung mit der Recherche beginne und dann zu einem anderen Tool wechsle, ist es unrealistisch, diese Sitzungen miteinander zu verknüpfen. Aber wir können nah genug herankommen, um ein aussagekräftiges Gespräch über den Wert der in diesen Sitzungen geleisteten Arbeit zu führen, und genau das sollten wir tun. Auch das Gegenteil trifft zu: Mehr Mist und Fehler schneller in die Produktion zu bringen, ist ebenfalls kein gutes Geschäftsmodell. Bei der Wertediskussion muss es um die langfristigen Gesamtauswirkungen der Sitzung gehen, nicht nur um das einzelne Ergebnis oder die Kosten.

Wenn eine leistungsstarke Sitzung bei einem System, das täglich Millionen von Anfragen verarbeitet, die Bearbeitungszeit einer Anfrage um 2 ms verkürzt, ist das ein enormer geschäftlicher Erfolg. Wenn dadurch eine Funktion entsteht, die Kunden lieben und die den Umsatz steigert, ist das ein enormer geschäftlicher Erfolg. Wenn dadurch ein Codeabschnitt umgestaltet wird, der 10 % der Fehler in der Produktionsumgebung verursacht hat, ist das ein enormer geschäftlicher Erfolg. Wenn dadurch lediglich ein paar Zeilen Code mehr entstehen, die eigentlich keinen Unterschied machen, dann lohnt es sich vielleicht nicht.

Wenn eine Schulung einem neuen Entwickler im Team vermittelt, wie man etwas macht, was er zuvor nicht wusste, ist das ein großer geschäftlicher Gewinn. Wenn sie einem erfahrenen Entwickler hilft, einen Durchbruch bei einem Problem zu erzielen, an dem er schon seit Tagen feststeckte, ist das ein großer geschäftlicher Gewinn. Wenn dabei lediglich ein paar Zeilen Code mehr entstehen, die jedoch keinen wirklichen Unterschied bewirken, dann lohnt sich der Aufwand vielleicht nicht.

Zuerst die Grundlagen, dann die Geschwindigkeit

An dieser Stelle knüpft es an etwas an, das ich bereits seit über einem Jahr betone. Bereits im April 2025 schrieb ich den Beitrag „GitHub Copilot – Change the Narrative“, in dem ich darlegte, dass der Fokus auf Produktivität im Zusammenhang mit KI falsch sei. Der wahre Wert besteht darin, dass KI Ingenieuren Zeit verschafft, um eine solide DevOps-Grundlage zu schaffen: automatisierte Pipelines, Tests, denen man tatsächlich vertrauen kann, Überwachung, das „More-Eyes“-Prinzip und „Everything-as-Code“.

Dieses Argument ist heute relevanter als damals. Bei der nutzungsbasierten Abrechnung muss jedes Team nachweisen, welchen Nutzen seine KI-Ausgaben bringen. Und plötzlich werden wir wieder eine (begründete) Diskussion über die KI-Kosten für dieses Team führen. Die Teams, die antworten können: „Wir haben die Zeit genutzt, um unsere Pipelines, Tests und Überwachungsmechanismen auf Vordermann zu bringen, und nun stellen wir Funktionen innerhalb von Tagen statt Wochen bereit – mit der Gewissheit, dass sie den Produktivbetrieb nicht beeinträchtigen“, werden sich deutlich von den Teams unterscheiden, die lediglich mehr Funktionen schneller auf einer wackeligen Grundlage bereitgestellt haben.

Es ist die Aufgabe der technischen Führungskräfte, den Teams zu ermöglichen, das Beste aus ihrem KI-Einsatz herauszuholen. Sie müssen den Teams die Zeit geben, sich mit den neuen Tools vertraut zu machen, die KI-Konfiguration an ihren Tech-Stack und ihre Arbeitsweise anzupassen – und noch einiges mehr. So viele Unternehmen begehen den Fehler, Lizenzen zu vergeben und zu hoffen, dass sie dadurch die Leistung ihrer Ingenieure verzehnfachen können. So funktioniert das aber nicht!

Verbringen Sie stattdessen die Anfangszeit gemeinsam mit dem Team damit, die Grundlagen für deren SDCLC-Einrichtung zu schaffen. Bauen Sie Ihr Selbstvertrauen so weit auf, dass Sie tatsächlich schneller vorankommen können. Dann legen Sie noch einen Gang zu.

Sobald diese Grundlage solide ist, ist die Bewältigung des Rückstands bei der technischen Verschuldung kein Luxus mehr. KI-Sitzungen eignen sich hervorragend für die Art von abgegrenzten, gut getesteten Refactoring-Arbeiten, die normalerweise für immer ganz unten im Backlog liegen bleiben. Die Kosten für eine Refactoring-Sitzung sind gering. Die Kosten, die entstehen, wenn diese Schulden ein weiteres Jahr lang mitgeführt werden – in Form von verlangsamten Lieferprozessen und mehr Fehlern –, sind hingegen weitaus höher.

Und dann der eigentliche Gewinn: die Geschwindigkeit, mit der sich Chancen ergeben

Sobald die Grundlagen und die technische Verschuldung in einem zufriedenstellenden Zustand sind, geht es im nächsten Gespräch um das, was für das Unternehmen tatsächlich von Bedeutung ist: die Opportunitätskosten.

Ein Team, das KI nahtlos in seinen SDLC integriert und zudem über eine solide DevOps-Grundlage verfügt, kann blitzschnell reagieren. Am Montag eine Idee für eine neue Funktion, am Freitag bereits ein MVP in den Händen der Nutzer. Diese Reaktionsgeschwindigkeit ist der geschäftliche Mehrwert. Nicht etwa, dass „die Entwickler schneller tippen“. Nicht: „Wir haben 30 % mehr Story-Punkte ausgeliefert.“ Die Fähigkeit, innerhalb von Tagen statt Monaten auf ein Marktsignal oder eine Kundenanforderung zu reagieren, ist das, was KI im SDLC tatsächlich ermöglicht – und genau das sollte im Business Case stehen.

Das Gespräch mit der Geschäftsseite läuft also wie folgt ab: Hier ist die Änderung, hier sind die KI-Kosten (Schulung der Ingenieure, Tokens, Rechenleistung), die für die Umsetzung erforderlich waren – ist der Nutzen diese Kosten wert? Meine ehrliche Erwartung ist, dass die Antwort in den meisten Fällen sofort „Ja“ lautet. In den Fällen, in denen dies nicht offensichtlich ist, richten Sie eine KI-Sitzung ein, um die erforderlichen Untersuchungen durchzuführen und ein schnelles MVP zu erstellen – das ist heutzutage ein Kinderspiel und reicht in der Regel aus, um einen echten Business Case zu erstellen.

Prüfen Sie den aktuellen Aufwand, um Überraschungen zu vermeiden, und lenken Sie das Gespräch anschließend auf den geschäftlichen Nutzen

Hier sind einige konkrete Punkte, in etwa in der Reihenfolge, in der ich sie angehen würde:

Falls Sie über eines dieser Themen sprechen möchten, kontaktieren Sie mich bitte auf LinkedIn.

Das Ende der Subventionsära ist keine schlechte Sache. Es zwingt uns zu einer Diskussion, die wir schon von Anfang an hätten führen sollen: Was ist das eigentlich wert?

Dieser Beitrag erschien ursprünglich auf devopsjournal.io