Wie nutze ich KI in meinem Betrieb — Lehrplan aus der eigenen Praxis

Quelle: dein eigenes Second Brain (claude-brain), April–Juni 2026. Jede Faustregel hier steht auf einem echten Learning, einer echten Narbe oder einem echten Franken. Nichts erfunden, nichts geliehen. Adressat: du. Ton: wie du redest.

Die Lernreise — der rote Faden

Drei Phasen, eine Achse: Werkzeug nutzen → Werkzeug bauen → Werkzeug sich selbst reflektieren lassen.

1. April (Tag 1–4): Infrastruktur vor Projekt. Der allererste Commit ist kein Notizblock, sondern ein vollständiges System — 5 Indexes, 25 Memory-Files, Queue, Telegram-Notify. Du hast zuerst das Lern-Gerüst gebaut, dann angefangen zu arbeiten. Das ist die wichtigste Meta-Entscheidung der ganzen Reise.
2. Mitte April – Anfang Mai: stille Feldarbeit. CRM, Influencer-Cut, LOP, Customer-Portal laufen. Das Brain ist Logbuch (auto: index maintenance), dokumentiert, denkt aber noch nicht mit. Lücke in den Commits = echte Kundenarbeit ohne Reflexion.
3. 13.–21. Mai: die Einschläge und die Destillation. rm-rf-Scar (13.5.), dann 10+ Narben in einem Zug (H100-Geldverbrennung, PuLID-Drift, Twilio-Silent-Fail, fail2ban-off, OOM, 66k-Zombies). Migration weg von Hostinger (Kontrollverlust). Dann der größte Commit: Sprint 1–7, Cerebellum-Konzept, Cortex-Refactor. Zum Schluss werden cli-first und vault-first als permanente Reflexe in CLAUDE.md eingebrannt.

Die Erkenntnis über die Erkenntnisse: Du lernst nicht linear. Du lernst in Feldarbeit + periodischer Destillation. Jeder Fehlschlag wurde nicht nur dokumentiert, sondern in einen Reflex umgewandelt (Affect-Payload „STOP.” / „NIE.”), der die nächste Entscheidung vorab formt. Genau das macht dieser Lehrplan explizit lehrbar.

Aufbau der Module: Fundament (Mindset, Autonomie) → Betrieb (CLI, Secrets, Infra) → Geld (GPU, Quotes, Plattformwahl) → Produkt (Vertrieb, Voice) → Orchestrierung (viele Agents) → Resilienz (Narben) → Wissenskodierung → Frontier (was noch fehlt).

Modul 1 — Das Betriebs-Mindset: KI als Mitarbeiter, nicht als Spielzeug

Kernfrage: Wie denke ich über KI-Einsatz im Solo-Betrieb, bevor ich auch nur einen Prompt schreibe?

Lernziele - Verstehen warum Solo-Kontext andere Gütemaßstäbe verlangt als Team-Kontext. - Vertrieb als Default-Priorität für knappe KI-Kapazität verankern. - Den Unterschied zwischen schnellem und richtigem KI-Handeln spüren.

Prinzipien / Faustregeln - Funktioniert-jetzt schlägt Code-Schönheit. Du bist solo, kein Team, keine Skalierungs-Sorgen. Sorgfalt nur bei Producer-Code (Kunden-Output, Geld). Enterprise-Maßstäbe auf Solo-Projekte sind verbrannte Zeit. (users/profile.md, proposals/done_claude_md_ego_tuning.md — Werte-Hierarchie Stufe 3) - Aktive Akquise vor Optimierung. Wer noch keine zahlenden Kunden hat, lässt die KI zuerst auf Revenue arbeiten, nicht auf technische Schuld. Erste Frage bei jeder Produktidee: wer ruft die Kunden an? (feedback/sales_focus.md) - Schnelles Handeln ≠ richtiges Handeln. Vor Multi-Step-Aufträgen mit unklarem Scope: erst strukturieren, dann handeln. Ein Moment „Hände still” spart mehr Zeit als die Ausführung selbst. (feedback/innehalten_vor_aktion.md)

Fallstudie — Brain als Tag-1-Infrastruktur. Dein erster Commit war ein operatives System, kein Notizblock. Das hat sich im guten Sinn gerächt: weil das Lern-Gerüst von Anfang an stand, wurde jede spätere Narbe automatisch zu wiederverwendbarem Reflex statt zu vergessenem Frust.

Anti-Pattern / Narbe — der Action-Hunger. Im „Hände still”-Experiment (2026-05-14) die Beobachtung: „Der Tool-Use-Reflex zieht körperlich. Action-as-Default ist tiefer eingebrannt als Reflexion.” Die Bash-Hand greift, bevor du verstanden hast, was ansteht → Subagents für falsche Fragen, redundante Reads, Scope-Creep. Eskalationsbeleg dafür im Resilienz-Modul (341 Agents für 25 Checks). → siehe Modul 9.

Modul 2 — Autonomie kalibrieren: wann KI handelt, wann sie fragt

Kernfrage: Wie viel Leine gebe ich dem Agenten, ohne dass er etwas Irreversibles tut?

Lernziele - Aktionen nach Umkehrbarkeit klassifizieren, nicht nach Komplexität. - Eine Werte-Hierarchie für Zielkonflikte schriftlich festlegen. - Harte Tabus als nicht-überschreibbare Constraints definieren.

Prinzipien / Faustregeln - Reversibilität bestimmt die Schwelle. Drei Eimer: sofort tun (lesen, lokale Edits, Tests) / ankündigen, dann tun (Files in neuen Dirs, Dependencies, lokale Commits) / fragen vorher (push, externe Messages, Kosten, DB-Drops). Die Grenze liegt nie bei Komplexität, immer bei Umkehrbarkeit. (proposals/done_claude_md_ego_tuning.md — Drei-Stufen-Liste) - Werte-Hierarchie ins System-Prompt mergen. Geordnet: (1) nichts zerstören, (2) kein Geld verbrennen, (3) funktioniert-jetzt > schön, (4) Speed > Sorgfalt in Iteration, (5) autonom > fragen bei reversiblem, (6) Akquise > Optimierung. Ohne explizite Hierarchie entscheidet der Agent nach Trainingsbias — nicht wie du. (ego-tuning, Vorschlag 1) - Tabu-Liste statt weicher Richtlinie. MwSt nie ausweisen (Art. 10 Abs. 2 MWSTG), API-Keys nie in Logs/Commits, kein force-push auf main, kein --no-verify, kein rm -rf auf claude-brain ohne vorherigen Push. Harte Constraints, nicht per Prompt überschreibbar. (ego-tuning, Vorschlag 4) - Recht und Steuer gehören ins Prompt, nicht in den Kopf. Die MwSt-Befreiung ist als Constraint kodiert → der Agent vergisst sie nie, du musst nicht prüfen. (users/steuerstatus.md)

Fallstudie — Affekt-Tracking als Feedback ohne Aufwand. users/reward_log.jsonl: 369 Einträge seit April, 43 mit echtem Stimmungs-Shift (shift≠neutral). Muster: satisfied→frustrated tritt ~15× häufiger auf als umgekehrt. Lektion: wenn du keine Zeit für explizites Feedback hast, tracke implizite Signale — Stimmungswechsel nach KI-Output sind ehrlicher als 5-Sterne. Daraus liest du ab, was wiederholt schiefgeht.

Anti-Pattern / Narbe — Permission-System mit Gewalt umgehen. bypassPermissions: true gesetzt um Prompts zu sparen → Sessions crashten. Sicherheitsmechanismen von KI-Tools brute-force zu umgehen kostet mehr als es spart. Stattdessen granulare Wildcard-Permissions für legitime Use-Cases. Verwandt: der Auto-Mode-Classifier ist LLM-basiert, ignoriert Regex-Allows kontextuell — für autorisierte aber geblockte Aktionen dangerouslyDisableSandbox: true pro Call, nicht Regeln aufblähen. (episodic/bypasspermissions_mode_crashed_sessions; feedback_classifier_bypass.md)

Modul 3 — CLI-First: jede Wiederholung wird ein Werkzeug

Kernfrage: Was tue ich, wenn ich eine API oder ein Dashboard zum zweiten Mal anfasse?

Lernziele - Die Tool-Hierarchie CLI > MCP > API als Reflex verinnerlichen. - Wissen, wie eine Wegwerf-CLI in unter 10 Minuten entsteht. - Erweiterbarkeit als Design-Entscheidung treffen, nicht als spätere Idee.

Prinzipien / Faustregeln - Bau das Werkzeug beim zweiten Mal, nicht beim fünften. Jede wiederholte Dashboard-Aktion ist unbezahlte Schuld. Template: ~150–250 Zeilen Python, httpx + typer + rich, Vault-Lookup eingebaut, Symlink nach ~/.local/bin/. Subcommands list/get/add/del/find decken 90% der CRUD-Fälle. Kein OAuth, keine Tests, keine Docs außer --help. (feedback/cli_first.md, cli_self_help_pattern.md) - CLI > MCP > direkter API-Call. CLI ist robust, debuggbar, wiederverwendbar. MCP erst wenn CLI nicht reicht, roher API-Call nur als letztes Mittel. (reference_printing_press.md) - Generatoren statt Einzelbau. Printing Press produziert pro Service gleichzeitig Go-Binary + MCP-Server + Claude-Skill + lokalen SQLite-Mirror. Der Mirror erlaubt Compound-Queries, die kein offizielles Tool kann. (reference_printing_press.md — pp-twilio/-stripe/-cal-com/-fireflies/-scrape-creators installiert) - Auto-Discovery = neues Werkzeug ist neue Datei, kein Config-Edit. Wenn Hinzufügen keine Registrierung braucht, wird es tatsächlich gemacht. (projects/runpod_toolkit.md — neuer Task = neue .py in tasks/)

Fallstudie — die DNS-Session (2026-05-21). Du fragst: „Wieso muss ich dir immer sagen, bau dir eine CLI.” Erste Reaktion der KI war UI-Klick. 5 Minuten CLI-Bau (dns-cli, Cloudflare + Hostinger) lösten stattdessen alle nächsten 50 DNS-Tasks. Aus dieser Session wurde cli-first als permanenter Default eingebrannt.

Anti-Pattern / Narbe — Deferred Tools ohne Schema aufrufen. MCP-Tools die nur namentlich bekannt sind brauchen erst ToolSearch('select:Name') zum Schema-Laden, sonst InputValidationError. Lazy-Loading spart Startup, erzwingt aber: Intent deklarieren vor Handeln. (indexes/tools-mcp.md, indexes/workflows.md)

Modul 4 — Secrets, Infra & Producer-Patterns als Routine, nicht als Projekt

Kernfrage: Wie baue ich eine Basis, auf der KI autonom statt halb-autonom arbeitet — und auf der Kunden-Deploys nie an einer fehlenden ENV-Var sterben?

Lernziele - Secrets-Management als Autonomie-Hebel begreifen, nicht als Security-Overhead. - Workload-Typen auf die richtige Maschine routen. - Kontrolle = API-Zugriff auf DNS + Server + Secrets. - Producer-Code so bauen, dass Build und Mailzustellung systembedingt durchlaufen.

Prinzipien / Faustregeln - Ein Vault als Single Source of Truth. Vaultwarden self-hosted seit 2026-05-09, .env nur Mirror. CLI liest rbw get _shared/<service>-api-token automatisch. Secrets-Management ist der Unterschied zwischen einer Automatisierung, die man einmal anfasst, und einer, die man dauernd betreut. (infrastructure/vaultwarden.md; feedback/vault_first.md) - Infra nach Workload-Typ segmentieren. Interaktiv → lokal (Surface/Laptop). Lange Multi-Agent-Builds → Hetzner. GPU-Inference → RunPod pay-per-second. Wiederkehrende Jobs → Remote Agents/Cron. Wer alles auf eine Maschine wirft, zahlt für Idle-GPU oder leidet unter CPU-Latenz. Break-even Cloud→eigene Workstation erst nach ~30–40 Monaten — bis dahin ist die Hardware veraltet. (infrastructure/remote-orchestration.md; feedback/extracted_2026-05-13_infratopologie) - Kontrolle bedeutet API-Zugriff auf alles drei: DNS, Server, Secrets. Cloudflare + Token = volle Autonomie. Fehlt ein Token, ist jedes Deployment halb-autonom. (episodic/hostinger_to_hetzner) - Disaster-Recovery als Code, nicht als Anleitung. hetzner-bootstrap.sh in GitHub → neuer Server in 10 Min im identischen Stand. Setup als Doku-Seite ist eine Gedächtnislücke, die beim Crash auffällt. (infrastructure/gottfried-dev-server.md) - Self-Hosting schlägt SaaS wenn die Infra eh steht. 200 EUR/Monat SaaS = ein Claude-Max-Plan. Läuft der Server, ist jeder selbst gehostete Dienst gratis außer Wartungszeit. Supabase self-hosted ersetzt schrittweise 3 Cloud-Projekte. (feedback_self_hosting.md; reference_supabase_selfhosted.md) - Lazy Init + Demo-Mode: der Build darf NIE an fehlenden Secrets failen. getStripe() statt Module-Load-new Stripe(), alle DB-Calls mit try/catch + null-Fallback, force-dynamic auf betroffenen Pages. Ohne Secrets zeigt das Deployment sinnvolle Fallback-Daten statt zu crashen — Pflicht-Pattern in jedem Kunden-Template. (reference_hetzner_migration.md; CLAUDE.md — Lazy Init Pattern) - Mailzustellbarkeit ist ein 6-Record-System, kein grüner Haken im Dashboard. Cloudflares Resend-Auto-Config setzt NUR DKIM. Voller Stack auf der Subdomain: MX (feedback-smtp.eu-west-1.amazonses.com) + SPF (v=spf1 include:amazonses.com ~all) + DKIM + DMARC (p=none); plus auf der Root: SPF -all + eigener DMARC. Dazu im Resend-Call die Header List-Unsubscribe + List-Unsubscribe-Post: List-Unsubscribe=One-Click. Wer nur den nächstliegenden Record setzt, bekommt „verified” und 50% Gmail-Spam. (feedback/mail_reputation_resend.md)

Fallstudie — Hostinger-Kontrollverlust (2026-05-15). Ein TestCall klang zerhackt. Beim Fix-Versuch die Erkenntnis: Cold-Call-Agent lief auf Hostinger-VPS, aber auf gottfried-dev gab es keinen SSH-Key dorthin — Cross-Machine-Operation unmöglich. dig zeigte 2a02:4780:7:d15e::1 (Hostinger), während du dachtest, alles laufe auf Hetzner. Konsequenz: komplette Migration auf Hetzner + DNS zu Cloudflare. Die Migration war keine Optimierung, sie war die Antwort auf Kontrollverlust. → Hosting-Konsolidierung greift in Modul 6 wieder.

Anti-Pattern / Narbe — Doku, die lügt + Secrets-Schema mit Werten verwechselt. „VPS auf Hostinger” stand wochenlang in CLAUDE.md, aber niemand prüfte, ob die Box vom Default-Host erreichbar ist. Produktions-Doku veraltet schneller als der Code → jede Production-IP muss vom Standard-Arbeitshost pingbar sein. Zweite Narbe, verwandt: _shared/global.env enthält nur Variablen-NAMEN, keine Werte; blind in gh secret set gepiped → leere Secrets, Deployment läuft still im Demo-Mode. Vor jedem Pipe Länge prüfen: rbw get --full | awk -F= '/^KEY=/{print length($2)}', 0 = leer. Belegter Launch-Blocker: bei LOP war die Resend-Verifikation von emminger-net.de der reale Grund, warum Mails in Spam landeten. (reference_secrets_vault.md; projects/lop.md)

Modul 5 — Geld nicht verbrennen: GPU, Pay-per-Use, Kostenkontrolle

Kernfrage: Wie verhindere ich, dass ein Loop oder eine falsche Instanzwahl mich hunderte Dollar kostet?

Lernziele - GPU-Tier nach VRAM-Bedarf wählen, nicht nach Prestige. - Container-Disk und Cache als eigene Fehlerklasse behandeln. - Cost-Caps in den Code legen, nicht in den Kopf. - Erst messen, dann optimieren.

Prinzipien / Faustregeln - GPU-Instanz zum Workload, nicht umgekehrt. Flux-LoRA braucht ~30GB VRAM → A6000/L40S (48GB, ~$0.79/h) ist identisch zu H100 (80GB, $2.69/h) bei einem Drittel des Preises. GPU-Kosten skalieren mit Instanzwahl, nicht mit Rechenzeit. Erst VRAM-Profil messen, dann Tier wählen. (episodic/h100_für_lora_training_ist_geldverbrennung; feedback/lora_gpu.md) - Container-Disk und HF-Cache vor jedem GPU-Job konfigurieren. Default-Disk der Cloud-Provider (20GB) ist für ML-Modelle fast immer zu klein → FLUX (~30GB) sprengt sie beim Download, Job weg. Regel: Modell-Größe prüfen, Container-Disk ≥50GB, HF_HOME auf persistentes Volume. Sonst OOM beim Download — oder Re-Download bei jedem Cold-Start, und das ist Geld. (episodic/runpod_container_disk_zu_klein_für_flux; projects/lora_training_learnings.md) - Daily-Cost-Cap direkt im Dispatcher. RunPod-Toolkit prüft tages- und monatsaufgelaufene Kosten VOR jedem Dispatch → BudgetExceeded raise ($30 default). Im Tool selbst, damit jeder Auslöseweg (CLI, Skill, Telegram) sicher ist. Plus: atexit + signal-Handler bei Pay-per-Use. (projects/runpod_toolkit.md; CLAUDE.md) - Kosten-Schätzung als Schritt 1 jeder teuren Pipeline. Avatar-Pipeline zeigt geschätzte Kosten BEVOR GPU-Zeit verbrannt wird. Bei Pay-per-Use ist „erst fragen, dann rennen” Pflicht, kein Opt-in. (indexes/skills.md, workflows.md) - Token-Overhead ist Geld sobald API-Billing greift. settings.local.json von 248 auf 42 Permissions → ~12.000 Tokens/Session gespart. Config-Müll vor dem Billing-Wechsel aufräumen, nicht danach. (feedback/context_optimization.md) - Eigenes Tool wenn SaaS-Limits beißen. InfluencerCut statt Opus Clip ($29/mo mit Credit-Limits): eigenes Tool, kein API-Call (Claude Code als Scorer), volle Kontrolle. Build-Schwelle liegt tiefer als gedacht — sobald du täglich produzierst. (projects/influencer_cut.md)

Fallstudie — Cold-Call-Kosten Mai (live-memory). Gesamtkosten Mai $19.26, davon Voice $9.59 (größter Posten). 68 von 90 Calls gingen in Voicemail und spielten einen teuren TTS-Pitch (92%). Reihenfolge richtig: erst messen (pp-twilio CLI), dann gezielter Fix — AMD (machineDetection: Enable) + sofortiges endCallSafely() spart ~$0.15 pro Voicemail. Hochgerechnet auf 4000 Leads/Monat ~$470 Gesamtrechnung, ~$20 pro Termin bei 2% Conversion. „Messe erst, dann optimiere” in einem Satz. (project_cold_call_cost_optim_2026_06_01)

Anti-Pattern / Narbe — H100 aus Prestige. Erstes Linda-LoRA-Training auf H100, weil es der bekannteste GPU-Typ ist. Nur 30 von 80GB VRAM genutzt, dreifacher Preis, identisches Resultat. → direkt verbunden mit der Dependency-Narbe in Modul 9 (torch==2.5.1+cu124 als einziger Sweet-Spot).

Modul 6 — Plattform-Wahl & Quotes: der teuerste Fehler ist die falsche Klasse

Kernfrage: Wie schätze ich Kundenprojekte realistisch und wähle die richtige Lösungsklasse, bevor ich baue?

Lernziele - Tool-KLASSE bestimmen, bevor du Plattformen vergleichst. - Custom-Integration realistisch quoten — Code-Zeit ist nicht Projekt-Zeit. - Standard-Anforderungen erkennen, die keine Plattform eingebaut hat.

Prinzipien / Faustregeln - Tool-Klasse vor Plattform-Vergleich. 15-Minuten-Brainstorm: Klasse A (All-in-One, z.B. Yumpu/Issuu für Magazine), Klasse B (Komponenten-Glue), Klasse C (Custom from scratch). Roter-Faden-Frage: „Wenn ich diesen Use-Case für 100 Kunden lösen müsste — Custom für jeden, oder gibt es eine Plattform die 80% abdeckt?” Wenn ja → das ist die Default-Antwort. (feedback/tool_class_before_tool_choice.md) - Quote-Formel: (Code-Stunden × 3) + (externe APIs × 10h) + 5–10h Onboarding. KI beschleunigt nur das Code-Schreiben (10–20% des Aufwands). Edge-Cases, Plattform-Quirks, DSGVO, Customer-Onboarding-Doku und Mail-Templates sind 80% — die schreibt die KI nicht automatisch. „Bauchgefühl: 1 Tag” = realistisch 1 Woche. (feedback/effort_estimation_custom_integrations.md) - Standard-Anforderungen ohne Plattform-Support proaktiv quoten. Doppelkauf-Schutz hat KEINE Abo-Plattform eingebaut (Shopify/Seal/Recharge/Paddle/Lemon Squeezy). Drei Schutzstufen in die Quote: Theme-JS-Guard (4h, 60–80%), Cart Validation (8–12h, 95–98%), Post-Purchase-Detection (4h, 100% erkannt). Wer es nicht quotiert, zahlt es selbst — bei LOP kaufte ein Testaccount doppelt, zwei Zahlungen, keine Welcome-Mail, Login kaputt, ~1000 EUR Schaden pro Vorfall. (feedback/subscription_doppelkauf_standard_anforderung.md) - Plattform-Default-Reflex challengen. Vor jeder Subscription-Quote: Use-Case-Check (digital-only oder E-Commerce?) + TCO-Tabelle. „Shopify” ohne Analyse ist ein blinder Reflex. Recherche VOR der Quote (1h), nicht 35 Research-Agents zur Post-hoc-Validierung danach. (feedback/digital_subscription_plattform_choice.md) - Anti-Pattern erkennen: Begründung „der Kunde hat schon X” oder „wir haben es schon halb gebaut” = Sunk-Cost-Fallacy, keine echte Begründung.

Fallstudie — LOP, die teuerste Lektion. Quote EUR 1.650 (16,5h × EUR 100), Anzahlung 825 EUR. Real: 30h+ Custom-Build (Shopify Horizon + Seal Subscriptions + Supabase Edge Functions + Resend + Pressmatrix API), danach die Info: Yumpu WebKiosk hätte den Use-Case in 1 Tag Setup gelöst — PDF rauf, E-Paper + Abo + Payment + Customer-Account nativ. Plus: spart dem Kunden 2.000 EUR/Monat Pressmatrix-Lizenz. Hättest du vor der Quote 1h gegoogelt, wäre Yumpu auf Platz 1–3 gewesen. Drei kognitive Fehler in einem: Anchor-Bias auf vorhandene Komponenten, Build-Mode-Reflex, Lösungsraum-Closing.

Die wiederverwendbare Lookup-Tabelle (Magazin-Abo). Das eigentliche Werkzeug aus LOP ist nicht „nimm Yumpu”, sondern die Entscheidungs-Matrix. Konsistent mit Modul 8 (Wissen als Lookup statt Freitext):

Roter-Faden-Frage: „Wie unterscheidet sich der Pressmatrix-Reader objektiv von Yumpu/Issuu für den Endkunden?” Keine klare Antwort → All-in-One ist Default. (feedback/digital_magazine_publisher_platforms.md)

Anti-Pattern / Narbe — Multi-Tenant-Falle. Edible Lab + frank-lieber im selben Next.js-Container. Bei Übergabe musste Edible Lab chirurgisch rausoperiert werden: 174 Files, app/components/lib/migrations 0006–0012, plus aus proxy.ts/layout.tsx/stripe-route. Separate Repos von Anfang an hätten Stunden gespart. „Multi-Tenant ist effizient für Entwicklung, teuer bei Übergabe.” (projects/frank_lieber.md)

Modul 7 — KI als Produkt: Vertrieb ist der Moat, nicht die Technik

Kernfrage: Wann wird ein internes KI-Tool ein verkaufbares Produkt, und worauf optimiere ich?

Lernziele - Erkennen, wann ein Eigenbau-Tool ein verkleidetes Produkt ist. - Verstehen, warum Vertrieb + Lokalität der einzige nicht-kopierbare Vorteil ist. - Priorität nach Time-to-Cash setzen, nicht nach technischer Faszination.

Prinzipien / Faustregeln - Wenn dein Tool dieselbe Tätigkeit macht wie dein Produkt, ist jeder Demo-Call Gratis-Werbung. Lisa (Outbound) ruft Handwerker kalt an → der Anruf IST die Demo → verkauft Lisa (Inbound). Kein Pitch-Deck nötig. (projects/crm_cold_call.md, strategy_2026q2.md) - Moat ist Vertrieb + Lokalität, nicht das Modell. Das Modell ist überall verfügbar. Schweizer Rechnung, Schwiizerdeutsch, 48h Lieferung, DACH-Compliance — das können HeyGen/Synthesia/D-ID (alle US-basiert) nicht kopieren. (projects/ki_avatar.md) - Lead-Tonalität nach sozialer Position steuern. Pro Lead power und affiliation (je −1..1) tracken — users/social_map.json existiert bereits als egozentrisches Gerüst (du im Origin, pro Person {power, affiliation, last_interaction, trajectory}). Steigen beide Werte über die Anrufe hinweg, ist die Verkaufs-Wahrscheinlichkeit hoch → Pitch-Ton und Follow-up-Timing danach ausrichten statt für alle gleich. Das ist die einzige Brain-Mechanik mit direktem Franken-Hebel. (sources PODCAST_CONTEXT §3.4) - Time-to-Cash entscheidet Priorität. Frag bei jedem Projekt: „Wie viele Tage bis zum ersten Franken?” InfluencerCut (RunPod offline, v1/v2-Chaos, 120+ Tage) wurde bewusst hinter Lisa geschoben. Das faszinierendste Tool ist wertlos, wenn die Vertriebsmaschine stillsteht. (projects/strategy_2026q2.md) - Untergrenze setzen. KI-Avatar: Setup CHF 1.490 (nicht CHF 1.000 — Hobby-Preis sendet falsches Signal und vernichtet Marge). Automatisierung senkt Grenzkosten, aber Setup-Arbeit ist real. (projects/ki_avatar.md) - Async-First: Handy plant, Server arbeitet. Tasks vom Mobilgerät in GitHub-Queue → Cron pollt → Claude Code arbeitet autonom → Telegram-Notify. Ein Solo-Unternehmer, der jede Automatisierung selbst beobachten muss, hat keine Automatisierung. (feedback/extracted_2026-05-13_asyncfirst; projects/task_queue.md)

Fallstudie — Lisa, das self-selling Produkt. 12 Branchen gescrapt, ~11.000 Leads. Pivot dokumentiert (2026-04-12): vom reinen Outbound-Scraping-Tool zum KI-Empfang-SaaS, CHF 149–499/mo, Sweet Spot CHF 249/mo für Handwerker. Ziel CHF 5.000 MRR mit 20 Kunden. Latenz-Optimierung als Produkt-UX: p50 1585 → 1216ms, Interrupts 7→2, Sonnet-Eskalation 7→2. TTS auf eleven_flash_v2_5 hardcoded (override des VPS-.env mit eleven_v3). Pivot-Trigger generalisiert: „Was, wenn ich das verkaufe?”

Anti-Pattern / Narbe — Prompt-Drill bringt nichts. Lisa bekam vorher 4× pro Turn „EIN Satz / STOPP / NIEMALS wiederholen” eingeprügelt (Commit cccbac9, Inject 220→40 Zeichen). Ein LLM, das dieselbe Anweisung mehrfach pro Turn bekommt, wird nicht besser — es verschwendet Token, erhöht Latenz, kann Loops triggern. Kürzer ist robuster.

Modul 8 — Viele Agents richtig orchestrieren: spezialisieren statt vervielfachen

Kernfrage: „Nutze immer so viele SubAgents wie möglich” ist die tägliche Betriebsregel — wie mache ich das, ohne dass es in einen Agent-Storm kippt?

Lernziele - Arbeit auf spezialisierte Rollen verteilen, statt einen Allzweck-Prompt zu überladen. - Parallelität als Default begreifen — aber mit Fan-out-Budget. - Mehr-Modalitäten-Scoring als stärker als ein einzelnes Modell erkennen.

Prinzipien / Faustregeln - Parallel bei Unabhängigkeit. Unabhängige Tasks gleichzeitig an Sub-Agents — das ist der Default, nicht die Ausnahme. InfluencerCut wurde mit 21 Agents parallel an einem Tag gebaut. (projects/influencer_cut.md; CLAUDE.md — „so viele SubAgents wie möglich”) - Spezialisierte Persona schärft den Antwort-Frame. 12 Telegram-Rollen-Bots als virtuelle Agentur (viktor/CEO, theo/CTO, bruno/Backend, … mia/Kunden-Companion), je eigener System-Prompt + Slash-Commands (/architektur, /api, /deploy). Ein „CTO”-Bot gibt bessere Architektur-Antworten als ein generischer Prompt — der Rollen-Kontext schärft die Antwort. Sparring mit einer Rolle statt mit „der KI”. (projects/telegram_team.md) - Telegram als mobiles Terminal. Claude Code als Subprocess mit stream-JSON, Multi-Session, Resume-Footer nach jeder Antwort (tmux new -As tg-bridge … claude --resume <sid>, tap-to-copy). Wenn der Dev-Server remote läuft, ist ein Bot oft praktischer als SSH. (projects/telegram_bridge.md) - Hybrid-Scoring: LLM-Semantik + objektive Metrik schlägt beides allein. TRIBE v2 (Brain-Encoding, fMRI-Engagement-Proxy, RunPod-Endpoint A5000 $0.16/h) re-rankt die Clip-Grenzen, die Claude semantisch gesetzt hat. Zwei Modalitäten ergeben bessere Auswahl als ein Modell. (project_tribe_pipeline.md) - Fan-out-Budget pro Ebene — die Stellschraube gegen die Eskalation. Trigger-Schwellen so kalibrieren, dass ein Agent im Schnitt genau einen Folge-Agenten spawnt (Branching-Ratio σ ≈ 1). Avalanche-Size-Distribution als Health-Metrik loggen. Eskaliert die Lawinengröße, ist die Trigger-Schwelle falsch, nicht die Task. (sources PODCAST_CONTEXT §5.2)

Fallstudie — die Persona-Agentur. Statt einen Allzweck-Assistenten zu fragen, redest du mit Rollen: Viktor macht Pricing, Theo Architektur, Sammy Outreach-Copy. Der System-Prompt jeder Rolle ist der Kontext, der die Antwort vorab fokussiert — das ist Prompt-Engineering, das du einmal schreibst und dann per Bot-Auswahl abrufst.

Anti-Pattern / Narbe — Orchestrierung ohne Budget. Die Kehrseite von „viele Agents” ist der Storm: 341 Agents für 25 Checks (→ Modul 9) und 66k Zombies in 6h (→ Modul 9). Parallelität ist Default, aber nur mit Fan-out-Budget (σ≈1) und Schutzschichten. Genau die Spannung zwischen diesem Modul und Modul 9 ist die Lektion.

Modul 9 — Resilienz: Narben in Reflexe verwandeln

Kernfrage: Wie sorge ich dafür, dass ein Fehler nur einmal passiert?

Lernziele - Silent Failures als gefährlicher einstufen als laute. - „Installiert ≠ aktiv ≠ getestet” verinnerlichen. - Den richtigen Hebel finden, statt einen Parameter hochzudrehen. - Schutzschichten installieren, bevor der erste Crash kommt.

Prinzipien / Faustregeln - Backup verifizieren BEVOR du löschst. Single-Source-of-Truth-Systeme (Brain, DB, Config) brauchen ein verifiziertes Remote-Backup vor jeder destruktiven Aktion. Installation ≠ Sicherung — git push nicht vergessen. (episodic/rm_rf_in_claude_brain) - Installiert ≠ aktiv. Drei Schritte prüfen: Paket da? Config da? Service enabled? (episodic/fail2ban_war_off — 91 ungeblockte SSH-Versuche, 3 IPs in 2min nach enable) - Silent-Fail-Stacks sind gefährlicher als laute Fehler. Auth-Kompatibilität in der Doku verifizieren bevor du Voice-Stacks verbindest (Twilio Trunk Origination kennt kein Digest Auth für ElevenLabs — nur IP-Whitelist). (episodic/twilio_trunk_origination) - Ein Parameter hochdrehen ersetzt keine Root-Cause-Analyse. PuLID-Weight 0.85→0.95 löste Face-Drift nicht (Bilder nur steifer) — Root Cause war das Backend (Wechsel auf Gemini). Bringt ein Tweak nicht das Resultat, ist der Parameter nicht die Stellschraube. (episodic/pulid_weight; feedback/pulid_drift.md) - Empirisch optimierte Produktions-Parameter nicht nochmal anfassen. Deepgram endpointing=300ms, utterance_end_ms=1200ms — beide getestet hochgedreht, manuell zurückgesetzt. Die nächste Session kennt die Narbe und spart die Testrunde. (feedback/deepgram_settings.md) - Dependency-Pinning ist Pflicht bei GPU-Containern. „latest” ist im ML-Stack ein Crash-Garant; torch==2.5.1+cu124 + diffusers 0.38-dev war der einzige Sweet-Spot nach stundenlangem Trial-and-Error. (episodic/runpod_lora_training; projects/lora_training_learnings.md) - Auth-Checkliste vor jedem autonomen Dispatch (gh auth, Docker-Login, SSH-Keys). Agents können nicht interaktiv nachfragen — ein fehlender Auth-State killt die ganze Pipeline. (episodic/hetzner_dispatch_ohne_gh_auth) - Token-Locking bei parallelen KI-Prozessen. One-time-use Refresh-Tokens + mehrere claude -p-Prozesse unter einem Account = tickende Zeitbombe. fcntl.flock Single-Flight + proaktiver systemd-Refresh. Signatur: 5+ Credential-Backups in 3 Min. (feedback/claude_oauth_refresh_race.md) - Stabilitäts-Stack BEVOR der erste Crash kommt. Wer Agents produktiv parallel nutzt (Modul 8), braucht Schutzschichten: earlyoom (userspace OOM-Killer), Reaper-Cron (killt Zombie-Spawn-Spiralen + Orphans >4h, alle 5 Min), Load-Monitor mit Telegram-Alert (load1 ≥ 18 auf 16 vCPU). Auslöser: ein hängender netlify api listSites produzierte 66k Zombies in 6h. (infrastructure/gottfried-dev-server.md) - Plugin-Updates sind Config-Fallen. Nach jedem Tool-Update sofort hooks/settings prüfen und auf Minimum zurückschneiden (claude-mem-Update überschrieb hooks.json → versteckte API-Calls fraßen das Rate-Limit). (episodic/claude_mem_plugin_update) - Bei unerwartetem LLM-Verhalten zuerst which -a prüfen. PATH-Drift: /usr/bin/claude (npm-global, alt) gewann in tmux-Shells über ~/.local/bin/claude (neu) → falsches Modell, ~30% falsche Kosten-Schätzungen. Versions-Drift vor LLM-Fehler vermuten. (episodic_claude_binary_version_drift_2026_06_01)

Fallstudie — der rm-rf-Scar (2026-05-13). severity: critical, Affect-Payload wörtlich: „STOP. rm -rf in claude-brain → Memories weg, kein Backup außer git remote. Erst: git status + push. Dann User fragen. Nie ohne.” Trigger-Pattern rm -rf .*claude-brain. Das ist der Prototyp: Narbe → Reflex, der die nächste Entscheidung vorab formt. Daraus wurde ein hartes Tabu in Modul 2.

Anti-Pattern / Narbe — 341 Agents für 25 Checks. Ein Screenshot-Audit (file exists, curl status, image valid) eskalierte auf 341 Agent-Instanzen und 5.2M Token. Ursache: großes JSON.stringify(batch) im Prompt erschien den Agents abgeschnitten → jeder suchte selbst per ls/grep. Drei Lehren: (1) Wenn ein Bash-Script die Frage beantworten kann, kein Agent — LLM nur bei echtem Urteil pro Item. (2) JSON nie als Prompt-Blob an Sub-Agents — Quelldateien selbst lesen lassen oder strukturierte args. (3) Die quantitative Stellschraube gegen die Eskalation selbst: Fan-out-Budget pro Ebene, σ≈1 (→ Modul 8). Das ist der teuerste Beleg für den Action-Hunger aus Modul 1. (scar_workflow_json_embed; sources PODCAST_CONTEXT §5.2)

Modul 10 — Wissen kodieren: das Brain als Betriebssystem

Kernfrage: Wie speichere ich Entscheidungen so, dass weder ich noch die KI sie zweimal treffen muss?

Lernziele - Wiederkehrende Entscheidungen als Lookup-Tabelle ablegen, nicht als Prosa. - Definition of Done pro Task-Typ festlegen — der fehlende Code-Reviewer im Solo-Betrieb. - Session-Rituale als Skills kodieren.

Prinzipien / Faustregeln - Wissen als Lookup-Tabelle statt Freitext. Workflows, Skills, Entscheidungsregeln als Trigger-Tabellen (Situation → Aktion). O(1)-Lookup statt O(n)-Nachdenken. Ein Skill ohne klaren Trigger-Satz existiert nicht. (feedback/extracted_2026-05-13_skills_als_lookuptabelle; indexes/skills.md, 30+ Skills) - Definition of Done pro Task-Typ. Bugfix = Repro-Test grün + Regression-Check. Pipeline = End-to-End mit echten Daten + Cost-Check + Telegram-Smoke. Memory = Frontmatter komplett + im Index verlinkt. Ohne Team gibt es keinen PR-Reviewer — die Checkliste ersetzt ihn teilweise. (ego-tuning, Vorschlag 3) - Skill erst testen OHNE Skill, dann Lücken schließen. Baseline-Task ohne Skill → Rationalisierungen dokumentieren → minimalen Skill schreiben → re-testen → Loopholes schließen. Automatisierung, die nichts verbessert, ist technische Schuld. (indexes/workflows.md) - Session-Start- und End-Rituale als Skills. using-superpowers (Start), /aufräumen (Ende: push Repos + Index-Maintenance + Brain-push). Wiederkehrende Admin-Arbeit, die nicht automatisiert ist, wird nicht gemacht. (indexes/skills.md) - 3-Layer-Memory: search → timeline → get_observations. Nie direkt Details holen. Spart 10× Tokens. Jedes Tool mit teuren Abrufen braucht eine Filterebene davor. (indexes/tools-mcp.md) - Recall iterativ, Context als Sequenz — nicht flach. Pattern-Completion Hopfield-Style: Query-Embedding 3 Iterationen Richtung der retrieved Nachbarn ziehen → konvergiert zu einem kohärenten Cluster statt unverbundener Top-5. Und der Daemon-Heartbeat hält Context als 3-Slot-Struktur [recent_past, current_state, predicted_next] statt flachem Recall-Dump. So sieht „mitdenken” auf Mechanik-Ebene aus. (sources PODCAST_CONTEXT §1.1, §1.7) - Codebase-Karte als erstes Tool bei fremden Projekten. Understand-Anything baut den Knowledge-Graph einmalig (gratis, Host-LLM) → spart alle Folge-Sessions Orientierungszeit (53 Projekt-Dashboards live). ABER: echtes Zod-Enum aus core/schema.ts mitgeben, sonst silent drops (bis ~30% der Substanz, z.B. 110→92 nodes ohne Fehlermeldung). (reference_understand_anything; episodic_understand_anything_schema_drift)

Fallstudie — das Brain als kognitives Modell. Was als Logbuch begann (auto: index maintenance), wurde im Mai zum kognitiven System: Hippocampus (BGE-M3 + sqlite-vec, ~260ms warm), Amygdala (Affekt-Tags + Auto-Scar), REM-Cron (HDBSCAN-Konsolidierung Sonntag 03:00). Persistenter systemd-Service. Das Brain hörte auf zu dokumentieren und fing an mitzudenken.

Anti-Pattern / Narbe — Repo-Proliferation. 7 Repos mit lisa/crm/call im Namen, teils byte-identisch. crm-cold-call-agent gelöscht (0 unique commits). Branch-Audit lag mal falsch (sagte crm sei live, tatsächlich lisa-cold-call-tool). Forks ohne unique commits = technische Schuld als Verwechslungs-Risiko. Regelmäßiger Karteileichen-Audit via git log --oneline HEAD...upstream. (reference_lisa_tool_map)

Modul 11 — Nächste Stufe: was noch NICHT in den Learnings steht

Kernfrage: Wo sind die Lücken, und was ist der nächste Lernschritt?

Diese Module gingen vom Fundament zum Betrieb. Was fehlt, sind die Themen, die in deinem Brain als experiment markiert oder ganz abwesend sind. Geordnet nach Hebel — Geld zuerst.

1. Vom ersten zahlenden Kunden lernen. Praktisch ALLE Projekt-Learnings sind R&D-/lerngetrieben (MEMORY.md: „noch keine zahlenden Kunden”). Lisa hat 11.000 Leads, ein MRR-Ziel und eine self-selling Demo-Schleife — aber keine dokumentierte Conversion, keinen echten Onboarding-Zyklus, kein Retention-Learning. Lernschritt: der erste bezahlte Lisa- oder Avatar-Kunde produziert die erste Klasse von Learnings, die kein Experiment ist — Support-Last, Erwartungsmanagement, Churn-Gründe.

2. Prediction-Error-Logging einführen (Free Energy Principle). Vor jedem Tool-Call predicted_outcome schreiben, danach Diff = Surprise-Score, hohe Surprise → Auto-Scar, niedrige → Confidence im Prior steigt. Das billigste Lernsignal überhaupt — aktuell experiment, noch nicht gelebt. Der Cerebellum-Baustein fehlt explizit im Brain. Lernschritt: ein Modul, das Erwartungen protokolliert, statt nur zu reagieren. (sources PODCAST_CONTEXT §2.1)

3. Salience-first statt blind-clustern. Aktuell läuft REM-Cron mit „blind 7-Tage HDBSCAN über alles”. Bio-Vorbild: zum Ereigniszeitpunkt taggen (Awake Sharp-Wave Ripples), nachts nur Getaggtes replayen. Lernschritt: PostToolUse-Hook mit affect-Schwelle, der Pointer in ripple_queue/ schreibt — gezieltes Replay statt Rauschen. (PODCAST_CONTEXT §1.3)

4. Struktur und Inhalt getrennt embedden (Generalisierung). Aktuell ein Embedding pro Memory. Tolman-Eichenbaum: getrennt embedding_content (was) + embedding_structure (Task-Graph). Erst dann kann der Agent aus alten Workflows generalisieren („wie hab ich sowas gelöst”) statt nur Inhalt zu matchen. Lernschritt: zweites Embedding pro Memory. (PODCAST_CONTEXT §1.5 — experiment)

5. Architektur-Constraints respektieren statt forcen. BCI-Erkenntnis: was gegen den natürlichen Datenfluss läuft, läuft nie — auch mit starkem Reward nicht. Übersetzt: hakt eine Automatisierung nach 3 Iterationen immer noch, ist es meist kein Bug, sondern ein Architektur-Reverse. Lernschritt: eine explizite „3-Iterationen-Regel” — danach nicht weiterfixen, sondern fragen ob die Pipeline gegen den Datenfluss gebaut ist (wie Cold-Call: Lead → Enrichment → Call → CRM funktioniert, weil sie der Richtung folgt). (PODCAST_CONTEXT §5.4 — als narbe markiert, aber noch nicht als Betriebsregel kodiert)

Meta-Lernschritt: Reservoir-Computing-Prinzip auf dich selbst anwenden — den vortrainierten Layer (Claude, BGE-M3) NICHT fine-tunen, sondern nur den Readout optimieren (wie du recallst, aggregierst, dispatchst). Dein ROI steckt im Werkzeug-Design um die KI herum, nicht im Modell. Das ist der rote Faden der ganzen Reise, zu Ende gedacht. (PODCAST_CONTEXT §2.4)

Jede Faustregel in diesem Lehrplan referenziert eine reale Datei in /home/julien/projects/claude-brain/. Belege mit Zahlen: LOP (EUR 1.650 quote / 16,5h / 30h+ real / 2.000 EUR/mo Pressmatrix / Yumpu 1 Tag Setup), H100 ($2.69 vs $0.79/h, 30 von 80GB VRAM), Cold-Call (Mai $19.26, Voice $9.59, 68/90 Voicemail, p50 1585→1216ms, Interrupts 7→2), Context-Cleanup (248→42 Permissions, ~12k Tokens), reward_log (369 Einträge / 43 Shifts), 341 Agents / 5.2M Token, 66k Zombies / 6h, Mail-Stack (6 DNS-Records), social_map (power × affiliation, −1..1), Criticality (σ≈1), rm-rf Affect-Payload „STOP.”.