Die Ökonomie von Agentic Work

Ein Coding Agent erzeugt in wenigen Minuten Code, für den ein Entwickler früher Stunden gebraucht hätte. Das ist inzwischen keine besonders exotische Erfahrung mehr. Je nach Aufgabe kann der Unterschied beeindruckend sein: Eine Implementierung, die früher einen halben Arbeitstag beansprucht hätte, steht nach wenigen Minuten als erster vollständiger Diff bereit.

Daraus entsteht schnell eine scheinbar naheliegende Rechnung:

10× schnellere Codegeneration
=
10× schnellere Softwareentwicklung
=
10× niedrigere Kosten

Die erste Zeile dieser Rechnung kann stimmen. Die beiden Gleichheitszeichen nicht.

Nicht, weil Codegeneration keinen Wert hätte. Im Gegenteil: Ich arbeite inzwischen intensiv mit Coding Agents und erlebe dabei selbst deutliche Produktivitätsgewinne. Für meine eigene Arbeit würde ich den aktuellen Effekt grob in der Größenordnung von 20 Prozent einordnen – bereits inklusive ernsthaftem Review der erzeugten Änderungen. Das ist keine wissenschaftliche Effektgröße, sondern meine persönliche Erfahrungsgröße in meinem aktuellen Arbeitskontext.

Der Fehler liegt an einer anderen Stelle: Wir verwechseln die Beschleunigung eines Produktionsschritts mit der Beschleunigung des gesamten Produktionssystems.

Software Engineering besteht nicht nur aus dem Schreiben von Code. Vor einer Änderung stehen Problemverständnis, Anforderungen, Architektur und Lösungsentscheidungen. Danach folgen Tests, Integration, Debugging, Verifikation, Review, Security, Betrieb und fachliche Acceptance. Manche dieser Schritte können durch AI ebenfalls schneller werden. Andere bleiben weitgehend bestehen. Einige werden sogar wichtiger, wenn die Menge maschinell erzeugter Änderungen steigt.

Genau deshalb ist die interessante ökonomische Frage nicht:

Wie billig kann ein Modell Tokens erzeugen?

Sondern:

Welche Kosten waren notwendig, bis aus einer gewünschten Änderung eine technisch und fachlich ausreichend verifizierte, akzeptierte Änderung wurde?

Ich werde diese operative Einheit im Folgenden Cost per Accepted Change nennen.

Sie ist nicht dasselbe wie ROI. Eine Änderung kann für wenige Euro erzeugt, getestet und akzeptiert werden und trotzdem wirtschaftlich wertlos sein. Umgekehrt kann eine teure Änderung einen enormen Geschäftswert besitzen. Cost per Accepted Change misst zunächst die Effizienz des Engineering-Prozesses. Der wirtschaftliche Wert liegt noch eine Ebene darüber.

Der rote Faden dieses Artikels führt deshalb vom Token über den Agent Run und die akzeptierte Änderung bis zur Organisation – und am Ende zu einer Frage, die in kurzfristigen Produktivitätsrechnungen leicht verloren geht: Welche Fähigkeiten besitzt eine Organisation danach noch, und welche baut sie für die Zukunft auf?

Der falsche Multiplikator

Software Engineering ist nicht Coding.

Das klingt banal, wird aber in vielen Diskussionen über AI-Produktivität erstaunlich schnell vergessen. Wenn eine Tätigkeit, die bisher drei Stunden dauerte, auf 18 Minuten schrumpft, ist der sichtbare Beschleunigungsfaktor tatsächlich zehn. Nur war diese Tätigkeit möglicherweise lediglich ein Teil einer achtstündigen Änderung.

Der Rest verschwindet nicht automatisch.

Eine fachliche Anforderung muss weiterhin verstanden werden. Architekturentscheidungen müssen zu einem bestehenden System passen. Tests müssen nicht nur vorhanden sein, sondern sinnvolle Aussagen treffen. Ein Diff kann syntaktisch korrekt und trotzdem fachlich falsch sein. Eine Migration kann lokal funktionieren und im Produktionssystem scheitern. Security-Anforderungen lassen sich nicht dadurch erfüllen, dass das Modell selbstbewusst behauptet, sie eingehalten zu haben.

Coding Agents können auch diese Tätigkeiten unterstützen. Das ist ein wichtiger Teil ihres Werts. Aber dann müssen wir genau diesen Effekt messen – nicht den Faktor, um den lediglich die Generierung von Implementierungscode schneller geworden ist.

10× Codegeneration
≠
10× Software Engineering
≠
10× Kostenreduktion

Gerade die aktuelle empirische Forschung zeigt, wie stark der gemessene Effekt vom betrachteten Ausschnitt abhängt. In einem bekannten randomisierten GitHub-Copilot-Experiment mit 95 rekrutierten Softwareentwicklern wurde eine klar abgegrenzte JavaScript-Aufgabe mit Copilot im Durchschnitt 55,8 Prozent schneller abgeschlossen. Drei größere randomisierte Feldexperimente bei Microsoft, Accenture und einem weiteren Fortune-100-Unternehmen mit zusammen 4.867 Entwicklern fanden in der kombinierten Auswertung 26,08 Prozent mehr abgeschlossene Aufgaben. Diese Arbeit ist inzwischen in Management Science erschienen. Auch dort schwanken die Resultate zwischen den einzelnen Experimenten deutlich; die gepoolte Schätzung besitzt einen Standardfehler von 10,3 Prozentpunkten.

Ein anderes Setting lieferte sogar das gegenteilige Ergebnis: METR ließ 2025 erfahrene Open-Source-Entwickler reale Aufgaben in ihren eigenen, ihnen seit Jahren bekannten Repositories bearbeiten. Mit damaligen AI-Tools benötigten sie im randomisierten Versuch im Mittel 19 Prozent mehr Zeit. METR betont selbst ausdrücklich, dass dies eine Momentaufnahme früher 2025er Werkzeuge in einem speziellen Umfeld war. Ein Folgeexperiment mit neueren Modellen deutete 2026 eher auf Beschleunigung hin, litt aber unter so starken Selektions- und Messproblemen, dass die Autoren die Größenordnung selbst als unzuverlässig bezeichnen.

Noch interessanter ist die im September 2026 revidierte Fassung des NBER Working Papers Writing Code vs. Shipping Code mit Daten von mehr als 500.000 GitHub-Entwicklern und deren AI-Nutzungstelemetrie. Dort wachsen mit neueren Generationen von Coding Tools die gemessenen Commits massiv. Für autonome Coding Agents berichten die Autoren einen kumulierten Effekt von 240 Prozent auf Commits. Auf höheren Produktionsstufen schwächt sich der Effekt jedoch deutlich ab: auf 80 Prozent bei Projekten und nur noch 30 Prozent bei tatsächlichen Releases. Auch das ist ein Working Paper, keine endgültige kausale Wahrheit. Der Befund illustriert aber sehr schön das Problem dieses Artikels: Writing Code und Shipping Code sind unterschiedliche Produktionsstufen.

Der relevante Multiplikator liegt deshalb nicht im Editor. Er liegt im vollständigen Produktionsfluss.

Vom Token zur akzeptierten Änderung

Die einfachste ökonomische Kennzahl eines Sprachmodells ist der Preis pro Token. Sie ist präzise, leicht vergleichbar und deshalb attraktiv.

Sie beantwortet nur leider eine sehr kleine Frage.

Eine sinnvollere Hierarchie sieht so aus:

Cost per Token
↓
Cost per Run
↓
Cost per Successful Run
↓
Cost per Accepted Change
↓
Economic Value

Cost per Token beantwortet, wie teuer Inferenz nach Tarif ist.

Cost per Run berücksichtigt, wie viel Kontext und Output ein konkreter Lauf tatsächlich verbraucht.

Cost per Successful Run berücksichtigt zusätzlich, dass ein Agent scheitern, abbrechen oder einen unbrauchbaren Lösungsweg verfolgen kann.

Cost per Accepted Change berücksichtigt schließlich, wie viele Versuche, Tests, Korrekturen, Reviews und wie viel menschliche Arbeitszeit erforderlich waren, bis die Änderung akzeptabel war.

Erst darüber liegt der Economic Value: Welchen wirtschaftlichen Nutzen erzeugt diese Änderung überhaupt?

Das lässt sich auch anders formulieren:

Model Pricing beantwortet die Frage, was Rechenarbeit kostet. Es beantwortet nicht, was Problemlösung kostet.

Das ist ein fundamentaler Unterschied. Ein Agent Run für 20 Cent, dessen Ergebnis ich 45 Minuten lang reparieren muss, kann teurer sein als ein Run für fünf Euro, den ich nach zehn Minuten Review akzeptiere.

Und eine technisch akzeptierte Änderung kann immer noch ein Feature sein, das niemand braucht.

Cost per Accepted Change ist deshalb kein Ersatz für ROI. Es ist die operative Engineering-Ebene unmittelbar darunter.

Was kostet Generation tatsächlich?

Bei tokenbasierter Abrechnung sind zunächst drei direkt bepreiste Kategorien besonders relevant. Input Tokens umfassen den Kontext, den das Modell erhält: Prompt, Conversation History, Sourcecode, Agent Instructions, Tool-Ergebnisse und gegebenenfalls große Teile eines Repositories. Cached Input ist wiederverwendeter Kontext, den der Provider zu einem reduzierten Preis abrechnen kann. Output Tokens umfassen die vom Modell erzeugte Nutzung. Bei Reasoning-Modellen können darin zusätzlich interne Reasoning Tokens enthalten sein, die nicht als sichtbarer Antworttext erscheinen.

Agentische Workflows machen diese Rechnung komplexer als einen einzelnen Chat. Ein Agent liest Dateien, führt Tools aus, erhält deren Ergebnisse zurück, verändert Code, startet Tests und verarbeitet deren Output. Er kann denselben Repository-Kontext mehrfach sehen oder aufgrund einer fehlgeschlagenen Hypothese mehrere Schleifen drehen.

Auch Tool Calls können je nach Plattform zusätzliche Gebühren besitzen. Lange Kontexte können eigene Preisregeln haben. Bei GPT-5.6 Sol werden API-Anfragen mit mehr als 272.000 Input Tokens beispielsweise für den gesamten Request mit dem doppelten Input- und dem 1,5-fachen Output-Tarif berechnet; Cache Writes kosten dort das 1,25-Fache des normalen Input-Tarifs. GPT-6 Astra besitzt ebenfalls eigene Cache-Write- und Long-Context-Regeln. Produktoberflächen wie Codex können wiederum abweichende Ausnahmen besitzen.

Damit wird bereits deutlich: Selbst der Listenpreis eines Modells ist noch keine vollständige Kostenfunktion für einen Agentic Flow.

Modellpreise im September 2026

Stand 10. September 2026 gelten bei OpenAI für GPT-5.6 Sol und GPT-6 Astra folgende Standardpreise pro Million Text-Tokens:

Modell	Input / 1M	Cached Input / 1M	Output / 1M	Hinweis
GPT-5.6 Sol	$4,00	$0,40	$20,00	Promotionstarif mindestens bis 21.11.2026
GPT-6 Astra	$10,00	$1,00	$50,00	Standardtarif am Stichtag
Verhältnis Astra / Sol	2,5×	2,5×	2,5×	bezogen auf diese Listenpreise

Die Werte stammen aus den aktuellen offiziellen OpenAI-Modellseiten und der tokenbasierten Rate Card. OpenAI weist ausdrücklich darauf hin, dass der derzeitige Sol-Preis ein zeitlich begrenzter Promotionstarif ist.

Astra besitzt damit nominal einen 2,5-fachen Preis pro Token gegenüber Sol.

Das ist eine korrekte Aussage.

Die Aussage

Astra kostet 2,5-mal so viel pro gelöster Aufgabe

folgt daraus jedoch nicht.

Und die Aussage

Astra kostet 2,5-mal so viel pro akzeptierter Änderung

noch weniger.

Konkrete Preise werden 2027 wahrscheinlich schon wieder veraltet sein. Das Rechenmodell dahinter bleibt trotzdem relevant.

Reasoning ist kein fixer Multiplikator

Besonders vorsichtig sollte man mit Aussagen wie „High Reasoning kostet dreimal so viel“ sein. Ein höheres Reasoning-Level erhöht bei OpenAI innerhalb desselben Modells nicht automatisch den Listenpreis pro Token. Die aktuelle Rate Card nennt für GPT-5.6 ausdrücklich denselben Tarif über verschiedene Reasoning-Stufen hinweg.

Mehr Reasoning kann allerdings mehr Nutzung erzeugen. OpenAI weist Reasoning Tokens innerhalb der output_tokens_details aus; sie sind Teil der Output-Nutzung. max_output_tokens umfasst sowohl sichtbare Ausgabe als auch Reasoning Tokens.

Ökonomisch lautet die saubere Formulierung deshalb:

Reasoning Effort ist kein fixer Preisaufschlag. Höherer Aufwand kann zusätzlichen Compute und zusätzliche Tokens verursachen, deren Umfang von Aufgabe, Modell und Lauf abhängt.

Das ist mehr als Wortklauberei. Für eine Aufgabe kann ein höherer Reasoning-Aufwand die Tokenzahl erhöhen und trotzdem billiger sein, wenn dadurch zwei weitere Agent Runs entfallen. Bei einer einfachen, bereits stark konvergierten Tätigkeit kann derselbe zusätzliche Aufwand schlicht Verschwendung sein.

Eine Änderung ist mehr als ihre Implementierung

Nehmen wir eine bewusst vereinfachte Änderung mit insgesamt acht Stunden klassischem Engineering-Aufwand. Die Implementierung selbst benötigt davon drei Stunden.

Ein Coding Agent beschleunigt genau diesen Teil um den Faktor zehn: Aus 180 Minuten Implementierung werden 18 Minuten.

Gleichzeitig verschiebt sich Arbeit in andere Phasen. Der Agent erzeugt mehr Tests und iteriert selbstständig, der Entwickler investiert dafür stärker in Review und Verifikation. Die folgenden Werte sind keine empirischen Durchschnittswerte, sondern eine illustrative Modellrechnung:

Arbeitsschritt	Klassisch	Agentisch
Verstehen / Analyse	60 min	55 min
Architektur / Entscheidung	45 min	50 min
Implementierung	180 min	18 min
Tests / Iterationen	75 min	90 min
Review / Verification	60 min	100 min
Integration / Acceptance	60 min	67 min
Gesamt	480 min	380 min

Die eigentliche Codeproduktion ist um 90 Prozent gefallen. Die Gesamtdauer sinkt aber nur von acht Stunden auf sechs Stunden und 20 Minuten: um rund 21 Prozent.

Das wäre keineswegs enttäuschend.

Ein belastbarer Produktivitätsgewinn von rund 20 Prozent in einer teuren Engineering-Organisation wäre ökonomisch hochattraktiv. Er klingt nur weniger spektakulär als „10ד.

Und genau darin liegt das Problem vieler AI-Diskussionen: Ein realistischer systemischer Gewinn wirkt klein, wenn man ihn direkt neben den Beschleunigungsfaktor einer einzelnen Tätigkeit stellt.

Die empirischen Ergebnisse passen zu dieser Vorsicht. Unter klar abgegrenzten Bedingungen können sehr große Beschleunigungen auftreten; in komplexeren realen Arbeitsumgebungen schwanken die Effekte erheblich und können sich entlang der Produktionskette abschwächen.

Meine persönliche Schätzung von ungefähr 20 Prozent ist deshalb auch genau das: eine persönliche Schätzung. Sie ist weder Bestätigung noch Widerlegung irgendeiner Studie.

Das teurere Modell kann billiger sein

Mit den aktuellen OpenAI-Preisen lässt sich das Problem noch konkreter zeigen.

Nehmen wir eine anspruchsvolle Änderung, bei der jeder Agent Run ungefähr 200.000 Input Tokens und 15.000 Output Tokens benötigt. Beim ersten Lauf ist der Input uncached; bei Folgeversuchen nehmen wir stark vereinfacht an, dass der große Kontext vollständig aus dem günstigen Cache gelesen werden kann.

Sol benötigt drei Versuche. Astra schafft in diesem Beispiel mit einem Versuch eine akzeptable Lösung.

Für menschliche Arbeit setzen wir in der Modellrechnung Vollkosten von $100 pro Stunde an. Auch das ist nur eine illustrative Rechengröße.

Kennzahl	GPT-5.6 Sol	GPT-6 Astra
Listenpreis je Tokenkategorie	1×	2,5×
Tokens pro Run	200k Input + 15k Output	200k Input + 15k Output
Anzahl Runs	3	1
Korrekturschleifen	2	0
Modellkosten	$1,86	$2,75
Steuerungs- / Korrekturzeit	70 min	25 min
Review / Verification	35 min	20 min
Human Active Time gesamt	105 min	45 min
Menschliche Kosten bei $100/h	$175,00	$75,00
Accepted	ja, nach Run 3	ja, nach Run 1
Cost per Accepted Change	$176,86	$77,75

Die Modellkosten von Sol berechnen sich hier aus einem ersten Lauf von $1,10 und zwei stark gecachten Folgeversuchen zu jeweils $0,38. Astra ist mit $2,75 reiner Inferenz tatsächlich teurer.

In der Gesamtrechnung ist Astra trotzdem erheblich günstiger, weil die angenommene menschliche Arbeitszeit stärker sinkt.

Die Modellrechnung beweist natürlich nicht, dass Astra generell besser oder billiger ist. Sie zeigt lediglich, warum der Listenpreis keine ausreichende Optimierungsvariable ist.

Das günstigste Modell ist nicht zwangsläufig das Modell mit dem niedrigsten Tokenpreis. Es ist das Modell, das eine ausreichend gute, verifizierte Änderung zu den niedrigsten Gesamtkosten erzeugt.

Das Gegenbeispiel ist genauso wichtig. Für einen standardisierten CRUD-Endpunkt mit hervorragenden Tests, klaren Architekturregeln und wenig Entscheidungsspielraum wäre ein Frontier-Modell möglicherweise unnötig. Wenn ein günstigeres Modell denselben Change mit derselben Zuverlässigkeit produziert, vernichtet zusätzliche Capability schlicht Marge.

Model Routing ist deshalb keine Qualitätsfrage allein. Es ist eine ökonomische Steuerungsaufgabe.

Modellökonomie altert schnell

Wie schnell diese Betrachtung veraltet, zeigt bereits die Entwicklung der letzten zwei Jahre.

Die folgende Tabelle ist ausdrücklich keine Benchmark-Zeitreihe. Benchmarks, Harnesses, Prompting, Reasoning Budgets, Test-Time Compute und teilweise sogar die Datensätze selbst haben sich verändert. Die Zahlen dürfen deshalb nicht zu einer mathematischen „Capability-Kurve“ verbunden werden.

Sie zeigen etwas anderes: Was für Coding und agentische Arbeit verfügbar war, konnte sich erheblich verbessern, während der Listenpreis konstant blieb oder sogar sank.

Zeitpunkt	Modell	Input / 1M	Output / 1M	Relevantes Coding-/Agentic-Signal
06/2024	Claude 3.5 Sonnet	$3	$15	neue Sonnet-Generation zum bestehenden Mid-Tier-Preis
10/2024	Claude 3.5 Sonnet, Update	$3	$15	SWE-bench Verified laut Anthropic von 33,4 auf 49,0 %, gleicher Preis
02/2025	Claude 3.7 Sonnet	$3	$15	63,7 % auf dem intern lauffähigen 489er-SWE-bench-Verified-Subset; 70,3 % mit zusätzlichem Test-Time Compute
05/2025	Claude Sonnet 4	$3	$15	72,7 % SWE-bench Verified im veröffentlichten Setup
09/2025	Claude Sonnet 4.5	$3	$15	77,2 % SWE-bench Verified, anderes Thinking-/Prompt-Setup
02/2026	Claude Sonnet 4.6	$3	$15	gleicher Preis; in frühen Claude-Code-Tests rund 70 % Präferenz gegenüber 4.5
04/2026	GPT-5.5	$5	$30	82,7 % Terminal-Bench 2.0
07/2026	GPT-5.6 Sol	aktuell $4	aktuell $20	88,8 % Terminal-Bench 2.1; Preisstand September 2026 ist temporär reduziert
06/2026	Claude Sonnet 5	$2	$10	Einführungspreis wurde im August 2026 dauerhaft gemacht

Anthropic startete Claude 3.5 Sonnet 2024 bei $3/$15 und hielt diesen Preis auch für mehrere Nachfolger. Das Update von Claude 3.5 Sonnet steigerte beispielsweise den von Anthropic gemeldeten SWE-bench-Verified-Wert von 33,4 auf 49,0 Prozent ohne Preissteigerung. Claude 3.7, Sonnet 4 und Sonnet 4.5 blieben ebenfalls bei $3/$15.

Die Vergleichbarkeit der jeweiligen SWE-bench-Werte ist allerdings eingeschränkt. Bei Claude 3.7 waren beispielsweise nur 489 der 500 Aufgaben auf Anthropics Infrastruktur intern lauffähig, und das High-Compute-Ergebnis nutzte parallele Versuche plus Auswahlmechanismus. Sonnet 4 wurde mit einem einfachen Zwei-Tool-Setup evaluiert; Sonnet 4.5 nutzte wiederum ein definiertes Thinking Budget und eine zusätzliche Prompt-Anweisung.

2026 wurde die Preisbewegung noch deutlicher: Sonnet 4.6 blieb bei $3/$15. Sonnet 5 startete im Juni zu $2/$10 als Einführungspreis; Anthropic erklärte diesen Preis im August 2026 anschließend für dauerhaft.

Auch bei OpenAI lässt sich keine einfache Gleichung „neuer = teurer“ formulieren. GPT-5.5 wurde mit $5 Input und $30 Output pro Million Tokens veröffentlicht. GPT-5.6 Sol liegt zum Stichtag dieses Artikels bei $4/$20, wenn auch als zeitlich begrenzte Promotion. OpenAI meldet für GPT-5.6 Sol unter anderem 88,8 Prozent auf Terminal-Bench 2.1 gegenüber 85,6 Prozent bei GPT-5.5.

Mit GPT-6 Astra springt Terminal-Bench inzwischen bereits auf Version 4.0. Dort nennt OpenAI 57,9 Prozent für Astra und 37,3 Prozent für Sol. Diese Werte sind gerade nicht mit Terminal-Bench 2.0 oder 2.1 aus älteren Veröffentlichungen als eine durchgehende historische Linie vergleichbar. Auf dem weiterhin gleich bezeichneten DeepSWE v1.1 liegen Astra und Sol in derselben aktuellen OpenAI-Auswertung mit 74,1 und 72,7 Prozent deutlich näher zusammen.

Das ist die wichtige ökonomische Lektion:

Capability kann stark steigen, während der Listenpreis konstant bleibt oder sogar sinkt.

Ein Business Case, der auf dem Preis-Leistungs-Verhältnis eines konkreten Modells von heute basiert, ist deshalb eine Momentaufnahme.

Kleine Capability-Sprünge können große agentische Effekte haben

Benchmarksteigerungen von wenigen Prozentpunkten wirken manchmal wenig spektakulär. In langen Agentic Flows kann eine kleine Verbesserung der lokalen Zuverlässigkeit jedoch einen erheblich größeren Effekt haben.

Nehmen wir als reines Gedankenmodell einen Workflow mit zehn relevanten Entscheidungen. Angenommen, jede davon würde unabhängig von den anderen mit 90 Prozent Wahrscheinlichkeit korrekt getroffen:

0,9^10 ≈ 35 %

Bei 97 Prozent wären es:

0,97^10 ≈ 74 %

Das bedeutet ausdrücklich nicht, dass reale Agenten auf diese Weise mathematisch modelliert werden können. Entscheidungen sind weder unabhängig noch gleich schwierig. Manche Fehler können später korrigiert werden, andere beeinflussen mehrere Folgeschritte gleichzeitig.

Das Modell illustriert lediglich einen Mechanismus: Je länger die Entscheidungskette, desto stärker kann sich zusätzliche Zuverlässigkeit auf die Wahrscheinlichkeit auswirken, einen Workflow ohne menschlichen Eingriff zu Ende zu bringen.

Das erklärt auch, warum sich einzelne Modellgenerationen subjektiv wie ein Quantensprung anfühlen können, obwohl ein Benchmark vielleicht nur moderat steigt. Nicht jede Verbesserung zeigt sich als spektakulär bessere einzelne Antwort. Manchmal ist der entscheidende Unterschied, dass der Agent nach dem siebten Tool Call nicht mehr vom ursprünglichen Auftrag wegdriftet.

Agentische Fähigkeiten können nichtlinear auf vergleichsweise kleine Verbesserungen der Modellzuverlässigkeit reagieren.

Und genau dann kann ein nominell teureres Modell plötzlich deutlich weniger Human Active Time benötigen.

88 Milliarden Tokens sagen erstaunlich wenig

Mein aktueller Arbeitgeber berichtete in einem Quarterly Meeting einmal stolz von ungefähr 88 Milliarden verbrauchten Tokens in einem Quartal. Das Unternehmen hat grob 1.000 Beschäftigte.

Mein erster Gedanke war: Das klingt unglaublich viel.

Der zweite war interessanter: Was bedeutet diese Zahl eigentlich?

Waren es Input Tokens? Cached Input? Output? Reasoning? Coding Agents? Andere AI-Workloads? Große Repository-Kontexte, die permanent wiederholt wurden? Hocheffiziente automatisierte Workflows? Oder teure Agent-Schleifen, die unnötig oft liefen?

Mit den aktuellen Sol- und Astra-Listenpreisen lässt sich zeigen, wie wenig die nackte Tokenzahl über die Kosten aussagt.

88 Milliarden Tokens entsprechen 88.000 Einheiten à einer Million Tokens:

Wenn alle 88 Mrd. Tokens angenommen würden als …	Grobe Kosten
Sol Cached Input zu $0,40 / 1M	$35.200
Sol Input zu $4 / 1M	$352.000
Astra Input zu $10 / 1M	$880.000
Sol Output zu $20 / 1M	$1.760.000
Astra Output zu $50 / 1M	$4.400.000

Die Berechnung nutzt die offiziellen OpenAI-Preise vom 10. September 2026.

Natürlich ist keines dieser Extrembeispiele realistisch. Ein echter Workload besteht aus einem Mix verschiedener Tokenarten, Modelle, Caching-Raten und eventuell zusätzlicher Toolkosten.

Genau deshalb ist die Tabelle nützlich.

Dieselbe Zahl von 88 Milliarden Tokens repräsentiert in diesen Grenzfällen zwischen rund 35.000 und 4,4 Millionen Dollar – einen Faktor von 125.

Und selbst wenn wir die tatsächlichen Kosten exakt kennen würden, wüssten wir noch immer nicht, ob der Einsatz wirtschaftlich war.

Tokenverbrauch ist eine Aktivitätsmetrik, keine Produktivitätsmetrik.

88 Milliarden Tokens können ein Zeichen hervorragender Automatisierung sein. Oder ein Zeichen dafür, dass sehr teure Schleifen sehr häufig laufen. Die Zahl allein unterscheidet beides nicht.

Wenn Usage zur Erfolgskennzahl wird

Viele Organisationen befinden sich noch in einer frühen Phase ihrer AI-Einführung. Entsprechend naheliegend sind Kennzahlen wie aktive AI-Nutzer, Agent Runs, generierte Codezeilen oder verbrauchte Tokens.

Diese Metriken sind nicht nutzlos. Sie beantworten Fragen über Adoption, Infrastrukturbedarf und Kostenentwicklung.

Sie sollten nur nicht mit dem Ergebnis verwechselt werden.

Usage
↓
Cost
↓
Verified Outcome
↓
Engineering Value
↓
Business Value

Wenn Tokenverbrauch zur eigentlichen Erfolgsmessung wird, entsteht sogar ein kurioser Anreiz: Ein Team, das denselben Change mit halb so vielen Tokens erzeugt, sieht in der Usage-Statistik schlechter aus als eines, das für dieselbe Arbeit doppelt so viel Inferenz verbrennt.

Hier passt Goodhart’s Law tatsächlich: Sobald eine Hilfsmetrik zum Ziel wird, kann sie ihren Informationswert verlieren.

Für ein Engineering Dashboard wären deshalb Größen wie erfolgreiche Agent Runs, Retries pro akzeptierter Änderung, Human Active Time, Review-Nacharbeit, Defect Escape Rate oder eben Cost per Accepted Change interessanter als eine reine Tokenzahl.

Erst auf dieser Ebene beginnt Usage, etwas über Produktion auszusagen.

Auch teure Inferenz kann ökonomisch sehr günstig sein

Bis hierhin könnte der falsche Eindruck entstehen, das Argument laute: AI ist teurer, als sie aussieht.

Das ist nicht die Aussage.

AI kann sogar dann wirtschaftlich hochattraktiv sein, wenn die absolute Inference-Rechnung erschreckend aussieht.

Nehmen wir eine Organisation mit 200 Entwicklern. Als einfache Modellannahme setzen wir 160 Arbeitsstunden pro Monat und Vollkosten von 75 Euro pro Entwicklerstunde an.

Damit stehen pro Quartal rechnerisch zur Verfügung:

200 Entwickler
× 160 Stunden
× 3 Monate
=
96.000 Entwicklerstunden

Was würde eine echte Produktivitätssteigerung von 10, 20 oder 30 Prozent rechnerisch bedeuten?

Produktivitätsannahme	Theoretisch freigesetzte Kapazität / Quartal	Bewertet mit 75 €/h
10 %	9.600 h	720.000 €
20 %	19.200 h	1.440.000 €
30 %	28.800 h	2.160.000 €

Auch diese Tabelle ist ausschließlich eine Modellrechnung.

Freigesetzte Kapazität ist kein Geldbetrag auf dem Bankkonto. 20 Prozent weniger Zeit für bestimmte Tätigkeiten bedeuten nicht automatisch 20 Prozent mehr Features, 20 Prozent mehr Umsatz oder 20 Prozent weniger Personal. Engpässe können an anderen Stellen liegen. Nachfrage kann begrenzt sein. Die gewonnene Zeit kann teilweise verpuffen.

Die Größenordnung zeigt trotzdem, warum eine Inference-Rechnung von mehreren hunderttausend Euro pro Quartal keineswegs automatisch „zu teuer“ sein muss.

Teure Inference kann erstaunlich billig sein, wenn sie teure menschliche Arbeitszeit tatsächlich produktiver macht.

Die entscheidende Einschränkung steckt im Wort tatsächlich.

Genau hier führt die Rechnung wieder zurück zu Accepted Changes statt Tokens.

Wall Clock ist nicht Human Active Time

Bei agentischer Arbeit kommt eine weitere Besonderheit hinzu.

Angenommen, ein Agent benötigt 20 Minuten für Analyse, Implementierung und Tests.

Sind diese 20 Minuten Kosten für den Entwickler?

Nicht zwingend.

Wenn ich währenddessen auf den Bildschirm starre und auf die Fertigstellung warte, sind Agent Time und meine gebundene Zeit fast identisch. Wenn ich dagegen eine Architekturentscheidung vorbereite, Anforderungen kläre oder Dokumentation lese, entsteht Parallelität.

Ich nutze solche Phasen inzwischen regelmäßig für Dokumentation, Architekturarbeit oder Weiterbildung rund um AI. Das ist ein realer Teil des Produktivitätseffekts, den ich persönlich bei Agentic Work erlebe.

Deshalb lohnt sich die Trennung dreier Zeitbegriffe.

Agent Time ist die Zeit, in der die Maschine selbstständig arbeitet.

Human Active Time ist die Zeit, in der der Mensch aktiv entscheiden, planen, reviewen, korrigieren oder Kontext liefern muss.

Coordination Time ist ein Teil dieser menschlichen Arbeit: Übergaben, Rückfragen, Context Switching, Synchronisation mehrerer Agents und der Wiederaufbau des eigenen mentalen Modells.

Wall Clock
├── Agent Time
└── Human Active Time
    └── davon: Coordination Time

Agent Time und Human Active Time können sich überlappen.

Die Kategorien sind also nicht einfach additiv. Während Agent Time läuft, kann gleichzeitig menschliche Arbeit an derselben oder an einer anderen Aktivität stattfinden.

Die wirtschaftlich interessante Größe ist deshalb nicht allein die Laufzeit des Agents.

Agentic Work kann nicht nur die Dauer einer Aufgabe reduzieren. Es kann menschliche Aufmerksamkeit innerhalb dieser Dauer freisetzen.

Freigesetzte Aufmerksamkeit besitzt allerdings nur dann wirtschaftlichen Wert, wenn sie tatsächlich in wertvolle Arbeit, Lernen, Planung oder andere produktive Aktivitäten fließt.

Technische Parallelisierung ist nicht menschliche Parallelisierung

Parallel laufende Agents wirken zunächst wie die perfekte Skalierungsstrategie.

Ein Agent implementiert ein Feature. Ein zweiter baut gleichzeitig E2E-Tests. Ein dritter analysiert vielleicht schon den nächsten Change.

Technisch ist das beeindruckend.

Kognitiv kann es schnell unangenehm werden.

Ich habe für mich ein relativ einfaches Prinzip: „Fokussiere dich auf eine Sache und mache sie gut.“ Das ist kein allgemeines Gesetz. Es beschreibt lediglich, wie ich komplexe Engineering-Arbeit am zuverlässigsten verarbeiten kann.

Die Kognitionsforschung unterstützt zumindest den Mechanismus dahinter. Forschung zu Task Switching unterscheidet zwischen stabiler Aufgabenfokussierung und kognitiver Flexibilität beim Wechsel zwischen Aufgaben. Reviews zu Unterbrechungen zeigen messbare Auswirkungen unter anderem auf die Wiederaufnahmezeit und die Genauigkeit einer Primäraufgabe. Daraus folgt nicht, dass Menschen „nicht multitasken können“. Es folgt aber sehr wohl, dass Wechsel und Wiederaufnahme kognitiv nicht kostenlos sind.

Für Agentic Work ist das entscheidend.

Maschinen können drei Workstreams parallel ausführen. Der Entwickler muss jedoch möglicherweise drei unterschiedliche Systemzustände, Lösungsräume und offene Entscheidungen im Kopf behalten.

Agentische Parallelität ist technisch billig. Menschliche Parallelität ist kognitiv nicht kostenlos.

Deshalb skaliert die Zahl sinnvoll parallel laufender Agents nicht automatisch mit der verfügbaren Rechenleistung.

Parallelität funktioniert besser im selben Lösungsraum

In meiner eigenen Arbeit funktioniert Parallelisierung deutlich besser, wenn die parallel laufenden Tätigkeiten dasselbe Problem umkreisen.

Zum Beispiel:

Feature
├ Implementierungs-Agent
├ E2E-Agent
├ Review-Agent
└ Mensch: Architektur und Acceptance

Alle Beteiligten bewegen sich im selben fachlichen Raum. Wenn der Implementierungs-Agent eine Entscheidung trifft, kann der Review-Agent genau diese Entscheidung prüfen. Der E2E-Agent testet denselben Flow. Ich selbst muss im Kopf nur ein Systemmodell aktiv halten.

Schwieriger wird es, wenn drei Agents gleichzeitig drei fachlich unabhängige Features verändern. Dann kann die technische Parallelität steigen, während Human Active Time und Coordination Time überproportional wachsen.

Das führt zu einer praktischen Hypothese:

Agentische Parallelität ist besonders wertvoll, wenn Maschinen unterschiedliche Teile desselben Problems bearbeiten, ohne den Menschen zu mehreren gleichzeitig offenen Systemmodellen zu zwingen.

Die optimale Agentenzahl ist damit keine reine Infrastrukturfrage. Sie hängt auch von der menschlichen Fähigkeit ab, die resultierenden Änderungen sinnvoll zu koordinieren und zu verifizieren.

Der eigentliche Invest heißt Agent Infrastructure

Wer Agentic Work nur über laufende Tokenkosten betrachtet, übersieht einen anderen wesentlichen Kostenblock: den Aufbau einer Umgebung, in der Agents zuverlässig arbeiten können.

Ich versuche inzwischen bewusst, möglichst wenig direkt in eine Agent-Implementierung einzugreifen. Mein Ziel ist nicht, jeden schlechten Agent Run manuell zu retten.

Stattdessen investiere ich lieber in Strukturen, die den nächsten Run besser machen:

• Agent Files und Skills,
• klare Architekturregeln und Modulgrenzen,
• nachvollziehbares Slicing,
• stabile Contracts,
• automatisierte Tests,
• ausführbare Architektur- und Qualitätschecks,
• nachvollziehbare Review-Regeln,
• konsistente Benennung und Projektstruktur.

Der Fokus verschiebt sich damit.

Ich schreibe weniger Implementierung direkt selbst und beschäftige mich stärker mit Architektur, Lösungsdesign, Constraints, Inspiration, Review und Agent Enablement. Selbst Tätigkeiten, die nie zu meinen Lieblingsaufgaben gehörten – Tickets sauber und vollständig auszuformulieren zum Beispiel – kann AI häufig strukturierter erledigen, als ich es spontan tun würde.

Ich behaupte nicht, Agentic Work bereits perfekt zu beherrschen. Im Gegenteil: Ein Teil meiner aktuellen Arbeit besteht gerade darin herauszufinden, wie weit sich ein gut gestalteter Flow treiben lässt.

Aber eine Veränderung wird dabei immer deutlicher: Der wichtigste Prompt ist langfristig vielleicht nicht derjenige, der den nächsten Change erzeugt. Es ist die Infrastruktur, die hundert ähnliche Changes zuverlässig macht.

Maximale Langeweile im Code

Das Ziel wiederholbarer Agent-Arbeit ist für mich nicht maximale Kreativität.

Ich möchte möglichst viel Langeweile.

Ähnliche Probleme sollen strukturell ähnliche Lösungen erzeugen. Eine neue Capability soll an der erwarteten Stelle liegen. Ein API-Zugriff soll denselben Regeln folgen wie der letzte. State Management soll nicht bei jedem Feature neu erfunden werden.

Das ist bereits für menschliche Teams wertvoll. Bei Agents wird es wirtschaftlich noch interessanter.

Denn Wiederholbarkeit reduziert nicht nur Implementierungszeit.

Sie reduziert auch Verification-Kosten.

Wenn ich ungefähr weiß, welche Struktur ein Change haben wird, kann ich ihn schneller lesen. Tests lassen sich gezielter formulieren. Architekturregeln können mechanisch geprüft werden. Überraschungen werden seltener.

Wiederholbarkeit senkt nicht nur Implementierungskosten. Sie senkt auch Verification-Kosten.

Das verändert die Kostenfunktion von Agentic Work.

Nehmen wir stark vereinfacht 10.000 Euro einmaligen Aufwand für Agent Instructions, Architekturregeln, Testinfrastruktur und Review-Automatisierung. Verteilt sich dieser Aufwand auf 20 akzeptierte Änderungen, sind das 500 Euro Vorlauf pro Change. Bei 50 Changes sind es 200 Euro. Bei 100 Changes noch 100 Euro.

Agent Files
+ Skills
+ Architecture Rules
+ Test Infrastructure
+ Review Setup
=
hoher Vorlauf

          ↓

20 Changes → 500 € / Change
50 Changes → 200 € / Change
100 Changes → 100 € / Change

Auch das ist nur ein Rechenbeispiel. Der Mechanismus entspricht aber klassischer Fixkostenökonomie: Der Vorlauf ist teuer, die Grenzkosten wiederholbarer Produktion können anschließend sinken.

Agentic Work wird wirtschaftlich besonders interessant, wenn einmalige Prompt-Arbeit zu wiederverwendbarer Produktionslogik wird.

Genau hier sehe ich langfristig mehr Potenzial als in der Frage, ob ein einzelner Prompt besonders clever formuliert war.

Local Models besitzen eine andere Kostenfunktion

Cloud-Modelle haben eine angenehm einfache Eigenschaft: Nutzung erzeugt weitgehend variable Kosten. Werden zehnmal mehr Tokens verarbeitet, steigt die Rechnung entsprechend.

Lokale Inferenz verschiebt die Kostenstruktur.

Statt laufender Providerpreise entstehen Hardwareinvestitionen, Abschreibung, Strom, Wartung, Administration und Auslastungsrisiko.

Als konkretes Beispiel eignet sich im September 2026 Qwen3.8-27B auf einer NVIDIA DGX Spark. Das offizielle Qwen-Modell ist unter Apache 2.0 veröffentlicht. NVIDIA spezifiziert für die DGX Spark 128 GB Unified Memory, 273 GB/s Speicherbandbreite, einen GB10 mit 140 Watt TDP und ein 240-Watt-Netzteil. Der aktuelle US-Listenpreis der DGX Spark liegt bei $4.699.

Für die tatsächliche Geschwindigkeit von Qwen3.8-27B auf dieser Hardware gibt es zum Stichtag keine belastbare Herstellerangabe, die ich als allgemeingültigen Throughput verwenden würde. Eine als solche gekennzeichnete Community-Messung meldet für eine NVFP4+MTP-Konfiguration bei Single-Stream Decode ungefähr 25,1 Tokens pro Sekunde. Das ist keine NVIDIA- oder Qwen-Garantie und kann je nach Runtime, Quantisierung, Kontextlänge und Konfiguration stark variieren.

Damit lässt sich trotzdem eine transparente Modellrechnung bauen.

Annahmen:

Hardware:              $4.699
Abschreibung:          3 Jahre
Arbeitstage:           220 / Jahr
Decode:                25,1 Output-Tokens/s
Stromansatz:           $0,30 / kWh
Leistung im Modell:    240 W

Die 240 Watt entsprechen dem Netzteilwert und sind hier bewusst ein konservativer Rechenansatz, keine gemessene dauerhafte Inference-Leistungsaufnahme. Administration, Wartung, Ausfallzeiten, Finanzierung, Prompt Processing und parallele Nutzer werden nicht eingerechnet. Die Rechnung betrachtet ausschließlich eine grobe Output-Token-äquivalente Kapazität. Gerade deshalb ist sie keine direkte Vollkosten-Gegenüberstellung zu einem Cloud-Output-Tarif, sondern eine Auslastungsrechnung für lokale Hardware.

Szenario	Hohe Auslastung	Niedrige Auslastung
Aktive Inferenz	8 h / Arbeitstag	1 h / Arbeitstag
Output-Kapazität / Jahr bei 25,1 tok/s	ca. 159 Mio. Tokens	ca. 19,9 Mio. Tokens
Output-Kapazität über 3 Jahre	ca. 477 Mio.	ca. 59,6 Mio.
Hardwareabschreibung / 1M Output-Tokens	ca. $9,85	ca. $78,79
Strom / 1M bei Modellannahmen	ca. $0,80	ca. $0,80
Hardware + Strom / 1M	ca. $10,65	ca. $79,59

Bei hoher Auslastung wirkt lokale Inferenz plötzlich sehr günstig. Bei niedriger Auslastung dominiert die Abschreibung.

Das ist genau der Punkt:

Lokale Inferenz ersetzt variable Cloudkosten teilweise durch Fixkosten und Auslastungsrisiko.

Ökologische Effizienz ist dabei ausdrücklich nicht Gegenstand dieses Artikels. Der Energieverbrauch wird hier ausschließlich als betriebswirtschaftliche Kostenposition betrachtet.

Local ist nicht automatisch billiger

Die Tabelle könnte zu einer falschen Schlussfolgerung führen.

Wenn Qwen lokal rechnerisch rund elf Dollar pro Million Output-Tokens kostet und Astra in der Cloud 50 Dollar, müsste Local doch automatisch günstiger sein.

Nein.

Ein Qwen-Token und ein Astra-Token sind ökonomisch nicht dasselbe Produkt.

Wenn ein kleineres lokales Modell bei derselben Änderung häufiger driftet, mehr Retries benötigt, schlechtere Tests erzeugt oder mehr Human Review bindet, kann der nominelle Tokenvorteil verschwinden.

Außerdem fehlen in der vereinfachten Local-Rechnung Administration, Upgrades, Monitoring, Ausfälle, Runtime-Tuning und die Opportunitätskosten ungenutzter Hardware.

Deshalb führt auch diese Betrachtung wieder zur gleichen Kennzahl:

Cost per Accepted Change.

Local kann bei hoher, planbarer Auslastung extrem attraktiv sein. Für einfache oder stark standardisierte Task-Klassen kann ein kleineres Modell wirtschaftlich ideal sein.

Für komplexe, seltene Aufgaben kann ein Frontier-Modell trotz deutlich höherem Tokenpreis günstiger bleiben.

Die interessante Architektur ist deshalb möglicherweise nicht „Cloud oder Local“, sondern ein Portfolio:

Routine / hohe Frequenz
→ günstiges oder lokales Modell

komplex / hohe Unsicherheit
→ Frontier-Modell

kritisch
→ zusätzliche Verification

Local als strategische Option

Lokale Modelle besitzen neben der reinen Inference-Rechnung noch zwei mögliche ökonomische Werte.

Der erste ist Geheimnisschutz. Ein lokales Modell kann die zentrale externe Model Trust Boundary entfernen. Das heißt jedoch nicht automatisch, dass der gesamte Agentic Flow lokal oder sicher ist.

Ein Agent kann weiterhin Daten an Webdienste, MCP-Server, Package Manager, Telemetriesysteme oder andere externe APIs senden.

Local Model und Local Workflow sind deshalb zwei unterschiedliche Aussagen.

Der zweite Wert ist strategische Optionalität. Wenn eine Organisation für bestimmte Task-Klassen eine lokale Alternative betreiben kann, entsteht eine Exit-Option gegenüber Providerpreisen, Quotas oder Änderungen der Produktbedingungen.

Diese Option besitzt auch dann einen Wert, wenn sie aktuell nicht der billigste Produktionsweg ist.

Der unscheinbare Workflow Lock-in

Hier steckt eine leicht ironische Entwicklung.

Am Anfang sagen Teams vielleicht:

Das AI-Abo kostet ungefähr 25 Euro im Monat. Klingt fast vernachlässigbar.

Ein paar Jahre später sind Architektur, Delivery-Prozesse, Teamgrößen, Review-Flows und Erwartungen an den Durchsatz auf permanente Inference ausgelegt.

Dann lautet die Rechnung möglicherweise:

Es kostet inzwischen deutlich mehr – aber ohne funktioniert unser aktueller Produktionsfluss nicht mehr.

Dafür braucht es keine böse Absicht eines Providers.

Es ist ein normaler ökonomischer Mechanismus: Je stärker eine Technologie in einen Produktionsprozess eingebaut ist, desto höher können die Wechselkosten werden. Agent Files, Tooling, Prompt Caches, APIs, Evaluationen und organisatorische Abläufe können zusätzlich modelspezifisch optimiert sein.

Je tiefer Agentic Work in das Produktionssystem integriert wird, desto höher können die tatsächlichen Wechselkosten werden.

Vielleicht ist deshalb langfristig nicht nur der heutige Tokenpreis interessant, sondern auch die Preiselastizität einer Organisation, deren Produktionsmodell bereits von kontinuierlicher Inference abhängt.

Consumer-Abos erzeugen eine Preisillusion

Auch Consumer-Abonnements sind für Enterprise-Kostenrechnungen nur begrenzt hilfreich.

ChatGPT Plus kostet in den USA weiterhin $20 pro Monat; lokale Preise können durch Steuern und Abrechnung abweichen. OpenAI bietet inzwischen zusätzlich Pro-Stufen zu $100 und $200 an. Laut aktueller Produktinformation umfasst Pro $100 das Fünffache und Pro $200 das Zwanzigfache des Plus-Nutzungsvolumens. API-Nutzung wird getrennt abgerechnet.

Daraus lässt sich kein garantierter „API-Gegenwert“ berechnen.

Ein Nutzer kann in einem Monat sehr wenig Inference verbrauchen. Ein Heavy User kann erheblich mehr Nutzung erzeugen. Rate Limits, Produktquoten, Caching, unterschiedliche Modelle und interne Routing-Mechanismen verändern die Kosten zusätzlich.

Auch der öffentliche API-Listenpreis ist nicht dasselbe wie der Grenzkostenpreis, zu dem ein Provider selbst Inferenz produziert.

Eine plausible Hypothese ist deshalb, dass Subscription-Produkte über Mischkalkulation funktionieren können: Einige Nutzer erzeugen gemessen am API-Listenpreis ein sehr hohes Nutzungsäquivalent, andere schöpfen ihre Quotas kaum aus, während Caching und Rate Limits die tatsächliche Kostenstruktur weiter verändern.

Über die tatsächlichen internen Margen eines Providers sagt das nichts aus.

Für eine Organisation ist die Schlussfolgerung einfacher: Ein Consumer-Abo ist kein belastbares Kostenmodell für einen Produktionsprozess.

Von der akzeptierten Änderung zur Organisation

Bis hierhin war die Betrachtung operativ.

Wie teuer ist das Modell? Wie viele Runs brauchen wir? Wie viel Human Active Time bleibt? Wie hoch ist der Review-Aufwand? Wie viele akzeptierte Änderungen entstehen?

Damit lässt sich ein erstaunlich großer Teil der kurzfristigen Agentic-Ökonomie beschreiben.

Es gibt jedoch eine zweite Bilanz.

Wenn AI dauerhaft einen größeren Teil der Ausführung übernimmt, verändert sich nicht nur die Kostenstruktur einer einzelnen Änderung. Es kann sich auch verändern, wie Menschen Erfahrung aufbauen.

Und damit landen wir bei einer wesentlich langsameren ökonomischen Variable: Human Capital.

Entry-Level-Hiring steht tatsächlich unter Druck – aber nicht nur wegen AI

Die Frage nach Junioren ist inzwischen schwer von der AI-Diskussion zu trennen.

Dabei muss man sehr vorsichtig zwischen Beobachtung und Kausalität unterscheiden.

In den USA zeigt das im August 2026 revidierte Stanford-Working-Paper „Canaries in the Coal Mine?“ auf Basis administrativer ADP-Payroll-Daten von Millionen Beschäftigten einen auffälligen Zusammenhang. Für 22- bis 25-Jährige in stark AI-exponierten Berufen liegt die Beschäftigung nach der verwendeten Vergleichsmethode rund 19 Prozent unter dem Pfad ähnlich junger Beschäftigter in weniger AI-exponierten Berufen. Bei erfahrenen Beschäftigten finden die Autoren keine vergleichbare Lücke. Besonders relevant ist: Die Anpassung zeigt sich laut Studie vor allem durch weniger Neueinstellungen, nicht durch erhöhte Entlassungen. Die Rückgänge konzentrieren sich zudem stärker auf Tätigkeiten, bei denen reale AI-Nutzung eher automatisierend als ergänzend wirkt.

Das ist ein starkes deskriptives Signal für ein interessantes Muster, aber ausdrücklich kein kausaler Nachweis einer monokausalen AI-Wirkung. Die Autoren selbst haben frühere Versionen nach zusätzlicher Kritik untersucht und eingeräumt, dass ein Teil früherer Rückgänge andere Ursachen gehabt haben dürfte; unter strengeren Kontrollen wird der zeitliche Zusammenhang erst ab 2024 klarer.

Auch andere Daten mahnen zur Vorsicht. LinkedIns Economic Graph berichtete im Februar 2026, dass sich das Entry-Level-Hiring im Software Engineering ähnlich wie der gesamte Technologiesektor und der US-Arbeitsmarkt entwickelt. LinkedIn interpretiert den damaligen SWE-Rückgang daher primär als Teil der breiteren makroökonomischen Schwäche und nicht als isolierten AI-Effekt. Gleichzeitig begannen 2023 und 2024 laut diesen Daten 55 Prozent der US-Absolventen mit Computer-Science-Abschluss ihre erste Vollzeitstelle außerhalb klassischer Software-Engineering-Rollen, gegenüber 49 Prozent im Jahr 2016.

Beides kann gleichzeitig wahr sein: Der Tech-Arbeitsmarkt kann konjunkturell schwach sein, während AI innerhalb dieses schwachen Marktes bestimmte Einstiegstätigkeiten zusätzlich unter Druck setzt.

Deutschland hat zusätzlich ein konjunkturelles IT-Problem

Für Deutschland sollte man die US-Daten nicht einfach übertragen.

Die Bundesagentur für Arbeit beschreibt für 2025 eine deutlich schwächere Nachfrage im IKT-Arbeitsmarkt. Im Jahresdurchschnitt waren rund 13.000 offene IKT-Stellen gemeldet – 22 Prozent weniger als im Vorjahr und der niedrigste Bestand seit 2015. Die berufsspezifische Arbeitslosenquote stieg von 3,7 auf 4,5 Prozent. Gleichzeitig waren weiterhin rund 1,15 Millionen Menschen sozialversicherungspflichtig in IKT-Berufen beschäftigt, zwei Prozent mehr als im Vorjahr.

Das Bild lautet also nicht „IT bricht zusammen“.

Es lautet eher: Beschäftigung wächst langfristig noch, während Neueinstellungen und offene Stellen kurzfristig deutlich schwächer geworden sind und sich die Nachfrage stärker in Richtung höher qualifizierter Spezialisten und Experten verschiebt.

Aus diesen Daten lässt sich allein kein AI-Effekt ableiten.

Für Juniors ist der Mechanismus dennoch relevant: Wenn Unternehmen in einem schwachen Markt ohnehin weniger einstellen und gleichzeitig mit Senior-plus-Agent-Konstellationen produktiver werden, fällt es wirtschaftlich leichter, eine offene Einstiegsstelle gar nicht erst entstehen zu lassen.

Der Arbeitsmarkt kann von unten schrumpfen, ohne dass Massenentlassungen stattfinden

Die öffentliche AI-Arbeitsmarktdebatte sucht häufig nach spektakulären Ereignissen.

Welche Berufsgruppe wurde ersetzt? Wie viele Menschen wurden entlassen? Wo steht die große Automatisierungswelle?

Vielleicht ist ein Teil des Effekts wesentlich unscheinbarer.

Eine Stelle, die nie ausgeschrieben wurde, erscheint in keiner Entlassungsstatistik.

Ein zusätzliches Junior-Team, das aufgrund höherer Produktivität eines bestehenden Teams nicht aufgebaut wurde, erzeugt keinen Kündigungsbrief.

Genau deshalb ist der Stanford-Befund zu Hiring statt Separations so interessant.

Die Hypothese wäre dann nicht:

AI vernichtet plötzlich den Beruf des Softwareentwicklers.

Sondern:

Ein Teil der Anpassung kann darin bestehen, dass bestimmte Einstiegsgelegenheiten gar nicht mehr entstehen.

Das ist kurzfristig für ein einzelnes Unternehmen möglicherweise vollkommen rational.

Langfristig entsteht daraus allerdings eine andere ökonomische Frage.

Senior + Agent ist kurzfristig eine sehr rationale Kombination

Ein erfahrener Entwickler bringt ein bereits aufgebautes mentales Modell mit.

Er erkennt unklare Anforderungen früher. Er kennt typische Fehlerbilder. Er kann zwischen einem hübschen Diff und einer robusten Lösung unterscheiden. Er weiß, wo zusätzliche Tests notwendig sind und wo die Komplexität einer vorgeschlagenen Architektur unverhältnismäßig ist.

Ein leistungsfähiger Agent ergänzt genau diesen Entwickler um schnelle Ausführung.

Damit entsteht eine ausgesprochen attraktive Kombination:

Erfahrung
+
hohe Generationsgeschwindigkeit
+
automatisierte Tests
+
schnelle Iterationen
=
hoher kurzfristiger Output

Aus Sicht eines Unternehmens ist die Frage „Warum sollte ich stattdessen einen Junior einstellen?“ deshalb nicht absurd.

Ein Junior benötigt Einarbeitung, Mentoring und Review. Gerade die Aufgaben, an denen Einsteiger früher produktiv mitarbeiten konnten – klar begrenzte Implementierungen, Standard-CRUD, Tests, einfache Refactorings – gehören gleichzeitig zu den Tätigkeiten, bei denen Coding Agents besonders schnell besser werden.

Man braucht dafür keine moralische Bewertung.

Kurzfristig kann Senior + Agent schlicht die ökonomisch attraktivere Einheit sein.

Das Problem beginnt erst, wenn wir ausschließlich kurzfristig rechnen.

Eine Junior-Aufgabe produziert zwei Dinge

Eine Junior-Aufgabe erzeugt mindestens zwei Outputs.

Junior Task
├ Software heute
└ Erfahrung morgen

Die erste Komponente ist offensichtlich. Es entsteht ein Endpoint, ein Formular, ein Test, eine Migration oder ein Bugfix.

Die zweite Komponente taucht in kaum einer Delivery-Metrik auf.

Der Junior lernt dabei, wie dieses System funktioniert.

Er macht einen Fehler und versteht, warum er falsch war. Er bekommt im Review erklärt, warum eine scheinbar elegante Abstraktion später problematisch wird. Er debuggt einen Produktionsfehler. Er sieht, wie eine fachliche Sonderregel eine technische Architektur beeinflusst. Mit der Zeit übernimmt er größere Teile des Systems und mehr Verantwortung.

Eine Junior-Aufgabe produziert nicht nur Software. Sie produziert Erfahrung.

Wenn AI die erste Produktion effizienter übernimmt, kann das kurzfristig hervorragend sein.

Wenn dadurch aber auch der zweite Produktionsprozess verschwindet, entsteht eine langfristige Kostenposition, die in der Tokenrechnung nicht vorkommt.

Erfahrung ist Human Capital

Erfahrung lässt sich nicht vollständig durch das Lesen von Dokumentation ersetzen.

Sie entsteht durch wiederholte Konfrontation mit realen Systemen:

Implementieren
→ Fehler machen
→ Debuggen
→ Review erhalten
→ Produktion erleben
→ Entscheidungen treffen
→ Verantwortung übernehmen
→ Systemverständnis aufbauen

Das bedeutet nicht, dass Juniors zehn Jahre lang manuell CRUD-Code schreiben müssen, damit sie irgendwann „richtige Entwickler“ werden.

Eine solche Vorstellung wäre eher ein Argument gegen Fortschritt.

Wenn AI Routinearbeit übernimmt, muss die Ausbildung nicht künstlich ineffizient gehalten werden. Die interessantere Frage lautet:

Wie bauen Menschen systemisches Engineering Judgment auf, wenn ein wachsender Teil der früheren Übungsfläche automatisiert wird?

Vielleicht können Agents dabei sogar helfen. Sie können Code erklären, Alternativen demonstrieren, Reviews simulieren und Lernschleifen beschleunigen.

Aber das passiert nicht automatisch dadurch, dass der Agent die Aufgabe vollständig übernimmt.

Ein Unternehmen kann Erfahrung kaufen – ein Markt muss sie aufbauen

Hier liegt für mich eine der spannendsten langfristigen Fragen der Agentic-Ökonomie.

Ein einzelnes Unternehmen kann sagen:

Wir brauchen keine Juniors. Wir stellen erfahrene Entwickler ein.

Das kann völlig rational sein.

Das nächste Unternehmen kann dieselbe Entscheidung treffen.

Und das nächste ebenfalls.

Irgendwann entsteht ein Koordinationsproblem.

Ein Unternehmen kann Erfahrung einkaufen. Ein Arbeitsmarkt kann Erfahrung nur aufbauen.

Wer einen Senior einstellt, kauft das Ergebnis jahrelanger Investitionen: Ausbildung, Mentoring, Projekte, Fehler, Reviews und Verantwortung – häufig finanziert von anderen Unternehmen.

Wenn viele Organisationen gleichzeitig weniger Juniors einstellen, weniger Midlevels entwickeln und überwiegend fertige Erfahrung einkaufen möchten, könnte der Arbeitsmarkt langfristig weniger Erfahrung produzieren.

Das ist ausdrücklich eine Hypothese, keine Vorhersage, dass es 2036 plötzlich keine Seniors mehr geben wird.

Märkte reagieren. Ausbildungsmodelle verändern sich. Neue Rollen entstehen. AI kann selbst zum Lernwerkzeug werden.

Die ökonomische Frage bleibt trotzdem bestehen:

Wer ausschließlich fertige Erfahrung einkaufen will, ist darauf angewiesen, dass jemand anderes sie zuvor finanziert hat.

Das ist klassische Human-Capital-Ökonomie – nur unter neuen technologischen Bedingungen.

Fluktuation macht Kompetenzaufbau nicht sinnlos

Gegen Investitionen in Nachwuchs wird häufig eingewandt, dass Beschäftigte ohnehin das Unternehmen wechseln.

Das ist richtig und gleichzeitig kein überzeugendes Gegenargument.

Als grobe Orientierung weist das US Bureau of Labor Statistics für Januar 2024 in Computer- und Mathematikberufen eine Median-Tenure beim aktuellen Arbeitgeber von 4,3 Jahren aus. Das ist keine weltweite Softwareentwickler-Fluktuationsrate und sagt nichts über Remote versus Office aus. Es zeigt lediglich, dass mehrjährige Betriebszugehörigkeit keineswegs ungewöhnlich ist, aber auch keine lebenslange Bindung erwartet werden kann.

Auch Arbeitsbedingungen beeinflussen Retention. Ein peer-reviewtes Nature-RCT mit 1.612 Beschäftigten eines chinesischen Technologieunternehmens fand bei zwei Homeoffice-Tagen pro Woche eine um rund ein Drittel niedrigere Kündigungsrate ohne messbare Verschlechterung von Performance oder Beförderungen. Das ist ein starkes Ergebnis für dieses konkrete Setting, aber ebenfalls keine universelle „Remote-Mitarbeiter bleiben X Jahre“-Formel.

Menschen wechseln Unternehmen.

Trotzdem entstehen während ihrer Beschäftigung Domänenwissen, Systemkenntnis, Beziehungen und Produktivität.

Fluktuation ist kein Argument gegen Kompetenzaufbau. Sie ist ein Grund, warum Organisationen Kompetenz kontinuierlich reproduzieren müssen.

Eine Firma, die Erfahrung ausschließlich extern einkauft, macht sich von einem Markt abhängig, dessen Angebotsseite sie selbst nicht mitentwickelt.

Nachwuchsarbeit ist eine Investition, keine Wohltätigkeit

Deshalb sollte die Junior-Frage auch nicht primär moralisch formuliert werden.

„Unternehmen haben eine soziale Verpflichtung, Juniors einzustellen“ ist ein anderes Argument.

Aus wirtschaftlicher Sicht reicht bereits:

Nachwuchsarbeit ist eine Investition in zukünftige Capability.

Diese Investition erzeugt firmenspezifisches Wissen, Domänenverständnis, technische Nachfolge, Teambeziehungen und eine interne Pipeline für Verantwortung.

Natürlich kann ein ausgebildeter Mitarbeiter gehen.

Eine Datenbank kann ebenfalls migriert, ein Server abgeschrieben und eine Plattform ersetzt werden. Investitionen besitzen nie zwangsläufig ewigen Nutzen.

Die relevante Frage ist, ob der erwartete Nutzen über die Zeit höher ist als die Investition.

Und genau diese Rechnung verändert sich durch Agentic Work: Der direkte Produktionswert einfacher Junior-Aufgaben könnte sinken, während ihr Ausbildungswert bestehen bleibt.

Damit muss Ausbildung expliziter als bisher Teil des Produktionssystems werden.

Ausbildung muss sich verändern

Es wäre wenig sinnvoll, auf AI mit dem Ruf nach „mehr traditionellem Coding“ zu reagieren.

Wenn Agents Code zuverlässig erzeugen können, sollten Menschen lernen, mit dieser Realität produktiv umzugehen.

Das bedeutet aber auch mehr als einen zusätzlichen Kurs „Prompt Engineering“.

Systematische Reviews zur GenAI-Nutzung in der Programmierausbildung zeichnen ein gemischtes Bild. AI kann Lernleistung, Feedback und Problemlösung unterstützen. Gleichzeitig treten Risiken durch Übervertrauen, fehlerhafte Ausgaben und Unterschiede in der Fähigkeit auf, generierte Lösungen überhaupt zu verifizieren. Eine 2025 veröffentlichte Review von 40 empirischen Studien betont deshalb die Bedeutung bewusster didaktischer Integration und geeigneter Assessments. Eine im September 2026 veröffentlichte Heliyon-Review über 76 empirische Studien kommt ähnlich zu dem Schluss, dass AI besonders dann nützlich ist, wenn sie mit Scaffolding, prozessorientiertem Feedback und menschlichem Judgment kombiniert wird.

Für Software Engineering könnte das bedeuten, Ausbildung stärker auf Fähigkeiten auszurichten, die entlang des gesamten Produktionsflusses benötigt werden: Problemverständnis, Requirements, Systemmodelle, Architektur, Debugging, Review, Trade-offs, Security Awareness, Verifikation und End-to-End-Verantwortung.

Coding verschwindet dabei nicht.

Wer Code nicht lesen kann, kann ihn schlecht reviewen. Wer nie erlebt hat, warum bestimmte Implementierungen scheitern, besitzt wenig Grundlage für Engineering Judgment.

Aber die Gewichtung kann sich verschieben.

Ich sehe diese Lücke auch in meinem privaten Umfeld. Ein Familienmitglied erhielt in einem Semesterprojekt sehr positives Feedback für die Architekturstruktur einer Software. Das dafür notwendige Architekturverständnis entstand allerdings nicht primär aus dem Studium, sondern zu einem erheblichen Teil aus informellem Austausch über Architektur.

Das ist eine persönliche Anekdote und kein Beleg für die Qualität irgendeines Studiengangs.

Sie illustriert für mich lediglich die Frage: Wenn technische Ausführung immer leichter verfügbar wird, wie systematisch lehren wir dann eigentlich die Fähigkeit, gute Systeme zu erkennen und zu gestalten?

Vom Spezialisten zum End-to-End-Verständnis

Eine mögliche positive Entwicklung von Agentic Work ist, dass Entwickler wieder breiter entlang eines vollständigen Flows arbeiten können.

DB
→ Service
→ API
→ Client
→ View

Das bedeutet nicht, dass jeder Frontend-Entwickler plötzlich Datenbank-, Backend-, Netzwerk-, Security- und UX-Spezialist sein muss.

Agents können einen Teil der technologischen Ausführung übernehmen.

Entscheidend wird dann stärker das Meta-Modell.

Ein Frontend-Entwickler muss einen CQRS-orientierten oder hexagonalen Microservice vielleicht nicht selbst in derselben Tiefe implementieren können wie ein Backend-Spezialist. Wenn er mit einem Agent daran arbeitet, sollte er aber erkennen können, welche Verantwortlichkeiten die Schichten besitzen, wo Domain Logic hingehört, wie der Contract funktioniert und ob der erzeugte Code strukturell plausibel ist.

Dasselbe gilt in die andere Richtung.

Agentic Work kann damit End-to-End-Verantwortung verbreitern, ohne Expertenwissen abzuschaffen.

Gerade Security, Kryptographie oder hochkritische Fachdomänen sind schlechte Kandidaten für die Vorstellung, ein Generalist könne mit genügend AI-Unterstützung plötzlich jede Tiefe ersetzen.

Agentic Work kann technische Ausführung verbreitern, ohne tiefes Expertenwissen überflüssig zu machen.

Vielleicht besteht ein starkes zukünftiges Team gerade aus Menschen, die ein breites Systemmodell besitzen, und Spezialisten, die an den Stellen echte Tiefe liefern, an denen sie wirtschaftlich oder sicherheitstechnisch notwendig ist.

Software Engineering verschiebt sich

Ich versuche momentan bewusst, möglichst wenig Code selbst zu schreiben. Nicht, weil ich Coding für wertlos halte, sondern weil ich wissen möchte, wie weit ein gut gestalteter Agentic Flow tatsächlich gehen kann.

Das verändert meine eigene Arbeit bereits deutlich. Weniger Zeit fließt in direkte Codeproduktion. Mehr Zeit geht in Architektur, Lösungsdesign, Constraints, Reviews, Agent Infrastructure und Systemverständnis. Das empfinde ich nicht als Rückzug aus Software Engineering, eher als Verschiebung innerhalb davon.

Der Agent implementiert vielleicht die Methode. Ich versuche stärker dafür zu sorgen, dass er überhaupt nur in einem Raum arbeiten kann, in dem sinnvolle Lösungen wahrscheinlich sind. Dazu gehören klare Modulgrenzen, Tests, Architekturregeln und mechanische Checks. Dazu gehört aber auch die Fähigkeit, zu erkennen, wann die automatisch erzeugte Lösung zwar grün baut, aber trotzdem die falsche Abstraktion besitzt.

Ich halte Agentic Work inzwischen für ein außerordentlich mächtiges Werkzeug. Ich würde gleichzeitig nicht behaupten, es bereits perfekt zu beherrschen. Gerade deshalb fällt mir der Unterschied zwischen zwei Arbeitsweisen immer stärker auf: AI als schnelleres Autocomplete ist etwas anderes als ein Engineering-System, in dem Agents eigenständig analysieren, implementieren, testen und reviewen können. Der zweite Ansatz benötigt deutlich mehr Vorlauf. Er eröffnet aber auch eine völlig andere Kostenstruktur.

Zwei ökonomische Bilanzen

Damit landen wir am Ende bei zwei getrennten, aber miteinander verbundenen Bilanzen.

Die operative Bilanz haben wir als Cost per Accepted Change entwickelt: Sie umfasst den gesamten Aufwand bis zur verifizierten, akzeptierten Änderung. Die zweite Bilanz ist strategisch. Sie fragt:

Welche Fähigkeiten besitzt die Organisation nach dieser Änderung – und welche baut sie für die Zukunft auf?

Dort stehen Agent Infrastructure, Systemverständnis, Domänenwissen, Nachwuchsentwicklung, Expertenwissen und die Fähigkeit, Kompetenz kontinuierlich zu reproduzieren.

Diese zweite Bilanz macht die erste nicht weniger wichtig.

Ein Unternehmen muss kurzfristig wirtschaftlich arbeiten. Ein Agentic Flow, der keinen messbaren Nutzen erzeugt, wird nicht dadurch sinnvoll, dass er angeblich langfristig strategisch wichtig sein könnte.

Umgekehrt kann eine Quartalsrechnung aber ebenfalls unvollständig sein, wenn sie jeden weggefallenen Junior-Task als reine Effizienzsteigerung bewertet und den Aufbau zukünftiger Erfahrung mit null ansetzt.

Die interessante Ökonomie von Agentic Work liegt genau zwischen diesen Zeithorizonten.

Token
↓
Agent Run
↓
Successful Run
↓
Accepted Change
↓
Engineering Capability
↓
Business Value
↓
Future Capability

Modelle werden weiter billiger, teurer und wieder billiger werden. Capability wird steigen. Manche Aufgaben werden beinahe vollständig automatisierbar. Andere werden sich als überraschend widerstandsfähig erweisen. Neue Arbeitsformen werden entstehen, und einige der heutigen Diskussionen über Tokenpreise werden rückblickend wahrscheinlich so relevant wirken wie frühere Debatten über den Preis einzelner Gigabyte Cloud-Speicher.

Der ökonomische Mechanismus bleibt trotzdem bestehen.

Codegeneration ist nur ein Produktionsschritt. Tokenverbrauch ist nur eine Aktivitätsgröße. Inference-Kosten sind nur eine Kostenposition. Eine akzeptierte Änderung ist noch kein Business Value.

Und kurzfristige Produktivität ist nicht die einzige Capability, die eine Engineering-Organisation produzieren muss.

Agentic Work kann enorm wirtschaftlich sein. Meine eigene Erfahrung spricht klar dafür, dass bereits heutige Systeme erhebliche Produktivitätsgewinne ermöglichen. Die empirische Forschung zeigt gleichzeitig, dass die Größenordnung stark vom Kontext abhängt und dass hohe lokale Beschleunigungen entlang des vollständigen Produktionssystems deutlich kleiner werden können.

Deshalb ist die richtige Schlussfolgerung weder:

AI macht Softwareentwicklung extrem billig.

noch:

AI ist in Wahrheit zu teuer.

Die interessantere Aussage ist nüchterner:

Die Ökonomie von Agentic Work entsteht erst im Gesamtsystem aus Modellkosten, Verifikation, menschlicher Aufmerksamkeit, wiederverwendbarer Infrastruktur und langfristigem Kompetenzaufbau.

Operativ sollten wir fragen:

Was kostet uns eine verifizierte, akzeptierte Änderung?

Strategisch sollten wir zusätzlich fragen:

Welche Capability bauen wir dabei auf – und welche bauen wir möglicherweise ab?

Code wird billiger. Software Engineering nicht automatisch.

Wer die Ökonomie von Agentic Work verstehen will, muss deshalb weiter rechnen als bis zum Tokenpreis.

Der Token steht auf der Rechnung. Der Wert – und manche der langfristigen Kosten – stehen woanders.

Quellen und Einordnung

Die konkreten Preis- und Produktangaben dieses Artikels sind eine Momentaufnahme vom 10. September 2026. Gerade Modellpreise, Produktnamen, Nutzungslimits und Benchmarks ändern sich schnell. Die ökonomischen Rechenmodelle sollen deshalb auch dann lesbar bleiben, wenn einzelne Zahlen später veraltet sind.

OpenAI – ChatGPT Rate Card / tokenbasierte Preise.
Aktuelle Preise für GPT-5.6 Sol, GPT-6 Astra und weitere Modelle sowie Hinweise zu Long Context, Fast Mode und regionaler Verarbeitung.
https://help.openai.com/en/articles/20001415

OpenAI – GPT-5.6 Sol.
Modellpreis, Promotionstarif, Kontextfenster sowie aktuelle Coding-Evaluierungen und Hinweise zur Effizienz.
https://developers.openai.com/api/docs/models/gpt-5.6-sol
https://openai.com/index/gpt-5-6/

OpenAI – GPT-6 Astra.
Aktueller Preis sowie Coding- und Agentic-Evaluierungen. Wichtig: Terminal-Bench 4.0 ist nicht als direkte historische Fortsetzung älterer Terminal-Bench-Versionen zu lesen.
https://developers.openai.com/api/docs/models/gpt-6-astra
https://openai.com/index/gpt-6-astra/

OpenAI – Tokens verstehen und zählen.
Reasoning Tokens sind nicht als Antworttext sichtbar, zählen aber zur Output-Nutzung und werden als Output Tokens abgerechnet.
https://help.openai.com/en/articles/4936856-w

Anthropic – Claude 3.5 Sonnet, Claude 3.7 Sonnet, Sonnet 4.5, Sonnet 4.6 und Sonnet 5.
Primärquellen für die im historischen Vergleich verwendeten Preise und Coding-Evaluierungen. Die jeweiligen SWE-bench-Ergebnisse unterscheiden sich teilweise in Harness, Prompting, Thinking Budget und Test-Time Compute und werden deshalb im Artikel nicht als einheitliche Zeitreihe interpretiert.
https://www.anthropic.com/news/3-5-models-and-computer-use
https://www.anthropic.com/news/claude-3-7-sonnet
https://www.anthropic.com/news/claude-sonnet-4-5
https://www.anthropic.com/news/claude-sonnet-4-6
https://www.anthropic.com/news/claude-sonnet-5

Peng et al. – “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot”.
Randomisiertes Experiment mit einer klar abgegrenzten JavaScript-Aufgabe; die Copilot-Gruppe schloss die Aufgabe 55,8 Prozent schneller ab.
https://arxiv.org/abs/2302.06590

Cui et al. – “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”.
Drei randomisierte Feldexperimente mit insgesamt 4.867 Entwicklern; gepoolte Schätzung von 26,08 Prozent mehr abgeschlossenen Aufgaben. 2026 in Management Science erschienen.
https://doi.org/10.1287/mnsc.2025.00535

Demirer, Musolff, Yang – “Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools”.
NBER Working Paper 35275, im September 2026 revidiert. Die aktuelle Fassung verwendet Daten von mehr als 500.000 GitHub-Entwicklern und berichtet für autonome Coding Agents eine starke Abschwächung vom Commit-Level bis zu tatsächlichen Releases. Working Paper, kein endgültiger kausaler Konsens.
https://www.nber.org/papers/w35275

METR – Developer Productivity Studies.
Das frühe 2025er RCT mit 16 erfahrenen Open-Source-Entwicklern und 246 Tasks fand eine Verlangsamung von 19 Prozent. METR bezeichnet dieses Ergebnis inzwischen selbst als historischen Snapshot. Die 2026er Folgestudie deutete eher auf Beschleunigung hin, war aber wegen Selektions- und Messproblemen nicht zuverlässig genug für eine präzise Effektgröße.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
https://metr.org/blog/2026-02-24-uplift-update/

Stanford Digital Economy Lab – “Canaries in the Coal Mine?”.
Revidierte August-2026-Fassung auf Basis von ADP-Payroll-Daten. Bei 22- bis 25-Jährigen in stark AI-exponierten Berufen liegt die Beschäftigung relativ zu weniger exponierten Peers deutlich niedriger; der Unterschied entsteht vor allem durch geringeres Hiring. Die Autoren bezeichnen die Ergebnisse ausdrücklich als deskriptive Frühindikatoren, nicht als kausale AI-Schätzung.
https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/

LinkedIn Economic Graph – U.S. Software Engineer Talent Landscape / February 2026.
Einordnung des schwachen US-SWE-Hirings und der schwächeren direkten Pipeline von CS-Absolventen in klassische Software-Engineering-Rollen.
https://economicgraph.linkedin.com/content/dam/me/economicgraph/en-us/PDF/us-software-engineer-talent-landscape-2026.pdf

Bundesagentur für Arbeit – Arbeitsmarkt IKT 2025.
Rund 13.000 gemeldete IKT-Stellen im Jahresbestand, 22 Prozent weniger als im Vorjahr; Arbeitslosenquote 4,5 Prozent; gleichzeitig weiterhin 1,15 Millionen sozialversicherungspflichtig Beschäftigte in IKT-Berufen.
https://www.arbeitsagentur.de/presse/2026-24-arbeitsmarkt-in-der-informations-und-kommunikationstechnik-ikt-im-spannungsfeld-konjunkturelle-schwaeche-trifft-auf-strukturellen-wandel

U.S. Bureau of Labor Statistics – Employee Tenure 2024.
Median von 4,3 Jahren beim aktuellen Arbeitgeber für “Computer and mathematical occupations”; keine spezifische Softwareentwickler- oder Remote-Tenure-Kennzahl.
https://www.bls.gov/news.release/tenure.t06.htm

Bloom et al. – “Hybrid working from home improves retention without damaging performance”.
Randomisiertes Experiment mit 1.612 Beschäftigten von Trip.com; zwei Homeoffice-Tage pro Woche reduzierten die Kündigungsrate im Experiment um rund ein Drittel.
https://doi.org/10.1038/s41586-024-07500-2

Nathaniel et al. – “Literature Review on the Integration of Generative AI in Programming Education”.
Systematische Review von 40 empirischen Arbeiten zur GenAI-Integration in der Programmierausbildung.
https://doi.org/10.1007/s40593-025-00524-3

“Artificial intelligence in programming education: A systematic review …”, Heliyon 2026.
Systematische Review von 76 empirischen Studien zu AI in der Programmierausbildung.
https://doi.org/10.1016/j.heliyon.2026.e45361

Qwen – Qwen3.8-27B.
Offizielle Modellgewichte, Apache-2.0-Lizenz und Modellinformationen.
https://huggingface.co/Qwen/Qwen3.8-27B

NVIDIA – DGX Spark.
Offizielle Hardwaredaten: 128 GB Unified Memory, 273 GB/s Speicherbandbreite, 140 W GB10 TDP und 240-W-Netzteil. NVIDIA erhöhte den MSRP im Februar 2026 auf $4.699.
https://www.nvidia.com/en-us/products/workstations/dgx-spark/
https://forums.developer.nvidia.com/t/2-23-2026-price-change-announcement/361713

Qwen3.8-27B auf DGX Spark – Community-Benchmark.
Die im Rechenbeispiel verwendeten 25,1 tok/s sind eine gekennzeichnete Community-Messung für NVFP4 + MTP und keine Herstellerzusage. Andere Laufzeitkonfigurationen können deutlich andere Werte liefern.
https://axforge.ai/benchmarks/qwen-3-8-dgx-spark/

OpenAI – ChatGPT Pro tiers.
Aktuelle US-Produktstaffelung: Pro $100 mit 5× und Pro $200 mit 20× Nutzung gegenüber Plus. Diese Kontingente sind keine garantierte API-Tokenmenge.
https://help.openai.com/en/articles/9793128

Stephen Monsell – Task switching (2003); Simon Y. W. Li, Farah Magrabi und Enrico Coiera – A systematic review of the psychological literature on interruption and its patient safety implications (2012).
Übersichtsarbeiten zu Aufgabenwechseln und Unterbrechungen, unter anderem zu Wechselkosten, Wiederaufnahmezeit und Fehlern. Sie stützen den begrenzten kognitiven Mechanismus im Artikel, keine konkrete Produktivitätsschätzung für Coding Agents. Task switching; Review zu Unterbrechungen.