Du sitzt als Designer vor einem fertigen Mockup. Ein Padding-Wert ist falsch – drei Pixel zu viel. Früher hättest du ein Ticket aufgemacht oder einen Engineer angeschrieben. Oder es ignoriert. Vielleicht wäre der Fehler erst in der nächsten Sprint-Planung aufgefallen. Heute öffnest du einen Code-Editor, kopierst den Prompt, fragst die KI, und zwei Minuten später ist der Fix live. Keine Abhängigkeit, keine Wartezeit. Dein Produkt sieht aus, wie du es haben willst – ohne Umwege.
Ein aktueller Artikel beschreibt diesen Alltagswandel. Der Autor befragte neun Designer aus Unternehmen wie Shopify, Meta und kleinen Startups zu ihren Erfahrungen mit KI-unterstütztem Coden. Er erwartete ein Gespräch über Tools und Workflows. Stattdessen fand er eine grundlegendere Debatte: Was ist der Kern des Design-Jobs? Was macht KI mit der Identität der Designer? Wie verändert sich das Verhältnis zu den Engineers, die plötzlich mit denselben KI-Werkzeugen arbeiten?
Die Rückkehr zur Freude am Machen
Vier der neun Designer sagten, das Bauen funktionierender Produkte – nicht nur Mockups – bringe sie zurück zu dem, was sie ursprünglich zum Design gebracht hat. Roland Tiango, der bei Headway, Faire und Shopify gearbeitet hat, sagte: „Ich liebe es, dass das Pushen von Code Designern erlaubt, wieder die Begeisterung und das Versprechen des einfachen ‚Dinge-Machens‘ zu erfahren. Es ist der Teil des Jobs, in den wir uns zuerst verliebt haben – aber auch der Teil, der aus vielen guten Gründen oft eingeschränkt war. Der gesamte Produktentwicklungsprozess wird kürzer. Das erlaubt Designern hoffentlich, in ihre Stärken zu gehen.“ Der Autor teilt diese Begeisterung. Designer steckten zu lange in der Vorschlagsrolle fest, abhängig von anderen, um ihre Ideen außerhalb von Canvas-Tools zu testen. Viele sind erleichtert, dass die Ketten endlich abfallen. Jeffrey Kalmikoff von Motive, Meta und Uber ergänzt: „PRs als normaler Bestandteil der Designarbeit erlauben Designern, sich durchs Machen zu beschweren. Je weiter die Arbeit vom Hypothetischen entfernt ist, desto besser. Designer übernehmen mehr Verantwortung dafür, die Arbeit zu finden, statt gesagt zu bekommen, was sie tun sollen. Zugang zu Daten-Tools erlaubt jedem, Ideen zu validieren. Zugang zu Code erlaubt jedem, echte Dinge zu bauen. Design-Tools sind jetzt eine weitere Art, eine Idee auszudrücken, nicht die einzige.“
Nicht neu – aber jetzt zugänglicher
Designer, die programmieren, gibt es nicht erst seit der KI-Ära. Der Autor selbst lernte sechs Programmiersprachen und baute in seiner frühen Karriere Design und Bau selbst. Programmieren war bei vielen frühen Tech-Jobs Pflicht. Jessica Harllee, die bei Shopify, Faire und Etsy gearbeitet hat, programmiert seit 15 Jahren als Product Designer. Der Unterschied heute: „KI senkt die Einstiegshürde. Der Zugang zu Entwicklertools verkürzt den Kreislauf zwischen dem Erkennen eines Problems und der tatsächlichen Behebung.“ Sie scannt ständig die Teile von Shopify, die sie verantwortet, und repariert kleine Details, die sonst im Backlog gelandet wären. Auch Michael Hintze (Google, Meta, Apple) sieht Vorteile bei kleinen Änderungen: „Kleine Optimierungen wie Farbaktualisierung, Padding-Korrektur, Schriftwechsel können Kommunikationskosten eliminieren und Probleme schneller beheben, wenn das Team es zulässt, ohne zusätzliche Reviews.“
Die Schattenseite: Auflösung der Rollen
Doch es gibt eine Kehrseite. Der Autor beschreibt ein zweites Phänomen: Die Jobbeschreibung löst sich auf. Für manche ein Silberstreif, für andere eine Quelle der Angst. Kim Lenox (Adobe, Zendesk, LinkedIn) sagt: „Die letzten 15 Jahre hatten klar definierte, skill-spezifische Rollen. Man wusste, in welcher Spur man schwimmt, wie man zusammenarbeitet und wie man befördert wird. Das hat sich geändert. Wir sind zurück in der Dotcom-Ära: keine Jobbeschreibungen, keine Rollendefinition. Es geht um Experimentierfreude und Komfort mit Ambiguität. Was zählt, sind Design-Grundlagen, Neugier, Systemdenken, eine unterscheidbare Perspektive und die Kreativität, sich auszudenken, was es noch nicht gibt.“ Für eine andere Gruppe ist Code der am stärksten standardisierte Schritt im Workflow – kein Kernteil der Identität, sondern Mittel zum Zweck. Andrew Milmoe (Blue Origin, GE) sagt: „Code sind die letzten fünf Prozent meines Jobs. Mich interessiert viel mehr, KI zu nutzen, um den Problemraum zu verstehen, Seite an Seite mit Nutzern zu sein und sicherzustellen, dass das System Reibung reduziert und Produkte priorisiert werden, die Kunden und Business Wert bringen. Viel zu viele Leute assoziieren UX-Design mit dem Pushen von Code in Produktion. Das ist der einfachste Teil des Workflows.“
Die Angst vor der falschen Priorität
Die Angst ist nicht, dass Designer nicht coden können. Sondern dass sie Ausführung mit dem Job verwechseln und ihre Zeit in Velocity stecken, statt das Richtige zu bauen. Michael Hintze, der selbst einen CS- und Mathe-Hintergrund hat, bevor er zum Design wechselte, sagt: „Wenn ich Engineer hätte werden wollen, wäre ich es geworden. Ich entscheide mich bewusst dafür, meine Zeit auf die weniger ausführenden Aspekte zu konzentrieren. Welches Problem sollten wir lösen? Warum ist es am wichtigsten? Haben wir eine neuartige Lösung? Passt sie in alles andere rein? Engineers brauchen keine Hilfe beim Pushen von mehr Code. Sie brauchen Hilfe bei der Entscheidung, was gebaut werden soll, warum, und Unterstützung von der Organisation, um gute Ideen nicht sterben zu lassen.“
Nicht jeder Designer ist gleich
Kim Lenox, die Teams durch diese Transformation führt, sagt ehrlich: Nicht jeder Designer ist gleich. „Manche fühlen sich wohl damit, im Abstrakten zu arbeiten, Code zu schreiben, Ergebnisse zu sehen und zu wissen, wo sie justieren müssen. Andere haben nicht die Fähigkeiten oder die Geduld. Manche erleben Frustration und verlieren Zeit damit, Code zu bändigen. Andere fühlen sich ermächtigt, aber auch unter Druck, Energie in Dinge zu stecken, die sie nicht gern tun. Visuelle Menschen arbeiten lieber mit UX-Elementen.“ Und dann gibt es den Teil, den man nur durchs Tun versteht: Echte Software mit einem LLM zu bauen bedeutet viel Hin und Her, Warten, Kompilieren und Verhandeln mit einem manchmal inkompetenten Agenten. Der Output ist oft mangelhaft. Ein anonymer Designer: „Shipping ist 100 % schneller, aber die Qualität ist beim ersten Release niedriger.“ Ein anderer: „Die Ausfallzeiten sind real. Ich bin es gewohnt, stundenlang in Figma Deep Work zu machen. Jetzt muss ich durch das Hin und Her mit LLMs multitasken, um Leerlaufzeiten zu nutzen.“ Jeffrey Kalmikoff sieht darin eine neue Kernfähigkeit: „Rationales Multitasking – mehrere Projekte gleichzeitig verfolgen, ohne auszubrennen.“
Die Ingenieurs-Perspektive
Die Designer sprachen offen darüber, wie ihre Engineering-Kollegen die Entwicklung sehen. Der gemeinsame Nenner: Wer seine Grenzen kennt und die richtige Problemgröße wählt, entscheidet, ob ein Pull-Request eines Designers Geschenk oder Kopfschmerz ist. Oscar von Hauske Valtierra (Meta, Google) sagt: „Ingenieure wissen am besten, wie Systeme funktionieren und wo Dinge brechen. Es hängt vom Maßstab ab. UI in einem Startup auszuliefern ist nicht dasselbe wie in einem globalen Megakonzern.“ Michael Hintze warnt: „Alles, was komplexer ist als einfache Änderungen, ist oft Zeitverschwendung für einen Designer, weil ein Engineer die Aufgabe 100-mal effizienter erledigt. Vibe-Coding ist nicht dasselbe wie Produktionscode und kann Unmengen an Problemen schaffen.“ Pointiert formuliert es Hang Xu, ein ehemaliger Designer und Recruiter: „Ich habe mit mehreren Engineers bei KI-fokussierten Unternehmen gesprochen. Ihr privates Feedback war frustrierend. Während es sich für Designer ermächtigend anfühlt, erzeugt es für die Entwickler, die diese Initiativen unterstützen, jede Menge zusätzliche Arbeit. KI-Mandate führen dazu, dass viele von uns schlechte Kollegen werden, im Bestreben, KI-native zu wirken.“ Das verlagert die Frage vom „Ist das gut für mich?“ zum „Ist das gut für das Team?“ Designer beschweren sich oft über andere Funktionen, die halbgares Zeug abliefern. Hier besteht die Gefahr, genau diese Funktion zu werden.
Wer wacht über die Qualität?
Kim Lenox sagt: „Manche Menschen sind einfach besser in Ästhetik als andere, auch wenn sie keine Designer sind. Unmengen von Fehlern gehen live und müssen entdeckt und analysiert werden. Der kulturelle Drang nach Geschwindigkeit auf Kosten der Qualität ist der Übeltäter, nicht die Menschen hinter dem Code.“ Jeffrey Kalmikoff betont: „Es ist weiterhin wichtig, dass jede Funktion einen verantwortlichen Ansprechpartner für Qualität hat, unabhängig davon, wer die Arbeit ausführt.“ Jessica Harllee mit tiefem technischen Hintergrund lebt den Owners-Mindset: Sie jagt „broken windows“ in der User Experience und genießt die Reparatur ohne Bürokratie. Aber selbst sie macht nur, was sinnvoll ist. Der Mittelweg: kleine Fixes sofort, große Entscheidungen – wann, warum, was gebaut wird – bleiben in den Händen derer, die das Gesamtsystem verstehen.
KI-unterstützte Code-Erstellung ist weder Allheilmittel noch Bedrohung. Sie verschiebt die Spielregeln für Designer grundlegend. Wer seine Stärken kennt – ob im Systemdenken, in der Nutzerforschung oder der Ästhetik – kann KI nutzen, um schneller zu liefern und mehr Verantwortung zu übernehmen. Wer sich im Code verliert, riskiert, seine wertvollsten Fähigkeiten zu untergraben. Für Teams bedeutet das: klare Kommunikation, Respekt vor Stärken, bewusster Umgang mit Qualität. In einer Welt, in der alles zehnmal schneller shipped, ist Qualität das Erste, was ohne echte Sorgfalt und Leitplanken über Bord geht. Die Frage ist nicht, ob Designer coden können oder sollen, sondern ob sie wissen, wann sie es lassen sollten.
Quelle: rongoldin.substack.com
