Die Reihenfolge für dein erstes eigenes Tool besteht aus sechs Schritten: ein Satz, was das Ding kann und für wen. Ein Merkzettel im Projektordner. Nur das Aussehen, klickbar und ohne Funktion. Einmal durchklicken. Dann der Code in einzelnen Stücken. Zum Schluss rausstellen und aufschreiben. Vier davon liegen vor der ersten Zeile Code und kosten zusammen 16 der 25 Minuten. Diese Seite spielt alle sechs offen aus. Das Blatt zum Ausfüllen liegt im PDF.
Warum scheitert der erste Versuch, sich ein Tool bauen zu lassen?
Weil er in der falschen Reihenfolge stattfindet. Du tippst „bau mir ein Tool", es kommt eine Menge Text, ein Haufen Dateien, und irgendwas läuft. Nur nicht das, was du wolltest. Du besserst nach, danach läuft das Alte nicht mehr, nach zwei Abenden löschst du den Ordner.
Genau so ist es mir auch gegangen. Zwei Abende drauflos getippt, rausgekommen ist nichts. Am dritten Abend stand nach 25 Minuten ein fertiges kleines Werkzeug da. Ein Selbsttest mit sieben Fragen, der Besucher klickt sich durch und trägt für sein Ergebnis seine Mailadresse ein. Am Werkzeug hatte sich nichts geändert. An mir auch nicht. Geändert hatte sich die Reihenfolge.
Der Grund dafür ist unspektakulär. Die Maschine ist nur so schlau wie der Satz, den du ihr tippst. Sagst du ihr am Anfang nicht, was das Ding können soll und für wen, dann rät sie. Und sie rät gut genug, dass du es erst nach zwanzig Minuten merkst.
Was sind die sechs Schritte, in denen ein erstes Tool entsteht?
Schritt 1 · Ein Satz. Was das Ding kann und für wen. Bevor du irgendetwas bauen lässt, schreibst du einen Satz auf. Nicht in die Maschine, auf ein Blatt. Zum Beispiel: „Ein Selbsttest mit sieben Fragen für Handwerksbetriebe, der am Ende ein Ergebnis zeigt und dafür die Mailadresse abfragt." Alles, was du hier offen lässt, erfindet die Maschine selbst: die Zielgruppe, die Anzahl der Fragen, das Aussehen des Ergebnisses. Danach baust du zwanzig Minuten an ihrer Erfindung herum statt an deiner. Das ist keine neue Idee, nur eine sehr kleine. Das Gabler Wirtschaftslexikon beschreibt die Anforderungsdefinition als das „Ermitteln der detaillierten Anforderungen an das Softwareprodukt (u.a. Funktionsumfang, Benutzerschnittstelle, Datenmaterial)" (Prof. Dr. Richard Lackes, Dr. Markus Siepermann, TU Dortmund). Dein Satz ist genau das, eingedampft auf eine Zeile. Der Test: Passt er in eine Zeile, und steht ein Für-wen drin? Fehlt eines von beiden, ist es noch ein Thema und kein Auftrag.
Schritt 2 · Der Merkzettel im Ordner. Leg in deinem Projektordner eine Datei an, die CLAUDE.md heißt. Hinein kommen vier Zeilen: dein Satz aus Schritt 1, was das Werkzeug ausdrücklich nicht können soll, die Farben, die du willst, und die Regel, dass nach jedem Schritt gestoppt wird. Diese Datei ist kein Trick, sondern der vorgesehene Weg. In der Dokumentation von Anthropic steht zu den CLAUDE.md-Dateien: „You write these files in plain text. Claude reads them at the start of every session." Dieselbe Seite empfiehlt Anweisungen, die konkret genug sind, um sie zu prüfen, also „Use 2-space indentation" statt „Format code properly". Ohne diese Datei erklärst du dein Vorhaben in jeder neuen Sitzung von vorne, und jedes Mal ein bisschen anders. Danach wunderst du dich, warum das Ergebnis wandert. Wie aus diesem einen Merkzettel später eine ganze Arbeitsumgebung wird, steht im Agent Dev Kit für Claude Code. Der Test: Lies die vier Zeilen laut. Wenn ein Fremder danach bauen könnte, ist der Zettel fertig.
Schritt 3 · Nur das Aussehen. Klickbar, ohne eine Zeile Funktion. Jetzt erst die erste Nachricht. Tipp in der Eingabezeile einen Schrägstrich /, es klappt eine Liste von Befehlen auf. Steht dort ein Design-Eintrag, nimm ihn. Das ist der Modus, der ausschließlich Oberflächen baut und die Funktion bewusst weglässt. Findest du ihn nicht, schreibst du die Regel selbst: „Bau mir nur die Oberfläche für [dein Satz aus Schritt 1]. Alle Knöpfe sichtbar und klickbar, aber ohne Wirkung. Keine Speicherung, keine Datenbank, keine Anmeldung. Eine einzige Seite. Danach stoppst du." Am Aussehen siehst du in zehn Sekunden, ob ihr über dasselbe Ding redet. An Funktionscode siehst du das erst, wenn er läuft, und bis er läuft sind zwanzig Minuten weg. Der Test: Die Seite öffnet sich im Browser und du erkennst dein Werkzeug wieder.
Schritt 4 · Durchklicken, bevor irgendein Code kommt. Klick jeden Knopf einmal an, lies jede Beschriftung, und alles, was dir jetzt auffällt, sagst du jetzt. Eine Änderung am Aussehen kostet hier eine Nachricht. Dieselbe Änderung kostet nach dem Code drei, weil dann auch die Funktion dahinter mitwandert. Das ist der Punkt, an dem die meisten Abende kippen. Der Test: Es gibt nichts mehr, was du ändern willst. Erst dann geht es weiter.
Schritt 5 · Der Code, in kleinen Stücken. Jetzt kommt die Funktion, und zwar eine pro Nachricht. Für den Selbsttest sind das drei: die Antworten zählen und ein Ergebnis daraus berechnen, das Feld für die Mailadresse anlegen und das Ergebnis erst danach zeigen, die Adresse dort ablegen, wo du sie brauchst. Nach jeder einzelnen Nachricht probierst du selbst genau die eine Sache aus, die gerade dazugekommen ist. Nicht das ganze Werkzeug, nur das neue Stück. Baust du drei Sachen auf einmal und danach geht etwas nicht, weißt du nicht welche, und dann fängst du an zu raten. Raten ist der teuerste Teil des Abends. Schlägt die Maschine von sich aus weitere Funktionen vor, sagst du Stopp und verweist auf den Merkzettel. Der Test: Das neue Stück tut, was du wolltest, und das alte tut es immer noch.
Schritt 6 · Rausstellen und aufschreiben. Sag: „Stell das Ganze so ins Netz, dass ich einen Link teilen kann, und sag mir jeden Schritt vorher an." Du bekommst eine Adresse, die du weitergeben kannst. Danach schreibst du drei Sätze in den Merkzettel: was gut lief, wo du hängst, was du beim nächsten Mal anders machst. Das erste Werkzeug dauert 25 Minuten. Das zweite dauert zehn, aber nur, wenn du die Reihenfolge aufgeschrieben hast statt sie dir zu merken. Denselben Ablauf an einem größeren Stück siehst du in Landingpage mit Claude Code bauen.
Was brauche ich, bevor ich anfange?
Drei Dinge. Einen Rechner, ein Claude-Konto und 25 Minuten, in denen dich niemand anspricht.
Claude Code ist kein Programm mit bunten Fenstern. Es läuft im Terminal, und Terminal heißt einfach: das Fenster, in das man Befehle tippt statt zu klicken. Auf dem Mac findest du es über die Lupe oben rechts, tipp dort Terminal ein. Auf Windows heißt es PowerShell. Installiert wird mit einer einzigen Zeile, auf Mac und Linux ist das curl -fsSL https://claude.ai/install.sh | bash. Die jeweils aktuelle Zeile, auch die für Windows, steht auf der Claude-Code-Seite. Kopier sie von dort, sie ändert sich gelegentlich.
Das Konto legst du unter claude.ai an. Der Link ist ein Empfehlungslink, ich bekomme dafür eine Provision. Der Weg über claude.ai ohne Empfehlung führt zum selben Konto. Danach legst du auf dem Schreibtisch einen leeren Ordner an, nennst ihn mein-erstes-tool, gehst im Terminal hinein und startest mit claude. Wenn du gar nicht aus der Technik kommst und dich das schon abschreckt: der ruhigere Einstieg steht in KI-Marketing ohne Code.
Warum liegen vier Schritte vor der ersten Zeile Code?
So haben sich die 25 Minuten bei mir am dritten Abend verteilt: 3 Minuten für den einen Satz, 4 für den Merkzettel, 6 für das Aussehen, 3 fürs Durchklicken, 7 für den Code in drei Stücken, 2 fürs Rausstellen und Aufschreiben. Fast zwei Drittel der Zeit vergehen, bevor die erste Zeile Code entsteht. Genau das ist die Reihenfolge.
Der Frust am anderen Weg ist inzwischen gemessen. Im Stack Overflow Developer Survey 2025 nannten 66 Prozent der 31.476 Antwortenden auf diese Frage „AI solutions that are almost right, but not quite" als Problem im Umgang mit KI-Werkzeugen, 45,2 Prozent nannten „Debugging AI-generated code is more time-consuming" (Stack Overflow Developer Survey 2025, AI-Sektion). Mehrfachnennungen waren erlaubt, und befragt wurden Entwicklerinnen und Entwickler, nicht Einsteiger. Für uns heißt das trotzdem etwas: fast richtig ist die teuerste Sorte Ergebnis. Man sucht den Fehler erst, wenn schon alles steht.
Was mache ich, wenn ich schon mittendrin stecke?
Du hast angefangen, es läuft halb, und du willst nicht alles wegwerfen. Musst du auch nicht. Du gehst rückwärts bis zum ersten leeren Schritt.
- 1.Schreib den Satz aus Schritt 1 jetzt auf. Zwei Minuten. Meistens merkst du dabei, dass du zwei verschiedene Werkzeuge gleichzeitig baust.
- 2.Leg den Merkzettel an und trag ein, was das Ding nicht können soll. Diese Zeile ist die wichtigste, weil dort alles steht, was in den letzten zwei Stunden dazugewuchert ist.
- 3.Öffne die Oberfläche und klick sie durch, als hättest du sie nie gesehen. Notier alles, was stört, bevor du irgendetwas anfasst.
- 4.Lass die Störungen einzeln beheben. Eine pro Nachricht.
- 5.Erst wenn die Oberfläche sitzt, geht es an der Funktion weiter.
Und wenn du merkst, dass du seit einer halben Stunde dieselbe Stelle im Kreis reparierst: neuer Ordner, Merkzettel hinein, von Schritt 3 an neu. Das dauert zwanzig Minuten. Weiterreparieren dauert den Rest des Abends.
Lohnt sich der Vorlauf, wenn ich doch einfach beschreiben kann, was ich will?
Der Einwand ist berechtigt, und er hat einen Namen. Die deutschsprachige Wikipedia definiert Vibe-Coding als „eine Art der Softwareentwicklung, bei der nahezu ausschließlich der Prompt eines großen Sprachmodells (LLM) bedient wird, um den für die Software erforderlichen Quellcode zu generieren". Der Artikel hält fest, dass Andrej Karpathy die Methode „besonders für ‚Wegwerf-Wochenendprojekte' geeignet" nannte, und führt als Risiko Code mit „unentdeckten Fehlern, Fehlfunktionen und Sicherheitslücken" an. Für ein Wochenendprojekt ist das in Ordnung. Für ein Werkzeug, dessen Link du einem Kunden schickst, nicht mehr.
Ähnlich nüchtern klingt es in der Fachpresse. In der Ankündigung zum Sonderheft c't KI-Wissen 2026 schreibt heise online: „Auch beim Programmieren reicht es nicht, einen KI-Agenten auf ein Projekt loszulassen und auf fertige Software zu hoffen." (heise online, Hartmut Gieselmann, 15.07.2026)
Der Punkt ist nicht, dass die Maschine zu schwach wäre. Sie ist stark genug, sofort loszubauen. Sie ist nur nicht in deinem Kopf. Alles, was du nicht sagst, füllt sie selbst auf. Bei einem Satz fällt das nicht auf. Bei fünfzig gebauten Dateien fällt es sehr auf, und dann steckt deine Entscheidung an dreißig Stellen fest. Die sechs Schritte schieben 16 Minuten vor die erste Zeile Code und sparen dir den kompletten dritten Anlauf.
Der zweite Einwand ist ehrlicher: „Ich kann nicht programmieren." Musst du nicht. Du musst nach jedem Schritt sagen können, ob das Ergebnis richtig ist. Das kannst du, es ist dein Werkzeug.
Diese Reihenfolge kommt aus unserer eigenen Werkstatt. Wir bauen damit die kleinen Helfer, die unseren Content am Laufen halten, aus dem 9.000 Leads im Monat kommen. Und wir geben sie an die 1151+ Mentis in der Academy weiter, weil dort jeder an derselben Stelle hängt. Nicht am Können, an der Reihenfolge.
Im PDF liegt dieselbe Reihenfolge als Blatt zum Ausdrucken: alle sechs Schritte mit voller Erklärung und einer Prüffrage je Schritt, die Minuten-Tabelle, wo die 25 Minuten hingehen, die Rückwärts-Reihenfolge für den halb fertigen Ordner und das leere Werkzeug-Blatt mit Feldern für deinen Satz, den Merkzettel, die drei Code-Stücke, den fertigen Link und die gebrauchte Zeit. Ein Blatt pro Werkzeug, gebrandet und druckfertig, oben über das Formular.