KI-gestützte UI- und UX-Entwicklung

KI-gestützte UI- und UX-Entwicklung

0:00 Jetzt kommt der Teil, auf den viele von Ihnen gewartet haben. Wie hilft künstliche Intelligenz beim Bauen von Oberflächen? Die Antwort ist erfreulich — an vielen Stellen erheblich. Und der Leitsatz nennt gleich die Bedingung: Generierter Code ist schnell da und sieht ordentlich aus. Genau deshalb braucht er dieselbe Prüfung wie jeder fremde Beitrag.

0:20 Sie würden auch keinen Pull Request eines unbekannten Beitragenden ungeprüft übernehmen, nur weil er sauber formatiert ist. Wichtig ist außerdem: Alles in diesem Modul setzt auf den prüfbaren Kriterien aus Modul sechzehn auf. Ohne sie gibt es nichts zu messen.

KI-gestützte UI- und UX-Entwicklung

0:36 Zehn Kapitel, und sie sind nach Verlässlichkeit sortiert. Erst die drei Rollen und ihre Risikoniveaus. Dann die Einsatzfelder, bei denen der Gewinn hoch und das Risiko gering ist: Spezifikationen ableiten, Varianten erzeugen, Edge Cases finden. Dann der heiklere Teil — Code erzeugen — und der wirksamste Hebel dagegen, nämlich die Verankerung im Auftrag.

0:57 Danach zwei Kapitel über den verlässlichsten Einsatz überhaupt: Erklären lassen und die Kombination der drei Datenquellen. Und zum Schluss die Verifikation. In der Übung beauftragen Sie eine Dialogkomponente und verbessern nicht den Code, sondern den Auftrag.

KI als Sparringspartner, Generator und Reviewer

1:13 Beginnen wir mit der Sortierung. Ein Sprachmodell kann drei sehr verschiedene Rollen einnehmen — und das Risiko unterscheidet sich dabei erheblich. Die riskanteste ist die, die am seriösesten wirkt. Drei Rollen, drei Risikoniveaus. Als Sparringspartner ist ein Modell nahezu risikofrei — das Ergebnis ist eine Diskussion, und die Entscheidung treffen Sie.

1:35 Wenn ein Argument nicht taugt, merken Sie es im Gespräch. Als Generator erzeugt es Artefakte, und die müssen geprüft werden wie fremde Arbeit. Als Reviewer beurteilt es fremde Arbeit — und das ist die gefährlichste Rolle, weil dort Plausibilität und Richtigkeit am leichtesten verwechselt werden. Ein gut formulierter Befund mit Kriteriennummer sieht nach Fachkompetenz aus. Er kann trotzdem an der Sache vorbeigehen, und Sie merken es nicht.

2:01 Die rechte Spalte ist die praktische: Was bleibt zu prüfen? Beim Sparringspartner nichts — die Entscheidung war immer bei Ihnen, der Vorschlag hat sie nur informiert. Beim Generator alles, genau wie bei fremdem Code. Und beim Reviewer jeder Befund einzeln, am Standard nachgeschlagen. Das ist Arbeit, und deshalb sollten Sie sich vorher fragen, ob die Reviewer-Rolle den Aufwand lohnt.

2:24 Häufig ist die Antwort ja — ein zusätzlicher Blick findet Dinge, die das Team übersieht. Aber der Aufwand für die Verifikation gehört in die Rechnung, sonst ist es kein Zeitgewinn, sondern eine Risikoverlagerung. Der erste Stolperstein ist strategisch und wird oft übersehen: ein Vorgehen aufbauen, das nur mit einem Anbieter funktioniert.

2:45 Der Markt bewegt sich schnell; halten Sie Ihre Aufträge und Kriterien so, dass sie übertragbar bleiben. Der zweite ist der Kern dieses Kapitels: die Reviewer-Rolle einsetzen, ohne Befunde nachzuprüfen. Dann haben Sie eine zweite Meinung, die niemand verantwortet. Und der dritte begleitet uns seit Modul drei: Artefakte übernehmen, weil sie flüssig formuliert sind.

3:06 Flüssigkeit ist die Kernkompetenz dieser Systeme — sie ist kein Qualitätsmerkmal, sie ist die Betriebsart.

Anforderungen in überprüfbare UI-Spezifikationen übersetzen

3:13 Jetzt ein Einsatz, den ich uneingeschränkt empfehle. Vage Wünsche in prüfbare Sätze umschreiben ist Fleißarbeit — und Fleißarbeit ist der beste Einsatzzweck dieser Werkzeuge. Erinnern Sie sich an Modul sechzehn: Aus „Der Dialog soll benutzerfreundlich sein" muss eine Liste prüfbarer Sätze werden — Fokusverhalten, Tastenbelegung, Namen, Fehlerzustände.

3:36 Diese Übersetzung ist mühsam, sie ist repetitiv, und ein Modell leistet sie hervorragend. Es kennt die üblichen Muster, es vergisst keinen Zustand, und es formuliert in Sekunden, wofür man sonst eine halbe Stunde braucht. Der entscheidende Satz steht am Ende: Was gilt, entscheiden Sie. Das Modell schlägt die vollständige Liste vor, und Sie streichen und ergänzen.

3:58 Diese Arbeitsteilung funktioniert bemerkenswert gut. Fünf Schritte. Sie benennen den vagen Wunsch und die Komponente, geben die Vier-Zeilen-Regel aus Modul sechs als Gliederung vor — Rolle, Name, Tasten, Zustände — und verlangen ausdrücklich prüfbare Formulierungen statt Absichtserklärungen. Dann kommen die beiden Schritte, die laut Fußzeile die eigentliche Arbeit sind: durchgehen und streichen, was nicht gelten soll, und ergänzen, was fachlich fehlt.

4:24 Das Ergänzen ist der Teil, den kein Modell leisten kann, weil Ihre Fachlichkeit nirgends in den Trainingsdaten steht. Bei Fahrtwind etwa: Was passiert, wenn die Reservierung während des Dialogs abläuft? Der erste Stolperstein ist die Abkürzung, die den Nutzen zerstört: die erzeugte Liste ungeprüft als Spezifikation weitergeben.

4:44 Dann steht in Ihrer Spezifikation, was üblich ist — nicht, was in Ihrem Fall gilt. Der zweite ist eine Frage, die immer dieselbe Antwort bekommt: nach Vollständigkeit fragen. Das Modell bestätigt sie stets, und das ist keine Auskunft. Und der dritte ist eine Erwartungsfrage: fachliche Regeln erwarten, die nirgends im Kontext stehen.

5:05 Ein Modell kann Ihre Stornobedingungen nicht kennen. Wenn Sie sie nicht mitgeben, erfindet es plausible — und plausibel ist hier das Problem.

Varianten, Wireframes und UX Writing erzeugen

5:14 Weiter zu einem Einsatz, der eine echte Verhaltensänderung ermöglicht. Varianten sind billig geworden — und das erlaubt Entscheidungen, die man vorher aus Aufwandsgründen nicht getroffen hat. Früher hat man eine Ergebnisliste entworfen, weil fünf Entwürfe eine Woche gekostet hätten. Heute kosten fünf Entwürfe Minuten. Das ändert nicht nur die Kosten, das ändert die Art der Entscheidung — Sie wählen aus statt zu rechtfertigen.

5:40 Ähnlich stark sind diese Werkzeuge beim Umformulieren von Fehlertexten und Beschriftungen; das ist genau die Microcopy aus Modul vier, für die im Alltag nie Zeit war. Der Wert liegt dabei im Vergleich, nicht in der direkten Übernahme. Fünf Varianten nebeneinander sagen Ihnen mehr über Ihre eigenen Kriterien als eine, über die man diskutiert.

6:00 Oben eine Bitte um Freundlichkeit. Was zurückkommt, ist freundlich — und in jedem Fall anders, weil „freundlich" nichts festlegt. Unten ein Auftrag mit vier Vorgaben: Nenne Ursache und nächsten Schritt in zwei Sätzen — das ist die Regel aus Modul elf. Sieze, keine Ausrufezeichen, kein Fachjargon. Und die letzte Zeile ist die, die man am häufigsten vergisst: die Terminologie. Fahrt statt Reise, Abfahrt statt Start.

6:26 Ohne diese Vorgabe driftet die Sprache über die Anwendung hinweg auseinander — auf einer Seite heißt es Fahrt, auf der nächsten Reise, und niemand merkt es, bis ein Nutzer stolpert. Der erste Stolperstein ist der eben gezeigte: ohne Tonfall- und Begriffsvorgabe formulieren lassen. Legen Sie diese Vorgaben einmal ab — das ist derselbe Gedanke wie beim Namensregister aus Modul sechs.

6:50 Der zweite verschenkt den eigentlichen Gewinn: die erste Variante übernehmen, statt zu vergleichen. Wenn Sie nicht vergleichen, hätten Sie sich das Erzeugen von fünf Varianten sparen können. Und der dritte ist eine Sorgfaltsfrage: generierte Texte ohne Gegenlesen in die Oberfläche stellen. Fehlertexte und Beschriftungen sind das, was Ihre Nutzer am häufigsten lesen.

7:11 Sie verdienen einen zweiten Blick von einem Menschen.

Alternative Bedienwege und Edge Cases erzeugen

7:15 Jetzt der unstrittigste Einsatz dieses Moduls — Sie kennen ihn schon aus Modul drei. Eine Liste in Minuten statt in Workshopstunden, mit klarer Trennung zwischen Vorschlagen und Entscheiden. Fragen Sie ein Modell nach Fällen, die ein Entwurf nicht abdeckt, und Sie bekommen eine brauchbare Liste: keine Verbindung gefunden, Fahrt während der Buchung ausgebucht, Zahlung abgebrochen, Sitzung abgelaufen.

7:39 Das sind genau die Zustände aus Modul vier, die im Entwurf regelmäßig fehlen. Diese Liste zu erzeugen kostet Minuten, sie im Workshop zu erarbeiten kostet Stunden — und das Workshop-Ergebnis ist meist kürzer, weil eine Gruppe nach zehn Fällen erschöpft ist. Wichtig bleibt die Einordnung: Das ist ein Vorschlag, keine Analyse. Sie ersetzt keinen Testlauf, spart aber viel Vorbereitungszeit.

8:02 Vier Gründe, dieselben wie in Modul drei — und sie gelten hier genauso. Das Erzeugen ist Fleißarbeit, das Auswählen die Fachaufgabe, und die bleibt bei Ihnen. Ein breiter Vorschlagsraum verhindert die frühe Festlegung auf den ersten Einfall; das ist eine der zähesten Kräfte in Workshops. Ein schlechter Fall wird verworfen und kostet nichts — es gibt hier keine stille Fehlinformation wie bei generierten Anforderungen.

8:27 Und die Diskussion startet bei zwanzig Fällen statt bei drei. Das verändert die Qualität des Gesprächs grundlegend: Sie priorisieren, statt zu sammeln. Der erste Stolperstein ist eine Statusverwechslung: die Liste als vollständig behandeln. Es fehlt garantiert etwas — besonders das, was in Trainingsdaten selten vorkommt, also gerade Ihre Besonderheiten. Der zweite ist ein Mengenproblem: alle Fälle umsetzen wollen.

8:52 Ein Vorschlag ist keine Verpflichtung; zwanzig Edge Cases umzusetzen sprengt jeden Sprint und die meisten sind selten. Und der dritte führt zurück zu Modul zwei: Fälle ohne Nutzungskontext bewerten und dabei den Bahnsteigfall vergessen. Was am Schreibtisch unrealistisch klingt, ist unterwegs Alltag. Bewerten Sie gegen den Kontext-Steckbrief.

HTML-, CSS- und Komponentencode erzeugen

9:13 Jetzt der heikelste Teil: Code erzeugen lassen. Die Prüfung ist dieselbe wie bei fremdem Code — mit einem Zusatz, der es hier besonders schwierig macht. Generierter Code ist schnell da und sieht ordentlich aus: gute Namen, saubere Einrückung, Kommentare. Genau deshalb braucht er dieselbe Prüfung wie fremder Code aus einem Pull Request.

9:33 Und jetzt kommt der Zusatz, der dieses Feld besonders macht: Bei Barrierefreiheit sind die Fehler unsichtbar, solange man nur hinschaut. Ein Container mit Schaltflächen-Rolle liest sich im Code völlig plausibel — der Autor hat ja an die Rolle gedacht. Der Fehler zeigt sich erst beim Drücken der Leertaste. Der Test ist deshalb nicht das Lesen, sondern die Tastatur und der Accessibility Tree.

9:56 Diese Tabelle ist eine Prüfliste für generiertes Markup, und die rechte Spalte sagt Ihnen, womit Sie den Fehler finden. Container mit Schaltflächen-Rolle sieht aus wie ein Knopf und fällt bei der Leertaste auf. Ein Label-Attribut neben einer sichtbaren Beschriftung sieht besonders sorgfältig aus und fällt bei der Sprachsteuerung auf.

10:15 Überschriften nach Größe gewählt sehen nach sauberer Struktur aus und fallen in der Überschriftenliste auf. Und eine Rolle ohne Tastenmuster sieht nach einem vollständigen Widget aus und fällt bei den Pfeiltasten auf. Vier Fehler, vier Handgriffe — das ist Ihre Prüfroutine. Der erste Stolperstein ist der zentrale dieses Kapitels: generierten Code nur lesen und nicht bedienen. Beim Lesen sieht alles gut aus — das ist ja die Stärke dieser Systeme.

10:41 Der zweite ist eine Halbheit, die wir aus Modul fünfzehn kennen: die Prüfung auf den automatischen Lauf beschränken. Eine Rolle ohne Tastenmuster besteht jede automatische Prüfung. Und der dritte ist eine Perspektivfrage: übernehmen, weil es funktioniert — ohne zu prüfen, für wen. Es funktioniert nämlich mit der Maus, und mit der Maus haben Sie es getestet.

Accessibility-Anforderungen im Prompt verankern

11:03 Jetzt der wirksamste Hebel des ganzen Moduls — und er liegt nicht in der Nachbesserung, sondern im Auftrag selbst. Der Unterschied lässt sich an fünf Zeilen zeigen. Die Erkenntnis ist simpel und wirkt sofort: Wer Semantik, Tastaturverhalten, zugänglichen Namen und Fehlerzustände ausdrücklich verlangt, bekommt deutlich besseren Code als mit einer allgemeinen Bitte um Barrierefreiheit.

11:26 Das Wort „barrierefrei" allein bewirkt erstaunlich wenig — es ist zu vage, um das Ergebnis zu lenken, und es führt oft sogar zu mehr ARIA statt zu besseren Elementen. Und der zweite Satz ist der organisatorische: Diese Vorgaben gehören in eine Projektanweisung, damit sie nicht jedes Mal neu geschrieben werden. Genau das ist der Übergang zu Modul achtzehn.

11:47 Oben: „Baue ein barrierefreies Akkordeon." Das führt zuverlässig zu Container-Gerüsten mit reichlich ARIA — die Maschine versucht, das Adjektiv zu erfüllen, und ARIA sieht nach Barrierefreiheit aus. Unten fünf konkrete Vorgaben: Bauart aus echten Elementen, kein ARIA, wo ein Element genügt, Zustandsmeldung, Tastaturbedienung.

12:07 Und die letzte Zeile ist der Trick, den ich Ihnen besonders ans Herz lege: „Nenne am Ende die Tastenbelegung." Das erzwingt eine Aussage über das Verhalten — und macht das Ergebnis prüfbar. Sie können die genannte Belegung nämlich sofort gegen den Code halten. Der erste Stolperstein ist der eben gezeigte: „barrierefrei" als Adjektiv in den Auftrag schreiben und hoffen. Das ist kein Auftrag, das ist ein Wunsch.

12:33 Der zweite ist Verschwendung mit Qualitätsverlust: Vorgaben jedes Mal neu formulieren statt sie abzulegen. Jedes Mal neu heißt jedes Mal etwas anders, und dann schwanken auch die Ergebnisse. Und der dritte ist eine verpasste Gelegenheit: nach Code fragen, ohne die Tastenbelegung mitzuverlangen. Diese eine Zeile kostet nichts und liefert Ihnen eine überprüfbare Selbstauskunft — die übrigens erstaunlich oft von dem abweicht, was der Code tatsächlich tut.

Bestehenden Code erklären und prüfen lassen

13:00 Jetzt der verlässlichste Einsatz im ganzen Modul — und meiner Erfahrung nach der unterschätzteste. Es geht ums Erklären statt ums Erzeugen. Fragen Sie: „Warum bekommt dieses Element keinen zugänglichen Namen?" Das ist ein sehr verlässlicher Einsatz, und zwar aus einem strukturellen Grund: Bei solchen Fragen arbeitet das Modell am vorliegenden Code, nicht aus dem Gedächtnis — und die Antwort lässt sich sofort widerlegen, indem Sie in den Accessibility Tree schauen.

13:28 Der Nutzen ist zudem hoch, weil das Erklären von Semantik genau die Lücke schließt, die in vielen Teams besteht. Es ist im Grunde ein geduldiger Kollege, der die Spezifikationen gelesen hat und rund um die Uhr Fragen beantwortet. Vier Gründe, und sie erklären das strukturelle Gefälle. Die Antwort bezieht sich auf vorliegenden Code, nicht auf Erinnerung — der Gegenstand liegt vor.

13:50 Sie lässt sich in dreißig Sekunden im Accessibility Tree widerlegen, also ist der Prüfaufwand minimal. Sie vermittelt Wissen, das beim nächsten Mal ohne Werkzeug trägt — das ist der Weiterbildungseffekt, den ich für den größten halte. Und ein Irrtum kostet nichts, weil nichts übernommen wurde. Vergleichen Sie das mit dem Erzeugen: dort ist der Gegenstand neu, die Prüfung aufwendig, und ein Irrtum landet im Produkt.

14:15 Der erste Stolperstein untergräbt den ganzen Vorteil: die Erklärung als Beleg verwenden, ohne sie nachzuprüfen. Die Nachprüfung dauert dreißig Sekunden — machen Sie sie. Der zweite ist eine Frageform mit schlechterem Ertrag: nach der Bewertung fragen statt nach der Erklärung. „Ist das gut?" liefert ein Urteil, „Warum passiert hier X?" liefert eine nachprüfbare Kausalkette.

14:39 Und der dritte ist ein Kontextfehler: Ausschnitte ohne umgebenden Kontext vorlegen und daraus schließen. Semantik hängt am Umfeld — ob eine Überschrift richtig ist, hängt davon ab, was darüber steht.

Screenshot, DOM und Accessibility Tree gemeinsam auswerten

14:52 Jetzt eine Technik, die erst durch die Kombination trägt. Drei Quellen, drei Antworten — und die wertvollen Befunde entstehen genau dort, wo sie auseinanderfallen. Drei Quellen mit drei verschiedenen Auskünften. Der Screenshot zeigt, was zu sehen ist. Das DOM zeigt, was gebaut wurde. Der Accessibility Tree zeigt, was ankommt.

15:12 Jede für sich ist unvollständig. Aber aus dem Vergleich entstehen genau die Befunde, um die es in diesem Seminar geht: Die sichtbare Beschriftung heißt „Buchen", der zugängliche Name „Weiter zur Zahlung" — das ist der Sprachsteuerungsfall. Die sichtbare Reihenfolge ist eine, die Fokusreihenfolge eine andere — das ist die Anordnungsfalle aus Modul neun.

15:34 Beide Befunde sind aus einer einzelnen Quelle grundsätzlich nicht erkennbar. Die rechte Spalte nennt die jeweilige Blindheit, und sie ist das Argument für die Kombination. Der Screenshot ist blind für Semantik und Reihenfolge — er kann nicht wissen, was ein Element ist. Das DOM ist blind dafür, was davon tatsächlich ankommt; zwischen Markup und Baum liegen Berechnungsregeln.

15:57 Und der Accessibility Tree ist blind dafür, wie es aussieht — er kennt keine Kontraste und keine Positionen. Wenn Sie ein Modell mit solchen Fragen beauftragen, geben Sie deshalb alle drei mit und bitten Sie ausdrücklich um den Abgleich. Der Abgleich ist die Leistung, nicht die Einzelanalyse. Der erste Stolperstein ist häufig, weil Screenshots so bequem sind: nur den Screenshot vorlegen und Semantikfragen stellen.

16:21 Das Modell wird antworten — plausibel und geraten, denn im Bild steht die Antwort nicht. Der zweite ist ein Kurzschluss, den auch erfahrene Entwickler machen: aus dem DOM auf den zugänglichen Namen schließen. Der Name entsteht nach festen Regeln aus mehreren Quellen; was im Attribut steht, muss nicht ankommen. Und der dritte verschenkt den Gewinn: die drei getrennt auswerten und die Abweichungen nicht suchen. Der Abgleich ist der Punkt, alles andere bekommen Sie auch einzeln.

KI-Befunde gegen die Standards verifizieren

16:50 Das letzte inhaltliche Kapitel behandelt eine Fehlerquelle mit unangenehmen Folgen. Modelle nennen Kriteriennummern mit großer Selbstverständlichkeit — und liegen dabei regelmäßig daneben. Jeder generierte Befund braucht zweierlei: die Rückführung auf ein konkretes Kriterium und eine eigene Nachprüfung. Denn hier liegt ein Verhalten vor, das in der Praxis viel Schaden anrichtet: Modelle nennen Kriteriennummern mit großer Selbstverständlichkeit und liegen dabei regelmäßig daneben.

17:18 Die Nummer klingt präzise, sie sieht nach Fachkompetenz aus, und in einem Kundenbericht ist sie ein Sachfehler mit Folgen. Dasselbe gilt für Fristen, Geltungsbereiche und Normfassungen — also für alles, worüber wir in Modul sieben gesprochen haben. Gerade dort ist die Versuchung groß, weil die Recherche mühsam ist. Fünf Schritte, und keiner davon ist verzichtbar. Das genannte Kriterium im Standard selbst nachschlagen — nicht in einer Zusammenfassung, im Standard.

17:45 Prüfen, ob es die beschriebene Situation überhaupt abdeckt; das ist der Schritt, bei dem die meisten Fehlzuordnungen auffallen. Den Befund im Produkt reproduzieren, mit Schritten — das ist die Anforderung aus Modul fünfzehn. Die Auswirkung auf Nutzende selbst formulieren, weil nur Sie den Kontext kennen. Und erst dann in den Bericht übernehmen. Die Fußzeile nennt den Grund: Ein falsch zugeordnetes Kriterium fällt beim Kunden auf und beschädigt den ganzen Bericht.

18:14 Der erste Stolperstein ist der eben besprochene: Kriteriennummern ungeprüft übernehmen. Der zweite ist der riskanteste in diesem ganzen Seminar: rechtliche Aussagen aus einem Modell in Kundenunterlagen übernehmen. Erinnern Sie sich an Modul sieben — wir ordnen ein, wir beraten nicht. Das gilt erst recht für eine Maschine, die keine Verantwortung trägt und deren Trainingsdaten einen Stichtag haben.

18:37 Und der dritte ist ein Verfahrensfehler: Befunde bündeln, bevor sie einzeln reproduziert wurden. Dann prüfen Sie eine Zusammenfassung und übernehmen die Fehler der Einzelteile mit.

Übung — eine Dialogkomponente beauftragen und prüfen

18:48 In der Übung beauftragen Sie eine Komponente, prüfen sie — und verbessern dann nicht den Code, sondern den Auftrag. Das ist der Unterschied zwischen einmal und immer. Sie beauftragen eine Dialogkomponente, prüfen das Ergebnis und überarbeiten den Auftrag. Geübt wird das Formulieren eines Auftrags, dessen Ergebnis prüfbar ist — und das Nutzen der Abweichungen zur Verbesserung des Auftrags.

19:11 Erfolgreich sind Sie, wenn der Dialog per Tastatur vollständig bedienbar ist, jede Abweichung benannt ist und der überarbeitete Auftrag sie nachweislich verhindert. Der Zusatz für die Schnellen ist besonders lehrreich: Lassen Sie dieselbe Komponente ein zweites Mal erzeugen und vergleichen Sie. Dasselbe Modell, derselbe Auftrag, ein anderes Ergebnis. Genau das ist der Grund für die eigene Prüfung.

19:34 Fünf Schritte. Der Auftrag mit Semantik, Tastatur, Namen und Fehlerzuständen — also die fünf Zeilen aus Kapitel sechs. Zusätzlich Tests und eine manuelle Prüfliste verlangen; das kostet nichts extra und liefert Ihnen die Selbstauskunft zum Gegenprüfen. Dann das Ergebnis mit Tastatur und Accessibility Tree prüfen. Dann jede Abweichung notieren, ohne sie sofort zu beheben — das ist die Disziplin, die den Lerneffekt trägt.

20:00 Und dann der eigentliche Punkt aus der Fußzeile: Nicht den Code reparieren, sondern den Auftrag. Denn der Code hilft einmal, der verbesserte Auftrag hilft bei jeder weiteren Komponente. Der erste Stolperstein ist der Reflex, gegen den die Übung gebaut ist: das Ergebnis von Hand nachbessern und den Auftrag unverändert lassen.

20:20 Beim nächsten Mal machen Sie dieselbe Nachbesserung. Der zweite ist eine Bequemlichkeit mit Risiko: die verlangte Prüfliste ungelesen übernehmen. Diese Liste ist eine Behauptung des Modells über sein eigenes Ergebnis — sie ist der Prüfgegenstand, nicht der Prüfbeweis. Und der dritte ist ein Umfangsfehler: nur prüfen, was im Auftrag stand.

20:41 Interessant ist gerade, was das Modell zusätzlich getan hat — überflüssiges ARIA etwa, oder eine erfundene Tastenkombination. Vier Punkte. Erklären lassen ist verlässlicher als erzeugen lassen, weil es widerlegbar ist — und weil es Wissen vermittelt, das bleibt. Der wirksamste Hebel ist der Auftrag, nicht die Nachbesserung; fünf konkrete Zeilen schlagen jedes Adjektiv.

21:04 Screenshot, DOM und Accessibility Tree tragen erst zusammen, weil die Befunde in den Abweichungen liegen. Und ein generierter Befund gilt erst, wenn ein Mensch ihn nachgeschlagen hat. Alles hier setzt auf den prüfbaren Kriterien aus Modul sechzehn auf — ohne sie gibt es nichts zu messen. Im nächsten Modul geben wir dem Werkzeug mehr Freiheit: Agenten, die selbst arbeiten.