Code Guardian im Alltag: Erfahrungen aus dem Betrieb von digital zentral

Offenlegung: Code Guardian ist ein Angebot der Provimedia GmbH. Deren Geschäftsführer Alexander Weipprecht ist Bruder und Geschäftspartner des Herausgebers von digital zentral. Der Herausgeber setzt Code Guardian selbst für diese Seite ein. Dieser Beitrag enthält Partnerlinks: Kommt darüber ein Kauf zustande, erhält digital zentral eine Provision; der Preis für Sie ändert sich nicht.

digital zentral ist ein kleines Online-Magazin, das technisch von einem KI-Assistenten gepflegt wird: Claude Code schreibt Artikeldateien, baut die Seite, pflegt die Werkzeuge im Repository und deployt per Push. Seit Oktober 2026 läuft dabei Code Guardian mit. Dieser Beitrag beschreibt, was das Paket in den ersten Wochen angehalten, gefunden und gekostet hat. Er ist kein Test unter Laborbedingungen, sondern ein Bericht aus dem Betrieb, mit den Protokollen, die das Paket selbst schreibt.

Die Ausgangslage

Das Magazin läuft auf einem statischen Seitengenerator mit Python-Werkzeugen für Aufbereitung, Bildgrafiken und Linkprüfung. Jeder Push auf den Hauptzweig löst den Build und das Deployment aus. Das heißt: Ein Fehler, der den Build überlebt, ist live. Vor Code Guardian lag die Prüfung bei einem Testlauf und beim Menschen, der den Diff überflog. Beides blieb, aber der Assistent bekam Regeln, die er nicht selbst auslegen darf.

Was der Lösch-Riegel angehalten hat

Zuerst fällt der Riegel gegen zerstörende Befehle auf. Er prüft jeden Shell-Befehl, bevor er läuft, und weist Schreibweisen ab, die Arbeit vernichten, die nur im Arbeitsbaum steht; was er noch nicht liest, steht in Vier harte Riegel. Im Audit-Protokoll dieser Seite steht dazu die Lehre vom 8. Oktober: Damals sperrte der Riegel das Schreiben und Lesen derselben Datei in einer Befehlskette, das Verwerfen ungesicherter Änderungen per Git-Checkout ohne begründeten Kommentar und jeden Text, der „rm -r /“ enthielt, auch in einem Argument. Darunter steht die Konsequenz: Kommandos trennen, Formulierungen ändern. In der Sitzung, in der diese Serie entstand, hat derselbe Riegel dreimal eine Befehlskette verworfen, die eine Artikeldatei schrieb und im selben Kommando wieder las; die Absage nannte jeweils das Glied der Kette, in dem der Grund steckte. Beides steht im Eintrag vom 4. November.

Ein zweiter Fall aus derselben Sitzung, ebenfalls im Eintrag vom 4. November: Der Assistent wollte einen Wegwerf-Arbeitsbaum entfernen, der nur für eine Probe angelegt worden war. Der Pfad stand in einer Shell-Variablen. Der Riegel löst Variablen bewusst nicht auf, weil er dann raten müsste, und hat den Befehl abgewiesen. Erst mit ausgeschriebenem Pfad und einem angehängten Grund lief er. Das ist genau die Sorte Reibung, die man will: Der Grund steht danach im Terminal-Verlauf.

Was der Kalt-Review gefunden hat

Besonders nützlich war für uns der Prüfer, der einen Plan liest, ohne die Begründung des Autors zu kennen. Für diese Artikelserie hatte der Assistent am Vorabend einen Plan geschrieben, den er für fertig hielt. Der Kalt-Review am nächsten Morgen lieferte neun Befunde, acht davon mit ausgeführtem Beleg. Der erste, laut Prüfer der schwerste: Der lokale Stand lag 24 Commits hinter dem Server, und fünf der zehn Artikelnummern, die der Plan vergeben wollte, waren dort schon belegt. Ein Push wäre abgewiesen worden, der Build nach dem Nachziehen wegen doppelter Nummern abgebrochen. Weitere Befunde: ein Suchmuster, das als Python-Zeichenkette gar nicht kompiliert hätte, eine Gegenprobe, die nichts bewies, weil der Testwert zu kurz war, und eine falsche Vorlage für den Offenlegungstext.

Keiner dieser Fehler wäre dem Autor beim erneuten Lesen aufgefallen, weil der Autor das Modell war, das sie gemacht hat. Die Prüfung von außen ist der Unterschied. Sechs Kalt-Review-Läufe vom 15. und 16. Oktober liegen als Ordner im Beweis-Verzeichnis des Projekts. Im Audit-Protokoll vom 15. Oktober steht außerdem, dass ein Diff-Review bei Sitzungsende ohne Ergebnis gestoppt wurde und auf den Commit neu anzusetzen war: Ein abgebrochener Review zählt nicht als gelaufen, und genau das steht dann auch da.

Plan-Freigabe und Entscheidungsfragen

Für diese Serie hat der Assistent vor dem ersten Buchstaben vier Entscheidungen einzeln vorgelegt: Rubrik, Erscheinungstermin, Perspektive und Umgang mit Preisen; die fünfte Vorgabe, keine anderen Produkte zu nennen, kam vom Herausgeber selbst. Jede Frage kam mit einer Empfehlung zuerst. Die Antworten stehen als Entscheidungsprotokoll im Plan, und die Freigabe des Plans war ein einziger Klick. Das Ergebnis: Als am nächsten Tag weitergearbeitet wurde, mussten die Fragen nicht neu gestellt werden, weil sie aufgeschrieben waren.

Die Einstufung davor ist mechanisch. Eine Änderung in genau einer bestehenden Datei mit höchstens 20 geänderten Zeilen, ohne Berührung der Sperrliste (Datenbank, Anmeldung, Zahlung, Deploy, Abhängigkeiten, die Hooks selbst, Geheimnisse, Produktionsdaten) und ohne offene Entscheidung läuft ohne Plan; alles darüber nicht. Der Assistent misst das mit Git-Befehlen, statt es zu schätzen. In der Praxis heißt das: Ein Tippfehler im Impressum kostet keine Freigabe, ein neuer Artikel mit Werkzeugänderung schon.

Die Verify-Pflicht

Das Projekt hat einen Prüflauf, der Tests, Linter, Aufbereitung, Build und Linkprüfung nacheinander fährt. Der Assistent fährt diesen Lauf vor dem Push; eine technische Sperre dafür gibt es nicht, und in der Sitzung dieser Serie lief er bei einem Folge-Commit zu einem anderen Artikel erst nach dem Push. Im Audit-Protokoll tragen beide Einträge aus dem Oktober als Stand die Zeile „verify grün“ mit Testzahl und Linkprüfung; einen Eintrag ohne diese Zeile gibt es nicht. Bei dieser Serie lief der Prüflauf mehrfach, ab dem zweiten Lauf gesiegelt im Aufgabenordner: einmal rot, weil parallel gestartete Testläufe den Build störten, danach grün. Das ist keine Sperre des Pakets, sondern eine Gewohnheit, die das Paket in sein Protokoll geschrieben hat und bei jedem Start wieder zeigt.

Wo es Reibung gibt

Ein ehrlicher Bericht nennt die Reibung. Erstens: Der Plan-Modus fühlt sich bei einer Aufgabe, die man im Kopf längst fertig hat, wie Bürokratie an. Zweitens: Die Sperren sind so gebaut, dass sie im Zweifel anhalten. Der Anbieter nennt in den Versionshinweisen zu 17.13 einen in 17.11 entfernten Fehlalarm: ein lesender Befehl, der nur den Namen eines Deploy-Skripts enthielt, wurde angehalten. Drittens: Das Paket schreibt viel. Audit-Protokoll, Aufgabenordner, Ledger, Aufgabenliste. Wer das nicht liest, hat nur Dateien. Wer es liest, hat ein Gedächtnis über Sitzungen hinweg, das sonst mit jedem neuen Fenster verloren geht.

Viertens, und diese Grenze gehört in jeden Bericht: Code Guardian verhindert keine falsche Entscheidung des Menschen. Wenn der Herausgeber einen Plan freigibt, der eine schlechte Idee ist, baut der Assistent die schlechte Idee sauber und belegt. Die Prüfschicht sorgt dafür, dass man weiß, was man tut. Sie entscheidet nicht, ob man es tun sollte.

Grenzen: Was Code Guardian nicht kann

Was das Paket laut Anbieter nicht leistet, steht auf der Produktseite: Für Sprachen ohne eingerichtete Analysewerkzeuge gibt es kein Statik-Gate, es ist kein Support-Vertrag, und die Plan-Freigabe unter Claude Code ist eine Anweisung, keine technische Sperre. Aus unserer Erfahrung kommt ein Punkt dazu: Die Qualität der Prüfung hängt daran, ob das Projekt überhaupt Tests hat. In einem Projekt ohne Testlauf kann die Belegpflicht nur verlangen, dass der Assistent etwas ausführt, nicht, dass das Ausgeführte etwas beweist.

Häufig gestellte Fragen

Lohnt sich Code Guardian für ein Ein-Personen-Projekt?

Wenn ein Fehler live geht, bevor jemand ihn sieht: ja. Genau das ist bei einer Seite mit automatischem Deployment der Fall. Bei einem Projekt, das nur lokal läuft und das niemand außer Ihnen nutzt, ist der Nutzen geringer.

Wie viel Zeit kostet die Prüfschicht?

Bei dieser Serie: eine Grill-Phase mit vier Fragen, eine Plan-Freigabe, ein Kalt-Review des Plans von rund 13 Minuten, Kalt-Reviews des Diffs in mehreren Runden und der Prüflauf von gut vier Minuten je Durchgang. Dafür entfielen ein abgewiesener Push und ein abgebrochener Build.

Ersetzt es den menschlichen Blick auf den Diff?

Nein. Es sorgt dafür, dass der Mensch einen Plan statt eines fertigen Diffs sieht, und dass der Diff mit Beleg kommt. Lesen muss er trotzdem.

Weiterlesen in dieser Serie

• Code Guardian: Was das Prüfpaket für Claude Code und Codex wirklich tut
• Vier harte Riegel: Löschen, Secrets, Deploy und Migration
• Nachweisbar geprüft: Audit, Kalt-Review und Belegpflicht

Auch interessant

• Wie viel KI tut uns gut? Alexander Weipprecht im Podcast

Code Guardian ansehen

Alle Angaben zu Umfang und Lizenz stehen beim Anbieter: Code Guardian bei Provimedia (öffnet in neuem Fenster)Anzeige. Mit dem Code PARTNER-4B79 erhalten Sie 10 % Rabatt auf den Einmalkauf der Firmenlizenz (nicht auf das Update-Abo; Stand 4. November 2026).