Blueprint im Vibecoding: von der Idee zum Plan in einem Prompt
So wird aus „ich will eine App“ ein Bauplan, nach dem der Agent wirklich baut
Blueprint im Vibecoding ist ein Projektplan aus einem einzigen Ideen-Satz. Du lernst, die Aufgabe in Schritte zu zerlegen, Abhängigkeiten zu sehen und den Agenten so zu fragen, dass kein Brei rauskommt.
Was ein Blueprint ist - einfach erklärt
Stell dir vor: Du kommst zu den Bauarbeitern und sagst „baut mir ein Haus“. Die schnappen sich die Hämmer und legen los. Eine Woche später - drei Wände, eine Treppe ins Nichts und ein hitziger Streit, wo eigentlich die Küche hin soll. Kommt dir bekannt vor? Genau so sieht Vibecoding ohne Plan aus.
Jetzt der vernünftige Anlauf. Zuerst der Bauplan. Auf dem Papier wird festgelegt: wo das Fundament hinkommt, wo die Wände, was zuerst gebaut wird, was von was abhängt. Und erst danach - die Hämmer. Genau dieser Bauplan heißt beim Code blueprint Blueprint (engl. „Bauplan, Blaupause“) - ein Schritt-für-Schritt-Plan des Projekts: ein Ideen-Satz wird in kleine, klar verständliche Schritte zerlegt, jeder mit eigener Anleitung. Erst der Plan - dann der Code. .
Wozu braucht ein Vibecoder einen Blueprint
Du bist Vibecoder. Du schreibst den Code nicht von Hand - du stellst die Aufgabe. Und hier die Falle: ein großes Projekt kann man nicht in einem Satz bestellen und auf ein Wunder hoffen. Der Agent verschluckt sich, fängt an herumzueiern, schreibt das um, was schon funktioniert hat, und bleibt auf halber Strecke stehen, im Würgegriff seines eigenen Codes.
Blueprint heilt das so:
- er zerlegt die riesige Aufgabe in kleine Stücke, die man wirklich überprüfen kann;
- er gibt die Reihenfolge vor - was zuerst gebaut wird und was danach;
- er lässt dich in mehreren Etappen arbeiten: Sitzung geschlossen, morgen wieder geöffnet - der Plan steht noch;
- er fängt Stolperfallen frühzeitig, solange es noch Text ist und kein kaputter Code.
Der Unterschied zwischen „die KI hat mir einen unverständlichen Brei zusammengebaut“ und „die KI hat mir eine funktionierende App gebaut“ ist oft der Unterschied zwischen „ich habe alles auf einmal verlangt“ und „wir hatten einen Bauplan“. Der Plan ist genau die Kunst, richtig zu fragen.
Wie Claude den Plan baut: 5 Schritte eines Bauzeichners
Du startest den Blueprint - und Claude stürzt sich nicht auf den Code. Er durchläuft fünf Phasen, wie ein anständiger Architekt vor dem Bau. Der Reihe nach.
1. Erkundung des Grundstücks
Zuerst schaut sich der Agent das „Grundstück“ an: was schon im Projekt da ist, welche Dateien, welche Notizen und Regeln. Ein Haus zeichnen, ohne den Boden zu kennen? Eher mäßige Idee.
2. Design: die Idee in Stücke schneiden
Die Idee wird in überschaubare Arbeitspakete zerlegt (meist sind es 3-12 Schritte). Für jeden Schritt wird festgelegt: was von was abhängt, was parallel laufen kann und was strikt nacheinander, und wie man zurückrollt, falls etwas schiefgeht.
3. Plan-Entwurf und Kontext-Briefing für jeden Schritt
Hier kommt der raffinierteste Teil. Jeder Schritt wird so geschrieben, dass ihn ein frischer Agent ausführen kann, der die vorherigen Schritte überhaupt nicht gelesen hat. Im Schritt steckt ein Kontext-Briefing Kontext-Briefing - eine kurze, in sich geschlossene Anleitung innerhalb eines Plan-Schritts: was zu tun ist, wozu, wie man das Ergebnis überprüft. Dadurch führt der Agent den Schritt „aus dem Kaltstart“ aus, ohne irgendwas von vorher zu wissen. : was zu tun ist, wie man es überprüft und wann der Schritt als fertig gilt.
4. Prüfung durch einen zweiten Agenten
Den fertigen Plan gibt man einem anderen, pingeligeren Agenten. Der liest akribisch: ist alles bedacht, stimmt die Reihenfolge, lauern bekannte Stolperfallen. Kritische Löcher werden vor Baubeginn geflickt, nicht danach.
5. Eintragung des Plans ins Projekt
Der Plan wird in einer Datei gespeichert und ins „Inhaltsverzeichnis“ des Projekts aufgenommen. Danach bekommst du das Ergebnis gezeigt: wie viele Schritte es sind und welche davon man parallel machen kann.
Abhängigkeiten und Parallelität: warum die Reihenfolge der Schritte entscheidet
Die größte Stärke des Plans: Er erkennt Abhängigkeiten Abhängigkeit - bedeutet: ein Schritt kann erst starten, wenn ein anderer fertig ist. Man kann zum Beispiel keine Wände streichen, die es noch gar nicht gibt. Der Plan ordnet die Schritte in die richtige Reihenfolge. . Eine Tür hängst du nicht ein, solange keine Wand da ist. Die Bezahlung baust du nicht an, solange kein Warenkorb existiert. Die Reihenfolge ist hier keine Laune - das ist die Physik des Bauens.
Und der Plan merkt auch, dass sich manche Schritte gegenseitig nicht in die Quere kommen, und lässt sie parallel laufen. Die Seite „Über uns“ und die Seite „Kontakt“ überschneiden sich nirgends - also kann man sie gleichzeitig machen. Weniger Warten, mehr Erledigtes.
- Die Aufgabe ist groß: eine ganze App, eine Website, ein großes Feature.
- Die Arbeit zieht sich über mehrere Etappen oder Tage.
- Es gibt Reihenfolge und Abhängigkeiten: das eine geht nicht ohne das andere.
- Du willst morgen wiederkommen und genau an derselben Stelle weitermachen.
- Die Aufgabe ist winzig: einen Text korrigieren, eine Button-Farbe ändern.
- Erledigt in ein paar Handgriffen - den Plan zu schreiben dauert länger als das Machen.
- Du sagst selbst „mach jetzt einfach“ - mach es nicht komplizierter.
- Eine einmalige Kleinigkeit, die man notfalls neu machen kann, ohne dass es weh tut.
Beispiel aus dem Leben: Sticker-Shop ohne Plan
Du schreibst dem Agenten: „mach mir einen Shop zum Verkauf von Stickern“. Er startet munter und wirft alle Dateien auf einmal raus: Katalog, Warenkorb, Bezahlung, Admin-Bereich. Eine Stunde später - Überraschung. Der Warenkorb verträgt sich nicht mit dem Katalog, die Bezahlung wurde vor dem Login angebaut, die Hälfte muss schon neu geschrieben werden. Die Baustelle steht still.
Was ist schiefgelaufen? Du hast das ganze Haus in einem Satz bestellt, ohne Bauplan.
Und so geht ein Vibecoder ran, der sich schon mal die Finger verbrannt hat - er bittet zuerst um einen Plan:
Schreib noch keinen Code. Erstelle zuerst einen Schritt-für-Schritt-Plan für das Projekt - einen Online-Shop für Sticker.
Anforderungen an den Plan:
- Zerlege alles in kleine Schritte, jeder ein überschaubares, klar umrissenes Stück Arbeit.
- Für jeden Schritt schreib: was zu tun ist, was von was abhängt und wie man überprüft, dass der Schritt fertig ist.
- Gib an, welche Schritte man parallel machen kann und welche strikt nacheinander.
- Speichere den Plan in der Datei PLAN.md, damit ich morgen darauf zurückkommen kann.
- Zeig den Plan und halt an - warte auf mein „ok“, und erst dann fang mit dem ersten Schritt an.
Was tun, wenn sich der Plan unterwegs ändert
Der Plan ist nicht in Stein gemeißelt. Im Lauf des Baus stellt sich heraus: ein Schritt muss in zwei geteilt, ein neuer eingeschoben, einer übersprungen oder vertauscht werden. Und das ist völlig normal. Ein guter Plan ändert sich sauber - mit dem Vermerk „was und warum korrigiert wurde“, damit du den Faden nicht verlierst.
Häufige Fehler beim Arbeiten mit dem Blueprint
- Das ganze Projekt in einem Satz verlangen. Der Agent verschluckt sich. Bitte zuerst um einen Plan.
- Sich ohne Bauplan in den Code stürzen. Etwas Gebautes umzubauen - das sind Stunden, den Plan zu korrigieren - Minuten.
- Einen Blueprint für eine Kleinigkeit machen. Eine Button-Farbe muss man nicht planen - das dauert länger, als sie einfach zu ändern.
- Riesen-Schritte. „Mach den ganzen Shop“ kann man nicht überprüfen. Schneide es in überschaubare Arbeitspakete.
- Den Plan nur im Chat halten. Der Plan muss in einer Datei liegen (PLAN.md), sonst ist er nach einem Neustart einfach weg.
- Abhängigkeiten ignorieren. Bezahlung vor dem Warenkorb angebaut - plan schon mal Zeit fürs Umbauen ein. Die Reihenfolge entscheidet.
TL;DR - если коротко
- Blueprint - der Bauplan deines Projekts: aus einem Ideen-Satz wird ein Schritt-für-Schritt-Plan statt einer Code-Müllhalde.
- Jeder Schritt ist ein klar umrissenes Stück Arbeit mit eigenem Briefing. Ein frischer Agent erledigt ihn, ohne irgendwas von vorher zu wissen.
- Der Plan erkennt Abhängigkeiten: was nach was kommt und was parallel laufen kann.
- Den fertigen Plan liest ein zweiter Agent gegen - er fängt Löcher vor dem Bau, nicht danach.
- Erst der Plan, dann der Code. Den Bauplan zu korrigieren ist billiger, als ein fertiges Haus wieder abzureißen.
- Bei einem großen Projekt rettet dir der Blueprint den Hintern. Für „ändere die Button-Farbe“ stört er nur.