11 Punkte von GN⁺ 4 시간 전 | Noch keine Kommentare. | Auf WhatsApp teilen
  • Demonstriert einen praxisnahen Workflow, indem gezeigt wird, wie Claude Code in der tatsächlichen Produktentwicklung eingesetzt wird und wie eine Autocomplete-Funktion direkt zu Excalidraw hinzugefügt wird
  • Obwohl es ein Vortrag einer Designerin ist, liegt der Inhalt fast näher an einem Entwickler-Workflow: mehrere Claude-Sitzungen parallel mit worktree ausführen, Funktionsprototypen erstellen, im Browser validieren und bis zum PR alles CLI-zentriert abwickeln
  • Der Kern ist, AI nicht einfach als Werkzeug zu nutzen, das Code anstelle des Menschen schreibt, sondern sie in eine Produktentwicklungs-Pipeline einzubinden, die von Ideenexploration → Vergleich von Implementierungsansätzen → Selbstvalidierung → PR-Erstellung → Einarbeitung von Reviews → Merge-Unterstützung reicht
  • Für Designer ist relevant, dass die Grenzen von Claude bei Designentscheidungen ausdrücklich anerkannt werden, gleichzeitig aber gezeigt wird, wie man schnell mehrere Implementierungsvarianten erstellt und sie per PR mit Screenshots und GIFs prüfen lässt, um Geschwindigkeit von Designentscheidungen und Qualitätskontrolle zugleich zu erhöhen
  • Für Entwickler ist nützlich, dass konkrete Muster sichtbar werden, wie Claude Code mit /prototype, loop, automatischem Berechtigungsmodus, Chrome-basierter Selbsttests sowie Automatisierung von Code-Bereinigung, Review und PR-Merge in reale Repositories und Kollaborationsabläufe eingebunden wird
  • Besonders wichtig ist die Perspektive: „Nur weil alle etwas bauen können, heißt das nicht, dass alles ausgeliefert werden sollte.“ Im AI-Zeitalter können mehr Menschen Code erzeugen, daher müssen Validierung, Reviews, Designbeteiligung und Deployment-Kriterien in skalierbare automatisierte Systeme überführt werden
  • Letztlich zeigt dieses Video weniger, wie Designer mit AI programmieren, sondern vielmehr ein Beispiel dafür, wie Designer und Entwickler mit AI dazwischen schneller experimentieren können, ohne die Produktqualität zu verlieren

Kontext des Vortrags und Vortragende

  • Meaghan Choi, Lead Designerin von Claude Code
  • Entwirft schon seit vor der Einführung von AI CLI-Produkte und war an der Gestaltung der Claude CLI beteiligt; sie beschreibt sich selbst als „CLI die-hard“
  • Sie erwähnt, dass Anthropic-Mitarbeitende ständig Zugang zu den Tools haben und sie den ganzen Tag nutzen, weshalb dort kontinuierlich nach optimaleren Arbeitsweisen gesucht wird
  • Die Desktop-App ist zugänglicher, und es wird ausdrücklich gesagt, dass sich alle im Demo gezeigten Arbeitsschritte genauso in der Desktop-App ausführen lassen
    • Die CLI ist eine persönliche Vorliebe der Vortragenden und nicht etwas, das Zuschauer zwingend übernehmen müssen

Einrichtung einer parallelen, schnellen Arbeitsumgebung

  • worktree

    • Wenn mehrere Claude-Instanzen gleichzeitig in einem lokalen Repository laufen, können sie sich gegenseitig überschreiben und Konflikte verursachen
    • worktree erstellt isolierte Kopien eines Repositories, damit mehrere Aufgaben parallel bearbeitet werden können
      • Wenn Ingenieure 4 bis 5 Claude-Instanzen offen haben, haben sie entweder das Repository als repo1, repo2 usw. dupliziert oder nutzen worktree
      • Bei claude --worktree wird automatisch ein neuer Branch ausgecheckt; das erleichtert die Verwaltung und wird deshalb empfohlen
  • Opus 1M · fast mode

    • Die Vortragende nutzt immer Opus mit 1 Million Kontext und fast mode, weist aber darauf hin, dass der Zugriff je nach Organisation eingeschränkt sein kann
    • Diese Einstellung diente dazu, das 15-Minuten-Demo schnell durchzuführen; es gebe einen kleinen Geschwindigkeitsunterschied
  • auto mode

    • Anthropic-Mitarbeitende verwenden stets auto mode als Alternative zu Modi mit niedrigeren Berechtigungen
    • Ein Klassifikator (classifier) erkennt riskante Aktionen, sodass nicht ständig „Yes, accept“ bestätigt werden muss und die Arbeit deutlich schneller wird
  • Loop

    • Loop ist ein Standard-Prompt im Sinn von „mach weiter, bis alles fertig ist“ und lässt Aufgaben bis zum Abschluss wiederholt ausführen

Prompts und die prototype skill

  • Ohne Design-Spezifikation wurde Excalidraw allein mit dem einfachen Prompt „Ich möchte Autocomplete hinzufügen“ zur Implementierung der Funktion angewiesen
  • prototype skill

    • Eine per Anfrage an Claude selbst erstellte slash prototype skill, die standardmäßig 5 (oder n) Implementierungsvarianten für eine Funktion erzeugt, sie als HTML-Dateien vorab anzeigt und dann iteriert
      • Es wird betont, dass man Skills nicht von Hand schreibt, sondern per Prompt erstellt; „heutzutage schreibt niemand Skills von Hand“
    • Claude soll zunächst selbst eine Variante auswählen und die Gründe erklären; die Vortragende sagt, es mache Spaß, die Ergebnisse zu sehen
    • Mit „Online-Recherche erlaubt“ ergänzt; bei einer Produktions-Codebasis hätte sie Claude angewiesen, Slack, Google Docs, Diskussionsprotokolle, BigQuery und andere Quellen mit einzubeziehen
    • Danach soll die beste Variante implementiert, validiert, stilistisch angepasst und ein PR mit Screenshots erstellt werden
      • Anschließend wechselt der Ablauf weg vom Transkript hin dazu, den PR mit einer Aufnahme der implementierten Funktion zu prüfen
    • Im Demo wird unter mehreren von Claude vorgeschlagenen Tab-Autocomplete-Varianten auf Basis des Publikumsfeedbacks Variante 2 gewählt

Drei Prinzipien der Arbeit

  • Die meisten LLMs einschließlich Claude sind im Design noch schwach, daher müssen Menschen bei Handwerk und Entscheidungen weiter eingebunden bleiben
    • Das ist nicht zwingend eine dauerhafte Grenze, aber der aktuelle Workflow basiert auf der Annahme, dass Menschen entscheiden, was ins Produkt aufgenommen wird
  • Codierung soll automatisiert werden, aber auch Nicht-Coding-Aufgaben sollten an Claude delegiert werden; sonst nutzt man es nicht in der am stärksten automatisierten Form
  • Nur weil jeder shippen kann, heißt das nicht, dass alles geshippt werden sollte; da nun alle in die Produktion pushen können, braucht es skalierbare Systeme

Automatisierung von Nicht-Coding-Aufgaben

  • Claude in the web (cloud)

    • Dient dazu, hunderte kleine Polish-Fixes, die in der App entdeckt werden, ohne separate Sitzung laufend zu bearbeiten
    • Wenn Ingenieure sich darüber beschweren, dass es zu viele Änderungen sind, wird darum gebeten, sie in einem einzigen PR zu squashen
      • Kleine CSS-Änderungen werden teils ohne Review automatisch genehmigt; das ist nützlich, um den Reifegrad des Produkts zu erhalten
  • Automatisierung des PR-Merge

    • Fast alle Mitarbeitenden lassen Claude ständig laufen, um beim PR-Merge zu helfen; die Vortragende ist nicht mehr direkt an CI oder den letzten Schritten vor dem Merge beteiligt
    • simplify und code review dienen intern im Repository dazu, die Codebasis aufzuräumen (prune); ein Engineering-Team, das AI nutzt, dürfte ähnliche Tools haben
    • commit push PR ist ein Befehl, der interne Prüfungen gesammelt ausführt
    • Ein in Skills eingebauter Befehl prüft offene PRs und drückt sie bis zur Fertigstellung voran
      • Er ist mit Slack integriert und sendet automatisch DMs an Reviewer oder die on-call-verantwortliche Person; entscheidend ist die Integration des Tool-Bündels
  • Claude in Chrome

    • Claude öffnet Chrome selbst und testet das Verhalten direkt; das wird als beste Methode zur Selbstvalidierung von Frontend-Änderungen empfohlen
    • Der Ablauf besteht darin, Screenshots als eine Reihe von GIFs aufzuzeichnen und zu posten und danach einen PR zu öffnen
  • Geplante Routinen (Claude code work)

    • Per geplanter Aufgabe (routine) werden Frontend-Änderungen aus allen Repositories gesammelt
    • Slack, Google-Meet-Transkripte, Google Docs usw. werden durchsucht, um festzustellen, ob ein Designer beteiligt war; falls nicht, wird dies markiert
    • Wenn keine Beteiligung vorlag, wird das Design geprüft und ein PR mit adversarial design als Entwurf erstellt, danach bekommt der betreffende Ingenieur eine DM mit der Bitte, mit einem Designer zusammenzuarbeiten
      • Da Claude im Design schwach ist, ist die DM-Funktion derzeit deaktiviert; das knüpft an das erste Prinzip an (LLMs sind im Design noch schwach)
    • Die Strategie ist, Automatisierung nicht nur bis zum ersten nächsten Schritt, sondern bis zum Schritt nach dem nächsten Schritt voranzutreiben, damit sie beim nächsten Modell-Release sofort eingesetzt werden kann

Warum das für Designer und Entwickler nützlich ist

  • Das Ziel des Vortrags ist ausdrücklich, das Niveau der Arbeitsweise von Claude-Code-Nutzern anzuheben (up level), und es werden reale, intern bei Anthropic beliebte Arbeitsweisen offen gezeigt
  • Aus Entwicklersicht werden konkrete Befehle und Abläufe gezeigt, die die tägliche Arbeit direkt beschleunigen, etwa paralleles Arbeiten mit worktree, Wegfall wiederholter Bestätigungen durch auto mode sowie Automatisierung von PR-Merge und CI
    • Es wird darauf hingewiesen, dass Tools wie simplify oder code review, die im Vortrag verwendet werden, in jedem AI-nutzenden Engineering-Team intern Entsprechungen haben dürften und man den eigenen Engineering-Partner danach fragen sollte
  • Aus Designersicht wird unter der Prämisse, dass LLMs im Design noch schwach sind, klar die Position vertreten, dass Menschen Träger von Handwerk und Entscheidungen bleiben und Automatisierung nur unterstützend eingesetzt wird
    • Vorgestellt wird ein Ansatz, Designqualität systemisch zu sichern, etwa durch eine geplante Routine, die ohne Designerbeteiligung ausgelieferte Frontend-Änderungen erkennt und markiert

Noch keine Kommentare.

Noch keine Kommentare.