KI-CTO: ein rollenbasierter Engineering-Agent
Technische Strategie, Code-Reviews, Architekturprüfung und Anbieterbewertung — begrenzt auf die Repositories und Tracker, die Sie freigeben, in Ihrer eigenen Infrastruktur.
Die Rolle KI-CTO in OperativeOps ist ein rollenbasierter Agent für Engineering-Leitungsarbeit. Er liest die Repositories, Issues und Incidents, die Sie ihm freigeben, entwirft Reviews und Entscheidungsdokumente — und kann weder Code mergen noch Infrastruktur verändern.
Was der Engineering-Agent tut
- Fasst Pull Requests zusammen und identifiziert kritische Probleme, Sicherheitslücken und Performance-Schwachstellen in den freigegebenen Repositories.
- Bewertet Anbieter und Werkzeuge anhand Ihrer definierten Kriterien — Preis, DSGVO-Lage, Integrationstiefe und Lock-in-Risiko.
- Triage technischer Schulden: bewertet, gruppiert und priorisiert Backlog-Einträge nach Risiko und Auswirkungsradius.
- Wandelt Architekturbeschreibungen in strukturierte Diagramme und Architecture Decision Records (ADRs) in Notion oder Markdown um.
- Erstellt wöchentliche Engineering-Digests — offene PRs, Deployment-Metriken, Incident-Anzahl und wichtige Entscheidungen.
- Führt PR-Triage durch: schlägt Reviewer vor, kennzeichnet veraltete Branches und hebt blockierte Punkte für Ihr Standup hervor.
- Entwirft Engineering-Hiring-Loop-Skripte, technische Interviewfragen und Bewertungsraster für Hausaufgaben.
Sample interactions
Sollten wir von REST auf gRPC für unsere internen Microservices migrieren?
Strukturierter Abwägungsvergleich: gRPC reduziert die Nutzlastgröße um ~30–40 % und erzwingt Verträge via Protobuf, erhöht jedoch die Tooling-Komplexität (HTTP/2, Code-Gen-Pipeline) und verschlechtert die Browser-Client-Ergonomie ohne grpc-web-Proxy. REST behält Ihre aktuelle Client-seitige Fetch-Story bei und lässt sich einfacher mit curl testen. Meine Empfehlung für Ihre aktuelle Größenordnung (unter 100 internen Aufrufen/s): Migration verschieben, jetzt OpenAPI-Schemas für Contract-Enforcement ergänzen und erneut prüfen, wenn Sie an Latenz-SLOs stoßen. Soll ich einen ADR-Entwurf erstellen?
Bitte reviewe diesen PR — er fügt eine neue Caching-Schicht zur Datenpipeline hinzu.
Kritische Punkte: (1) Der Cache-Key enthält die Nutzer-Zeitzone, was bei Zeitumstellungen zu Thrashing führt — verwenden Sie stattdessen UTC-Epoch-Grenzen. (2) Cache-Invalidierung bei Schema-Migrationen fehlt — fügen Sie ein Versions-Präfix zum Key hinzu. (3) Die LRU-Eviction-Größe von 512 Einträgen ist hartcodiert; erwägen Sie konfigurierbare Werte für verschiedene Deployment-Größen. Vorschlag: eine Cache-Miss-Metrik ergänzen, um die Hit-Rate von Anfang an in Datadog zu verfolgen. Insgesamt: Der Performance-Gewinn ist real und der Ansatz solide — ich kann das als Review-Kommentar für einen menschlichen Freigebenden posten, freigeben oder mergen kann ich es nicht.
Wir müssen uns zwischen Sentry und Datadog für das Error-Tracking entscheiden. Budget ist knapp.
Vergleich für Ihren genannten Kontext (Selbstbetrieb, DSGVO-gebunden, unter 10 Engineers): Sentry im Selbstbetrieb ist kostenlos und hält Fehlerdaten auf Ihrer Infrastruktur — starke DSGVO-Position, aber Sie tragen die Betriebslast. Datadog ist ein gehosteter Dienst und beginnt bei ~15 $/Host/Monat; leistungsstarke Dashboards und Log-Korrelation, aber die Daten verlassen Ihre VPC. Wenn Budget die primäre Einschränkung ist und Sie bereits Kubernetes betreiben, ist Sentry im Selbstbetrieb die klarere Wahl. Datadog würde ich nur empfehlen, wenn Sie Logs, APM und Error-Tracking vereinheitlicht brauchen und die Kosten bei Skalierung rechtfertigen können.
Integrationen
Liest PRs und Diffs, entwirft Review-Kommentare, schlägt Reviewer vor und kennzeichnet veraltete Branches.
Liest Issues, bewertet Tech-Debt-Tickets und aktualisiert Status, soweit Sie Schreibrechte erteilen.
Fasst Fehlertrends zusammen, erkennt Regressionen und verknüpft sie mit den verantwortlichen Commits.
Postet Engineering-Digests, PR-Triage-Zusammenfassungen und Incident-Alerts in die von Ihnen gewählten Channels.
Schreibt ADRs, Meeting-Notizen, Architekturdokumente und Anbieterbewertungsmatrizen in die freigegebenen Seiten.
Liest die Incident-Historie zur Einordnung von Zuverlässigkeitsmetriken und für Post-Mortems.
Die Berechtigungsgrenze
Was er lesen darf: die Repositories, Issue-Tracker, Fehlerströme und Incident-Historien, die Sie ausdrücklich über MCP anbinden, sowie die Dokumente, die Sie in Ihren eigenen Vektorspeicher eingelesen haben. Nichts wird eigenständig entdeckt — ein nicht angebundenes Repository ist für den Agenten unsichtbar, und Retrieval-Antworten führen ihre Quellen mit, sodass ein Reviewer die Argumentation am Material prüfen kann.
Was er tun darf: entwerfen. Review-Kommentare, ADRs, Runbooks, Digests, Anbieter-Vergleichsmatrizen, Interview-Raster. Wo Sie einen Schreibbereich freigeben — ein Posting in einen Slack-Channel, eine Statusänderung an einem Issue, eine neue Notion-Seite —, läuft die Aktion über ein Freigabe-Gate, das Sie pro Rolle und Tool-Klasse konfigurieren, und landet zusammen mit der zugrunde liegenden Modellentscheidung im Append-only-Audit-Ledger.
Was ihm verwehrt ist: Code mergen, sein eigenes Review freigeben, ein Deployment auslösen, Infrastruktur ändern oder ein System außerhalb seines freigegebenen Bereichs erreichen. Das sind keine Konventionen, um deren Einhaltung das Modell gebeten wird — es sind außerhalb des Modells durchgesetzte Berechtigungsgrenzen. Deshalb lautet die interessante Frage zu einem solchen Agenten, was ihm erteilt wurde, nicht, was ihm gesagt wurde.
Frequently asked questions
Wie reviewt der Engineering-Agent Code?
Er liest den PR-Diff über die GitHub-Integration und wendet eine strukturierte Review-Checkliste an: Korrektheit, Sicherheitsoberfläche, Performance-Implikationen, Testabdeckung und Einhaltung der Muster in Ihrer Codebasis. Die Befunde werden verständlich zusammengefasst, kritische Punkte getrennt von Vorschlägen. Das Ergebnis ist ein Review-Entwurf; freigeben oder mergen tut ein Mensch.
Hat er Zugriff auf Ihre Repositories?
Nur auf die, die Sie freigeben. Der Agent verbindet sich über eine GitHub-App-Installation, die auf die von Ihnen gewählten Repositories beschränkt ist; da OperativeOps in Ihrem eigenen Netz läuft, bleibt der Integrationsverkehr dort. Quellcode erreicht einen externen Modellanbieter nur, wenn Sie einen konfigurieren — mit einem lokalen Ollama- oder vLLM-Backend bleibt auch die Inferenz in Ihrem Perimeter.
Welches Modell betreibt ihn?
Das, welches Sie konfigurieren. OperativeOps ist Bring-your-own-Model: OpenAI, Anthropic oder ein Open-Weight-Modell auf Ihren eigenen GPUs über Ollama oder vLLM, pro Agent umschaltbar. Der Engineering-Agent kann auf einem anderen Backend laufen als der Rest Ihrer Bereitstellung, wenn Ihre Review-Richtlinie das verlangt.
Kann er autonom Code oder Infrastruktur ändern?
Nein. Er liest und empfiehlt. Er kann Pull-Request-Beschreibungen, ADRs und Runbooks entwerfen, aber keinen Code mergen, kein Deployment auslösen und keine Infrastruktur verändern. Jede schreibende Aktion setzt einen ausdrücklich erteilten Bereich voraus und läuft über ein Freigabe-Gate pro Aktion.
Was ist der Unterschied zu GitHub Copilot?
Copilot ist ein Inline-Completion-Werkzeug in der IDE — es hilft einzelnen Entwicklern, schneller Code zu schreiben. Hier geht es um einen rollenbasierten Agenten auf Team- und Architekturebene: Er synthetisiert über PRs, Issues, Incidents und Anbieterbewertungen hinweg und bereitet Entscheidungen für die Engineering-Leitung auf. Beides ergänzt sich, es konkurriert nicht.
Kann er in air-gapped Umgebungen laufen?
Ja. Der Selbstbetrieb unterstützt vollständig air-gapped Betrieb in Kombination mit einem On-Premises-Modell-Backend wie vLLM oder Ollama. GitHub Enterprise Server und ein selbstbetriebenes Linear können die Cloud-Äquivalente ersetzen. Melden Sie sich für eine Architekturprüfung.