Niemand ruft an, weil seine Website veraltet ist. Angerufen wird, weil ein Relaunch her soll. Und wenn ich dann hineinsehe, ist selten etwas kaputt – es fehlen einfach die zwei Jahre, in denen niemand sie angefasst hat.
Wie eine Website altert
Eine Website ist am Tag des Launches auf dem Stand des Unternehmens. Ab dem Tag danach bewegt sich nur noch das Unternehmen. Der Abstand wächst leise, in Schritten, die einzeln nie groß genug sind, um jemanden zu beschäftigen.
Wenn ich einen bestehenden Auftritt durchsehe, finde ich fast immer dieselben drei Arten von Rückstand. Inhaltlich: eine Teamseite mit zwei Personen, die längst weg sind, Preise aus der vorletzten Kalkulation, ein Referenzprojekt, das der Kunde gar nicht mehr nennen darf. Technisch: Abhängigkeiten mit offenen Sicherheitsmeldungen, Links auf Seiten, die es nicht mehr gibt, ein Kontaktformular, das seit dem Providerwechsel ins Leere schickt. Gestalterisch: ein Design-System, das auseinanderläuft, weil jede neue Landingpage ihre eigene Abstandslogik mitgebracht hat.
Keiner dieser Punkte ist ein Fehler im Sinne von „funktioniert nicht“. Genau deshalb bleiben sie liegen. Sie erzeugen keinen Ticket-Druck, sondern nur ein diffuses Gefühl, dass die Seite nicht mehr ganz stimmt – bis es für den Relaunch reicht, der dann alles neu macht und den Zyklus von vorn beginnt.
Der naheliegende Gedanke: Das kann ein Agent nachts erledigen. Er liest den Code, findet die toten Links, hebt die Abhängigkeiten an, schreibt die fehlenden alt-Texte. Technisch ist das heute unspektakulär. Die Frage, an der es in Projekten tatsächlich hängt, ist eine andere – nämlich welche dieser Änderungen jemand vorher sehen will.
Prüfbar oder Urteilssache
Die brauchbare Trennlinie verläuft nicht zwischen „einfach“ und „schwierig“, sondern zwischen prüfbar und Urteilssache. Eine Aufgabe ist für einen Agenten geeignet, wenn es eine Regel gibt, die das Ergebnis ohne Rückfrage entscheidet.
Ein Link liefert 404 oder er liefert es nicht. Ein Bild hat ein alt-Attribut oder keines. Eine Abhängigkeit hat eine gemeldete Schwachstelle oder nicht. In all diesen Fällen kann die Maschine ihr eigenes Ergebnis überprüfen: Sie ändert etwas, führt denselben Test noch einmal aus und weiß, ob sie fertig ist.
Sobald die Frage „Ist das jetzt gut?“ lautet, gibt es diesen Test nicht mehr. Ob ein Text den Ton der Marke trifft, ob eine Bildauswahl zur Zielgruppe passt, ob eine Startseite den richtigen Schwerpunkt setzt – dafür lässt sich kein Kriterium schreiben, das der Agent gegen sich selbst laufen lassen könnte. Er kann prüfen, ob ein Text den Vorgaben des Style Guides entspricht. Ob der Style Guide für diesen Kunden noch der richtige ist, kann er nicht prüfen.
- Tote interne und externe Links, geprüft gegen den tatsächlichen Statuscode.
- Abhängigkeiten mit gemeldeter Schwachstelle, samt Changelog-Zusammenfassung im Vorschlag.
- Bilder ohne alt-Attribut, fehlende Sprachauszeichnung, doppelte IDs im Markup.
- Seiten ohne Meta-Description oder mit einem Titel, den es schon zweimal gibt.
- Abweichungen vom Design-System: fest eingetragene Farben und Abstände statt der Variablen.
- Bilder ohne moderne Formate oder ohne gesetzte Abmessungen im Markup.
Wichtig ist, was auf dieser Liste nicht steht: „Barrierefreiheit herstellen“. Automatische Werkzeuge finden einen Teil der Probleme, nicht alle. Ein unabhängiges Audit der britischen Verwaltung verglich 2018 gängige Prüfwerkzeuge an einer Seite mit 142 bewusst eingebauten Barrieren; das beste Werkzeug erkannte 40 Prozent davon. Der Hersteller von axe kam 2021 in einer eigenen Auswertung auf rund 57 Prozent – allerdings gemessen an der Menge der auftretenden Fehler, nicht an der Zahl der Erfolgskriterien, was die Quote systematisch anhebt, weil sich einige leicht erkennbare Fehlertypen besonders häufig wiederholen.
Vier Stufen der Autonomie
„Darf der Agent das?“ ist als Ja-Nein-Frage nicht zu beantworten. Sie wird brauchbar, sobald man sie in Stufen zerlegt. Ich arbeite mit vieren, und jede Aufgabe bekommt genau eine davon zugewiesen.
Stufe 0 – melden. Der Agent schreibt einen Bericht, ändert nichts. Sinnvoll als Einstieg für jede neue Aufgabe, weil man an ein paar Durchläufen sieht, ob seine Funde überhaupt stimmen.
Stufe 1 – vorschlagen. Der Agent öffnet einen Pull Request und wartet. Die Änderung ist vollständig, sie ist im Diff sichtbar, und ein Mensch entscheidet mit einem Klick.
Stufe 2 – selbst zusammenführen. Der Agent darf mergen, wenn die Pipeline grün ist und die Änderung in einem klar umgrenzten Bereich liegt. Der Bericht kommt trotzdem, nur nachher statt vorher.
Stufe 3 – direkt ausliefern. Ohne Umweg live. Das ist die Ausnahme, und sie ist nur da vertretbar, wo eine falsche Änderung sofort sichtbar wäre und in Sekunden zurückgenommen werden kann.
Diese Zuordnung gehört nicht in den Prompt des Agenten, sondern in eine Datei im Repository, die im Review-Prozess mitläuft wie jede andere. Bei einem Laravel-Projekt liegt sie am naheliegendsten dort, wo auch die übrige Konfiguration steht:
<?php
/**
* Autonomiegrade der Pflege-Agenten.
*
* 0 = nur melden, 1 = Pull Request öffnen, 2 = bei grüner Pipeline selbst
* mergen, 3 = direkt ausliefern. Eine Aufgabe steigt erst dann eine Stufe
* auf, wenn sie über mehrere Wochen keinen zurückgewiesenen Vorschlag
* produziert hat – der Weg zurück ist eine Zeile in dieser Datei.
*/
return [
'aufgaben' => [
'tote-links' => ['stufe' => 2, 'pfade' => ['content/', 'resources/views/']],
'abhaengigkeiten' => ['stufe' => 1, 'pfade' => ['composer.json', 'package.json']],
'alt-texte' => ['stufe' => 1, 'pfade' => ['resources/views/']],
'design-abweichung' => ['stufe' => 0, 'pfade' => ['resources/scss/']],
'texte-umschreiben' => ['stufe' => 0, 'pfade' => []],
],
// Diese Pfade bleiben in jeder Stufe unangetastet: die Regeln selbst,
// die Auslieferung und alles, was Geld oder Rechtsverbindlichkeit berührt.
'gesperrt' => [
'config/pflege.php',
'config/legal.php',
'.github/workflows/',
'public/.htaccess',
],
];Die zweite Liste ist die wichtigere. Ein Agent, der seine eigenen Befugnisse erweitern oder die Auslieferung umbauen kann, hat effektiv Stufe 3 für alles – unabhängig davon, was oben in der Datei steht. Dasselbe gilt für redaktionelle Einzelquellen wie Preise, Impressum oder Datenschutzerklärung: Dort ist eine falsche Änderung keine Panne, sondern ein Rechtsproblem.
Die Grenze hängt an der Person
Die Stufen sehen nach einer Projekteigenschaft aus. Sie sind aber eine Personeneigenschaft, und das ist der Punkt, an dem Standardvorgaben scheitern.
Ein Beispiel aus diesem Projekt. Das Markenrot hier ist #e6195d. Gegen weißen
Hintergrund kommt es auf ein Kontrastverhältnis von 4,5 zu 1 – und liegt damit exakt auf
der Schwelle, die die WCAG für normalen Text fordern. Jede Prüfsoftware meldet hier
„bestanden“, aber eben auch: keinerlei Reserve. Ein Agent, der die Farbe minimal
abdunkelt, hätte technisch recht.
Für mich als Entwickler ist das eine Variable in _variables.scss, eine Zeile,
fünf Minuten. Für jemanden, der die Marke verantwortet, ist es der Primärton, der auf
Visitenkarten, Rechnungen und im Fahrzeugaufkleber steht. Dieselbe Änderung ist einmal
eine Wartungsaufgabe und einmal eine Entscheidung, die außerhalb der Website getroffen
werden muss.
Daraus folgt: Die Stufe gehört nicht allein an die Aufgabe, sondern an das Paar aus Aufgabe und zuständiger Person. Es gibt keine Voreinstellung, die für alle passt, weil jeder an einer anderen Stelle das Gefühl hat, dass gerade sein Beitrag ersetzt wird. Praktisch heißt das: Die Stufen nicht selbst festlegen, sondern beim Kunden einmal durchgehen und die Antworten in die Datei schreiben.
Umkehrbarkeit schlägt Vertrauen
In der Diskussion um autonome Agenten geht es meist um Vertrauen. Vertrauen ist aber keine Eigenschaft, die man einbauen kann. Was sich einbauen lässt, ist Umkehrbarkeit – und die macht die Vertrauensfrage weitgehend überflüssig.
Konkret: Jeder Agentenlauf erzeugt einen eigenen Branch mit einem einzigen Thema. Kein Lauf fasst zwei Aufgaben in einem Commit zusammen, weil sich sonst der Link-Fix nicht ohne das Dependency-Update zurücknehmen lässt. Jede Änderung trägt im Commit, welcher Lauf sie erzeugt hat und welche Prüfung sie ausgelöst hat.
name: Nächtliche Pflege
on:
schedule:
- cron: '17 2 * * *' # versetzt, damit der Lauf nicht mit dem Backup kollidiert
workflow_dispatch:
jobs:
pflege:
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write # bewusst kein 'actions: write' – der Agent
# soll seine eigenen Workflows nicht ändern können
steps:
- uses: actions/checkout@v4
- name: Prüfungen sammeln
run: php artisan pflege:pruefen --json > bericht.json
- name: Änderungen erzeugen
run: php artisan pflege:anwenden --bericht=bericht.json --max-stufe=2
- name: Vorschlag öffnen
uses: peter-evans/create-pull-request@v6
with:
branch: pflege/${{ github.run_id }}
title: 'Nächtliche Pflege – Lauf ${{ github.run_number }}'
body-path: bericht.md
labels: pflege, automatischDer Bericht ist dabei nicht Beiwerk, sondern das eigentliche Produkt der ersten Wochen. Er beantwortet drei Fragen: Was wurde geprüft, was wurde gefunden, was wurde daraus gemacht. Wer nach zwanzig solcher Berichte eine Aufgabe eine Stufe hochsetzt, tut das auf einer Grundlage. Wer sie hochsetzt, weil bisher nichts passiert ist, tut es aus Gewöhnung – das ist etwas anderes.
Und der Weg nach unten muss genauso billig sein wie der nach oben. Wenn eine Aufgabe zweimal danebengreift, wird sie in der Konfiguration eine Stufe zurückgesetzt, nicht abgeschaltet. Eine Automatisierung, die man nur ganz oder gar nicht haben kann, wird beim ersten Zwischenfall komplett abgeschaltet und kommt nie wieder.
Fazit
Der Nutzen von Agenten in der Website-Pflege liegt nicht darin, Arbeit zu übernehmen, die jemand gern macht. Er liegt in der Arbeit, die niemand macht: der laufende Abgleich zwischen dem, was die Website behauptet, und dem, was inzwischen gilt.
Dafür braucht es keine Website, die sich selbst neu erfindet. Es reicht, sauber zu trennen zwischen dem, was eine Regel entscheiden kann, und dem, was jemand entscheiden muss – die Zuordnung in eine versionierte Datei zu schreiben, sie beim Kunden pro Person zu klären und jede einzelne Änderung so klein zu halten, dass ihre Rücknahme keine Diskussion wert ist.
Das eigentliche Risiko ist ohnehin nicht die Seite, die sich zu viel verändert. Es ist die, die zwei Jahre stillsteht und dann komplett ersetzt werden muss.