grok-bot
63589e684a
AI Act/OWASP und Residenz/Log-TTL in Kap. 19–20, Framing- und Taxonomie-Fixes quer durch Manuskript und Templates, Kap.-10-Anker im Assembler; Handoff fortgeschrieben.
14 KiB
Team, Ownership, Review
Sprint-Review: das Support-Feature „läuft“. Prompt steckt in drei Repos und einem Feature-Flag-JSON, das Golden Set hat seit dem Launch niemand angefasst, das Model-String ist gpt-…-latest in Service A und ein anderes Pin in Service B. On-Call kennt das HTTP-Runbook — wer bei Quality-Drop den Prompt freigibt oder das Eval-Gate bewegt, steht nirgendwo. Zwei Wochen später: stilles Provider-Update, Repair-Rate hoch, LGTM auf „klingt besser“ im Chat. Nicht die Technik ist kaputt — die Ownership.
Foundation-Model-Features erzeugen Artefakte, die Code ähneln und doch anders leben: Prompts, Golden Sets, Pins, Policies, Caps. Ohne benannte Menschen hinter jedem davon gilt These T10 nur auf dem Whiteboard.
Kern in einem Satz: Mensch bleibt Owner — von Prompt, Eval, Model-Pin, Index, Policy und On-Call: named humans, versionierte AI-Diffs im Review und freigabefähige Gates, nicht „das Team“ und nicht der Agent-Loop (T10, T3, T9).
Anschluss: Eval und Gates → Kapitel 17; Online-Qualität → Kapitel 18; Lifecycle und Pins → Kapitel 24; On-Call und Runbooks → Kapitel 25. Vorlagen: templates/production-ready-checklist.md, templates/model-change-checklist.md. Onboarding: checklists/team-onboarding-30-tage.md.
Bridge: Klassisches SE → AI Engineering
| Klassisches SE | AI Engineering … |
|---|---|
| Service-Owner / Product Owner | Capability-Owner + Artefakt-Owner (Prompt, Eval, Pin, …) |
| CODEOWNERS auf Pfaden | CODEOWNERS + Prompt-/Eval-/Config-Pfade und Gate-Approver |
| PR-Review (Code, Tests) | PR-Review plus Prompt-Diff, Config-Diff, Eval-Delta |
| Release Manager | Promote-Owner für Model/Prompt/Index-Bundle |
| On-Call für Deploy/Infra | On-Call inkl. Kill-Switch, Pin-Rollback, Cost-Cap |
| Platform: CI, Auth, Observability | Platform: Pin-Registry, Guardrail-Framework, Token-Accounting |
| Product: Domain-Logik | Product: Capability-Prompts, Domain-Eval, Spec-Metriken |
| Postmortem mit Action Items | dasselbe — plus Gate-, Pin- und Label-Schuld |
Die Brücke: euer SE-Ownership-Modell bleibt. Es muss explizit auf AI-Artefakte erweitert werden — sonst erbt „niemand“ Prompt und Golden Set.
Ownership-Matrix: named humans
„Team X owns AI“ ist keine Ownership. Ein Name (oder Rotation mit klarem Slot) pro Zelle:
| Artefakt / Pflicht | R (Responsible) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---|---|---|---|
| Feature-Spec / Success Metrics | Eng + PM | Product | Domain, Security | Support |
| Prompt / Template-Version | Capability-Eng | Capability-Lead | Eval-Owner, Safety | Platform |
| Golden Set + Labels | Eval-Owner | Capability-Lead | Domain-Reviewer | Eng |
| Eval-Gates (CI/Release) | Eval-Owner | Eng-Lead | Platform | Product |
| Model-Pin / Routing | Platform oder Capability (wählen) | benannter Pin-Owner | Security (Residenz), Cost | alle Consumer |
| Index / Corpus-Snapshot | Data/Search/Capability | Index-Owner | Privacy, Domain | Eng |
| Policy / Guardrail-Pack | Security/Platform | Security-Lead | Legal, Product | Eng |
| Caps / Cost envelope | Platform + Capability | Cost-Owner pro Feature | FinOps | Leadership |
| On-Call / Runbook | Capability on-call | Eng-Manager | Platform, Security | Status-Kanal |
Minimal: vier Namen vor Launch — Prompt, Eval, Model-Pin, On-Call — siehe production-ready-checklist.md. Rotation ist ok; leere Zellen nicht.
Wer entscheidet was?
| Entscheidung | Empfohlener Approver (in diesem Modell) | Nicht ausreichend |
|---|---|---|
| Model-Change / Pin-Move | Pin-Owner + Checklist grün | „hat im Chat besser gewirkt“ |
| Prompt-Promote nach Prod | Prompt-Owner + Eval-Gate | Hotfix ohne Version |
| Gate-Schwelle lockern/straffen | Eval-Owner + Capability-Lead | stilles Threshold-Tweaking |
| Policy-/Safety-Pack | Security (+ Legal bei Scope) | nur Prompt „sei sicher“ |
| Tool mit Side Effects freigeben | Capability + Security | LGTM auf Demo |
| Feature flag off im Incident | On-Call (Runbook) | warten auf denselben Autor |
RACI hier ist Arbeitsmittel, kein Konzern-Ritual. Wenn zwei Teams dasselbe Feature deployen, eine Accountable-Zeile — sonst zwei widersprüchliche Pins.
Platform vs. Product
| Zentral (Platform / AI-Enabling) | Dezentral (Product / Capability) |
|---|---|
| Pin-Registry, Default-Routing-Tiers | Capability-Prompts und Tool-Wahl im Domain-Kontext |
| Guardrail- und Policy-Framework | Domain-Failure-Modes und Golden-Slices |
| Token-Accounting, Budgets, Quotas | Feature-Envelope (€/Task, Latency-SLO) |
| Shared Observability (Trace-Schema, Version-Felder) | Dashboards und Alerts der Capability |
| Model-Change-Prozess, CI-Bausteine | Durchführung der Checklist pro Release |
| Security-Baselines, Secret-Handling | Threat-Model des konkreten Features |
| Provider-Vertrag / Residenz-Defaults | Ausnahme-Anträge und Datenklassen im Feature |
Decision Frame: zentraler Platform-Owner vs. pure Product ownership
| Signal | Tendenz |
|---|---|
| Viele Capabilities, gemeinsamer Provider, gemeinsame Rechnung | Platform für Pins, Accounting, Guardrail-Runtime |
| Eine isolierte Capability, starkes Domain-Risiko | Product hält Prompt/Eval eng; Platform liefert nur Bausteine |
| Pin-Drift und „jedes Team sein Model-String“ | Registry zentral, Promote-Recht klar |
| Platform als Flaschenhals für jedes Komma im Prompt | Prompts und Domain-Eval dezentral, Gates teilen |
| Security/Residenz unklar | Platform/Security Accountable für Defaults |
Anti-Muster der Mitte: Platform „besitzt alles AI“, Product „schickt nur Tickets“ — dann verrotten Domain-Evals. Umgekehrt: jedes Squad pflanzt eigene Pins und Policies — dann brennt On-Call ohne gemeinsame Hebel.
Coding-Agent vs. Produkt-Agent
| Coding-Agent (Dev-Tool) | Produkt-Agent (im Produkt) | |
|---|---|---|
| Nutzer | Entwickler:innen | Endnutzer / interne User des Produkts |
| Ownership | DevEx / Platform-Engineering | Capability + Product |
| Risiko | Repo, Secrets im Dev, Supply Chain | User-Daten, Writes, Brand, Regulierung |
| Eval | oft manuell, PR-Diff, Tests im Repo | Golden Set, Online-Metriken, Safety suite |
| Hier im Buch | Abgrenzung; Tiefe → Coding Agents in der Praxis | Hauptgegenstand (Harness, Loop, Tools) |
Beide brauchen Review und Caps. Nicht vermischen: ein Coding-Agent, der Prod-Prompts „mal optimiert“ ohne Gate, ist ein unauthorisierter Release-Kanal. Produkt-Agenten erben die Ownership-Matrix oben; Coding-Agents erben Repo- und Secret-Policy eures Dev-Stacks.
AI-Diffs reviewen
Code-PR allein genügt nicht. Was in denselben Review-Strom gehört:
| Diff-Typ | Review-Fokus |
|---|---|
| Prompt / Template | Intent, Constraints, Tool-Hinweise, Leakage, Ton; Diff lesbar versioniert |
| Config (pin, caps, flags, routing) | Envelope, Rollback, wer promote darf |
| Schema / Tool-Contract | Breaking vs. additive; Validierung; Side Effects |
| Eval / Golden Set | Label-Änderungen = Gate-Move; neue Failure Modes? |
| Gate-Schwellen | Begründung, Baseline-Delta, Risiko |
| Policy-Pack | Strenger/locker, False-Refuse vs. Safety |
| Index-Pipeline | Corpus-Quelle, Privacy, Snapshot-ID |
Review-Checkliste für AI-PRs
Vor Approve (an Spec und model-change-checklist.md anbinden):
- Versionen:
prompt_version(prompt_id@semver oder Content-Hash),model_id, ggf.index_version, config version — und werden sie getraced? - Schema / Structured Output: Validierung und Repair-Caps gesetzt?
- Safety: Input/Output-Pfade, Tool-Deny, keine Secrets in Prompts/Logs.
- Cost envelope: Tier, max tokens/steps, Budget-Caps; grobe Estimate bei Model-/Pfad-Wechsel.
- Eval-Gate: Offline grün gegen aktuelles Golden Set; Delta erklärt wenn Scores sich bewegen.
- Rollback: last-known-good Pin/Flag in Minuten aktivierbar?
- Owner: Prompt/Eval/Pin-Owner im PR oder CODEOWNERS sichtbar?
- Kein Vibe-LGTM: „klingt gut“ ohne Gate und Diff-Begründung ist kein Approve.
Decision Frame: Code-Review-only vs. AI-Artefakt-Review
| Lage | Wahl |
|---|---|
| Nur Orchestrator-Refactor, gleiches Prompt/Pin | Code-Review + bestehende Contract-Tests oft genug |
| Prompt, Pin, Gate oder Policy ändert sich | Artefakt-Review + Mini-Eval Pflicht |
| Hochrisiko (Writes, PII, Safety) | Security mit C/A; kein Fast-Track |
| Dringender Incident-Hotfix | versionierter Fix + nachziehen: Gate und Postmortem |
Patterns und Trade-offs
Pattern: Ownership-Matrix als Living Doc
Eine Seite pro Capability (Wiki/Repo): Tabelle oben + Links zu Runbook, Dashboards, Pins. Im Onboarding Woche 4 abhaken (team-onboarding-30-tage.md).
Trade-off: Pflege; ohne sie erbt Slack die Wahrheit.
Pattern: CODEOWNERS für prompts/, evals/, policies/
Pflicht-Reviewer analog zu kritischem Code.
Trade-off: etwas mehr Latency im PR; weniger anonyme Hotfixes.
Pattern: Eval-Change braucht zwei Augen
Label- oder Threshold-PR: Autor ≠ alleiniger Approver (Domain oder zweiter Eng).
Trade-off: Prozess; schützt vor „Gate grün machen durch Relabeln“.
Pattern: Promote-Recht ≠ Merge-Recht
Merge in main darf CI grün sein; Prod-Pin-Move nur Pin-Owner nach Checklist.
Trade-off: zwei Stufen; verhindert „merged = production model“.
Trade-off: Hero-Engineer vs. bus-factor ≥ 2
| Hero | Verteilte Ownership |
|---|---|
| schnell am Anfang | langsamer Konsens |
| Urlaub = Risiko | Rotation und Docs |
| implizites Wissen | reviewbare Artefakte |
Für Prod-Capabilities: mindestens zwei Personen können Pin rollbacken und Golden Set erklären.
Anti-Patterns
| Anti-Pattern | Symptom | Besser |
|---|---|---|
| Everyone owns nothing | „das AI-Team“ ohne Namen | Matrix mit R/A |
| Prompt-Hotfix ohne Review | Prod-String aus Slack | versionierter PR + Gate |
| Eval owned by nobody | veraltetes Golden Set | named Eval-Owner (T3, T10) |
| Model string per service | Drift, Incident-Chaos | Pin-Registry (T9) |
| LGTM on vibe | Score egal, Demo gut | Diff + Eval-Delta |
| Hero-Engineer | eine Person weiß alles | Pair, Docs, Rotation |
| Platform owns all prompts | Domain-Blindheit, Queue | Prompts dezentral, Framework zentral |
| Product owns pins secretly | Residenz/Cost umgangen | Pin-Owner + Security C |
| Coding-Agent schreibt Prod-Prompt ungeprüft | unkontrollierter Release | gleicher Review-Pfad |
| Gate move ohne Changelog | „plötzlich grün“ | Label-PR mit Begründung |
| On-Call ohne AI-Hebel | nur HTTP-Restart | Runbook: flag, cap, pin (Kapitel 25) |
| Ownership nur im Org-Chart | Wiki 2024, Reality 2026 | Matrix im Repo, Review-Pflicht |
Production Notes
Cost. Unklare Ownership erzeugt teure Doppel-Evals, Shadow-Verkehr ohne Cap und Hero-Firefights. Cost-Owner pro Feature (Envelope) und Platform-Accounting gehören zusammen (T7, Kapitel 23). Review-Zeit für Prompt/Eval ist Produktkosten — billiger als unreviewter Pin-Drift.
Latency. Mehr Approver verlängern Lead Time. Kompensieren: kleine, häufige AI-Diffs; schnelle Contract-Tests im PR; schwere Golden-Läufe staged. Flaschenhals „nur eine Person reviewed alle Prompts“ ist ein Organisations-Bug, kein Naturgesetz.
Observability. Ownership ohne Telemetrie ist Theater: Traces müssen prompt_version, model_id, feature_key tragen, sonst kann der Owner nicht haften (Kapitel 22). Alerts verlinken Runbook und namentliche Eskalation.
Security. Policy- und Tool-Freigaben sind Security-Ownership, nicht „Prompt-Polishing“ (T8). Coding-Agents und Produkt-Agenten teilen Secret- und Data-Klassen-Disziplin; Evidence und Logs bleiben redacted (Kapitel 19, 20).
Lifecycle. Model- und Prompt-Changes sind Team-Prozesse: Checklist, Canary, Rollback-Owner (Kapitel 24). Production-Ready heißt: Matrix ausgefüllt, AI-PR-Review etabliert, Onboarding-Checkliste grün — nicht „Feature demoed“.
Key Takeaways
- T10: Mensch bleibt Owner — freigeben, eskalieren, rollbacken; der Loop ersetzt keine Named Accountability.
- Ownership-Matrix für Prompt, Eval, Model-Pin, Index, Policy, Caps, On-Call — Namen, nicht Abteilungsnebel.
- Platform zentralisiert Pins, Guardrail-Runtime und Accounting; Product besitzt Domain-Prompt und Domain-Eval.
- AI-PRs: Prompt-, Config- und Eval-Diffs reviewen; Checkliste Schema, Safety, Cost, Versionen, Rollback.
- Coding-Agent (Dev-Tool) und Produkt-Agent (im Produkt) trennen — gleicher Ernst, andere Owner und Risikoflächen.
- Anti-Patterns: everyone owns nothing, Vibe-LGTM, Eval ohne Owner, Pin-Wildwuchs, Hero-only.
- Vorlagen und Einstieg: production-ready-checklist.md, team-onboarding-30-tage.md.
Praktische nächste Schritte
- Schreibt für die Top-Capability eine Ownership-Matrix (vier Pflichtnamen: Prompt, Eval, Pin, On-Call) ins Repo.
- Erweitert CODEOWNERS (oder Äquivalent) um
prompts/,evals/, Policy-Pfade. - Hängt die AI-PR-Review-Checkliste an euren PR-Template; verbietet unversionierte Prod-Prompt-Edits.
- Klärt schriftlich: wer Model-Pin moved (Platform vs. Capability) und welcher Prozess gilt (model-change-checklist.md).
- Lauft team-onboarding-30-tage.md bzw. Production-Ready-Check gegen ein bestehendes Feature; Lücken als Tickets mit Owner.
- Organisation skalieren und Pilot→Platform: Einführung im Unternehmen.