90 % des Designprozesses Ihrer Agenten ist am Ende

AAI LABS
컴퓨터/소프트웨어창업/스타트업경영/리더십AI/미래기술

Transcript

00:00:00Im alten Entwicklungsprozess gab es eine Ebene, die heute nicht mehr existiert.
00:00:03Die meisten Teams wissen noch nicht, womit sie diese ersetzen sollen, also folgen sie
00:00:06dem alten Ablauf aus reiner Gewohnheit.
00:00:08Diese Woche hat Jenny Wen ein Interview in Lennys Podcast veröffentlicht.
00:00:11Sie ist Designchefin für Claude bei Anthropic und war davor Design Director
00:00:16bei Figma.
00:00:17In der Folge sprach sie darüber, dass der klassische Designprozess tot ist und was ihn
00:00:21tatsächlich ersetzt.
00:00:22Wir werden also analysieren, was sich warum geändert hat, und dann den exakten Prozess
00:00:26durchgehen, der an seine Stelle getreten ist.
00:00:27Um den Ersatz zu verstehen, muss man begreifen, warum es den alten Prozess überhaupt gab.
00:00:31Im alten Modell wurden zuerst Anforderungen definiert, dann erstellte ein Designer
00:00:35in Figma ein Mockup davon, wie die App aussehen soll.
00:00:38Diese Figma-Datei war das Übergabedokument zwischen Vision und Umsetzung.
00:00:43Ein Frontend-Entwickler wandelte diese Datei dann in Code um.
00:00:46Parallel dazu baute der Backend-Entwickler, da die API-Spezifikation vorab festgelegt
00:00:51war, sodass beide Seiten gleichzeitig arbeiten konnten und am Ende alles zusammenpasste.
00:00:55Jenny beschreibt dies als einen Prozess, den Designer fast wie ein Ritual behandelten.
00:00:58Das war der Industriestandard.
00:01:00Die meisten Erklärungen für den Wandel übersehen den eigentlichen Grund für die Existenz des alten Weges.
00:01:05Simon Willison, ein Entwickler mit einem der meistgelesenen Tech-Blogs,
00:01:09schrieb im Januar über Jennys Talk in Berlin und ergänzte die Erkenntnis, die sie impliziert,
00:01:14aber nicht direkt ausspricht.
00:01:16Das Bauen mit KI senkt die Kosten für Fehlentwicklungen drastisch.
00:01:19Vor der KI bedeutete eine falsche Richtung Monate verschwendeter Entwicklungszeit.
00:01:23Ein kleiner Fehler im Frontend verursachte den zehnfachen Aufwand bei der Implementierung.
00:01:27Deshalb rechtfertigten Teams jeden einzelnen Schritt.
00:01:28Research, Personas, User Journeys, Wireframes, Spezifikationen.
00:01:33All das war Schutz davor, das Falsche im großen Stil zu bauen.
00:01:36Was also hat sich im Prozess tatsächlich geändert?
00:01:38Zuerst änderte sich die Geschwindigkeit in der Softwareentwicklung.
00:01:40Und sie änderte sich schneller, als die meisten Leute es verarbeiten konnten.
00:01:42Jenny sagte, vor ein paar Jahren verbrachte sie als Designerin 60 bis 70 % ihrer Zeit mit Mockups und Prototypen.
00:01:48Heute sind es nur noch 30 bis 40 %.
00:01:49Sie hat sich nicht aktiv für eine andere Arbeitsweise entschieden.
00:01:51Die Entwickler um sie herum ließen plötzlich mehrere Agenten parallel laufen,
00:01:55und plötzlich war das Engineering nicht mehr der Flaschenhals.
00:01:58Das Engineering änderte sich zuerst, und das Design musste folgen.
00:02:00Auch die Zeitrahmen für Visionen haben sich gewandelt.
00:02:02Früher erstellte das Design Visionen für die nächsten 2 bis 5 Jahre.
00:02:04Heute bewegt sich die Technik so schnell, dass 3 bis 6 Monate der realistische Horizont sind.
00:02:09Und es ist nicht mehr unbedingt eine Präsentation.
00:02:11Es ist ein Prototyp, der den Leuten die Richtung weist.
00:02:13Dasselbe passierte mit dem Schritt der Übersetzung.
00:02:15Wenn ein Agent ein Anforderungsdokument nehmen und eine funktionierende Oberfläche bauen kann,
00:02:19fällt die Übersetzungsebene weg.
00:02:20Der Agent schreibt den Code.
00:02:22Es gibt keine Figma-Datei zum Übersetzen, weil es nie eine Figma-Datei gab.
00:02:25Wenn euch unser Content gefällt, drückt gerne den Hype-Button, denn das hilft uns,
00:02:29mehr solcher Inhalte zu erstellen und mehr Menschen zu erreichen.
00:02:33Bei Kundenprojekten ist das genau der Umbruch, den wir vollziehen mussten.
00:02:36Der Designprozess hat sich geändert, aber was gleich geblieben ist, sind die Anforderungen.
00:02:40Schlechte Anforderungen ruinieren den gesamten Bau.
00:02:42Und die meisten Teams springen direkt zur Spezifikation.
00:02:44Das ist die falsche Reihenfolge.
00:02:45Wenn man einen Prototyp baut, braucht man weder Tech-Stack noch API-Spezifikation.
00:02:48Man muss genug wissen, um etwas zu bauen, das sich wie das echte Produkt anfühlt,
00:02:52damit man es jemandem zeigen und ein klares Ja oder Nein bekommen kann.
00:02:56Bevor ihr also den Prototyp anfasst, startet mit den Akteuren.
00:02:58Ein Akteur ist eine Person, die mit dem System interagiert.
00:03:01Eine spezifische Person mit einem spezifischen Ziel.
00:03:03Denn wer es nutzt, bestimmt, was es tun muss.
00:03:06Wenn jemand Inhalte einreicht und ein anderer sie genehmigt, sind das zwei
00:03:10verschiedene Oberflächen mit zwei unterschiedlichen Startbildschirmen.
00:03:12Schaut euch dann an, wo sich die Ansichten trennen.
00:03:13In fast jedem Produkt kommt der Punkt, an dem zwei Akteure dieselbe URL aufrufen,
00:03:18aber völlig verschiedene Dinge sehen.
00:03:19Ein Admin sieht ein Dashboard zur Verwaltung.
00:03:21Ein regulärer Nutzer sieht sein persönliches Dashboard.
00:03:22Der letzte Punkt sind Einschränkungen (Constraints).
00:03:24Sagt dem Agenten nicht, welche Tools er nutzen soll.
00:03:26Sagt ihm, was er nicht tun darf und was es nicht kosten darf.
00:03:28Das macht auch die späteren technischen Entscheidungen viel einfacher.
00:03:32Wir haben all diese Regeln in diesen "PRD-Erstellungs-Prompt" implementiert,
00:03:37der euch im Grunde interviewt – er fungiert als euer PRD-Interviewer
00:03:42und stellt euch basierend auf den Regeln eine Reihe von Fragen.
00:03:44Am Ende erhaltet ihr eine PRD-Markdown-Datei, die in den späteren
00:03:48Phasen des Prozesses verwendet wird.
00:03:49Auf dieser PRD-Datei baut alles Weitere auf.
00:03:52Der nächste Schritt ist die Umwandlung in die Struktur für das Frontend.
00:03:55Dafür nutzen wir diesen Layer-Prompt, der dem Agenten sagt, er solle das PRD analysieren,
00:04:00das – wohlgemerkt – noch kein volles technisches Dokument ist, und zwei Dinge erstellen.
00:04:04Er soll die Seiten und Modals für den Prototyp festlegen
00:04:08und anschließend die User Flows definieren.
00:04:09Seiten und Modals sind natürlich wichtig für die Struktur, damit alles, was der Agent
00:04:14im Frontend implementieren muss, vorher geplant ist.
00:04:17Wir betonen immer wieder, wie wichtig Planung vor der Aktion ist,
00:04:21besonders für den Agenten und das Kontextfenster, also müssen wir das nicht vertiefen.
00:04:24Bei den User Flows ist es wichtig, die Aktionen jedes Akteurs zu definieren.
00:04:28Da wir uns bereits auf die Akteure statt auf Features konzentrieren, müssen wir auch
00:04:32die User Flows festlegen, damit der Agent die richtigen Interaktionszustände
00:04:36und die Navigation für den UI-Prototyp umsetzen kann.
00:04:40Wir erhalten so zwei Dateien, wobei die architecture.md die Seiten,
00:04:45Modals und die besprochenen User Flows enthält.
00:04:46Danach lassen wir eine Next.js-App installieren, da dies unser üblicher
00:04:50Tech-Stack ist: Next.js zusammen mit Supabase.
00:04:53Und das hier ist das Ergebnis.
00:04:55Insgesamt sieht das Design wirklich gut aus, aber dafür gibt es einen speziellen Grund.
00:04:58Es wurde vorhin nicht erwähnt, aber das Projekt war eine Community-Plattform
00:05:03mit Kanälen, Produkten und Kursen.
00:05:04Es gibt im Wesentlichen zwei Akteure: das Mitglied und den Creator.
00:05:08Der Creator hat alle administrativen Funktionen wie Kanäle erstellen,
00:05:12Produkte hinzufügen, Kurse hochladen und Statistiken einsehen.
00:05:15Für einen ersten Prototyp finden wir das Design wirklich gelungen.
00:05:19Die UX ist allerdings noch nicht optimal, da man normalerweise kein solches Dashboard möchte.
00:05:23Und genau das ist der springende Punkt.
00:05:24Solche Anpassungen dauerten früher Tage, hier dauern sie Minuten.
00:05:27Weil die KI diese Änderungen extrem schnell umsetzen kann.
00:05:30Da es hier noch kein Backend gibt, muss man sich nicht um den ganzen Zusatzaufwand kümmern,
00:05:34es ist ein reiner Frontend-Prototyp.
00:05:36Normalerweise erstellt KI nicht von sich aus so gut aussehende Interfaces.
00:05:40Dass das hier gut aussieht, liegt daran, dass wir diesen allgemeinen Frontend-Skill
00:05:44nutzen, den Anthropic in einem ihrer Blogs geteilt hat.
00:05:46Wir empfehlen dringend, diesen vor der UI-Implementierung zu verwenden.
00:05:50Speichert ihn als Slash-Befehl oder Skill, damit euer Agent darauf zugreifen kann.
00:05:53Wenn ihr für einen Kunden arbeitet, müsst ihr ihm nur diesen Prototyp zeigen,
00:05:57der funktional voll einsatzbereit ist – allerdings mit Mock-Daten,
00:06:01da wir jetzt noch keine Datenbank anbinden.
00:06:02Ihr zeigt das dem Kunden, holt das Okay ein oder macht Änderungen
00:06:06und macht dann mit dem Rest des Projekts weiter.
00:06:08Diese Aufgabenlisten sind einer der Gründe, warum wir Agenten jetzt
00:06:12voll funktionsfähige Prototypen erstellen lassen können.
00:06:14Es liegt an diesen Listen, der Aufgaben-Persistenz und der Tatsache,
00:06:17dass alles strukturiert ist.
00:06:18Deshalb war die architecture.md-Datei so wichtig, weil sie dem Agenten
00:06:23erlaubt, eine optimierte Aufgabenliste zu erstellen, ohne zu halluzinieren.
00:06:28Danach gehen wir zur Backend-Implementierung über.
00:06:30Normalerweise gibt es zwei Möglichkeiten.
00:06:32Man könnte bei Next.js bleiben, das Frontend in Next.js lassen
00:06:36und das Backend als separaten Python-Service implementieren.
00:06:39Aber das hängt von der Art der Anwendung ab.
00:06:42Für die meisten eurer Projekte wird Next.js völlig ausreichen.
00:06:46Ein separates Python-Backend braucht ihr nur für spezielle Bibliotheken,
00:06:50die in Next.js nicht verfügbar sind, oder wenn ihr eine komplexe
00:06:55Orchestrierung von Hintergrundjobs zur Optimierung benötigt.
00:06:57In diesem Fall ist ein separates Backend sinnvoll.
00:06:59Ansonsten ist das Next.js-Backend meistens alles, was ihr braucht.
00:07:03Bevor wir das Backend anrühren, müssen wir wissen, was das Frontend davon benötigt.
00:07:07Also ließen wir den Agenten den Frontend-Code, das PRD und die Architektur-Datei analysieren
00:07:11und eine API-Spezifikation schreiben.
00:07:12Danach sollte er diese Dokumente nutzen, um das komplette Supabase-Schema zu erstellen,
00:07:17da wir Supabase plus Next.js verwenden.
00:07:20Er muss die Schemas erstellen, in denen die Daten der App gespeichert werden.
00:07:25Normalerweise würde euch ein Agent sagen: Besorgt euch die API-Keys
00:07:28der Datenbank und kopiert die SQL-Queries für die Tabellen manuell hinein.
00:07:33Stattdessen solltet ihr aber das Supabase-MCP nutzen.
00:07:36Versucht immer ein MCP für den jeweiligen Dienst zu verwenden,
00:07:40da es viele Schritte automatisiert.
00:07:41Wir mussten uns zum Beispiel gar nicht erst die Projekte ansehen.
00:07:43Es hat automatisch das Projekt erstellt, die Queries für das Schema ausgeführt
00:07:48und die Migrationen direkt gestartet.
00:07:49Wir mussten also im Grunde gar nichts tun.
00:07:51Sobald die Datenbank steht, verbindet ihr das Frontend mit ihr.
00:07:55Hier gibt es wieder eine klare Unterscheidung.
00:07:57Man muss das Backend nicht separat an die Datenbank anbinden,
00:08:00da es bereits im Frontend integriert ist.
00:08:01Das Frontend kommuniziert direkt mit der Datenbank, was die Integration
00:08:06und die Komplexität deutlich vereinfacht.
00:08:07Wir sind für dieses Video eine Partnerschaft mit Warp eingegangen, die kürzlich OZ
00:08:11veröffentlicht haben – eine Orchestrierungsplattform für Cloud-Agenten.
00:08:14Diese Cloud-Agenten sind praktisch für Aufgaben, die man delegieren möchte
00:08:19und von denen man weiß, dass der Agent sie eigenständig erledigen kann.
00:08:21Bis zu diesem Punkt hatte der Agent das Frontend mit der Datenbank verbunden
00:08:26und die App funktionierte bereits auf dieser Basis.
00:08:27Aber für Dinge wie Zahlungsabwicklung, Benachrichtigungen, Rate-Limiting oder Analytics
00:08:32benötigen wir eine dedizierte Backend-API-Ebene, um das alles zu integrieren.
00:08:37Dafür haben wir eine Umgebung mit OZ erstellt und einen Cloud-Agenten gestartet,
00:08:41der diese Backend-Ebene aufbauen sollte.
00:08:43Nach etwa 15 Minuten war die Aufgabe erledigt und das Ganze war fertig.
00:08:47Um das Projekt wirklich startklar für Nutzer zu machen, fehlten nur noch
00:08:51Google-Authentifizierung, Stripe-Integration und ein paar Feinschliffe.
00:08:56Ihr habt nun den gesamten Prozess und die Prompts auf dem Bildschirm gesehen.
00:09:00Falls ihr all diese Prompts als Schritt-für-Schritt-Workflow für eure eigenen
00:09:04Projekte haben wollt, stellen wir sie in AI Labs Pro bereit.
00:09:06Für alle, die es nicht kennen: Das ist unsere Community mit fertigen Templates,
00:09:10die ihr direkt für eure Projekte nutzen könnt – für dieses und alle alten Videos.
00:09:14Wenn euch unsere Arbeit gefällt und ihr den Kanal unterstützen wollt,
00:09:18ist das der beste Weg.
00:09:19Der Link steht in der Beschreibung.
00:09:20Damit sind wir am Ende dieses Videos angelangt.
00:09:22Wenn ihr den Kanal unterstützen wollt, damit wir weiterhin solche Videos machen,
00:09:26könnt ihr das über den Super-Thanks-Button unten tun.
00:09:28Wie immer, danke fürs Zuschauen und bis zum nächsten Mal!

Key Takeaway

Der traditionelle, ritualisierte Designprozess weicht einer agilen, KI-gesteuerten Entwicklung, bei der funktionale Prototypen die statische Figma-Übergabe ersetzen und die Geschwindigkeit der Umsetzung drastisch erhöhen.

Highlights

Der klassische Designprozess, bei dem Mockups als starre Übergabedokumente dienten, wird durch KI-gestützte Prototypen ersetzt.

KI senkt die Kosten für Fehlentwicklungen massiv, da Prototypen in Minuten statt in Tagen angepasst werden können.

Design-Visionen haben heute einen Zeithorizont von 3 bis 6 Monaten statt früher 2 bis 5 Jahre.

Moderne Workflows fokussieren sich auf Akteure und deren spezifische Ziele statt auf reine Feature-Listen.

Die technische Umsetzung erfolgt zunehmend durch Agenten, die PRD-Dateien direkt in funktionalen Frontend-Code umwandeln.

Tools wie Supabase-MCP und Orchestrierungsplattformen wie OZ automatisieren die Datenbank-Migration und Backend-Logik.

Ein spezialisierter 'Frontend-Skill'-Prompt ist entscheidend, damit KI-generierte Oberflächen ästhetisch und hochwertig aussehen.

Timeline

Der Tod des klassischen Designprozesses

Der Sprecher erklärt, dass die traditionelle Ebene der Design-Übergabe im modernen Entwicklungsprozess nicht mehr existiert. Er bezieht sich auf ein Interview mit Jenny Wen, der Designchefin für Claude bei Anthropic, die den klassischen Prozess für tot erklärt. Früher wurden Anforderungen definiert, in Figma-Mockups umgewandelt und dann mühsam von Entwicklern in Code übersetzt. Dieser Ablauf war eher ein ritueller Industriestandard als eine effiziente Notwendigkeit. Heute wissen viele Teams noch nicht, wie sie diese Lücke füllen sollen, und halten aus reiner Gewohnheit am Alten fest.

Warum sich die Kosten der Entwicklung geändert haben

In diesem Abschnitt wird beleuchtet, warum der alte Prozess mit seinen vielen Absicherungen wie Personas und Wireframes überhaupt existierte. Simon Willison wird zitiert, um zu verdeutlichen, dass KI die Kosten für Fehler drastisch senkt. Vor der KI-Ära bedeutete eine falsche Design-Entscheidung oft Monate verschwendeter Arbeit für die Entwickler. Jede Spezifikation diente als Schutzschild gegen kostspielige Fehlentwicklungen im großen Stil. Nun, da die Umsetzung schneller und günstiger ist, verliert dieser starre Schutzmechanismus an Bedeutung.

Verschiebung der Zeitanteile und Visionen

Die Geschwindigkeit der Softwareentwicklung hat sich schneller verändert, als viele Fachkräfte es verarbeiten konnten. Jenny Wen berichtet, dass sie früher 70 % ihrer Zeit mit Mockups verbrachte, während es heute nur noch etwa 30 % sind. Das Engineering ist nicht mehr der Flaschenhals, da Entwickler KI-Agenten parallel laufen lassen können. Auch der Planungshorizont für Visionen ist von mehreren Jahren auf nur noch 3 bis 6 Monate geschrumpft. Ein funktionaler Prototyp weist heute die Richtung, anstatt eine rein visuelle Präsentation zu sein.

Der neue Prozess: Akteure und Anforderungen

Obwohl sich der Prozess gewandelt hat, bleiben präzise Anforderungen das Fundament für jedes Projekt. Der Sprecher warnt davor, direkt zur technischen Spezifikation zu springen, ohne die Akteure zu definieren. Ein Akteur ist eine spezifische Person mit einem klaren Ziel, dessen Bedürfnisse die Benutzeroberfläche bestimmen. Es wird erklärt, wie man Einschränkungen definiert, ohne dem Agenten die Tools vorzuschreiben. Am Ende dieses Schrittes steht eine PRD-Markdown-Datei, die durch einen interaktiven KI-Prompt erstellt wird und als Basis für alles Weitere dient.

Strukturierung und Frontend-Prototyping

Nach der PRD-Erstellung folgt die Umwandlung in eine Frontend-Struktur mittels eines Layer-Prompts. Dieser analysiert das Dokument und erstellt eine 'architecture.md', die Seiten, Modals und User Flows festlegt. Der Fokus liegt hierbei auf der Planung vor der Aktion, um Halluzinationen der KI im Kontextfenster zu vermeiden. Im Beispiel wird eine Community-Plattform mit Next.js und Supabase aufgebaut, die bereits nach Minuten funktionsfähig ist. Der Sprecher betont, dass solche Anpassungen früher Tage gedauert hätten, während sie jetzt fast in Echtzeit erfolgen.

Design-Qualität und Kunden-Feedback

Ein kritischer Punkt ist das visuelle Erscheinungsbild der KI-generierten Interfaces. Um hochwertige Ergebnisse zu erzielen, wird die Nutzung eines speziellen 'Frontend-Skills' von Anthropic empfohlen. Dieser sorgt dafür, dass die Prototypen professionell aussehen und direkt dem Kunden präsentiert werden können. Obwohl die App in diesem Stadium nur Mock-Daten verwendet, ist sie funktional voll einsatzbereit für ein erstes Feedback. Diese Vorgehensweise erlaubt es, schnell ein 'Ja' oder 'Nein' vom Kunden einzuholen, bevor die tiefe technische Integration beginnt.

Backend-Integration und Automatisierung

Der Übergang zum Backend erfolgt durch die Analyse des Frontend-Codes, um eine API-Spezifikation abzuleiten. Für die meisten Projekte reicht ein Next.js-Backend aus, während Python nur für spezielle Bibliotheken nötig ist. Durch den Einsatz des Supabase-MCP (Model Context Protocol) wird die Erstellung von Tabellen und Migrationen fast vollständig automatisiert. Der Agent kann SQL-Queries direkt ausführen, ohne dass der Entwickler manuell eingreifen muss. Dies vereinfacht die Komplexität der Integration zwischen Frontend und Datenbank erheblich.

Cloud-Agenten und Abschluss

Im letzten Schritt werden komplexe Aufgaben wie Zahlungsabwicklung und Authentifizierung über Cloud-Agenten auf Plattformen wie OZ gelöst. Diese Agenten bauen die Backend-API-Ebene eigenständig auf, was im gezeigten Beispiel etwa 15 Minuten dauerte. Damit ist die Anwendung bereit für den Einsatz von Stripe oder Google-Auth und kurz vor dem Go-Live. Zum Abschluss bietet der Sprecher ein kostenpflichtiges Workflow-Template in AI Labs Pro an. Das Video endet mit einer Zusammenfassung der gezeigten Prompts und einem Dank an die Zuschauer.

Community Posts

View all posts