Kategorie: Erklärer

Von sechs geplanten Drift-Regeln gegen einen AKS-Cluster haben am Ende nur zwei getragen, und auch die erst nach einem Umbau. Drei scheiterten an der Plattform, eine blieb aus Risikogründen ungetestet. Der Abstand zwischen dem, was im Handbuch machbar aussieht, und dem, was in einem echten Cluster mit echtem Lifecycle tatsächlich feuert, ist der eigentliche Erkenntnisgewinn eines Praxistests mit Drasi.

Drasi ist eine Plattform für Continuous Queries. Statt Metriken zu pollen oder Admission-Webhooks zu beauftragen, hält Drasi einen materialisierten Graphen des Cluster-Zustands aktuell und bewertet stehende Cypher-Abfragen bei jeder relevanten Änderung neu. Reaktionen hängen an Zustandsübergängen, nicht an Ticks einer Uhr. Diese Übergangslogik macht das Werkzeug für Drift interessant, also für Abweichungen, die erst nach der Admission entstehen und über Zeit an Aussagekraft gewinnen oder verlieren.

Warum bestehende Tools die Lücke nicht schließen

In einem GitOps-Cluster laufen typischerweise drei Klassen von Wächtern parallel. Gatekeeper und Kyverno blockieren unerwünschte Konfiguration zum Admission-Zeitpunkt. Flux und Argo CD melden, wenn der Live-Cluster vom Git-Stand abweicht. Prometheus alarmiert auf Metriken mit einer for:-Bedingung. Keiner davon ist falsch, alle drei ergänzen sich. Ihnen fehlt die Fähigkeit, eine Frage zu beantworten, die mehrere Ressourcentypen relational zueinander in Beziehung setzt.

Solche relationalen Fragen sehen im Kubernetes-Alltag vertraut aus: Läuft dieses Deployment nach fünf Minuten immer noch unter repliziert? Gehört zu diesem Pod ein Image, das nicht aus der zugelassenen Registry stammt? Gibt es in diesem Namespace überhaupt eine NetworkPolicy? Solche Schnitte zwischen Deployment, ReplicaSet, Pod und Namespace lassen sich mit reinen Admission-Regeln oder mit Metriken nur umständlich abbilden. Genau hier setzt Drasi an, mit stehenden Cypher-Queries über den Ressourcen-Graphen, mit temporalen Funktionen wie trueFor und trueLater, und mit einem Resultset, das sich eigenständig aktuell hält.

Wichtig ist die Einordnung gegenüber den etablierten Tools. Drasi ersetzt weder Gatekeeper noch Argo noch Prometheus. Es besetzt eine Nische dazwischen: Laufzeitdrift, der erst nach der Admission entsteht und nur sichtbar wird, wenn man Beziehungen zwischen Ressourcen ausdrücken kann.

Installation und die Frage der Watchliste

Der Einstieg ist unkompliziert. Drasi wird entweder im selben Cluster ausgerollt oder eine externe Instanz wird über ein kubeconfig-Secret an den Zielcluster angebunden. Für die RBAC gilt das übliche Prinzip minimaler Rechte: Die Quell-Credential benötigt ausschließlich list und watch auf den Ressourcentypen, die deine Regeln tatsächlich lesen. Ein Servicekonto für ein Lese-Dashboard ist das passende Vorbild, nicht mehr.

Was sich beim ersten Test als harte Grenze herausstellt, ist die feste Watchliste der Kubernetes-Source. Drasi beobachtet unabhängig von RBAC und unabhängig von deinen Queries genau zwölf Ressourcentypen: Pod, Deployment, ReplicaSet, StatefulSet, DaemonSet, Job, Service, ServiceAccount, Node, Ingress, PersistentVolume und PersistentVolumeClaim. Namespace, NetworkPolicy, PodDisruptionBudget und Secret fehlen auf dieser Liste. Kein RBAC-Grant ändert daran etwas. Wenn deine Regel einen dieser Typen benötigt, lässt sie sich auf der Kubernetes-Source heute nicht ausführen.

Sechs Regeln geplant, zwei haben den ersten Lauf überlebt

Der Praxistest startete mit sechs Regeln, die gegen die Dokumentation formuliert wurden. Jede einzelne wurde anschließend gegen einen Live-Cluster mit absichtlich herbeigeführten Verstößen geprüft. Das Ergebnis war ehrlicher als die Dokumentation vermuten lässt.

Unter-replizierte Deployments funktionierten, mussten aber umgeschrieben werden. Der Grund war handfest: status.readyReplicas ist während eines Rollouts null, und die ursprüngliche Query warf dann auf jedem Mid-Rollout-Deployment einen Fehler. Erst coalesce(status.readyReplicas, 0) macht die Regel alltagstauglich.

Images aus nicht zugelassenen Registries funktionierten, mussten aber ebenfalls umgeschrieben werden. Die gewohnte Cypher-Funktion STARTS WITH parst im gepinnten Parser-Subset nicht. Die tragfähige Form ist left(c.image, N) <> 'prefix'. Was zunächst wie eine Marotte wirkt, ist eine echte Einschränkung der unterstützten Sprachoberfläche.

Namespaces ohne NetworkPolicy ließen sich nicht realisieren. Zwei Probleme stapeln sich hier: Erstens versteht der Parser keine EXISTS { MATCH ... }-Subqueries, zweitens werden Namespace und NetworkPolicy schlicht nicht materialisiert. Die Regel scheitert an der Plattform, nicht an der Query-Logik.

Zertifikatsablauf über TLS-Secrets scheiterte am gleichen Watchlisten-Problem. Secrets gehören nicht zu den zwölf beobachteten Typen. Die Idee hinter der Regel war didaktisch trotzdem wertvoll, denn trueLater ist das Werkzeug der Wahl, wenn ein Alarm zu einem festen Zeitpunkt in der Zukunft feuern soll, ohne Cron-Job.

PodDisruptionBudget-Erschöpfung scheiterte ebenfalls an der Watchliste. PDB ist nicht enthalten. Wer auf PDB-Erschöpfung überwachen will, muss heute einen anderen Mechanismus wählen.

Sustained Node Pressure war als sechste Regel geplant und syntaktisch sauber, aber die Live-Erprobung blieb aus. Der Grund war Risiko: Das Test-Node war ein Shared Control-Plane-Knoten, und ein absichtlich herbeigeführter Memory-Druck hätte die gesamte Drasi-Umgebung mitreißen können. Die Mechanik ist bewiesen, der Übergang in einem echten Störfall nicht.

Drei Ersatzregeln, die ihren Platz im Rulebook verdient haben

Was die nicht realisierbaren Regeln nicht abdecken konnten, übernahmen drei Ersatzregeln. Zwei davon sind gegen echte Verstöße gelaufen, eine nur syntaktisch.

Die Regel für unter-replizierte Deployments ist das Aushängeschild für trueFor. Ein flackernder Zustand während eines normalen Rollouts feuert nicht. Erst eine echte, fünf Minuten anhaltende Verknappung schlägt durch. Wer das in der Praxis schnell erleben will, kann das Fenster im Test verkürzen und einen nodeSelector setzen, der niemals matcht, sodass das Deployment dauerhaft unerfüllt bleibt. Das Ergebnis kam nach Ablauf des Debounce-Fensters sauber als Transition.

Die Image-Registry-Regel nutzt left() als Workaround für das fehlende STARTS WITH. Was zunächst wie eine mechanische Notlösung wirkt, deckt beim ersten realen Lauf zwei Eckfälle auf. Erstens: Dapr-Sidecars melden sich als docker.io/daprio/daprd:1.14.5. Eine rein auf Präfixen basierende Allowlist muss docker.io/daprio/ explizit aufnehmen, sonst flaggt jeder Drasi-Pod mit Sidecar. Zweitens: Calico-Komponenten referenzieren Images als reiner sha256:-Digest ohne Registry-Präfix. Eine präfixbasierte Regel ist an dieser Stelle blind. Das ist kein Randbefund, sondern eine echte Lücke in der Sichtbarkeit, die man benennen sollte, statt sie als Fußnote zu verstecken.

Die Crashlooping-Container-Regel wirkt auf den ersten Blick trivial, benötigt aber eine unwind-Middleware, um die containerStatuses aus jedem Pod in eigene Container-Knoten zu heben. Wer den Middleware-Block versehentlich unter spec: statt unter sources: setzt, bekommt einen lautlosen Apply-Fehler ohne hilfreiche Diagnose. Korrekt eingebunden meldet die Regel sauber jeden Pod, der in CrashLoopBackOff wartet.

Die Replicaless-Deployments-Regel richtet sich gegen Deployments ohne ReplicaSet. Der erste Reflex war wieder eine EXISTS { MATCH }-Subquery, mit dem bekannten Parser-Problem. Die tragfähige Variante ist OPTIONAL MATCH mit count(). In einem gesunden Cluster bleibt das Resultset erwartungsgemäß leer.

Was eine gesunde Regelmenge leistet und was sie nicht leistet

Eine gut justierte Regelmenge ist fast immer langweilig, und genau das ist das Ziel. Auf einem konformen Cluster sitzen alle Regeln leer, ohne Zeilen, ohne Rauschen, und bleiben es auch. Ein Eintrag erscheint nur in dem Moment, in dem ein echter Verstoß seine Schwelle überschreitet, und verschwindet wieder, sobald das zugrundeliegende Problem behoben ist. Nicht nach einem Poll-Intervall, sondern beim nächsten relevanten Übergang im Graphen.

Wenn eine Regel gegen einen gesunden Cluster dauerhaft feuert, liegt das fast immer an der Regel selbst. Eine fehlende coalesce-Behandlung oder ein zu kurzes Debounce-Fenster, das normale Rollouts nicht ausspart, sind die häufigsten Ursachen. Wenn eine Regel hingegen kommentarlos leer bleibt, egal was im Cluster kaputt geht, dann lohnt sich der Blick auf die Watchliste, bevor man dem vermeintlich grünen Zustand vertraut.

Parser-Surface, hart erlernt

Was in der Dokumentation knapp gehalten ist, zeigt sich im laufenden Betrieb deutlich konkreter. Die unterstützten Vergleichsoperatoren sind =, <>, !=, <, <=, >, >=, IN und IS, dazu arithmetische Operatoren. Nicht unterstützt sind STARTS WITH, CONTAINS, ENDS WITH, Regex mit =~ und EXISTS { MATCH }-Subqueries. Unterstützt sind left(), coalesce(), OPTIONAL MATCH mit Aggregation sowie das unwind-Middleware. Der Middleware-Block sitzt unter sources: im Manifest, nicht unter spec:.

Ein nützlicher Nebeneffekt für alle, die das selbst nachvollziehen wollen: Beim Listen der Pod-Images auf dem Test-Cluster tauchen die tatsächlichen Plattform-Komponenten auf, etwa query-container-query-host, query-container-view-svc, query-container-publish-api, source-query-api, source-change-dispatcher, source-change-router. Wer Registry-Probes gegen nackte Namen wie query-host oder view-svc laufen lässt, wird mit 404ern abgespeist, weil die Komponenten in Containern mit eigenem Namensschema leben.

Was das konkret bedeutet

Drasi ist eine sinnvolle Ergänzung im Werkzeugkasten eines GitOps-Clusters, kein Ersatz für die etablierten Wächter. Es füllt eine Lücke, die weder Admission Policy noch Git-Diff noch Metrik-Alerting schließen können, nämlich die relationale, zeitliche Frage über Ressourcen hinweg, nachdem sie admitted wurden. Wer Drasi produktiv einsetzen will, sollte drei Dinge verinnerlicht haben: die feste Watchliste und ihre Grenzen, die Parser-Surface und ihre Eigenheiten, die Tatsache, dass eine gesunde Regelmenge fast nie etwas meldet und gerade dadurch ihren Wert beweist.

Wer im Cluster mit Kubernetes-Secrets, NetworkPolicies oder PodDisruptionBudgets arbeiten will, muss heute auf andere Mechanismen ausweichen oder auf eine Erweiterung der Source warten. Für die zwölf beobachteten Typen jedoch, allen voran Deployments, Pods, Container und Nodes, liefert Drasi eine Form von Sichtbarkeit, die mit Bordmitteln nicht erreichbar ist, ohne Cron, ohne Ticks, mit echtem Übergangsverhalten.

Quelle: luke.geek.nz

Ein Nutzer öffnet die ChatGPT-App und entdeckt neben dem bekannten Reiter „Chat“ plötzlich einen zweiten: „Work“. Er klickt darauf und fragt sich, was dieser neue Bereich können soll. In den folgenden Wochen stellt er fest: Hinter diesem Namen steckt mehr als eine simple Erweiterung des Chat-Modus.

Simon Willison, britischer Entwickler und Fürsprecher offener Daten, hat das Produkt seit der Ankündigung am 9. Juli 2026 intensiv getestet. Sein Fazit: ChatGPT Work kann viel – und verwirrt zugleich. Außerdem ist es eigentlich nicht ein Produkt, sondern zwei.

Zwei Produkte, ein Name: Work Cloud und Work Local

Willison nennt die beiden Varianten „Work Cloud“ und „Work Local“. Work Cloud läuft über chatgpt.com und die mobilen Apps. Work Local bekommst du über die Desktop-App, die früher Codex hieß. Sie kann auf Dateien auf deinem Computer zugreifen und Programme direkt ausführen. Für Nicht-Entwickler wirkt Work Local wie eine entschärfte Codex-Variante, sagt Willison. Sein Fokus liegt auf Work Cloud. Die schauen wir uns hier an.

Work kostet Geld. Das Produkt ist nur für Abonnenten ab 20 Dollar pro Monat verfügbar. Nutzer des kostenlosen Tarifs und die Go-Stufe für acht Dollar haben keinen Zugriff. Work ist also in den bestehenden Abos enthalten – ein separates Work-Abo gibt es nicht. Dafür bekommst du im 20-Dollar-Tarif einige Funktionen, die im normalen Chat fehlen.

ChatGPT Work im Vergleich zu ChatGPT Chat: Was wirklich neu ist

OpenAI selbst sagt: Chat ist für Antworten, Erklärungen und Brainstorming da, Work für Aufgaben mit klarem Ergebnis, etwa Briefings, Präsentationen oder Analysen. Willison findet diese Erklärung nutzlos. Diese Aufgaben hat er schon lange mit Chat erledigt. Die entscheidende Frage: Welche Fähigkeiten hat Work, die Chat nicht hat? In Tests hat er eine klare Liste zusammengestellt.

Da ist zunächst die Modellauswahl. In Work stehen GPT-5.6 Sol, Luna und Terra bereit, jeweils mit den Denkstufen Light, Medium, High, Extra High, Max und Ultra. Chat bietet GPT-5.6 Instant und bis zu High. Wer 100 Dollar im Monat zahlt, bekommt Extra High und Pro. Diese Aufteilung verwirrt, weil OpenAI nicht erklärt, welche Modelle dahinterstecken. Vermutlich ist Instant Sol, so Willison. Ultra wiederum delegiert offenbar besonders häufig an Sub-Agents.

Ein weiterer Unterschied betrifft die Abrechnung: Work-Sitzungen laufen gegen das Codex-Kontingent, Chat-Sitzungen haben ein eigenes Kontingent. Das könnte auch die unterschiedliche Modellauswahl erklären. Klar ist: Work ist kein bloßes Rebranding von Chat, sondern ein eigenständiges Werkzeug.

Code-Ausführung mit Internetzugang: Das Herzstück von Work Cloud

Was Willison an Work Cloud am meisten interessiert, ist die Code-Ausführungsumgebung. Schon 2023 hatte OpenAI mit dem Code Interpreter Maßstäbe gesetzt. Doch in Chat darf diese Umgebung nicht mit dem Internet kommunizieren. Pakete installieren? Teilweise, aber unzuverlässig. In Work Cloud ist das anders: Die Umgebung kann im Standardfall auf alle Domains zugreifen. Du kannst GitHub-Repositories klonen, Abhängigkeiten installieren und mit Web-APIs arbeiten.

Dazu kommt ein unsichtbarer Chrome-Browser. Work öffnet Webseiten, füllt Formulare aus und macht Screenshots. Verlangt eine Seite eine Anmeldung, kannst du selbst übernehmen. Passwörter und Zwei-Faktor-Codes bleiben in deiner Hand, das Modell sieht sie nicht. Willison hat den Browser sogar JavaScript-Code gegen das DOM einer Webseite ausführen lassen, um alle Überschriften zu extrahieren. Das funktionierte reibungslos.

Auch der Dateispeicher ist neu: Chat-Sitzungen bekommen jedes Mal einen frischen, isolierten Speicherbereich. Work-Sitzungen behalten ihre Ordner im gemeinsamen /workspace-Verzeichnis. Willison hat dort inzwischen 171 Ordner. Verschiedene Sitzungen können auf dieselben Dateien zugreifen, solange sie laufen. So lässt sich eine Arbeit ohne Unterbrechung über mehrere Sitzungen fortsetzen. Im bisherigen Chat-Modell gab es das nicht.

ChatGPT Sites, Sub-Agents und geplante Aufgaben: Work wird zum Baukasten

Work kann komplette Websites erstellen und veröffentlichen – über Cloudflare Workers. Diese Seiten dürfen HTML und JavaScript enthalten und serverseitige Funktionen nutzen, etwa mit den Datenbanken D1 und R2. Willison hat auf diese Weise ein Verzeichnis über „Pelican in her Piety“-Darstellungen in London gebaut – ein mittelalterliches Motiv, das man dann plötzlich überall entdeckt. Die Seite ist standardmäßig privat, kann aber öffentlich gemacht werden. In Team-Plänen auch bestimmten Personen zugänglich.

Außerdem lassen sich in Work Sub-Agents starten, also parallele Teil-Agenten, die mit Sol, Luna oder Terra arbeiten. Chat kann das nicht. Und schließlich gibt es geplante Aufgaben: Du kannst Work anweisen, jeden Morgen um 8 Uhr zu einem bestimmten Thema zu suchen und dich nur bei relevanten Neuigkeiten zu melden. Willison hat herausgefunden, dass diese Funktion auch in Chat verfügbar ist. Mit den Fähigkeiten von Work wird sie aber nützlicher – etwa wenn eine geplante Aufgabe stündlich eine ChatGPT-Site aktualisieren soll.

Sicherheitsbedenken und eine unnötig verschleierte Dokumentation

So begeistert Willison von den Möglichkeiten ist, so kritisch sieht er die Sicherheitslage. Er warnt vor einer „tödlichen Dreifaltigkeit“ bei Agenten-Systemen: Zugriff auf private Daten, Konfrontation mit unvertrauenswürdigen Inhalten und ein Kanal, um gestohlene Daten nach außen zu schicken. ChatGPT Work vereine diese drei Elemente. Offen ist, wie OpenAI die Sitzungen vor Prompt-Injection-Angriffen schützt – also davor, dass manipulierte Webseiten oder Dokumente das System dazu bringen, Dinge zu tun, die es nicht tun sollte.

Willison vermutet, dass ein ähnlicher automatischer Review-Mechanismus wie bei Codex greift, aber OpenAI schweigt sich aus. Diese Intransparenz zieht sich durch das gesamte Produkt: Die Dokumentation erkläre, wofür Work gedacht ist, aber nicht, welche Werkzeuge und Systemprompts tatsächlich verwendet werden. Willison hat deshalb kurzerhand eine Work-Sitzung beauftragt, eine Website zu erstellen, die alle 223 registrierten Tools auflistet – davon stammen sechs aus seinen eigenen MCP-Konfigurationen. Zusätzlich hat er die zugehörigen „Skills“ im Klartext extrahiert. Dabei kamen 44 Fähigkeiten zum Vorschein, darunter ein Skill namens „control-browser“, der die komplette Browser-API-Dokumentation enthält. Genau diese Informationen hätte sich Willison von OpenAI gewünscht.

Das Fazit fällt gemischt aus. Für Endnutzer hat OpenAI noch kein mächtigeres Tool angeboten. Internetzugang, Code-Ausführung, persistenter Speicher und eigene Websites: Das kann der normale Chat nicht. Gleichzeitig zeigt der Wirbel um Modellnamen, Kontingente und fehlende Dokumentation, wie viel Arbeit noch vor OpenAI liegt. Wer Work nutzt, sollte sich bewusst sein: Das System kann viel – und es hat viel Macht über deine Daten.

Quelle: simonwillison.net

Viele gehen davon aus, dass CI/CD-Pipelines streng deterministisch sein müssen – feste Schritte, keine Überraschungen. GitHub Agentic Workflows zeigt, dass diese Annahme zu kurz greift. KI-Agenten übernehmen Triage, Doku-Updates oder Testverbesserungen, du behältst die Kontrolle.

Die Idee klingt verlockend. Statt morgens Unmengen von Issues, Pull Requests und fehlgeschlagenen Tests zu sichten, bekommst du eine aufbereitete Zusammenfassung. Der Agent erstellt außerdem Vorschläge, die du nur noch durchsiehst und freigibst. Das spart Zeit. Es wirft Fragen auf: Wie sicher ist das? Was passiert, wenn er falsch liegt? Was kostet das?

Dieser Artikel beantwortet die Kernfragen: Was ist GitHub Agentic Workflows? Wie integrierst du es in deine CI/CD-Landschaft? Welche Sicherheits- und Kostenmechanismen sind eingebaut? Du lernst, eigene Workflows zu erstellen und die Rolle der AI-Engines kennen. Am Ende kannst du einschätzen, ob sich der Einsatz für dein Team lohnt.

Was sind GitHub Agentic Workflows?

GitHub Agentic Workflows erweitert GitHub Actions. Du nutzt es über die offizielle CLI. Der Name klingt sperrig, das Konzept ist simpel. Statt fixer YAML-Schritte, die nur Befehle ausführen, definierst du Arbeitsaufträge in Markdown-Dateien. Ein KI-Agent versteht diese Aufträge, trifft Entscheidungen und schlägt Änderungen vor.

Der Agent arbeitet wie ein neuer Kollege mit Repository-Zugriff, aufgabenorientiert: „Erstelle einen täglichen Statusbericht als Issue“ oder „Überprüfe offene Pull Requests auf fehlende Tests“. Er kennt die Repository-Struktur, liest relevante Dateien und erzeugt einen Output – innerhalb klar definierter Grenzen.

Technisch basiert es auf dem Befehl gh aw compile. Er übersetzt eine Markdown-Datei in eine abgesicherte .lock.yml-Datei. GitHub Actions führt diese mit der gewählten AI-Engine aus. Unterstützt werden fünf Engines: GitHub Copilot (Standard), Claude Code, OpenAI Codex, Google Gemini und Pi. Die Engine arbeitet nicht direkt auf deinem Repository, sondern in einer Sandbox.

So funktioniert die Automatisierung im Alltag

Der Alltag sieht oft so aus: ein Repository mit vielen Issues, Pull Requests und Diskussionen, jeden Morgen aufs Neue. Ein Workflow erzeugt automatisch einen Statusbericht. Das offizielle GitHub-Beispiel zeigt, wie wenig Code nötig ist. Eine Markdown-Datei definiert den Trigger (täglich per Zeitplan), die Berechtigungen (nur Lesen, bestimmte Scopes) und den Auftrag an den Agenten.

Der Agent liest die letzten Aktivitäten – Issues, Pull Requests, Discussions, Releases, Codeänderungen – und schreibt einen kompakten Report. Er hebt Ziele hervor, erkennt Fortschritte und schlägt nächste Schritte vor. Das Ergebnis landet als GitHub Issue im Repository, mit festgelegtem Titel-Präfix und automatischer Bereinigung älterer Ausgaben.

So unterscheidet sich GitHub Agentic Workflows von herkömmlichen CI/CD-Pipelines. In klassischen Pipelines baust du manuell Schritte, die Events abfragen und Daten ausgeben. Hier überlässt du dem Agenten die Interpretation und Zusammenfassung. Du prüfst das Ergebnis und entscheidest, ob du die Vorschläge übernimmst.

Für den Einstieg reicht eine einfache Markdown-Datei. Du schreibst den Workflow, führst gh aw compile aus, die fertige GitHub-Actions-Datei entsteht. Den Rest übernimmt GitHub. Das ist deutlich einfacher als klassische Pipelines mit dutzenden YAML-Zeilen.

Guardrails und Sicherheit

KI-Agenten in einem Repository klingen riskant. Sie haben Schreibrechte, können Daten nach außen übertragen. GitHub hat Sicherheitsmaßnahmen eingebaut. Das Stichwort lautet Defense-in-Depth: mehrschichtige Kontrolle statt einer einzelnen Absicherung.

Erstens laufen Agenten in einer Sandbox, einer isolierten Umgebung ohne Zugriff auf das gesamte Dateisystem oder Netzwerk. Zweitens sind die Berechtigungen stark eingeschränkt. Ein Workflow nutzt nur die Scopes, die du in den Frontmatter-Optionen festlegst. Drittens werden Outputs über eine spezielle Schnittstelle gegated. Gefährliche Anweisungen oder bösartiger Inhalt werden herausgefiltert.

Warum? KI-Agenten sind anfällig für Prompt-Injection. Ein Angreifer kann einen bösartigen Kommentar in ein Issue schreiben, um den Agenten zu einer schädlichen Aktion zu verleiten. Ohne Guardrails könnte der Agent das ausführen. Mit Sandbox und gated Outputs bleibt die Aktion wirkungslos außerhalb der definierten Grenzen. GitHub bietet zusätzlich eine Threat Detection, die verdächtige Verhaltensmuster erkennt.

Du kannst die Sicherheitsarchitektur als gegeben betrachten. Trotzdem solltest du wissen, welche Berechtigungen du freigibst. Die offizielle Dokumentation beschreibt das Modell detailliert. Wer das Tool im Unternehmenskontext betreibt, sollte das Sicherheitsmodell verstehen und eigene Tests durchführen.

Kosten im Griff: Budgets, Transparenz und OpenTelemetry

KI-Agenten verbrauchen Tokens, Tokens kosten Geld. Ohne Begrenzung überrascht dich die Rechnung am Monatsende. GitHub Agentic Workflows bietet mehrere Mechanismen zur Kostenkontrolle.

Die wichtigste Kennzahl ist der AI Credit (AIC). Jeder Aufruf eines Agenten verbraucht Credits. Der Parameter max-ai-credits pro Run legt das Maximum fest. Das ist ein hartes Budget. Überschreitet der Agent das Limit, wird der Lauf abgebrochen. So verhinderst du, dass ein fehlkonfigurierter Workflow das gesamte Monatsbudget auffrisst.

Zur Überwachung gibt es gh aw logs und gh aw audit. Sie zeigen, welche Runs die meisten Tokens und Credits verbrauchen. Damit passt du Prompts und Trigger an, bevor die Kosten davonlaufen. Für detaillierte Analysen exportierst du OpenTelemetry-Traces an ein Backend und baust dir Dashboards, die Verbrauch und Kosten in Echtzeit anzeigen.

Auch die Effektivität zählt. Ein billiger Lauf ohne nützliche Ergebnisse ist so teuer wie ein teurer Lauf mit wertvollem Output. Vergleiche Kosten und Ergebnisse über einen längeren Zeitraum. Schau nicht nur auf die monatliche Summe, sondern auf den geschaffenen Wert.

Eigene Workflows erstellen und anpassen

Du musst kein Experte für natürliche Sprachverarbeitung sein. GitHub bietet in der Doku einen Workshop, der Schritt für Schritt zeigt, wie du einen Workflow aus dem Browser erstellst. Alternativ nutzt du die CLI, schreibst eine Markdown-Datei und kompilierst sie.

Der Schlüssel ist das Frontmatter in der Markdown-Datei. Dort legst du Trigger, Berechtigungen, Ausgabeoptionen und die AI-Engine fest. Beispiel: Ein Agent soll jedes neue Issue automatisch kategorisieren. Du definierst den Trigger on: issues, die Permissions und die Ausgabe als Kommentar oder Label. Den Rest macht der Agent.

Neu ist die Integration eigener AI-Engines. Neben den fünf eingebauten Engines – Copilot, Claude Code, Codex, Gemini und Pi – kannst du über den Engine-Import eigene Coding-Agent-CLIs einbinden. Das funktioniert über Markdown-Definitionen und bietet Flexibilität für Teams mit speziellen Anforderungen.

Agentic Workflows passen in bestehende Repository-Automatisierung. Du betreibst sie neben klassischen GitHub Actions und ergänzt schrittweise neue Automatisierungen. In der Galerie auf der GitHub-Website findest du fertige Vorlagen für typische Aufgaben – von Doku-Updates bis zu Testverbesserungen.

Was das für deine CI/CD-Strategie bedeutet

GitHub Agentic Workflows ersetzt keine deterministischen CI/CD-Pipelines. Es ergänzt sie um intelligente Automatisierung. Deine Build-, Test- und Deploy-Schritte bleiben vorhersagbar und reproduzierbar. Die KI-Agenten übernehmen Aufgaben, die Kontext und Sprachverständnis erfordern – Triage, Berichte, Vorschläge.

Diese Arbeitsteilung ist sinnvoll. Ein Agent liefert morgens einen klaren Statusbericht, spart Zeit und reduziert kognitive Last. Erwarte aber keine fehlerfreie Arbeit. Ergebnisse müssen geprüft und freigegeben werden. Die Guardrails schützen nicht vor Fehlentscheidungen, sondern vor unkontrollierten Folgen.

Für Entwickler bedeutet das eine neue Form der Zusammenarbeit. Du delegierst Aufgaben an einen KI-Agenten, behältst aber die Kontrolle über kritische Schritte. Das erinnert an Teamarbeit mit einem effizienten, gelegentlich kreativen Kollegen. Du lernst, wann du ihm vertraust und wo du nachhakst.

Entscheidend ist dein Anwendungsfall. Wird dein Repository täglich mit Issues und PRs überschwemmt, bieten Agentic Workflows echten Mehrwert. Sind deine Prozesse stark reguliert und jede Änderung kritisch, schätzt du Sandbox und Budgetgrenzen, musst aber manuelle Prüfungen einplanen.

GitHub Agentic Workflows ist kein Wundermittel, sondern eine durchdachte Plattform. Einfache Markdown-Definitionen, klar definierte Sicherheitsmaßnahmen, transparente Kosteninstrumente. Das macht das Tool für Teams interessant, die erste Schritte mit KI-Agenten wagen. Der Wert: ein kontrollierter Rahmen zum Experimentieren. Du findest heraus, welche Automatisierungen wirklich etwas bringen, ohne sofort Risiken einzugehen.

Quelle: github.github.com

Wie viel Autonomie sollte ein KI-Agent bekommen? Das ist keine theoretische Frage mehr, sondern eine operative Entscheidung. Viele Teams stehen vor einer binären Wahl: Vollzugriff oder read-only. Vollzugriff ist riskant, weil Agenten unvorhersehbar scheitern können. Read-only lässt den größten Teil des Nutzens ungenutzt.

Die Differenz zwischen dem, was ein Agent tun könnte, und dem, was ein Betreiber ihm zutraut, nennen Dev Arora, Meera Kezhukoot und Sathish Kumar Prabakaran in einem Beitrag im AWS-Architecture-Blog die Vertrauenslücke. Der Text stammt damit von AWS selbst und beschreibt das Muster entlang der hauseigenen Dienste wie Amazon Bedrock AgentCore – eine Herstellerperspektive, auch wenn das Grundmuster übertragbar ist. Um sie zu schließen, schlagen sie ein architektonisches Muster vor: abgestufte Autonomie. Agenten verdienen sich erweiterte Berechtigungen durch nachgewiesene Zuverlässigkeit – und verlieren sie wieder, wenn die Leistung nachlässt. Klingt nach einem vernünftigen Prinzip. Aber wie setzt man das technisch um?

Die Vertrauenslücke und die sechs Schichten des Frameworks

Herkömmliches Identity and Access Management beantwortet die Frage „Wer darf was?“ genau einmal, bei der Bereitstellung. Dieses Modell setzt voraus, dass sich ein Prinzipal konsistent verhält. Ein Agent auf Basis eines großen Sprachmodells bricht diese Annahme. Derselbe Agent kann am Montag präzise arbeiten und am Dienstag nach einer Prompt-Änderung oder einem Modell-Update halluzinieren.

Um die Lücke zu schließen, braucht es drei Fähigkeiten, die rohe API-Logs kaum liefern. Erstens: Sichtbarkeit. Logs zeigen Ingenieuren, was passiert ist, sagen einem Compliance-Verantwortlichen aber nichts darüber, ob eine Aktion sicher war. Zweitens: Entscheidungsherkunft. Man muss eine Aktion zurückverfolgen können zu dem Signal, das sie ausgelöst hat, zu den betrachteten Alternativen und zur Konfidenz des Agenten. Drittens: Umkehrbarkeit. Der Zustand vor der Aktion muss erfasst werden, damit Betreiber falsche Handlungen rückgängig machen können.

Der Beitrag beschreibt ein Framework aus sechs architektonischen Schichten, das genau diese drei Fähigkeiten liefert. Jede Schicht übernimmt eine klar abgegrenzte Aufgabe. Das gesamte System ist als geschlossener Regelkreis konzipiert. Vertrauen wird nicht einmalig zugewiesen, sondern laufend neu verdient.

Das Framework besteht aus einer Scoring-Engine, einem Stufensystem, einer Pre-Execution-Schicht, einer Enforcement-Schicht, einer Post-Execution-Schicht und einem Delivery-Gate. Die Scoring-Engine berechnet einen gewichteten Vertrauensscore. Das Stufensystem übersetzt dauerhafte Scores in Autonomiestufen. Die Pre-Execution-Schicht blockiert gefährliche Aktionen, bevor sie ausgeführt werden. Die Enforcement-Schicht setzt die Stufen über Cedar-Richtlinien auf Infrastrukturebene durch. Die Post-Execution-Schicht bewertet Ergebnisse, protokolliert Entscheidungen und speist Signale zurück in die Scoring-Engine. Das Delivery-Gate hält degradierte Agentenversionen aus der Produktion fern.

Jede Schicht ist austauschbar. Die Scoring-Modelle, Stufengrenzen, Pre-Execution-Signale und Bewertungskriterien sind Konfiguration, kein Code. Das erleichtert die Anpassung an eigene Anforderungen. Wer das Muster verstehen will, sollte sich die zentrale Designentscheidung jeder Schicht ansehen. Genau das tun die Autoren in den weiteren Abschnitten.

Scoring-Engine: Vertrauen messbar machen

Die Scoring-Engine bewertet jeden Agenten über ein rollierendes Fenster von 50 Aktionen. Daraus entsteht ein gewichteter Score zwischen 0 und 100. Fünf Dimensionen fließen ein: Korrektheit mit 25 Prozent, Sicherheit mit 20 Prozent, Konsistenz mit 20 Prozent, Compliance mit 20 Prozent und Effizienz mit 15 Prozent. Korrektheit misst, ob Aufgaben erwartungsgemäß abgeschlossen wurden. Sicherheit erfasst, ob Grenzen respektiert, gegnerische Inhalte erkannt und erlaubte Werkzeuge verwendet wurden.

Konsistenz bewertet die Verhaltensvorhersagbarkeit, also die Abweichung des Werkzeugnutzungsmusters. Compliance prüft die Qualität der Begründung vor der Handlung und das Einhalten von Guardrails. Effizienz zählt unnötige Wiederholungen und Ressourcenverschwendung. Der zusammengesetzte Score treibt Dashboards und Stufenzuweisungen. Doch Sicherheit wirkt als unabhängige Untergrenze. Ein gefährlicher Einzelwert kann nicht durch starke andere Kennzahlen weggemittelt werden.

Die Sicherheitsuntergrenze zieht sich durch das gesamte Framework. Ein Agent, der bei Korrektheit glänzt, aber regelmäßig Sicherheitsgrenzen überschreitet, bleibt unten. Vertrauen wird so nicht zu einem bloßen Rechenexempel.

Vom T1 bis T4: Das Stufensystem der Autonomie

Jeder neue Agent startet auf Stufe T1, der Bewährungsstufe, unabhängig von Testergebnissen. In T1 sind nur Lese- und Auflistungsrechte erlaubt, und es stehen zwei Werkzeuge zur Verfügung. Steigt der Score auf 41 bis 70, erreicht der Agent T2 und darf Schreiboperationen ausführen, wobei der Mensch bei hohen Risiken zustimmen muss. Ab einem Score von 71 bis 90 gilt T3 als vertrauenswürdig: Der Agent darf ausführen und ändern, Anomalien werden zur Überprüfung markiert. Die höchste Stufe T4 ab 91 erlaubt vollen Zugriff – nur noch eine nachträgliche Prüfung findet statt.

Drei Regeln steuern die Übergänge. Erstens: Eine Beförderung erfordert anhaltende Leistung. Der Score muss während des gesamten rollierenden Fensters über der Beförderungsschwelle liegen. Zweitens: Eine Herabstufung erfolgt sofort. Sobald die Sicherheit unter ihre Untergrenze fällt oder eine Injektion erkannt wird, sinkt der Agent. Drittens: Hysterese verhindert Oszillation. Für den Aufstieg in eine Stufe sind fünf Punkte über dem Mindestwert nötig. Die Herabstufung passiert dagegen schon an der Untergrenze selbst.

Der Vertrauenszustand liegt in Amazon DynamoDB, als aktueller Datensatz plus Zeitserienverlauf pro Agent. Die Durchsetzungskomponenten lesen die aktuelle Stufe bei jedem Aufruf. DynamoDB liefert diesen Lookup typischerweise im einstelligen Millisekundenbereich. Diese Geschwindigkeit ist nötig, denn Vertrauen muss in Echtzeit wirken.

Zwei Verteidigungslinien: Pre-Execution und Enforcement

Eine Bewertung nach der Ausführung kann Schaden nicht mehr rückgängig machen. Deshalb bewertet die Pre-Execution-Schicht jeden Werkzeugaufruf und kann ihn blockieren, bevor er ausgeführt wird. Sechs Signale fließen in diese Bewertung ein. Zuerst die Erkennung von gegnerischen Injektionen: Bekannte Injektionsphrasen lösen sofort eine Blockierung und eine Vertrauensstrafe aus. Dazu kommt die Erkennung sensibler Ziele durch Regex-Abgleich von Zugangsdaten, Tokens und privaten Schlüsseln in Werkzeugargumenten.

Gefährliche Werkzeuge werden über Muster erkannt, die auf destruktive Operationen hinweisen. Die Verhaltenskonsistenz vergleicht den aktuellen Werkzeugaufruf mit der historischen Verteilung der Werkzeugnutzung des Agenten. Die Konfidenzkalibrierung prüft, ob die angegebene Konfidenz zur tatsächlichen Genauigkeit passt. Übermäßig selbstsichere Fehler werden doppelt so stark bestraft. Schließlich wird die Begründungsqualität geprüft: Hat der Agent vor der Handlung eine Begründung geliefert?

Diese Checks sind schnelle Erstfilter, keine vollständige Verteidigung. Die Autoren betonen, dass die Enforcement-Schicht mit ihren Deny-by-default-Richtlinien alles abfangen muss, was die Pre-Execution-Schicht übersehen hat. Zwei Verteidigungslinien also. Die erste ist schnell und pragmatisch, die zweite ist hart und prinzipientreu.

Die Pre-Execution-Schicht ist Anwendungscode innerhalb des Agentenprozesses. Die Enforcement-Schicht arbeitet außerhalb, auf Infrastrukturebene. AgentCore Gateway, eine Fähigkeit von Amazon Bedrock AgentCore, sitzt zwischen dem Agenten und seinen Werkzeugen. Jede MCP-Werkzeuginvokation wird durch Policy in Amazon Bedrock AgentCore geleitet, das Cedar-Richtlinien mit Forbid-Wins-Semantik auswertet. Eine einzige erfüllte Forbid-Regel überstimmt beliebig viele Permit-Regeln.

Die Stufe des Agenten bildet sich direkt im Richtlinienzustand ab. Auf der Bewährungsstufe blockiert eine Forbid-Richtlinie Schreib-, Ausführungs- und Löschaktionen. Nach einer Beförderung wird die Forbid-Richtlinie entfernt und breitere Permits treten in Kraft. Bei einer Herabstufung wird die Forbid-Richtlinie wieder aktiviert. Im Enforce-Modus listet das Gateway nur die Werkzeuge auf, die die Richtlinie erlauben würde. Ein Agent ruft ein Werkzeug, das er nie gesehen hat, höchstwahrscheinlich nicht auf.

Das Auflisten ist eine Meta-Aktion. Jede Invokation wird trotzdem einzeln und mit vollem Kontext bewertet, einschließlich Eingabeparametern. Cedar verweigert standardmäßig. Die Durchsetzung hängt also nie von der Bereitschaft des Agenten ab, sich zu benehmen. Für die Sicherheit auf Modellebene ergänzt Amazon Bedrock Guardrails die Policy-Schicht und filtert schädliche Inhalte sowie sensible Informationen, unabhängig von der Stufe.

Nach der Tat: Post-Execution, Audit-Trail und Delivery Gate

Nach jedem Werkzeugaufruf bewertet das System das Ergebnis anhand von acht Signalen. Dazu gehören Konfidenzkalibrierung, Verhaltensdrift, menschliche Übersteuerungen und die Erkennung von unnötigen Wiederholungen. Jede Aktion erzeugt einen Audit-Datensatz, der die Kette Think, Plan, Act, Observe, Score abbildet. Think steht für die Gedankenkette des Agenten. Plan enthält das ausgewählte Werkzeug, die vorbereiteten Eingaben und den Pre-Execution-Score.

Act protokolliert, welche Cedar-Richtlinie gegriffen hat und wie die Gateway-Route verarbeitet wurde. Observe hält Erfolg oder Misserfolg sowie die Ausgabedaten fest. Score erfasst die Vertrauenswirkung, die Einzeldimensionen und die Stufenänderung. Genau die Plan- und Act-Aufzeichnungen machen eine Wiederherstellung möglich, weil sie den Zustand vor der Aktion festhalten. Ohne diese Information kann man eine falsche Handlung nicht gezielt rückgängig machen.

Betreiber können Fragen in natürlicher Sprache stellen. Ein Provenance-Query-Endpunkt liefert eine menschenlesbare Erklärung jeder Entscheidung. Die Audit-Einträge landen dauerhaft in DynamoDB. Diese Nachvollziehbarkeit ist mehr als Compliance-Pflicht. Sie schafft die Grundlage dafür, dass Menschen einem Agenten mehr Autonomie zugestehen können.

Zur Nachvollziehbarkeit im Betrieb kommt die Qualitätssicherung vor dem Deployment. Jede Änderung am Prompt, an der Konfiguration oder an den Werkzeugdefinitionen des Agenten löst einen AWS-CodePipeline-Lauf aus. Die Pipeline deployed den Kandidaten in einer Staging-Umgebung und führt ihn gegen Ground-Truth-Testfälle aus, unterstützt durch Amazon Bedrock AgentCore Evaluations. Die Testfälle enthalten gegnerische Szenarien wie Prompt-Injection und Datenexfiltration. Ein einziger unbefugter Werkzeugaufruf in einem dieser Fälle lässt den Lauf scheitern. Die Version, die besteht, wird zur letzten bekannten stabilen Version erklärt.

Im laufenden Betrieb injiziert das Framework synthetische Honeypot-Fälle mit bekanntem erwartetem Verhalten in einen kleinen Teil des Datenverkehrs. Die Validierung prüft die Werkzeugaufruf-Trajektorie: erwartete Werkzeuge, erwartete Reihenfolge, keine verbotenen Werkzeuge. Natürlichsprachige Ausgaben sind nicht deterministisch, aber die Trajektorie muss stimmen. Eine Abweichung signalisiert eine echte Anomalie. Die Honeypot-Ergebnisse fließen nicht in die Produktionsmetriken ein.

Sinkt die Sicherheitsuntergrenze, wird der Agent herabgestuft und die letzte bekannte stabile Version erneut bereitgestellt. So kehren bekanntermaßen guter Code und ein engerer Berechtigungssatz gemeinsam zurück. Gleichzeitig werden die Betreiber alarmiert. Deren Urteil fließt direkt in das System ein: Die Quote der abgelehnten Aktionen deckelt die effektive Sicherheitsmetrik. Wenn Betreiber 30 Prozent der Aktionen ablehnen, ist die Sicherheit bei 70 Prozent gedeckelt.

Für den Notfall gibt es einen Stopp-Knopf. Ein einziger Cedar-Deny-All-Richtlinienbefehl wird verbreitet und aktiviert sich in der Regel innerhalb von Sekunden. Das Gateway verweigert dann alle Werkzeugaufrufe ohne neue Bereitstellung. In Multi-Agenten-Systemen gilt: Die effektive Stufe einer delegierten Aktion ist das Minimum über die gesamte Delegationskette. Damit ist der Privilegien-Eskalationspfad über Delegation geschlossen.

Was das konkret bedeutet

Abgestufte Autonomie ist kein theoretisches Modell, sondern ein umsetzbares Architekturmuster. Es umgeht die binäre Wahl zwischen Vollzugriff und Read-only, indem es Vertrauen als kontinuierliche Größe behandelt. Agenten bekommen genau so viel Freiheit, wie ihr nachgewiesenes Verhalten rechtfertigt. Und sie verlieren diese Freiheit wieder, wenn sie sie missbrauchen.

Für Teams, die das einführen wollen, geben die Autoren eine konkrete Startempfehlung: Dimensionen, Gewichte und Stufengrenzen aus den Tabellen als Ausgangsvorlage für einen einzigen Agenten nehmen. Diesen Agenten auf T1 starten. Dann den Delivery-Gate-Prozess mit Amazon Bedrock AgentCore Evaluations aufbauen und die Stufenrichtlinien mit Policy in Amazon Bedrock AgentCore umsetzen. Das Muster lässt sich iterativ anpassen.

Fazit: Vertrauen in KI-Agenten ist kein einmalig vergebenes Gut. Es ist ein Betriebszustand, den man messen, überwachen und durchsetzen muss. Wer das akzeptiert, kann Agenten sicherer betreiben und gleichzeitig mehr von ihrem Potenzial nutzen. Wer es ignoriert, wird sich zwischen Risiko und Nutzlosigkeit entscheiden müssen.

Quelle: aws.amazon.com

KI-Assistenten produzieren Code, der plausibel aussieht – aber ohne Begrenzung driften sie ab. Das ist die Beobachtung, die Birgitta Boeckeler in ihrem Artikel auf martinfowler.com beschreibt, und sie dürfte jedem Team bekannt vorkommen, das KI-Coding-Assistenten ernsthaft einsetzt. Der Code kompiliert, die Tests laufen grün, und trotzdem verschlechtert sich die interne Konsistenz der Codebasis langsam aber sicher. Naming-Konventionen werden aufgeweicht, Architekturregeln umgangen, und irgendwann ist das Projekt ein Flickenteppich, den kein Mensch mehr überblickt. Das Tückische: Der Verfall ist leise. Er passiert nicht auf einen Schlag, sondern in vielen kleinen, plausibel wirkenden Abweichungen, die keine bestehende Prüfung bemerkt.

Ein Harness für KI-Code: Die Logik der Tests übertragen

Die Lösung liegt in einer Übertragung einer alten Idee. Tests machen Code nicht korrekt, indem sie ihn erstellen; sie erkennen, wenn er aufhört, korrekt zu sein. Ein Test-Harness ist kein Zwang, der den Entwickler einschränkt, sondern ein Mechanismus, der fortlaufend prüft, ob das Geschriebene den Standard erfüllt. Diese Logik lässt sich auf die KI-gestützte Entwicklung übertragen – nur mit einem breiteren Prüfumfang. Während Tests funktionale Korrektheit abfragen, braucht es für KI-generierten Code eine Harness, die auch Architekturentscheidungen, Namenskonventionen, Sicherheitsregeln und strukturelle Vereinbarungen überwacht. Genau das nennt Boeckeler Harness Engineering. Von ihr stammen Begriff und Grundgedanke. Alles Weitere in diesem Text — die drei Säulen, die Reifegrade, die Schleifen — ist die Ausgestaltung des Plugins ai-literacy-superpowers, dessen Dokumentation die Quelle dieses Beitrags ist.

Der Unterschied ist entscheidend. Ein funktionaler Test sagt dir, ob das Programm das tut, was es soll. Er sagt dir nicht, ob die neue KI-generierte Funktion die Abstraktionsschicht für Datenbankzugriffe umgangen hat oder eine veraltete Logging-Bibliothek benutzt, die im Projekt längst abgeschafft wurde. Solche Verstöße bleiben unter dem Radar funktionaler Tests, weil das Programm weiterhin korrekt arbeitet – bis später jemand an der falschen Stelle refactort. Ein Harness für KI-Code schließt genau diese Lücke. Er ist das Sicherheitsnetz, das die unsichtbaren Abweichungen sichtbar macht.

Die drei Säulen: Kontext, Architektur, Entropie

Der Kern von Harness Engineering besteht aus drei Komponenten, die zusammenwirken. Die erste ist Context Engineering: Die KI kann nur mit dem arbeiten, was sie weiß. Kennt sie die projekteigene Logging-Bibliothek nicht, erfindet sie eine eigene. Weiß sie nicht, dass globaler Zustand strikt verboten ist, benutzt sie ihn, sobald es bequem erscheint. Deshalb muss der Harness dem KI-Assistenten eine Wissensbasis liefern – in der Praxis ein Dokument namens HARNESS.md, das den Stack, die Architekturentscheidungen, Namenskonventionen und deren Begründung festhält. Das ist kein README für Menschen, sondern ein Kontextdokument für die Maschine, und es muss präzise und aktuell sein.

Die zweite Säule sind Architektur-Constraints. Dass die KI die Regeln kennt, heißt nicht, dass sie sie befolgt. Ein KI-Assistent ist ein probabilistisches System, das Plausibilität optimiert, kein regelbefolgender Roboter. Context Engineering reduziert Verstöße, eliminiert sie aber nicht. Deshalb braucht es Verifikationsslots – definierte Momente im Workflow, in denen eine Prüfung läuft und entweder grün gibt oder den Fortschritt blockiert. Die entscheidende Frage ist dabei, ob die Prüfung mit einem deterministischen Tool wie einem Linter oder Skript erfolgt oder mit einem agentenbasierten Review durch ein Sprachmodell. Deterministische Checks sind schnell und zuverlässig, wenn sich die Regel präzise ausdrücken lässt. Agenten sind teurer und unzuverlässiger, können aber auch semantische Verstöße erkennen, die kein Skript abbilden kann.

Die dritte Säule ist Garbage Collection, das Aufräumen. Eine Codebasis ist ein lebendes System, in dem mit der Zeit Entropie entsteht: toter Code, veraltete Abhängigkeiten, TODO-Kommentare, die niemand mehr anfasst, Konventionen, die still beerdigt wurden. Anders als die ersten beiden Komponenten arbeitet diese nicht beim Schreiben oder Reviewen, sondern nach Zeitplan. Regelmäßig – täglich, wöchentlich – prüfen Agenten oder Skripte, ob die Codebasis bestimmte Sauberkeitskriterien noch erfüllt. Der Output ist keine PR-Blockade, sondern ein Bericht, der auf akkumulierende Probleme aufmerksam macht, bevor sie kritisch werden.

Der lebendige Harness: Selbstreferenz als Feedback-Schleife

Der wichtigste Unterschied zu statischen Regelwerken ist, dass ein Harness selbst lebendig bleibt. Ein einmal geschriebenes Harness-Dokument spiegelt den Wissensstand des Teams zu einem bestimmten Zeitpunkt. Die Codebasis entwickelt sich weiter, neue Muster entstehen, alte Regeln verlieren ihre Bedeutung, und neue KI-Fehler tauchen auf, die ursprünglich niemand vorhergesehen hat. HARNESS.md ist deshalb selbstreferentiell aufgebaut: Es beschreibt nicht nur die geltenden Constraints, sondern auch deren Status – ob sie ungeprüft, per Agent oder deterministisch durchgesetzt werden. Dieses Dokument deklariert, was wahr sein soll; Agenten, Hooks und CI-Checks verifizieren, ob es wahr ist. Der Harness-Audit, ein geplanter Agent, liest die Ergebnisse und aktualisiert die Statuseinträge – so entsteht eine Feedback-Schleife.

Die Selbstreferenzialität ist das, was einen lebendigen Harness von einem toten Dokument unterscheidet. Weil der Harness selbst Gegenstand der Durchsetzung ist – der Audit prüft, ob HARNESS.md den Realzustand korrekt abbildet – wird Vernachlässigung sichtbar statt unsichtbar. Der Alltagszugang zu dieser Selbstkontrolle ist der Befehl /harness-sync, der die Erkennungslogik des Audits ausführt und eine einheitliche Abweichungstabelle präsentiert. Du siehst dann auf einen Blick, wo deklarierte Regeln und tatsächliche Verifikation auseinanderlaufen, ohne ein separates Diagnosetool bemühen zu müssen. Das ist praktische Transparenz.

Progressive Härtung: Vom Bekenntnis zur harten Regel

Nicht jede Constraint ist von Anfang an bereit für eine deterministische Durchsetzung. Progressive Hardening ist die Karriereleiter, auf der Regeln sich entwickeln. Am Anfang steht der Zustand Unverified: Du hast eine Regel in HARNESS.md notiert, weil du sie für wichtig hältst, aber es gibt noch keinen Mechanismus, sie zu prüfen. Das ist kein Scheitern, sondern ehrliche Buchführung – ein ungeprüfter Constraint ist ein Versprechen, eine Prüfung zu bauen, nicht die Behauptung, dass bereits eine existiert.

Der nächste Schritt ist Agent. Jetzt gibt es einen Agent-Prompt, der die Regel beim PR-Review oder in einer regelmäßigen Inspektion prüft. Der Agent ist ein Sprachmodell, das ein Urteil fällt – er erwischt die meisten Verstöße, ist aber nicht perfekt und braucht menschliche Kontrolle. Irgendwann folgt der Zustand Deterministic: Du hast die Regel präzise genug formuliert, um sie als Skript, Linter-Regel oder Strukturcheck zu kodieren. Sie läuft in CI, gibt entweder grün oder blockiert den Merge – ohne Urteilsvermögen, aber auch ohne Verwechslungsgefahr. Die Bewegungsrichtung ist immer von weich nach hart. Wenn ein Agent immer wieder dieselbe Verletzungsklasse findet, ist das ein Signal: Das Muster ist jetzt verstanden genug für Automatisierung. Schreib das Skript, pensioniere den Agenten für diese konkrete Regel, und aktualisiere den Status in HARNESS.md.

Progressive Härtung verhindert zwei Fehlermodi. Der erste wäre der Versuch, von Anfang an alles deterministisch durchzusetzen – das scheitert an neuartigen oder semantisch komplexen Regeln. Der zweite wäre, Agenten als Dauerzustand zu akzeptieren – das ist teuer und unzuverlässig. Die Leiter gibt dir einen Pfad dazwischen. In der Praxis heißt das: Wer klug härtet, gewinnt mit der Zeit ein Regelwerk, das immer weniger Nachsehen braucht.

Drei Schleifen: Wie die Umsetzung konkret aussieht

Damit das Ganze nicht graue Theorie bleibt, setzt ai-literacy-superpowers die Verifikationsslots in drei Durchsetzungsschleifen um, die sich in Frequenz und Härte unterscheiden. Die innere Schleife arbeitet beraterisch zur Bearbeitungszeit. Wenn du eine Datei speicherst oder eine Coding-Session abschließt, laufen leichte Checks, die potenzielle Probleme als Vorschlag anzeigen – nicht als Blockade. Sie ist auf geringen Reibungsverlust optimiert und soll deinen Fluss nicht unterbrechen, sondern Probleme früh sichtbar machen.

Die mittlere Schleife ist streng und läuft zur PR-Zeit. Beim Öffnen eines Pull Requests kommt eine volle Suite aus Agenten- und Deterministischen Checks zum Einsatz. Diese Schleife darf einen Merge blockieren. Sie ist der Hauptdurchsetzungspunkt für Architektur-Constraints. Fehler hier müssen behoben werden, bevor der Code landet. Die äußere Schleife schließlich ist investigativ und arbeitet nach Zeitplan: Garbage-Collection-Regeln, Fitness-Funktionen und Harness-Audits laufen täglich oder wöchentlich. Sie erzeugt Berichte statt Blockaden, und ihre Erkenntnisse fließen als neue Constraints oder Updates zurück in den Harness.

Die drei Schleifen korrespondieren mit den drei Säulen: Die innere dient dem Context Engineering – sie hält die KI im Moment informiert. Die mittlere dient den Architektur-Constraints – sie erzwingt Standards beim Integration-Zeitpunkt. Die äußere dient der Garbage Collection – sie erkennt langsame Entropie zwischen Integrationsereignissen. Wichtig ist: Agenten im Plugin arbeiten mit begrenztem Vertrauen. Kein Agent hat einseitig die Macht, Produktionscode zu ändern oder Merges zu beschließen. Agenten prüfen, schlagen vor, berichten und markieren. Menschen entscheiden. Das ist eine bewusste Designentscheidung: Der Harness verstärkt menschliches Urteilsvermögen, er ersetzt es nicht.

Dazu kommt eine selbst-verbessernde Dimension. Nach jeder Coding-Session protokolliert der Befehl /reflect, was gut lief, was scheiterte, welche Konventionen verletzt wurden und welche neuen Muster auftauchten. Diese Reflexionen sammeln sich in einem Log, das die Harness-Agenten bei ihren Entscheidungen lesen. So beeinflussen vergangene Fehler die aktuelle Review. Auch die Regressionserkennung wirkt in dieselbe Richtung: Der Harness-Audit prüft nicht nur, ob aktuelle Constraints erfüllt sind, sondern ob die Abweichungsmuster sich wiederholen. Das Harness lernt also aus seiner eigenen Betriebsgeschichte – ein evolutionärer Vorteil, den statische Regelwerke nie haben.

Was das für deine Arbeit bedeutet

Harness Engineering ist keine Zauberei, sondern eine konsequente Anwendung alter Ingenieursprinzipien auf eine neue Generation von Werkzeugen. Du musst keine KI haben, die perfekt ist – du brauchst einen Rahmen, der ihre Schwächen abfängt. Der Preis ist Arbeit: Ein Kontextdokument führen, Constraints formulieren, Checks pflegen, Audits lesen. Der Gewinn ist ein weitgehend ruhigeres Gewissen beim Einsatz von KI-Coding-Assistenten. Der Code bleibt kohärent, nicht weil die KI immer richtig liegt, sondern weil dein Harness die Abweichungen sichtbar macht und in geordnete Bahnen lenkt.

Die konkrete Bedeutung für deinen Alltag: Wenn du mit KI-Assistenten arbeitest, solltest du nicht nur auf Tests vertrauen. Du brauchst eine zweite Ebene aus Kontext, Constraints und regelmäßigem Aufräumen. Starte mit einem HARNESS.md, dokumentiere die wichtigsten Architekturregeln, führe einen einfachen Agent-Check bei PRs ein, und härtete nach und nach die Regeln, die sich wiederholen. So nutzt du die Produktivität der KI, ohne ihre Drift zu erben. Das ist die eigentliche Superpower – nicht die KI selbst, sondern die Disziplin, sie in einen stabilen Rahmen zu zwingen.

Quelle: habitat-thinking.github.io