--- title: "Womit hier eigentlich gearbeitet wird" description: "Ein Editor, zwei Modellfamilien nebeneinander und eine Schicht aus Rezepten, Regeln und Schranken. Der Teil, über den am wenigsten geredet wird und der am meisten trägt." author: "Matthias Meyer" published: 2026-08-05 updated: 2026-08-05 language: de tags: ["maschinenraum", "arbeitsweise", "werkzeuge", "claude", "codex"] canonical: "https://studiomeyer.io/de/blog/arbeitssystem-editor-modelle-werkzeuge" markdown_versions: ["https://studiomeyer.io/de/blog/arbeitssystem-editor-modelle-werkzeuge.md", "https://studiomeyer.io/en/blog/arbeitssystem-editor-modelle-werkzeuge.md", "https://studiomeyer.io/es/blog/arbeitssystem-editor-modelle-werkzeuge.md"] publisher: "StudioMeyer, https://studiomeyer.io (llms.txt: https://studiomeyer.io/llms.txt)" --- # Womit hier eigentlich gearbeitet wird Über Modelle wird viel geredet. Über das Drumherum kaum. Dabei entscheidet in der täglichen Arbeit das Drumherum. Was hier beschrieben ist, ist kein Produkt und nichts, was wir verkaufen. Es ist die Antwort auf die Frage, die uns im Gespräch am häufigsten gestellt wird, und zwar von Leuten, die selbst mit KI arbeiten: Wie ist das bei euch eingerichtet. ## Der Editor ist die Bühne Gearbeitet wird in einem normalen Code-Editor, nicht in einem Chatfenster im Browser. Das ist der wichtigste einzelne Unterschied. Ein Chatfenster im Browser sieht nur, was man hineinkopiert. Ein Assistent im Editor sieht die Dateien, kann Befehle ausführen, Ergebnisse lesen und daraus den nächsten Schritt ableiten. Der Unterschied zwischen "erkläre mir, wie ich das ändere" und "ändere es, führ die Tests aus und zeig mir das Ergebnis" ist nicht Bequemlichkeit, sondern eine andere Art zu arbeiten. ## Zwei Modellfamilien, absichtlich Nebeneinander laufen Assistenten aus zwei verschiedenen Häusern. Das ist keine Unentschlossenheit, sondern der wirksamste Qualitätsgriff, den wir gefunden haben. Modelle derselben Familie machen ähnliche Fehler. Wenn der Erbauer und der Prüfer aus demselben Haus stammen, übersieht der Prüfer verlässlich genau das, was der Erbauer übersehen hat. Sie teilen die blinden Flecken. Lässt man ein Modell einer anderen Familie über dieselbe Arbeit laufen, mit dem ausdrücklichen Auftrag, sie zu widerlegen, kommen andere Funde. Nicht mehr Funde, andere. Das ist bei uns inzwischen der Standardweg bei allem, was nicht trivial ist: eins baut, ein zweites greift an, und zwar so lange, bis nichts Substanzielles mehr kommt. ## Rezepte statt wiederholtem Erklären Die zweite Schicht sind Rezepte für wiederkehrende Abläufe. Ein Deploy, ein Blogbeitrag, ein Kunden-Onboarding, ein Server-Check. Der Punkt daran ist nicht Automatisierung. Der Punkt ist, dass jedes dieser Rezepte die Fallen enthält, in die wir schon einmal getappt sind. Beim Veröffentlichen einer Seite zum Beispiel steht darin die Reihenfolge der Prüfungen, die vor dem Umschalten fällig sind. Solches Wissen verschwindet sonst. Es lebt im Kopf von jemandem, der an dem Tag nicht da ist. In einem Rezept steht es und wird beim nächsten Mal befolgt, auch von einem Assistenten, der die Geschichte dahinter nicht kennt. ## Schranken, die nicht höflich fragen Die dritte Schicht ist die, die uns am meisten Ärger erspart hat. Es sind harte Sperren, die bestimmte Aktionen technisch verhindern, statt sie zu missbilligen. Der Unterschied ist entscheidend. Eine Anweisung wie "benutze niemals dieses Werkzeug gegen einen Server" ist eine Bitte. Sie wirkt meistens und irgendwann eben nicht, weil sie in einer langen Sitzung unter viel anderem Text steht. Eine Schranke, die den Befehl abfängt und mit einer Begründung ablehnt, wirkt immer. Solche Schranken hängen an den Stellen mit dem größten Schaden: an allem, was einen Server überschreiben kann, an ausgehender Post, an löschenden Aktionen. Die Lehre dahinter ist allgemeiner als das Werkzeug: **Eine Regel ohne Durchsetzung ist eine Notiz.** Wenn dieselbe Sache zweimal passiert ist, ist der Text darüber widerlegt und es braucht einen Mechanismus. ## Und das Gedächtnis darunter Alles davon hängt an dem Gedächtnis, das an anderer Stelle in dieser Serie beschrieben ist. Es hält Entscheidungen, Fehler und Muster über Monate, und zwar sitzungsübergreifend. Der praktische Effekt: Ein Fehler, der einmal gemacht und festgehalten wurde, kommt beim nächsten passenden Anlass als Warnung zurück, ohne dass jemand daran denken muss. Das ist der Unterschied zwischen einem System, das lernt, und einem, das jeden Montag wieder bei null anfängt. ## Was davon übertragbar ist Wir bauen niemandem diesen Aufbau nach, das wäre auch albern. Aber drei Dinge daraus gelten unabhängig vom Werkzeug. Erstens: Der Assistent gehört dorthin, wo die Arbeit liegt, nicht daneben. Zweitens: Prüfen muss jemand anderes als bauen, und je unterschiedlicher, desto besser. Drittens: Was schon einmal schiefgegangen ist, braucht eine Schranke und keinen Merksatz. Der Rest ist Geschmack und Gewohnheit. ## Weiterlesen, Maschinenraum - [Der Maschinenraum: was bei uns selbst läuft](https://studiomeyer.io/de/blog/maschinenraum-was-wir-selbst-betreiben.md) - [Eine Agenten-Flotte, sortiert nach Aufgaben](https://studiomeyer.io/de/blog/agenten-flotte-wer-macht-was.md) - [Eine Lernplattform, die von Agenten betrieben wird](https://studiomeyer.io/de/blog/academy-von-agenten-betrieben.md)