Umso erstaunter war ich, als mir kürzlich in einem ruhigen Moment auffiel, dass ich mich selbst im Arbeitsalltag erstaunlich selten daran halte. Und schlimmer noch: dass ich ziemlich gut darin geworden bin, mir das auch noch schönzureden.

Eisenhower ist aus meiner Sicht weiterhin ein sinnvolles Werkzeug – das ist mir wichtig vorwegzuschicken. Gleichzeitig stößt dieses Zeitmanagement-Modell aus der Mitte des 20. Jahrhunderts – entwickelt von einem US-General und späteren Präsidenten – im Arbeitsalltag moderner Wissensarbeiter erstaunlich schnell an seine Grenzen.

Dafür gibt es mehrere Gründe.

Kognitive Überlastung: Wenn zu viele Reize um Aufmerksamkeit konkurrieren

Wissensarbeiter – egal ob Fachspezialisten, Berater oder Entscheider – leiden heute weniger an fehlender Priorisierung als an kognitiver Überlastung. Die ständige Notwendigkeit, zwischen konzentrierter Arbeit an komplexen Fragestellungen und reaktiver Kommunikation zu wechseln, erzeugt Kontextwechselkosten (siehe auch [1]), die Fokus, Entscheidungsqualität und letztlich auch die eigene Zufriedenheit spürbar beeinträchtigen.

Die Eisenhower-Matrix verspricht an dieser Stelle eigentlich Orientierung, scheitert jedoch häufig an der psychologischen Realität der Illusion of Urgency [2]: Aufgaben fühlen sich dringend an, erzeugen Handlungsdruck und verlangen Aufmerksamkeit – ohne deshalb, um in der Sprache von Eisenhower zu bleiben, automatisch auch wichtig oder tatsächlich dringend zu sein.

Für mich hat sich daraus eine einfache, bewusst pragmatische Regel ergeben: Aufgaben, die sich in weniger als fünf Minuten erledigen lassen, versuche ich unmittelbar abzuschließen. Nicht aus Effizienzgründen im klassischen Sinne, sondern um kognitive Last zu reduzieren. Jede nicht beantwortete Rückfrage, jede angefangene, aber nicht abgeschlossene Kleinigkeit bleibt im Kopf präsent – und konkurriert dort mit eigentlich wichtigeren Themen um Aufmerksamkeit.

Das Problem: In meinem hochfragmentierten Arbeitsalltag gibt es überraschend viele „kurze Anfragen“. Und so schlägt die Fünf-Minuten-Regel bei mir erstaunlich oft Eisenhower.

Und ja, ich weiß: Man muss Mails und Chatnachrichten nicht sofort lesen. In der Theorie leuchtet mir das vollkommen ein. In der Praxis stressen mich 13 ungelesene Teams-Nachrichten jedoch zuverlässig. Disziplinierte Zeitfenster für Mail- und Chatkommunikation funktionieren für manche hervorragend. Für mich nicht. Und so stößt auch Eisenhower an seine Grenzen.

Kognitive Last der Organisation: Wenn zu viele Themen gleichzeitig offen sind

Nun ist kognitive (Über-)Last kein individuelles Versagen. Sie ist in vielen Fällen ein übergreifendes organisatorisches Problem. Organisationen arbeiten selten an einem Thema zur gleichen Zeit. Sie arbeiten an sehr vielen. Projekte, Initiativen, Abstimmungen, Eskalationen, strategische Themen und operative Kleinigkeiten laufen parallel – oft über Monate oder sogar Jahre. Jeder offene Vorgang erzeugt kognitive Last. Nicht nur bei Einzelpersonen, sondern im System insgesamt: in Meetings, Statusrunden, Entscheidungsprozessen oder auch nur, weil ich diese eine nervige Aufgabe nun schon zum dritten Mal in die Folgewoche verschiebe.

Diese systemische kognitive Last entsteht unabhängig davon, wie dringend oder wichtig ein einzelnes Thema gerade ist. Allein die Tatsache, dass etwas „noch offen“ ist, bindet Aufmerksamkeit. Ein psychologisches Fundament dieser Beobachtung liefert übrigens der Zeigarnik-Effekt, der besagt, dass uns unterbrochene, unerledigte Aufgaben kognitiv stärker beschäftigen als abgeschlossene [4]. Das kostet Energie – selbst dann, wenn faktisch gerade niemand daran arbeitet.

Ein besonders plastisches Beispiel dafür habe ich im behördlichen Umfeld erlebt. Eine Broschüre sollte aktualisiert werden – kein besonders dringendes Thema, von mittlerer Wichtigkeit. Der erste Entwurf war schnell erstellt. Danach passierte lange Zeit: nichts. Aufgrund interner Prozesse mussten verschiedene Einheiten involviert werden, zwischen den einzelnen Abstimmungen lagen jeweils mehrere Wochen.

Das Ergebnis? Ein Prozess über 20 Monate. Durch unzählige Abstimmungsrunden und Liegezeiten musste sich jeder Beteiligte in jedem Termin neu eindenken („Wo standen wir nochmal?“). Am Ende wurde konservativ geschätzt mindestens das Zehnfache der eigentlichen Arbeitszeit investiert, nur weil das Thema immer wieder liegen blieb. Ein klassisches Beispiel dafür, wie „nicht dringende“ Themen durch reinen Zeitverzug zu hocheffizienten Ressourcenfressern mutieren.

Die Eisenhower-Matrix betrachtet Aufgaben isoliert. Sie hilft dabei, einzelne To-dos zu priorisieren. Was sie jedoch systematisch ausblendet, ist die kumulative Wirkung vieler paralleler, offener Themen auf eine Organisation.

In der Praxis ist es oft nicht das einzelne wichtige oder dringende Thema, das überlastet – sondern die schiere Anzahl an offenen Baustellen. Aus einer Lean-Perspektive ist es deshalb sinnvoll, die Anzahl gleichzeitig offener Themen möglichst gering zu halten. Nicht nur, um schneller zu werden, sondern um arbeitsfähig zu bleiben.

Genau hier beginnt ein Aspekt, den Eisenhower nur unzureichend adressiert: Offene Themen sind nicht neutral. Sie sind nicht einfach „noch nicht dran“. Sie erzeugen Kosten – allein durch ihr Liegenlassen.

Cost of Delay: Wenn Liegenlassen teuer wird

Wenn man genau hinschaut, habe ich im obigen Behördenbeispiel bereits ein Konzept verwendet, ohne es zu benennen: Cost of Delay.

Nicht die (gefühlte und meist sehr subjektive) Wichtigkeit einer Aufgabe entscheidet über ihre Priorität, sondern die Kosten, die entstehen, wenn sie nicht umgesetzt wird. Diese Kosten sind oft nicht sichtbar – aber sie sind real.

Ein einfaches Beispiel: Ein kurzes Debriefing zu einem Konferenzbesuch an Kollegen zu schicken, ist selten dringend und meist auch nicht besonders wichtig. Während der Zugfahrt nach Hause ist das in wenigen Minuten erledigt. Zwei Wochen später brauche ich dafür schon deutlich länger. Zwei Monate später muss ich anhand meiner Notizen rekonstruieren, was ich eigentlich mitteilen wollte.

Die Aufgabe ist dieselbe geblieben – der Aufwand nicht. Die Verzögerung hat hier keinen inhaltlichen Mehrwert erzeugt, sondern ausschließlich zusätzliche Arbeit. Genau das beschreibt Cost of Delay.

In Organisationen wirkt dieser Effekt noch stärker. Der eigentliche Cost of Delay entsteht häufig nicht durch fehlende Umsetzung, sondern durch das Wiederanlaufen: sich erneut einlesen, Kontexte rekonstruieren, Entscheidungen erklären, Abhängigkeiten neu klären. Je länger ein Thema liegt, desto höher werden diese Reibungsverluste. Besonders schön wird es dann, wenn Nachfragen nach dem Stand einer Aufgabe und ein oder zwei Feedbackschleifen in Summe bereits mehr Zeit kosten als die eigentliche Erledigung.

Eisenhower hilft dabei zu entscheiden, was wichtig und dringend ist. Cost of Delay macht sichtbar, was es kostet, nichts zu entscheiden – und Themen immer wieder liegen zu lassen.

Mir ist bewusst, dass Cost of Delay ein abstrakter Begriff bleibt. Mir hilft dieser Perspektivwechsel jedoch sehr, meine Arbeitsprioritäten besser zu setzen. Übliche Dimensionen, die meinen höchst persönlichen Cost of Delay ausmachen, sind:

• der erwartete Mehrwert des Arbeitspakets (strategisch, operativ oder risikoseitig)
• Effizienz- und Reibungsverluste über die Zeit (Wiederanlauf, Abstimmung, Kontextverlust)
• die Möglichkeit, Themen sauber abzuschließen und damit kognitive Last zu reduzieren
• Lernen und Wissensgewinn – oder dessen Verzögerung

Ob ich eine Aufgabe selbst erledige oder delegiere, beantwortet Cost of Delay allerdings nicht. Aber dazu kommen wir im kommenden Abschnitt.

Verteilte Verantwortung: Wenn klassische Delegation an Grenzen stößt

Die Eisenhower-Matrix ist in einer Welt klarer Hierarchien entstanden. Aufgaben werden priorisiert, erledigt oder delegiert. Delegation setzt dabei etwas voraus, das lange selbstverständlich war: eine eindeutige hierarchische Ordnung mit klarer Weisungsbefugnis.

In der Sprache von Reinventing Organizations [5] würde man sagen: Eisenhower passt hervorragend zu bernsteinfarbenen, stark hierarchischen Organisationen. Führung bedeutet dort, Entscheidungen zu treffen und Aufgaben weiterzugeben.

Viele Organisationen funktionieren heute jedoch anders. Wir sprechen über flache Hierarchien, selbstorganisierte Teams, laterale Führung und Servant Leadership. Verantwortung liegt nicht mehr ausschließlich bei einzelnen Rollen, sondern verteilt sich auf Teams. Entscheidungen werden gemeinsam getroffen, Aufgaben gemeinsam getragen.

In solchen Strukturen wird Delegation unscharf. An wen delegiere ich, wenn Verantwortung im Team liegt? Was bedeutet „abgeben“, wenn ich fachlich gar nicht weisungsbefugt bin? Und was passiert, wenn Delegation nicht als Entlastung, sondern als Abschieben wahrgenommen wird?

Gleichzeitig verstehen sich viele Organisationen zunehmend als lernende Systeme. Aufgaben sind nicht nur Mittel zur Zielerreichung, sondern auch Gelegenheiten zur Entwicklung. Konzepte wie Management 3.0 [6] betonen genau diesen Aspekt: Arbeit dient nicht nur der Effizienz, sondern auch dem Lernen, der Motivation und dem Kompetenzaufbau von Mitarbeitern.

Damit wird Delegation zu einer Führungsentscheidung mit mehreren Dimensionen. Nicht jede Aufgabe, die delegierbar wäre, sollte delegiert werden. Und nicht jede Aufgabe, die belastet, lässt sich sinnvoll abgeben. Eisenhower gibt darauf keine Antworten – weil er diese Organisationslogik schlicht nicht kennt.

Fazit: Eisenhower reicht nicht mehr – aber er bleibt hilfreich

Die Eisenhower-Matrix ist kein schlechtes Werkzeug. Sie hilft, innezuhalten, Aufgaben bewusst zu betrachten und sich nicht von jeder Dringlichkeit treiben zu lassen. Das allein ist viel wert.

In meinem Arbeitsalltag reicht sie jedoch nicht mehr aus. Kognitive Überlastung, systemische Reibung, Cost of Delay und veränderte Organisationsformen lassen sich nicht sauber in vier Quadranten pressen. Dafür sind moderne Wissensorganisationen zu komplex – und Arbeit zu stark von Kontext, Abhängigkeiten und Lernen geprägt.

Was mir heute hilft, ist kein Ersatz für Eisenhower, sondern eine Ergänzung: der bewusste Blick auf Liegezeiten, auf kognitive Last – und auf die Frage, was es mich und die Organisation kostet, Dinge nicht zu entscheiden.

Eisenhower hilft mir weiterhin bei der Orientierung. Die eigentliche Priorisierung entsteht jedoch erst im Zusammenspiel aus Kontext, Verantwortung und Cost of Delay. Am Ende bleibt die Erkenntnis: Ein Werkzeug ist eben nur ein Werkzeug. Mit einem Hammer lässt sich vieles erledigen – aber nicht alles im modernen Arbeitsalltag ist ein Nagel.

Referenzen

[1] Multitasking: Switching Costs – https://www.apa.org/topics/research/multitasking 
[2] The Illusion of Urgency –  https://pmc.ncbi.nlm.nih.gov/articles/PMC10159458/ 
[3] Mintzberg, H. (1973). The nature of managerial work.
[4] Zeigarnik-Effekt – https://de.wikipedia.org/wiki/Zeigarnik-Effekt 
[5] Reinventing Organisations – https://www.reinventingorganizations.com/ 
[6] Management 3.0 – https://management30.com/ 

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Die Webentwicklung verändert sich rasant – aktuell vor allem durch neue Frontend-Paradigmen und den zunehmenden Einsatz von AI-gestütztem Coding. Genau deshalb war die c’t webdev conference Mitte November im KOMED im MediaPark in Köln für mich mehr als nur ein Pflichttermin.

Zwei Tage lang trafen sich dort Frontend-Entwickler:innen, die sich intensiv mit Themen wie UI/UX, modernen JavaScript-Frameworks und neuen Ansätzen wie Vibe Coding und AI Agents beschäftigten. Der klare fachliche Fokus, die Tiefe der Vorträge und der direkte Austausch auf Augenhöhe machten schnell klar: Die Konferenz richtet sich nicht an Neugierige, sondern an echte Praktiker:innen. Die Organisation war top und das Catering im KOMED hervorragend – ideale Voraussetzungen für konzentriertes Networking und Lernen.

Doch was die c’t webdev wirklich auszeichnet, war die spezifische Zielgruppe: Es handelte sich um eine klare Frontend-Konferenz. Das Publikum war tief in den Themen UI/UX, Coding mit AI Agents, Vibe Coding und den aktuellen JavaScript-Frameworks (React, Angular, Vue) verwurzelt. Hier traf man auf gleichgesinnte Frauen und Männer, die nicht nur auf der Suche nach Inspiration waren, sondern auch den tiefen fachlichen Austausch suchten. Der Vibe stimmte sofort, was eine ideale Basis für die kommenden Vorträge legte.

Tag 1: Über AI Autopilots, Architektur und granularem State-Management

Keynote: Von Copilot zu Autopilot

Der Tag begann mit einer fesselnden Keynote von Daniel Sogl, der uns mitnahm auf die Reise „From Copilot to Autopilot – How AI Coding Tools Are Transforming the Developer Role“. Der Vortrag war mehr als eine Bestandsaufnahme; er war eine Aufforderung, die neue Realität kritisch zu hinterfragen.

Sogl präsentierte eindrucksvolle Statistiken zur Adoption von AI-Tools, wobei 84 % der Entwickler sie bereits nutzen oder planen zu nutzen, und 51 % sie täglich verwenden. Diese Tools versprechen echte Produktivitätssteigerungen, wie z. B. eine um 55,8 % schnellere Aufgabenerledigung in kontrollierten Studien und eine Reduzierung der täglichen Arbeitszeit um 56 Minuten.

Der zentrale Weckruf kam mit dem Trust Paradox: Während Syntax-Fehler dank AI um bis zu 76 % reduziert werden, steigt das Risiko für tiefer liegende, architektonische Probleme signifikant an. Berechtigungsprobleme (+322 %) und Architekturmängel (+153 %) sind laut Sogl keine Seltenheit. Diese Zahlen haben mich am meisten überrascht und bestätigen meine Skepsis: AI erzeugt „saubereren“ Code, verleitet aber zur Vernachlässigung der architektonischen Kontrolle.

Die Quintessenz des Vortrags: Die Entwicklerrolle wandelt sich vom reinen Coder zum Orchestrator und Strategen. Die Zukunft liegt in der Spec-Driven Development (SDD), bei der wir die Spezifikationen klar vorgeben, bevor die AI den Code generiert. Genau hier liegt für mich eine der großen Herausforderungen der nächsten Jahre: Wir müssen uns stärker als je zuvor auf die architektonische Planung und saubere Anforderungsanalyse konzentrieren, um die AI als präzises Werkzeug zu führen, statt uns von ihren zufälligen ‚Vibes‘ treiben zu lassen.

​

Das Highlight von Tag 1: Signals in Depth

Nach der strategischen Keynote, die den Rahmen für die Zukunft der Entwicklerrolle setzte, tauchten wir am späten Vormittag tief in die Frontend-Architektur ein. Mein persönliches Highlight von Tag 1 war ein Vortrag, der zeigte, wie die modernen Frameworks das Kernproblem der Webentwicklung – die Reaktivität – endlich effizient lösen: „Signals in Depth – How reactivity works in many frontend frameworks“ von Garrelt Mock.

Mock erklärte anschaulich die Schwächen traditioneller Reaktivitätsansätze: das „Dirty Checking“ (bekannt aus älteren Angular-Versionen mittels Zone.js) und das Virtual DOM (VDOM) Diffing in React. Diese Methoden, obwohl funktional, verursachen oft Performance-Overhead und unnötige Rechenzyklen, da unnötig große Teile der Komponenten neu gerendert werden, selbst wenn sich nur ein kleiner Datenpunkt geändert hat.

Die Lösung liegt in Signals, die auf einem granularen Observer-Pattern basieren: Ein Signal weiß genau, welche UI-Teile oder Effekte von ihm abhängen. Bei einer Änderung wird nur dieser spezifische abhängige Effect aktualisiert, nicht die gesamte Komponente.

Für mich war dieser Vortrag die wichtigste technische Erkenntnis des Tages. Die Eleganz und Effizienz, mit der Signals die Notwendigkeit für komplexe Mechanismen wie Zone.js oder VDOM-Diffing eliminieren und Frameworks wie SolidJS, Preact und das neue Angular schneller und speichereffizienter machen, ist ein klarer Hinweis auf einen Paradigmenwechsel im State-Management. Die Frontend-Architektur wird sich dadurch grundlegend vereinfachen – ein Muss für jede skalierbare Anwendung in den kommenden Jahren.

Der Rest des ersten Tages: Von AI-Agents bis zur Frontend-Architektur

Neben Keynote und Signal-Tiefgang bot der erste Konferenztag eine spannende Bandbreite an Themen, die die aktuellen Herausforderungen und Trends in der Frontend-Welt widerspiegelten.

AI-Driven Development: Sebastian Springer beleuchtete in seiner Session „AI Agents Beyond Simple Chatbots“ die Entwicklung komplexer, autonomer AI-Lösungen und proaktiver Assistentensysteme, die weit über einfache LLM-Chat-Interfaces hinausgehen. Er zeigte Frameworks wie LangChain, mit denen man AI-Agents befähigen kann, reale Probleme zu lösen und mehrstufige Workflows zu automatisieren.

Architektur und Skalierung: Der Vercel-Partner-Talk „From Monolith to Microfrontends: Choosing the Right Architecture…“ von Yi Min Yang lieferte einen praktischen Leitfaden zu modernen Frontend-Architektur-Patterns. Er diskutierte alles von Monorepos (z.B. mit Turborepo) bis Microfrontends und präsentierte ein klares Entscheidungs-Framework, um die passende Architektur für Teamgröße und technische Anforderungen zu finden. Sehr interessant zu sehen, wie man auch step-by-step Architekturen modernisieren kann.

Qualität und Metriken: Richard Gross erklärte unter dem Titel „Making sense of frontend code with forensic techniques“, wie man mithilfe von Tools wie CodeCharta und CodeGraph die Code-Qualität und Architektur in Projekten mit hunderttausenden Zeilen analysiert. Darüber hinaus zeigte Eva Feigl in „Beyond clicks: Measuring UX, outcomes and real product success“ auf, wie man Produkt-Telemetrie und qualitative Nutzerforschung kombiniert, um wirklich verwertbare UX-Metriken zu erhalten und den Produkterfolg zu validieren.

Tag 2: Menschliche Empathie und AI-Strenge 

Keynote: Nobody needs UX – Die Unverzichtbarkeit der Empathie

Der zweite Konferenztag begann mit einer provokanten und nachdenklich stimmenden Keynote von Vicky Pirker mit dem Titel „Nobody needs UX“.

Pirker nutzte diesen vermeintlich paradoxen Titel, um die Essenz von User Experience (UX) in Zeiten der schnellen AI-Entwicklung neu zu definieren: Es braucht nicht den Begriff UX, sondern die menschliche Haltung dahinter. Schlechte UX führt zu Frustration und Ablehnung, wie sie eindrücklich zeigte.

Besonders relevant war die Diskussion im Kontext der AI-Revolution. Ihre klare Schlussfolgerung: User Experience bleibt menschzentriert, und KI dient lediglich als unser Sidekick. Die Aufgabe der Entwickler und Designer ist es, die Vision zu formen und die Nutzer zu begeistern.

Für mich war der Fokus auf die Empathie der wichtigste Takeaway. Während KI gut darin ist, bekannte UX-Schemata und Design-Regeln zu erlernen und perfekt umzusetzen, bleibt die Fähigkeit, sich tief in den User hineinzufühlen – also die Wünsche und emotionalen Reaktionen vorherzusehen – eine zutiefst menschliche Leistung. Dieser Mangel an Empathie kann aber zum Problem werden, wenn KI versucht, UX komplett zu übernehmen. Daher muss die menschliche Perspektive, die qualitative Nutzerforschung und Empathie stets die letzte Kontrollinstanz bleiben.

Das Highlight von Tag 2: EXACT Coding gegen den „Vibe“

Die Keynote von Vicky Pirker stellte klar: Der Mensch muss die ethische und empathische Kontrolle behalten. Der darauf folgende Vortrag „AI-Powered Development Vibe Code Doesn’t Work!“ von Marco Emrich und Ferdinand Ade lieferte die technische Methodik dazu. Sie äußerten eine klare Kritik am unstrukturierten „Vibe Coding“ (generieren, akzeptieren, nicht prüfen) und belegten, dass dieser Ansatz – obwohl schnell – zu unsauberen und unsicheren Codebasen führt.

Ich sehe Vibe Coding als einen effizienten Weg für schnelles Prototyping und Proof-of-Concepts; man erhält in kürzester Zeit gute, lauffähige Ergebnisse. Doch für Production-Ready Code ist dieser Ansatz meiner Meinung nach untauglich.

Die Lösung der Sprecher war EXACT Coding, ein Ansatz, der die besten Seiten der AI mit der Disziplin etablierter Methoden kombiniert. EXACT Coding basiert auf EXample-Guided Ai-CollaboraTive.

Das ist die Essenz für professionelle Softwareentwicklung: Bevor die AI überhaupt mit dem Codieren beginnt, müssen wir als Software Engineers in unseren Teams die Anforderungen und Spezifikationen klar erfassen und visualisieren. Der Mensch (Human-in-the-Loop) definiert das „Was“ durch die Beispiele und Tests; die AI übernimmt die Implementierung.

Der größte Vorteil dieser Methodik ist die Qualitätssicherung der Architektur: Indem wir uns zuerst auf Spezifikationen und die „Red“-Phase des TDD-Zyklus konzentrieren, zwingen wir die KI, in einem engen, validierten Rahmen zu arbeiten. Das beugt nicht nur Syntaxfehlern vor, sondern verhindert auch das Auseinanderdriften von Code und Gesamtarchitektur. Nur so stellen wir sicher, dass wir nicht nur Code schreiben, sondern nachhaltige, wartbare Software entwickeln und dabei niemals das große Ganze aus dem Auge verlieren.

Weitere Highlights an Tag 2: Reaktivität, Testing und Agenten-Interfaces

Auch abseits der Keynote und des AI-Vortrags lieferte Tag 2 wertvolle Inhalte, die sich tief mit den technischen Details der modernen Frontend-Entwicklung beschäftigten:

Standardisierung von AI-Interfaces: Max Marschall stellte in seinem Vortrag „AG-UI & MCP: Standardizing Agentic Web Interfaces“ zwei neue Protokolle vor: AG-UI (Agent-User Interaction Protocol) und MCP (Model Context Protocol). Diese zielen darauf ab, die Interaktion zwischen intelligenten Agents und modernen Web-Frontends zu standardisieren und modularer, testbarer und verständlicher zu gestalten.

Test-Qualität: Marco Emrich leitete die interaktive Session „How valuable are your tests?“. Er präsentierte die „Four Pillars of a Good Test“ von Vladimir Khorikov, um Kriterien für eine objektive Bewertung des Nutzens von Tests zu schaffen und so eine fundierte Diskussion über Teststrategien zu ermöglichen.

Accessibility in Komponenten: Und natürlich das beinahe-Highlight „Accessible Web Components“ von Anna Maier. Sie lieferte einen wichtigen Einblick, wie man technische Fallstricke des Shadow DOM vermeidet, um die Barrierefreiheit von Komponenten von Anfang an zu gewährleisten, und betonte die Notwendigkeit, dies auch im Produktkontext zu testen und zu dokumentieren.

Fazit: Eine lohnende Investition in die Frontend-Zukunft

Die zwei Tage auf der c’t webdev conference im Kölner MediaPark waren für mich eine absolut lohnende Investition. Die Konferenz lieferte nicht nur einen umfassenden Überblick über die aktuellen Tools und Frameworks (von Signals bis React Fullstack), sondern beleuchtete vor allem die strategischen und methodischen Herausforderungen der Branche. Der Fokus lag klar auf der Zukunft der Entwicklerrolle: Wir bewegen uns vom reinen Code-Schreiber hin zum Orchestrator, der AI strukturiert einsetzt und dabei die menschliche Urteilsfähigkeit (Human Judgement) behält.

Die wichtigste Erkenntnis: Der Mensch bleibt die Kontrollinstanz

Die entscheidenden Takeaways liegen für mich in der methodischen Disziplin und Empathie. Wir haben gelernt, dass wir AI nicht blind vertrauen dürfen (Stichwort: Trust Paradox bei Architekturmängeln), sondern dass unser menschliches Urteilsvermögen und die Fähigkeit zur Empathie die unverzichtbaren Kontrollinstanzen bleiben.

Networking und Empfehlung

Abgesehen vom Inhalt war die Atmosphäre auf der Konferenz herausragend. Die Teilnehmer:innen waren sehr freundlich und offen für einen fachlichen Austausch, was das Networking sehr erleichtert hat.

Ich kann die c’t webdev conference definitiv uneingeschränkt weiterempfehlen, da sie wertvolle Beiträge und tiefgreifende Infos aus der Tech-Branche im Bereich Frontend liefert. Die Konferenz richtet sich an diejenigen, die wissen wollen, wie man die Zukunft baut, nicht nur, wie man sie benutzt. Ob ich im nächsten Jahr wieder dabei bin, steht noch offen – schließlich soll man als Entwickler auch mal über den Tellerrand hinausschauen. Aber die Impulse aus Köln sind gesetzt und werden meine Arbeit nachhaltig prägen.

Als technologieagnostische Konferenz bietet das SAG weniger Deep Dives, dafür aber einen breit gefächerten und gut zugänglichen Überblick über den aktuellen „Architektur-Mainstream“ in Deutschland. Man trifft viele bekannte Gesichter und das Programm ist üblicherweise mit namhaften nationalen wie internationalen Sprecherinnen und Sprechern besetzt. In diesem Jahr etwa mit Bernd Ruecker (Co-Founder Camunda, mit – Überraschung – einem halben, aber sehr sympathischen Werbevortrag), Cheryl Hung (ehem. CNCF), Alistair Cockburn (Mitautor des Agilen Manifests) oder Gregor Hohpe (dessen launisch-meinungsstarke Vorträge ich seit jeher mag).

Der Nachteil dieser breiten und bewusst agnostischen Ausrichtung liegt allerdings auf der Hand: Viele Themen bleiben eher an der Oberfläche. Auch in diesem Jahr gab es ausschließlich Talks der Kategorien „Beginner“ und „Intermediate“ – wirklich neue Erkenntnisse sind dementsprechend selten.

Wir waren dennoch vor Ort – und möchten im Folgenden ein paar Eindrücke teilen.

Themenlandschaft: weniger AI-Dominanz als erwartet

Ein Blick auf die Agenda brachte die erste Überraschung. Trotz ordentlicher Präsenz war AI nicht erdrückend dominant – für eine Architekturkonferenz zur aktuellen Zeit fast wohltuend. „Nur“ ungefähr jeder sechste Talk drehte sich explizit um die Themen AI, wobei natürlich sehr viele Sessions das Thema zumindest gestreift haben. Im Sprachgebrauch des Gartner Hype Cycle sind wir nun wohl endgültig über den Peak of Inflated Expectations hinaus und arbeiten uns langsam, aber sicher, hin zu wirklichen und nachhaltigen Use Cases.

Statt GenAI waren sozio-technologische Fragestellungen oder auch der Dauerbrenner DDD in diesem Jahr wieder deutlich präsenter.

Auch Green IT, ein Thema, von dem ich mir vor drei bis vier Jahren eine dauerhafte Etablierung erhofft hatte und das spätestens vom energieverschlingenden GenAI-Hype ein wenig in den Hintergrund gedrängt worden ist, war (für mich) überraschend präsent. Letzteres mag damit zu tun haben, dass das iSAQB seit vergangenen Jahr ein neues Modul „Green IT“ in seiner Advanced-Zertifizierung anbietet [1].

Vibe Coding, Verantwortung und Plattformarchitektur

Unter den Vorträgen ist mir der Talk „Vibe Coding Auth Without Melting Down!“ von Cheryl Hung besonders in Erinnerung geblieben [2]. Er ging der Frage nach, ob sich auch fehlerintolerante Bereiche wie Authentifizierung mittels Vibe Coding lösen lassen. Die Antwort: It depends. In ihrem Beispiel zeigte sie eine mit Claude Code generierte Authentifizierungslösung, die funktional war, aber typische handwerkliche Anfängerfehler enthielt – etwa die Verwendung veralteter Hash-Bibliotheken oder das unbeabsichtigte Leaken von Nutzerinformationen [3]. Das deckt sich sehr mit meinen eigenen Erfahrungen: Vibe Coding liefert einen erstaunlich brauchbaren, aber eben nicht fehlerfreien Ausgangspunkt [4].

Spannend war allerdings weniger der Code selbst, sondern Cheryls Vorgehen: Sie hat die Sicherheitslücken nicht eigenhändig gesucht, sondern Claude Code im einmal generierten Code gezielt nach Schwachstellen analysieren lassen – eine Vorgehensweise, die in der Praxis zunehmend eingesetzt wird [5]. Einerseits nicht unerwartet, andererseits irgendwie faszinierend – das LLM „weiß“ grundsätzlich von diesen Schwachstellen, muss aber erst in die richtige Richtung geleitet werden.

Damit bleibt Vibe Coding für mich auf einem Niveau, das signifikante Geschwindigkeitsvorteile ermöglicht – solange man den Leitsatz beachtet: Never vibe code an app you wouldn’t be able to code yourself. Ob das im Startup-Kontext immer beherzigt wird? We will see…

Als möglichen Lösungsansatz griff Cheryl das Konzept Shift Down Security auf. Während Shift Left als etabliertes Prinzip die frühzeitige Verlagerung von Verantwortung – etwa für Qualität, Tests, Sicherheit oder Architektur – in die Entwicklungsteams und in die frühe Phase des Entwicklungsprozesses beschreibt, setzt Shift Down an einer anderen Stelle an: Statt Verantwortung weiter nach vorne zu schieben, wird sie bewusst nach unten, also auf Plattform- und Infrastruktur-Level, verlagert [6][7].

Dort werden Sicherheitsmechanismen technisch und organisatorisch verankert – etwa durch vordefinierte, abgesicherte Base Images, verpflichtende Policies, vorstrukturierte Toolchains oder Plattform-Guardrails, die bestimmte Fehler (menschliche wie maschinelle) gar nicht erst zulassen. Dieser Gedanke deckt sich stark mit dem Prinzip sogenannter Enabling Constraints: Bedingungen, die nicht einschränken, sondern Qualität und Sicherheit gezielt ermöglichen [8].

Ein Konzept, das sowohl menschlichen als auch KI-basierten Entwicklerwerkzeugen hilft, typische Fehler gar nicht erst entstehen zu lassen. Und noch dazu ein netter Querverweis zum Talk von Michael Mahlberg war, in welchem Enabling Constraints eine wichtige Rolle einnehmen [9].

Der Übergang von Vibe Coding zu Shift Down war für meinen Geschmack etwas abrupt, zumal die gezeigten Authentifizierungsfehler kaum über Plattformmechanismen lösbar gewesen wären. Trotzdem ein sehr gelungener Talk mit einem prägnanten Beispiel sowie einem für mich neuen und interessanten Konzept.

Hexagons, Ports & Adapter

Auch der Vortrag von Alistair Cockburn zur hexagonalen Architektur [10] – laut ihm selbst eine der drei schlimmsten Benennungen von Architekturkonzepten überhaupt – war eine der Sessions, die gleichzeitig unterhaltsam, temporeich und technisch fundiert waren. Zum einen ist es schlicht faszinierend, den Urheber eines Architekturstils über Historie, Motivation und ursprüngliches Designziel sprechen zu hören. Zum anderen hat Alistair den Vortrag sehr geschickt mit konkreten Implementationsbeispielen aus unterschiedlichen Sprachen kombiniert.

Allein das Tempo machte den Talk für mich zum anspruchsvollsten Vortrag, den ich die Tage gehört habe – und damit zur willkommenen Abwechslung zu den insgesamt sehr gut gemachten, aber oft sehr einsteigerorientierten Sessions. Ein einzelnes fachliches Learning würde ich rückblickend gar nicht herausgreifen. Stattdessen hat sich mein Eindruck bestätigt, dass Port-&-Adapter-Architekturen zu den Stilformen gehören, mit denen sich jede Entwicklerin und jeder Architekt ernsthaft beschäftigt haben sollte (und spätestens dann versteht, wie ich von Hexagons zu Ports & Adaptern komme).

Fazit: Vor allem eine gute Orientierung

Was bleibt für mich am Ende vom SAG? Am Ende war es inhaltlich zumeist nicht revolutionär, aber durchaus wertvoll. AI war präsent, DDD sowieso – und manche Konzepte wirken erstaunlich robust gegenüber Hype-Zyklen. Vielleicht ist genau das der eigentliche Reiz des SAG: Man nimmt selten ein einzelnes atemberaubendes Konzept mit nach Hause, aber jedes Jahr ein etwas klareres Verständnis davon, warum sich bestimmte Ideen in der Architektur so hartnäckig halten. Und vielleicht reicht das völlig.

Referenzen

1. iSAQB Advanced Level Module – Green IT
   https://isaqb.org/certifications/advanced-level/green-it/ 
2. Keynote: Vibe Coding Auth Without Melting Down!
   https://conferences.isaqb.org/software-architecture-gathering/session/keynote-vibe-coding-auth-without-melting-down/ 
3. Cheryl Hung – Vibe Coding Auth Without Melting Down (Slides)
   https://www.slideshare.net/slideshow/cheryl-hung-vibe-coding-auth-without-melting-down-isaqb-software-architecture-gathering-2025-pdf/284317660 
4. Ein halber Tag im Leben eines Vibecoders
   https://dev.atra.consulting/engineering/ein-halber-tag-im-leben-eines-vibecoders 
5. Passing the Security Vibe Check: The Dangers of Vibe Coding
   https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding 
6. Shift-Down Security (SIG-Security Working Paper)
   https://raw.githubusercontent.com/kubernetes/sig-security/main/sig-security-docs/papers/shift-down/shift-down-security.md 
7. What is Shift-Down Security?
   https://nirmata.com/2024/09/13/what-is-shift-down-security/ 
8. The Magic Power of Enabling Constraints
   https://www.scrum.org/resources/blog/magic-power-enabling-constraints
9. Now We’ve Given Them Every Freedom – and They Still Don’t Do What We Want
   https://conferences.isaqb.org/software-architecture-gathering/session/now-weve-given-them-every-freedom-and-they-still-dont-do-what-we-want/ 
10. The Hexagonal or Ports & Adapters Architecture
    https://conferences.isaqb.org/software-architecture-gathering/session/the-hexagonal-or-ports-adapters-architecture/
    

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Wie holen wir das Beste aus unseren Java-Anwendungen heraus? Zu diesem Thema gab Karsten Silz bei uns im Stuttgarter Office einen tiefen Einblick in die aktuellen Möglichkeiten der Performance-Optimierung.

Gerade in Zeiten von Serverless Computing und Microservices ist die Startzeit von Java-Anwendungen ein kritischer Faktor. Karsten zeigte uns anschaulich die Bandbreite der Möglichkeiten auf – vom einfachen Spring Boot Tuning über Class Data Sharing (CDS) und Project Leyden bis hin zu Project CRaC und GraalVM Native Image.

Besonders wertvoll war dabei der Blick auf die Wirtschaftlichkeit: Nicht jede technische Optimierung rechnet sich am Ende auch betriebswirtschaftlich.

Wer den Vortrag verpasst hat oder tiefer in die technischen Details, Benchmarks und ROI-Berechnungen einsteigen möchte, findet alle Informationen, Folien und Beispiel-Code direkt in Karstens Zusammenfassung.

Timo Kaiser

Senior Software Engineer

Timo ist ein erfahrener Webentwickler mit über 15 Jahren Projekterfahrung, insbesondere in der Umsetzung moderner, barrierefreier Frontends auf Basis von Angular, TypeScript, HTML und SCSS. Sein Schwerpunkt liegt auf der Entwicklung skalierbarer, wartbarer und zugänglicher Webanwendungen.

Als Lead Developer verantwortet er in Projekten die technische Umsetzung, Architekturentscheidungen sowie die kontinuierliche Optimierung der User Experience. Timo ist Ansprechpartner für technische und methodische Fragen, übersetzt Anforderungen in strukturierte Sprints und Git-Workflows und sorgt durch Code-Reviews, Pairing und Coaching für hohe Qualität und Effizienz im Team. Er arbeitet eng mit Design- und UX-Teams zusammen und bringt seine gestalterische Erfahrung auch in Tools wie Figma oder Adobe XD ein.

t.kaiser@atra.consulting    

• LinkedIn

Retrospektiven gelten als Herzstück agiler Teams – doch was, wenn sie sich nur noch wie ein weiteres Meeting anfühlen? In diesem Artikel schildere ich, wie ich selbst in die Falle der „Retro Fatigue“ getappt bin, welche Muster mir dabei aufgefallen sind und wie wir Retros wieder zu echten Räumen für Verbesserung machen können. 

Beruflich gesprochen bin ich mit agiler Softwareentwicklung groß geworden. Als ich 2017 meine ersten Schritte bei einer großen deutschen Traditionsversicherung machte, waren hippe Agile-Trainingscenter mit Kickertisch und Gratiskaffee sowie der Trend zu autonomen Teams mit mehr Freiheitsgraden selbst dort längst angekommen. Und was soll ich sagen? Vielleicht lag es auch an meiner ersten Führungskraft, die noch eher vom Typ „Excelliste & Rapport-Planung“ war – aber ich war sofort fasziniert von der agilen Denkweise, die motivierte Individuen und ein funktionierendes Produkt in den Mittelpunkt stellt. Vom ersten Tag an hätte ich mich wohl als Agilist bezeichnet – ohne den Begriff überhaupt zu kennen.

Auch heute noch begeistern mich Konzepte wie Modern Agile, und in meinen Projekten übernehme ich gelegentlich agile Rollen. Umso erstaunter war ich, als ich kürzlich feststellte: Ich freue mich nicht mehr auf meine Retrospektive. Im Gegenteil – der zweiwöchentliche Termin fühlte sich zunehmend wie eine lästige Pflichtaufgabe an. Wäre ich als Agile Master nicht qua Rolle der Hüter der Retro gewesen – ich hätte sie wohl abgesagt.

Dabei halte ich es eigentlich mit Woody Zuill, der sagte:

„If you adopt only one agile practice, let it be retrospectives. Everything else will follow.“

Wie konnte es soweit kommen? Wie wurde aus dem vielleicht wichtigsten Ritual der agilen Welt eine Routine, die ich (und vermutlich große Teile des Teams) als wenig wertvoll empfand?

Eins vorweg: Nicht jede Retro war schlecht. Es gab großartige Diskussionen und wertvolle Impulse für Verbesserungen. Und ja, vermutlich habe ich mich im operativen Tagesgeschäft manchmal zu sehr verfangen und Inspect & Adapt nicht immer priorisiert.

Aber dennoch … die Retros fühlten sich oft wie eine Pflichtübung an. Wie kam es zu dieser Retro Fatigue? Und was kann man dagegen tun?

Inspect ohne Adapt

Es beginnt oft leise: Ein Action Item verschwindet in der Jira-Tiefe. Ein anderes bleibt ohne Besitzer. Beim dritten ist unklar, was es eigentlich bedeuten soll. Niemand sagt es laut, aber alle spüren es – da bewegt sich wenig. Die Retro war nicht schlecht, aber auch nicht wirksam. Genau hier entsteht sie: die stille Enttäuschung, die sich Retro für Retro summiert. Und plötzlich fragt man sich: Warum machen wir das eigentlich noch?

Ich glaube, genau dieser Punkt ist der gefährlichste Kipppunkt jeder Retrokultur. Denn auch wenn das Gespräch gut war – wenn aus den Erkenntnissen keine Veränderung entsteht, schlägt Reflexion in Frustration um. Das Team spürt: Wir reden, aber es passiert nichts. Und mit jedem unerledigten Action Item sinkt die Bereitschaft, sich beim nächsten Mal einzubringen.

Die Ursachen dafür sind vielseitig – und meist ganz banal. Maßnahmen werden vage formuliert („Wir sollten mehr aufeinander achten“), bleiben ohne Verantwortliche oder versickern einfach im Alltag. Besonders tückisch: Oft merkt es niemand sofort. Doch wenn es zur Gewohnheit wird, dass auf Retros keine Veränderung folgt, wird aus dem wichtigsten agilen Ritual ein frustrierendes Meeting mit Alibi-Charakter.

Was hilft? Klare, konkrete Maßnahmen – versehen mit Zuständigkeit, Frist und Sichtbarkeit. Und: Mut zur Ehrlichkeit. Wenn ein Thema dem Team nicht wichtig genug ist, um Energie hineinzustecken, dann darf es auch bewusst verworfen werden. Alles andere ist Selbsttäuschung. Und ja, auch als Scrum Master oder Agile Coach sollte man sich nicht reflexartig jedes „verwaiste“ To-do greifen. Denn wenn sich niemand verantwortlich fühlt, ist das oft die deutlichere Botschaft als jede Diskussion.

Nicht zuletzt hilft es, Erfolge auch sichtbar zu machen – und sei es nur ein kleiner Schritt. Denn nichts motiviert mehr als das Gefühl: Wir können etwas verändern.

Zu große oder zu heterogene Teams

Wer kennt es nicht? Während beispielsweise der Scrum Guide 3 bis maximal 9 Teammitglieder für ein agiles Team empfiehlt, finden sich in der Realität oft riesige Teams von 10, 15 oder gar über 20 Teammitgliedern. Dies führt nicht nur unweigerlich zu „Teams in Teams“, sondern sorgt auch dafür, dass die Retro sich anfühlt wie ein Meeting-Marathon ohne Fokus. Oft sprechen nur wenige, während sich andere zurücklehnen oder gedanklich ausklinken. Einzelne Stimmen gehen unter oder wiederholen sich. Entscheidungen werden verwässert, Diskussionen enden in Allgemeinplätzen.

In solchen Situationen hilft es, bewusst kleinere Gruppen zu bilden, etwa durch eine Retrospektive in Subteams mit anschließendem Austausch der Erkenntnisse. Auch das Wechseln der Perspektive – etwa durch gezielte Fragestellungen pro Teambereich – kann helfen, mehr Relevanz und Beteiligung zu erzeugen. 

Am Ende lässt sich dieses Problem jedoch nur bedingt im Team lösen: Wenn das Team zu groß ist, um gemeinsam wirklich reflektieren zu können, dann ist das kein Zeichen gegen die Retro – sondern ein klarer Hinweis auf ein organisatorisches Problem. 

Retro overload

Während so gut wie alle agilen Events, von Sprintplannung über Daily Standups bis zu Reviews, mehr oder weniger regelmäßig hinterfragt oder zumindest kritisiert werden, scheinen Retrospektiven in den meisten Teams heilig. Und das ist doch gut so, oder?

Immerhin ist Inspect & Adapt der zentrale Gedanke agilen Arbeitens und ich selbst habe Woody Zuills Aussage zur Wichtigkeit von Retrospektiven zu Beginn dieses Artikels zitiert.

Ganz so einfach ist es in meinen Augen dann aber doch nicht. Vermutlich haben die meisten bereits Retros erlebt, an dem die Leute verschlossen, abgelenkt, unmotiviert oder einfach genervt von Gott und der Welt waren. Natürlich kann man hier durch gute Vorbereitung und Moderation sowie einem gemeinsamen Verständnis der Wichtigkeit einer Retrospektive viel erreichen. Aber dennoch glaube ich, manche Retros sind von vornherein zum Scheitern verurteilt.

Vielleicht sind die Teams noch nicht so weit, im vorgesehenen Rhythmus gemeinsam zu reflektieren. Vielleicht fehlt Vertrauen oder sind Verhaltensweisen oder Organisationen so festgefahren, dass Veränderung einfach eine gewisse Zeit brauchen. Es gibt viele Gründe, weswegen Teams zu viele Retros durchführen können. Dabei führen viele Retros eben nicht zu besonders viel Inspect & Adapt, sondern zu kompletten Stillstand. Frei nach Paracelsus: Die Dosis macht das Gift.

Gerade weil Retros so wichtig sind, trauen sich meiner Erfahrung nach die wenigsten Teams oder Coaches wirklich, ihre Retros kritisch zu hinterfragen. Dabei ist genau diese Reflektion zentral, um Meetings wirklich wertvoll zu machen. Und ich lade jedes Team herzlich ein, in der nächsten Retro einmal über den Sinn – und Unsinn der eigenen Retro zu diskutieren.

Fokus auf den Circle of Concern

Eine Kunst bei Retrospektiven ist es, den Blick über den Tellerrand zu werfen und gleichzeitig vor allem das eigene Verhalten zu reflektieren.

Allzu häufig beobachten wir jedoch eine Fixierung auf den „Circle of Concern“ – also Themen, die zwar die Arbeit des Teams beeinflussen, auf die es aber keinen direkten Einfluss hat. Da wird dann über Tools, die Unternehmensleitung, unklare Strategie oder die Organisation als Ganzes geschimpft. Und ja, manches davon ist durchaus berechtigt – aber selten produktiv.

In Retros geht es vor allem um Selbstwirksamkeit. Um den „Circle of Influence“. Also um die Frage: Was können wir ändern? Wo liegt unser Gestaltungsspielraum? Sich das immer wieder bewusst zu machen und notfalls auch mal freundlich, aber bestimmt zurück auf den Einflussbereich zu lenken, ist eine der wichtigsten Aufgaben eines guten Facilitators.

Manchmal hilft hier ein Perspektivwechsel: Etwa durch gezielte Fragen wie „Was war unser Anteil daran?“ oder „Was würden wir anders machen, wenn wir es allein entscheiden könnten?“ – und manchmal wandelt sich tatsächlich ein Ohnmachtsgefühl in einen konkreten Handlungsspielraum.

Infantilisierung von Mitarbeitern und Monotonie

Viele Retros laufen nach einem sehr ähnlichen Muster ab. Zuerst gibt es einen Checkin, um ein gutes Gesprächsklima zu schaffen. Danach werden Eindrücke und Themen aus der vergangenen Iteration gesammelt. Hieraus werden (oftmals priorisiert durch Dot-Voting) Erkenntnisse gemeinsam diskutiert und abgeleitet, bevor sich das Team auf Action Items einigt und die Retro mittels eines Check-Outs abschließt. Auch wenn es hier von Lego-, über Dino- und Superhelden-Retros verschiedenste Flavour gibt und sich die Details sicherlich unterscheiden (und die Unterscheidung sehr sinnvoll sein kann!) fallen doch die meisten Retros in dieses Schema. Und ermüden die Teams. Eigentlich tolle Hilfsmittel, wie der Retromat verstärken ein solches Muster nochmals. 

Natürlich wirkt sich dieser Faktor umso stärker aus, je weniger nachhaltige Ergebnisse die Retros wirklich produzieren (s.o.).

Auch wenn es etwas harsch klingt: Ich habe oftmals das Gefühl, auch im agilen Kontext neigen wir dazu, Kolleginnen und Kollegen zu infantilisieren. Dies beginnt damit, dass Widerstände gegen Change gerne mal mit “fehlendem agilen Mindset” weggewischt werden oder dass wir glauben, dass sich ein Teammitglied schon öffnet, wenn wir ihm schon genügend, auflockernde und teambildende Checkins und Möglichkeiten bieten. Dabei ist es eigentlich eine Grundannahme des agilen, Menschen wie Erwachsene zu behandeln.

Und genau dies ist meiner Erfahrung nach auch der richtige Weg: Das Team dort abholen, wo es startet und etwaige Störgefühle offen ansprechen. Zur Abwechslung auch mal gar keine oder nur eine minimale Struktur für die Retro vorzugeben und in einem offenen Format dem Team den Raum geben, Themen und Optimierungsmöglichkeiten zu besprechen, kann helfen, aus dem Trott auszubrechen. Auch abwechslungsreiche Formate wie ein Pre-Mortem sind in diesem Kontext spannende Werkzeuge.

Misstrauen (in das Management) 

Ich denke manchmal an Asterix & Obelix, wenn ich manche Teams in ihren Retros beobachte. Da sitzt ein gallisches Dorf zusammen, kämpferisch, eng verbunden, voller Stolz auf die eigene Selbstorganisation. Und draußen lauert das Imperium: das Management, die Enterprise Architekten, die fremdbestimmten Roadmaps. Was als gesunder Schutzmechanismus beginnt, kann schnell zur systemischen Trennung werden.

Besonders in Retros wird dieses Muster sichtbar. Immer wieder kommen dieselben Themen auf: fehlende Entscheidungsspielräume, widersprüchliche Impulse von außen, Tooling, das bremst. Doch je häufiger solche Punkte ohne spürbare Reaktion bleiben, desto mehr verfestigt sich im Team ein Gefühl von: „Die da draußen machen ja doch, was sie wollen.“ Und damit auch: „Dann machen wir hier halt unser Ding.“ Die Retro wird zur Bühne der Selbstvergewisserung – aber nicht mehr zur Brücke nach außen.

Agile Coaches tragen zu dieser Dynamik manchmal ungewollt bei. Indem sie Teams in ihrer Eigenständigkeit stärken, aber gleichzeitig versuchen, sie vor destruktiven oder unklaren Einflüssen von außen zu schützen. Das ist verständlich – aber auch gefährlich. Denn wenn das Team sich nur noch im Inner Circle bewegt, wird Selbstorganisation schnell zu Selbstabschottung. Die Retrospektive verkommt zur Selbstbespiegelung: Immer die gleichen Themen, immer die gleichen Perspektiven, keine echte Weiterentwicklung.

Was hilft? Brücken bauen. Zum Beispiel durch „Retro Reviews“ mit Stakeholdern, durch Eskalationsschleifen mit Feedback-Rückkanal oder durch die bewusste Einbindung von Führungskräften – nicht als Kontrolle, sondern als Dialogpartner. Besonders wichtig ist in diesem Kontext die Rolle des Product Owners – und anderer Personen, die sich in übergreifenden Gremien und Abstimmungen bewegen, auf einer Ebene, die viele als Flight Level 2 bezeichnen würden. Gerade wenn diese Rollen über lange Zeit eng im Team verankert waren, neigen sie dazu, Konflikte zu vermeiden und übernehmen häufig unbewusst die Narrative des Teams als „Good Buddy“. Wenn es ihnen jedoch gelingt, sich aus dieser Sichtweise zu lösen und gezielt Impulse von außen ins Team zu tragen, kann das die Retro wieder öffnen – für neue Perspektiven und echte Veränderung.

Denn ein gallisches Dorf ist stark – aber es muss anschlussfähig bleiben, wenn es nicht irgendwann alleine dastehen will.

Ein kleines Fazit 

Retrospektiven sind ein zentrales Werkzeug agiler Zusammenarbeit – und gleichzeitig anfällig für Abnutzung, Frustration und schleichende Bedeutungslosigkeit. Die in diesem Artikel beschriebenen Symptome von „Retro Fatigue“ habe ich nicht nur beobachtet, sondern teilweise selbst verursacht. Doch genau darin liegt auch eine Chance: Wenn wir den Mut haben, offen über unsere eigenen Routinen zu sprechen, können wir Retrospektiven wieder zu dem machen, was sie sein sollen – Räume für echte Reflexion, lernende Teams und kontinuierliche Verbesserung.

Also was würde ich zukünftig denn nun anders machen? Als allererstes wohl offen mit dem Team sprechen. Und einmal reflektieren, welche Anti-Pattern gerade eigentlich auf uns zutreffen.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Manuelle Software-Releases stellen eine häufige Quelle für Belastungen und Ineffizienz in Entwicklungsteams dar. Der Prozess umfasst oft nächtliche Deployments, manuelle Checklisten und die mühsame Erstellung von Changelogs. Dieser risikobehaftete, manuelle Arbeitsablauf birgt nicht nur ein erhebliches Potenzial für menschliche Fehler, sondern kann auch eine „Release Anxiety“ begünstigen, welche agile Entwicklungszyklen verlangsamt. Die Entscheidung, an einem Freitagnachmittag einen kritischen Fix zu mergen, wird dadurch häufig verzögert.

Ein idealer Workflow würde es jedoch ermöglichen, dass jeder Merge in den Main-Branch sicher einen neuen, korrekt versionierten Release auslöst, komplett mit strukturierten, automatisch generierten Release Notes. Dies ist nicht nur ein Prinzip moderner CI/CD-Praktiken, sondern eine erreichbare Realität. Durch die Nutzung einer strukturierten Commit History können Software-Releases zu einem routinierten, vorhersagbaren und vollständig automatisierten Prozess werden.

Dieser Artikel bietet eine technische Anleitung, um dieses Automatisierungsniveau durch die Implementierung der “Conventional Commits”-Spezifikation und des semantic-release-Tools zu erreichen.

Das Kernprinzip: Die Steuerung des Releases durch die Commit History

Der Schlüssel zu dieser Automatisierung liegt in einem konzeptionellen Wandel: Die Git Commit History wird nicht mehr nur als Protokoll von Änderungen betrachtet, sondern als die alleinige Quelle der Wahrheit für die Versionierung. Anstatt dass ein Entwickler entscheidet, ob eine Änderung einen Patch-, Minor- oder Major-Release rechtfertigt, wird diese Entscheidung direkt aus der Historie des Codes abgeleitet.

Der daraus resultierende Vorteil ist signifikant: Der Release-Prozess wird von subjektiven Entscheidungen entkoppelt und zu einer direkten, logischen Konsequenz der geleisteten Arbeit. Jeder Commit trägt eine eigene semantische Bedeutung, wodurch die Versionsnummer zu einem vorhersagbaren Ergebnis anstatt einer Schätzung wird. Diese Philosophie bildet die Grundlage der Automatisierung.

Die Grundlage: Etablierung eines Standards für Commit-Nachrichten

Die Voraussetzung für jede Automatisierung ist die Etablierung einer standardisierten, maschinenlesbaren Sprache für die Kommunikation. Die Conventional Commits-Spezifikation bietet einen solchen Standard, indem sie eine klare und verbindliche Struktur für Git Commit Messages vorschreibt, die Mehrdeutigkeiten beseitigt und die Absicht jeder Änderung explizit macht.

<type>[optionaler scope]: <description>

[optionaler body]

[optionale(r) footer]

Der type-Bezeichner ist die entscheidende Komponente, die die Auswirkung eines Commits auf die Versionierung gemäß den Prinzipien des Semantic Versioning diktiert:

• fix: Kennzeichnet eine Fehlerbehebung, die ein Problem in der Codebasis korrigiert. Dies entspricht einem Patch Release (z. B. 1.0.0 -> 1.0.1).
• feat: Bezeichnet die Einführung eines neuen Features, das Funktionalität hinzufügt. Dies entspricht einem Minor Release (z. B. 1.0.1 -> 1.1.0).
• feat! oder fix!: Signalisieren eine nicht abwärtskompatible Änderung (ein „Breaking Change“). Dieser Indikator erfordert einen Major Release (z. B. 1.1.0 -> 2.0.0).

Commits mit anderen Typen wie docs, chore, style, refactor oder test sind für die Wartung der Codebasis unerlässlich, lösen jedoch keine Anpassung der Versionsnummer aus. Diese Unterscheidung ist entscheidend, da sie sicherstellt, dass das für den Benutzer sichtbare Changelog auf wertschöpfende Änderungen, nämlich neue Features und Fehlerbehebungen, konzentriert bleibt. Dieser disziplinierte Ansatz führt zu einer transparenten und vorhersagbaren Git History.

Der Autopilot: Orchestrierung des Release-Prozesses mit semantic-release

Mit einer strukturierten Commit History kann der Release-Prozess mithilfe von Tools wie semantic-release automatisiert werden. Dieses Dienstprogramm fungiert als Orchestrator des Release-Workflows und integriert die Git History mit dem Paketmanager des Projekts und dem Repository-Host.

semantic-release automatisiert den gesamten Package Release Workflow, der die Bestimmung der nächsten Versionsnummer, die Erstellung von Release Notes und die Veröffentlichung des Pakets umfasst.

Das Tool analysiert die Commit History des Projekts, um die nächste semantische Version abzuleiten, und führt anschließend eine konfigurierbare Abfolge von Release-Schritten aus. Obwohl es als Node.js-Paket vertrieben wird, bietet seine plugin-basierte Architektur die Flexibilität, Projekte zu unterstützen, die in allen gängigen Programmiersprache entwickelt wurden. Die folgenden Abschnitte demonstrieren die Anwendung innerhalb eines Spring-Boot-Projekts.

Praktische Implementierung: Eine schrittweise Anleitung

Die Konfiguration lässt sich in drei Hauptschritte unterteilen.

Schritt 1: Vorbereitung des Gradle-Builds (gradle.properties)

Das gradle-semantic-release-plugin benötigt einen festgelegten Ort, um die Version des Projekts zu aktualisieren. Die Datei gradle.properties erfüllt diesen Zweck effektiv. Die Entkopplung der Versionsnummer in eine Properties-Datei ist eine empfohlene Praxis, da sie externen Tools ermöglicht, die Version zu lesen und zu schreiben, ohne komplexe Build-Skripte parsen zu müssen.
gradle.properties

version = 0.0.0

Schritt 2: Konfiguration des Release-Workflows (.releaserc.yml)

Diese Konfigurationsdatei definiert die genaue Abfolge der Operationen, die semantic-release ausführen wird.

.releaserc.yml

release:
  branches:
    - 'main'
preset: 'conventionalcommits'
plugins:
  - '@semantic-release/commit-analyzer'
  - '@semantic-release/release-notes-generator'
  - - '@semantic-release/changelog'
    - changelogFile: 'CHANGELOG.md'
      changelogTitle: '# Changelog'
  - - '@semantic-release/github'
    - assets:
        - path: 'CHANGELOG.md'
          label: 'Changelog'
  - 'gradle-semantic-release-plugin'
  - - '@semantic-release/git'
    - assets:
        - 'CHANGELOG.md'
        - 'gradle.properties'

Die Anweisungen in dieser Datei sind wie folgt zu verstehen:

• branches: Beschränkt die Ausführung des Release-Prozesses auf Commits im main-Branch.
• preset: Ermöglicht das Einbinden von vordefinierten Konfigurationen. Hier wird eine auf die Conventional-Commits-Konvention abgestimmte Konfiguration genutzt.
• plugins: Definiert die geordnete Pipeline von Aktionen:

• commit-analyzer: Analysiert Git-Commits seit dem letzten Release-Tag, um den erforderlichen Release-Typ (Major, Minor oder Patch) zu bestimmen.
• release-notes-generator: Erstellt strukturierte Release Notes aus den relevanten Commit-Nachrichten.
• changelog: Fügt die generierten Notes an eine CHANGELOG.md-Datei an und pflegt so eine beständige Aufzeichnung der Änderungen.
• github: Erstellt einen offiziellen, getaggten Release auf der GitHub-Plattform und fügt angegebene Assets, wie das Changelog, hinzu.
• gradle-semantic-release-plugin: Führt sprachspezifische Aufgaben aus, in diesem Fall die Aktualisierung der Version in gradle.properties und die Ausführung des publish-Tasks.
• git: Committet die geänderten Dateien (CHANGELOG.md, gradle.properties) zurück in das Repository, um dessen Zustand mit dem neuen Release zu synchronisieren.

Schritt 3: CI/CD-Integration (GitHub Actions)

Schließlich ist eine CI-Pipeline erforderlich, um den Release-Workflow bei einem Push in den main-Branch auszulösen. Der folgende GitHub-Actions-Workflow realisiert dies.

.github/workflows/release.yml

name: Release
on:
  push:
    branches:
      - main
permissions:
  contents: read
jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    permissions:
      contents: write
      issues: write
      pull-requests: write
      id-token: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Node einrichten
        uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'
      - name: Install dependencies
        run: |
          npm install -g \
            semantic-release \
            @semantic-release/git \
            @semantic-release/changelog \
            conventional-changelog-conventionalcommits \
            gradle-semantic-release-plugin
      - name: Release durchführen
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx semantic-release

Dieser Workflow installiert semantic-release und seine Plugins und führt dann den Release-Prozess aus. Der Parameter fetch-depth: 0 ist von entscheidender Bedeutung, da er sicherstellt, dass die gesamte Git History zur Analyse verfügbar ist. Der permissions-Block gewährt dem Job ausreichende Berechtigungen, um Releases zu erstellen und Dateien zurück in das Repository zu committen.

Fazit: Die strategischen Vorteile der Release-Automatisierung

Die Implementierung dieser automatisierten Release-Pipeline führt zu erheblichen strategischen Vorteilen. Sie eliminiert manuellen Aufwand und das Potenzial für menschliche Fehler im Versionierungs- und Release-Prozess. Die Praxis, Versionsnummern zu schätzen und Changelogs manuell zusammenzustellen, wird durch ein deterministisches, automatisiertes System ersetzt.

Diese Transformation bewirkt mehr als nur eine Zeitersparnis; sie verbessert den Softwareentwicklungszyklus grundlegend. Sie ermöglicht eine höhere Deployment-Frequenz mit größerem Vertrauen, was eine schnellere Bereitstellung von Features und Fehlerbehebungen erlaubt. Die mit Release-Ereignissen verbundene Anspannung wird durch die Effizienz von Continuous Delivery ersetzt. Die Hauptverantwortung des Entwicklungsteams reduziert sich auf die Aufrechterhaltung einer hohen Standard an Commit-Hygiene; der Release-Mechanismus übernimmt die übrigen Aufgaben.

Daniel Schock

Senior Software Engineer

Daniel ist ein erfahrener Fullstack-Entwickler und DevOps-Spezialist mit einem klaren Schwerpunkt auf der Backend-Entwicklung mit Java und Kotlin. Seine Expertise wird durch praktische Erfahrung in der Frontend-Entwicklung mit Vue.js abgerundet. Er verfügt über umfassende Kenntnisse in der Konzeption von CI/CD-Pipelines sowie im Einsatz von Cloud-Technologien wie Kubernetes und AWS, die er erfolgreich in den Branchen Versicherung, Logistik und E-Commerce einsetzte. Daniel arbeitet bevorzugt in agilen Umgebungen und zeichnet sich durch seine analytische Denkweise und hohe Problemlösungskompetenz aus.

d.schock@atra.consulting    

Vor einigen Monaten bat mich ein ehemaliger Kunde um Unterstützung. Er plante den Schritt in die Selbstständigkeit und wollte im Rahmen seines Businessplans eine grobe Kosteneinschätzung für eine eigene Website inklusive App. Der Einsatz von Standardlösungen kam für ihn aus verschiedenen Gründen nicht infrage. Nachdem wir seine Anforderungen in ein, zwei Runden durchgesprochen hatten, nannte ich ihm – eher konservativ geschätzt – einen Betrag von 60.000 bis 80.000 Euro für eine solide entwickelte, barrierefreie, SEO-optimierte Webanwendung mit Integration in relevante Umsysteme.

Die Summe überraschte ihn. Verständlich – viel Geld für ein Startup, das zu diesem Zeitpunkt noch nicht einmal offiziell gegründet war.

Gerade in solchen Situationen wirken die zahlreichen Vibe-Coding-Plattformen, die aktuell wie Pilze aus dem Boden schießen, besonders verlockend. Vibe-Coding ist ein von Andrej Karpathy – ehemaliger KI-Chef von Tesla und Mitgründer von OpenAI – geprägtes Konzept (Quelle bei X): Man beschreibt in natürlicher Sprache, was man bauen möchte, und ein großes Sprachmodell generiert direkt lauffähigen Code. Der Code selbst wird meist nicht wirklich verstanden – man folgt dem „Vibe“, iteriert in schnellen Feedbackschleifen. Eine faszinierende Vorstellung, besonders für Gründer ohne technisches Know-how.

Ein prominentes Beispiel für eine solche Plattform ist das schwedische Start-up Lovable: Nur drei Monate nach seiner Gründung Ende 2023 zählte es nach eigenen Angaben bereits 30.000 Abonnenten und erzielte einen jährlich wiederkehrenden Umsatz (Annual Recurring Revenue, ARR) von 17 Millionen Dollar (Handelsblatt). Keine fünf Monate später legte Lovable noch einmal nach – und wurde zum jüngsten Software-Unternehmen aller Zeiten, das die Marke von 100 Millionen Dollar ARR durchbrach (Tech.eu).

Ich persönlich nehme in der öffentlichen Debatte aktuell eine zunehmende Polarisierung rund um Vibe-Coding und AI-basierte Softwareentwicklung wahr. Während manche, wie etwa Softbank-Gründer Masayoshi Son, das Ende der menschlichen Programmierer postulieren und noch 2025 Milliarden autonomer AI-Agenten einsetzen wollen (heise.de), warnen Kritiker vor den Risiken von unkontrolliertem Code. Zuletzt machte ein Fall Schlagzeilen, bei dem ein AI-Agent eigenständig eine komplette Unternehmensdatenbank löschte und anschließend sogar noch versuchte, diesen Fehler zu verheimlichen (PCMag).

Auch die Studienlage ist alles andere als eindeutig: Während einige Erhebungen positive Effekte von AI-Tools aufzeigen, zeigt etwa eine Untersuchung der Non-Profit-Organisation Metr, dass erfahrene Entwickler zwar subjektiv von Effizienzgewinnen ausgehen – objektiv aber 19 % langsamer arbeiten, wenn sie AI-Tools einsetzen (metr.org).

Ich persönlich sehe mich irgendwo in der öffentlich wenig präsenten Mitte: Ich bin überzeugt, dass wir auf absehbare Zeit erfahrene Architekten und Entwickler brauchen, um komplexe Systeme zu verstehen, zu gestalten und langlebig zu betreiben – insbesondere, wenn es darum geht, die eigentlichen Bedürfnisse des Kunden zu ergründen. Gleichzeitig glaube ich, dass viele AI-Tools uns bereits heute spürbar effizienter machen können. Mein Bauchgefühl: 15 bis 20 Prozent Produktivitätsgewinn sind realistisch – unter den richtigen Bedingungen.

Aber ich gebe auch zu: Ich stehe dem konkreten Thema Vibe-Coding eher skeptisch gegenüber. Vielleicht, weil es niemand gern hört – und noch weniger gern zugibt –, dass das, was man selbst jahrelang gelernt, gelehrt und beruflich begleitet hat, plötzlich von einer Maschine besser, schneller und billiger erledigt werden könnte. Aber: Ist diese Skepsis berechtigt? Oder doch nur verletzter Entwicklerstolz?

Um genau das herauszufinden – um meiner Skepsis entweder ein solides Fundament zu geben oder es ihr zu entziehen – habe ich mich in ein kleines Offsite zurückgezogen. Für einen halben Tag bin ich selbst zum Vibecoder geworden: kein Editor, keine Zeile selbstgeschriebener Code. Nur ich, ein Use Case, ein KI-Tool – und vier Stunden Zeit.

Und genau von diesem halben Tag im Leben eines Vibecoders möchte ich euch jetzt erzählen.

Der Usecase

Ein reales Kundenprojekt schied allein schon aus Sicherheitsgründen aus – also musste ein internes Vorhaben her, das auch über meinen kleinen Proof of Concept hinaus einen echten Mehrwert bringt. Gleichzeitig sollte das Szenario überschaubar genug sein, um Lovable eine realistische Chance zu geben, aber auch nicht zu trivial – idealerweise mit mindestens einem integrierten Umsystem.

Die Wahl fiel schnell auf einen Profilgenerator. Bei neuen oder freiberuflichen Berater:innen entsteht regelmäßig Aufwand, ihren Lebenslauf oder ihre Projekthistorie in unser internes Standardformat zu überführen. Intern nutzen wir bereits intensiv Google Gemini, das sich gut dafür eignen sollte, Informationen aus Lebensläufen zu extrahieren und ansprechend aufzubereiten. Wenn das Ergebnis anschließend auch noch automatisch in Google Docs abgelegt wird, haben wir einen Use Case mit zwei Systemintegrationen – bei gleichzeitig klar umrissenen Ziel.

Klingt fair für mich.

Eine kurze Vorbereitung

Eine erste Prompt zur Profilerstellung war schnell geschrieben – und funktionierte überraschend gut. Das Zauberwort lautete: Few-Shot-Prompting. Auch die Einrichtung von Lovable war unkompliziert: Innerhalb von fünf Minuten war ich startklar und hatte für 25 $ im Monat das Pro-Abo abgeschlossen, inklusive 100 Credits. Insgesamt habe ich während meiner vier Stunden rund 130 Credits verbraucht und 50 € ausgegeben.

Erste Schritte

Jetzt wurde es ernst: Mein erster Vibe-Coding-Prompt war schnell formuliert – und dann hieß es erstmal warten. Gut, nur kurz: Nach exakt 3 Minuten und 16 Sekunden stand die erste Version meines Profilgenerators. Lovable informiert dabei sehr benutzerfreundlich darüber, woran gerade gearbeitet wird.

Mein initialer Prompt

Build a web app called „Profile Generator“.

Core functionality:
– Users can upload one or more resumes (PDF, DOCX, or TXT format).
– Optional: Users can add additional context for the profile generation.
– Provide a toggle, dropdown, or slider to let the user choose whether they want to add context.
– If activated:
– Show a text input field.
– Show a file upload that allows multiple documents (PDF, DOCX, TXT).
– Let the user choose between OpenAI and Google Gemini as the LLM provider.
– Prepare the API key as a configurable variable – I will insert it later.
– On clicking „Generate Profile“:
– The uploaded data and context are sent to the selected model.
– Use a pre-defined prompt template (to be filled in later) to structure the request.
– Display the generated, standardized profile in a separate view area (e.g. modal, sidebar, or overlay).

Design guidelines (corporate identity):
– Font: Helvetica Neue or Helvetica. If unavailable, fall back to Arial.
– Use the following colors:
– Primary: #264892 (dark blue)
– Secondary:
– Light blue: #a7c6eb
– Dark grey: #777777
– Light grey: #dedede
– Accent:
– Dark orange: #dc421e
– Light orange: #f98752
– Use a dark UI theme overall.
– Accent colors should be used for buttons, toggles, and loading indicators.

Technical:
– Keep the code modular and flexible so additional LLM providers or prompt templates can be added later.
– The app should work well on both desktop and mobile devices.

Und tatsächlich: Die erste Version sah schon ziemlich schick aus.
Ein kleiner Bug hatte sich eingeschlichen – das Kontextmenü ließ sich per Slider aktivieren, aber nicht wieder deaktivieren. Der Fix war für 0,6 Credits schnell erledigt. Der Vibe stimmte noch nicht ganz, aber nach fünf – sechs Iterationen und etwa 20 Minuten stand ein Design, mit dem ich wirklich zufrieden war. Inklusiver automatische Unterstützung für Light- und Dark-Mode als kleine Spielerei.

Stimmungsbarometer zu diesem Zeitpunkt: 9/10.

Für einen (eingerosteten) Entwickler, der sich eher in Backend-Architekturen und Algorithmik zuhause fühlt, war die schnelle Erstellung eines modernen (wenn auch etwas generischen) Frontends schlicht ein Traum. Ich selbst hätte dafür sicherlich mehr als einen Tag gebraucht, und auch ein erfahrener UI-Entwickler hätte einige Stunden investieren müssen.

Warum keine 10/10?

Ein paar Kinderkrankheiten gibt es noch. So konnte ich unser Unternehmenslogo nicht direkt hochladen, sondern musste Lovable erst mit einem GitHub-Repository meiner Wahl verbinden und die Bilddatei manuell ablegen. Kein Beinbruch – aber als echter Vibe-Coder will man eigentlich nichts mehr mit den src/assets-Ordnern dieser Welt zu tun haben.

Immerhin: Die GitHub-Integration funktioniert hervorragend.

Lovable committed sauber, transparent, und der Re-Sync läuft quasi in Echtzeit.

Zwischen Begeisterung und Bauchschmerzen: Das erste echte Problem

Eines der Hauptargumente gegen Vibe-Coding ist, dass dabei nicht nur sogenannter bloated Code entsteht – also unnötig umfangreicher, redundanter oder unstrukturierter Code, der schwer wartbar ist –, sondern dass essenzielle Aspekte wie Sicherheit, Skalierbarkeit und Fehlertoleranz häufig zu kurz kommen.

Umso erfreulicher war es, dass Lovable bei einem sensiblen Punkt direkt reagierte:
Ich hatte das Tool bewusst darum gebeten, meinen Gemini-API-Key hart in den Code einzubetten – ganz im Sinne eines schnellen Prototyps. Doch statt den einfachsten Weg zu gehen, empfahl mir Lovable, den Schlüssel lieber in ein Secret auszulagern. Vorbildlich. (Mehr zu den Sicherheitsfeatures von Loveable findet sich hier).

Passenderweise bietet Lovable mit einer Supabase-Integration auch gleich eine Lösung an. Supabase ist – kurz gesagt – ein gehosteter Postgres-Dienst mit API-Zugriff, Authentifizierung und Dateispeicher (https://docs.lovable.dev/integrations/supabase).

Ich wollte jedoch bewusst nicht den für Lovable einfachsten Weg gehen und keine zusätzliche Anbieterabhängigkeiten schaffen. Also bat ich um einen Alternativplan. Nach kurzer Diskussion einigten wir uns darauf, den API-Key über eine Umgebungsvariable einzubinden – ganz im Sinne eines später cloudfähigen Deployments. Lovable generierte daraufhin automatisch eine .env.local-Datei und eine begleitende GEMINI_SETUP.md. Den Test-Key konnte ich direkt über den integrierten Code-Browser ablegen.

Und dann kam der erste grobe Patzer.

Die .env.local-Datei landete im Git-Repository. Ein klassischer Anfängerfehler: .gitignore nicht gepflegt. Ich bin mir relativ sicher, dass Lovable in ein paar Monaten genau solche Fehler zuverlässig vermeidet – und in der ursprünglich empfohlenen Supabase-Lösung (die ein echter Vibe-Coder wohl verfolgt hätte) wäre das gar nicht erst passiert.

Aber dennoch: Das sind Fehler, die Senior-Entwicklern – und ein solcher auf Steroiden will Lovable letztlich sein – nicht passieren dürfen.

Ein wenig bestärkt in meiner Skepsis, aber weiterhin beeindruckt von Tempo und Nutzerführung, bewegt sich meine Laune bei 6 von 10 Punkten.

Kontrollverlust mit Ansage: Wenn der Vibe kippt

Was wie ein kleiner Stimmungseinbruch wirkte, entpuppte sich leider als Auftakt zu einer echten Stunde des Vergessens.

Zunächst war da das Problem mit der .env.local: Die Umgebungsvariable wurde von der Anwendung in Lovable nicht gezogen – die Datei war schlicht verschwunden. Ich vermute, intern wurde auf den Stand aus Git zurückgesetzt, aus dem ich die Datei inzwischen ja wieder entfernt hatte. Also: GitHub-Verbindung ein zweites Mal bemüht, Repository lokal geklont – und siehe da, lokal funktionierte die Einbindung der Umgebungsvariable problemlos.

Alles gut? Mitnichten.

Beim ersten lokalen Start begrüßte mich die Konsole mit einer klassischen NPM-Warnung:

added 397 packages, and audited 398 packages in 6s, 7 vulnerabilities (1 low, 4 moderate, 2 high).

Der Vibe-Coder in mir war verunsichert. Also tat ich, was ein echter Vibecoder tun sollte: Ich fragte die KI um Hilfe. Und es passierte… nichts (Gutes).

Ob die internen Sicherheitsmechanismen von Lovable (siehe Screenshot) blockierten oder die KI einfach einen schlechten Tag hatte – keine Ahnung. Fest steht: Ich musste den Befehl npm audit fix lokal ausführen und den Code zurück ins Repository pushen, um die Sicherheitswarnungen loszuwerden.

Wenigstens konnte ich mich jetzt endlich der Backend-Integration widmen. Die Nutzung meines vorbereiteten Prompts zur Gemini-Anbindung funktionierte grundsätzlich: Ein API-Aufruf wurde generiert, die Kommunikation mit Gemini stand. Aber: Auf die Idee, die Rückgabewerte zu typisieren oder zu validieren, kam das Tool nicht. Stattdessen: lose JSON-Strukturen im Backend. An dieser Stelle fühlte sich Vibe-Coding das erste Mal wirklich falsch an.

Am Frontend sah ich sofort Ergebnisse. Ich habe Feedback, bekomme UI, sehe Fortschritt. Hier dagegen diskutierte ich eine Stunde lang mit der KI über API-Strukturen – ohne jedes wirkliche Feedback, ob wir uns in die richtige Richtung bewegen. Ohne eigene Programmier- oder Anwendungserfahrung wäre ich an diesem Punkt komplett verloren gewesen.

Vielleicht hätte ich auch einfach dem Vibe mehr vertrauen sollen. Aber hey – ich habe nicht jahrelang Programmieren gelernt, um dann schlechten Code blind durchzuwinken.

Immerhin: Lovable ließ sich schnell überzeugen, dass Typisierung vielleicht doch keine ganz dumme Idee ist.

Vertrauen ist gut – Tests sind besser?

Mit wachsender Skepsis wollte ich die Leine nun kürzer halten: „Please add a test framework and implement some tests for our work.“ – eine eigentlich einfache Bitte. Gerade Testfallerzeugung wird oft als Paradebeispiel für AI-Coding-Unterstützung genannt.

Doch es blieb wirklich der Wurm drin. Fünf Minuten Wartezeit, acht eigene „Let me fix this“-Schleifen – und am Ende stand wieder… nichts (Funktionierendes).Warum? Keine Ahnung. Zu viele Vorgaben meinerseits? Zu wenig Vibe-Vertrauen? Eine Laune der KI? Eine funktionierende Testabdeckung habe ich von Lovable jedenfalls nicht gesehen.

Claude to the Rescue?

Ganz wollte ich das Thema nicht abhaken – immerhin gelten Tests als KI-Paradedisziplin.

Also bat ich Claude Code um Hilfe. Auch hier brauchte es mehrere Runden, aber letztlich funktionierte es.

Der finale Fix wirkte etwas verzweifelt – aber hey, es lief.

Zu diesem Zeitpunkt, etwa drei Stunden nach Projektstart, war meine Laune am Tiefpunkt: 1/10. Die Euphorie der ersten Stunde war einer Mischung aus Frust und Ermüdung gewichen. 

Aber ich wollte das Experiment nicht so enden lassen. Also: kurze Pause, frische Luft, neuer Anlauf. Noch eine Stunde war übrig – und vielleicht ja auch noch ein bisschen Vibe.

Die Rückkehr zur Freude und ein Hauch von agentic AI

Nach einer dringend nötigen Pause startete ich in die letzte Stunde meines Experiments.

Die Backend-Anbindung an Gemini hatte mich etwas abgeschreckt, also zog es mich zurück auf den Happy Path – zurück zur Oberfläche, zurück zum UI.

Der Einstieg war vielversprechend: Eine Funktion zur Erstellung von Demo-Profilen mit Mock-Daten sowie die Möglichkeit, sämtliche Felder nachträglich zu bearbeiten, war innerhalb weniger Minuten umgesetzt. Und ganz ehrlich? Hier macht Vibe-Coding einfach Spaß. Schnelle Feedbackzyklen, sichtbare Fortschritte.

Einziger Wermutstropfen: Die Testabdeckung bleibt weiterhin keine Priorität von Loveable. Aber gut – wir reden doch alle über agentic AI. Also darf Claude dann eben parallel Tests prüfen sowie aktualisieren und mir nebenbei auch noch ein erstes Docker-Setup aufsetzen.

Zwischenzeitlich liefen sogar drei KIs gleichzeitig:

• Lovable baute UI-Features
• Claude machte Code-Reviews, testete, dockerisierte
• ChatGPT optimierte der Prompt für Gemini, sodass wirklich strukturierter Output (statt Fließtext) zurückkam

Und das Beste zum Schluss: Auch eine erste Google-Docs-Integration funktionierte auf Anhieb. Feine Formatierung war zwar eine Herausforderung – an der Stelle hätte ich die Klasse wohl selbst noch mal geschrieben – aber der technische Durchstich lief perfekt.

Zwischen Euphorie und Ernüchterung – mein Zwischenfazit

Das, was ich in nur vier Stunden erreicht habe, hätte ich ohne KI in dieser Zeit niemals auch nur annähernd geschafft. Ich verstehe absolut, wieso Vibe-Coding begeistert.

Gleichzeitig habe ich aber auch viele Herausforderungen gespürt, die dieser Ansatz heute noch mit sich bringt. Besonders bei Lovable habe ich das Gefühl, dass das Tool stark auf die schnelle und visuell überzeugende UI-Generierung optimiert ist – was aus Marketingsicht absolut Sinn ergibt, wenn man bedenkt, dass die Zielgruppe vor allem jene 99 % der Menschheit sind, die nicht programmieren können.

Doch sobald Lovable vom Happy Path abwich, geriet es ins Straucheln. Komplexere Logik, Fehlertoleranz, saubere Typisierung oder Testabdeckung – all das wurde deutlich schwieriger. Aber, um fair zu bleiben: Auch bei eigenen Programmierprojekten habe ich schon viele Stunden auf der Suche nach Bugs oder Denkfehlern verbracht, die sich im Nachhinein als trivial herausgestellt haben. Mehr als einmal. Viel mehr als einmal.

Und es bleibt festzuhalten: Ich habe mit kaum nennenswerter eigener Programmierleistung in vier Stunden eine funktionale, hübsche und zu 80 % fertige Web-App gebaut – inklusive Docker-Setup und KI-Integration. Das ist beachtlich.

Für den produktiven Einsatz im Alleingang ist Vibe-Coding für mich derzeit noch zu intransparent und fehleranfällig. Aber: Lovable war deutlich weiter, als ich erwartet hatte – und was Claude Code in Sachen Docker geliefert hat, war ebenfalls eine angenehme Zeitersparnis.

Besonders spannend finde ich aktuell jedoch vor allem einen Anwendungsfall: Kund:innen innerhalb weniger Minuten interaktive UI-Prototypen mit Mock-Funktionalitäten präsentieren, um Feedback frühzeitig einzuholen und gemeinsam zu iterieren. Für diesen Zweck könnte Vibe-Coding schon heute ein echter Gamechanger sein. 

Und was ist mit meinem ehemaligen Kunden und seinem Startup?

Ich gebe zu: Ich ringe noch ein wenig mit mir. Für einen ersten Proof of Concept ist ein Vibe-Coding-Ansatz wie Lovable durchaus geeignet. Gerade im Gespräch mit Investor:innen kann eine funktionierende App – selbst wenn sie noch nicht produktionsreif ist – ein starkes Argument sein. Nach diesen vier Stunden bin ich überzeugt: In ein bis zwei Wochen ließe sich ein funktionsfähiger Prototyp erstellen und in der Cloud der Wahl deployen.

Ob ich diesen Weg allerdings uneingeschränkt empfehlen kann, hängt von einer entscheidenden Frage ab: Wie tragfähig ist die technische Basis – und wie gut lässt sich darauf weiterentwickeln?

Die Antwort darauf wird auch beeinflussen, ob und in welchem Maß sich meine ursprüngliche Kostenschätzung relativiert. Die von mir geschätzten 15–20 % Effizienzgewinn durch den Einsatz von AI (auch ohne Vibe-Coding im engeren Sinne) halte ich für realistisch. Bei tendenziell geringer Backend-Komplexität und UI-fokussierter Entwicklung kann ich mir in Einzelfällen sogar eine Halbierung des Entwicklungsaufwands vorstellen.

Aber: Diese Effizienz erkauft man sich mit technischen Schulden, die spätere Featureentwicklungen massiv verlangsamen können – insbesondere bei wachsender Komplexität. (Siehe z. B. dieser Artikel zu langlebigen Architekturen.)

Ich werde mich demnächst mit einem erfahrenen Frontend-Entwickler zusammensetzen und gemeinsam philosophieren, ob – und in welchem Umfang – sich die von Lovable erzeugte Lösung als technische Grundlage für ein echtes Produkt weiterverwenden lässt.

Davon wird abhängen, ob ich diesen Weg ruhigen Gewissens empfehlen kann – oder eher nicht.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Die Vorstellung, mobiles Arbeiten zu nutzen, um den Laptop für ein paar Tage am Strand aufzuklappen, hat zweifellos ihren Reiz. Das haben inzwischen auch viele Unternehmen erkannt und bieten flexible Arbeitsmodelle an – darunter auch die sogenannte Workation (eine Mischung aus “Work” und “Vacation”).

Laut einer Studie des Deutschen Instituts für Wirtschaft  von 2022 ermöglichen bereits 15,1 % der Unternehmen in Deutschland ein solches Modell. Eine aktuelle PWC-Studie aus dem Jahr 2024 zeigt: 80 % der 18- bis 29-Jährigen wünschen sich die Möglichkeit zur Workation. Und altersunabhängig würden ganze 30 % der Befragten ein Jobangebot ablehnen, wenn diese Option nicht gegeben ist. (Ich habe da übrigens meine Zweifel – in einer Onlineumfrage ist das schnell gesagt).

Auch bei atra.consulting – wie bei jedem meiner früheren Arbeitgebern – gibt es die Möglichkeit zur Workation. Mich persönlich hat das Konzept jedoch nie besonders angesprochen. Mein Arbeitsalltag ist oft durch Meetings und Deadlines geprägt – die Vorstellung, dieselben Videocalls nur von einem anderen Ort aus zu führen, erschien mir wenig verlockend. Für ein bisschen Stadtbummel am Abend noch zusätzlich Reisezeit und -kosten auf mich zu nehmen? Nicht wirklich.

Und doch sitze ich nun an einem Küchentisch in Lacanau an der französischen Atlantikküste und schreibe diesen Erfahrungsbericht. Was ist passiert? Ich muss wohl David, einem guten Freund, danken, der mich auf die Idee eines gemeinsamen Surfcamps gebracht hat. Surfen hat mich immer gereizt – aber eine ganze Woche an einem Ort verbringen, nur um am Ende vielleicht eine Welle zu stehen? Auch das klang nicht wirklich nach meinen Urlaubsvorstellungen. Doch beide Ideen zusammen ergänzten sich perfekt: Wenn ich ohnehin für das Surfen an einem Ort gebunden bin – warum dann nicht gleich Arbeit und Wellen kombinieren?

So startete unsere gemeinsame Workation. Wir entschieden uns (zum Glück!) gegen das Surfcamp und buchten ein ruhiges, zweigeschossiges AirBnB mit Rückzugsmöglichkeiten und stabilem WLAN. Und was soll ich sagen? Ich bin begeistert – und habe meine Skepsis (unter den richtigen Rahmenbedingungen) vollständig abgelegt.

Am Ende gibt es insbesondere drei Faktoren, die die Arbeitswoche zu einer der angenehmsten Arbeitswochen dieses Jahres gemacht haben:

1. Klare Abgrenzung zwischen Arbeit und Freizeit

Unsere Surfstunden waren fest terminiert. Ich habe von 7 bis 10:30 Uhr gearbeitet, bin dann für drei Stunden ins Wasser und um 13:30 saß ich wieder erfrischt und gut gelaunt am Laptop. Der Arbeitstag ging dann oft bis 18 oder 19 Uhr – aber mit müden Muskeln und frischem Kopf war das überraschend angenehm. Der erwartete psychologische Druck, weder der Arbeit noch dem Urlaub gerecht zu werden, kam bei mir gar nicht erst auf.

2. Gemeinsames Arbeiten 

Ich arbeite normalerweise entweder allein im Homeoffice oder beim Kunden vor Ort. Im Homeoffice bin ich sicherlich effizient und flexibel, aber der monotone Videocall-Alltag ist oft ermüdend.  Beim Kunden versuche ich persönliche Interaktionen zu maximieren, Besprechungen möglichst vor Ort abzuhalten und checke in der Zwischenzeit hastig meine Mails, die während der letzten Präsenzbesprechung liegen geblieben sind. Das Paradox, dass eine flexible und selbstbestimmte Arbeitswelt jemanden einsam machen kann, kenne ich also zu genüge. 

Daher war ich positiv überrascht, wie angenehm es ist, mit jemandem außerhalb des eigentlichen Arbeitsalltages zusammenzuarbeiten. Erfolge, wie etwa eine gewonnene Ausschreibung, konnten schnell über den Küchentisch geteilt werden, kurze Rückfragen direkt geklärt werden, und in unmotivierten Momenten konnte man sich gut über die Learnings der heutigen Stunde austauschen. Mich hat es echt positiv überrascht, wie gut das Arbeitssetting funktioniert – auch wenn ich mich auf meinen ergonomischen Bürostuhl zuhause in Köln sehr freue.

3. Die Freude auf den Feierabend

Zu Hause empfinde ich Termine nach der Arbeit oft als Belastung („Wir müssen um 18 Uhr los, aber die Präsentation muss noch raus!“). In unserem kleinen Haus in Lacanau hingegen lief die Zeit langsamer. Ob wir um 18 oder 20 Uhr zum Strand gingen, war egal. Gleichzeitig stimmen kleine Kommentare schon frühzeitig auf die Perspektive ein, bald schon wieder mit Schlägern, Ball und Badehosen zum Strand aufzubrechen. Und wenn es später wurde – dann eben zum Sonnenuntergang.

Und was hat zum Erfolg beigetragen?

Natürlich war diese Woche auch deshalb so gelungen, weil einige Voraussetzungen stimmten:

• Infrastruktur: Ich habe bewusst aufgerüstet – mit einem zweiten Monitor und neuen Noise-Cancelling-Kopfhörern.
  
• Abstimmung im Projekt: Auch im Projektalltag habe ich meine Workation abgestimmt und klar kommuniziert, was zur Folge hatte, dass ich in vielen Regelmeetings für eine Woche aussetzen durfte. Hierdurch konnte ich deutlich selbstbestimmter meinen Arbeitsalltag gestalten und habe mich verstärkt kreativen oder strategischen Themen gewidmet. (Wobei ich mir trotzdem viel zu viel vorgenommen habe – irgendwas Operatives ist immer).
  
• Rückzugsmöglichkeiten: Unser AirBnB war ruhig und groß genug. Im Surfcamp wäre fokussiertes Arbeiten – egal wie gut die Kopfhörer sind – unmöglich gewesen.
  

Was nehme ich mit?

Eine Woche Workation, nur um mal woanders zu arbeiten, reizt mich weiterhin wenig. Aber kombiniert mit einer Aktivität und guten Freunden wird es definitiv nicht das letzte Mal gewesen sein.

Ansonsten sind mir diese Woche nochmals einige der Herausforderungen, welche mit der dazugewonnen Flexibilität durch „New Work” entstanden sind, schmerzlich bewusst geworden:

• Pausen machen produktiv: Die sportliche Aktivität zwischendurch hat mich frischer, motivierter und (wie ich finde) leistungsfähiger gemacht. Soweit der Projektalltag dies erlaubt, möchte ich versuchen auch in Zukunft längere Pausen einzuplanen und nicht für x Stunden alleine im Homeoffice zu sitzen – auch wenn mein Fitnessstudio sicherlich nicht ganz mit dem Atlantik mithalten kann.
  
• Wir haben zu viele Meetings. Punkt.: Dieses Thema höre ich bei jedem Kunden – und nehme es mir künftig für meinen Beratungsalltag noch bewusster vor, diese zu hinterfragen und zu reduzieren.
  

Und ja: Ich habe mehr als nur eine Welle gestanden.

David bleibt der talentiertere Surfer – aber ich bin stolz auf meine Fortschritte. Und: Die Kombination aus Arbeit und Wellen funktioniert. Ich werde es definitiv wiederholen.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Warum Barrierefreiheit mehr ist als nur eine gesetzliche Vorgabe

Viele Unternehmen betrachten digitale Barrierefreiheit lediglich als eine gesetzliche Pflicht, die es zu erfüllen gilt. Doch wer sich nur auf die Mindestanforderungen konzentriert, verpasst enormes Potenzial.

Barrierefreiheit ist nicht nur ein Zeichen für soziale Verantwortung – sie bietet handfeste wirtschaftliche Vorteile:

In diesem Artikel zeigen wir Ihnen, wie Unternehmen langfristig von Barrierefreiheit profitieren und wie sie A11Y erfolgreich in ihre digitale Strategie integrieren können.

1. Wirtschaftliche Vorteile: Warum Barrierefreiheit ein Wettbewerbsvorteil ist

1.1 Größere Reichweite & neue Zielgruppen erschließen

15 % der Weltbevölkerung leben mit einer Behinderung – das sind über 1 Milliarde Menschen mit einer kollektiven Kaufkraft von über 8 Billionen US-Dollar (Quelle: The Return on Disability Report).

Wer eine barrierefreie Website anbietet, öffnet seine Angebote für:

• Menschen mit Seh-, Hör- oder Mobilitätseinschränkungen.
• Ältere Nutzer, die auf größere Schrift oder einfache Bedienung angewiesen sind.
• Kunden mit temporären Einschränkungen (z. B. gebrochener Arm, schlechte Lichtverhältnisse).
  

Fallbeispiel: Ein Online-Shop, der seine Navigation und Checkout-Prozesse barrierefrei optimiert hat, konnte seine Conversion-Rate um 20 % steigern, da mehr Kunden ihren Kauf erfolgreich abschließen konnten.

1.2 Verbesserte Nutzererfahrung & höhere Conversion-Rate

Eine barrierefreie Website ist für alle Nutzer einfacher zu bedienen. Durch klare Navigation, optimierte Formulare und eine bessere Struktur wird die User Experience erheblich verbessert.

Höhere Verweildauer: Nutzer bleiben länger auf einer Website, die gut lesbar und leicht verständlich ist.
Geringere Absprungraten: Komplexe oder schlecht bedienbare Websites führen zu Frustration – und Nutzer springen ab.
Mehr abgeschlossene Transaktionen: Besonders im E-Commerce ist eine barrierefreie Kaufabwicklung ein entscheidender Faktor.

Fallbeispiel: Ein Finanzdienstleister reduzierte seine Support-Anfragen um 35 %, nachdem er seine Online-Formulare für Screenreader-Nutzer optimiert hatte.

1.3 Barrierefreiheit als SEO-Booster für mehr organischen Traffic

Suchmaschinen wie Google bevorzugen barrierefreie Websites. Warum?
Semantischer HTML-Code mit klaren Strukturen wird von Google besser verstanden.
Alternativtexte für Bilder helfen nicht nur Screenreadern, sondern auch der Bildersuche.
Schnellere Ladezeiten durch optimierte Inhalte verbessern das Google-Ranking.

Google’s Algorithmus ist darauf ausgelegt, barrierefreie Inhalte besser zu bewerten. Unternehmen, die A11Y umsetzen, profitieren also ganz automatisch von einer besseren Auffindbarkeit in den Suchergebnissen.

Fallbeispiel: Eine Nachrichten-Website implementierte barrierefreie Maßnahmen und steigerte ihre Sichtbarkeit in der Google-Suche um 27 %.

2. Erfolgreiche Unternehmen setzen auf Barrierefreiheit – Praxisbeispiele

2.1 Apple – Vorreiter in Sachen digitale Inklusion

Apple setzt seit Jahren auf eingebaute Barrierefreiheitsfunktionen, darunter:

• VoiceOver (Screenreader für blinde Nutzer).
• Hohe Kontraste & Farbfilter für Menschen mit Sehschwäche.
• AssistiveTouch für motorisch eingeschränkte Nutzer.

Erfolg: Apple hat eine treue Nutzerbasis in der inklusiven Tech-Community aufgebaut, die ihre Produkte bevorzugt.

2.2 LinkedIn – Mehr Reichweite durch inklusive Inhalte

LinkedIn hat eine Funktion eingeführt, mit der Nutzer Alt-Texte für Bilder hinzufügen können. Dadurch sind Beiträge für blinde und sehbehinderte Menschen verständlicher.

Erfolg: Die Engagement-Rate auf barrierefreien Posts stieg messbar an.

3. Strategische Maßnahmen für Unternehmen – So gelingt langfristige Barrierefreiheit

Barrierefreiheit ist kein einmaliges Projekt – sie muss langfristig in digitale Strategien integriert werden.

Schritt 1: A11Y als festen Bestandteil der Unternehmenskultur etablieren

• Barrierefreiheit von Anfang an in neue Web-Projekte integrieren.
• Mitarbeiterschulungen durchführen, um A11Y-Kompetenzen zu stärken.
• Externe Experten einbinden, falls internes Know-how fehlt.

Schritt 2: Regelmäßige Audits & Optimierungen durchführen

• Website & digitale Plattformen jährlich auf Barrierefreiheit prüfen.
• Nutzerfeedback einholen und Probleme kontinuierlich beheben.
• Technische Standards (WCAG 2.1) regelmäßig updaten.

Schritt 3: Barrierefreie Inhalte & Kommunikation sicherstellen

• Marketingmaterialien inklusiv gestalten (z. B. Untertitel in Videos, barrierefreie PDFs).
• Alternativtexte für alle Grafiken in Blogartikeln & Social Media nutzen.
• Klare, verständliche Sprache in Kundenkommunikation & Websites verwenden.

Fazit

Barrierefreiheit ist kein Kostenfaktor, sondern eine Investition in nachhaltigen Erfolg. Unternehmen, die sie konsequent umsetzen, profitieren von:

Lassen Sie uns gemeinsam eine digitale Welt für alle schaffen! Kontaktieren Sie uns für eine unverbindliche Erstberatung und starten Sie Ihre A11Y-Optimierung noch heute.

Unsere Expertise

Mit unserer erfahrungsreichen Expertise unterstützen wir Unternehmen bei der barrierefreien Gestaltung ihrer digitalen Angebote. Unsere Dienstleistungen umfassen:

• Technische Umsetzung: Von der Optimierung bestehender Seiten bis hin zur Erstellung neuer, barrierefreier Lösungen.
• Barrierefreiheits-Audits: Wir prüfen Ihre Website auf Konformität mit den WCAG-Standards.
• Strategieberatung: Wir helfen Ihnen, Barrierefreiheit strategisch in Ihre digitalen Prozesse zu integrieren.
  

Besuchen Sie auch gerne für mehr Informationen unsere Website speziell zu diesem Thema!

atra.consulting/barrierefreiheit

Barrierefreiheit

Machen Sie Ihre Website barrierefrei – für mehr Reichweite und rechtliche Sicherheit! Wir helfen Unternehmen, digitale Angebote inklusiver, zugänglicher und gesetzeskonform zu gestalten.

Lassen Sie uns gemeinsam die digitale Welt inklusiver gestalten!

In einem kostenlosen Erstgespräch analysieren wir den aktuellen Stand Ihrer Website und zeigen Ihnen konkrete Maßnahmen auf, wie Sie sie für eine breitere Zielgruppe zugänglich machen können. So verbessern Sie nicht nur die User Experience, sondern stärken auch Ihre Marke und steigern Ihre Reichweite.

Kontaktieren Sie uns jetzt und machen Sie den ersten Schritt zu einer digitalen Zukunft, die niemanden ausschließt!

Ihr Ansprechpartner

Timo Kaiser

Senior Software Engineer Consultant
Web-Entwickler / A11Y-Spezialist

t.kaiser@atra.consulting
+49 1520 2380444

Timo kontaktieren

Barrierefreiheit als Erfolgsfaktor

Digitale Barrierefreiheit sorgt nicht nur für eine bessere Nutzererfahrung, sondern wird für viele Unternehmen ab 2025 zur Pflicht. Doch wie setzt man eine barrierefreie Website oder einen Online-Shop konkret um?

Dieser Artikel zeigt Ihnen die wichtigsten Maßnahmen, um Ihre Website zugänglich, nutzerfreundlich und gesetzeskonform zu gestalten. Dabei orientieren wir uns an den Web Content Accessibility Guidelines (WCAG) – dem internationalen Standard für digitale Barrierefreiheit.

1. Die drei Stufen der WCAG – Welche Anforderungen gelten?

Die Web Content Accessibility Guidelines (WCAG) definieren drei Stufen der Barrierefreiheit:

A (Basisanforderungen):

• Alternative Texte für Bilder, damit Screenreader sie erfassen können.
• Inhalte müssen per Tastatur bedienbar sein (z. B. keine Mauspflicht).
• Kein automatisches Abspielen von Videos oder Audiodateien.

AA (Empfohlen für Unternehmen – Standard für gesetzliche Vorgaben):

• Hohe Farbkontraste zwischen Text und Hintergrund.
• Untertitel für Videos & Alternativen für Audio-Inhalte.
• Klare Navigationsstruktur & konsistentes Design.

AAA (Höchster Standard):

• Gebärdensprachvideos für hörgeschädigte Nutzer.
• Einfache Sprache für kognitive Barrierefreiheit.
• Keine Zeitlimits für Eingaben (z. B. Formulare).

Empfehlung: Unternehmen sollten mindestens Stufe AA umsetzen, da dies gesetzliche Anforderungen (BFSG ab 2025) erfüllt und die beste Balance zwischen Aufwand und Nutzen bietet.

2. Technische & gestalterische Maßnahmen für eine barrierefreie Website

2.1 Barrierefreie Texte & Inhalte

• Kurze, verständliche Sätze & klare Struktur (Überschriften, Absätze, Listen).
• Alternativtexte für Bilder & Icons, damit Screenreader sie interpretieren können.
• Einfache Sprache verwenden, falls komplexe Themen erläutert werden.
• Keine alleinige Nutzung von Farben zur Informationsvermittlung (z. B. Fehlermeldungen müssen mehr als nur eine Farbänderung haben).

2.2 Design & Usability optimieren

• Hoher Farbkontrast (mind. 4,5:1 zwischen Text & Hintergrund gemäß WCAG 2.1 AA).
• Skalierbare Schriftgrößen & flexible Layouts, um Lesbarkeit zu gewährleisten.
• Keine flackernden Animationen oder schnell blinkenden Inhalte, um epileptische Anfälle zu vermeiden.
• Konsistente & logische Navigation, damit Nutzer sich leicht orientieren können.

2.3 Technische Umsetzung & Entwicklung

• Semantisches HTML (richtige Nutzung von <h1>–<h6>, <nav>, <main>, <article> für eine logische Seitenstruktur).
• ARIA-Attribute nutzen, um Screenreader zu unterstützen.
• Tastaturfreundliche Bedienung – Alle interaktiven Elemente müssen ohne Maus nutzbar sein.
• Formulare mit eindeutigen Labels & Fehlermeldungen, damit Nutzer verstehen, was von ihnen verlangt wird.

3. Praktische Tools zur Überprüfung der Barrierefreiheit

Um zu testen, ob Ihre Website barrierefrei ist, gibt es zahlreiche kostenlose Tools:

Automatisierte Test-Tools für Unternehmen & Entwickler

Google Lighthouse → Testet Barrierefreiheit & SEO in Chrome DevTools.
WAVE (WebAIM Accessibility Tool) → Analysiert Farbkontraste, Alternativtexte & Struktur.
axe DevTools → Browser-Erweiterung für Entwickler zur WCAG-Prüfung.

Manuelle Tests & Screenreader-Simulationen

NVDA (NonVisual Desktop Access) → Kostenloser Screenreader für Windows zur Live-Prüfung.
VoiceOver (Mac/iOS) → Eingebauter Screenreader für Apple-Geräte.
Keyboard-Only-Testing → Alle Funktionen einer Website ohne Maus navigieren und testen.

4. Roadmap zur Umsetzung – So machen Unternehmen ihre Website barrierefrei

Schritt 1: IST-Analyse & Bewertung

• Testen Sie Ihre Website mit Analyse-Tools, wie Lighthouse, WAVE oder axe DevTools.
• Notieren Sie alle Probleme, die in der Analyse auftreten.
• Nutzen Sie einen Screenreader & testen Sie die Navigation per Tastatur.

Schritt 2: Priorisierung & Strategie definieren

• Fokus auf Stufe AA der WCAG, um gesetzliche Anforderungen zu erfüllen.
• Wichtige Seiten & Funktionen zuerst optimieren (Startseite, Checkout-Prozesse).
• Falls nötig: Externe Experten für Barrierefreiheit hinzuziehen.

Schritt 3: Umsetzung & Testing

• Technische Anpassungen im Frontend & CMS umsetzen.
• Nach jeder Änderung erneut mit Test-Tools prüfen.
• Live-Tests mit echten Nutzern durchführen, z. B. mit Personen aus der Zielgruppe.

Schritt 4: Kontinuierliche Optimierung

• Regelmäßige Audits durchführen & Barrierefreiheit langfristig in den Entwicklungsprozess integrieren.
• Team-Schulungen zu A11Y-Standards durchführen.
• Feedback von Nutzern sammeln & Optimierungen umsetzen.

Ein Beispiel aus der Praxis

Wie ein mittelständischer Online-Shop Barrierefreiheit erfolgreich umgesetzt hat

Ausgangssituation:
Ein mittelständischer Anbieter für Bürobedarf betrieb seit Jahren einen gut laufenden Online-Shop. Die Website war funktional, aber nicht barrierefrei. Erste Nutzerhinweise und eine Lighthouse-Analyse zeigten: schlechte Farbkontraste, unbeschriftete Buttons und eine fehlende Tastaturnavigation erschwerten vielen Kundengruppen die Nutzung.

Umsetzung:
Das Unternehmen beauftragte eine Agentur mit einem WCAG-Audit. Die Optimierungen erfolgten in vier Phasen:

1. Analyse & Priorisierung: Fokus auf Stufe AA der WCAG.
2. Technische Umsetzung: Navigation per Tastatur, kontrastoptimiertes Design, saubere HTML-Struktur, Alt-Texte.
3. Testing: Kombination aus Lighthouse, WAVE und Tests mit NVDA und VoiceOver.
4. Launch & Monitoring: Veröffentlichung der optimierten Version, begleitet von einem barrierefreien Newsletter.

Ergebnis:
✅ Die Absprungrate sank um 18 %
✅ Die Conversion-Rate stieg in mobilen Ansichten um 24 %
✅ Es kamen gezielte Anfragen von Großkunden, die auf Barrierefreiheit achten
✅ Das Unternehmen wurde als vorbildlich im Branchennewsletter erwähnt

Fazit & Ausblick auf den nächsten Artikel

Barrierefreiheit ist kein einmaliges Projekt – sondern ein Bekenntnis zu Nutzerfreundlichkeit und digitaler Qualität. Es ist ein kontinuierlicher Prozess, der sowohl technische als auch gestalterische Maßnahmen erfordert. Doch der Aufwand lohnt sich: Eine barrierefreie Website verbessert die Usability, sorgt für eine größere Reichweite und erfüllt gesetzliche Vorgaben. Unternehmen, die hier investieren, profitieren auf allen Ebenen.

Lesen Sie im dritten Teil der Serie, wie Unternehmen langfristig von Barrierefreiheit profitieren – mit echten Erfolgsbeispielen und strategischen Tipps!

Unsere Expertise

Mit unserer erfahrungsreichen Expertise unterstützen wir Unternehmen bei der barrierefreien Gestaltung ihrer digitalen Angebote. Unsere Dienstleistungen umfassen:

• Technische Umsetzung: Von der Optimierung bestehender Seiten bis hin zur Erstellung neuer, barrierefreier Lösungen.
• Barrierefreiheits-Audits: Wir prüfen Ihre Website auf Konformität mit den WCAG-Standards.
• Strategieberatung: Wir helfen Ihnen, Barrierefreiheit strategisch in Ihre digitalen Prozesse zu integrieren.
  

Besuchen Sie auch gerne für mehr Informationen unsere Website speziell zu diesem Thema!

atra.consulting/barrierefreiheit

Barrierefreiheit

Machen Sie Ihre Website barrierefrei – für mehr Reichweite und rechtliche Sicherheit! Wir helfen Unternehmen, digitale Angebote inklusiver, zugänglicher und gesetzeskonform zu gestalten.

Lassen Sie uns gemeinsam die digitale Welt inklusiver gestalten!

In einem kostenlosen Erstgespräch analysieren wir den aktuellen Stand Ihrer Website und zeigen Ihnen konkrete Maßnahmen auf, wie Sie sie für eine breitere Zielgruppe zugänglich machen können. So verbessern Sie nicht nur die User Experience, sondern stärken auch Ihre Marke und steigern Ihre Reichweite.

Kontaktieren Sie uns jetzt und machen Sie den ersten Schritt zu einer digitalen Zukunft, die niemanden ausschließt!

Ihr Ansprechpartner

Timo Kaiser

Senior Software Engineer Consultant
Web-Entwickler / A11Y-Spezialist

t.kaiser@atra.consulting
+49 1520 2380444

Timo kontaktieren