Transcription
Hallo Freunde, ich bin Dan Delamarski. Ich bin einer der Maintainer von SpecKit, dem neuen Projekt von GitHub. Es ist dieses Experiment, von dem ihr überall auf YouTubes, Tik Toks, Instagrams und sonst wo gehört habt. Aber im Ernst, schaut euch die Zahlen an. Schaut euch das an. 16,3.000 Sterne. Ich habe gestern noch gefeiert, dass wir 15.000 erreicht haben, und es sind bereits 16,3.000 eine Woche nach der Veröffentlichung. Das ist verrückt für mich. Absolut verrückt. Danke. Danke an all diejenigen, die das ausprobieren, die experimentieren, die Issues einreichen, Pull Requests öffnen. Es hilft enorm. Und Junge, wir haben noch viel mehr für euch auf Lager rund um SpecKit. Aber das ist eigentlich der Punkt des Videos. Wir werden heute über SpecKit sprechen. Wir werden darüber sprechen und tatsächlich darauf eingehen, wie das funktioniert. Und übrigens, ich bin auch einer von denen, die sich diese Issues ziemlich regelmäßig ansehen. Wenn ihr also Feedback habt, geht hin und reicht es ein. Reicht euer Feedback hier auf GitHub ein. Öffnet ein Issue. Äh, öffnet keinen Pull Request, der das Ganze als MCP-Server neu schreibt. Ich weiß, ich mag MCP. Ich werde diese Anfrage ablehnen, weil ihr mit niemandem darüber gesprochen habt. Wenn ihr also größere Änderungen habt, sprecht zuerst darüber im Issue. Und was sind die Issues, die ich manchmal sehe, die geöffnet werden, wie Dr. D? Was ist das? Ich meine, ernsthaft. Ja, öffnet keine Issues, die nur DR sagen, gebt mir etwas Kontext, wie wir das verbessern können. Aber egal, SpecKit, was es ist, ist ein Toolkit, das euch den Einstieg in die Spec-Driven Development erleichtert. Bei Microsoft setzen wir in letzter Zeit sehr auf Spec-Driven Development. Und eines der Dinge, die wir uns angesehen haben, ist, wie wir den Prozess der Nutzung von Spec-Driven Development zur Erstellung echter Software vereinfachen können. Es ist eines dieser wichtigen Dinge, über die man nicht wirklich nachdenkt, bis man es tatsächlich versucht. Eine der Unterhaltungen, die ich kürzlich hatte, drehte sich um Vibe Coding, richtig? Man hört all diese Leute, die über Vibe Coding sprechen, eine SaaS-App, und es gibt viel von dieser Ungenauigkeit. Man landet in diesen zufälligen Kaninchenbauten, wo der Code nicht ganz das ist, was man wollte. Die Implementierung ist nicht ganz das, was man wollte. Das Design ist nicht ganz das, was man wollte. Spec-Driven Development kann Ihnen also helfen, aus diesem Kaninchenbau herauszukommen und zu einer etwas skalierbareren Lösung für Ihre Software zu gelangen.
Schauen wir uns das mal an. Es ist wieder ein GitHub-Repo. Es ist alles Open Source. Es ist kostenlos. Man kann sich ansehen, was wir hier haben. Und äh, natürlich, eines der Dinge, die ich kürzlich getan habe, ist, die Specify CLI zu pushen. SpecKit enthält dieses wunderbare Ding, das Specify CLI heißt. Es erstellt Dinge für euch. Wenn ihr also ein Entwickler seid und denkt: "Wow, was brauche ich, um mit Spec-Driven Development zu beginnen?", ist die CLI genau das Richtige. Es gibt also auch eine Referenz dafür. Und äh, ich benutze uvx, und ihr könnt es direkt aus dem GitHub-Repo installieren, weil ich es noch nicht im Python-Paket-Repository veröffentlicht habe. Es kommt. Ich arbeite daran. Ich habe gesehen, dass Leute bereits Issues dazu eingereicht haben, was großartig ist. Aber wir werden es direkt aus dem Repo verwenden, wie es ist. Ich kopiere also einfach diesen Befehl mit UVX. Shoutout an die Leute von Astral. Das ist fantastisch. UVX. Ich benutze UV und UVX die ganze verdammte Zeit. Ähm, wenn ihr auch keine CLI verwenden wollt, ist das völlig in Ordnung. Ich verstehe, dass ihr keine Dinge installieren wollt. Ihr wollt UVX nicht installieren. Shoutout an die Astral-Leute. Euer Produkt ist großartig. Ich liebe UVX. Das ist nicht von ihnen gesponsert. Aber wenn ihr das nicht tun wollt, könnt ihr zu den Releases gehen und die Vorlagen einfach selbst herunterladen. Wir unterstützen mehrere Agenten. Und erst heute habe ich die Unterstützung für Cursor gestartet. Wenn ihr also zu den Leuten gehört, die Cursor verwenden, habt ihr Glück. Ihr könnt eine der Releases hier verwenden. Wir haben eine ganze Menge davon. Äh, es gibt zum Beispiel für Copilot, wir haben sie für PowerShell und Shell-Skripte. Es gibt eine ganze Menge, die ihr gleich in unserer Demo sehen werdet. Je nachdem, welches Betriebssystem ihr verwendet. Wenn ihr also unter Linux lauft, verwendet ihr vielleicht Bash-Skripte. Wenn ihr unter Windows lauft, verwendet ihr vielleicht PowerShell. Keine Wertung hier. Verwendet, was immer zu eurem Szenario passt. Aber ihr könnt diese herunterladen. Wir werden sagen, nehmt die Zip-Datei für das PowerShell-Skript für unseren Copilot und legt sie in Downloads. Und wir werden sie hier speichern. Und lasst uns das mal ansehen. Lasst es uns öffnen. Und ihr werdet bemerken, dass ich den Specify-Ordner habe, der einige Metadaten für Specify-Dinge wie Speicher, Skripte und Vorlagen enthält. Und Skripte sind natürlich PowerShell, weil das ist, was wir heruntergeladen haben. Das sind Hilfsskripte. Wir haben einige Prompts im GitHub-Ordner, auf die wir gleich eingehen werden. Ihr könnt das also einfach nehmen, in euer Projekt legen. Ihr müsst keine CLI verwenden. Ich verspreche euch, keine Installation erforderlich. Aber die Installation macht es tatsächlich viel einfacher. Ich empfehle also die Verwendung. Ich habe gerade den Befehl kopiert und gehe einfach zum Terminal, zoome ihn ein, und wir fügen ihn hier ein. Und wir werden ein neues Projekt bootstrappen. Mal sehen, was wir heute bauen wollen. Und sagen wir, ich möchte eine Podcast-Website bauen. Ich bin ein großer Podcast-Fan. Wenn ihr die Arbeit noch nicht gehört habt, schaut sie euch an. Aber sagen wir, ich habe keine Podcast-Website und möchte eine für mich selbst bauen.
Natürlich möchte ich einfach den Spec-Prozess für die Website bootstrappen. Ich werde es Pod Site nennen und wir werden Enter drücken und warten, bis Specify startet. Hier wird es interessant. Wir haben verschiedene Optionen. Ich kann verschiedene Agenten auswählen, für die ich diese benutzerdefinierten Befehle, benutzerdefinierten Prompts bootstrappe. Manchmal benutze ich Copilot, manchmal benutze ich Cloud Code. Ich bin kein großer Fan von Gemini CLI und Cursor, aber ich weiß, dass andere Leute sie benutzen. Also, sie sind da. Ihr könnt sie über die Specify CLI verwenden. Und weil es im Terminal läuft, könnt ihr immer einfach, wisst ihr, mit den Pfeiltasten navigieren, eure Tastatur benutzen, euch mit eurer Tastatur wohlfühlen und den Agenten auswählen, den ihr wollt. Ich wähle Copilot. Jetzt wähle ich auch die Art der Skripte aus, die ich für mein Hilfssystem verwenden werde, richtig? Denn wenn wir eine Reihe dieser Prompts ausführen, werden sie auch eine Reihe von Skripten ausführen, die Dinge wie Git-Branches bootstrappen und sicherstellen, dass der JSON-Inhalt, den wir zur Verknüpfung von Metadaten verwenden, derselbe ist. Und dafür ist es am einfachsten, Skripte zu verwenden, weil es deterministisch ist. Man muss sich nicht wirklich auf das LLM, das Large Language Model, verlassen, um herauszufinden, wie man die Dinge zusammensetzt. Die Dinge funktionieren einfach. Es wählt standardmäßig das Betriebssystem aus, auf dem ihr gerade läuft. In diesem Fall habe ich PowerShell ausgewählt, weil ich das auf einem Windows-Terminal ausführe, richtig? Aber wenn ich es wünsche, kann ich zu Shell-Skripten wechseln. Wenn ihr WSL 2 ausführt oder vielleicht eine Ubuntu VM oder eine Fedora VM habt, könnt ihr das auch dort verwenden. Und übrigens, das ist gerade erst gestartet, es ist brandaktuell. Ihr könnt jetzt tatsächlich PowerShell unterstützen. Ihr braucht kein WSL 2 unter Windows, um das auszuführen. Ihr könnt es einfach nativ unter Windows ausführen. Ich wähle PowerShell, richtig? Denn das ist es, was wir wollen. Wir wollen das unter Windows so ausführen, wie es ist. PowerShell also. Und wir werden einige Statusänderungen sehen. Das ist im Grunde die Specify CLI, die eine Menge Zeug herunterlädt und die Vorlagen lokal extrahiert. Wie ich bereits erwähnt habe, ist das nur eine Komfortschicht. Das ist nichts, was ihr tun müsst. Ihr könnt einfach das Zip selbst aus der Veröffentlichung für den Agenten und den Shell-Skript-Typ, den ihr wollt, herunterladen und es extrahieren und in euer Projekt einfügen. Genauso einfach.
Jetzt werdet ihr feststellen, dass es hier einige Anweisungen für mich gibt. Ich kann zum Ordner navigieren. Ich kann in Visual Studio Code öffnen und einige Slash-Befehle verwenden. Es gibt Specify Plan und Tasks. Diese werden mir helfen, mein Projekt tatsächlich zu bootstrappen. Und ich kann die Verfassungsdatei aktualisieren. Die Verfassungsdatei ist tatsächlich etwas, von dem ihr wahrscheinlich noch nie gehört habt, weil sie relativ neu ist. Die Idee der Verfassung ist, dass sie eine Reihe von nicht verhandelbaren Prinzipien für euer Projekt festlegt. Wenn ihr also Dinge habt wie "Ich muss immer Tests haben", "Ich muss immer sicherstellen, dass ich Nex.js einer bestimmten Version ausführe", kodiert ihr das in die Verfassung. Dort gehört das Zeug hin. Hier kommt also die Verfassung ins Spiel und sie wird für alle eure Projekte super hilfreich. Äh, jetzt springen wir zurück zu unserem Terminal und ich starte VS Code, weil ich natürlich an diesem Projekt in VS Code iterieren werde, und wir werden feststellen, dass Pod Site hier ist, und das liegt daran, dass ich den falschen Ordner geöffnet habe, und so merke ich, dass ich Pod Site hier habe und das sind die GitHub-Ordner. Aber wenn ich in den Agentenmodus in VS Code wechsle und ihr seht, wenn ihr anfängt, /specify einzugeben, oh, ich kann nicht slsp specify tippen, richtig? Und ihr seht den Befehl dort nicht, bedeutet das, dass ihr im falschen Ordner seid, ihr seid eine Ebene zu hoch von dort, wo ihr sein müsst, um das zu tun. Wir schließen VS, gehen zurück zum Terminal und gehen zu cd pod site. Deshalb habe ich diese Anweisung hier in Grün hinterlegt, die ihr hier im Terminal sehen werdet. Sie heißt cd podsite. Geht in den Ordner, um diese Befehle verwenden zu können. Also, wir gehen dorthin, richtig? Und jetzt starten wir Code von hier. Fantastisch. Jetzt sind wir in VS Code. Jetzt sehen wir den GitHub-Ordner und Pod Site ist im Stammverzeichnis, was fantastisch ist. Das ist genau das, was ich wollte. Und jetzt sehe ich, dass es den GitHub-Ordner mit einer Menge Prompts gibt. Das werden unsere Slash-Befehle sein. Und Slash-Befehle in VS Code sind nichts anderes als benutzerdefinierte Prompts. Das ist alles, was es ist. Wenn ihr euch einen davon anseht, beschreibt er im Grunde eine Reihe von Anweisungen für das LLM, denen es folgen soll, um spezifische Konventionen für das, was wir bauen, festzulegen. In unserem Fall erfordert es die Ausführung eines bestimmten Skripts. Wir sehen einige Anweisungen für Dinge, die zu tun sind. Absolute Pfade verwenden. Das ist nett. Dasselbe für Specify. Dasselbe für Tasks. Und wir sehen gleich den Zweck dieser Befehle, nur in einer Sekunde hier. Und wir haben auch den Specify-Ordner. Nochmals, Shoutout an die Community-Mitglieder, die das vorgeschlagen haben, denn früher, wenn man Speicher und eine Menge dieser Hilfsskripte und Vorlagen hatte, landeten sie direkt im Repository-Stammverzeichnis, was nicht sehr hilfreich ist, wenn man bereits ein Projekt hat. Diese vereinfachen die Dinge also ein wenig. Ihr könnt sie also einfach in diesem Specify-Ordner aufbewahren. Und wenn ihr wollt, könnt ihr ihn sogar ignorieren, was ich nicht verstehe, warum ihr das tun würdet, aber ihr könnt es.
Jetzt, da wir diese grundlegenden Teile hier haben, lasst uns unsere Slash-Befehle verwenden. Ich werde die Chat-Box maximieren. Ich werde GPD5 verwenden, aber ihr könnt auch verschiedene Modelle verwenden. Ihr könnt tatsächlich mit verschiedenen Modellen experimentieren, die in Copilot oder einem der von euch verwendeten Agenten existieren, um zu sehen, welche Ausgabe für das, was ihr baut, besser ist. Die Ausgabe wird variieren. Äh, zum Beispiel mag ich persönlich GPD5 und Cloud Sonnet 4, aber je nachdem, was ihr baut und den Umfang dessen, was ihr baut, möchtet ihr vielleicht anpassen. Und wie ich bereits erwähnt habe, gibt es dieses Verfassungsdokument. Wenn ihr also zu Memory geht und es gibt Constitution, ist es im Moment nur eine leere Vorlage, aber wir können diese Verfassung mit Hilfe des LLM festlegen. Ich werde das also tun und wir werden das LLM bitten, es für uns auszufüllen. Füllt also die Verfassung mit den Mindestanforderungen für eine statische Web-App auf Basis einer Vorlage aus, denn wir wollen der Vorlage folgen. Die Verfassung. Wenn ihr euch auch das hier anseht, sind diese Prinzipien und Beispiele alle darauf ausgerichtet, es dem LLM zu erleichtern, es für euch auszufüllen. Das kann bootstrappen. Das bedeutet nicht, dass ihr das nicht manuell tun könnt. Es ist eher so, dass es für euch bootstrappt und euch etwas Zeit spart. Wir drücken also Enter. Mindestanforderungen. Und wir werden sehen, was dabei herauskommt. Wir werden GPD5 verwenden. Ich GBD5 ist gut für solche Dinge. Wenn ihr Dinge wie Sonnet verwendet, sehe ich, dass es manchmal aus dem Ruder läuft und eine Menge Dinge tut und die Verfassungsdatei bearbeitet und dann mehr Dateien erstellt, auf die es sich beziehen wird. Das wollen wir hier nicht. Also, ich verlasse mich einfach auf die Verfassung. Es ist in Ordnung. Und es wird den vorhandenen Inhalt und die vorhandene Vorlage betrachten, und ich hoffe, dass es das so ausfüllen wird, wie ich es möchte, denn wenn ich das manuell schreiben würde, würde es eine halbe Stunde dieses Videos dauern, und niemand möchte mir beim Tippen zusehen. Also geben wir ihm noch eine Sekunde. Ähm, ich habe auch bemerkt, dass GP5 manchmal etwas länger dauert als Sonnet. Also, Sonnet in diesem Zusammenhang mit Copilot wird einfach damit beginnen, daran zu arbeiten und ihr werdet sehen, wie sich die Änderungen allmählich in die Dateien einfügen. GPD5 ist ein wenig mehr, ich möchte sagen, nachdenklich, wo es anfangen wird zu denken und zu denken und zu denken und dann alles auf einmal ausspuckt, was wieder schön oder nicht so schön sein kann, je nachdem, welches Szenario ihr versucht zu bewältigen. Wählt also eure Kämpfe bei den Modellen, die ihr verwenden wollt, und probiert sie aus. Der einzige Weg, um herauszufinden, was hier die besten Ergebnisse liefert, ist durch Experimentieren. Genau wie SpecKit, SpecKit, die Spec-Driven Development-Sachen, die wir hier liefern, sind ein Experiment. Wir sind hier, um zu lernen. Ich möchte euch nur daran erinnern, dass dies kein Produktionsszenario ist. Es gibt viel für uns zu lernen. Wir wollen euer Feedback. Wir wollen euren Input. Wenn also etwas kaputt geht, wenn etwas nicht funktioniert, wenn etwas, das es produziert, Müll ist, lasst es uns wissen. Ich möchte diesen Müll sehen. Ich möchte verstehen, was funktioniert hat und was nicht, denn das wird uns helfen, es besser zu machen und dadurch das Produkt für alle anderen zu verbessern, die sich in ähnlichen Situationen wie ihr befinden könnten.
Es sieht so aus, als ob GBD5 immer noch nachdenkt. Es wird die Verfassungsdatei aktualisieren, indem es die Platzhalter durch konkrete statische Website-Anforderungen ersetzt. Wir warten also darauf, dass es diesen Prozess abschließt >> ein paar Momente später. >> Alles klar, es scheint fertig zu sein. Ich behalte also die Änderungen bei und sehen wir uns an, was es tatsächlich gesagt hat. Keine statische Erstauslieferung, keine serverseitige Ausführung. Die Website liefert HTML, CSS, JS und statische Assets über CDN. Das ergibt Sinn. Einfachheit über Werkzeuge. Bevorzugt Vanilla HTML, CSS, JS. Das gefällt mir. Ich denke, das ergibt Sinn. Barrierefreiheit und SEO-Grundlagen machen ebenfalls Sinn. Performance-Budget, wisst ihr, ich kümmere mich nicht unbedingt um diese Dinge, da wir gerade Prototypen erstellen. Für Produktionsszenarien solltet ihr euch unbedingt um Performance und Sicherheit kümmern. Vorerst möchte ich mich damit nicht befassen. Ähm, auch Dinge wie Anforderungen hier, Entwicklungs-Workflow, Qualitätskontrollen. Ähm, ja, das ergibt Sinn, aber ich denke, für das, was wir gerade tun, ist das ein bisschen zu viel. Wir werden also diese Teile entfernen. Und ich denke, viele der drei Prinzipien, die drei Artikel unserer Verfassung ergeben Sinn. Statische Erstauslieferung, Einfachheit über Werkzeuge und Barrierefreiheit und SEO-Grundlagen, was gut ist, richtig? Also, jetzt haben wir eine Verfassung. Ähm, jetzt kann ich den Specify-Befehl verwenden, von dem ich gesprochen habe, um die grundlegende Spezifikation zu definieren. Machen wir das also. Wir verwenden /sp specify. Und wieder, weil ich jetzt im richtigen Ordner bin, sehe ich slpspecify / specify. Und hier definiere ich wie ein echter Produktmanager das Was und das Warum. Wir konzentrieren uns nicht auf technische Anforderungen. Wir konzentrieren uns nicht darauf zu sagen, verwende Nex.js und diese Datenbank und so weiter. Wir kümmern uns im Moment nicht darum. Es geht darum, sicherzustellen, dass wir die Motivation für das Produkt und das, was tatsächlich gebaut werden muss, darlegen. Das ist hilfreich, denn für jemanden, der das liest, wird es vollständig von der Implementierung getrennt sein. Das ist wichtig. Der Vorteil der Spezifikation ist, dass sie vollständig von der Implementierung getrennt ist. Wenn wir das also irgendwann mit Nex.js bauen, aber irgendwann zu Hugo oder einem anderen statischen Site-Generator wechseln, verwendet ihr dieselbe Spezifikation. Die Spezifikation ist geschrieben, die Anforderungen sind da, ihr werft sie einfach in ein LLM und bittet es, euch drei, vier, fünf, sechs Varianten basierend auf derselben Spezifikation zu schreiben. Also irgendwie nett. Ein Nebeneffekt dessen, worum es hier geht.
Also, wir gehen hier zurück und verwenden Specify, und hier sage ich, was meine Anforderungen sind. Ich baue also eine moderne Podcast-Website, die schick aussehen soll. Wir wollen den Begriff schick verwenden. Ich denke, die Jugend benutzt diesen Begriff heutzutage, schick. Ich möchte, dass sie schick ist. Etwas, das auffallen sollte, sollte eine Landingpage mit einer Featured Episode haben. Es sollte eine Episoden-Seite, eine Über-uns-Seite und, mal sehen, eine FAQ-Seite geben. Es sollte 20 Episoden haben und die Daten sind gemockt. Ihr müsst nichts aus einem echten Feed ziehen, richtig? Wir legen also nur die Anforderungen fest. Wir trennen uns von den technischen Details. Wir denken nicht über technische Details nach. Wir sagen einfach, das ist, was ihr baut. Ich denke, das ist für mich gut genug, um anzufangen. Nochmals, für ein echtes Produktionsszenario gilt: Je detaillierter der Prompt, desto besser für uns, denn wir betrachten diesen sehr grundlegenden Kontext. Wir werden das einfach verwenden und ich werde Specify verwenden. Und was passieren wird, ist, dass es tatsächlich unseren Prompt-Datei verwenden wird, richtig? Das wird die Datei-Anweisungen und Specify Prompt MD verwenden, denn das ist die Prompt-Datei, die den Slash-Befehl steuert, richtig? Es wird das Skript lesen, das dort referenziert wird. Das ist sehr wichtig. Es wird die Spec-Vorlage lesen, die als Grundlage verwendet wird, denn schaut, es gibt einen Vorlagenordner. Und es wird uns fragen, ob wir dieses PowerShell-Skript ausführen wollen. Und äh, ja, lasst uns tatsächlich Auto-Approve YOLO-Modus zur Rettung aktivieren. Und weil ich das in einer VM ausführe, mache ich mir keine wirklichen Sorgen. Ich sage einfach "Erlaube die Ausführung dieses Befehls". Es wird ein PowerShell-Skript ausführen, ein Hilfsskript. Großartig. Es hat zu einem neuen Branch gewechselt, denn wie ich bereits erwähnt habe, ist das Git-basiert. Wenn ihr das also in eurem Projekt ausführt, werden diese benutzerdefinierten Branches verwendet, um eure Arbeit zu organisieren. So beschädigt ihr nichts in der Produktion und könnt Änderungen, die euch nicht gefallen, immer rückgängig machen. Wieder ein Nebeneffekt des Spec-Prozesses, die Tatsache, dass er euch zwingt, über viele dieser Dinge nachzudenken, während ihr experimentiert und iteriert, wollt ihr die bestehende Implementierung nicht beeinträchtigen. Richtig? Die Spezifikation legt also die Grundlage fest. Ihr arbeitet sie durch, ihr experimentiert, und dann mergt ihr sie nach Bedarf in euren Hauptbranch ein.
Sieht so aus, als würde er einige Informationen aus der Spezifikationsdatei lesen, die er hilfreich in den Specs erstellt hat. Die Datei ist im Moment leer, weil er die Vorlage noch nicht eingefügt hat, aber wir werden sehen, wie GPT5 bald alle erforderlichen Informationen einfügt, was nett sein wird. Wunderbar. Wir haben jetzt eine Spezifikation. Ich behalte sie, weil ich ihr einfach so sehr vertraue. Ich vertraue dem LLM wirklich nicht, Produktionssoftware für euch zu erstellen. Überprüft es einfach. Ihr müsst es überprüfen. Überprüft die Software-Aussage, die in der Spezifikation gemacht wird. Also, wir schauen uns die Spezifikation an. Sie hat Dinge für eine moderne Podcast-Website erstellt. Großartig. Das ist es, was ich darum gebeten habe. Äh, schauen wir uns hier die schnellen Richtlinien an, die wieder die Richtlinie für die Spezifikation sind. Wir müssen sie respektieren. Das LLM muss sie respektieren. Konzentriert euch darauf, was Benutzer brauchen und warum. Großartig. Äh, für KI-Generierung all die Dinge, die wieder hilfreiche Grundlagen sind, die wir beibehalten und respektieren müssen. Also Benutzerszenarien und Tests. Alles klar. Es gibt einige User Stories und wenn ihr ein PM seid, wird euch das sehr bekannt vorkommen. Wir haben einige Akzeptanzszenarien. Wir haben einige Edge Cases, richtig? Es hat Dinge wie die Reihenfolge der Episoden, die nicht spezifiziert ist, und so weiter berücksichtigt. Es gibt auch eine Menge funktionaler Anforderungen, die, wenn ihr ein PM seid, funktionale Anforderungen sind, die in die Spezifikation gehören. Das ist, wisst ihr, es ist für euch erledigt. Äh, es gibt eine Menge Dinge hier, aber beachtet auch, dass es eine Überprüfungs- und Akzeptanz-Checkliste gibt. Das ist hier entscheidend. Ich kann das nicht genug betonen. Wenn ihr eine Spezifikation habt, wenn ihr eine Spezifikation schreibt, müsst ihr sicherstellen, dass ihr eine Akzeptanz-Checkliste habt und sicherstellen, dass die Akzeptanz-Checkliste tatsächlich ausgefüllt ist. Also Dinge wie keine Implementierungsdetails, richtig? Sprachen, Frameworks, APIs, denn darum geht es uns nicht. Wir konzentrieren uns auf das Was und das Warum, nicht auf das Wie. Äh, ich habe auch Details über, wisst ihr, nicht-technische Stakeholder, obligatorische Abschnitte ausgefüllt. Eine Sache, die nicht angekreuzt ist, ist "keine Klärung erforderlich". Und das ist tatsächlich etwas, das hier gerade fehlt, denn wenn ihr euch die Punkte anseht, die geklärt werden müssen, wie die Reihenfolge der Episodenliste sollte umgekehrt chronologisch sein, neueste zuerst, bestätigt die Reihenfolge. Jetzt, da wir Prototypen erstellen und damit experimentieren, kann ich das LLM bitten, eine bestmögliche Schätzung vorzunehmen. Wir werden das also für Dinge tun, die geklärt werden müssen. Verwendet die bestmögliche Schätzung, die ihr für vernünftig haltet. Aktualisiert die Akzeptanz-Checkliste danach. Und wir lassen das LLM das im Grunde für uns ausfüllen, weil ich nicht möchte, dass ihr über diesen Prototyp nachdenkt. Ich möchte nur, dass ihr ein bisschen Vibe Coding macht, schätze ich, aber es ist nicht wirklich Vibe Coding, weil ich das ein bisschen besser strukturiere als nur Vibe Coding.
Also, sobald die Spezifikation festgelegt ist, denkt daran, dass sie sehr einfach mit eurem Team geteilt werden kann. Wenn also jemand kommt und sagt, wie habt ihr diese Website erstellt, schaut euch die Spezifikation an, schaut euch die Begründung an. Ihr als Mensch im Loop könnt hineingehen und das bearbeiten. Leute machen den Fehler zu denken, dass das LLM das produziert hat. Ich kann das nur mit dem LLM verwalten. Nein, es ist eine Markdown-Datei. Geht mit euren Händen hinein und fangt an zu tippen und Anforderungen einzugeben, die ihr für euer Produkt als notwendig erachtet. Wenn ihr also fest davon überzeugt seid, dass die Landingpage ein Logo in der Mitte und einen Farbverlauf haben sollte, der wie ein Regenbogen aussieht, könnt ihr das absolut tun. Fügt einfach eine weitere funktionale Anforderung hinzu, die ihr manuell erledigen könnt. Ihr müsst das LLM nicht bitten, das zu tun. Ähm, und das ist besonders wichtig, wenn ihr in Unternehmensumgebungen oder kontrollierteren Umgebungen arbeitet, wo ihr tatsächlich spezifische Anforderungen hinzufügen müsst. Manchmal kann das LLM nicht für euch raten, was in Ordnung ist. Manuelle Arbeit gibt es immer noch, und wir als Entwickler müssen sie von Zeit zu Zeit machen. Also, wir warten einfach darauf, dass GBD5 hier ein wenig nachdenkt und unsere Klärungspunkte ausfüllt. Wir haben jetzt die aktualisierte Checkliste. Angeblich. Also, scrollen wir hier zurück. Also, alles klar, sieht so aus, als wären wir gut. Keine Klärung erforderlich, nirgendwo im Code, was unsere Spezifikation ist. Es ist eigentlich kein Code. Es ist eine Markdown-Datei. Wir schauen hier. Es sieht großartig aus. Ich denke, wir sind bereit für den nächsten Schritt. Der nächste Schritt ist, dass wir den Slash Plan Befehl verwenden werden. Und hier legen wir tatsächlich die technischen Anforderungen fest. Ich werde Next.js JS mit statischer Site-Konfiguration verwenden. Keine Datenbanken und wir müssen sicherstellen, dass die Seite reaktionsfähig und für Mobilgeräte bereit ist, denn 2025 haben wir immer noch Mobiltelefone. Wir brauchen sie. Das ist also gut. Es gibt uns eine Grundlage, über die wir nachdenken können. Wir werden also wieder den Plan-Prompt verwenden. Er wird auch einige Hilfsskripte ausführen. Wir brauchen also Zugriff auf das Terminal hier in VS Code oder einem anderen Agenten, den ihr verwendet. Wenn ihr Cloud Code verwendet, verwenden wir einfach Cloud Code, weil Cloud Code sehr gut darin ist, Dinge direkt in eurem Terminal auszuführen. Es wird auch einige zusätzliche Inhalte bootstrappen, die wir bald im Repository sehen werden. Dinge wie der Plan, der Vertrag und beachtet vor allem, dass er die Verfassung konsultiert. Es gibt dann die Verfassung, die Verfassung und die Plan-Vorlage. Die Verfassung ist also in Kraft, die Reihe von nicht verhandelbaren Dingen, über die wir früher gesprochen haben, ist immer noch in Kraft, sehr wichtig.
Wir führen also das Skript aus. Wir erlauben es. YOLO. Nicht ganz YOLO, weil ich es aus irgendeinem Grund immer noch genehmigen musste. Aber wir sehen das JSON hier, das ist die Ausgabe des Skripts, denn wenn es JSON ist, ist es für das LLM sehr einfach zu parsen und zu verstehen. Beachtet, dass es die Verfassung gelesen hat, denn das sind nicht verhandelbare Prinzipien. Wir müssen sie respektieren, egal was ihr tut. Also habt ihr diesen Plan-Schritt, der ihn liest und dann den eigentlichen Plan und eine Menge zusätzlicher Metadaten ausfüllt, die uns helfen werden, eine gute Projektbasis zu schaffen. Beachtet, dass, weil all das Zeug auch in einem dedizierten Ordner liegt. 001 Ich baue, weil es einfach von eurem Prompt aufgegriffen wird und einen Namen für die Funktion generiert. All das Zeug ist hier gruppiert. Wenn ihr also später beschließt, die gesamte Funktion neu zu erstellen, wie ihr seht, was es gebaut hat, und denkt: "Weißt du was, Set 5 oder besser gesagt Set 4 hat nicht ganz das getan, was es erwartet hat. Ich möchte zu GPT5 wechseln oder vielleicht zu GPT41 wechseln und ausprobieren, wie das funktioniert, vielleicht für Gemini Flash. Ihr habt im Grunde die Spezifikation. Ihr habt alle eure Artefakte. Ihr könnt einfach die Quelle löschen. Die Spezifikation ist immer noch da und dann verwendet ihr den Model-Switcher hier im Chat und implementiert sie neu. Das ist alles. Ihr könnt sie einfach neu erstellen. Ihr könnt zusätzliche Anforderungen hinzufügen. Wenn ihr seht, dass das Logo falsch generiert wurde oder das Layout der Seite seltsam ist. Es gibt keinen Header und Footer. Geht hin und bearbeitet die Spezifikation und erstellt die Quelle neu. Sobald die Quelle erstellt ist, könnt ihr natürlich anders damit iterieren. Ihr könnt eine weitere Spezifikation für eine weitere Funktion, für eine weitere Komponente hinzufügen. Ihr, die eine Spezifikation, die wir hier in diesem sogenannten Greenfield-Projekt haben, weil wir etwas Neues erstellen, ist nur der Bootstrap des Projekts. Ihr könnt dasselbe für jede andere Funktion tun. Wenn ihr Unterstützung für einen Spotify-Player zum Beispiel auf eurer Podcast-Seite hinzufügen möchtet, verwendet einfach Specify, um im Grunde eine neue Funktion zu erstellen, richtig? Das ist es irgendwie. Ihr verwendet Plan, um eine weitere Reihe von technischen Details für diese Funktion zu erstellen, denn das ist es, was es tun wird. Es wird neue Unterordner erstellen, die ihr dann bearbeiten könnt.
Also, wir warten hier ein wenig darauf, dass GPD5 nachdenkt. Aber beachtet, dass es tatsächlich angefangen hat, über Dinge wie Verträge nachzudenken, weil es sich Datenverträge ansieht, die innerhalb der Seiten existieren. Aber ich werde es nicht stören. Ich lasse es nachdenken und seine Arbeit machen. Und wir kommen zurück, sobald wir das tatsächliche Ergebnis des Prozesses sehen. >> Nein. Gott, nein. Gott, bitte. Nein. Nein. Nein. Nein. >> Alles klar. Wir haben jetzt den Plan. Der Plan ist gut. Wir können ihn uns ansehen. Wir sehen Plan. Ich behalte alle Änderungen bei. Es hat eine Menge anderer Metadaten erstellt. Wir können also durch den Plan scrollen. Wir können das Terminal ein wenig minimieren. Wir sehen, dass es einen Ausführungsfluss für den Plan hat. Großartig. Äh, technischer Kontext, Sprachversion, JavaScript, TypeScript und Node.js. Großartig. Primäre Abhängigkeiten, Nex.js, Static Expert, SSG, richtig? Weil wir nach einer statischen Website gefragt haben. Das ist großartig. Es denkt darüber nach. Tests Lighthouse und einige andere Bibliotheken. Zielplattform statisches Hosting über CDN Versify GitHub Pages. Azure Static Web Apps. Das ist richtig. Ich habe tatsächlich einige gute Annahmen getroffen. Ich habe das nicht spezifiziert. Beachtet, dass, wenn ich zum Beispiel Dinge auf Cloudflare oder Azure hosten wollte, ich das in der Verfassung angeben könnte. Ich kann sagen, dass alles, was ihr tut, auf Cloudflare oder Azure oder einen anderen Anbieter ausgerichtet sein muss, was immer ihr wollt, oder andere technische Anforderungen, übrigens.
Also, wir haben die Projekttypen, einige Verfassungsprüfungen und es gibt ein Gate, das wieder die Verfassungsprüfung bestehen muss, es muss die Anforderungen bestehen, die wir für Dinge wie die Verwendung eines Frameworks, eines einzelnen Datenmodells, die Vermeidung von Mustern, ja, Architektur, statische Erstauslieferung, minimale Abhängigkeiten, ja, das ergibt Sinn, das ergibt Sinn. Es gibt eine Gliederung für Gliederung und Forschung. Alles klar, einige Forschungsartefakte erstellt. Und übrigens, Copilot hat in diesem Fall keine tatsächliche Recherche durchgeführt, sondern seine Trainingsdaten verwendet, um diese Research.mmd-Datei zu erstellen. Andere Agenten wie Copilot, Entschuldigung, wie Quad Code können tatsächlich recherchieren. So bekommt ihr die aktuellsten Informationen aus dem Internet. Aber es hat tatsächlich ziemlich gute Annahmen getroffen. Also haben wir den Kontext, wir haben einige der Gliederung der Phasen. Und jetzt seht ihr, uns fehlt die generierte Aufgabe. Wir werden jetzt den Task-Befehl ausführen. Aber bevor wir das tun, schauen wir uns das hier an. Es gibt also eine Forschungsdatei, wie ich erwähnt habe. Sie hat ihre Trainingsdaten durchsucht, denn das alles wird im Grunde vom LLM generiert, richtig? Es ist alles, was in den Trainingsdaten eingebettet ist. Das ist, was es als Inspiration verwendet, anstatt tatsächlich ins Web zu gehen. Wir können etwas wie den Beast Mode von unserem guten Freund Burke Holland verwenden, um es zu zwingen, bestimmte Dinge zu tun, aber ich benutze hier nur den Standard-Agentenmodus, weil ich keine benutzerdefinierten Modi verwendet habe, was in Ordnung ist für unseren Prototyp. Es ist in Ordnung. Also haben wir das. Wir haben eine Datenmodell-Gliederung für Felder einer Episode, was wieder großartig ist. Es hat den Kontext. Wir bauen eine Podcast-Website, einige Details zur Website, einige Validierungsregeln, abgeleitete Ansichten. Wir haben immer noch unsere Spezifikation. Wir haben unseren Quick Start, der eine Vorstellung davon gibt, worum es auf der Website geht und welche Voraussetzungen für die Ausführung der Website erforderlich sind. Wieder super super schön, das an einem Ort zu haben. Die Spezifikation und alle Artefakte werden zu diesem ausführbaren Kontext, den ihr an euer Team weitergeben und sie damit arbeiten lassen könnt. Aber wir haben den Plan u, und wie der Plan sagt, müssen wir zu unseren Aufgaben springen. Also können wir Tasks verwenden und sagen, zerlegen wir das. Richtig? Also wird es wieder einige Hilfsskripte ausführen, die es leiten werden, und es wird die Arbeit in überschaubare Stücke zerlegen, die der Agent einzeln bewältigen kann, denn das ist super schön. Das ist irgendwie die Fähigkeit, genau zu sehen, was es tun muss, anstatt anzunehmen, dass es an bestimmten Aktionen teilnehmen muss. Richtig? Wenn ich also den Test-Driven-Development-Ansatz verfolgen möchte, bei dem ich Tests zuerst haben möchte, all das Zeug, das kann in einzelne Aufgaben zerlegt werden. Es wird das zuerst tun. Es wird sicherstellen, dass die Tests bestanden werden, und dann zur Implementierung des Datenmodells und so weiter übergehen.
Also, wir werden es noch etwas mehr Arbeit machen lassen. Ich werde die Task-Voraussetzungen prüfen. Alles klar. Es wird eine Testvorlage verwenden. Es wird die Dinge für uns einrichten. Und wir erhalten eine weitere Tasks.md-Datei, eine weitere Markdown-Datei in unserem Ordner, die wir verwenden können, um die Aufgaben tatsächlich zu durchsuchen. Im Moment, weil alles Markdown ist, ist es für euch als Entwickler verfügbar. Ihr könnt das LLM hier in dieser Chat-Ansicht verwenden und es einfach durch all die Dinge führen, die ihr braucht. Oder ihr könnt einfach in das Markdown gehen und damit herumspielen, weil es so einfach zu bearbeiten ist. Es braucht keinen proprietären Editor irgendeiner Art. Ihr könnt das einfach öffnen und wisst ihr, überall dort, wo ihr Copilot integriert habt, wisst ihr, es muss nicht unbedingt VS Code sein, ich benutze zufällig VS Code, richtig? Und wieder, SpecKit und Specify sind mit vielen anderen Agenten kompatibel und es kommen noch mehr Agenten, wie ich gerade an OpenAI Codex arbeite, QN, wir schauen uns das auch an, Open Code Root Code, all diese wunderbaren Projekte aus der Community werden kommen. Also, ich lasse Chat oder GPD5 fünf in diesem Fall ein wenig nachdenken und unsere Aufgabenliste erstellen. Schaut mal. Wir haben unsere Aufgaben-Datei. Wenn ich also hier wieder hingehe, behalten wir alle Änderungen bei. Und wir sehen eine Menge T. Lasst uns die Größe hier tatsächlich reduzieren, richtig? Ihr könnt also tatsächlich ein wenig sehen. Wir werden die Größe davon auch reduzieren. Ähm, und wir sehen die Abschnitte hier, richtig? Es hat das einfach in einzelne Phasen zerlegt. Wir haben Setup, Initialisiere Next.js App Skeleton. Yep. Yep. Das klingt gut. Test zuerst muss vor 33 fehlschlagen. Alles klar. Ja, weil wir hier Test-Driven Development verwenden wollen. Okay, das klingt gut. Kernimplementierung nur nach fehlschlagenden Tests, richtig? Weil wir zuerst die Tests einrichten. Ergibt Sinn. Über uns-Seite, und so weiter. Integrationsverfeinerung, Lighthouse ausführen. Und hier kann ich, wisst ihr, ihr könnt Dinge ändern, Dinge entfernen, die euch nicht gefallen. Wisst ihr, wollt ihr Lighthouse auf einem Prototyp ausführen? Vielleicht, vielleicht nicht. Und natürlich, Politur, reaktionsfähige Bilder, Dokumentation, alles gut. Barrierefreiheit Politur. Klingt gut. Ich denke, wir sind bereit. Ich denke, wir sind bereit, das zu implementieren.
Also, ich werde jetzt mein Modell auf Cloud Sonnet 4 umstellen, weil ich das für Code am besten mag. GBD5 ist gut darin, das Spezifikations-Scaffolding für uns einzurichten, aber für kreative Ausgaben ist Sonnet 4 für mich immer noch unschlagbar. Also, ich sage das einfach und sage: Implementiere die Aufgaben für dieses Projekt und aktualisiere die Aufgabenliste, während du vorgehst. Und jetzt lassen wir den Agenten wild laufen und unsere Website implementieren. [Musik] [Applaus] Hit. [Musik] Hit. [Musik] Hit. Hit. [Musik] Danke. [Musik] [Musik] Tada. Sieht aus, als hätte er es geschafft. Er hat die Arbeit beendet. Er hat die Dinge getan, die er tun sollte. Jetzt habe ich die Ausgabe nicht gesehen. Das wird eine Überraschung. Also, behalten wir alle Änderungen bei. Stellen wir sicher, dass wir sie behalten. Es hat alle Aufgaben aktualisiert. Es ist bei einigen Lighthouse-Tests fehlgeschlagen, aber das liegt daran, dass ich Chrome nicht installiert habe. Aber wir können tatsächlich npm ausführen, ich mag es, num npm run build auszuführen. Lasst uns unsere statische Website bauen und dann werden wir npm npm rundev ausführen, um sie tatsächlich in Aktion zu sehen, sobald sie tatsächlich gebaut ist. Wir werden also sehen, wie sie aussieht. Alles klar. Auswahl von Build-Traces, die anscheinend am zeitaufwendigsten sind. Alles klar. Und dann npm run dev. Okay. Localhost 3000. Mal sehen, wie unsere Podcast-Website aussieht. Sie lädt. Das kann schrecklich schlecht sein. Aber eigentlich, schaut, es ist nicht schlecht. Es, wisst ihr, meistert die Kunst des Podcastings. Featured Episode sieht gut aus. Hat alle Details. Pod Site. Ich habe meine Über-uns-Seite. Wenn ich hierher gehe, gibt es eine schöne Beschreibung. Alles klar. FAQ. Okay. Ja, es gibt eine FAQ. Alles klar. Großartig. Episoden. Schauen wir uns das hier an. Wir haben einzelne Podcast-Episoden mit Links zur Podcast-Plattform. Und bedenkt, dass ich in diesem Zusammenhang auch, wenn ich MCP-Tools wie Figma MCP einbinde, auf tatsächliches Design verlinken kann. Ich kann es also tatsächlich dazu bringen, Dinge zu bauen, die zum Designsystem meiner Organisation passen. Ich muss also nicht zufällig annehmen, dass es das Richtige bauen wird. Das ist also irgendwie nett. Es hat all diese Dinge erstellt.
Jetzt fragt ihr euch vielleicht: Ist das wirklich besser als Vibe Coding? Ich hätte diese gesamte Pod Site per Vibe Coding erstellen können, richtig? Aber der Punkt ist, dass ich jetzt, da ich die Spezifikation habe, da ich die Artefakte hier in meiner Spezifikationsimplementierung habe, sie leicht anpassen kann. Ich kann sie jetzt verfeinern. Ich kann Dinge hinzufügen, wie ich möchte sicherstellen, dass die Farbe auf eine bestimmte Weise ist. Ich möchte sicherstellen, dass eine bestimmte Designentscheidung getroffen wird. Und das erleichtert es mir, Dinge neu zu implementieren und neu zu erstellen und Funktionen additiv auf strukturierte Weise hinzuzufügen, weil das dann als Kontext verwendet werden kann. Also etwas, woran mein Kollege und Freund John Lamb arbeitet, ist die Optimierung einiger dieser Strategien zur Erfassung von Kontext. Das wird sich also in Zukunft ändern. Aber ihr könnt euch vorstellen, dass es, je mehr Kontext ich im Speicher des Systems habe, das gebaut wird, einfacher wird, konsistente Software zu bauen. Hoffentlich ist dies eine großartige Einführung für euch, um zu sehen, wie SpecKit funktioniert, was die Artefakte sind und wie es sie produziert und wie ihr sie dann anpassen könnt. Ich hoffe wirklich sehr, dass ihr zu SpecKit geht. Probiert es aus. Bringt es auf eurem Rechner zum Laufen. Seht, was funktioniert und was nicht, besonders wenn ihr viele verschiedene Funktionen und Fehlerbehebungen und all diese Dinge für eure Projekte zusammenfasst. Lasst es mich wissen. Geht zu github.com/github/spec-kit. Ladet es herunter. Benutzt es. Sagt mir, was falsch ist. Und dann sehen wir uns im nächsten Video, wo wir über komplexere Dinge sprechen werden, die ebenfalls mit Hilfe von Spec-Driven Development erreicht werden. Ich hoffe, euch gefällt das. Bis zum nächsten Mal.