Teams
KI-Subagenten. Jede Aufgabe bekommt einen eigenen, kurzlebigen Branch in einem eigenen Arbeitsverzeichnis (Git-Worktree). Das gemeinsame Hauptverzeichnis bleibt unberührt.
Entwicklung
Wie wir entwickeln.
CloudManager ist eine Plattform, mit der Server, Anwendungen, Backups und Sicherheit für eigene Produkte und für Kunden betrieben werden. Gebaut wird sie von einer einzelnen Person, in einer Entwicklungsumgebung, in der eine KI einen großen Teil der Umsetzung übernimmt und der Mensch über Umfang, Freigaben und Eingriffe entscheidet. Hier steht, wie das konkret aussieht.
01 · GitLab & CI/CD
Alles im eigenen Haus
Quellcode, Issues, Roadmap und Pipelines liegen in einem selbst betriebenen GitLab. Es ist die einzige maßgebliche Quelle; ein öffentlicher Spiegel wird automatisch nachgezogen.
- Roadmap aus Issues. Jeder geplante Punkt ist ein GitLab-Issue mit Labels für Art, Bereich, Status und Priorität; Meilensteine bilden die Wellen. Das Roadmap-Dokument im Repository wird daraus erzeugt und nie von Hand bearbeitet.
- Prüfpipeline für jeden Merge-Request. Typprüfung für API, Oberfläche und Agent, Lint, alle Testsuiten, ein Rechte-Audit für jede schreibende Schnittstelle, ein Abgleich der API-Beschreibung mit dem Code sowie statische Sicherheitsanalyse und Geheimnis-Erkennung. Die letzte Pipeline mit Testbericht zählte rund 12.900 Testfälle (Stand 02.10.2026).
- Gemeinsame CI-Bausteine. Wiederkehrende Prüfungen (Typprüfung, Lint, Tests, Abhängigkeits-Audit, Rechte-Audit, API-Abgleich, Sprachprüfung) liegen als versionierte Komponenten in einem eigenen Repository. Ein Projekt bindet sie auf eine feste Version gepinnt ein. So kommen Änderungen bewusst und nicht nebenbei.
- Builds nur aus Releases. Images entstehen nur bei einer neuen Versionsnummer, werden signiert und mit Stückliste (SBOM) versehen. Nachts läuft zusätzlich eine reine Audit-Pipeline.
02 · Claude Code als Arbeitsumgebung
Ein festes Rollenmodell
Die Entwicklung läuft in Claude Code, der Kommandozeilen-Umgebung von Anthropic. Gearbeitet wird nach vier Rollen:
Das Gate
Ein eigener Prüf-Agent, der vor dem Zusammenführen die kombinierte Änderung aller parallelen Stränge ansieht: Widersprüche, doppelte Logik, Prüfungen, die gar nicht greifen können.
Der Integrator
Die Hauptsitzung. Nur sie führt auf main zusammen, vergibt Versionen und Migrationsnummern und erstellt Releases.
Der Betreiber
Ein Mensch. Er entscheidet über Umfang, Freigaben und jeden Eingriff an Servern.
Die Trennung ist technisch abgesichert: Ein Hook in
Claude Code blockt jeden Versuch eines Subagenten, auf
main zu committen, zu mergen oder zu pushen.
03 · Skills, Subagenten, Plugins, Hooks
Werkzeuge, die in jedem Projekt gleich sind
Die Werkzeuge sind in einem eigenen Plugin-Marktplatz gebündelt. Das zentrale Plugin enthält:
- 32 Befehle für wiederkehrende Abläufe, vom Planen über das Umsetzen bis zu Review, Release, Sitzungsabschluss und -wiederaufnahme.
- 19 spezialisierte Subagenten (Backend, Frontend, iOS, Android, Tests, Sicherheit, Review, Migrationen, CI, Performance, Barrierefreiheit u. a.). Jeder hat ein fest zugeordnetes Modell: kleine, schnelle Modelle für reine Suche, mittlere für Umsetzung, die stärksten für Review, Sicherheit und das Gate.
- 6 Skills aus diesem und zwei weiteren Plugins, darunter die gemeinsamen Arbeitskonventionen, das Melden von Infrastruktur-Störungen mit Belegen und das automatische Beheben von Schwachstellen in Abhängigkeiten auf Basis der Scans, die CloudManager ohnehin speichert.
-
6 Hooks, die automatisch greifen: Formatierung nach jeder Dateiänderung, Schutz von
main, Sperre gegen endlose Wartebefehle, Aufräumen nachweislich erledigter Branches nach dem Zusammenführen, ein Lagebild beim Sitzungsstart und eine Erinnerung an den Sitzungsabschluss. Die Hooks haben eigene Tests. - Anliegen aus Produktprojekten. Sie kommen als GitLab-Issue mit festem Label an. Ein Worker holt sie regelmäßig ab und bearbeitet sie in einer unbeaufsichtigten Sitzung mit eng begrenzten Rechten und einer festen Liste erlaubter Routinen. Alles, was Infrastruktur wachsen lässt, wartet auf eine menschliche Freigabe.
Zahlen gelten für den 02.10.2026 und ändern sich laufend.
04 · Token sparen
Kontext ist die größte Kostenquelle
KI-Entwicklung kostet Rechenzeit, und die größte Kostenquelle ist nicht die Antwort, sondern der Kontext, der bei jedem Schritt neu gelesen wird. Die Regeln dazu:
- Kurze Sitzungen. Ab rund 150.000 Token Kontext empfiehlt ein Hook, den Stand zu sichern und neu zu beginnen. Die neue Sitzung bekommt automatisch eine Kurzfassung des letzten Stands und muss nicht alle Dokumente erneut lesen.
- Wenige Agenten gleichzeitig. Höchstens drei parallel; mehr Agenten bringen mehr Nahtstellen, nicht mehr Ergebnis. Das ist eine Richtlinie, keine technische Sperre.
- Leichtes und volles Gate. Reine Doku-Änderungen, Einzeiler und Versions-Pins prüft die Hauptsitzung selbst; alles mit Logik geht durch das volle Gate.
- Ergebnisse lesen statt wiederholen. Das Gate liest den Testbericht der Pipeline, statt die ganze Testsuite noch einmal im eigenen Kontext laufen zu lassen.
- Verweisen statt wiederholen. Regeln für Subagenten stehen in einer Datei, auf die jeder Auftrag verweist.
- Messen. Ein Skript wertet die Verbrauchszahlen der Sitzungen aus, nie deren Inhalt, und meldet sie an CloudManager.
05 · Lokale LLMs
Wo Daten das Haus nicht verlassen sollen
Dafür läuft ein lokal betriebenes Sprachmodell (Ollama, Modell mit 14 Milliarden Parametern, im eigenen Netz). Was davon im Einsatz ist und was nicht, steht hier getrennt:
Läuft heute
Die automatischen Analyse-Routinen von CloudManager laufen primär über das lokale Modell. Fällt es aus, gibt es einen Alarm; ein Ausweichen auf einen Cloud-Anbieter ist nur möglich, wenn es dafür ausdrücklich freigeschaltet ist. Vor automatischen Updates prüft zuerst ein Regelwerk; bei breiteren Updates (Host-Pakete insgesamt, Container-Images) bewertet das lokale Modell das Risiko zusätzlich anhand des Host-Zustands. Reine Sicherheitspatches laufen nur über die Regeln, damit eine Lücke nicht auf ein Modell wartet. Ist die Modell-Bewertung vorgesehen und bleibt sie aus, passiert nichts automatisch.
Eingebaut, in Erprobung
Lange Test-, Build- und Pipeline-Ausgaben kann das lokale Modell verdichten, bevor die Entwicklungs-KI sie liest; Geheimnisse werden vorher maskiert, fällt das Modell aus, geht die Originalausgabe durch. Ein kleines Werkzeug schärft eine Aufgabe mit bis zu vier Rückfragen zu einem knappen Auftrag. Beides ist noch kein Routinebetrieb: im Nutzungsprotokoll steht bisher ein einziger Eintrag.
Geplant
Das Verdichten der Berichte der Subagenten selbst, nicht nur der Werkzeug-Ausgaben, ist vorgesehen und noch nicht gebaut.
Bewusst nicht: Das lokale Modell trifft keine Sicherheits-, Review- oder Freigabe-Urteile. Es fasst zusammen; entschieden wird woanders.
06 · Qualitäts-Gates & Freigaben
Vier Stufen, jede mit eigener Bedingung
- Vor jedem Commit. Typprüfung ohne Fehler, Lint innerhalb einer festen Obergrenze, und die Zahl der Tests darf nicht sinken.
- Vor jedem Zusammenführen. Grüne Merge-Request-Pipeline und das Gate.
- Nach dem Release. Ein reines Patch-Update ohne Datenbankänderung spielt CloudManager selbst ein, mit Gesundheitsprüfung und automatischem Rücksprung bei Fehlern.
- Wenn es riskant wird. Jede neue Datenbank-Migration und jeder größere Versionssprung wird angehalten. CloudManager schickt dann eine Freigabe-Anfrage an die iOS-App PocketCM. Erst nach Freigabe wird ausgerollt. Kann die Risikobewertung selbst nicht stattfinden, gilt das Update als riskant.
Kontakt
Fragen zur Arbeitsweise?
Wie das im Detail aussieht, zeige ich gern am laufenden System, auch an den Stellen, an denen es noch nicht rund läuft.