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!