Erst suchen, dann schreiben: der Prompt, der dir Stunden spart

Was „erst suchen, dann schreiben“ bedeutet

Du musst einen Nagel einschlagen. Weg eins: Du gehst in die Garage, nimmst den Hammer - er liegt da, bewährt, bequem, schon dein Opa hat damit Nägel eingeschlagen. Weg zwei: Du schmiedest dir aus einem Stück Eisen von Grund auf deinen eigenen Hammer, weil „ich mach das ja selbst, so ist es interessanter“.

Klingt wie ein Witz. Und jetzt die Überraschung: genau Weg zwei wählt der Agent standardmäßig - solange du nichts anderes sagst. Sag ihm „mach ein Formular mit E-Mail-Prüfung“ - und er codet munter sein eigenes Stückchen für diese Prüfung. Obwohl es längst fertige, von tausenden Menschen abgeschliffene Tools gibt, die genau dasselbe tun - besser, zuverlässiger und kostenlos.

Die Gewohnheit „erst suchen, dann schreiben“ ist simpel. Du zwingst den Agenten, sich zuerst umzuschauen: Gibt es nicht schon was Fertiges? Und nur wenn wirklich nichts da ist - ran ans Schmieden.

Warum eine fertige Lösung besser ist als selbstgeschriebener Code

Du bist Vibecoder. Code tippst du nicht mit den Händen - aber du steuerst den, der ihn tippt. Und wenn man den Agenten nicht lenkt, fängt er aus Gewohnheit an, alles von null zu erfinden. Womit trifft dich das ganz persönlich?

• Länger. Eigenes von Grund auf - das sind Stunden. Fertiges anbinden - Minuten.
• Teurer. Der Agent verbrennt Token Token - ein Stückchen Text, mit dem das Modell liest und schreibt. Je mehr Code es ausdenkt, desto mehr Token, also desto mehr von deinem Geld. (dein Geld) dafür, etwas auszudenken, das längst im Regal lag.
• Fehleranfälliger. Frisch selbstgeschriebener Code ist fast immer roh. Fertiges wurde schon an Millionen Nutzern erprobt.
• Mühsamer zu reparieren. Bricht Selbstgeschriebenes, musst du es selbst Stück für Stück aufdröseln. Eine beliebte Bibliothek hat Doku und Foren, wo jemand dein Problem schon vor drei Jahren gelöst hat.

Der Unterschied zwischen „der Agent hat mir eine Website gebaut, die nach einer Woche zerfiel“ und „der Agent hat mir eine Website aus zuverlässigen Bausteinen zusammengesetzt“ - oft ist es genau eine Gewohnheit: erst suchen, dann schreiben.

Wo der KI-Agent nach Fertigem sucht: vier Regale

Wenn man dem Agenten sagt „such erst“, stürzt er sich nicht aufs Coden. Er geht vier „Regale mit Fertigem“ ab - ungefähr in dieser Reihenfolge, vom Nahen zum Fernen.

1. Dein eigenes Projekt

Zuerst - das Naheliegendste. Vielleicht ist es schon in deinem eigenen Projekt geschrieben? Ein Klassiker: Du bittest um „mach einen Senden-Button“, und so ein Button lebt schon in der Nachbardatei. Der Agent findet ihn und nutzt ihn wieder - statt ein zweites identisches Stück zu produzieren.

2. Fertige Bibliotheken und Pakete

Weiter - die große weite Welt. Es gibt riesige Lager mit fremdem Code: Bibliotheken Paket (Bibliothek) - ein fertiges Stück Code, das jemand geschrieben, getestet und veröffentlicht hat, damit andere es einfach nehmen und nutzen. Wird mit einem Befehl angebunden. , die sich mit einem Befehl installieren lassen. Brauchst du eine Datenprüfung, einen Mailversand, einen schicken Kalender - mit ziemlicher Sicherheit hat das schon jemand gemacht und veröffentlicht.

3. Tools, Erweiterungen und MCP

Manchmal ist das, was du brauchst, keine Bibliothek, sondern ein ganzes fertiges Tool - zum Beispiel ein anschließbares MCP MCP - eine Möglichkeit, dem Agenten ein fertiges externes Tool zu geben: Zugriff auf eine Datenbank, auf die Mail, auf den Kalender und so weiter. Das musst du nicht von Hand schreiben - du schließt es einfach an. oder ein Skill. Dann gibt es für den Agenten überhaupt nichts zu coden - er nimmt einfach das Fertige und nutzt es.

4. Open Source und Beispiele im Internet

Und nur wenn nichts gepasst hat - schaut der Agent, ob es nicht eine ähnliche Vorlage oder ein Beispiel auf GitHub gibt. Damit er wenigstens nicht mit einem leeren Blatt anfängt, sondern sich auf fremde Erfahrung stützt.

Wann man Fertiges nimmt und wann man Eigenes schreibt

Fertiges zu finden ist die halbe Miete. Danach musst du verstehen: lohnt es sich überhaupt, es zu nehmen? So trifft der Agent (und du mit ihm) die Entscheidung.

Beispiel: ein Anmeldeformular mit E-Mail-Prüfung

Du sagst dem Agenten: „mach ein Newsletter-Anmeldeformular - das prüft, dass die E-Mail echt ist“.

Ohne richtigen Prompt: Der Agent denkt sich munter seine eigene E-Mail-Prüfung aus. Er schreibt eine trickreiche Formel, die auf den ersten Blick funktioniert, in Wahrheit aber krumme Adressen durchlässt und normale blockiert. Eine Woche später stellt sich heraus, dass die Hälfte der Leute sich nicht anmelden kann - und du gehst zum Agenten, um das zu reparieren, was er selbst verbockt hat.

Und so macht es ein Vibecoder, der Bescheid weiß. Er fügt der Bitte eine Vorgabe hinzu - „such erst nach Fertigem“:

Ich brauche ein Newsletter-Anmeldeformular mit E-Mail-Prüfung.
Bevor du Code schreibst, mach Folgendes:

Check, ob es in meinem Projekt nicht schon passenden Code gibt - vielleicht existiert ein ähnliches Formular oder eine Prüfung bereits.
Such nach beliebten fertigen Bibliotheken für E-Mail-Prüfung und für Formulare. Nimm die, die wirklich genutzt werden und kürzlich aktualisiert wurden.
Zeig mir 2-3 Optionen als kurze Liste: was du gefunden hast, was daran gut ist, was du wählst und warum.
Und erst danach binde das Gewählte an. Eigenen Code schreib nur dort, wo es wirklich nichts Fertiges gibt.

Häufige Anfängerfehler bei der Lösungssuche

• Du bittest um „schreib X“ statt um „finde fertiges X“. Ohne das Wort „finde“ fängt der Agent standardmäßig bei null an. Füg die Vorgabe zu suchen hinzu - jedes Mal.
• Du greifst zum Erstbesten. Bibliothek gefunden - schau, ob sie lebendig ist und ob sie genutzt wird. Verlassener Code fliegt dir genau dann um die Ohren, wenn du keine Zeit hast.
• Du schleppst einen Brocken wegen einer Kleinigkeit an. Du brauchst keine gigantische Bibliothek für einen einzigen Button. Halt die Größe zur Aufgabe im Verhältnis.
• Du fragst nicht, was der Agent gewählt hat. Bitte ihn, die Optionen als Liste zu zeigen - und du siehst ohne unangenehme Überraschungen, worauf dein Projekt aufbaut.
• Du erfindest etwas, das es in deinem eigenen Projekt schon gibt. Der häufigste und ärgerlichste Fall - das zu duplizieren, was seelenruhig in der Nachbardatei liegt.