Print/KDP 6×9 Grayscale (just, QA, Assets), erweiterter Agent-Harness und Manuskript-/Abbildungs-Stand mit frischen eBook- und Print-PDFs.
13 KiB
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 |
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.
| 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
- Agenten als Hebel mit Guardrails; Orakel und Review parallel zu Generation (13.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
- Drei Scorecard-Metriken baselinen + Engpass 13.2 · Hüte mit Artefakt-DoD.
- Anti-Hype (13.6) scoren (≥3 → Harden-Plan) + 90-Tage-Zeile (13.5 #7).

