ki-buch/teil-03-praxis/kapitel-07-agenten-im-sdlc.md

Kapitel 7: Agenten im Software Development Life Cycle

Teil III · Agentenbasierte Softwareentwicklung in der Praxis – MCP & Context Engineering im Fokus

---

„Wir rollen Coding Agents aus“ klingt nach einer Entscheidung – und verdeckt zehn. Discover, Spec, Design, Implement, Review, Test/CI, Release und Operate haben andere Ziele, andere Kontexte, andere Tools und andere sinnvolle Autonomiegrade. Wer nur den Editor-Chat optimiert, verschenkt oft den größeren Hebel: bessere Specs, Review-Second-Eyes, CI-Orakel und Operate-Signale.

These: Agenten ersetzen den Softwareprozess nicht – sie brauchen pro Phase Context Packs, Verify-Loops und HITL-Gates. Context Engineering mit MCP (Codebase, Git, Issues, CI, Docs on-demand) macht aus Disziplin Betriebspraxis.

Leitfrage: Wo im Lebenszyklus schaffen Agenten echten Wert – und welche Gates braucht jede Phase, bevor sie schreibend in die Mainline greifen?

Teil III beginnt hier mit der SDLC-Landkarte und Autonomy-Levels, übersetzt die Prinzipien aus Teil II in Team-Alltag und liefert in 7.9 eine 90-Tage-Scorecard, damit Nutzen gemessen statt behauptet wird. Multi-Agent-Orgs folgen in Kapitel 8; Toolchain in Kapitel 9; der Bau in Kapitel 10. Besonders relevant für Engineering-Manager und Teams, die Rollouts planen – nicht nur für einzelne Power-User.

Lernziele

Nach diesem Kapitel kannst du:

• Agenten-Einsatz entlang des SDLC (von Discovery bis Operate) planen statt nur „im Editor chatzen“,
• sinnvolle Automatisierungsgrade und Human-in-the-Loop-Punkte pro Phase festlegen,
• Coding Agents für Implementierung, Review, Test und CI sinnvoll abgrenzen,
• Context Engineering für Coding Agents mit MCP entwerfen (Codebase, Git, Issues, Docs on-demand),
• Qualitäts- und Risikokriterien definieren, bevor Agenten schreibend in den Mainline greifen,
• ein schrittweises Rollout in einem realen Team skizzieren,
• Nutzen und Risiko über 90 Tage mit einer Scorecard messen statt behaupten (7.9).

Schicht	In diesem Kapitel	Stand
Stabil	SDLC-Phasen, Autonomy-Levels, HITL-Gates	Prinzipien
Mittelstabil	Context Packs, Agent-ready Issues, Verify pro Phase	Muster
Volatil	konkrete CI-YAML-/Host-Integrationen	Juli 2026

{ width=100% }

---

7.1 Der SDLC als Agenten-Landkarte

Agenten sind kein Ersatz für den Softwareprozess – sie beschleunigen und entlasten Phasen, wenn Kontext und Tools stimmen.

Konzept-Plate: SDLC mit MCP-Quellen

{ width=100% }

Phase	Agenten-Nutzen	Typische MCP-Server
Discover	Issues schärfen, Akzeptanzkriterien	issues, memory
Design	Optionen, ADR-Entwürfe	memory, repo (read)
Implement	Code, Refactors, Migrationen	repo, graph, tests
Review	Checklisten, Risk Notes	git diff, memory, security
Test/QA	Repro, Testdaten, Flaky-Analyse	tests, ci, repo
Release	Changelog, Checklisten	ci, issues, memory
Operate	Triage, Runbook-Schritte	logs, k8s/read, memory

Analogie: Der SDLC ist eine Fertigungslinie. Agenten sind spezialisierte Stationen mit Sensoren (Resources) und Aktoren (Tools) – nicht ein Roboter, der „die Fabrik ist“.

---

7.2 Discover & Spec: bessere Aufgaben, weniger Halluzination

Schlechte Tickets erzeugen teure Agenten-Läufe. Hier lohnt Automatisierung vor dem Coding.

Agentische Unterstützung

• unklare Issues in User Story + Akzeptanzkriterien + Out-of-Scope strukturieren,
• verwandte ADRs und frühere Incidents vorschlagen,
• fehlende Logs/Repro-Schritte markieren (nicht erfinden).

Context Pack für Spec-Agenten

1. Issue-Text + Kommentare (issues://…)
2. betroffene Service-Karte aus Memory
3. relevante ADRs
4. keine halbe Codebase – außer explizite Spike-Tasks

DoD der Phase: Ticket ist agent-ready: reproduzierbar, messbar, mit Constraints (Perf, Security, Kompatibilität). Der Spec-Prompt erzwingt strukturierten Output (summary, acceptance_criteria[], constraints[], questions[]), verbietet erfundene Fakten und markiert Unklarheiten explizit als QUESTIONS.

---

7.3 Design: Optionen, ADRs und Leitplanken

Design-Agenten sollen Alternativen und Konsequenzen liefern, nicht heimlich die Architektur umbauen.

Gut	Schlecht
2–3 Optionen mit Trade-offs	„Ich habe schon alles refactored“
ADR-Entwurf als Resource	Entscheidung nur im Chat
Bezug auf bestehende Conventions	grüne Wiese ignorieren
explizite Non-Goals	Scope-Creep

Persistenz: record_decision / memory://adr/… (Kap. 5). Mensch approved Architektur, Agent darf danach implementieren.

---

7.4 Implementierung: der Coding Agent im engeren Sinn

Arbeitsmodus

1. Working Set bestimmen (Dateien, Tests, Contracts)
2. Repro / failing test
3. minimale Änderung
4. lokal verifizieren
5. Diff + Erklärung

Schreibende vs. lesende Rechte (Autonomy L0–L3)

Die Stufen unten sind Privilege-/Tool-Levels (was der Agent darf), nicht die Rollout-Phasen aus Kap. 11.9/11.10.7. Beide Ebenen koppeln: höhere Privilegien nur mit Harness-Gates und Error Budgets (Kap. 11).

Stufe	Erlaubt	Typischer Einsatz	Kap.-11-Bezug (Orientierung)
L0 Read-only	search, read, explain	Onboarding, Analyse	Phase 0 assist only
L1 Workspace write	edit, format, local test	Feature-Branches	Phase 0–1 Vorbereitung
L2 Repo integrate	commit, push branch, draft PR	Standard-Dev	Phase 1 draft PR
L3 Protected	merge, release, prod mutate	nur HITL / CD	Phase 3 enge Auto-Merge + Human Gate

Default für die meisten Teams: L1–L2 mit Branch-Protection. L2→L3 nur, wenn Eval grün, required checks und Error Budget greifen (Kap. 11.10.7; Scorecard 7.9).

Branch-Strategie

• Agent arbeitet auf agent/issue-123-…
• CI voll grün
• Mensch reviewed
• optional Auto-merge nur bei engem Scope, harten Gates und freigegebenem Error Budget (Kap. 11)

---

7.5 Review: Agenten als Second Pair of Eyes

Review-Agenten ersetzen keine Ownership, aber sie skalieren Checklisten.

Sinnvolle Review-Perspektiven

• Korrektheit gegen Akzeptanzkriterien
• Security (Injection, AuthZ, Secrets)
• API-Kompatibilität
• Testlücken
• Operability (Logs, Metrics, Flags)

{ width=100% } Context: Diff + geänderte Interfaces + relevante ADRs + CI-Summary – nicht der gesamte Main.

---

7.6 Test, CI und Qualitätssicherung

Agenten-Rollen

Rolle	Aufgabe	Tooling
Test Author	fehlende Unit/Integrationstests	repo write + tests
Flaky Hunter	bisect, Timing, Isolation	ci logs, repro
CI Fixer	Build-Break nach Dependency-Bump	ci, repo
Coverage Guide	riskante ungetestete Pfade	graph + coverage resource

Goldene Regel

Agenten dürfen „fertig“ erst sagen, wenn objektive Checks (Tests, Lint, Types) über Tools grün sind.

def implementation_done(mcp_tests, mcp_lint) -> bool:
    t = mcp_tests.call_tool("run_unit_tests", {})
    l = mcp_lint.call_tool("run_linter", {})
    return bool(t.get("ok") and l.get("ok"))

CI als Agent-Host

Pipeline-Jobs können denselben MCP-Stack nutzen (read-mostly + kommentierende Tools):

• PR-Kommentar mit Risikoanalyse,
• automatischer Label-Vorschlag,
• Blocken bei Policy-Verstoß (Secret im Diff).

---

7.7 Release, Operate und Feedback in den Loop

Release

• Changelog aus commits/PRs entwerfen
• Migrations-Checkliste aus Diff ableiten
• Feature-Flag-Empfehlungen

Schreibende Prod-Tools: HITL-default.

Operate / Incident

Incident-Agenten glänzen bei:

• Log-/Trace-Korrelation (mit strengen Scopes),
• Runbook-Schritten als MCP-Prompts,
• Postmortem-Entwürfen aus Timeline-Artifacts.

Vorsicht: Produktionszugriff ist High Privilege. Separate Server, separate Credentials, kurze TTLs (Kap. 11).

Feedback

Aus Incidents und Postmortems:

• neue Eval-Cases (Kap. 6),
• neue Memory-Einträge,
• schärfere Spec-Templates.

Der SDLC schließt sich, wenn Operate wieder Discover füttert.

---

7.8 Context Engineering für Coding Agents mit MCP

Theorie aus den Kapiteln 3 und 5 wird zum SDLC-Alltag: Issue, Working Set, Diff, Tests und CI fließen budgetiert über MCP-Primitives – statt Repo-Dump. Der Leitgedanke entspricht erfahrenen Entwicklern: nur Ticket, Repro, wenige Dateien, Tests und Hausregeln laden. Policies, Deny-Globs und on-demand Resources machen Coding Agents beherrschbar, bevor sie schreibend in die Mainline greifen.

7.8.1 Die Kontextquellen der Softwarearbeit

Die Tabelle ordnet typische Software-Artefakte MCP-Formen zu. Sie ist eine Landkarte der Quellen, keine Aufforderung, alles parallel zu laden. Spalte „Wann laden“ ist der eigentliche Context-Engineering-Anteil.

Quelle	Typische MCP-Form	Wann laden
Codebase (Working Tree)	Resources repo://…, Tools search/edit	immer task-bezogen
Symbol-/Dependency-Graph	graph://…, impact_analysis	vor größeren Änderungen
Git-Historie	git://log, git://blame, diff resources	Root Cause, Ownership
Issue Tracker	issues://KEY	Start + Abnahme
CI/Test	tools run_*, resources ci://…	Verify-Loop
Docs / ADRs	memory://, docs://	Design, Constraints
Team Conventions	gepinnte Resource	jeder Implement-Turn
Secrets / Env	meist nie ins Window	Redaction

{ width=100% }

7.8.2 Working Set statt „Repo dump“

Working Set = minimale Menge an Artefakten, mit der ein kompetenter Dev starten würde.

Algorithmus (pragmatisch):

1. Issue-Entities parsen (Service, Error, File hints)
2. Code search / graph expand (1–2 Hops)
3. Rank nach Score (Pfad-Match, Symbol-Impact, Recency)
4. Budget kappen (Kap. 3)
5. Pinned: conventions + acceptance criteria

from dataclasses import dataclass


@dataclass
class WorkingSetItem:
    uri: str
    reason: str
    tokens: int
    score: float


def build_working_set(
    issue_text: str,
    candidates: list[WorkingSetItem],
    token_budget: int = 12_000,
    pinned: list[WorkingSetItem] | None = None,
) -> list[WorkingSetItem]:
    pinned = pinned or []
    used = sum(p.tokens for p in pinned)
    chosen = list(pinned)
    for c in sorted(candidates, key=lambda x: x.score, reverse=True):
        if c.uri in {x.uri for x in chosen}:
            continue
        if used + c.tokens > token_budget:
            continue
        chosen.append(c)
        used += c.tokens
    return chosen

7.8.3 Codebase-Kontext on-demand

Pattern Progressive Disclosure:

Stufe	Inhalt	Mechanismus
0	Pfade, Signaturen, Suchtreffer	search tool / graph cards
1	relevante Dateifenster / Symbole	resources/read
2	Nachbar-Dateien, Tests	expand on failure
3	Historie/blame	nur bei „warum“-Fragen

Scheitern Tests, steigt das Level gezielt (z. B. 0→1→2), statt vorsorglich die halbe Historie zu laden.

7.8.4 Git-Historie sinnvoll nutzen

Historie ist Gold – und Token-Gift, wenn roh.

Frage	Besserer Kontext
Wann kaputt gegangen?	git bisect tool + kurze commit messages
Wer kennt den Code?	blame summary, code owners resource
Warum so designed?	linked ADR / PR description
Was änderte sich im Release?	git://diff/v1.2.0...v1.3.0 aggregiert

Tool-Beispiele: git_log(path, n), git_blame(path), git_diff(base, head) mit serverseitiger Kürzung.

7.8.5 Issue-Tracker als Steuerkontext

Issues liefern Ziel und Constraints. Lade:

• Beschreibung, Labels, Linked PRs,
• Akzeptanzkriterien (strukturiert),
• nicht 200 Kommentare mit Memes – summarize tool server-seitig.

@mcp.tool
def get_issue_context(key: str) -> dict:
    raw = fetch_issue(key)
    return {
        "key": key,
        "title": raw["title"],
        "acceptance": extract_acceptance(raw["body"]),
        "constraints": extract_constraints(raw["body"]),
        "links": raw.get("links", []),
        "comment_summary": summarize_comments(raw.get("comments", [])),
    }

7.8.6 Dokumentation on-demand

Docs gehören in Resources mit gutem Catalog:

• docs://service/billing/overview
• docs://runbooks/payment-timeout

Agent sucht zuerst im Catalog (Metadaten), liest dann Full Body. Veraltete Docs: Memory-Status stale + Hinweis, Code/Tests als Source of Truth zu bevorzugen.

7.8.7 Phasen-spezifische Context Packs

Phasen wechseln nicht nur die Tools – sie wechseln das Informationsbedürfnis. Spec braucht Klarheit und Constraints; Implement braucht lokalen Code und Tests; Review braucht Diff und Akzeptanz; Incident braucht Runbook und frische Signale. Dieselben MCP-Server, andere Packs.

Phase	Pinned	On-demand	Tools dominant
Spec	Issue, Template-Prompt	verwandte Incidents	issues, memory read
Implement	AC, conventions, failing test	graph impact, files	repo, tests
Review	Diff, AC, CI summary	ADRs, threat model	read-only + notes write
Incident	Runbook prompt, alert	logs window, recent deploys	observability read

7.8.8 Referenz-Policy (kurz)

# context-policy.coding.yaml (illustrativ)
pinned_resources:
  - memory://project/conventions
budget_tokens:
  total: 24000
  code: 12000
  docs: 4000
  tool_results: 5000
  other: 3000
disclosure:
  start_level: 0
  max_level: 2
git:
  max_log_entries: 15
  prefer_paths_from_working_set: true
issues:
  include_comment_summary: true
  max_raw_comments: 0
safety:
  deny_resource_globs:
    - "repo://**/.env"
    - "repo://**/secrets/**"
  deny_tools:
    - "shell_raw"

Hosts lesen solche Policies und filtern MCP-Discovery entsprechend (CA-MCP, Kap. 5).

7.8.9 End-to-End: Issue → PR mit Context Trace

Der End-to-End-Lauf bündelt die Packs zu einer Geschichte, die du im Trace lesen können solltest: nicht „der Agent war fleißig“, sondern welche Resources, welches Budget, welche Verify-Schritte.

{ width=100% } Context Trace Summary (für Review): welche URIs geladen, welche Tools, Token-Spend – macht Agentenarbeit auditierbar.

---

Rollout im Team: pragmatische Stufen

Die Team-Stufen spiegeln die Autonomy Ladder in Kap. 11.9/11.10.7 (Phases 0–4) und die Privilege-Levels L0–L3 oben – hier als pragmatische Scope-Leiter, dort mit Harness-Gates und Error Budgets.

Stufe	Scope	Privilege (ca.)	Erfolgskriterium
1	Read-only Explain/Search	L0	Dev-Zufriedenheit, keine Incidents
2	Branch + Tests + Draft PR	L1–L2	Human Edit Rate sinkt
3	Review-Agenten kommentieren	L0–L1 (read + notes)	Review-Zeit, gefundene Defects
4	CI-Bots mit gleichen Servern	L0 + report tools	konsistente Quality Gates
5	Enge Auto-Merge-Pfade	L3 nur eng	Eval + Policy-Reife + Error Budget

Messt parallel: Lead Time, Change Fail Rate, Tokens/PR, Revert-Rate (DORA-nah [E2] + AI-Metriken [E4]). Bei Ampel-Rot Autonomy senken, nicht „mehr Modell“ (Kap. 11).

---

7.9 90-Tage-Nutzen-Messung – Scorecard

Zweck: Nutzen belegen oder Autonomy zurücknehmen. Kein ROI-Märchen.
Baseline: Woche 0–2 ohne Änderung der Autonomy-Stufe.
Scope: ein Team, ein Repo oder eine Service-Grenze – nicht die ganze Firma.
Die Zielbänder unten sind Engineering-Orientierung [E4] – keine Branchen-RCTs zu Agent+MCP (Stand 2026-07; Anhang F.2/F.8).

A) Outcome-Metriken (primär)

Metrik	Baseline (W0)	Ziel W12 (Orientierung [E4])	Ist W12	Ampel
Lead Time for Changes (med, h)		−10–20 % oder stabil bei ↑ Qualität
Change Fail Rate (%)		nicht schlechter
MTTR (med)		stabil/besser
% PRs mit Agent-Assist		bewusst gesetzt
Human Edit-Rate (nach Agent)		sinkend oder erklärt

B) Agent-System-Metriken (sekundär)

Metrik	Definition	W0	W12
Task Success (Eval-Suite, n≥20)	% Tasks mit automatischem Orakel grün
Steps / erfolgreichem Task	Median
Context Hit Rate	genutzte vs. geladene Ressourcen (Stichprobe)
Context Waste Proxy	Tokens oder Zeichen Prompt / Task
Tool Error Rate	failed tool calls / all
Escalation Rate	Tasks → Human vor Stopp
Policy Denies	blockierte Tool-calls (sollte bei sinnvoller Policy >0 sein)

C) Risiko-Metriken (Veto-fähig)

Signal	Schwelle (Beispiel)	Reaktion
Sev-1/2 mit Agent-Beteiligung	≥1 in 90 Tagen ohne Postmortem-Maßnahmen	Autonomy −1 Stufe
Unauditierte MCP-Server in Nutzung	>0	Katalog-Stopp
Prod-Credentials in Dev-Agent	>0	sofortiger Kill-Switch
Eval-Suite rot >7 Tage	ja	Merge-Stopp für Agent-Policy-Änderungen

D) Investitions-Check (0–2 Punkte je Zeile)

Fähigkeit	0	1	2	Score
Agent-ready Issues (DoR)
Verify-Orakel (Tests/Types) im Agent-Loop
Context Policy schriftlich
MCP-/Tool-Katalog mit Owner
Threat Model (Kap. 11 Template)
Traces für Postmortems
Summe / 12

Interpretation [E4]: ≥9 und Ampeln grün → Autonomy vorsichtig erhöhen · 6–8 → industrialisieren (Kap. 10–11), nicht multiplizieren · ≤5 → Host-Assist ok, kein Plattform-Narrativ.

E) Entscheidung am Tag 90

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

Referenzen: Kap. 6.5 Evals · Kap. 10 TRACE-DEMO · Kap. 11 Error Budgets · Anhang C/F.

Autonomy-Stufen ohne Scorecard sind Mut – nicht Messung:

Was wir (noch) nicht wissen: Welche Netto-Effekte Autonomy L2/L3 (Tool-Loops, MCP) in euren Teams auf Lead Time, CFR und Edit Rate wirklich haben – Completions-RCTs übertragen sich nicht 1:1 (Anhang F.2 [E1]; Agent-Feld-Lücke Stand 2026-07).

• Offene Fragen: 1) Ab welchem Orakel-/Review-Niveau steigt Task Success ohne CFR↑? 2) Wann dominiert Verification Tax (METR-Richtung [E1])?
• Widersprüchliche Evidenz: Completions-Gewinne [E1] vs. Senior-Verlangsamung auf reifen Repos [E1] vs. Scorecard-Orientierung dieses Kapitels [E4].
• Was die Aussage widerlegen würde: 90-Tage-Lauf ohne Baseline-Vergleich oder Autonomy↑ bei roter Eval und CFR↑ „trotzdem Erfolg“ genannt.
• Überprüfung: Scorecard 7.9 A–E; vor L2→L3 Canaries (Kap. 11).
• Was wir trotzdem tun [E4]: Baseline 2 Wochen; Ampeln + Invest-Check; Autonomy nur mit grüner Eval und stabiler CFR erhöhen.

---

Best Practices

1. Macht Tickets agent-ready, bevor ihr Automationen skaliert.
2. Koppelt „fertig“ an CI-objektive Signale.
3. Nutzt phasen-spezifische Context Packs und Policies.
4. Pinnt Conventions; ladet Code on-demand.
5. Speichert Design-Entscheidungen in Memory, nicht nur in Slack.
6. Trennt Privilege-Level (L0–L3) klar in MCP-Tool-Allowlists.
7. Liefert Context Traces mit jedem Agent-PR.

---

Pitfalls

Pitfall	Folge	Gegenmaßnahme	Kapitel-Querverweis
Agent auf Main ohne Protection	Chaos	Branch + Reviews	Kap. 7
Ganzes Repo als Kontext	Kosten, Fehler	Working Set	Kap. 7
Review nur durch LLM	blinde Flecken	Human Ownership	Kap. 7
Prod-Tools im Dev-Server	Blast Radius	getrennte Server/Creds	Kap. 7
Docs als alleinige Wahrheit	falsche Fixes	Tests/Code priorisieren	Kap. 7
Kein Feedback aus Incidents	wiederholte Fehler	Eval + Memory Updates	Kap. 7

---

Key Takeaways

• Agenten entfalten Wert über den gesamten SDLC, nicht nur beim Tippen von Code.
• Pro Phase gelten andere Ziele, Kontexte, Tools und Autonomiegrade.
• Implementierung braucht Working Sets, Verify-Loops und Branch-Disziplin.
• Review- und CI-Agenten skalieren Qualität, ersetzen aber keine Verantwortung.
• Context Engineering mit MCP orchestriert Codebase, Git, Issues, CI und Docs on-demand.
• Policies (Budget, Disclosure, Deny-Globs) machen Coding Agents beherrschbar.
• Rollout stufenweise und metrikgetrieben – die 90-Tage-Scorecard trennt Nutzen von Theater [E4].

---

Was als Nächstes kommt

Kapitel 8 skaliert von einzelnen SDLC-Agenten zu Multi-Agenten-Teams für komplette Softwareprojekte – inkl. Rollen, Handoffs und MCP als zentraler Kontext- und Tool-Schicht.

---

Übungsanregungen

1. Mappt eure Toolchain auf die SDLC-Phasen und markiert MCP-Lücken.
2. Definiert L0–L3 Privileges für euer Team und mappt sie auf die Kap.-11-Phasen inkl. Error-Budget-Schwellen.
3. Baut eine context-policy.coding.yaml für euren häufigsten Bugfix-Flow.
4. Schreibt eine Checkliste „agent-ready Issue“.