KI-Agenten in der Webentwicklung: Wie ein Ticket geprüft wird, bevor ich es sehe

Was ein Agent hier ist und was nicht

Ein KI-Agent ist in meinem Ablauf eine eigene Claude-Instanz mit genau einer Aufgabe, einer schriftlichen Anleitung und einem festgelegten Satz Werkzeuge. Der Barrierefreiheits-Agent prüft Barrierefreiheit, der Sicherheits-Agent prüft Sicherheit. Keiner von beiden darf eine Datei ändern: Sie dürfen lesen, suchen und sich den Diff ansehen, mehr nicht.

Das ist der Unterschied zu dem, was meistens unter „KI programmiert“ verstanden wird. Gebaut wird in einer Session, die das Ticket kennt und den Code schreibt. Die Agenten kommen danach und berichten. Was aus ihren Berichten folgt, entscheidet die bauende Session nach festen Regeln, und was keine Regel entscheiden kann, entscheide ich.

Jeder Agent ist eine Markdown-Datei im Projekt, mit einer Beschreibung, wann er gerufen wird, den erlaubten Werkzeugen und der Anleitung selbst. Wer wissen will, warum ein Agent etwas gemeldet hat, liest diese Datei. Es gibt keine Blackbox, nur Text, der versioniert ist wie der übrige Code.

Was sich seit März geändert hat

Im März habe ich in Webentwicklung mit KI beschrieben, wie ich Claude, Copilot und GPT im Alltag nutze. Der Kern damals: Die KI kennt meine Regeln, eine Session baut eine Landingpage in sechs Schritten und prüft am Ende selbst eine Checkliste durch. Das stimmt alles noch. Drei Dinge sehe ich heute anders.

• Wer baut, prüft nicht mehr selbst. Damals hieß Schritt fünf „Fehler behebt sie selbst“. Eine Session, die ihren eigenen Code prüft, findet aber vor allem das, was sie ohnehin für richtig hält. Heute prüfen getrennte Agenten, die den Code nur aus dem Diff kennen.
• Der Prüfung wird selbst misstraut. Ich hatte geschrieben, das KI-Review ersetze kein Review mit einem Kollegen. Das gilt weiter. Neu ist ein Agent, dessen einzige Aufgabe es ist, den anderen zu widersprechen. Erst was diese Gegenprüfung übersteht, wird geändert.
• Figma ist keine Handarbeit mehr, Gestaltung schon. Design-Entscheidungen trifft weiterhin ein Mensch, in Agenturprojekten das Designteam. Die Werte aus dem Entwurf liest heute aber ein Agent über den Figma MCP aus, mit Node-ID für jede Zahl.

Dazu kommt der Rahmen. Damals ging es um meine eigene Website. Heute läuft der Ablauf in Projekten, in denen eine Agentur Design und Projektleitung übernimmt und ich die Entwicklung, mit einem Board, auf dem jemand anderes die Tickets schreibt.

Ein Ticket, ein Worktree, eine Session

Jedes Ticket bekommt einen eigenen Git-Worktree, einen eigenen Branch und eine eigene Claude-Code-Session. Zwei Sessions im selben Checkout gibt es nicht. So laufen mehrere Tickets parallel, ohne dass eine Session die halbfertige Arbeit einer anderen sieht.

Die Tickets stehen auf einem awork-Board. Ein Befehl liest das Ticket über die awork-API: Beschreibung, geplante Stunden, frühere Kommentare und vor allem die Figma-Links, denn sie sind die Designquelle. Daraus entsteht ein Startprompt, der den Umfang festhält, dann der Worktree mit lokaler Vorschau auf eigenem Port. Das Ticket springt auf „In Bearbeitung“.

Die Kette danach hat sechs Glieder, und jedes setzt einen festen Status auf dem Board:

1. Ticket starten: Worktree, Startprompt, Status „In Bearbeitung“.
2. Bauen: zuerst die Spezifikation aus Figma, dann der Code.
3. Selbstprüfung: Messung, Auditoren, Gegenprüfung, Deploy auf Dev, Status „Testing“.
4. Meine Prüfung: anhand des Prüfrahmens im Ticket.
5. Übergabe: an die Agentur zur Freigabe, oder als Rückfrage, wenn nur eine Entscheidung offen ist.
6. Landen: nach der Freigabe auf den Hauptbranch, Status „Fertig“.

Kommt von der Agentur Feedback, geht es als neue Runde in dieselbe Session zurück, mit genau diesen Punkten und keinen weiteren. Widerspricht ein Punkt dem Entwurf oder einer Regel, setzt die Session ihn nicht um, sondern meldet ihn begründet als offen.

Eine Zahl steht fest in der Anleitung: Ab vier Tickets auf „Testing“ fragt der Startbefehl nach, ob wirklich ein weiteres beginnen soll. Der Engpass ist nicht das Bauen. Der Engpass ist, dass ich jedes Ticket selbst prüfe.

Vor dem Bauen liest ein Agent das Design

Bevor eine Zeile Code entsteht, läuft der Design-Auditor. Er ruft über den Figma MCP die Komponente aus dem Design-System ab, mit allen Varianten und Breakpoints. Daraus schreibt er eine Spezifikation als JSON: Breite der Karte bei 1280 Pixeln, Abstand vom Kopf zu den Karten, Schriftgröße der Überschrift bei 375 Pixeln. Jeder Wert trägt die Node-ID, aus der er stammt.

Diese Spezifikation ist die Bauvorgabe. Gebaut wird gegen Zahlen, nicht gegen einen Screenshot. Nach dem Bauen misst ein Skript headless bei 1920, 1280, 1024 und 375 Pixeln, legt Ist und Soll nebeneinander und speichert je Breakpoint einen Screenshot. Die Datei bleibt im Repository, damit sich die nächste CSS-Änderung wieder gegen den Entwurf messen lässt.

Die Falle mit den Variablen

Figma MCP liefert über get_variable_defs, welche Tokens eine Node verwendet, samt Werten. Es sagt aber nicht, wofür. Dass ein Abstands-Token 76 Pixel beträgt, verrät nicht, ob er der Seitenrand ist oder der Spaltenabstand. Genau an dieser Stelle rät ein Modell gern, und deshalb steht in der Anleitung ausdrücklich: Nie aus der Variablenliste auf eine Zuordnung schließen. Für eine Zuordnung braucht es den Design-Kontext genau dieser Node.

Lücken werden Annahmen, keine Fragen

Kein Design-System zeichnet jede Kombination. Fehlt eine Variante bei 1024 Pixeln, leitet der Agent sie aus der nächsten Variante und den Tokens ab und vermerkt sie intern als Annahme, mit Link auf die Vorlage. Abgeleitet heißt dabei nicht erfunden: Jeder Wert hat eine Vorlage im Entwurf. Ob daraus eine Frage an die Agentur wird, entscheide ich beim Prüfen.

Nach dem Bauen prüfen die Auditoren

Hält die Session das Ticket für fertig, ruft sie selbst die Prüfrunde auf. Welche Agenten laufen, hängt davon ab, welche Dateien der Diff berührt. Sie arbeiten parallel, und jeder holt sich den Diff selbst.

Welcher Agent bei welchem Diff prüft

Agent	läuft bei	prüft
Komponenten	Twig, CSS, Template einer Komponente	Projektkonventionen, Tokens, Aufbau
Barrierefreiheit	Markup, CSS, Skripte	WCAG 2.2 AA, ARIA-Muster, Kontrast als Rechnung
Editor	neue oder geänderte Blöcke	ob der Block im Backend so aussieht wie im Frontend
Design	Komponente mit Figma-Node	Spezifikation gegen CSS und Markup
SEO	Templates, strukturierte Daten	Überschriften, Schema, Archive
Performance	neues CSS oder JavaScript, Bilder	LCP-Kandidaten, Bildgrößen, Ladeverhalten
Sicherheit	PHP mit Eingaben, REST, Import	Escaping, Nonces, Berechtigungen
Backend	PHP außerhalb der Komponenten	Architektur, Fehlerfälle
Testlücken	reine Logik in PHP	was einen Test bräuchte
Browser	Seiten, auf denen der Code läuft	Chrome, Firefox, WebKit, iPhone, Android im Vergleich

Dazu kommen drei auf Abruf, für Datenschutz, Launch und Fehlersuche. Alle Anleitungen teilen denselben Absatz, und er ist mir wichtiger als jede einzelne Prüfregel: Ein Lauf ohne Befund ist ein gültiges Ergebnis. Was nicht geprüft werden konnte, steht als „nicht geprüft“ im Bericht, nicht als „in Ordnung“.

Der Satz steht dort, weil ein Modell, das Fehler finden soll, sonst welche liefert. Die Anleitungen enthalten deshalb Regeln gegen Fehlalarme. Der Barrierefreiheits-Agent darf zum Beispiel kein role="button" auf einem <button> verlangen, kein aria-label neben sichtbarem Text und keinen Kontrastmangel melden, ohne ihn aus den Tokens bis zum Hex-Wert auszurechnen. „Wirkt zu hell“ ist kein Befund.

Und jeder Agent bewertet nur, was der Diff hinzufügt. Was vorher schon so war, landet in einer eigenen Liste und wird nicht im laufenden Ticket repariert. Sonst wächst jedes Ticket um die Altlasten, die zufällig in derselben Datei stehen.

Der wichtigste Agent widerspricht

Der Befund-Prüfer bekommt alle Befunde einer Runde auf einmal. Seine Anleitung beginnt mit dem Satz: Auditoren, die Lücken finden sollen, finden fast immer welche, auch wenn die Arbeit stimmt. Seine Aufgabe ist das Gegenteil. Er soll jeden Befund am Code widerlegen, nicht am Bericht.

Dazu liest er die genannte Stelle samt Umgebung und ordnet jeden Befund ein:

• bestätigt: Die Tatsache stimmt, kommt durch diesen Diff und verletzt Korrektheit, Sicherheit, Barrierefreiheit, den Entwurf oder eine Projektregel. Nur das wird behoben.
• optional: Stimmt, ist aber Härtung oder Geschmack. Geht in meine Checkliste, wird nicht geändert.
• vorbestehend: Stimmt, war aber schon vorher da. Wird ein eigenes Ticket.
• widerlegt: Stimmt nicht, mit Beleg aus dem Code. Fällt weg.
• nur im Browser entscheidbar: Bleibt offen für die Messung oder für mich.

Bestätigte Befunde behebt die Session selbst und misst neu, höchstens zwei Runden lang. Was danach offen ist, steht in meiner Checkliste. Die Grenze ist Absicht: Eine Session, die bis zum letzten Befund weiterrepariert, baut irgendwann Code für die Prüfer statt für die Website.

Auch der Befund-Prüfer hat einen Ehrlichkeitsabsatz. Er widerlegt nur, was er belegen kann. Ein Lauf, in dem alles bestätigt wird, ist so gültig wie einer, in dem alles fällt.

Ein Agent hält die Regeln ehrlich

Die Agenten sind nur so gut wie die Regeln, nach denen sie prüfen. Und Regeln veralten: Eine Klasse wird umbenannt, ein Pfad verschoben, ein Wert geändert, und die Regel behauptet weiter den alten Stand. Eine falsche Regel ist teurer als keine, weil sie jede folgende Session in denselben Fehler schickt.

Deshalb läuft in jeder Runde der rules-keeper. Er sucht alles, was der Diff geändert hat, in den Regeln, Skills und Agenten-Anleitungen, auch unter dem alten Namen. Er meldet, was falsch geworden ist, was fehlt und wo zwei Anleitungen sich jetzt widersprechen. Für diese eher mechanische Suche läuft er, wie der Browser-Agent, auf einem kleineren Modell als die übrigen.

Was sich wiederholt, wird zur Regel

Jeder Befund bekommt einen kurzen, wiederverwendbaren Schlüssel, der den Fehler benennt und nicht die Kategorie. Beim Landen eines Tickets werden die Schlüssel gesucht, die in diesem und mindestens einem anderen Ticket vorkamen. Daraus wird einer von drei Vorschlägen: eine Regel in der passenden Datei, eine automatische Prüfung oder verwerfen. Auch „verwerfen“ wird notiert, damit derselbe Vorschlag nicht beim nächsten Ticket wiederkommt.

Dahinter steht der Grundsatz, der das ganze System klein hält: Was ein grep entscheiden kann, gehört in ein Skript, nicht in einen Agenten. Agenten sind für Urteile da. Ein fehlendes alt-Attribut findet ein Suchbefehl zuverlässiger und für einen Bruchteil der Kosten.

Was bei mir ankommt: der Prüfrahmen

Am Ende der Selbstprüfung steht der Stand auf Dev, und im Ticket steht ein interner Kommentar, den die Agentur nicht sieht. Er heißt Prüfrahmen und ist immer gleich gegliedert:

• Optisch prüfen: der Hauptteil. Varianten und Breakpoints, die eine Messung nicht entscheidet, Inhaltsgrenzen wie sehr lange Überschriften oder leere Felder. Jeder Punkt mit Figma-Link auf die Node.
• Code-Stichproben: zwei bis vier Stellen, nach Risiko ausgewählt, nicht nach Größe. Sicherheitsrelevantes immer zuerst.
• Zu entscheiden: Annahmen bei Lücken im Entwurf, Änderungen an geteilten Dateien, jeweils mit Vorschlag.
• Automatisch geprüft: welche Agenten liefen, wie viele Werte der Messung im Rahmen lagen, was die Gegenprüfung ergab.
• Nicht geprüft: was fehlte und warum, zum Beispiel Testinhalt oder ein Zustand ohne Entwurf.

Der letzte Abschnitt fehlt nie, auch wenn er der unbequemste ist. Eine Komponente, die mit einem Satz Testinhalt geprüft wurde, ist für genau diesen Satz Testinhalt abgesichert. Nicht für acht Listenpunkte, nicht für eine Überschrift über drei Zeilen. Steht das nicht im Prüfrahmen, glaube ich beim Prüfen, es sei erledigt.

Was behoben ist, steht nicht als Aufgabe drin, sondern nur in der Zählung. So prüfe ich keine Liste von Dingen, die schon erledigt sind, sondern nur das, was ein Mensch ansehen muss.

Wo der Mensch bleibt

Die Agenten entscheiden viel, aber nichts, was nach außen wirkt. Die Schritte, die etwas verändern, das andere sehen, ruft nur ein Mensch auf: das Ticket starten, an die Agentur übergeben, Feedback einspielen, auf den Hauptbranch landen. Die Selbstprüfung und den Deploy auf Dev ruft die Session selbst auf, denn beides sieht außer mir niemand.

Fragen an die Agentur haben eine Schwelle

Eine KI fragt gern nach. In einem Agenturprojekt kostet jede Frage aber Zeit auf der anderen Seite. Eine sichtbare Frage an das Design entsteht deshalb nur, wenn drei Dinge zusammenkommen: Der Entwurf widerspricht sich oder lässt nichts Belastbares ableiten, die Antwort ändert, was der Endkunde sieht, und eine falsche Annahme wäre teuer zurückzunehmen. Eine Frage, die mit „macht es wie bei X“ beantwortet würde, ist keine. Dann ist X die Antwort.

Was die Agentur zu lesen bekommt, ist anders geschrieben als der Prüfrahmen: Alltagssprache, kein Dateiname, keine CSS-Eigenschaft. Was ist neu, bitte anschauen, und nur wenn nötig eure Entscheidung. Wer ein Projekt leitet, soll entscheiden können, ohne eine CSS-Kaskade zu lesen.

Zeit aus dem Protokoll, nicht von der Stoppuhr

Gebucht wird die Zeit, in der eine Session am Ticket gearbeitet hat, ausgelesen aus dem Transkript. Zeitstempel mit weniger als fünf Minuten Abstand bilden einen Block, längere Pausen zählen nicht. Meine eigene Prüfzeit steht nicht im Transkript, weil sie großteils im Browser stattfindet. Sie wird deshalb abgefragt, nicht geschätzt. Am Ende steht im Ticket Ist gegen Plan, ohne Aufrunden.

Ein Hook erinnert die Session, wenn nach der letzten Prüfrunde neue Commits dazugekommen sind oder Änderungen uncommittet herumliegen. Er erinnert einmal und sperrt nicht. Ein zweiter Versuch geht immer durch.

Was das für Agenturen bedeutet

Für eine Agentur, die Entwicklung vergibt, ändert der Ablauf vor allem eines: Jede Aussage über das Design ist belegt. Weicht etwas ab, steht daneben die Zahl, der Sollwert und der Link auf die Node. Hat die Entwicklung etwas angenommen, steht es als Annahme im Ticket und nicht als stille Entscheidung im Code.

Schneller wird es auch, aber das ist nicht der Punkt, auf den es ankommt. Die gewonnene Zeit geht in die Prüfung. Jedes Ticket, das bei der Agentur zur Freigabe landet, ist vorher gemessen, von mehreren Agenten gelesen, gegengeprüft und von mir angesehen worden. Wie die Zusammenarbeit abläuft und wie ein Festpreis zustande kommt, steht auf der Seite zur WordPress-Entwicklung für Agenturen.

Gebaut wird in diesen Projekten auf dem Baukasten aus Custom Gutenberg Blocks mit Timber und Twig, den die Agenten über ihre Regeln kennen. Der Gedanke dahinter ist derselbe wie beim Ausrollen von WordPress-Updates in Stufen: Nichts geht weiter, bevor die vorige Stufe belegt ist. Wer hinter dem Ablauf steht und welche Agenturjahre ihn geprägt haben, steht auf der Seite über mich und meinen Werdegang.

Mein Fazit nach den ersten Wochen: Die Agenten haben nicht ersetzt, dass ich prüfe. Sie haben verändert, was ich prüfe. Statt einen Diff Zeile für Zeile zu lesen, sehe ich mir die Stellen an, die eine Maschine nicht entscheiden kann, und weiß dabei, welche das sind.

---