Warum KI-Tools frustrieren: eine praktische Lernkarte
MarkdownVier Lernbezeichnungen als Metapher des Autors, praktische Hinweise zum Arbeitsablauf und ein Drei-Säulen-Versuch für Fortschritt an einem KI-gestützten Projekt.
Vollständigen Artikel lesen
Das Wichtigste
Dieser Artikel nutzt eine populäre vierteilige Lernkurve als Metapher des Autors für die Arbeit mit Claude Code oder Cursor. Anfangsbegeisterung kann Frustration, bewussterer Übung und einem stabileren Ablauf weichen. Die Bezeichnungen helfen bei Reflexion. Sie sind weder eine bestätigte allgemeine Reihenfolge noch Abbruchprognose oder diagnostischer Test. Checklisten und Drei-Säulen-Modell sind praktische Vorschläge für einen Versuch an einem Projekt.
Weitere Anleitungen zur Arbeit mit Ailoot findest du in der Dokumentation.
Eine Lernmetapher statt eines allgemeinen psychologischen Gesetzes
Der Dunning-Kruger-Effekt betrifft Grenzen der Einschätzung eigener Leistungen. Das vertraute Bild von Gipfel, Tal, Anstieg und Plateau ist eine populäre Darstellung, kein Beleg, dass jeder Lernende vier Phasen in dieser Reihenfolge durchlaufen muss. Hier ordnet es lediglich Beispiele zu Erwartungen, Frustration und Übung.
Die praktische Frage dieses Artikels ist enger als eine psychologische Diagnose: Passen deine Erwartungen zu Ergebnissen, die du prüfen kannst? Vergleiche erwarteten Abschluss und tatsächlich funktionierendes Ergebnis und passe daraus die nächste Aufgabe an.
Miss Können nicht allein am Selbstvertrauen. Prüfe ein echtes Ergebnis und die zugrunde liegenden Kontrollen.
Die Kurve ist hier eine Metapher. Es gibt keine Untersuchung dieser Leserschaft, die eine Abbruchquote, feste Lerndauer oder allgemeine Reihenfolge dieser Bezeichnungen belegt.
Die 4 Phasen des Vibe-Codings – Wo stehst du gerade?
Das Wichtigste
Die folgenden vier Bezeichnungen beschreiben mögliche wiedererkennbare Situationen, keine von allen Claude-Code-Nutzern zu durchlaufenden Phasen. Der Gipfel des Mount Stupid: Du liest einen Artikel über Agents und denkst, du seist ein Vibe-Coder. Das Tal der Verzweiflung: Du beschäftigst dich mit MCP und Skills und erkennst, dass du nichts verstanden hast. Der Pfad der Erleuchtung: Die Regeln funktionieren und die Methodik liefert Ergebnisse. Das Plateau der Nachhaltigkeit: Dein Wissen entspricht deinem Selbstvertrauen, und du entwickelst stetig Produkte. Jede Phase hat ihre eigenen Gedanken und ihr eigenes sichtbares Verhalten.
Jede Phase lässt sich an typischen Gedanken und Verhaltensweisen erkennen. Hier ist die Übersicht.
Phase 1 – Gipfel des Mount Stupid
Du liest einen Artikel über Claude Code. Vielleicht hast du ein Video gesehen. Alles scheint klar: Tool installieren, Prompt schreiben, Code bekommen. Die Autoren der Artikel erzählen, wie sie „in einem Abend ein SaaS gebaut haben“. Das willst du auch an einem Abend schaffen.
Gedanken im Kopf:
- „Ich glaube, ich hab’s verstanden.“
- „Das ist doch nur ein Chat, bloß schlauer.“
- „Ich bin Unternehmer; Programmierer brauche ich nicht.“
- „In einem Monat beherrsche ich das und fliege nach Dubai.“
Verhalten:
- Du lädst Claude Code herunter und installierst es.
- Du tippst „Build me a booking app“ in den Chat.
- Du erhältst Code, der nicht läuft.
- Du denkst, das falsche Modell sei schuld, und kaufst ein Max-Abo.
In dieser Phase überschätzt du sowohl das Tool als auch dich selbst. Das ist ein möglicher Einstieg. Bleiben Erwartungen vom funktionierenden Ergebnis getrennt, kann Frustration wachsen. Ein kleines Projekt mit ausdrücklichen Prüfungen schafft eine konkrete Lerngrundlage.
Bitte als praktische Selbstprüfung jemand anderen, dieselbe Ausgabe anhand ausdrücklicher Kriterien zu betrachten. Eine selbstbewusste Bezeichnung wie „KI-Experte“ belegt keine Qualität eines generierten Ergebnisses.
Behandle einen frühen selbstbewussten Eindruck als Hypothese. Führe Code aus, prüfe die Ausgabe und lass das Ergebnis deine Einschätzung dessen verändern, was du tatsächlich schaffst.
Phase 2 – Tal der Verzweiflung
Du steigst tiefer ein. Du liest über MCP und versuchst, einen Server anzubinden. Du lädst einen fertigen Skill herunter und versuchst, ihn zu verstehen. Du startest den Plan Mode – der Agent schreibt einen Plan und kommt dann bei Schritt drei vom Kurs ab. Du öffnest ~/.claude/ – dort sind 12 Ordner, und du verstehst nicht, wozu auch nur einer davon dient.
Gedanken im Kopf:
- „Ich weiß überhaupt nicht, wie man etwas macht.“
- „Alle in den sozialen Medien lügen doch nur.“
- „Was bei anderen funktioniert, klappt bei mir nicht.“
- „Vielleicht bin ich zu früh eingestiegen.“
- „Ich habe 200 $ für Tokens ausgegeben – und was kann ich vorweisen?“
Verhalten:
- Du öffnest gleichzeitig 20 Tabs mit Dokumentation.
- Jeder Chat beginnt mit „Vergiss den vorherigen Kontext.“
- Du durchstöberst Foren und liest Threads wie „X hat mein Projekt kaputt gemacht“.
- Du vergleichst Claude mit Cursor, Cursor mit Codex, Codex mit Cline. Du denkst, du hättest das falsche Tool.
- Du setzt dich morgens zum Programmieren hin, aber zur Mittagszeit scrollst du schon durch deinen Feed.
Das kann frustrierend sein. Der Artikel hat dafür keine gemessene Abbruchquote. Nutze die folgenden Anzeichen, um eine konkrete Änderung auszuprobieren.
Phase 3 – Pfad der Erleuchtung
Du hältst inne. Du gehst es langsamer an. Du stürzt dich nicht mehr auf jede Neuigkeit. Du schreibst deine erste CLAUDE.md und legst sie im Projekt ab. Du erstellst einen Ordner business/ und legst dort eine Beschreibung des Produkts, der Preise und der Zielgruppe ab. Du verwendest /compact zehnmal und verstehst schließlich, welche Kontextteile erhalten bleiben sollen. Du erstellst deinen ersten Skill – für eine konkrete Aufgabe, 30 Zeilen lang.
Gedanken im Kopf:
- „Ach, so funktioniert das.“
- „Heute habe ich etwas geschafft, das ich vor einer Woche noch nicht konnte.“
- „Ich glaube, ich verstehe, wie sich
business/vonai-clone/unterscheidet.“ - „Für Aufgabe X habe ich schon einen fertigen Prompt.“
Verhalten:
- Vor jeder neuen Aufgabe kehrst du zum Plan Mode zurück.
- Bevor du etwas an Claude schreibst, fragst du dich: „Steht das in meiner CLAUDE.md?“
- Du suchst nach der nächsten methodischen Regel; ein neues Tool zieht deine Aufmerksamkeit nicht mehr auf sich.
- Du hilfst anderen in Chats: „Daran bin ich auch hängen geblieben – probier es mal so.“
Phase 4 – Plateau der Nachhaltigkeit
Das ist nicht der Punkt, an dem alles einfach wird. Es ist der Punkt, an dem dein Wissen endlich deinem Selbstvertrauen entspricht.
Gedanken im Kopf:
- „Ich weiß, was ich nicht weiß.“
- „Diese Aufgabe dauert drei Stunden; ich habe sie schon einmal erledigt.“
- „Dafür brauche ich einen neuen Skill; den stelle ich jetzt zusammen.“
- „Wenn Claude vom Plan abweicht, kenne ich drei mögliche Gründe.“
Verhalten:
- Du entwickelst stetig Produkte – eines an einem Abend, ein anderes am Wochenende.
- Du hast deinen eigenen Skills-Ordner, eigene Subagents und für jedes Projekt einen eigenen
business/-Ordner. - Du beauftragst gezielt externe Kräfte – für Teile, die du grundsätzlich nicht selbst bewältigen kannst.
- Du schaust dir nur selten Video-Tutorials anderer an – meist, um neue Ideen zu bekommen, nicht um die Grundlagen zu lernen.
Checkliste zur Selbsteinschätzung – In welcher Phase bist du jetzt?
- Wenn du Claude Code noch nicht ausprobiert hast und denkst: „Oh, das schaffe ich an einem Abend“, bist du in Phase 1.
- Wenn du es ausprobiert, MCP geöffnet, Skills zu lesen versucht hast und denkst: „Warum habe ich damit angefangen?“, bist du in Phase 2.
- Wenn du eine CLAUDE.md erstellt hast und erkennen kannst, wie sie Claudes Verhalten tatsächlich verändert, bist du in Phase 3.
- Wenn du stetig Produkte entwickelst und genau weißt, welches Tool du wann einsetzen musst, bist du in Phase 4.
7 Anzeichen dafür, dass du gerade im Tal der Verzweiflung steckst
Das Wichtigste
Das Tal der Verzweiflung lässt sich an sieben Verhaltensweisen erkennen – vom endlosen Wechsel zwischen Tools bis zum Satz „Das ist einfach nichts für mich“. Nutze die sieben Anzeichen zur Reflexion statt als bewertete Diagnose. Wähle dasjenige, das den Abschluss deiner aktuellen Aufgabe am stärksten stört, und teste eine passende Änderung.
Das Tal kommt nicht plötzlich. Es schleicht sich an. Hier sind die Anzeichen:
1. Du vergleichst Tools, statt etwas zu entwickeln. Du öffnest einen Tab mit „Cursor vs Claude Code“. Du liest den Artikel zu Ende. Dann öffnest du „Cline vs Cursor“. Danach „Codex vs. alles andere“. Mit jedem Vergleich denkst du: „Vielleicht grabe ich an der falschen Stelle.“ Am Ende des Tages hast du keine einzige Codezeile geschrieben und vier Stunden verbraucht.
2. Du beginnst jeden neuen Chat mit „Vergiss alles, was vorher war“. Du hast keine CLAUDE.md, beherrschst /compact nicht und verstehst nicht, was ein Kontextfenster ist. Jede Sitzung beginnt bei null. Eine Woche später wirst du feststellen, dass du Claude zum fünfzehnten Mal dasselbe erklärt hast.
3. Du sammelst Prompts, verwendest sie aber nicht. Du hast in Notion einen Ordner „Claude-Code-Prompts“ angelegt. Darin sind 47 Lesezeichen. Keines davon hast du zweimal benutzt. Jedes Mal denkst du: „Genau das brauche ich.“
4. Du denkst, andere „haben Erfolg, weil sie Beziehungen haben“. Du öffnest die sozialen Medien und siehst, wie jemand an einem Wochenende die erste Version eines Produkts bereitstellt. Du denkst: „Die haben ein Team. Die haben Beziehungen. Ich schaffe das nicht.“ Du berücksichtigst nicht, dass sie in Phase vier sind, während du in Phase zwei bist.
5. Du brichst ein Projekt am dritten Tag ab. Jedes neue Projekt beginnt mit Begeisterung („Das wird großartig!“) und endet am dritten Tag. Wenn die Herausforderung von „eine Begrüßung im Chat“ zu „eine Zahlung verarbeiten“ wächst, steigst du aus. Etwas Schwieriges zu tun, macht Angst.
6. Du suchst in ChatGPT nach Antworten, weil es mit Claude nicht geklappt hat. Claude gab dir eine schlechte Antwort, also öffnest du ChatGPT. ChatGPT gab dir eine schlechte Antwort, also öffnest du Gemini. Dir kommt nicht in den Sinn, dass die Anfrage schlecht formuliert war – du gibst immer dem Tool die Schuld.
7. Du sagst dir: „Das ist einfach nichts für mich.“ Das ist das heimtückischste Anzeichen. Es klingt wie ein abschließender Abwehrsatz, nach dem die Person geht. Dieser Gedanke kann Frustration statt fehlender Lernfähigkeit ausdrücken. Das „Tal“ ist hier eine Metapher. Es gibt weder gemessenen Anteil noch festen Zeitraum dafür, wer so empfindet und wie es weitergeht.
Passen mehrere Anzeichen, wähle ein kleines funktionierendes Ergebnis als nächstes Ziel. Erfasse die konkrete Blockade und ändere einen Teil des Ablaufs. Die Checkliste sagt keine Verbesserungsdauer voraus.
Warum Menschen im Tal aufgeben – und warum das keine Faulheit ist
Das Wichtigste
Das Tal bezeichnet in dieser Metapher die Lücke zwischen erwartetem und tatsächlichem Fortschritt. Eine vermeintlich schnelle Aufgabe kann unbekannte Einrichtung und Fehlersuche erfordern; soziale Medien können den Vergleich entmutigend machen. Das beschreibt praktische Frustration, keine neurologische Diagnose.
Frustration mit einem Tool ist kein verlässliches Maß der Fähigkeit. Prüfe Aufgabengröße, fehlendes Wissen und Ausführungsumgebung vor einer dauerhaften Entscheidung über das Tool.
Leite aus einer schwierigen Woche keinen Gehirnmechanismus ab. Erfasse beobachtbare Fakten: versuchte Aufgabe, funktionierende Teile, konkreter Fehler des nächsten Schritts und benötigte Zeit. Das schafft einen bestimmten Ansatzpunkt zur Verbesserung.
Im Tal triffst du gleich zwei Rückschläge. Erstens entspricht dein eigener Fortschritt nicht deinen Erwartungen. Zweitens veröffentlichen die Menschen um dich herum Ergebnisse, die du nicht vorweisen kannst. Du öffnest die sozialen Medien – jemand hat die erste Produktversion bereitgestellt, jemand einen Agent entwickelt, jemand seine ersten hundert Dollar mit der Claude API verdient. Du hast drei Wochen damit verbracht, es nicht einmal zu schaffen, eine Datenbank anzubinden.
Erfasse Dauer und subjektives Tempoempfinden getrennt. Ein Agent kann produktiv wirken und zugleich Prüf- und Nacharbeit verursachen. Vergleiche eine repräsentative Aufgabe mit deinem bisherigen Vorgehen statt gefühlten Gewinn als gemessenen zu behandeln.
Langsamer Fortschritt bei unbekannten Aufgaben belegt keine fehlende Fähigkeit. Trenne Lernaufwand von Toolausgabe und definiere ein kleineres prüfbares Ergebnis.
Ohne wiederholbaren nächsten Schritt wechselt man leicht das Tool oder gibt die Aufgabe auf. Das folgende Drei-Säulen-Modell ist der Strukturvorschlag des Autors, keine statistisch bewiesene Erklärung für Abbrüche.
3 Säulen – Eine Methodik, um aus dem Tal herauszukommen
Das Wichtigste
Als Strukturversuch schlägt der Autor drei Säulen vor: KI-Klon mit Skills und persönlicher Methodik, zweites Gehirn mit CLAUDE.md und business/ sowie Kontext-Engineering mit Plan Mode und Kontextverwaltung. Gemeinsam können sie Abläufe leichter prüfbar und wiederholbar machen. Sie beseitigen keine Halluzinationen und ersetzen keine Ergebnisprüfung.
Nach der hier beschriebenen Erfahrung des Autors dauerte es drei Monate, aus dem Tal herauszukommen: In dieser Zeit wurden Dutzende Tools ausprobiert. Und ich habe eine Sache verstanden: Claude war nicht das Problem. Das Problem war, dass ich jedes Mal bei null anfing. Kein Gedächtnis, keine Regeln, keine Grenzen.
Danach stellte ich ein Framework zusammen. Ich nannte es „die drei Säulen“. Der Name bezieht sich auf drei Arten von Komponenten, auf denen der gesamte Claude-Code-Workflow beruht. Nimmt man eine davon weg, bricht das Framework zusammen.
Säule 1 – Ein KI-Klon von dir
Ein KI-Klon ist dein Fachwissen in einem Format, das Claude automatisch anwendet.
Im Tal der Verzweiflung schreibst du Claude: „Hilf mir bei dieser Aufgabe“, und erklärst jedes Mal von vorn, wie du vorgehst. Säule 1 löst dieses Problem: Deine Methoden liegen als Sammlung von Dateien im Ordner ai-clone/. Ein Skill für „wie ich einen Kundenfall bearbeite“. Ein Skill für „wie ich einen Telegram-Beitrag schreibe“. Ein Subagent namens „Produktarchitekt“, der in der Planungsphase wie du denkt.
So sieht Säule 1 in der Praxis aus:
- Skills – Dateien mit Anleitungen für bestimmte Aufgaben (
/build-article,/build-reel-script). - Subagents – Personas mit unterschiedlichen Fachgebieten, an die Claude Teilaufgaben delegiert.
- Der Ordner
ai-clone/feedback/– Regeln, die aus Fehlern gelernt wurden. Jede Regel folgt dem Format Regel – Warum – Wie.
Ausführlich habe ich das im Leitfaden zu Skills, Subagents, MCP und Plugins behandelt – einer Übersicht, was wann zum Einsatz kommt.
Säule 2 – Ein zweites Gehirn
Ein zweites Gehirn ist ein strukturiertes Wissensarchiv über ein Projekt, auf das Claude direkt zugreifen kann.
Im Tal der Verzweiflung erklärst du Claude in jeder Sitzung, was das Produkt ist, wer die Zielgruppe ist und wie das Geschäftsmodell aussieht. Am Ende der dritten Woche merkst du, dass du zum fünfzehnten Mal dasselbe erklärt hast. Säule 2 löst dieses Problem: Du organisierst dein Projektwissen in Dateien neben dem Code. Claude liest sie bei Bedarf selbst.
So sieht Säule 2 in der Praxis aus:
CLAUDE.md– der Einstiegspunkt für den Agent. Verhaltensregeln, Pfade und Links zu allem anderen.- Der Ordner
business/– Produkt, Zielgruppe, Wirtschaftlichkeit, Ziele, Inhaltspläne, Wettbewerber. - Der Ordner
plans/– technische Pläne nach Phasen und mit dem Status der einzelnen Phasen. - Der Ordner
retrospectives/– Erkenntnisse aus früheren Sitzungen, damit sich dieselben Fehler nicht wiederholen.
Die vollständige Übersicht findest du im Leitfaden zum Einrichten von CLAUDE.md und im Leitfaden zum zweiten Gehirn in Claude Code.
Säule 3 – Kontext-Engineering
Kontext-Engineering bedeutet, zu verwalten, was in Claudes Kontextfenster gelangt, bevor du auf Enter drückst.
Im Tal der Verzweiflung verstehst du nicht, warum Claude nach vierzig Nachrichten in einem Chat Anweisungen „vergisst“. Du verstehst nicht, wozu /compact nötig ist. Du öffnest den Plan Mode nicht, weil es „ohne schneller geht“. Säule 3 löst dieses Problem: Du steuerst bewusst, was du in den Kontext lädst. Das liefert relevantere Eingaben. Aussagen und Ausgaben musst du weiterhin prüfen.
So sieht Säule 3 in der Praxis aus:
- Plan Mode – der Agent schreibt zunächst einen Aufgabenplan, du stimmst ihm zu, dann führt er ihn aus. Wenn du ihn nicht verwendest, ist dein erster Versuch chaotisch.
/compact– intelligente Komprimierung des Chatverlaufs. Wenn sich der Kontext füllt, komprimiere ihn und behalte nur die wichtigsten Entscheidungen.- Strukturierte Prompts – statt „Hilf mir“ schreibst du: „Hier ist Kontext A, hier ist Aufgabe B, gib das Ergebnis im Format C zurück.“
- Subagents – Teilaufgaben werden an neue Kontexte delegiert, damit der Hauptkontext nicht überlastet wird.
Ich habe das im Leitfaden zu Kontext-Engineering und im Leitfaden zum Plan Mode behandelt.
Warum drei und nicht eine
Du kannst nur ein zweites Gehirn aufbauen, dann kennt Claude dein Projekt. Aber ohne Regeln verhält er sich wie ein Praktikant.
Du kannst nur einen KI-Klon aufbauen, dann übernimmt Claude dein Fachwissen. Doch ohne Projektgedächtnis beginnt jede Sitzung von vorn.
Kontext-Engineering kann Aufgabeneingaben verbessern, garantiert aber keinen reibungslosen Lauf und bewahrt allein kein Wissen. Doch Wissen sammelt sich nicht zwischen den Aufgaben an.
Erst wenn alle drei zusammenkommen, erhältst du das, was ich ein „planbares Framework“ nenne. Claude erinnert sich an dein Projekt. Er wendet deine Methodik automatisch an. Und innerhalb einer Aufgabe verliert er nicht den Faden.
Dann kommst du aus dem Tal der Verzweiflung heraus.
7 Fehlmuster, die dich im Tal festhalten
Das Wichtigste
Die folgenden Muster sind Reflexionsbeispiele des Autors für frustrierende Abläufe: Arbeit ohne CLAUDE.md, lange Gespräche ohne /compact, Vertrauen in die erste Antwort und fehlende Kostenkontrolle. Wähle eine passende Änderung und prüfe ihren Nutzen am Abschluss einer echten Aufgabe. Einen validierten Bestehenswert dieser Liste gibt es nicht.
Fehlmuster zur Prüfung deines eigenen Ablaufs:
1. „Schreib mir eine funktionierende App“ ohne CLAUDE.md. Du öffnest einen frischen Claude-Code-Chat und diktierst sofort die Aufgabe. Claude kennt weder den Kontext deines Projekts noch deine Methodik oder Vorlieben. Er gibt dir eine allgemeine Vorlage, und du bist enttäuscht.
Was du tun solltest: Erstelle eine CLAUDE.md und schreibe das Nötigste hinein – deinen Stack, dein Geschäftsmodell, deine Zielgruppe und Links zu den anderen Dateien. Jeder Chat beginnt mit diesem Kontext.
2. Ein langes Gespräch ohne /compact. Du führst eine Sitzung mit 80 Nachrichten. Claude erinnert sich nicht mehr daran, was ihr in Nachricht 12 beschlossen habt. Das Kontextfenster ist mit einem Verlauf voll, der keine wichtigen Entscheidungen enthält – nur Unentschlossenheit. Die Qualität der Antworten sinkt.
Was du tun solltest: Rufe alle 30–40 Nachrichten /compact auf und gib an, was wichtig ist und erhalten bleiben soll. Der Kontext wird fokussierter.
3. Der ersten Antwort vertrauen. Claude gibt dir eine Lösung, und du setzt sie sofort um. Eine Stunde später stellst du fest, dass sie drei andere Dateien beschädigt hat. Du gibst auf, weil „es schon wieder nicht richtig funktioniert“.
Was du tun solltest: Verwende den Plan Mode für komplexe Aufgaben. Zuerst der Plan, dann besprecht ihr den Plan, dann wird er ausgeführt. So erkennst du Fehler während der Planung statt nach einem halben Arbeitstag.
4. Ein schlampiger Prompt ohne Struktur. Du schreibst „Mach es gut“ und erwartest, dass Claude es selbst versteht. Das tut er nicht. Er weiß nicht, was „gut“ für dich bedeutet. Er rät.
Was du tun solltest: Schreibe Prompts nach der Struktur „Kontext – Aufgabe – Einschränkungen – Format“. So steigen die Chancen auf ein gutes Ergebnis beim ersten Versuch deutlich.
5. Kostenkontrolle ignorieren. Du weißt nicht, wie viele Tokens du verbrauchst. Dein Monatskontingent ist aufgebraucht, du öffnest das Dashboard und siehst, dass du 200 $ ausgegeben hast. Du bist überrascht. Du hörst auf.
Was du tun solltest: Richte Tracker für den Tokenverbrauch ein. Die Tools habe ich im Leitfaden zu Token-Trackern besprochen. Wenn du deine Ausgaben in Echtzeit siehst, verbrennst du nicht mehr sinnlos Tokens.
6. Die endlose Suche nach dem „richtigen Tool“. Cursor kommt heraus – du wechselst zu Cursor. Cline erscheint – du probierst Cline. Codex wird aktualisiert – du kehrst zu Codex zurück. Alle zwei Wochen nutzt du ein neues Tool und fängst jedes Mal von vorn an. Du erreichst nie das Niveau, auf dem das Tool für dich zu arbeiten beginnt.
Was du tun solltest: Wähle ein Tool. Nutze es drei Monate lang. Wechsle nicht bei der ersten Gelegenheit. Vergleiche schaue ich mir nur an, wenn mein Tool etwas grundsätzlich nicht kann.
7. „Keine Zeit, die Methodik zu lesen.“ Du denkst, das Tool sollte ohne Vorbereitung funktionieren. Prompts zu schreiben sei eine angeborene Fähigkeit. CLAUDE.md sei „eine zusätzliche Ebene“. Deshalb machst du auch im zweiten Monat noch Dinge, die du mit einer Methodik in einer Woche hättest erledigen können.
Was du tun solltest: Akzeptiere, dass Claude Code gelernt werden muss, wie jedes professionelle Tool. Du lernst es durch Methodik; Intuition funktioniert hier nicht.
Dazu passend: Der Leitfaden zu Schmeichelei in Claude Code untersucht, wie du das größte Missverständnis im Tal vermeidest – dass Claude immer recht hat, wenn er deiner Idee zustimmt.
5 Anzeichen dafür, dass du auf dem Pfad der Erleuchtung bist – So erkennst du, dass du es herausgeschafft hast
Das Wichtigste
Du erkennst den Pfad der Erleuchtung an einigen gelassenen Veränderungen, nicht an Euphorie. Du hast eine CLAUDE.md mit mehr als 200 Zeilen. Du kehrst ohne Erinnerung zum Plan Mode zurück. Du kennst deine Skills auswendig. Dein Arbeitstempo hat sich stabilisiert – du weißt jetzt, wie lange eine typische Aufgabe dauert. Und andere bitten dich um Hilfe, weil du Ergebnisse erzielst.
Fünf Anzeichen dafür, dass du in Phase drei bist:
1. Du hast eine CLAUDE.md mit mehr als 200 Zeilen und pflegst sie bewusst. Du hast sie nicht aus einer Vorlage kopiert, sondern selbst aufgebaut. Du kennst jeden Abschnitt und weißt, warum er dort steht. Wenn du ein neues Muster erkennst, fügst du eine Regel hinzu.
2. Vor jeder nicht routinemäßigen Aufgabe schaltest du den Plan Mode ein. Ohne Erinnerung und nicht aus Disziplin, sondern weil du verstehst, dass du ohne Plan eine Stunde vergeudest und das falsche Ergebnis erhältst. Es ist kein „zusätzlicher Schritt“ mehr, sondern ein Reflex.
3. Du hast deinen eigenen Katalog an Skills und Subagents. Nicht von GitHub heruntergeladen, sondern selbst erstellt. Für deine konkreten Aufgaben. Wenn eine neue Aufgabe einer früheren ähnelt, fällt dir dein Skill ein, statt dass du einen Prompt von Grund auf schreibst.
4. Dein Tempo hat sich stabilisiert. Du weißt jetzt: „Eine solche Aufgabe dauert bei mir 3 Stunden.“ Nicht „Oh, das geht schnell“ und nicht „Oh, das dauert ewig“. Du hast eine realistische Zeitschätzung. Das bedeutet, dass du den Dunning-Kruger-Effekt in beide Richtungen überwunden hast – du über- und unterschätzt dich nicht mehr.
5. Andere fragen dich um Rat. Jemand stellt in einem Chat eine Frage zu MCP, und du antwortest mit einem konkreten Beispiel: „Das ist mir passiert.“ Jemand fragt nach dem Plan Mode, und du zeigst dein Beispiel. Das ist eine Begleiterscheinung, wenn man die Methodik beherrscht: Menschen im Tal erkennen ihre eigene Erfahrung in deiner wieder und wenden sich an dich.
Nutze diese Anzeichen zur Reflexion jüngster Fortschritte statt als Punktzahl oder Zeitprognose. Prüfe wiederholt, ob deine Schätzungen und funktionierenden Ergebnisse mit der Zeit besser übereinstimmen.
Auf dem Plateau verändert sich die Rolle des Menschen in einem Framework mit Agents.
Das ist das Ergebnis der Reise aus dem Tal: Du „lernst nicht mehr, Prompts zu schreiben“. Du verwaltest ein Framework aus Agents, bist der Prozessarchitekt und stehst an der Spitze.
Was du JETZT tun kannst, wenn du den Mut verlierst
Das Wichtigste
Wenn du diesen Artikel gelesen und erkannt hast, dass du im Tal feststeckst, schließe den Tab nicht. Unternimm drei Schritte: Benenne deine Phase laut (Diagnose), geh es langsamer an (ein Projekt, zunächst eine Säule) und sorge für Struktur (deine eigene oder die einer anderen Person). Teste einen strukturierten Ablauf, bevor du die Lösung in einem neuen Tool suchst. Behalte ihn nur bei verbesserten Ergebnissen. Weder Metapher noch Zeitplan garantieren Fortschritt.
Drei Schritte für einen Versuch an deiner nächsten Aufgabe.
Schritt 1 – Benenne die Phase laut. Sag dir: „Ich bin im Tal der Verzweiflung. Das ist ein frustrierender Teil meines aktuellen Ablaufs. Ich kann die konkrete Blockade benennen und einen kleineren nächsten Schritt wählen.“ Sobald du die Phase benennst, ist es nicht mehr „meine persönliche Katastrophe“, sondern „meine aktuelle Position auf der Kurve“.
Schritt 2 – Geh es langsamer an. Wähle EIN Projekt. Nicht zwei, nicht drei – eins. Wähle EINE der drei Säulen – diejenige, die bei diesem Projekt die meisten Probleme löst. Ist das Projekt neu und hat überhaupt keinen Kontext, wähle das zweite Gehirn (CLAUDE.md). Existiert das Projekt bereits, aber Claude verhält sich nicht „wie du“, wähle den KI-Klon (Skills). Sind die Aufgaben lang und füllt sich der Kontext, wähle Kontext-Engineering (Plan Mode + /compact).
Ein Projekt, eine Säule, zwei Wochen. Versuche nicht, an einem Wochenende alles aufzubauen – das führt dich zurück ins Tal.
Schritt 3 – Sorge für Struktur. Du kannst die Methodik selbst entwickeln. Nach der hier beschriebenen Erfahrung des Autors dauerte das drei bis sechs Monate.
Quellen
- Anthropic Engineering, wirksames Kontext-Engineering für KI-Agents (2025) – warum das Kontextfenster an Qualität verliert und verwaltet werden muss.
- Claude Code Documentation - Memory – die offizielle Claude-Code-Speicherhierarchie.
Um weiter mit Modellen zu arbeiten, kannst du zu Ailoot gehen.
Weitere Details
Fragen und Antworten
Sagen die vier Phasen voraus, dass ich nach einem Monat aufgebe?
Nein. Der Artikel nutzt eine populäre Kurve als Metapher ohne gemessene Abbruchquote oder allgemeine Zeitachse. Nutze Beispiele zum Finden konkreter Hindernisse statt zur Selbstdiagnose oder Vorhersage des Lernfortschritts.
Was hilft als nächster Versuch bei ständigem Wechsel zwischen KI-Tools?
Wähle ein Projekt und ein kleines prüfbares Ergebnis. Verbessere den störendsten Teil: Projektanweisungen, wiederverwendbares Verfahren oder Kontextverwaltung. Vergleiche tatsächliches Ergebnis und Zeit mit dem vorherigen Versuch.