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.
24 KiB
Anhang B: Anti-Patterns
Dieser Anhang ist der buchweite Katalog: Early-Warning-Signale, Risiken und Gegenmittel an einem Ort. In den Kapiteln 03–28 stehen lokale Anti-Pattern-Tabellen im Kontext von Mechanik, Organisation und Production Notes — dort lohnt das Lesen, wenn du gerade am jeweiligen Thema baust. Hier konsolidieren wir, was in Reviews, Postmortems und Launch-Gates immer wieder denselben Schaden anrichtet.
Anti-Patterns sind keine „dummen Fehler von Anfängern“. Sie entstehen oft aus gutem Druck (Demo-Termin, Vendor-Hype, fehlende Ownership) und fühlen sich im Moment effizient an. Das Gegenmittel ist selten ein längerer Prompt — meist Spec, Caps, Code-Policy, Eval-Gate oder ein named Owner.
Verwandt: Anhang D Entscheidungsmatrizen, production-ready-checklist, security-review-ai.
Wie lesen
Jede Zeile folgt denselben Spalten:
| Spalte | Bedeutung |
|---|---|
| Name | Kurzer, wiedererkennbarer Label (im Team-Jargon nützlich) |
| Symptom | Was du in Code, Reviews, Traces oder Meetings siehst |
| Risiko | Warum das in Prod wehtut (Qualität, €, Security, Ops) |
| Gegenmittel | Erste, konkrete Korrektur — nicht die ganze Architektur neu |
| Kapitel | Vertiefung im Manuskript |
Nutzung: Beim Spec-Review, Architecture-Review und Incident-Postmortem die passende Gruppe scannen. Wenn drei Symptome aus einer Zeile zusammenkommen, ist das kein Bauchgefühl — das ist ein Blocker-Kandidat (siehe Top-10 unten).
Spec & Adaptation
Ampel, Spec-Envelope, Architecture Patterns und Adaptation Ladder (Kapitel 05–08; Modelle/FT: 09, 15).
| Name | Symptom | Risiko | Gegenmittel | Kapitel |
|---|---|---|---|---|
| Lösung vor Problem | Kickoff startet mit Modell-/Vendor-Namen | Falsches Werkzeug, Budget verbrannt | Job-to-be-done + Ampel vor Stack-Wahl | 05 |
| LLM als Business-Rule-Engine | Rabatte, ACLs, SLA-Regeln nur im Prompt | Stille Policy-Brüche, nicht testbar | Policy im Code; LLM erklärt höchstens | 05 |
| Grünwaschen | Hohes Risiko, „wir prompten vorsichtig“ | Incidents ohne HITL/Gate | Gelb/Rot ehrlich; HITL oder nicht shippen | 05 |
| Prompt-as-Spec | „Steht im System-Prompt“ = Anforderung | Drift, kein Review, kein Orakel | Spec im Repo; Prompt implementiert Contracts | 06 |
| Metrik-Theater | 20 KPIs, keine Gate-Schwelle | Optimierung ohne Steuerung | 3–6 Metriken mit Zielen und Owner | 06 |
| Budget später | Erste Rechnung = Architektur-Review | Cost-Spike, Panik-Routing | Envelope + Alerts von Tag 1 | 06 |
| Chat als Architektur | Ein Thread = Business-Prozess | Nicht rekonstruierbar, nicht skalierbar | Pattern + State außerhalb des Transcripts | 07 |
| Prompt-as-Control-Plane | Policies/Preise nur im System-Prompt | Injection umgeht „Policy“ | Policies im Code; Prompt für Sprache/Format | 07, 11 |
| Ladder-Skipping | FT oder freier Agent im Kickoff, kein Golden Set | Kosten und Ops ohne Qualitätsbasis | Stufe 2–3 + Eval zuerst | 08 |
| FT als Wiki | „Wir trainieren die Policies ein“ | Veraltete Gewichte, teure Korrektur | RAG + versionierte Policy im Code | 08, 15 |
| Demo-Stufe | Stakeholder-Demo → Prod-Default | Ungetestete Failure Surface | Ampel, Spec, Climb Signals, Eval-Gate | 08 |
| Strong-by-Default | Ein Frontier-Modell für alle Tasks | Unit Economics und Latency sterben | Tiers + Routing nach Task; pin | 09 |
Context, Prompt, RAG
Context-Assembly, Prompt als Interface, Retrieval (Kapitel 10–12).
| Name | Symptom | Risiko | Gegenmittel | Kapitel |
|---|---|---|---|---|
| Context-Maximalismus | Ganze DBs/PDFs „zur Sicherheit“ im Prompt | Kosten, Latency, Signal ertrinkt | Diät, Top-k, stufenweises Nachladen | 10 |
| Transcript als State | Business-State nur im Chat-Log | Verlorene Wahrheit, kaputte Multi-Turn | Working-State in Domain/Workflow | 10 |
| Memory-Staubsauger | Alles speichern, nichts löschen | Privacy, Drift, falsche Prefs | Tiers, Consent, Retention, Korrektur-UI | 10 |
| PII erst im UI | Provider/Traces sehen Rohdaten | Leak, Compliance-Bruch | Redaction in der Assembly-Pipeline | 10, 20 |
| Prompt-Zoo | Dutzende Varianten in Notion/Slack | Kein Rollback, keine Attribution | Ein Repo, IDs, Owner, Review | 11 |
| Freitext-als-API | Downstream parst Prosa mit Regex-Hoffnung | Fragile Integrationen | Structured Output + harte Validation | 11 |
| Schema ohne Validate | „JSON mode an“ = fertig | Müll-JSON in Prod | Validation + Repair-Cap + Fallback | 11 |
| Unversionierter Prompt | Prod-Verhalten nicht rekonstruierbar | Incidents ohne Diff | prompt_version pin + Traces |
11 |
| Magic Words Engineering | „IMPORTANT!!!“-Spiralen statt Contract | Pseudo-Fortschritt, Context-Ballast | Schärferes Schema, Eval, richtiger Context | 11 |
| Vektor-DB = fertig | Index ohne Eval/ACL/Freshness | Falsche Evidenz, Leaks | RAG als System + Checkliste | 12 |
| Generate ohne Refuse | Modell füllt Lücken aus Pretraining | Halluzination mit Autoritäts-Look | Evidenz-Contract + Refuse | 12 |
| Index ohne ACL | Ein Index, Multi-Tenant-Queries | Cross-Tenant-Leak | ACL/Filter von Tag 1; Isolationstests | 12 |
Tools & Agents
Function Calling, Side Effects, Workflow vs. freier Loop (Kapitel 13–14).
| Name | Symptom | Risiko | Gegenmittel | Kapitel |
|---|---|---|---|---|
| God-Tool | execute(action, payload) / freies Shell |
Unkontrollierte Side Effects | Enge, benannte Tools + Contracts | 13 |
| AuthZ im Prompt | „Rufe nur erlaubte …“ | Prompt-Injection = Privilege Escalation | Server-side AuthZ vor jedem Tool | 13, 19 |
| Tenant aus Args | Modell wählt tenant_id |
Cross-Tenant-Write/Read | Tenant aus Session/Identity | 13 |
| Write ohne Idempotenz | Doppel-Tickets, Doppel-Charges | Geld- und Trust-Schaden | Idempotency-Keys vor erstem Write | 13, 16 |
| Roh-Output in Context | 200 KB JSON + Secrets in die nächste Runde | Cost, Injection, Leak | Project + clip + redact | 13 |
| Shell/HTTP free-for-all | Beliebige URLs/Commands | SSRF, Exfil, RCE-Fläche | Allowlist, SSRF-Guards, least privilege | 13 |
| Agent by Default | Jedes Feature „ist ein Agent“ | Unbounded Steps, unklare Ownership | Pipeline zuerst; Agent-Readiness | 14, 07 |
| Unbegrenzter Loop | Steps ohne Cap | Cost- und Latency-Bombe | max_steps / cost / timeout |
14 |
| Coding-Agent-Kopie | Dev-Shell-Rechte im Produkt | Produkt-Threat-Model verfehlt | Getrennte Threat Models; ki-praxis ≠ Prod | 14 |
| HITL-Theater | Approve-Button ohne Diff/Risk-Kontext | Rubber-Stamp, Schein-Sicherheit | Kontextreiche Freigabe + Audit | 14 |
| Eval = Happy Transcript | Ein Demo-Pfad als „Agent-Test“ | Failure Modes unentdeckt | Trajectory-Set inkl. Fails | 14, 17 |
| Ein Agent für die Firma | Eine Loop-Oberfläche für alle Jobs | Unendliche Failure Surface | Enge Capabilities pro Schnitt | 14 |
Orchestrierung
Control Flow im Code, Validate/Repair, Outcomes (Kapitel 16).
| Name | Symptom | Risiko | Gegenmittel | Kapitel |
|---|---|---|---|---|
| Prompt as Orchestrator | Ablauf nur in Prosa beschrieben | Nicht steuerbar, nicht testbar | Graph/State Machine im Code | 16 |
| Infinite Repair | validate-fail → ewige Schleife | Token-Sturm, hängende UX | Repair-Cap + Fallback/Refuse | 16 |
| Retry everything | 10× gleicher Call bei jedem Fehler | Verstärkt Outages und Kosten | Fehlerklassen trennen; Circuit Breaker | 16, 21 |
| Happy-Path only | Kein Fallback in Spec/Code | Stille 200 oder harte 500 | Outcome-Taxonomy (success / success_degraded / refuse / needs_human / …) |
16 |
| Chat as State | Orchestrierungs-State im Transcript | Race, Replay, Lost Updates | Externes State-Objekt | 16 |
| SDK in the Controller | UX ruft Provider-SDK direkt | Keine Caps, keine Attribution | Model Access + Orchestrator trennen | 16, 07 |
| Silent 200 | Müll oder leerer Body als „OK“ | Nutzer-Trust, Support-Last | refuse / degraded UX spezifizieren |
16 |
| Budget im Bauchgefühl | Rechnung überrascht | Keine Steuerung (T7) | Budget object + feature_key + Alerts | 16, 23 |
| Idempotenz später | Side Effects ohne Keys | Doppelte Buchungen unter Retry | Keys vor erstem Write-Tool | 16 |
| Framework = Design | Niemand kennt den echten Graph | Vendor-Lock-in der Gedanken | Eine Seite Architektur-Skizze zuerst | 16 |
Eval & Online Quality
Offline-Gates, Online-Signale, Canary (Kapitel 17–18).
| Name | Symptom | Risiko | Gegenmittel | Kapitel |
|---|---|---|---|---|
| Vibe QA | „Klingt gut“ als Abnahme | Regression unbemerkt | Golden Set + Task-Metrik | 17 |
| Nur Demo-Set | 5 Happy Paths | Prod-Failure Modes offen | Failure Modes + adversarial Slices | 17 |
| Judge without anchors | LLM-Judge-Score ohne Rubrik | Score-Theater | Rubrik, Kalibrierung, Human-Anker | 17 |
| Gate theater | Score sinkt, Ship trotzdem | Eval als Dekoration | Harte Blocker vor Merge/Promote | 17 |
| Eval owned by nobody | Veraltetes Set, niemand pflegt | Falsche Sicherheit | Named Owner (T10) + Cadence | 17 |
| Metric vanity | BLEU/„Ähnlichkeit“ ohne Task-Bezug | Optimierung am Job vorbei | Task Success + Spec-Metriken | 17 |
| Offline-only confidence | Prod unmonitored | Drift erst im Support-Ticket | Online proxies + Canaries | 18 |
| HTTP-green = quality-green | 200 mit Unsinn | Stille Degradation | Outcome + Task-Metrics im Panel | 18, 22 |
| Big-bang model swap | Alias auf neu, beten | Wochenend-Incident | Shadow → Canary → pin | 18, 24 |
| Hotfix prompt in prod | Keine Version, kein Gate | Unreproduzierbar, zweites Incident | Version + Mini-Eval vor Promote | 18 |
| Shadow with side effects | Doppelbuchungen im Shadow | Echte Schäden im Test | Dry-run / read-only Shadow | 18 |
| Alert fatigue | Alle Schwellen dauerhaft rot | Echte Drops werden ignoriert | Wenige, spez-gekoppelte Alerts + Runbook | 18 |
Security & Privacy
Injection, AuthZ, Logs, Trust UX (Kapitel 19–20).
| Name | Symptom | Risiko | Gegenmittel | Kapitel |
|---|---|---|---|---|
| Security by prompt | Nur „folge der Policy“ | Injection umgeht Prosa | Code-Gates + least privilege | 19 |
| Model as AuthZ | Berechtigung im Prompt formuliert | Privilege Escalation | Echte AuthZ vor Tools | 19 |
| Trusted retrieval | Jedes Doc = Instruction | Indirekte Injection | Untrusted slots + Hygiene | 19, 12 |
| No red team | Erste Injection in Prod | Späte, teure Lektion | Safety-Suite vor Launch | 19 |
| Ignore indirect injection | Nur Chat-Filter | Docs/Tools/Mails als Angriffsvektor | Gesamte Trust Boundary mappen | 19 |
| Alert without kill-switch | Erkennen, nicht stoppen | Bleed bis Deploy-Pipeline | Feature-Flag / disable capability | 19, 25 |
| Privacy by prompt | „Gebe keine PII preis“ als einzige Maßnahme | Leak über Output und Logs | Minimierung + Filter + ACL | 20 |
| Log full prompts forever | Unbegrenzte Klartext-Traces | PII-See, Subprocessor-Risiko | TTL, redaction, ACL, Sample | 20, 22 |
| Global vector soup | Ein Index für alle Tenants | Cross-Tenant-Retrieval | Harte Isolation + Tests | 20 |
| Secrets in system prompt | Keys im Template | Exfil über Logs/Output | Secret store, nie Context | 20 |
| Trust theater | Badge „AI-powered“ ohne Limits | Erwartungsbruch, regulatorisches Risiko | Ehrliche UX + HITL wo nötig | 20 |
| Delete = UI only | „Löschen“ lässt Index/Memory | DSGVO/Vertrauensbruch | Technischer Löschpfad end-to-end | 20 |
Serving, Observability, Cost, Lifecycle, Incidents
Betriebsschicht (Kapitel 21–25).
| Name | Symptom | Risiko | Gegenmittel | Kapitel |
|---|---|---|---|---|
| Timeout = SDK-Default | Hängende Requests, random 504 | UX und Resource-Leaks | Explizite Timeout-Hierarchie | 21 |
| Retry-Sturm bei 429 | Aggressive Retries verschlimmern Quota | Cascade Outage | Backoff, Circuit, degrade | 21 |
| Health = Prozess up | Pod grün, Capability rot | Traffic auf toten Pfad | Synthetic Canary auf dem User-Pfad | 21 |
| HTTP-only monitoring | 200 mit Müll | Quality-Bleed unsichtbar | Outcomes + Quality-Signals | 22 |
| No model_id in prod | „Irgendein GPT“ in Traces | Kein Pin, kein Diff, kein Rollback | pin + Pflichtfeld in Traces | 22, 24 |
| Provider console as Obs | Nur Vendor-Dashboard | Keine Feature-Attribution | Eigene Telemetrie pro feature_key |
22 |
| Cloud-bill as metric | Eine Zahl, keine Features | Keine Steuerung | €/feature, €/success | 23 |
| Optimize model only | Context 100k Tokens, teures Tier | Falscher Hebel (T4 vor T7-Illusion) | Context-Diät und Caps zuerst | 23, 10 |
| SLO without quality | Stabiler Müll unter Latency-Ziel | Erfolgreich falsche Service | Quality-SLO neben Latency/Error | 23 |
| latest in prod | Unpinned Alias, unerklärliche Deltas | Breaking Change ohne Deploy | pin + registry + Change-Checklist | 24, 09 |
| No rollback path | „Muss fixen“ unter Druck | Verlängerte Incidents | Pin zurück in Minuten + Flag | 24 |
| „Modell schuld“ ohne Trace | Blaming ohne Versionen/Evidence | Falsche Mitigation | Evidence-Pack first | 25 |
Team & Organisation
Ownership, Einführung, Reife (Kapitel 26–28; Fundamente auch 03). Kapitel 26–28 vertiefen die Organisationsseite; die Einträge hier sind der konsolidierte Early-Warning-Satz — auch wenn ein Kapitel noch skizzenhaft ist.
| Name | Symptom | Risiko | Gegenmittel | Kapitel |
|---|---|---|---|---|
| Everyone owns nothing | „Die AI-Leute“; Prompt/Eval/Model ohne Namen | Incidents ohne On-Call, veraltete Sets | Named Owner pro Capability (Prompt, Eval, Model, Tools) | 26, 03 |
| Rollen-Wirrwarr | AI-Skill ohne SLO-/Incident-Scope | Orphans im Betrieb | Feature-Owner + klare Review-/On-Call-Pflichten | 26, 03 |
| Review ohne Eval | LGTM auf Formulierungsästhetik | Regression per Merge | Golden-Set-Delta vor Merge | 26, 11 |
| Prompt-Engineering-Only-Hire | Stelle ohne System-/Security-Scope | Theater-Rolle ohne Lieferfähigkeit | SE-Profil mit AI-Skills; Prompt als Teilskill | 03, 26 |
| Pilot theater | Ewiger PoC, nie Production-Ready-Check | Budget und Glaubwürdigkeit verbrannt | Exit-Kriterien: Spec, Eval, Obs, Security, Owner | 27 |
| Demo-Definition of Done | Stakeholder-Applaus = Ship | Prod ohne Gate | Messbare Success Metrics + Checklist | 03, 27 |
| Platform before product | Shared Platform ohne ein grünes Feature | Leere Abstraktionen, Adoption null | Ein Job in Prod, dann Plattform extrahieren | 27 |
| Vendor als Strategie | Roadmap folgt Release-Notes | Fremdbestimmte Prioritäten | Jobs-to-be-done + Unit Economics | 05, 27 |
| Maturity theater | Reifegrad-Scorecard ohne Golden Sets/Caps | Selbsttäuschung im Management | Levels an harten Artefakten messen (Eval, pin, kill-switch) | 28 |
| Center-of-Excellence-Theater | Zentrales Team blockiert oder deliver’t Demos | Shadow-IT und Doppelarbeit | Enablement + klare Plattform-Schnitt; Feature-Teams delivern | 27, 26 |
| Postmortem without owners | Action Items ohne Datum und Namen | Wiederholung desselben Incidents | Datierte Owner; Follow-up im nächsten Review | 25, 26 |
| Climb without Owner | Index/Tools/FT ohne Verantwortliche | Ladder-Aufstieg = Ops-Kollaps | Owner vor Adaptation-Stufe (T10) | 08, 26 |
Gegenmittel-Matrix (Kurz)
Symptom-Cluster → erste Maßnahme (nicht die ganze Roadmap).
| Symptom-Cluster | Erste Maßnahme | Danach oft |
|---|---|---|
| „Klingt gut“, Demo grün, Prod rot | Golden Set + Task-Metrik anlegen | Online proxies, Slices |
| Hohe Token-Rechnung, schwache Qualität | Context-Diät + tokens_per_slot messen |
Routing/Tiers, Cache mit Policy |
| Unerklärliche Verhaltensänderung | model_id + prompt_version in Traces prüfen |
Pin, Rollback, Canary-Disziplin |
| Policy-Brüche trotz „striktem Prompt“ | Policy in Code; AuthZ vor Tools | Safety-Suite, Allowlist |
| Agent-Loops / Cost-Spikes | Caps: steps, tokens, timeout, cost | Pipeline statt freiem Loop |
| 200 OK, Nutzer unzufrieden | Outcome-Taxonomy + Quality-Panel | Canary-Stop auf Quality, nicht nur 5xx |
| Cross-Tenant-Verdacht | Isolationstests auf Index/Cache/Tools | ACL by design, Tenant aus Session |
| Shadow/Canary „macht kaputt“ | Side-effect-freie Shadow-Pfade | Getrennte Credentials, dry-run Tools |
| Team streitet über „nächstes Modell“ | Spec + Eval-Delta auf aktuellem Pin | Ladder/ADR, nicht Vendor-Blog |
| Keiner reagiert auf Dashboard | Named On-Call + Runbook + 3 Alerts | Kill-switch üben |
| Pilot ohne Ende | Production-Ready-Checklist als Exit | Owner, Envelope, Security-Review |
| Reifegrad-Folien ohne Artefakte | Artefakt-Check: Eval, pin, redaction, flag | 90-Tage-Plan an echten Gaps |
Top-10 „stop shipping until fixed“
Harte Blocker: nicht mit „wir monitoren das“ überdecken. Bis behoben: Feature-Flag aus oder Launch stoppen.
| # | Blocker | Warum hart | Mindest-Fix |
|---|---|---|---|
| 1 | AuthZ im Prompt / Model as AuthZ | Injection = Privilege Escalation | Server-side AuthZ vor jedem Tool |
| 2 | Write-Tools ohne Idempotenz + Caps | Doppelte Side Effects unter Retry/Loop | Keys + max tool calls / max steps |
| 3 | Kein Kill-Switch / Feature-Flag | Bleed bis die Pipeline durch ist | Disable capability in Minuten |
| 4 | Unpinned latest in Prod |
Fremde Breaking Changes ohne Deploy | Pin + Change-Prozess |
| 5 | Kein Eval-Gate bei Prompt/Model-Change | Regression als Normalzustand | Golden-Set-Blocker vor Promote |
| 6 | Multi-Tenant ohne Isolationstests (Index/Cache/Tools) | Daten-Leak zwischen Kunden | Harte Isolation + automatisierte Tests |
| 7 | Secrets oder Roh-PII im Context/Logs ohne Redaction | Exfil und Compliance-Bruch | Secret store; redaction pipeline; TTL |
| 8 | God-Tool / free-form Shell-HTTP | Unkontrollierte Angriffsfläche | Enge Contracts, Allowlist |
| 9 | Shadow/Canary mit echten Side Effects | „Test“ produziert Produktionsschäden | Read-only / dry-run Shadow |
| 10 | Everyone owns nothing (Prompt/Eval/Model/On-Call) | Niemand stoppt den Bleed | Named Owner + Runbook vor Traffic |
Ergänzende Checklisten: security-review-ai.md, production-ready-checklist.md, agent-readiness.md, rag-production-ready.md.
Key Takeaways
- Anti-Patterns sind Early-Warning-Signale, keine moralische Kategorie — sie entstehen unter Druck und fühlen sich oft „pragmatisch“ an.
- Kapitel-Tabellen bleiben die lokale Vertiefung; dieser Anhang ist der Scan für Reviews und Postmortems.
- Die meisten Gegenmittel sitzen in Spec, Code-Policy, Caps, Eval und Ownership — nicht im nächstlängeren Prompt.
- Drei Symptome aus einer Zeile oder ein Treffer in den Top-10: Ship stoppen, fixen, dann trafficen.
- Ohne named Owner (T10) kehren gelöschte Anti-Patterns im nächsten Quartal zurück.
Praktische nächste Schritte
- Nimm ein laufendes AI-Feature und markiere in diesem Anhang alle zutreffenden Zeilen (15 Minuten).
- Sortiere: Top-10-Treffer zuerst; Rest in Backlog mit Owner und Datum.
- Verlinke die Gegenmittel in Spec/ADR und im incident-runbook-ai.
- Mach den Katalog zur festen Agenda-Zeile im Architecture- und Launch-Review — nicht zur einmaligen Lektüre.