Birte: Mein persönliches Highlight war der Talk „Design System for the Machines – How to Make AI Understand Your UI“ von Jennifer Wjertzoch (Senior Frontend Engineer bei DKB Code Factory). Die Kernidee dahinter ist, dass ein Design System sich nicht mehr nur an Menschen richtet. Auch Maschinen „lesen" unser UI wie z. B. unser KI-Assistent, der unseren Code versteht, weiter- und umbaut. Doch Maschinen lesen, anders als wir Menschen, nicht nur Texte, sondern Bausteine und ihre Bedeutung in der UI. Und dabei fehlen ihr regelmäßig drei Dinge:
Missing Meaning – Ein < div class="button" > ist für die KI erstmal nur ein div. Dass es ein Button sein soll, ist über die CSS-Klasse nicht erkennbar. Die Bedeutung fehlt.
Missing Behavior – Was tut das Element? Öffnen, umschalten, absenden? Wenn es nirgends steht, kann man nur interpretieren. Die Funktion fehlt.
Missing Intent – Warum ist das hier, was soll der Nutzer damit tun? Die Absicht fehlt.
An dieser Stelle erinnerte ich mich an das letzte Accessibility Meet Up Kiel. Die Lücke, über die KI stolpert, ist dieselbe, über die auch ein blinder/ sehbeeinträchtigter Mensch stolpert und weswegen Screenreader Informationen benötigen. Die Lösung dieses Talks war also kein Pitch für ein neues Tool, sondern Accessibility mit semantischer HTML ( < button >, < nav >, < main > statt div-Dschungel) und saubere ARIA-Labels und -Rollen, wenn die Semantik nicht ausreicht. Damit werden Meaning, Behavior und Intent maschinenlesbar – für die KI und Menschen mit einer Sehbeeinträchtigung. Dadurch wird barrierefreier Code eine Schnittstelle, die KI-Agenten und assistive Technologien gleichermaßen verstehen. In der Praxis bedeutete das am Montag nach der Konferenz für mich: Anstatt „irgendwann mal aufräumen“ jest-axe in die Pipeline geben. Dann prüft axe-core (von Deque) automatisiert auf fehlende Labels, falsche Rollen sowie Kontrastprobleme und lässt sich direkt in CI/CD einhängen. Jeder Merge wird so zum Accessibility-Check ohne manuelles Nachdenken.
Milan: Mein Highlight war der Talk: „Are Classical Automation Frameworks Dead? How AI Agents Are Transforming QA“ von Andrei Nutas (Technical Test Architect bei Atos). Hier wurden einige Probleme aus unserem Arbeitsalltag angesprochen: UI-Tests, die „flaky“ sind, also mal durchlaufen und mal fehlschlagen sowie „Selector Maintenance Tax“, der ständige Pflegeaufwand, wenn sich Selektoren in der Oberfläche ändern. Im Talk wurden drei Ansätze vorgestellt: das Full Agentic Testing, ein Hybrid-Modell und das „klassische“ manuelle Aufsetzen von Tests. Es hat mich nicht überrascht, dass ein hybrides Test-Modell empfohlen wurde und vor einem Testsystem, das immer mit KI-Agenten läuft, gewarnt wird und bei jedem Testlauf Tokens verbrannt werden. Im hybriden Test-Modell wurde gezeigt, wie klassische Frameworks wie „Playwright“ oder „Skyvern“ genutzt werden können, um sich selbstständig reparierende Tests zu schreiben. Schlägt ein Test fehl, müssen Entwickler:innen nicht direkt in die Logs schauen und die oft trivialen, aber schwer zu entdeckenden Fehler finden und beheben. Stattdessen springt nur in diesem Fall ein KI-Agent ein, löst das Problem, passt den Test entsprechend an (z. B. über eine editierbare Datenbank, die in der Pipeline verfügbar ist) und muss beim nächsten Durchlauf nicht mehr eingreifen. Dieser Prozess ist simpel genug, dass er sogar über lokale Modelle laufen könnte.
Thoren: Hängen geblieben ist bei mir vor allem der Talk: „You don't need to write the code. You need to become a verification architect and prove it's correct“ von Guillaume Moigneu (Field CTO bei Upsun). Die zentrale These: Der „10x-Entwickler“ der Agent-Ära ist nicht, wer zehnmal mehr Code schreibt, sondern wer zehnmal mehr Umfang definiert, verifiziert und ausliefert. Und Absicherung wird dabei vom Bremsklotz zum Geschwindigkeitsmultiplikator, denn je härter die Prüfmechanismen, desto mehr kann man den Agenten unbeaufsichtigt laufen lassen. Moigneu unterteilt hierfür: Verification (Haben wir es richtig gebaut?) wie Tests, Typen, Linting ist Maschinensache und im Idealfall voll automatisiert. Validation (Haben wir das Richtige gebaut?) prüft die Maschine gegen eine niedergeschriebene Intention. Wir sind verantwortlich, die Verifikations-Pipeline zu bauen, sodass am Ende der Human-in-the-loop (HITL) idealerweise nur noch für die Validierung zuständig ist.
Was mir an dem Talk gefallen hat: Er beschreibt den State of the Art gut und beinhaltet Erfahrungen sowie Probleme, die ich auch mit KI-Agenten gemacht habe und erklärt einen strukturierten, rekonstuierbaren Flow von Commit-Hooks bis Critic-Prompt. Einige dieser Ansätze fließen bereits in meinen Arbeitsalltag ein und genau daran merke ich, dass dieser Talk mehr war als eine gute halbe Stunde Programm.
