.jpg)
Wer schreibt bei euch eigentlich das Frontend? In unserem Team: die Designer:innen. Klingt erstmal falsch, ist aber seit einigen Monaten unser Alltag. Früher haben mein UX-Kollege Florentin und ich Frontendlösungen konzipiert, manchmal auch Prototypen gebaut und dann an unsere Softwareentwickler:innen übergeben. Heute setzen wir sie selbst in Code um, stellen Pull Requests und mergen am Ende in den Main. Möglich macht das Agentic Development: LLMs schreiben den Code, wir steuern Anforderungen, Qualität und Details.
Damit das funktioniert, braucht es allerdings mehr als ein Abo bei einem Modellanbieter. Es braucht einen Prozess. Wir haben uns unseren in den letzten Monaten Schritt für Schritt erarbeitet – und er sieht inzwischen so aus.
Von der Idee bis in den Main
Der Anfang ist klassisch. Es gibt ein Designkonzept als Wireframe. Damit findet ein Refinement statt und es wird die Backend-Entwicklung durch die Devs definiert und umgesetzt. Dann übernehmen wir und entwickeln das Frontend. Ist es fertig, stellen wir einen Pull Request, der mindestens dreimal reviewed wird, bevor gemerged wird. Zwischen Backend und Frontend liegt aber noch ein Schritt, der unseren Prozess besonders macht: der Handoff.
Der Handoff: von Mensch zu Mensch – und von KI zu KI
Bei der Übergabe erklären uns die Devs, wie das Backend gebaut wurde. Welche API-Endpunkte gibt es, wie funktionieren sie, welche Payloads erwarten sie? So weit, so normal.
Das Besondere: Wir übergeben nicht nur von Mensch zu Mensch, sondern auch von KI zu KI. Aus der Konversation zwischen Dev und LLM, in der das Backend entstanden ist, generiert ein Skill automatisiert ein Übergabedokument. Das speisen wir in unser LLM ein und starten damit in die Frontend-Entwicklung. Das Wissen aus der Entstehung des Backends geht also nicht verloren, sondern wandert direkt in den nächsten Arbeitsschritt.
Wie wichtig dieser Schritt ist, merkt man spätestens dann, wenn man ihn überspringt: Ohne Übergabe ins Frontend zu starten macht unsere Arbeit langsamer und fehleranfälliger.
Drei Reviews – und die Reihenfolge ist kein Zufall
Unser Pull Request durchläuft mindestens drei Reviews. Zuerst schaut jemand anderes aus dem Design drauf und konzentriert sich auf das Visuelle und die Interaktion. Danach reviewed mindestens ein LLM – und zwar bewusst ein Modell von einem anderen Hersteller als dem, mit dem wir das Projekt umgesetzt haben. Jedes Modell hat blinde Flecken, und ein fremdes Modell findet eher die Fehler, die das eigene übersehen hat. Es konzentriert sich primär auf technische Aspekte und korrigiert sie teilweise direkt. Erst in letzter Instanz reviewed ein:e Entwickler:in.
Diese Reihenfolge ist Absicht. Das Ziel: Die meisten Fehler sind bereits ausgemerzt, bevor der PR bei den Entwickler:innen ankommt – damit für sie möglichst wenig Arbeit übrig bleibt. Geben sie ihren Segen, wird in den Main gemerged.
Schnell konzipieren, sauber bauen
Unser größtes Learning steckt in der Trennung von Konzeption und Umsetzung. Wir konzipieren zwar direkt im Code, aber in einem separaten Repo, das genau dafür gedacht ist. Dort sind viele der Guardrails abgeschaltet, die man sonst hat – in diesem Fall in Ordnung, weil es nicht das Live-Produkt ist. Auf dem Konzept-Branch arbeiten wir meist mit kleineren, schnelleren, schlichten Modellen wie Sonnet. Es geht um Geschwindigkeit, nicht um Codequalität.
Ist das Konzept festgezurrt, fangen wir im Produkt-Repo auf einem neuen Branch von vorne an. Warum? Weil Konzeption kein geradliniger Prozess ist. Man trifft Entscheidungen, revidiert sie, probiert Abzweigungen aus – und diese Nicht-Linearität hinterlässt Spuren im Code. Also starten wir mit einem klaren Zielbild und langsameren, schlaueren Modellen (ab Opus-Niveau) sauber neu in die Umsetzung.
Daraus hat sich für uns eine Faustregel ergeben: Je größer die Ungewissheit, desto größer sollten das Modell und seine Effort-Stufe sein. Größere Modelle mit hohem Effort betreiben schlichtweg mehr Recherche.
Und noch ein Tipp, der sich bewährt hat: diktieren statt tippen. Wer Prompts per Mikrofon einspricht, beschreibt das Problem automatisch detaillierter und vollständiger. Das erhöht merkbar die Qualität des Outputs.
Wissensinseln vorbeugen
Eine Sache ist uns in den letzten Monaten deutlich aufgefallen: Früher haben wir in Figma gearbeitet, alle konnten auf dasselbe schauen und wunderbar kollaborieren. Heute arbeitet jeder von uns in seinen eigenen LLM-Konversationen. So entstehen Wissensinseln. Umso wichtiger ist es geworden, den Austausch zu ritualisieren – und das Tooling darauf anzupassen.
Dafür haben wir uns zwei Skills gebaut. Mit dem Context-Handoff-Kit lässt sich der Kontext aus einer Konversation so auslagern, dass Kolleg:innen über ihre eigenen LLMs darauf zugreifen können. Das Wissen ist konserviert, statt in einer privaten Konversation zu verstauben. Besonders praktisch, wenn jemand im Urlaub ist und Fragen zu einem Projekt aufkommen, an dem nur diese eine Person gearbeitet hat: Dann befragt man einfach das Kontext-Paket des Projekts.
Der zweite Skill kümmert sich um unsere Dokumentation nach außen. Während wir an einem Frontend-Feature arbeiten, wird der zugehörige Hilfecenter-Artikel automatisch mit aktualisiert. Das LLM kennt aus der Konversation den Kontext und die Änderungen, hat direkten Zugriff auf das Hilfecenter und arbeitet die Unterschiede direkt in den Artikel ein.
Was das für uns bedeutet
Kurz gesagt: Agentic Development erlaubt es uns als UX-Designer:innen, schneller zu konzipieren und diese Konzepte sauber selbst umzusetzen. Die Grenze zwischen Design und Entwicklung verschiebt sich bei uns im Team dadurch spürbar – nicht, weil Devs überflüssig würden, sondern weil sich die Arbeit neu verteilt: Sie bauen das Fundament und sichern am Ende die Qualität, wir bauen das, was unsere Nutzer:innen sehen. Und ehrlicherweise möchten wir nicht mehr zurück.
