ki-werkzeuge ki-konzepte coding-cli prompting

Die KI macht, was sie will — und keine CLAUDE.md, kein Memory, keine Regel der Welt hält sie auf

Redaktion · 1. Mai 2026 · 5 Min. Lesezeit

Mal ehrlich: Wer aktuell täglich mit KI-Modellen arbeitet, kennt das Gefühl. Man sitzt da, will einfach nur seinen Job machen — und das verdammte Modell macht schon wieder irgendeinen Scheiß, den man ihm absolut nicht gesagt hat. Wieder. Zum gefühlt fünfzigsten Mal. Und man fragt sich: Warum the fuck merkt sich dieses Programm nicht, was ich ihm seit Wochen erzähle?

Willkommen im Club. Genau dieses Gefühl ist der Grund, warum es BoostN gibt.

Du tust eigentlich alles richtig — und es bringt trotzdem nichts

Schauen wir uns mal an, was man als halbwegs disziplinierter Nutzer alles macht, um diesen Modellen Leitplanken zu geben:

Man schreibt eine CLAUDE.md. Sauber strukturiert, mit Zonen, Verboten, Erlaubtem, Workflow-Regeln.
Man pflegt User-Memory-Einträge — global wie projektweit.
Man legt Konventionen fest, dokumentiert Pfade, beschreibt explizit, was nicht angefasst werden darf.
Man wiederholt Anweisungen in jedem zweiten Prompt, weil man inzwischen weiß, dass es sonst untergeht.
Man baut sich eigene Skills, Hooks, Slash-Commands, nur damit das Modell sich an die einfachsten Dinge hält.

Und dann passiert Folgendes: Eine Woche läuft es. Manchmal zwei. Man denkt sich „okay, jetzt sitzt es endlich”. Und dann — ohne erkennbaren Auslöser — fängt das Modell wieder an, genau die Dinge zu tun, die zehnmal in der Memory stehen, dass es sie nicht tun soll. Es ignoriert die CLAUDE.md. Es vergisst, dass man die Datenbank ausschließlich über psql gegen aws-1-west ansprechen soll. Es baut Code, der gegen jede Konvention verstößt, die man je in den Kontext gepfeffert hat.

Und das Schlimmste: Man hat keine Möglichkeit, das System zu zwingen. Man kann nur hoffen, dass es beim nächsten Mal besser wird. Hoffen. Bei einem Werkzeug, für das man Geld bezahlt.

Das Grundproblem: Anweisungen sind Wünsche, keine Regeln

Hier liegt der Kern. Alles, was du in CLAUDE.md, in der Memory oder im Prompt schreibst, ist für das Modell ein Hinweis — kein Befehl. Das Modell wägt ab. Es interpretiert. Es vergisst. Es priorisiert um. Es hat Trainingseinflüsse, die manchmal stärker ziehen als deine drei Bullet-Points zur Code-Konvention.

Das ist keine böse Absicht — das liegt in der Architektur. Ein LLM ist kein deterministischer State Machine, der Regeln stur abarbeitet. Es ist ein Wahrscheinlichkeitsapparat, der bei jedem Token neu rät, was als nächstes „passend” wäre. Und manchmal verliert deine Regel diesen Wahrscheinlichkeitskampf.

Heißt im Klartext: Solange du dem Modell nur erzählst, was es tun soll, bleibt jedes Verhalten optional. Egal wie oft du es wiederholst. Egal wie groß deine Memory wird. Egal wie ausgefeilt deine CLAUDE.md.

Die unbequeme Wahrheit

Memories und Markdown-Regeln sind Empfehlungen, die das Modell jederzeit überstimmen kann. Wenn dein Workflow davon abhängt, dass eine Regel immer greift, ist Prompt-basierte Steuerung das falsche Werkzeug.

Was wirklich hilft: Verhalten erzwingen, nicht erbitten

Genau hier setzt BoostN an. Wir haben uns nicht hingesetzt und versucht, die hundertste „bessere CLAUDE.md-Vorlage” zu schreiben — das löst das Problem nicht. Wir haben einen anderen Weg gewählt:

Wir geben dem Modell die Anweisungen Schritt für Schritt — und verhindern jegliches Ausbrechen.

Statt am Anfang einer Session einen Berg an Regeln in den Kontext zu kippen und zu hoffen, dass das Modell sie über Stunden hinweg respektiert, läuft es bei uns über strukturierte Workflows. Jeder Schritt ist klar definiert. Das Modell bekommt genau das, was es im Moment braucht — nicht mehr, nicht weniger. Und wenn es versucht, links oder rechts auszubrechen, fängt der Workflow das ab, bevor der Schaden passiert.

Konkret heißt das:

Determinierte Schritte statt freier Interpretation — das Modell entscheidet nicht mehr selbst, in welcher Reihenfolge es deine Anweisungen abarbeitet.
Kontext zur richtigen Zeit, nicht alles auf einmal — Memory-Overload verschwindet, weil der Workflow nur das nachschiebt, was im aktuellen Schritt relevant ist.
Harte Leitplanken statt Bitten — bestimmte Aktionen sind im Workflow schlicht nicht möglich, statt dass sie über einen Memory-Eintrag „verboten” wären.
Wiederholbarkeit über Sessions hinweg — dieselbe Eingabe führt morgen zum gleichen Ergebnis wie heute. Kein „heute ist das Modell wieder so drauf”-Roulette.

Warum das anders ist als „noch eine bessere Memory schreiben”

Ein häufiger Reflex: „Dann muss ich meine Memory halt noch detaillierter machen.” Funktioniert nicht. Wir haben das selbst durch. Je länger und detaillierter die Memory wird, desto mehr Tokens frisst sie — und desto wahrscheinlicher wird, dass das Modell selektiv liest. Mehr Regeln führen nicht zu mehr Compliance. Sie führen zu mehr Rauschen.

Der einzige Weg, der nachhaltig funktioniert, ist: die Steuerung aus dem Prompt rausziehen und in die Workflow-Schicht packen. Nicht dem Modell sagen, was es tun soll, sondern den Rahmen so bauen, dass das, was es tun soll, der einzige Weg ist, der überhaupt offensteht.

Genau das macht BoostN. Genau dafür gibt es uns.

Wenn du das auch satt hast

Wenn du das Gefühl kennst, dem Modell ständig dieselben Dinge eintrichtern zu müssen — und es trotzdem nichts bringt — schau dir an, wie wir das gelöst haben:

→ BoostN Features entdecken — KIDOKU + Workflows

Fazit

Du machst nichts falsch. Deine CLAUDE.md ist nicht das Problem. Deine Memory ist nicht das Problem. Das Problem ist, dass diese Werkzeuge gar nicht dafür gebaut sind, das Verhalten eines Modells zu erzwingen — sie können es nur beeinflussen. Solange das so bleibt, wirst du jede Woche aufs Neue dieselben Diskussionen mit demselben Modell führen.

Wer aus dem Loop raus will, muss die Steuerungsebene wechseln. Nicht mehr besser bitten — sondern den Spielraum kontrollieren. Genau dafür haben wir BoostN gebaut.

Entdecke mehr

Blog

Themenuebersicht

KI-Werkzeuge Coding-CLI KI-Konzepte Prompting