52 lines
4.8 KiB
Markdown
52 lines
4.8 KiB
Markdown
---
|
||
created: 2026-09-06
|
||
updated: 2026-09-06
|
||
sources:
|
||
- podcast/2026-09-06_ai-coding-infrastructure-crisis-outage-drill.md
|
||
- other/2026-09-06_openclaw-cast-episode-identification-correction.md
|
||
tags: [agents, ai-coding, resilience, outages, token-costs, vendor-lock-in]
|
||
---
|
||
|
||
# Resilienz für AI-Coding-Infrastruktur
|
||
|
||
Ein Audio-Briefing zur Woche vom 29.08.–04.09.2026 bündelt drei Risiken beim Einsatz cloudbasierter Coding-Agenten: **Verfügbarkeitsabhängigkeit**, **unkontrollierte tokenbasierte Kosten** und **verlernte manuelle Fallbacks**. Die konkrete Quelle ist nicht redaktionell identifiziert; Zahlen und Produktclaims bleiben daher Podcast-Angaben. Die Architekturlektionen sind davon getrennt belastbar.
|
||
|
||
## Drei Ausfallklassen
|
||
|
||
| Risiko | Mechanik | Gegenmaßnahme |
|
||
|---|---|---|
|
||
| Vendor-/Cloud-Ausfall | Ein Zugang oder eine gemeinsame Netzwerk-/Compute-Schicht fällt aus; mehrere Workflows stehen gleichzeitig | Zweiter Provider, lokales Modell und getestetes Umschalt-Runbook |
|
||
| Kosten-Bloat | Dynamisches Routing und große Volltext-Rewrites erzeugen deutlich mehr Input-/Output-Tokens als der sichtbare Änderungsumfang erwarten lässt | Routing und Budget am Gateway begrenzen; Diffs/Region-Patches verlangen; tatsächliche Kosten messen |
|
||
| Kompetenz-Erosion | Entwickler verlassen sich so stark auf Copiloten, dass sie bei Ausfall keine realistische manuelle oder lokale Ersatzroute mehr kennen | Regelmäßiger Outage-Drill mit einer echten Aufgabe und klarer Negativliste |
|
||
|
||
## 30-Minuten-Outage-Drill
|
||
|
||
Das Briefing schlägt einen kurzen, praktischen Test vor:
|
||
|
||
1. Eine komplexe, realistische Aufgabe auswählen, die bei einem Ausfall weiterbearbeitet werden müsste.
|
||
2. Einen zweiten Cloud-Provider Ende-zu-Ende konfigurieren und tatsächlich ausführen — inklusive Authentifizierung, Routing und Abrechnung.
|
||
3. Ein lokales Modell auf der eigenen Hardware testen und die ehrliche Leistungsgrenze dokumentieren.
|
||
4. Ein Zwei-Zeilen-Runbook lokal speichern: **Tool/Modell für den Wechsel** und **Aufgaben, die mit dem Fallback nicht verantwortbar sind**.
|
||
5. Die Umschaltung stoppen und messen. Im Ernstfall darf nicht erst Dokumentation gelesen oder ein Billing-Problem gelöst werden.
|
||
|
||
Der wichtigste Teil ist die Negativliste: Ein schwächeres lokales Modell ist kein vollwertiger Ersatz für komplexe Refactorings, nur weil es einfache Edits und Testgerüste beherrscht.
|
||
|
||
## Architekturlektionen
|
||
|
||
- **Harness statt Vendor-Dashboard:** Task-Rezepte, Systemprompts und Integrationslogik sollten als versionierte Dateien im eigenen Repository liegen. Dann kann das Modell oder der Provider ausgetauscht werden, ohne die Geschäftslogik neu zu bauen.
|
||
- **Isolation:** Für autonome Enterprise-Aufgaben kombinieren sich Micro-VMs, eng begrenzte Tool-/API-Rechte, ein MCP-Gateway und zentrale Audits zu einer kontrollierbaren Ausführungsgrenze.
|
||
- **Logging ist kein Enforcement:** Ein Budget, das nur eine Benachrichtigung auslöst, stoppt keinen Runaway-Loop. Harte Caps, Reservations, Concurrency-Limits und ein echter Kill Switch müssen vor oder während der Ausführung greifen. Siehe [[agent-budget-breaker.md]].
|
||
- **Gezielte Patches statt Volltext-Rewrites:** Bei großen Dateien ist der sichtbare Änderungsumfang kein verlässlicher Proxy für die Tokenkosten. Region-Patches und Diffs begrenzen Kosten und Review-Fläche.
|
||
- **Abhängigkeit sichtbar machen:** Uptime einzelner Anbieter reicht nicht als Resilienzmaß. Entscheidend ist, welche Provider, Hyperscaler, Routing-Layer und Identitäts-/Billing-Systeme ein Workflow gemeinsam nutzt.
|
||
|
||
## Quellenkritik und Identifikation
|
||
|
||
Die Folge wird laut nachgereichter Prüfung dem **OpenClaw Cast** und dem Titel „OpenClaw 2.0’s Repair Command Deletes What It Doesn’t Recognize“ (22:43) zugeordnet. Die Hosts sind fiktiv; außerdem weichen Episodentitel/-beschreibung und Audiotext deutlich voneinander ab. Die konkrete OpenClaw-`doctor --fix`-Behauptung ist im vorliegenden Audio nicht belegt. Das Audio bleibt deshalb eine synthetische Sekundärquelle: brauchbar für das Resilienz-Muster, nicht für Nachrichten- oder Produktclaims. Siehe [[../../../raw/other/2026-09-06_openclaw-cast-episode-identification-correction.md]].
|
||
|
||
## Einordnung
|
||
|
||
Die Quellenlage trennt sich sauber: Das Audio liefert Beispiele, Zahlen und Produktbehauptungen, die hier nicht als unabhängig bestätigte Fakten gelten. Der **30-Minuten-Drill**, der versionierte Harness und die harte Ausführungsgrenze sind dagegen allgemeine Architekturmaßnahmen, die unabhängig von den genannten Anbietern sinnvoll bleiben. Für unüberwachte Jobs ist die Budget-Seite mit dem [[agent-budget-breaker.md]] besonders relevant; für Updates ergänzt der Drill das Canary-Muster der [[../../institutions/openclaw-cast.md]].
|
||
|
||
## Quelle
|
||
|
||
- Audio und STT-Zusammenfassung: [[../../../raw/podcast/2026-09-06_ai-coding-infrastructure-crisis-outage-drill.md]]
|