CodeCourier in Produktion betreiben

Hobby- und Produktionsnutzung von CodeCourier driften scharf auseinander. Eine einzelne Engineerin mit einigen Sessions am Tag braucht kaum operative Disziplin. Eine Engineering-Org mit dutzenden Nutzern, unbeaufsichtigten Workflows und Sprint Chains, die nachts laufen, braucht sie komplett. Dieser Guide ist das Handbuch für die zweite Welt.

1. Rollen kartieren, bevor Nutzer sie bekommen

Öffnen Sie Workspace → Roles und definieren Sie vier Rollen, bevor Sie eine einzige Person einladen. Das permissive Default-Setup ist für Produktion falsch.

• Viewer - sieht Sessions und PRs, kann nichts starten. Für Stakeholder, PMs und teamübergreifend Interessierte.
• Operator - kann Issue Sessions gegen Repos starten, auf die er GitHub-Zugriff hat. Kann keine Personas oder Workflows ändern. Für die meisten Engineers.
• Builder - bearbeitet Personas und Workflows. Für Senior-Engineers, die die Agent-Infrastruktur besitzen.
• Admin - volle Workspace-Kontrolle. Auf zwei, drei Personen begrenzen, darunter mindestens eine aus dem Security-Bereich.

2. Budgets auf jeder Ebene setzen

Geld geht in unbeaufsichtigten KI-Systemen als Erstes schief. CodeCourier setzt Budgets auf drei Ebenen durch - Workspace, Repo und Persona. Setzen Sie alle drei.

budgets:
  workspace_monthly_usd: 5000
  per_repo_daily_usd:    200
  per_persona_run_usd:   25

actions_on_exceed:
  - notify slack channel #codecourier-budget
  - pause new sessions on the affected scope
  - require admin acknowledge to resume

Das Pausen-Verhalten ist das Entscheidende. Weiche Benachrichtigungen werden ignoriert; harte Pausen erzwingen ein Gespräch.

3. Alerts an die Bereitschaft verkabeln

Konfigurieren Sie unter Workspace → Alerts drei Alert-Kanäle: Budget-Überschreitung, Session-Failure-Rate über 10 % in einem 15-Minuten-Fenster, und jede Session, die länger als 2 Stunden läuft. Die ersten beiden auf die On-Call-Rotation, die dritte auf einen niedrigprioren Kanal.

Der 2-Stunden-Timeout ist bewusst gesetzt. Sessions, die länger laufen, deuten fast immer auf einen fehlerhaft konfigurierten Workflow hin - nicht auf echte Langläufer. Früh abfangen.

4. Vollständiges Audit-Logging aktivieren

Schalten Sie den Audit-Log-Export an Ihr SIEM (Datadog, Splunk, Sumo - was immer Sie nutzen) ein. Jeder Session-Launch, jede Persona-Änderung, jedes Budget-Override und jeder PR-Merge wird mit Actor, Timestamp und vollem Request-Body geloggt. Ihre Security-Abteilung möchte das vor der Freigabe sehen - liefern Sie es, bevor sie fragt.

5. Ein einseitiges Runbook schreiben

Dokumentieren Sie in einer Seite die fünf wahrscheinlichsten Produktionsstörungen und die Reaktion darauf. Pro Eintrag maximal drei Zeilen: Diagnose, Sofortmaßnahme, Eskalation.

• Budget-Pause - wer bestätigt, wie man das Cap anhebt.
• Steckengebliebene Session - killen, Partial-Output sichern.
• Persona-Regression - Rollback auf die vorherige Version.
• Schlechter PR geöffnet - Revert und Re-Run mit überarbeitetem Plan.
• GitHub-Integration-Token widerrufen - Reinstallations-Prozedur.

Pinnen Sie diese Seite im On-Call-Channel an. Das Runbook ist der Unterschied zwischen einem 10-Minuten-Incident und einem 2-Stunden.

6. Die langweilige Wartung einplanen

Zwei Recurring Tasks machen Produktionsnutzung dauerhaft tragfähig. Wöchentlich ausführen - und im Kalender des Team-Owners verankern.

• Persona-Review - fünf jüngste Sessions pro Persona stichprobenartig prüfen, Bestätigen oder Nachbessern, jede 30 Tage ungenutzte Persona stilllegen.
• Budget-Retrospektive - Vorwochenausgaben pro Repo und Persona lesen, Caps anhand realer Nutzung anpassen.

7. Nächste Schritte

Mit Operations als Fundament steht alles andere. Die Integration auf das volle Backlog zeigen, Sprint Chains über die Flotte fächern, unbeaufsichtigte Workflows freigeben - all das wird sicherer, sobald die operative Disziplin da ist. Die Reihenfolge zählt: drehen Sie sie nicht um.