Agentic Coding für Weboberflächen

Agentic Coding für Weboberflächen

0:00 Im letzten Modul hat die Maschine auf Zuruf gearbeitet. Jetzt bekommt sie mehr Freiheit: Ein Coding Agent liest das Projekt, ändert Dateien, führt Befehle aus und bewertet das Ergebnis. Das ist ein qualitativer Sprung — und der Leitsatz benennt gleich die Gefahr: Ein Agent, der sofort schreibt, produziert viel Änderung und wenig Verlass.

0:20 Viel Änderung sieht nach Fortschritt aus und ist es nicht. Der wichtigste Einzelrat dieses Moduls kommt deshalb gleich im zweiten Kapitel, und er kostet eine Minute: Lassen Sie erst planen. Das spart regelmäßig eine Stunde.

Agentic Coding für Weboberflächen

0:34 Zehn Kapitel. Erst die Einordnung der drei Selbstständigkeitsstufen, dann die Planung als Qualitätshebel. Danach der Kontext: Projektregeln, die im Repository liegen, und Aufgaben mit prüfbaren Kriterien. Dann die technische Neuerung, die dieses Feld gerade verändert — Agenten mit Browserzugriff — und der iterative Zyklus, der daraus entsteht.

0:54 Zum Schluss drei Kapitel über Kontrolle: automatische Prüfungen, Regressionen und Freigabepunkte. In der Übung führen Sie einen Agentenlauf mit Prüfschleife und vergleichen ihn mit einem Lauf ohne Planungsschritt.

Chat-Assistent, Coding Copilot und Coding Agent

1:08 Sortieren wir zuerst die Begriffe. Drei Stufen der Selbstständigkeit — und mit jeder Stufe steigt nicht nur der Nutzen, sondern im selben Maß die Notwendigkeit, Grenzen zu setzen. Drei Stufen. Der Assistent antwortet auf Fragen — Sie kopieren und übernehmen selbst. Der Copilot ergänzt direkt im Editor, in Ihrem Arbeitsfluss.

1:28 Und der Agent liest das Projekt, ändert Dateien, führt Befehle aus und bewertet das Ergebnis. Das ist qualitativ etwas anderes: Zwischen Ihrer Anweisung und dem Ergebnis liegen viele Einzelentscheidungen, die Sie nicht gesehen haben. Deshalb der zweite Satz: Mit der Selbstständigkeit steigt der Nutzen — und im gleichen Maß die Notwendigkeit, Grenzen und Freigabepunkte zu setzen.

1:51 Beides zusammen, nicht das eine ohne das andere. Die rechte Spalte zeigt, was jede Stufe an Kontrolle verlangt. Beim Assistenten nichts Besonderes — Sie übernehmen von Hand, also prüfen Sie ohnehin beim Einfügen. Beim Copiloten aufmerksames Lesen beim Annehmen; das klingt selbstverständlich und ist es beim fünften Vorschlag in zwei Minuten nicht mehr.

2:13 Und beim Agenten: Plan, Grenzen, Freigabepunkte — also drei Dinge, die man ausdrücklich einrichten muss. Sie entstehen nicht von allein. Das ist die Botschaft dieser Tabelle: Der Sprung zur dritten Stufe ist nicht nur ein Werkzeugwechsel, er verlangt ein Verfahren. Der erste Stolperstein ist eine gute Faustregel in Negativform: einem Agenten Aufgaben geben, die man selbst nicht abnehmen könnte.

2:37 Wenn Sie das Ergebnis nicht beurteilen können, haben Sie keine Kontrolle, sondern nur Hoffnung. Der zweite ist der Alltagsfehler beim Copiloten: die Ergänzung annehmen, weil sie plausibel aussieht — und plausibel ist, wie wir wissen, die Betriebsart. Und der dritte ist der strukturelle: Selbstständigkeit erhöhen, ohne die Prüfkette mitzuziehen.

2:57 Wer zum Agenten wechselt und weiterprüft wie beim Copiloten, hat die Geschwindigkeit erhöht und die Kontrolle verringert.

Planung vor Implementierung

3:04 Jetzt der wichtigste Einzelrat dieses Moduls. Er ist unspektakulär, kostet eine Minute und verändert die Qualität agentischer Arbeit mehr als jede andere Maßnahme. Ein Agent, der sofort losschreibt, produziert viel Änderung und wenig Verlass. Sie bekommen dann einen Änderungssatz über zwanzig Dateien und die Aufgabe, ihn zu verstehen — nachträglich, ohne den Gedankengang zu kennen.

3:27 Lässt man den Agenten dagegen erst einen Plan vorlegen — betroffene Dateien, Vorgehen, Prüfschritte —, dann können Sie den Plan bewerten, bevor Code entsteht. Und einen Plan zu lesen dauert eine Minute. Diese Zwischenstufe ist der wirksamste Qualitätshebel, den ich in der agentischen Arbeit kenne. Sie ist auch der Grund, warum viele Werkzeuge inzwischen einen eigenen Planungsmodus anbieten.

3:51 Vier Dinge sehen Sie im Plan, die Sie sonst erst hinterher sehen. Welche Dateien angefasst werden — und ob das die richtigen sind; hier fällt oft auf, dass der Agent an einer ganz anderen Stelle ansetzen will. Ob die Aufgabe überhaupt richtig verstanden wurde, was erstaunlich oft nicht der Fall ist. Welche Prüfschritte vorgesehen sind und welche fehlen.

4:11 Und der vierte ist der interessanteste: Wo der Agent raten wird, weil ihm Kontext fehlt. Ein guter Plan macht das sichtbar — und dann können Sie den fehlenden Kontext nachliefern, statt eine geratene Lösung zu korrigieren. Der erste Stolperstein ist der, den ich am häufigsten bei mir selbst beobachte: den Plan überfliegen und dann doch alles laufen lassen.

4:33 Der Plan ist da, er sieht vernünftig aus, man will weiterkommen. Lesen Sie ihn wirklich — es sind fünfzehn Zeilen. Der zweite ist eine halbe Anwendung: nach dem Plan fragen und ihn nicht mit der Aufgabe abgleichen. Der Plan kann in sich schlüssig sein und trotzdem die falsche Aufgabe lösen. Und der dritte: große Aufgaben planen lassen, statt sie vorher zu teilen. Ein Plan für eine zu große Aufgabe ist auch nur ein großer, unüberprüfbarer Plan.

Repository-, Design-System- und Accessibility-Regeln als Kontext

5:00 Jetzt zum Kontext. Was in Ihrem Projekt gilt, muss der Agent lesen können — und zwar dort, wo er ohnehin hinschaut. Was nirgends steht, muss er raten. Kompass-Komponenten statt Eigenbau. Tokens statt fester Werte. Semantik vor ARIA. Fokus sichtbar. Das sind die Regeln aus zwei Tagen Seminar — und sie stehen in vielen Teams nirgends, sondern werden mündlich weitergegeben. Für einen Agenten heißt mündlich: nicht vorhanden.

5:28 Solche Regeln gehören als Datei ins Repository, dorthin, wo der Agent liest. Der Gewinn ist doppelt: Sie wirken bei jeder Aufgabe automatisch, und Sie müssen sie nicht in jedem Prompt wiederholen. Und ein angenehmer Nebeneffekt: Neue Teammitglieder lesen sie auch. Die Datei nützt Menschen genauso wie Maschinen. Oben der Normalzustand vieler Projekte: Die Regeln stehen im Kopf erfahrener Leute. Unten fünf Zeilen in einer Datei. Kompass-Komponenten verwenden.

5:59 Abstände und Farben nur über Tokens. Semantisches Element vor ARIA-Attribut. Jede Komponente nennt Rolle, Name, Tasten, Zustände — das ist die Vier-Zeilen-Regel aus Modul sechs. Und: Fokus sichtbar lassen, die Umrandung nie ersatzlos entfernen — das ist der Leitsatz aus Modul zehn. Fünf Zeilen, die den Kern von zwei Seminartagen tragen und bei jeder Aufgabe gelten. Kein Prompt muss sie mehr wiederholen, und keiner kann sie mehr vergessen.

6:29 Der erste Stolperstein ist ein Ortsproblem, das wir aus Modul sechs kennen: Regeln im Wiki pflegen, wo der Agent sie nicht liest. Legen Sie sie dorthin, wo gearbeitet wird — ins Repository. Der zweite ist eine Unvollständigkeit mit klarer Ursache: nur Stilregeln aufschreiben und die Semantik weglassen. Stilregeln fallen bei Reviews auf, Semantikregeln nicht — deshalb sind sie schriftlich noch wichtiger.

6:53 Und der dritte ist ein Alterungsproblem: die Datei anlegen und bei Änderungen im Design System nicht nachziehen. Eine veraltete Regeldatei ist schlimmer als keine, weil der Agent sie befolgt.

Strukturierte Aufgaben und überprüfbare Kriterien

7:05 Jetzt kommt Modul sechzehn zurück. Derselbe Satz, den Sie als Akzeptanzkriterium geschrieben haben, taugt als Auftrag an einen Agenten. Wer dort sauber formuliert hat, spart hier die Arbeit. Ein Auftrag mit Akzeptanzkriterien liefert bessere Ergebnisse als eine offene Bitte — und zwar aus einem einfachen Grund: Das Kriterium ist zugleich die Abnahmebedingung.

7:28 Der Agent weiß dann, woran er selbst prüfen kann, und Sie wissen, woran Sie abnehmen. „Der Dialog schließt mit Escape und gibt den Fokus zurück" ist überprüfbar. „Mach den Dialog barrierefrei" ist es nicht. Sie kennen dieses Begriffspaar aus Modul sechzehn — dort ging es um Menschen, hier um Maschinen, und es funktioniert bemerkenswerterweise für beide gleich.

7:49 Ein guter Satz ist ein guter Satz. Fünf Schritte. Auf eine Komponente oder einen Ablauf begrenzen — Umfang ist der wichtigste Qualitätsfaktor. Die Akzeptanzkriterien aus der Story übernehmen statt neu zu erfinden; Sie haben sie ja schon. Dann Schritt drei, den die Fußzeile zu Recht heraushebt: Benennen, was ausdrücklich nicht geändert werden soll.

8:11 Dieser Schritt verhindert die meisten unerwünschten Nebenwirkungen und wird fast immer vergessen. Dann den Prüfweg vorgeben — Tastatur, Accessibility Tree, Testlauf. Und verlangen, dass am Ende Abweichungen benannt werden. Das ist derselbe Kunstgriff wie die Tastenbelegung aus Modul siebzehn. Der erste Stolperstein ist ein Umfangsfehler mit direkter Wirkung: mehrere Komponenten in einem Auftrag ändern lassen.

8:36 Die Änderungsmenge wächst überproportional, und mit ihr sinkt Ihre Fähigkeit zur Abnahme. Der zweite kennen Sie aus Modul sechzehn: Kriterien formulieren, die nur mit Fachwissen prüfbar sind. Wenn nur Sie das Kriterium prüfen können, gibt es genau einen Flaschenhals. Und der dritte ist der eben besprochene Schritt drei: nicht sagen, was unangetastet bleiben soll.

8:57 Der Agent optimiert dann fleißig mit — Formatierungen, Benennungen, Strukturen — und Ihr Änderungssatz ist dreimal so groß wie nötig.

Agenten mit Browser, DevTools und Testwerkzeugen verbinden

9:06 Jetzt die Entwicklung, die dieses Feld gerade grundlegend verändert. Seit 2026 können Agenten die laufende Anwendung im Browser untersuchen — und damit schließt sich ein Kreis. Bisher hatte ein Agent ein grundsätzliches Problem: Er schrieb Code und wusste nicht, was daraus wird. Er konnte es nur vermuten. Seit 2026 können Coding Agents über Chrome DevTools for Agents eine Anwendung im laufenden Browser untersuchen, verschiedene Gerätebedingungen emulieren und Prüfungen ausführen.

9:35 Damit schließt sich der Kreis: Der Agent ändert nicht nur Code, er sieht das Ergebnis — und, das ist der entscheidende Punkt, er kann seine eigene Änderung widerlegen. Aus Codegenerierung wird ein Prüfprozess. Das ist eine erhebliche Qualitätsverbesserung und gleichzeitig kein Freibrief, wie wir gleich sehen. Vier Zeilen, die den Unterschied greifbar machen. Code wird nicht nur erzeugt, sondern ausgeführt — Laufzeitfehler fallen auf.

10:01 Das Aussehen wird nicht vermutet, sondern gesehen — Layoutfehler fallen auf. Die Semantik wird nicht behauptet, sondern im Baum gelesen — Namen und Rollen werden prüfbar. Und die Prüfung folgt nicht später, sie läuft im Zyklus mit, sodass Belege nebenbei entstehen. Das ist ein echter Fortschritt, und es adressiert genau die Schwächen, die wir in Modul siebzehn aufgelistet haben. Was es nicht ändert: dass ein Mensch am Ende abnimmt.

10:28 Der erste Stolperstein ist der naheliegendste angesichts der neuen Möglichkeiten: den Browserzugriff für einen Konformitätsnachweis halten. Der Agent prüft, was prüfbar ist — die Grenze aus Modul fünfzehn gilt unverändert. Der zweite ist ein Sicherheitsthema mit echten Folgen: den Agenten auf der Produktivumgebung arbeiten lassen. Ein Agent führt Befehle aus; geben Sie ihm eine isolierte Umgebung.

10:52 Und der dritte ist eine Genauigkeitsfrage: emulierte Gerätebedingungen mit echten Geräten verwechseln. Emulation ist eine sehr gute Näherung und kein Ersatz für ein echtes Telefon mit einer echten Mobilverbindung.

Der iterative Zyklus mit Screenshot und Accessibility Tree

11:05 Damit zum Zyklus, der aus alldem entsteht. Er ist derselbe wie in guter menschlicher Entwicklungsarbeit, nur schneller — und ein Schritt darin entscheidet über alles. Untersuchen, planen, ändern, ausführen, testen, bewerten. Das ist der Zyklus, und Sie erkennen darin die Arbeitsweise guter Entwicklungsteams — nur läuft er in Minuten statt in Tagen.

11:27 Entscheidend ist der letzte Schritt: die Bewertung gegen ein Kriterium. Ohne ihn entsteht Bewegung ohne Fortschritt; der Agent ändert, führt aus, ändert wieder — und niemand weiß, ob es besser geworden ist. Für die Bewertung braucht er zwei Rückkanäle: den Screenshot für Layoutfehler und den Accessibility Tree für Semantikfehler.

11:47 Das ist genau die Kombination aus Modul siebzehn, jetzt automatisiert. Vier Gründe, und sie wiederholen bewusst die Logik aus Modul siebzehn, weil sie hier praktisch wird. Der Screenshot zeigt, was Sehende sehen — und sonst nichts. Der Baum zeigt, was gemeldet wird — und nichts über das Aussehen. Erst der Vergleich findet abweichende Namen und Reihenfolgen; das sind genau die Befunde, die dieses Seminar ausmachen.

12:12 Und der vierte Punkt ist der ermutigende: Ein Agent mit beiden Rückkanälen korrigiert die auffälligen Fehler selbst. Er merkt, dass die Schaltfläche keinen Namen hat, und behebt es — ohne dass Sie es bemerken mussten. Das ist echter Gewinn. Der erste Stolperstein ist eine Halbierung der Wirkung: nur Screenshots zurückgeben lassen und Semantik nicht prüfen.

12:34 Dann korrigiert der Agent Layout und übersieht genau das, worum es hier geht. Der zweite ist der Kern dieses Kapitels: den Zyklus ohne Bewertungsschritt fahren und Änderungen zählen. Zwölf Iterationen sind keine Leistung, wenn die zwölfte nicht besser ist als die erste. Und der dritte ist eine Erwartungsfrage: erwarten, dass der Agent subtile Fehler von allein bemerkt.

12:55 Die auffälligen ja — eine falsche Fokusreihenfolge in einem mehrstufigen Ablauf braucht weiterhin einen Menschen mit einem Kriterium.

Automatische Prüfungen im Agentenlauf

13:04 Jetzt die Prüfläufe im Zyklus. Sie erzeugen Vorher-Nachher-Belege, die nebenbei entstehen — mit einer bekannten Einschränkung, die ich noch einmal wiederhole. Prüfläufe lassen sich in den Zyklus einhängen, sodass der Agent seine Änderung sofort gegen einen Regelsatz stellt. Das ist praktisch, weil dabei Vorher-Nachher-Belege entstehen, die Sie mitliefern können — genau die Dokumentation, die in Modul sieben verlangt wurde, ohne dass jemand sie eigens erstellen muss.

13:31 Und dann die Einschränkung, die ich zum dritten Mal sage, weil sie so wichtig ist: Ein sauberer automatischer Lauf ist kein Konformitätsnachweis. Das ist der Satz aus Modul fünfzehn, und er wird durch die Automatisierung nicht schwächer, sondern verführerischer. Diese Tabelle würde ich mir ausdrucken. Weniger Verstöße als vorher sagt: Es wurde etwas behoben — nicht, dass es vollständig ist.

13:54 Keine Verstöße sagt: Der Regelsatz greift nicht mehr — nicht, dass es bedienbar ist. Und ein grüner Testlauf sagt: Bekanntes bleibt heil — nicht, dass Neues geprüft wurde. Drei Belege, drei präzise Aussagen, und keine davon ist „ist barrierefrei". Wenn Sie diese drei Formulierungen in Ihren Berichten verwenden statt der Kurzfassung, sind Sie ehrlich und trotzdem positiv — denn jede der drei Aussagen ist eine gute Nachricht.

14:21 Der erste Stolperstein ist der Kern der Tabelle: den grünen Lauf als Abnahme werten. Der zweite ist ein Dokumentationsfehler, der Ihnen später fehlt: nur den Nachher-Stand aufheben und den Vorher-Stand verwerfen. Ohne Vorher gibt es keinen Beleg für die Verbesserung — Sie haben dann nur eine Momentaufnahme. Und der dritte macht Zahlenvergleiche wertlos: den Regelsatz zwischen den Läufen ändern und die Zahlen trotzdem vergleichen.

14:45 Das ist derselbe Punkt wie bei den Kennzahlen in Modul vierzehn und bei der Regelversion in Modul fünfzehn — gleiche Definition, sonst kein Vergleich.

Regressionen erkennen und Änderungen nachvollziehbar belegen

14:54 Jetzt eine unangenehme Eigenschaft agentischer Arbeit: Manchmal wird ein Fehler behoben und dabei ein neuer erzeugt. Dagegen hilft vor allem eines — kleine Änderungsmengen. Agenten beheben gelegentlich einen Fehler und erzeugen dabei einen neuen. Der Klassiker in unserem Feld: Ein Fokus-Fix stellt nebenbei die Tabulatorreihenfolge um.

15:15 Beides hängt zusammen, die Absicht war gut, und das Ergebnis ist an anderer Stelle kaputt. Dagegen hilft nur zweierlei: eine Testbasis, die vorher grün war, und eine überschaubare Änderungsmenge. Ohne grüne Basis vorher merken Sie den Unterschied nicht. Und zu jeder Änderung gehört eine Zusammenfassung: was geändert wurde, warum, welche Prüfungen liefen, was offen blieb.

15:38 Wie so eine Zusammenfassung aussieht, zeigt die nächste Folie. Oben: „Barrierefreiheit des Dialogs verbessert." Klingt gut, sagt nichts, und in drei Monaten weiß niemand mehr, was passiert ist. Unten fünf Zeilen mit fünf Auskünften: was geändert wurde, warum, was geprüft wurde, was offen blieb und was ausdrücklich nicht angefasst wurde.

15:59 Die letzte Zeile ist übrigens der Nachweis zu Schritt drei aus Kapitel vier. Und die Fußzeile hebt die wichtigste hervor: die Zeile „Offen". Ohne sie wirkt jeder Lauf vollständig — und das ist die gefährlichste Eigenschaft agentischer Arbeit, weil das Ergebnis immer abgeschlossen aussieht. Der erste Stolperstein ist der praktisch folgenreichste: große Änderungsmengen zusammen abnehmen.

16:23 Ab einer gewissen Größe liest niemand mehr wirklich — man überfliegt und stimmt zu. Halten Sie die Mengen klein, das ist Ihr eigentlicher Schutz. Der zweite ist Bequemlichkeit mit Risiko: die Zusammenfassung des Agenten ungeprüft als Commit-Nachricht übernehmen. Sie ist eine Behauptung über die eigene Arbeit, nicht ein Prüfbericht.

16:43 Und der dritte ist ein Ehrlichkeitsproblem, das wir schon aus Modul sieben kennen: offene Punkte weglassen, weil der Lauf sonst unfertig wirkt.

Freigabepunkte und menschliche Kontrolle

16:52 Das letzte inhaltliche Kapitel, und es ist das grundsätzlichste. Es braucht festgelegte Stellen, an denen ein Mensch entscheidet — denn Verantwortung lässt sich nicht an ein Werkzeug delegieren. Drei Stellen bieten sich an: vor dem Plan, vor dem Zusammenführen, vor der Veröffentlichung. An jeder entscheidet ein Mensch. Der Grund ist nicht Misstrauen gegenüber der Technik, sondern eine schlichte Tatsache: Verantwortung lässt sich nicht an ein Werkzeug delegieren.

17:19 Der Agent liefert Vorschläge und Belege, nicht die Freigabe. Und für Barrierefreiheit gilt das doppelt, weil dahinter eine rechtliche Pflicht steht und Menschen, die auf das Ergebnis angewiesen sind. Das ist der Bogen zurück zu Modul sieben: Wenn etwas schiefgeht, haftet nicht das Werkzeug. Jeder Punkt hat eine eigene Frage, und die rechte Spalte sagt, wann er übersprungen wird. Vor dem Plan: Ist die Aufgabe richtig verstanden?

17:45 Übersprungen, wenn der Lauf schon gestartet ist — dann ist der Punkt strukturell nicht mehr erreichbar. Vor dem Zusammenführen: Ist die Änderung überschaubar? Übersprungen, wenn die Menge zu groß wurde, was wieder für kleine Aufträge spricht. Und vor der Veröffentlichung: Sind die Belege vollständig? Übersprungen, wenn der Termin drückt — der ehrlichste Eintrag dieser Tabelle, denn genau dann passiert es.

18:10 Der erste Stolperstein ist eine Unterlassung mit klarer Folge: Freigabepunkte nicht ausdrücklich setzen und sie damit abschaffen. Was nicht vereinbart ist, findet unter Zeitdruck nicht statt. Der zweite ist ein Vier-Augen-Problem: die Freigabe an die Person geben, die den Auftrag geschrieben hat. Sie prüft dann gegen ihre eigene Erwartung und sieht dieselben blinden Flecken.

18:33 Und der dritte ist der, der die ganze Kette aushebelt: Belege akzeptieren, ohne eine Stichprobe selbst nachzustellen. Eine Stichprobe pro Lauf reicht. Aber eine muss sein — sonst prüfen Sie nur, ob der Agent behauptet, geprüft zu haben.

Übung — einen Agentenlauf mit Prüfschleife durchführen

18:47 In der Übung führen Sie einen vollständigen Agentenlauf — und wer schnell ist, macht den Vergleich, der den Kern dieses Moduls belegt. Sie lassen drei bekannte Barrieren beheben. Geübt wird das Führen eines Agentenlaufs, bei dem Plan, Änderung und Beleg getrennt bewertbar sind. Erfolgreich sind Sie, wenn der Plan vor der Änderung vorlag, alle drei Barrieren behoben sind und Ihre eigene Prüfung sowohl Übersehenes als auch neu Entstandenes benennt.

19:13 Beides gehört ins Protokoll. Der Zusatz für die Schnellen ist der eigentliche Beleg für dieses Modul: Geben Sie denselben Auftrag ohne Planungsschritt und vergleichen Sie Umfang und Qualität. Ohne Planungsschritt fällt die Änderungsmenge regelmäßig doppelt so groß aus. Fünf Schritte. Die drei Barrieren als Akzeptanzkriterien formulieren — Sie können die Sätze aus Modul sechzehn übernehmen.

19:36 Plan anfordern und gegen die Kriterien abgleichen; nicht überfliegen. Ausführen lassen, mit Prüfung im Browser nach jeder Änderung. Dann selbst prüfen: Tastatur, Accessibility Tree, die drei Kriterien. Und Schritt fünf: festhalten, was übersehen und was neu kaputtgemacht wurde. Die Fußzeile ergänzt etwas Wichtiges: Dieser Schritt gehört auch dann ins Protokoll, wenn nichts kaputtging.

20:01 „Keine Regression festgestellt" ist ebenfalls ein Befund — und einer, den Sie später brauchen. Der erste Stolperstein ist die Versuchung des Moduls: den Plan durchwinken, um schneller zum Ergebnis zu kommen. Der Plan ist der Ort, an dem Sie am günstigsten eingreifen — hinterher wird es teuer. Der zweite ist ein Prüfumfangsfehler: nur die drei Kriterien prüfen und den Rest der Oberfläche auslassen. Genau dort sitzen die Regressionen.

20:28 Und der dritte hebelt die Kontrolle aus: die Belege des Agenten übernehmen, ohne eine Stichprobe zu wiederholen. Eine Stichprobe, fünf Minuten — und Sie wissen, ob die Belege tragen. Vier Punkte. Plan vor Implementierung ist der wirksamste Hebel im agentischen Arbeiten — eine Minute Lesen gegen eine Stunde Korrektur. Projektregeln gehören ins Repository, nicht in den einzelnen Prompt; fünf Zeilen wirken bei jeder Aufgabe.

20:55 Screenshot und Accessibility Tree tragen erst zusammen, weil die Befunde in den Abweichungen liegen. Und der grundsätzlichste Punkt: Was veröffentlicht wird, hat ein Mensch verantwortet — nicht das Werkzeug. Ein letzter praktischer Rat aus der Fußzeile: Sagen Sie im Auftrag auch, was unangetastet bleiben soll. Im letzten Modul schauen wir voraus — auf ein Web, in dem auch Agenten Nutzer sind.