Dark Factory Gap: Was passiert mit Teams, Rollen und Organisationen

In Teil 1 dieser Serie haben wir das Warum durchgearbeitet: Shapiros fünf Stufen der KI-Entwicklung, Brynjolfssons J-Kurve, und die Kernthese, dass AI-Tools allein keine Produktivität bringen — Workflow-Redesign schon. In Teil 2 haben wir das Wie aufgedröselt: Spec-Driven Development, Digital Twin Universe, Scenarios als Holdout-Set. StrongDM als Referenzimplementierung — drei Personen, drei Markdown-Dateien, zehntausende Zeilen produktiver Code.

Jetzt kommt das Wer. Was passiert mit den Menschen darin? Mit den Rollen, die wir kennen? Mit den Teams und Organisationen, die diese Transformation durchleben sollen?

Das ist die Frage, die in vielen AI-Adoption-Diskussionen ausgespart wird. Nicht weil niemand die Antwort kennt — sondern weil die Antwort unbequem komplex ist. Keine einfachen Botschaften ("AI macht alle Entwickler arbeitslos") und keine beruhigenden ("KI schafft mehr Jobs als sie vernichtet"). Was ich sehe, ist differenzierter — und für den DACH-Raum gibt es bemerkenswert gute Gründe, die Ausgangslage nüchtern, aber nicht pessimistisch zu sehen.

Die Rolle wird neu geschrieben

Vom Individual Contributor zum PM-Developer

McKinsey beschreibt in der November-2025-Analyse¹ ein neues Rollenbild und zitiert Cursor-CEO Michael Truell: ICs, die ein "junior team of asynchronous agents" dirigieren — eine Mischung aus Engineering Manager und Individual Contributor. Ich nenne diese Rolle "PM-Developer": jemand, der nicht mehr primär Code schreibt, sondern Agenten orchestriert. Das ist kein Futuristensatz — das ist eine Beschreibung eines Übergangs, der in frühen Teams bereits sichtbar wird.

Was bedeutet das konkret? Level 4 in Shapiros Framework — der "Robotaxi-Modus", bei dem Entwickler tagsüber Specs schreiben und abends auf fertigen Code stoßen — erfordert eine Rollendefinition, die der klassische "Individual Contributor" nicht erfüllt. Wer Code schreibt, muss nicht die Fähigkeit haben, Anforderungen so zu formulieren, dass eine Maschine sie zuverlässig umsetzt. Beides sind gute Software-Skills — aber sie sind nicht identisch.

InfoQ beschrieb Spec-Driven Development im Januar 2026² als "an architectural pattern that inverts the traditional source of truth by elevating executable specifications above code itself." GitHub hat sein offenes Spec Kit veröffentlicht³, Googles Antigravity-Projekt⁴ ist darum herum gebaut. Das Muster konvergiert: Der Code ist nicht mehr das Primärprodukt. Die Spec ist es. Und die Spec zu schreiben ist eine andere Fähigkeit als Code zu schreiben — näher am Product Management, näher am Domain Engineering, näher am, ja, Pflichtenheft-Denken, das in der DACH-Ingenieurskultur tief verankert ist.

CIO.com formulierte es kürzlich pointiert: "The agile team now consists mainly of humans who all share one basic role: Specifying what AI agents should do." Das klingt nach einer Vereinfachung — und ist trotzdem nicht ganz falsch. Die Diversifizierung der Rollen auf Level 4 ist real: Spec-Writer, Agent-Orchestrator, Quality-Validator, Domain-Expert. Aber alle teilen die Grundaufgabe, Maschinen verständlich zu sagen, was erwartet wird.

Die Mehrheit, die noch nichts geändert hat

Eine Einordnung, die ich für wichtig halte: Die meisten Unternehmen haben ihre Rollen und Prozesse trotz AI-Tools noch nicht verändert. Das ist kein Versagen — das ist eine rationale Reaktion auf unklare Signale. Wer Copilot auf den bestehenden Prozess drauflegt und "läuft" sagt, hat keine Lüge erzählt. Der Tool läuft wirklich. Dass der Prozess darunter unverändert geblieben ist, macht die kurzfristige Entscheidung nicht falsch — nur suboptimal mittel- bis langfristig.

McKinseys Analyse "Unlocking the value of AI in software development"¹ (November 2025) quantifiziert den Unterschied: 15 Prozentpunkte Leistungsgap zwischen den AI-Effektivsten und den AI-Schwächsten unter den untersuchten Softwareorganisationen. McKinsey beschreibt das führende Merkmal der stärkeren Seite explizit: Fokus auf "structured communication of specs" und "problem framing and intent specification." Nicht auf Tool-Auswahl. Auf die Fähigkeit, Anforderungen präzise zu formulieren.

Diese Unternehmen haben Zeit — aber nicht unbegrenzt. Der Konkurrenzdruck kommt nicht von einer abstrakten Technologieentwicklung, sondern von konkreten Organisationen, die die Transition bereits durchlaufen.

Die Junior-Pipeline-Krise

Das ist das Thema, das mich am meisten beschäftigt. Nicht weil es dramatischer ist als andere — sondern weil die Konsequenzen am langsamsten sichtbar werden und deshalb am meisten unterschätzt werden.

Was die Daten zeigen

Eine Studie von Hosseini Maasoum und Lichtinger⁵ (Harvard, August 2025, SSRN 5425555) hat den US-Arbeitsmarkt für Softwareentwicklung mit einer Differenz-in-Differenzen-Methodik analysiert: In AI-adoptierenden Unternehmen sank die Junior-Beschäftigung relativ zu nicht-adoptierenden Unternehmen um 7,7% innerhalb von sechs Quartalen ab Q1 2023. Wichtiges Caveat der Autoren: Der Junior-Hiring-Einbruch begann bereits 2022 — parallel zu den Fed-Zinserhöhungen, also vor der breiten AI-Adoption. Die Kausalität ist nicht sauber zu trennen. Was die Studie zeigt: Bestehende Juniors wurden nicht entlassen — Beförderungen stiegen sogar. Was fiel, war die Einstellungsrate für neue Juniors.

Das bestätigt andere Daten. ISE-Zahlen, berichtet u. a. von The Register⁶, zeigen für 2024 einen Rückgang der Tech-Graduate-Stellen um 46%, mit weiterer Projektion von 53% bis 2026. High Fliers Research⁷ verzeichnet für die 100 größten UK-Arbeitgeber insgesamt einen Rückgang von 14,6% — der stärkste Einbruch seit der Finanzkrise 2009. Verschiedene Analysen von Indeed- und FRED-Daten⁸ zeigen, dass Software-Developer-Stellenausschreibungen in den USA seit dem Peak 2022 um rund 67-70% unter dem Höchststand liegen (die genaue Zahl variiert je nach Abgrenzung und Zeitraum). Brynjolfsson, Chandar und Chen messen in "Canaries in the Coal Mine"⁹ (November 2025) einen methodisch strenger eingegrenzten 13% relativen Rückgang für die Altersgruppe 22-25.

Die meisten dieser Studien stammen aus dem US- und UK-Markt. Eine vergleichbare Differenz-in-Differenzen-Analyse fehlt für den DACH-Raum. Aber die Richtung ist auch hier sichtbar: Indeed Hiring Lab Deutschland¹⁰ zeigt einen deutlichen Rückgang bei Junior-Softwareentwickler-Stellenausschreibungen seit 2020 — bei gleichzeitig wesentlich geringerem Rückgang für Senior-Positionen. Die Schere zwischen Junior- und Senior-Nachfrage öffnet sich auch in Deutschland signifikant.

Molly Kinder von der Brookings Institution¹¹ formulierte im Januar 2026 das Problem scharf: "To save entry-level jobs from AI, look to the medical residency model." Dario Amodei (Anthropic) und Demis Hassabis (Google DeepMind) haben auf dem Weltwirtschaftsforum in Davos 2026¹² beide unabhängig voneinander vor dem AI-Einfluss auf Entry-Level-Jobs gewarnt. Das ist nicht die übliche Unternehmenskommunikation.

Das eigentliche Risiko: Scaffolding-Kollaps

Was hier auf dem Spiel steht, ist nicht nur billiges Arbeitsvermögen. Junior-Entwickler sind das Wissenstransfersystem der Branche.

Man tritt als Junior ein. Man erledigt Aufgaben, die Seniors zu teuer sind — Boilerplate, einfache Bugfixes, Dokumentation. Dabei lernt man das System, die Konventionen, die historischen Entscheidungen. Aus Juniors werden Mids, aus Mids Seniors. Die nächste Generation von Junior-Mentorinnen und Senior-Architektinnen kommt aus den Junior-Kohorten von heute.

Wenn die Junior-Pipeline einbricht, wird das in drei bis fünf Jahren bei den Seniors sichtbar. Nicht als Entlassungswelle, sondern als Erfahrungslücke. Organisationen, die heute nicht mehr ausbilden, werden in fünf Jahren Seniors suchen, die keine Juniors mehr trainiert haben.

Die Harvard-Studie⁵ zeigt, dass bestehende Juniors tatsächlich schneller befördert werden — das klingt gut. Aber Beschleunigung ohne Mentoring-Tiefe ist ein anderes Risiko: Titel ohne proportionale Erfahrung. Das ist keine Spekulation — das ist der logische Folgeprozess aus "weniger Juniors im System, gleiche Senior-Nachfrage."

Dazu kommt ein Befund des ZEW Mannheim¹³ (Schlenker und Brüll, 2025): Über 60% der Beschäftigten in Deutschland nutzen bereits AI am Arbeitsplatz — auch in Unternehmen ohne formale AI-Einführung, als sogenannte "Shadow AI Usage." Die logische Konsequenz daraus — und hier verlasse ich den empirischen ZEW-Befund und ziehe eine eigene Schlussfolgerung — ist eine wachsende "Verifikationslast": Wenn AI-generierter Code zur Norm wird, verschiebt sich die Kernaufgabe vom Schreiben zum kritischen Prüfen. Firmen brauchen Entwickler, die als skeptische Editoren agieren. Das setzt aber genau die Erfahrungstiefe voraus, die Juniors per Definition noch nicht haben. Die Anforderung verschiebt sich von "Code schreiben" zu "AI-Output verifizieren" — und das bevorzugt systematisch Seniors.

Der medizinische Residency-Begriff von Kinder ist präzise: Ein System, das Fachkräfte nicht durch strukturierte, betreute Praxis ausbildet, produziert keine Fachkräfte. Es kauft sie — und wenn der Markt enger wird, steigen die Preise oder die Qualität sinkt.

Bitkom und die DACH-Spezifik

In Deutschland hat Bitkom¹⁴ 2025 in einer Studie mit 855 Unternehmen rund 109.000 unbesetzte IT-Stellen gemessen — ein Rückgang gegenüber dem Rekord von 149.000 im Jahr 2023. Der Rückgang ist laut Bitkom kein Anzeichen verbesserter Lage, sondern ein Einstellungsstopp-Effekt. Entscheidend: Der Großteil dieser offenen Stellen richtet sich an erfahrene Fachkräfte — Experten und Spezialisten, nicht an Berufseinsteiger. Der Hays Fachkräfte-Index Q4 2024 bestätigt die Tendenz: spezialisierte IT-Segmente bleiben nachfrageresistent, während die allgemeine IT-Nachfrage zurückgeht — ein Muster, das Junior-Profile überproportional trifft. Gleichzeitig: 27% der befragten Unternehmen erwarten, dass AI Köpfe reduziert; 42% erwarten, dass AI zusätzliche IT-Nachfrage erzeugt. Beide Dynamiken gleichzeitig — kein Widerspruch, sondern ein Hinweis darauf, dass die Verschiebung entlang der Erfahrungsstufen verläuft.

Nur 5% aller deutschen Unternehmen setzen AI bereits zur Substitution von IT-Köpfen ein¹⁴. Bei Großunternehmen (250+ Mitarbeiter) sind es 21%. Der Mittelstand liegt deutlich darunter — was bedeutet, dass der eigentliche Transformationsdruck im deutschen Mittelstand noch aussteht.

AI-Native-Ökonomie: Was der neue Maßstab bedeutet

Die Effizienz-Diskrepanz

Im Mai 2025 haben Henry Shi und Jeremiah Owyang das "Lean AI Native Leaderboard"¹⁵ veröffentlicht — eine kuratierte Benchmark-Analyse, kein peer-reviewed Dataset: Die zehn führenden AI-nativen Startups erzielten laut ihrer Auswertung im Schnitt 3,48 Millionen Dollar Umsatz pro Mitarbeiter, bei einer durchschnittlichen Teamgröße von 24 Personen.

Die Einzelbeispiele sind eindrücklich. Cursor: über 1 Milliarde Dollar annualized revenue (November 2025, laut eigenem Series-D-Blogpost¹⁶), rund 300 Mitarbeiter — rechnerisch 3,3 Millionen Dollar pro Kopf. Midjourney: nach verschiedenen Schätzungen hochprofitabel mit einem kleinen Team von rund 100 Personen, ohne externe Investition — eines der wenigen komplett unabhängigen AI-Unternehmen. Lovable: 200 Millionen Dollar ARR (November 2025), rund 100 Mitarbeiter.

Zum Vergleich: SaaS Capital 2025 berichtet einen Medianwert von 130.000 Dollar Umsatz pro Mitarbeiter für private SaaS-Unternehmen¹⁷; Scale-SaaS-Unternehmen über 50 Millionen ARR streben rund 300.000 an. AI-native Firmen operieren laut Owyang und Shi mit "7-8-fach weniger Mitarbeitern pro Umsatzdollar" als traditionelle SaaS-Unternehmen.

Was das nicht bedeutet

Diese Zahlen haben in der öffentlichen Diskussion oft zu einem Schluss geführt, den ich für falsch halte: Alle werden entlassen, Enterprise-Teams schrumpfen auf Dreier-Gruppen.

Das stimmt nicht — aus mehreren Gründen. Erstens sind AI-native Startups Greenfield-Builds. Sie starten mit der Annahme, dass Agenten Code schreiben; Legacy-Strukturen, Governance-Anforderungen, regulatorische Abläufe fehlen. Ein österreichisches Finanzinstitut kann seine IT-Abteilung nicht auf das StrongDM-Modell umstellen, ohne die halbe Compliance-Abteilung neu zu designen.

Zweitens sind 3,48 Millionen Dollar pro Mitarbeiter das obere Ende einer Verteilung, nicht der neue Mittelwert. Das ist wie Benchmarking gegen die Champions League, wenn man in der zweiten Bundesliga spielt — nützlich als Orientierung, nicht als unmittelbares Ziel.

Drittens — und das finde ich am wichtigsten — sagen diese Zahlen nichts über absolute Headcounts. Eine Organisation, die früher zehn Entwickler brauchte und heute mit sieben auskommt, hat das Verhältnis verschoben, aber nicht eliminiert. Der neue Gleichgewichtspunkt liegt irgendwo zwischen "gleiche Headcounts, deutlich mehr Output" und "drastisch kleinere Teams, gleicher Output" — wo genau, hängt von Domainkomplexität, Regulatorik und Brownfield-Last ab.

Was die Zahlen zeigen: Die Gleichgewichtsannahmen für Teamgröße und Umsatz pro Kopf verschieben sich. Wer Headcount-Planung auf den Annahmen von 2022 betreibt, plant an der Realität vorbei.

Post-Agile: Von Sprints zu Specs

Warum Scrum an Level 4 stößt

Agile war eine Antwort auf Wasserfall — auf lange Planungszyklen, starre Anforderungsdokumente, spätes Feedback. Die Lösung: kurze Iterationen, enge Feedbackschleifen, Working Software over Comprehensive Documentation. Für menschliche Teams war das richtig.

Für Agenten ist es die falsche Prämisse.

AWS hat im DevOps-Blog "Bolts" als Konzept eingeführt: kürzere Arbeitszyklen, gemessen in Stunden statt Wochen. "Epics" werden zu "Units of Work". Der Sprint als zweiwöchiger Rhythmus der menschlichen Teamkoordination verliert seine Rechtfertigung, wenn Agenten asynchron und in Stunden statt Tagen arbeiten. P3 Group¹⁸, ein deutsches Beratungsunternehmen, beschrieb im September 2025 den Übergang von "Sprints to Swarms" als drei Paradigmen: Agent Swarms, Orchestrated Pipelines, Prompt-Chained Workflows. Ihr Urteil: "Traditional Scrum becomes a strategic liability" in Level-4-Umgebungen.

Ethan Mollick¹⁹ (Wharton) hat StrongDMs radikalen Ansatz²⁰ — keine Sprints, kein Standup, kein Jira, keine menschliche Code Review — als "truly radical approach" bezeichnet und gleichzeitig argumentiert, mehr solcher Leapfrog-Ideen seien nötig: nicht AI in alte Prozesse integrieren, sondern Prozesse von Grund auf neu designen. Die Zahlen, die er zitiert, stützen das: AI auf bestehende Prozesse draufgelegt ergibt 5 bis 15% Gewinn; fundamentales Prozess-Redesign ergibt "dramatically more." Shapiro schätzt²¹, und ich teile diese Einschätzung, dass es sich nicht um mehr desselben handelt, sondern um eine andere Größenordnung.

Das ergibt methodisch Sinn. Agile löste das Koordinationsproblem menschlicher Teams: Wie synchronisiert man viele individuelle Arbeitsstränge? Sprints, Standups und Jira sind Koordinationsinstrumente. Agenten brauchen keine Koordination durch Sprints — sie brauchen Spezifikationsklarheit. Die Methodik muss das abbilden.

Was "Post-Agile" konkret heißt

Ich verwende den Begriff mit Vorsicht, weil er leicht missverstanden wird. Es geht nicht darum, iterative Arbeit abzuschaffen — es geht darum, dass die Iterationen nicht mehr um menschliche Kommunikationszyklen herum gebaut sein müssen.

Spec-Driven Development ist nicht Wasserfall. Es ist agil in einem neuen Sinn: Specs iterieren schnell, Agenten implementieren fast sofort, Holdout-Scenarios validieren kontinuierlich. Die Iteration passiert auf der Spec, nicht auf dem Code. Das ist ein anderer Rhythmus — schneller in manchen Dimensionen, anforderungsreicher in anderen (Spec-Qualität als kontinuierliche Disziplin, nicht als einmaliges Artefakt).

Was in vielen Teams fehlt, die den Übergang beginnen: Jira abzuschaffen ist einfach. Eine Spec-Kultur aufzubauen, in der Anforderungen präzise genug sind, dass ein Agent damit arbeiten kann, ist schwer. Das erfordert andere Fähigkeiten, andere Review-Prozesse, andere Qualitätsgates.

DACH hat den Bauplan

Das ist die Einschätzung, bei der ich am stärksten von der pessimistischen Mainstream-Diskussion abweiche. Der DACH-Raum hat strukturelle Vorteile, die in der globalen Debatte fast nicht vorkommen.

Betriebsrat als Transformationsarchitekt

AI-Transformation ist nicht nur Tooling, sondern vor allem Prozess- und Rollenumbau. Wenn neue KI-gestützte Prozesse und Tätigkeitsfelder entstehen, gehört der Betriebsrat als eigener Workstream von Anfang an auf die Landkarte — ähnlich wie Security, Compliance oder Architektur. Früh einbinden, den Kontroll- und Datenrahmen transparent machen (z. B. Logging, Auswertungen, Monitoring-Grenzen), und Qualifizierung sowie Übergänge planen: Das reduziert Eskalationsrisiko, macht Entscheidungen belastbarer und beschleunigt die Einführung, weil spätere Blockaden und "Überraschungen" seltener werden.

Hinweis: Es gibt dazu bereits Rechtsprechung und einen klaren juristischen Rahmen — etwa Mitbestimmungsfragen rund um Überwachung und Arbeitsmethoden²². Ich bin kein Jurist; das ist eine Management-Empfehlung aus Transformationssicht. Für die konkrete Ausgestaltung lohnt sich eine entsprechend tiefe arbeitsrechtliche Prüfung und eine saubere Abstimmung mit Betriebsrat und HR.

Duale Ausbildung als strukturelles Sicherheitsnetz

Molly Kinders Residency-Modell-Vorschlag für Entry-Level-Jobs trifft sich mit einer Struktur, die im DACH-Raum seit Jahrzehnten existiert: dem dualen Ausbildungssystem.

CEDEFOP²³ beobachtet, dass Deutschland AI aktiv als "key VET competence" in bestehende Ausbildungsrahmen integriert — ohne Neustart, mit Curriculum-Update. TRUMPF²⁴ hat 2025 einen dualen Studiengang "Data Science and Artificial Intelligence" eingeführt — ein frühes Beispiel dafür, wie Industrieunternehmen AI-Kompetenzen direkt in die Ausbildungsstruktur integrieren.

Die Daten zeigen, dass das duale System tatsächlich als Gegengewicht zum offenen Junior-Markt funktioniert. In der Schweiz stiegen die ICT-Lehrverträge laut ICT-Berufsbildung Schweiz²⁵ 2024 um 8,6% auf 3.623 neue Verträge — bei einer Zufriedenheitsrate von 96%. In Österreich hat sich die Zahl der IT-Lehrlinge im ersten Ausbildungsjahr seit 2017 fast verdoppelt: von 520 auf 968 (2023)²⁶. Während der offene Markt für Hochschulabsolventen einbricht, wächst die strukturierte Ausbildungspipeline. Das ist kein Zufall — es ist der Unterschied zwischen "wir stellen ein, wenn wir jemanden brauchen" und "wir bilden aus, weil wir wissen, dass wir jemanden brauchen werden."

Kinders Kern-Argument ist, dass juniors durch strukturierte, betreute Praxis ausgebildet werden müssen — genau das, was das duale System strukturell liefert: beaufsichtigtes Lernen durch echte Arbeit, mit festgelegtem Ausbildungsvertrag, mit institutionellem Rahmen. Das ist kein Zufall, das ist der Design-Vorteil des Systems.

Die Herausforderung bleibt: Was ist "echte Arbeit" für einen AI-Ausbildungslehrling, wenn AI selbst den Großteil der technischen Ausführungsarbeit übernimmt? Die Antwort liegt in Spec-Writing, Domain-Engineering, Quality-Validation — Fähigkeiten, die sich durch betreute Praxis aufbauen lassen. Die duale Ausbildung muss sich in ihrer Inhaltsdefinition anpassen, hat aber den Rahmen dafür.

Was DACH-Großunternehmen bereits tun

Die Daten für die frühen Mover im DACH-Raum sind real und signifikant.

Deutsche Telekom²⁷ berichtet, dass 2023 rund 66.000 Mitarbeitende an KI-Trainings teilnahmen; 2024 wurden 30.000 interne Nutzer praktisch im Einsatz von KI (Prompting) geschult. CEO Tim Höttges spricht von über 100.000 Kolleginnen und Kollegen, die seit 2023 in KI trainiert wurden. Gleichzeitig läuft eine "Junior Software Development Academy", die Customer-Service-Advisors in Entwicklerinnen umschult. 5.400 Ausbildungsplätze für 2025/2026 sind geplant.

SAP²⁸ hat ein Ziel von 12 Millionen extern in AI geschulten Personen bis 2030 angekündigt und ein umfangreiches Portfolio kostenloser AI-Kurse aufgebaut — das ist Ökosystem-Entwicklung im großen Maßstab.

Siemens²⁹ hat 1.700 neue Ausbildungsplätze für 2025 angekündigt und integriert "digital und AI" explizit in alle Ausbildungsprofile.

Was diese Programme unterscheidet: Sie sind keine defensiven "Wir retten Jobs"-Ankündigungen. Sie sind offensive Investitionen in Fähigkeitsaufbau — mit der Annahme, dass AI Arbeit verändert, aber nicht eliminiert, und dass die Organisationen, die die Transition managementtechnisch begleiten, besser aussteigen als die, die darauf warten, dass sich der Staub legt.

Meine Perspektive

Ich arbeite mit Teams, die an diesem Übergang stehen. Was ich sehe, ist konsistenter als man erwarten würde.

Das Infrastructure-as-Code-Paralleluniversum gilt auch hier. Als IaC in der Branche ankam, entstand dieselbe Diskussion: Werden Systemadministratoren ersetzt? Die Antwort war: Nein, aber die Rolle hat sich fundamental verändert. Wer früher Server provisioned hat, schreibt heute Terraform und Ansible. Die Fähigkeiten haben sich verschoben — von "ich kenne die CLI-Befehle" zu "ich kann das System in Code beschreiben." Wer die Transition nicht mitgemacht hat, wurde nicht entlassen — aber marginalisiert, ja. Wer sie mitgemacht hat, ist gefragter als je zuvor.

Dasselbe Muster zeichnet sich für Softwareentwicklung ab. Wer den Übergang vom Code-Schreiben zum Spec-Schreiben, vom Implementierer zum Quality-Validator, vom Individual Contributor zum Agent-Orchestrator macht, verändert sein Profil — nicht eliminiert es. Der Wert verschiebt sich: Weg von "wer schnell Code tippen kann", hin zu "wer präzise sagen kann, was gewollt ist." Das ist eine Aufwertung von Domain-Expertise und Systemdenken. Beides ist schwer zu automatisieren.

Was ich bei den Teams, die frühzeitig in die Transition gehen, beobachte: Der Übergang ist leichter für diejenigen, die schon immer gut spezifizieren konnten. Nicht unbedingt formal — Pflichtenheft-Affinität ist ein Vorteil, kein Muss. Aber die Fähigkeit, ein System vollständig zu durchdenken, Edge Cases zu antizipieren, Anforderungen so zu formulieren, dass kein Interpretationsspielraum bleibt — das ist die Kernfähigkeit des Level-4-Entwicklers. Und das ist eine Fähigkeit, die sich entwickeln lässt.

Bei Infralovers haben wir unsere Trainings und unser Coaching in den letzten Monaten verstärkt auf diese Verschiebung ausgerichtet. Nicht weil wir früher falsch lagen — AI Coding Essentials war schon immer mehr als Prompt-Engineering. Sondern weil wir sehen, dass die Nachfrage sich verschiebt: Von "wie nutze ich Cursor" zu "wie strukturiere ich Arbeit so, dass Agenten verlässlich liefern." Das ist die tiefere Frage. Und die Antwort liegt in Spec-Disziplin, in Holdout-Set-Denken, in der Fähigkeit, Domain-Wissen maschinenlesbar zu kodieren.

Was mir an der DACH-Perspektive am meisten Zuversicht gibt, ist nicht die Regulatorik und nicht die Ausbildungsstruktur allein — es ist die Kombination. Betriebsrat zwingt zu strukturierter Transition-Planung. Duales Ausbildungssystem liefert den Rahmen für betreute Praxis. Und die DACH-Ingenieurskultur — Pflichtenheft, Gründlichkeit, Systemdenken — ist überraschend gut auf Spec-Driven Development vorbereitet, wenn man es so formuliert. Der Begriff ist neu. Das Denkmuster ist es nicht.

Was das für Engineering-Führungskräfte bedeutet

Keine generischen Empfehlungen. Was aus den Daten und meiner eigenen Erfahrung konkret folgt.

1. Die Junior-Pipeline jetzt gestalten, nicht reaktiv verwalten

Die Harvard-Studie⁵ zeigt, dass der Einstellungsrückgang durch Hiring Freeze, nicht durch Entlassungen getrieben ist. Das ist eine bewusste Entscheidung, und sie hat Konsequenzen in drei bis fünf Jahren. Wer heute keine Juniors mehr einstellt, baut heute keine Mentoring-Kapazität auf.

Meine Einschätzung: Es lohnt sich, das Rollenprofil für Juniors neu zu definieren — weg von "macht Boilerplate" hin zu "lernt, präzise zu spezifizieren, Domain-Wissen zu kodieren, Scenarios zu schreiben." Das ist ein höherwertiger Einstiegsjob als früher — und ein, der für die nächste Generation von Seniors sorgt, die weiterhin Domain-Expertise haben.

2. Rollen explizit neu schreiben, nicht implizit driften lassen

Der "PM-Developer" ist kein Selbstläufer. Wenn man Entwicklern sagt "nutzt AI mehr", aber das Rollenprofil, die Bewertungskriterien und die Karrierepfade nicht aktualisiert, entsteht Rollenkonfusion. Wer nach Code-Output bewertet wird, schreibt Code. Wer nach Spec-Qualität und Agent-Output bewertet werden soll, braucht explizite neue Kriterien.

Konkreter Schritt: Im nächsten Performance-Review-Zyklus einen expliziten Bereich für "Spec-Writing-Qualität" und "Agent-Orchestration-Effektivität" einführen. Das klingt bürokratisch. Es ist der Signal-Setzungsmechanismus, der Prioritäten kommuniziert.

3. Betriebsrat frühzeitig einbeziehen — strategisch, nicht defensiv

Organisationen, die AI-Transformation gemeinsam mit dem Betriebsrat planen, haben einen Prozess, der nachher hält. Organisationen, die Restrukturierungen ankündigen und dann in Sozialplan-Verhandlungen gehen, verlieren Zeit und Vertrauen.

Frühzeitig bedeutet: bevor ein konkreter Restrukturierungsplan auf dem Tisch liegt. Ein gemeinsamer Workshop zu "was ändert AI an unserer Arbeit" ist kein Eingeständnis von Schwäche — es ist die Grundlage für eine Betriebsvereinbarung, die AI-Adoption ermöglicht statt blockiert.

4. Upskilling nach dem AT&T-Modell — mit realistischem Zeithorizont

AT&T investierte rund eine Milliarde Dollar in ein mehrjähriges Reskilling-Programm ("Future Ready")³⁰ und machte Upskilling zu einem strategischen Kernhebel. Die Ergebnisse waren stark: Über 180.000 von 203.000 Mitarbeitenden nahmen teil, und die Hälfte aller internen Stellen wurde mit umgeschulten Mitarbeitern besetzt. Aber der Zeithorizont — sieben bis acht Jahre von der Erkenntnis bis zu messbaren Ergebnissen — ist entscheidend.

Das bedeutet: Wer jetzt beginnt, hat 2033 skalierbare Ergebnisse. Wer wartet, bis der Druck unübersehbar ist, startet 2028 und hat 2035 skalierbare Ergebnisse. In einer Branche, die sich in 18-Monats-Zyklen verändert, ist das ein erheblicher Unterschied.

Deutsche Telekom, SAP und Siemens haben das erkannt — nicht weil sie AI-Enthusiasten sind, sondern weil ihre Planungshorizonte für Talent-Entwicklung lang genug sind, dass der sieben-Jahres-Zeithorizont im strategischen Kalkül sichtbar wird.

5. Die konkrete Sequenz für die nächsten 12 Monate

• Jetzt: Bestandsaufnahme der aktuellen Junior-Hiring-Rate. Nicht als Schuldzuweisung, sondern als Datenpunkt: Wie viele Juniors haben wir in den letzten 12 Monaten eingestellt, verglichen mit den drei Jahren davor? Was ist die implizite Annahme hinter dieser Entscheidung?
• Nächste drei Monate: Ein Pilotteam für Level-3-/Level-4-Workflows identifizieren. Nicht das beste Team — das Team, das am offensten für Methodenwechsel ist. Die frühen Erfahrungen aus diesem Team sind die Grundlage für alles Weitere.
• Nächste sechs Monate: Spec-Writing als explizite Disziplin einführen. Einen Bootcamp-Format-Tag für das Pilotteam — was macht eine gute Agent-Spec aus? Wie baut man Holdout-Scenarios? Was sind die häufigsten Spec-Qualitätsprobleme? Das ist die Investition, die den Unterschied macht, nicht weitere Tool-Lizenzen.
• Nächste 12 Monate: Karrierepfad-Update. Die Rollenbeschreibungen für Mid- und Senior-Developers aktualisieren, um Agent-Orchestration und Spec-Qualität als explizite Kompetenzfelder einzuführen.

Das ist der dritte und letzte Teil der Serie. Was wir in drei Posts durchgearbeitet haben:

Teil 1 hat die Mechanik erklärt — warum AI-Tools allein nicht reichen, warum die J-Kurve ein Durchgangsstadium ist, nicht ein Endpunkt. Teil 2 hat die Architektur auseinandergenommen — wie Spec-Driven Development, Digital Twins und Holdout-Set-Thinking zusammenspielen, wenn Agenten den Code schreiben. Dieser Teil hat die Organisationsfrage gestellt: Was passiert mit den Menschen darin?

Die Antwort: Alles verändert sich. Die Rollen, die Metriken, die Karrierewege, die Junior-Pipeline, der Prozessrahmen. Aber "alles verändert sich" ist kein Grund für Panik — es ist ein Grund für Planung. Die Organisationen, die frühzeitig explizit planen — Rollen neu schreiben, Junior-Ausbildung neu definieren, Betriebsrat einbeziehen, Spec-Kultur aufbauen — sind in zwei bis drei Jahren besser aufgestellt als die, die auf Stabilisierung des Status quo warten.

Der 7-8-Jahres-Zeithorizont von AT&T gilt. Das Fenster für gute Planung ist jetzt offen. Es bleibt nicht ewig offen.

Wie dieser Artikel entstanden ist

Recherche, Struktur, Argumentation und alle inhaltlichen Entscheidungen sind meine. Die Texterstellung erfolgte in Zusammenarbeit mit Claude (Anthropic) — demselben Tool, mit dem ich in meinem AI-Workflow auf Level 4 arbeite. Quellenrecherche über Gemini, ChatGPT und Claude; DACH-spezifische Datenrecherche über einen gezielten Research Brief, als die ursprüngliche Quellenlage eine geografische Lücke zeigte. Fünf Runden Faktencheck, manuelle Überprüfung jeder einzelnen Quellenangabe, externer Holdout-Check über GPTZero (0% Plagiarismus-Score — ausnahmslos korrekte Zitationen). Infografiken generiert mit Gemini, nach jedem Editing-Durchgang gegen den Artikeltext geprüft. Alle Entwürfe, Research Briefs und Recherche-Ergebnisse sind in Git versioniert.

Der Prozess, den dieser Artikel beschreibt — Spec schreiben, Agent arbeiten lassen, Output kritisch prüfen — ist derselbe Prozess, mit dem er geschrieben wurde. Den vollständigen Workflow beschreibe ich in AI-gestützte Wissensarbeit: Wie ich meinen Recherche- und Schreibprozess neu aufbaue.