Ich designe inzwischen mehr mit Claude als mit Figma

• Der Design-Workflow verlagert sich von Spezifikationsdokumenten und Figma-Mockups mit anschließender Implementierungsprüfung hin zu einem Ablauf, bei dem Prototyp-Features direkt in der echten Codebasis gebaut werden
• Copilot, Cursor und Gemini blieben bei Aufgaben wie Spielanpassungen, Produktbriefs und Wireframes hinter den Erwartungen zurück, aber in einer neu zu erlernenden Umgebung mit OCaml und Bonsai wurde AI-Unterstützung zu einem unverzichtbaren Bestandteil
• Ein umsetzungszentrierter Prozess, der damit beginnt, Probleme und Vorschläge als Prompt zu übergeben, und dann über Basisimplementierung, iterative Überarbeitung, Deployment in die Entwicklungsumgebung, Einholen von Nutzerfeedback bis zur Einreichung eines Features führt
• Ein Prototyp, der LLM-Prompting zu JSQL-Eingaben hinzufügte, führte zu vielen Iterationen bei Buttons, Shortcuts, Formulierungen, Prompts und Bestätigungsmeldungen; die Arbeit konzentrierte sich nicht auf Figma-Komponenten oder Dokumentformatierung, sondern auf echte Ergebnisse
• Designer können Ideen nun selbst in nutzbare Formen bringen, doch Prototypen, die wie fertige Features wirken, bringen neue Herausforderungen für Review-Prozesse und kreative Exploration mit sich

---

Von LLM-Skepsis zum unverzichtbaren Hilfswerkzeug

• Lange Zeit war ich jedes Mal enttäuscht, wenn ich LLMs benutzte, und immer wenn ich sie auf Aufgaben anwandte, die ich gut beherrschte, war die Qualität schlechter, als wenn ich es selbst gemacht hätte
• Im vergangenen Jahr nutzte ich Copilot und Cursor, um ein Spiel zu modifizieren, das ich gebaut hatte, aber keiner von beiden konnte eine funktionierende Änderung erzeugen; in meinem vorherigen Job versuchte ich mit Gemini Entwürfe für Produktbriefs und Wireframes zu erstellen, aber alles wurde verworfen
• Seit ich letzten Sommer zu Jane Street gekommen bin, musste ich viel Neues lernen, und bei Technologien wie OCaml und Bonsai, mit denen ich noch nicht vertraut war, spielte AI-Unterstützung eine unverzichtbare Rolle
• Die große Veränderung war, dass AI inzwischen sogar meinen sichersten Design-Workflow verändert hat

Echte Prototypen in der Codebasis statt Figma und Dokumenten

• Statt Spezifikationsdokumente zu schreiben, Figma-Mockups zu bauen, Vorschläge zu verfassen und die Implementierung mit Entwicklern abzustimmen, erstelle ich Prototyp-Features, die die Funktion in meinem Kopf tatsächlich ausführen
• Der tatsächliche Ablauf sieht so aus: Ich schreibe Sätze, die Problem und Vorschlag erklären, starte im Editor Build, Server und Claude und verwende diese Beschreibung dann als Prompt
  • Zuerst bringe ich die Grundfunktion zum Laufen, um die Möglichkeiten zu prüfen, und überarbeite sie dann beliebig oft iterativ
  • Ich spiele die Änderungen in die Entwicklungsumgebung ein, hole Nutzermeinungen ein und reiche dann ein Feature ein, sobald Form und Verhalten stimmen
  • Ein Feature entspricht bei Jane Street in etwa einem Pull Request
• Ein Prototyp-Feature in der echten Codebasis ist in fast jeder Hinsicht eine bessere Erfahrung als Mockups und Dokumente
• Ein jüngster Prototyp, der LLM-Prompting zu JSQL-Eingaben hinzufügte, funktionierte tatsächlich, und ich konnte ihn über mehrere Tage selbst im Einsatz testen
  • JSQL ist ein internes SQL-Dialekt, der in verschiedenen Tools für Nutzer verwendet wird
  • Claude ermöglicht freie und praktisch unbegrenzte Iteration, selbst bei der 50. Meinungsänderung oder bei kleinen Änderungswünschen
  • Verbessert wurden der Submit-Button, Keyboard-Shortcuts, Formulierungen, Prompts und sogar die erzeugten Bestätigungsmeldungen
• Solche Workflow-Verbesserungen hätten in meinem vorherigen Job Tage oder Wochen an Hin und Her zwischen Engineering und Design erfordert oder wären mit hoher Wahrscheinlichkeit gar nicht passiert
• Die Arbeit an diesem Feature floss nicht in Zwischenergebnisse wie das Erstellen von Figma-Komponenten oder das Anpassen von Dokumentlayouts, sondern in die Verbesserung des tatsächlichen Ergebnisses

Deutlich größerer Umfang in den letzten zwei Monaten

• Es dauerte eine Weile, bis ich zu diesem Ablauf kam; anfangs nutzte ich AI nur für kleine Aufgaben wie das Beheben kleiner UX-Unannehmlichkeiten
• Für große Ideen verwendete ich weiterhin Figma und Dokumente, und Versuche, sie mit Claude umzusetzen, scheiterten
• In den letzten zwei Monaten ist die Zahl der Situationen, in denen ich Figma öffne, stark zurückgegangen; verbesserte Modelle, mehr Tool-Erfahrung und die richtige Wahl des Umfangs kamen dabei zusammen
• AI funktionierte nicht nur für JSQL-Prompts, sondern auch für etwa sechs Prototypen mit Änderungen an Nutzeroberflächen, Datenmodellen und Bibliotheken
  • Einige Prototypen umfassten Diffs von mehr als 2000 Zeilen
  • Sie wurde auch für die Umsetzung interaktiver Prototypen einer neuen App verwendet, die in Figma entworfen wurde
  • Bei manchen neuen Apps wurde Figma ganz übersprungen und die visuelle Gestaltung von Anfang an direkt mit Claude iteriert

Mehr Handlungsspielraum für Designer und ein neu zu definierender Review-Prozess

• Ingenieure können bei einer Idee selbst einen funktionierenden Proof of Concept bauen, Designer müssen dagegen andere davon überzeugen, ihn für sie zu erstellen
• Bei Ideen wie „LLM-Prompting direkt im JSQL-Eingabefeld“ ist zu Beginn nicht klar, ob sie überhaupt machbar sind; wenn man jemand anderen um einen Prototyp bittet, kann das leicht Zeit verschwenden
• Manche Vorschläge erfüllen die Nutzeranforderungen womöglich nicht klar genug; wenn Claude eine Idee in eine reale Form bringt, können andere sie direkt benutzen und leichter beurteilen
• Der Nachteil ist, dass Reviewer etwas erhalten, das wie ein fertiges Feature aussieht, und es unklar wird, ob sie nur den Code prüfen oder auch ohne vorherige Mitgestaltung Input zum Feature geben sollen
• In der Designsprache ist das ungefähr so, als würde ein PM detaillierte Wireframes übergeben und bitten, sie einfach nur hübsch zu machen — keine besonders erfreuliche Art von Review-Arbeit
• Ein Vorschlag muss klar und vollständig sein, sollte von Engineering-Kollegen aber wie ein Figma-Mockup behandelt werden, also als etwas, an dem man gemeinsam im Designraum iteriert
• Die aktuelle Lösung ist ein kurzer Hinweis in der Feature-Beschreibung
  • Der Prototyp ist ein lebendes Vorschlagsdokument
  • Der Code kann verworfen werden
  • Die Rolle der Reviewer ist Feedback zu Design und User Experience
• Am Ende übernimmt der Reviewer die Idee und implementiert sie in einem separaten Feature; der Prototyp dient als Referenz, aber der Produktionscode liegt in der Verantwortung des Reviewers
• Im realen Arbeitsalltag wird noch immer ausgelotet, was sich in diesem neuen Workflow sinnvoll und stimmig anfühlt

Grenzen der Iteration und das Gefühl, wieder im echten Medium zu arbeiten

• Es gibt die Sorge, dass Design mit Claude von einer fließenden, kreativen Denkweise entfernt und in Iterationen innerhalb dessen gefangen hält, was Claude vermutlich erzeugen kann
• Wenn Änderungen wie in reifen Tools eher iterativ sind, ist das in Ordnung, aber beim Erschaffen von etwas Neuem besteht das Risiko, Ideen zu verpassen
• Als ich 2011 meine berufliche Laufbahn begann, wurde viel über designers should code diskutiert, und Kritiker argumentierten, dass große Ideenänderungen schwieriger werden, sobald man mit Programmierung beginnt
• Ich mochte es, Websites zu bauen und zu programmieren, und schrieb deshalb weiter Code; als Frontend-Frameworks wie React allgegenwärtig wurden und Frontend-Entwicklung komplexer wurde, entschied ich mich für Spezialisierung
• Eigene React-Projekte halfen mir dabei, mit Entwicklern zu interagieren, aber im Job verbrachte ich fast meine gesamte Zeit in Figma und Dokumenten
• Wäre ich schon vor LLMs zu Jane Street gekommen, wäre ich wahrscheinlich noch stärker in Figma verankert gewesen; und anders als JavaScript waren OCaml und Bonsai völlig neu, sodass sich technischer Beitrag wie etwas außerhalb meiner Reichweite angefühlt hätte
• Jetzt baue ich wieder echte Ergebnisse, arbeite in diesem Medium und habe stärker das Gefühl, alles ausprobieren zu können

[GN⁺]

Hacker-News-Kommentare

• Die Business-Seite bringt Anforderungen oft schon in Form einer von ihnen ausgedachten Lösung mit, und meistens ist das etwas wie eine Rube-Goldberg-Maschine, sodass man sie erst im Gespräch rückwärts analysieren muss, um bei den eigentlichen Anforderungen anzukommen
  Künftig werden sie wohl schon eine „fertige“ und „funktionierende“ Lösung mitbringen und noch weniger offen dafür sein, sich Design und Architektur im Ganzen anzusehen
  Es wird dann wohl heißen: „Man kann es doch einfach so bauen. Es ist fast fertig, warum brauchen wir noch X Personentage?“

  • Ich habe das schon gesehen, und es war von Anfang bis Ende mit Vibe Coding gebaut
    Der Nachteil ist, dass die Business-Seite nicht versteht, warum man diese App nicht einfach direkt in Produktion deployen kann
    Der Druck in Richtung „Mit AI geht es doch schneller“ wird größer, und am Ende wird es wohl davon abhängen, ob die Organisationsdynamik gesund ist
    Der Vorteil ist, dass die Idee deutlich gründlicher validiert wurde als bei einer Skizze auf einer Serviette
    Claude wird bereits nach Randfällen und Designentscheidungen gefragt haben, und vermutlich wurde irgendwann ausdrücklich gesagt: „Darum kümmere dich nicht, nimm es einfach an“ oder „Nach ein paar Versuchen gefällt mir diese Interaktion nicht, mach es anders“
    Im Moment ist der Druck „Was ist das Problem, deployt es einfach“ stark, dumm und demotivierend, also beinahe ein klarer Nettoverlust, aber wenn sich das einpendelt, könnte es für zukünftige Projekte auch ein Nettogewinn werden
  • Es kommt viel zu oft in der Form herein: „Es ist fast fertig, vor dem Produktions-Deployment braucht es nur noch ein paar kleine Anpassungen“
    Diese kleinen Anpassungen sind dann Dinge wie: Das Layout bricht auseinander, wenn der Browser nicht exakt 1920 px breit ist, Filter und Sortierung funktionieren gelegentlich nicht richtig, oder nach bestimmten Aktionen werden neue Werte in der App nicht korrekt aktualisiert
    Unabhängig vom Problem glaubt die Business-Seite dann schon, sie habe 95 % der Arbeit erledigt, und nimmt vorab an, dass „ein erfahrener Entwickler das schnell beheben kann“
  • In der Welt des Audio Engineering war so etwas eine Zeit lang häufig, als Home-Demos klanglich fast professionelle Qualität erreichten
    Die Leute gewöhnen sich an ihr vorhandenes Ergebnis und akzeptieren Veränderungen in einem neuen professionellen Mix nur schwerer
  • Bei uns bringt die Business-Seite die von ihr erdachte Lösung ebenfalls als Anforderung mit, und meist ist das nicht das, was der Kunde will
    Es gibt PMs, CSMs und TAMs mit dem Gespür dafür, Kundenprobleme in gut nutzbare Produktfunktionen zu übersetzen, aber wenn man die Problemdefinition überspringt und eine andere Funktionsorganisation die Lösung bauen lässt, endet das meist in einer Katastrophe, die Engineering und andere Ressourcen massiv verschwendet
    Wenn jemand schon mit einer Lösung ankommt, besteht ein hohes Risiko, dass man erst nach Monaten beim Bauen produktionsfähiger Software merkt, dass Kunden sie hassen, das eigentliche Problem nicht gelöst wird oder sogar neue Probleme entstehen
  • Das passiert gerade tatsächlich
    Nicht dort, wo ich jetzt arbeite, sondern an einer früheren Stelle, und es wurde trotz Datenverlust und Sicherheitsproblemen direkt in Produktion deployt

• Soweit ich weiß, ist Jane Street Investor bei Anthropic, das sollte man also mit bedenken

  • Das sollte man mit einer sehr großen Prise Salz nehmen
    Dazu kommt, dass im Juli 2025 Indiens Börsenaufsicht SEBI Jane Street vorwarf, über mehrere Gesellschaften hinweg Marktmanipulation betrieben zu haben, und ihnen den Marktzugang untersagte
  • So wie ich Jane Street verstehe, haben sie viel zu OCaml beigetragen und bauen auch eigene Web-Frameworks
    Ein großer Geldtopf braucht wohl viele Dashboards
    Der Designer scheint hier aber einen falschen Ansatz zu verfolgen und einer Art Ingenieurssehnsucht zu verfallen, bei der man den Prototyp so tief und realistisch wie möglich machen will
    Aber das ist nicht der wichtigste Teil von Designarbeit
    Am wichtigsten ist, dass das Richtige gebaut wird
    Fragen wie „Warum brauchen wir ein JSQL-Eingabefeld? Was wollen wir eigentlich wirklich? Welche anderen Wege gibt es?“ lassen sich oft besser mit Skizzen auf Papier, Meetings, Beobachtung und Diskussion klären
    Das ist besser, als sich zu früh auf ein bestimmtes Design zu verengen und dann in Diskussionen darüber abzurutschen, ob ein Button links oder rechts stehen soll oder wie sich ein LLM im Detail verhalten soll
  • Selbst wenn sie kein Investor wären, weiß ich nicht, wie sehr mich die Frontend-Design-Meinungen einer Quant-Trading-Firma interessieren sollten
  • Ganz HN wirkt inzwischen wie eine riesige AI-Werbetafel
  • Man muss nicht einmal einen leicht interessanten Blogpost eines zufälligen Mitarbeiters gleich als psychologische Kriegsführung lesen
    Wobei sie natürlich genau das wollen könnten

• Ich sehe das manchmal
  LLMs können derzeit nicht über Iteration hinausblicken, deshalb muss ich selbst außerhalb des Rahmens denken und fragen: „Wie wäre es aus dieser Perspektive?“, damit plötzlich eine neue Designrichtung entsteht
  Manchmal muss ich sogar ein Flussdiagramm bauen, damit das LLM über seine aktuelle Fortschrittsstufe hinaussehen kann

• Bei der Aussage „Claude hat mir kostenlose, unbegrenzte Iteration gegeben, ohne sich daran zu stören, dass ich zum 50. Mal meine Meinung ändere oder um eine kleine Anpassung bitte“: Bezahlen sie Claude nicht?

  • „Kostenlos, unbegrenzte Iteration, stört sich nicht daran“ scheint hier eher zu bedeuten, dass man bei Drittanbietern oder Freelance-Designern oft einen Preis für „Entwurf + 1 Überarbeitung“ hat und danach jede weitere Änderung extra kostet
    Bei kleinen Designstudios ist es ähnlich, und oft wird nicht wie bei Entwicklern nach Stunden abgerechnet
  • Jane Streets Nettogewinn pro Mitarbeiter lag 2025 nicht beim Umsatz, sondern beim Gewinn im hohen einstelligen Millionen-Dollar-Bereich
  • Gemeint ist mit kostenlos wohl nicht der Preis, sondern kreative Freiheit ohne manuelle Arbeit
  • Etwas am Rande dazu: Ich war einmal in einem Bewerbungsgespräch mit CEO, Lead Developer und Lead Designer, und bekam die offensichtliche Frage nach meinen Schwächen
    Ich antwortete ehrlich, dass ich wirklich schlecht in Design bin und auch Probleme damit habe, aus Designsystemen etwas abzuleiten
    Es ist für mich extrem schwer, einen Punkt zu erreichen, an dem etwas okay aussieht, und auf dem Weg dorthin mache ich es fast immer noch schlechter
    Der Designer im Gespräch nahm das persönlich und ging mich darauf an
    So etwas hatte ich schon früher
    Designer mochten die ständigen Fragen dazu nicht, wie etwas aussehen soll, und wollten die Übergabe lieber als einmaligen Handover abschließen
    Selbst in Marketing- und Werbeagenturen musste ich ständig darum kämpfen, Beispiele dafür zu bekommen, wie Dinge aussehen sollen, die nicht in der Design-Spezifikation standen
    Das heißt nicht, dass ich recht hatte, aber für mich ist das eine große Achillesferse
    Wenn ich also „kostenlos, unbegrenzte Iteration, stört sich nicht daran“ höre, denke ich eher an Zeit und Geduld als an Geld
    Bolt, das ich fürs Prototyping nutze, wird nicht wütend
    Es macht vielleicht nicht das beste Design, aber deutlich besser, als ich es könnte, und wenn ich fertig bin, kann ich einen echten Designer bitten, es besser zu machen
    Bis dahin muss ich mir keine Sorgen machen, jemanden zu verärgern

• Ich habe für das Frontend Claude Design verwendet.
  Das Erscheinungsbild und die Anmutung der Ergebnisse sind durchaus gut genug, aber die Designs sehen oft ähnlich aus und folgen meist den abgedroschenen Mustern des modernen Webs.
  Ich frage mich, ob jemand damit schon untypische kreative Versuche gemacht hat.

  • Schaut euch bitte meine Portfolio-Website an, am besten auf dem Desktop.
    Bisher stecken ungefähr drei Wochen darin, und sie ist noch nicht fertig, aber man bekommt schon einen Eindruck.
    So wie es in den letzten zehn Jahren SaaS-Boilerplates gab, gibt es auch LLM-Boilerplate, die aus dem Internet gelernt wurde.
    Trotzdem ist immer noch alles möglich, wenn man genug Hand anlegt.
  • Ich habe ähnliche Erfahrungen gemacht und deshalb angefangen, verschiedene Prompts und Eingaben zu testen.
    Interessant ist, dass es Anforderungen gut umsetzt, aber ohne Richtungsvorgabe sichere Entscheidungen trifft.
    Wenn man die Ästhetik des Outputs sowie User Experience und Inhalte bewerten will, aber kaum Prompts zur Ästhetik gibt, bekommt man eben nur sichere Standardwerte.
    Designs mit einem bootstrap-/tailwind-Klon-Gefühl kann es gut erzeugen, aber genau diesen Teil muss man bewusst vorantreiben.
    Bei einfachen Webseiten habe ich begonnen, den ersten Iterationen den alleinigen Fokus auf den visuellen Stil zu geben.
  • Die meisten Anwendungen brauchen keine untypische Kreativität.
  • Bei mir ist es ähnlich.
    Man muss nur konkret anweisen, dass es nicht standardmäßig aussehen soll, und Beispiele für den gewünschten Website-Stil geben.
    Mit etwas Ringen wirkt es etwas kreativer, aber dafür ist Prompt-Arbeit nötig.
  • Ich nutze auch Claude Design.
    Es wurde mir von sehr angesehenen und erfahrenen Designern empfohlen; sie bauen Prototypen inzwischen fast vollständig in Claude und verfeinern sie in Figma, wenn ihnen das Ergebnis gefällt.
    Wenn man ohne detaillierte Stil-Prompts einfach nach einer allgemeinen UI fragt, ist es selbstverständlich, dass eine allgemeine Gestaltung herauskommt.

• Der Vorteil hier ist, dass Designer lernen zu coden.
  Ich fand es schon immer seltsam, dass Designer Software gestalten, ohne zu wissen, wie Software gebaut wird.
  Zur Einordnung: Ich bin selbst Designer.
  Allerdings ist das Entwerfen im Code ein technikzentrierter Ansatz.
  Wenn der Zweck von Design darin besteht, Ergebnisse im Sinne menschlicher Ziele zu formen, kann man auch sagen, dass es besser ist, nicht bei den strengen Regeln des Codes zu beginnen.
  Nicht wegen schöner aussehender Ergebnisse, sondern weil es das Denken nach vorn treibt, ist Stift und Papier noch immer schwer zu schlagen.

  • Ich habe sechs Jahre als Full-Stack- und vor allem Frontend-Ingenieur gearbeitet und war es leid, Code von Hand zu schreiben, also bin ich ins Design gewechselt.
    Jetzt, wo man praktisch per Stimme coden kann, kehre ich wieder zum Vibe Coding und zum Bauen von Produkten zurück, und es ist wirklich großartig.
    Mein Vorgesetzter versucht diese neue Situation noch zu begreifen, aber die alte Rollentrennung scheint allmählich zu sterben.
    An der Schnittstelle zu sein, ist meiner Meinung nach gerade der beste Platz.
    Es fühlt sich an, als hätte mein ganzes Leben mich auf diesen Moment vorbereitet.
  • Es hilft, die Einschränkungen des Mediums zu verstehen, aber man muss nicht jede Ebene kennen bis hin dazu, wie sich Elektronen in Silizium bewegen.
  • LLMs sorgen normalerweise eher dafür, dass man das Coden vergisst, daher bin ich skeptisch, ob das zum Lernen auf diese Weise gut ist.
    Für Designer dürfte es eher wie Figma sein, bei dem man das Ergebnis sieht und Änderungen sprachlich statt in einem visuellen Editor vornimmt.
  • Designer lernen nicht zu coden.
    Meine Frau ist Produktmanagerin bei einem FAANG-Unternehmen, und ihr Team verlässt sich extrem darauf, mit AI Software-Stücke per Vibe Coding zu erstellen, die früher wohl in Word oder Excel gelandet wären.
    Sie lernen kein Coden und schauen den Code keine einzige Sekunde an.
  • Man braucht Designer, die eng mit Ingenieuren gearbeitet haben und ein solides Urteilsvermögen mitbringen.

• Der Ansatz „Der Prototyp ist ein lebendiges Vorschlagsdokument, der Code darf weggeworfen werden, und die Aufgabe der Reviewer ist es, Feedback zu Architektur und User Experience zu geben.
  Am Ende übernimmt der Reviewer die Idee, implementiert sie als separates Feature, orientiert sich am Prototyp, besitzt den Produktionscode aber selbst“ löst für mich ein Problem, das ich bei jedem POC erlebt habe.
  Das ist wirklich eine sehr gute Vorgehensweise.

  • Diesen Text hat niemand geschrieben, der seinen Lebensunterhalt mit Figma verdient.
    Wenn es um ein konkretes Problem in einem konkreten Produkt geht, nennt man es leicht ein „Vorschlagsdokument“.
    Aber es gibt immer noch unzählige Designer, die Figma nutzen, um Designsysteme über Produkte und Plattformen hinweg zu definieren und zu pflegen, und in diesem Fall ist Figma die Quelle der Wahrheit.

• Unser Team arbeitet auch so, und ich bin Frontend-Ingenieur; ehrlich gesagt vermisse ich die alte Arbeitsweise sehr.
  Weil geschriebene Spezifikationen durch funktionierende Prototypen ersetzt wurden, kommt jetzt die zusätzliche kognitive Last dazu, Code zu lesen und zu entscheiden, was die beabsichtigte Änderung ist und was nur zu verwerfendes Rauschen.
  Ich muss generierte PRs übernehmen und entscheiden, ob ich die nötigen Änderungen darauf aufbaue oder alles von Grund auf neu mache, und beides erzeugt Reibung.
  Es kam auch schon vor, dass massenhaft unbeabsichtigte Änderungen erzeugt wurden, ich Zeit investiert habe, sie durch Reimplementierung zu übertragen, und später dann ein „Ups, sorry, das wollten wir eigentlich gar nicht ändern“ kam.
  Ich verstehe, dass das mehr Eigenständigkeit gibt, aber es nimmt mir auch einen Teil der Freude an meiner früheren Arbeit und macht daraus eher ein Ärgernis.

  • Ich bin in einer ähnlichen Lage.
    Design und Produktseite entwerfen und coden mit Claude Features oder Erlebnisse per Vibe, bauen schnell Prototypen und bringen sie mit minimalem Engineering-Aufwand vor Kunden, um Feedback einzuholen.
    Das ist großartig.
    Aber überraschenderweise hat es insgesamt kaum dabei geholfen, schneller auszuliefern.
    Ich glaube, der Grund ist, dass in diesem Prozess Denkarbeit verloren gegangen ist.
    Ein nicht geringer Teil des Denkens wurde jetzt an das Sprachmodell ausgelagert.
    Es übermalt Lücken in den Prompts und füllt nicht spezifiziertes Verhalten mit Halluzinationen auf.
    Früher hätten wir bei Dingen gestoppt wie: „Das passt nicht so richtig“, „Wie vermittle ich diese Idee?“ oder „Was passiert in diesem Fall?“ — jetzt verschwindet das, und solche Details werden auf später verschoben, wenn man es dann richtig baut.
    Natürlich kann man den Prozess verbessern und darüber nachdenken, wie man diese neue Technik besser nutzt, aber ob es besser ist als früher, da bin ich mir nicht sicher.
  • Warum lässt man Claude Design nicht ein Dokument schreiben, das den Prototypen vollständig spezifiziert?
  • Die alte Arbeitsweise war schwerfällig, die Feedback-Zyklen waren lang, und sie hat die UI gatekeeped.
    Sie stirbt aus.
    Jetzt machen Backend-Leute auch Frontend.
  • Code wird jetzt nicht mehr geschrieben, damit Menschen ihn lesen.
    Das ist ein Irrtum.
    Schaut man sich den vom Compiler erzeugten Assembler an? Nein.
    Warum also schaut ihr euch diesen Code an?
    Wir haben die Abstraktionsebene nach oben verschoben.

• Ich nutze oft denselben Ansatz
  Schon vor AI habe ich das manuell so gemacht
  Zuerst habe ich mich nur mit dem Nutzer und Stift und Papier hingesetzt, danach schnell ein Frontend-POC oder eine Demo gebaut, den Nutzer damit herumprobieren lassen und dann so lange angepasst, bis es wie gewünscht funktionierte
  Für mich war es oft ohnehin schneller, eine schnelle Frontend-Demo in Code statt in Produktionsqualität zu bauen, als in Figma präzise Interaktionen zu erstellen
  Durch die vollständige Interaktivität konnte ich deutlich mehr Grenzfälle bei der User Experience erfassen
  Dank Claude Code geht das Erstellen von Wegwerfprototypen jetzt schneller, aber der Unterschied ist nicht riesig
  Da 80 % der Gesamtzeit darauf entfallen, mit dem Nutzer zu sprechen und darüber nachzudenken, wie es funktionieren soll, halbiert Claude im Vergleich zum schnellen Selbstbauen ungefähr nur die verbleibenden 20 %
  Die erste Version ist schneller, aber wenn man es noch nicht vollständig verstanden hat, sind Iterationen langsamer

• Edwin, schön zu sehen, dass du das gepostet hast
  Ich erinnere mich, dass wir ungefähr 2012/2013 zusammen einen Hackathon gemacht haben
  Die Fähigkeit, schneller zu einem funktionierenden Prototyp zu kommen, ist enorm bestärkend, auch wenn dabei die Versuchung besteht, unausgereifte Ideen direkt auszuliefern
  Design- und User-Experience-Anforderungen profitieren stark davon, wenn man über Storyboards und Wireframes hinausgehen und den tatsächlichen Ablauf wirklich anfassen und erleben kann