Files
ki-buch/teil-04-zukunft/kapitel-13-auswirkungen-softwarebranche.md
grok-bot 0fbbaf71d5
CI / Companion (py3.11) (push) Has been cancelled
CI / Companion (py3.12) (push) Has been cancelled
build: KDP-Print-Pipeline, Lektorat und regenerierte Dist-PDFs.
Print/KDP 6×9 Grayscale (just, QA, Assets), erweiterter Agent-Harness
und Manuskript-/Abbildungs-Stand mit frischen eBook- und Print-PDFs.
2026-08-09 10:04:12 +02:00

13 KiB
Raw Permalink Blame History

Kapitel 13: Auswirkungen, Rollen und Führungsentscheidungen

Teil IV · Strategie und Organisation


Wenn Agenten produktiv werden, spüren Teams das zuerst nicht an „mehr Intelligenz“, sondern an verschobenen Engpässen: mehr Diffs, vollere Review-Warteschlangen, unklare Ownership, und Führungsfolien mit Lab-Multiplikatoren, die im eigenen Repo nicht halten. Wer das ignoriert, kauft Seats und erntet Output-Theater – PRs/Woche steigen, CFR und Vertrauen sinken.

These: Die wirtschaftlichen und organisatorischen Effekte sind real, ungleich und setting-abhängig. Completions sind nicht dasselbe wie Agent+MCP; Gewinne enden am engsten Engpass aus Review, Orakeln, Kontext und Security. Führung entscheidet über Risk Appetite, portable Architektur und Skills – nicht über Titel-Theater.

Leitfrage: Wo entstehen echte Produktivitätsgewinne – und welche Entscheidungen in 90 Tagen trennen Nutzen von Hype?

Dieses Kapitel ordnet Evidenz (Größenordnungen mit Setting, ausführlich Anhang F), den Review-Engpass, Seniority-Verschiebungen und ein Rollenmodell aus Hüten mit Artefakt-DoD ein. Die 90-Tage-Entscheidungsliste und die Anti-Hype-Checkliste sind Arbeitsmittel, keine Motivationsposter. Scorecard und Autonomy-Gates bleiben in Kapitel 7.9 und 11 verankert; Kapitel 12 lieferte Wetten und Invest-Split – hier wird daraus Org- und Führungsrealität.

Lernziele

Nach diesem Kapitel kannst du:

  • Produktivität setting-abhängig einordnen (Lab vs. Feld vs. reife Repos; Anhang F),
  • den Engpass Review / Orakel / Kontext / Security mit Signalen steuern,
  • Ownership-Hüte (Context, MCP Server, Agent Infra) mappen – Hüte vs. Stellen,
  • 90-Tage-Führungsentscheidungen an Scorecard (7.9) und Readiness (11) koppeln,
  • mit einer Anti-Hype-Checkliste zu frühe Automation erkennen.

13.1 Produktivität: wo die Gewinne wirklich liegen

Agenten beschleunigen nicht „Softwareentwicklung“ als Ganzes – sie beschleunigen bestimmte Aktivitäten und lassen andere (Stakeholder, Architektur-Trade-offs, Politik) weitgehend menschlich. Die erste Tabelle ist eine Wirkungs-Landkarte: stark beschleunigte Routine vs. gemischte oder menschliche Domänen. Danach folgen Feld- und Labor-Größenordnungen – als Planungsrahmen, nicht als Garantie.

Aktivität Typische Wirkung mit reifen Agenten
Boilerplate, Glue, Routine-Refactors stark beschleunigt
Tests (mit Orakeln) beschleunigt; Qualität = Review + Orakel
Unklare Prod-Bugs gemischt – Kontext kritisch
Architektur & Trade-offs unterstützt, nicht ersetzt
Stakeholder, Priorisierung, Politik menschlich

{ width=100% }

Messung: DORA + AI-Metriken (Edit Rate, Tokens/PR, Task Success). Nur „PRs/Woche“ = Output-Theater (7.9).

Daten 2026 (Kurzfassung · ausführlich Anhang F.2)

Setting Größenordnung Stufe Quelle
Kurzer Labortask (Copilot) ≈ +56 % schneller [E1] Peng et al., 2023
Enterprise-RCT, n≈4 867 ≈ +26 % Tasks/PRs/Woche [E1] Cui et al., 2025
Erfahrene OSS-Devs, eigene reife Repos ≈ +19 % längere Zeit [E1] METR / Becker et al., 2025

Completions ≠ autonome MCP-Agents – für Agent+MCP fehlen große Feld-RCTs (Stand 2026-07): selbst messen (Kap. 6.5, Anhang C). DORA 2025: AI als Amplifier (Throughput↑ möglich, Stabilität/Trust unter Druck) [E2]. GitClear-artige Churn-/Copy-Paste-Signale: Frühwarnung, keine saubere Tool-Kausalität [E2].

Faustregel: Plant mit Feld-Größenordnungen (~+¼ Tasks in günstigen Enterprise-Settings) und eigener Baseline (4–6 Wochen) – nicht Lab-56 % oder Folien-10×. [E4]
(Lab/Feld-RCTs zu Completions: Anhang F.2 [E1]; Transfer auf Agent+MCP selbst messen.)

Was für die Planung offen bleibt:

Was wir (noch) nicht wissen: Welche Netto-Produktivität autonome Coding Agents (Tool-Loops, MCP, L2/L3) in gemischten Seniority-Teams wirklich liefern.

  • Offene Fragen: 1) Übertragen sich Completions-RCTs (Cui 2025 ≈+26 % [E1]; Peng 2023 Lab ≈+56 % [E1]) auf Agent-Loops? 2) Wann dominiert Verification Tax (METR 2025 [E1])?
  • Widersprüchliche Evidenz: Completions-Gewinne [E1] vs. METR-Verlangsamung bei Senioren auf eigenem Repo [E1] vs. Multi-Agent-Token ~2–3,5× [E4] — verschiedene Welten (Anhang F.2/F.4).
  • Was die Aussage widerlegen würde: Feld-RCT Agent+MCP vs. Completion-only: Null-Effekt auf review-acceptierte Arbeit oder Revert/Incident ↑ bei gleichem Throughput.
  • Überprüfung: Vor L2→L3 Canaries + Error Budgets (Kap. 11); quartalsweise Scorecard (Kap. 7.9).
  • Was wir trotzdem tun [E4]: Autonomy an Orakel/Budgets koppeln; Lab-56 % und Marketing-10× nicht in den Business Case (Anhang F.2).

13.2 Qualität und der Engpass Review

Mehr generierter Code hebt Qualität bei starken Orakeln – und senkt sie bei überlastetem Review. Der Netto-Gewinn endet am engsten Engpass:

Engpass Frühsignal Wenn anhaltend …
Review-Kapazität Edit-Rate↑; Warteschlange; CFR↑ Autonomy −1; assistive Review-Agenten; mehr Orakel
Orakel-Qualität grüne CI, rote Prod; flaky Evals Tests/Types vor L2; Eval-Freeze (7.9 C)
Context / Memory Hit Rate↓; Waste↑ Policy, Working Set, KB-Hygiene (7.8)
Security Tools/Server unauditierte Server; Denies = 0 Katalog-Stopp; Threat Model (11)

Ohne paralleles Skalieren von Review und Orakeln: schnellere technische Schuld.


13.3 Teamstrukturen und Seniority

Wenn Generation billiger wird, verschiebt sich Wertschöpfung zu Verify, Orakel-Design, Governance und portablen Capabilities. Junior/Mid und Senior/Staff profitieren unterschiedlich – und scheitern an unterschiedlichen Anti-Mustern (Copy-Paste-Karriere vs. Review-SPOF). Die Tabelle ist ein Führungsradar, kein Karriereplan.

Profil Wertbeitrag verschiebt sich zu … Risiko Führungshebel
Junior / Mid Verify, kleine Agent-Tasks, Tests, Policy-Pflege Copy-Paste-Karriere Pairing an Diffs/Traces
Senior / Staff Architektur, Orakel-Design, Governance, portable Caps Review-Überlast; SPOF Orakel-/Platform-Kapazität schützen
Team-Schnitt weniger reine Feature-Hände; mehr Platform/Context/Quality Shadow Platform Hüte schriftlich (13.4)

Kleine Teams profitieren oft spürbar mit Disziplin (weniger Koordinationssteuer, kürzere Feedback-Zyklen) [E4] – ohne Disziplin multiplizieren Agenten Chaos. Junior-Hiring stoppen „weil Agenten coden“ ist ein Anti-Hype-Signal (13.6).


13.4 Rollenmodell: Hüte vs. Stellen

Ownership-Artefakte schlagen Titel. In kleinen Teams Hüte, in großen Profile.

{ width=100% }

Hut / Rolle Mission Ownership-Artefakt (DoD) Background
MCP Server Owner Domänenfähigkeiten als sichere Server Katalog, Version, AuthZ/SBOM, Contract-Tests, SLO Backend / Platform
Context Engineering Owner Kontext messbar und governance-fähig context-policy, Working-Set-Regeln, Hit/Waste, Memory-Hygiene Senior Dev / Data / Docs+Systems
Agent Infra Owner Hosts, Gateway, Eval-CI, Traces, Autonomy-Rollouts Host-Standards, Eval-Gate, Kill-Switch SRE / DevEx
Security Liaison (Hut) Boundaries, Allowlists, Incident Agent/MCP Threat-Model-Template, Playbook Security + alle drei

Nicht: Server Owner = Loop-Bastler; Context Owner = Prompt poet; Infra = Feature-Coding. Querverweis Kap. 8 und Team-Readiness (Kap. 11).

Teamgröße Empfehlung
<10 2–3 Hüte schriftlich (nicht 3 FTE); Platform+MCP kombinierbar
10–50 20–50 %-Mandate; Minimum: Katalog + Policy + Eval-Gate
50+ Stellen/Guild; Security-Liaison formal; Shadow Platform verbieten

DoD-Portfolio: ein Server im Katalog · eine Policy mit Metriken · eine Eval-Gate-Pipeline – messbar in 90 Tagen.


13.5 Was Führung jetzt entscheidet (90 Tage)

Strategie ohne schriftliche Entscheidungen bleibt Absicht. Die folgenden sieben Punkte sind ein 90-Tage-Minimum: je eine Entscheidung, ein Messsignal und die typische Fehlentscheidung. Engineering Manager und CTO teilen sich die Zeilen – aber niemand darf sie „implizit“ lassen.

# Entscheiden (schriftlich) Messen Fehlentscheidung
1 Risk Appetite + Autonomy L0–L3 Error Budget; Sev mit Agent L2 ohne Orakel
2 System-Invest ≥ Modell-Lizenzen (12.5) Invest-Check 7.9 D ≥6 nur Seats
3 Eval- und Security-Budget first-class Eval grün; unauditierte Server = 0 Security später
4 Hüte + Mandate (13.4) Owner auf Katalog/Policy/Eval Titel-Theater
5 Review parallel zu Generation Edit-Rate; CFR; Warteschlange Generation ohne Review
6 Vendor-Exit (Model + Host) Anteil portabler Server Host-Lock-in
7 Tag-90 Autonomy-Zeile (7.9 E) Outcome / Eval / Risiko weiter ohne Daten

EM: Baseline, Review-Last, Hüte, wöchentliche Signale. CTO: Invest-Split, portable Architektur, org-weites Risk Appetite, Exit.

Wir behalten / senken / erhöhen Autonomy auf L_ weil:
Outcome: … | Eval: … | Risiko: … | Engpass: Review|Context|Orakel|Security

13.6 Anti-Hype-Checkliste

Hype erkennt man selten an einem einzelnen Symptom – eher an einem Muster: Lab-Zahlen ohne Baseline, Autonomy ohne Eval, Plattform-Narrativ ohne Owner. Die Checkliste ist ein Frühwarnsystem. Ab ≥3 Punkten: Autonomy nicht erhöhen – hardenen oder messen, bevor ihr skaliert.

# Signal Reaktion
1 Lab-56 % / Folien-10× ohne Baseline Baseline 4–6 Wochen; Anhang F
2 Autonomy↑ bei fehlender/roter Eval-Suite Freeze; n≥20 (7.9)
3 „Agent-OS“ ohne Server-Owner Hut benennen oder Scope streichen
4 Review-Warteschlange↑; CFR/Churn↑ Autonomy −1; Orakel (13.2)
5 Junior-Hiring gestoppt „weil Agenten coden“ Pipeline + Review-Skills schützen
6 Server pro Team ohne Katalog Katalog-Stopp (Szenario D)
7 Policy Denies = 0 Allowlists erzwingen (11)
8 Multi-Agent vor Intent/Verify Verify first (12.3–12.4)
9 Traces nicht postmortem-fähig Trace-Minimum; kein L2 (11.10)
10 Readiness < 8/12, trotzdem org-weiter L2-Pilot Readiness nachziehen (11)

13.7 Geschäftsmodelle und Bildung (kompakt)

Agenten verändern nicht nur Team-KPIs, sondern wer womit Geld verdient und was gelernt werden muss. Die Übersicht ist bewusst kompakt: Implikationen für Produkt, Agenturen, Vendoren und OSS – plus der Bildungshebel, der langfristig mehr zählt als Tool-Schulungen allein.

Akteur Implikation
Produkt Standardfeatures schneller; Differenzierung: Domäne, Daten, UX, Compliance, Betrieb
Agenturen unklare Festpreise riskanter; Eval/Server/Enablement statt Tippen-Leasing
Vendoren Host+Model-Bundles; offene Protokolle begrenzen Lock-in
OSS Server/Evals/Policies als Commons; Supply-Chain-Vertrauen

Bildung: Host sicher nutzen, Agent-Output reviewen und verwerfen, Tools/Kontext/Risiko verstehen – Curricula: Systeme, Tests, Security, Kontext.


Best Practices

  1. Agenten als Hebel mit Guardrails; Orakel und Review parallel zu Generation (13.2).
  2. Hüte mit Artefakt-DoD (13.4); KPIs an 7.9; Anti-Hype quartalsweise (13.6).

Pitfalls

Pitfall Gegenmaßnahme
10× / Lab-56 % als Planung; Autonomy ohne Scorecard Baseline + Anhang F; Tag-90-Zeile (7.9 E)
Junior-Hiring stoppen; Rollen ohne Mandate Review-Skills; Artefakt-DoD (13.4)
Jeder baut Server; nur Lizenzen Katalog + Owner; Capabilities/Policies (12.5)

Key Takeaways

  • Gewinne real, ungleich, setting-abhängig – Completions ≠ Agent+MCP (Lab/Feld [E1], Agent-Transfer offen).
  • Review, Orakel, Kontext, Security begrenzen den Netto-Gewinn [E4]; Portfolio schlägt Titel.
  • Führung: Risk, portable Architektur, Skills; Scorecard 7.9 + Anti-Hype trennen Nutzen von Theater.

Was als Nächstes kommt

Das Schlusswort bündelt Leitmotive mit Kap.-12/13-Entscheidungen und max. vier nächste Schritte.


Übungsanregungen

  1. Drei Scorecard-Metriken baselinen + Engpass 13.2 · Hüte mit Artefakt-DoD.
  2. Anti-Hype (13.6) scoren (≥3 → Harden-Plan) + 90-Tage-Zeile (13.5 #7).