--- 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-09-30 updates: - date: 2026-09-30 note: "Browser-Zugriffe, unabhängige Modellprüfung und technische Schranken präzisiert; Abruf von Warnungen prüfbar gemacht." 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. Für unseren Aufbau war der direkte Zugriff auf Dateien, Befehle und Prüfergebnisse entscheidend. Auch Browser-Assistenten können heute Uploads, Connectors und Cloud-Werkzeuge nutzen; das Chatfenster allein sagt noch nichts über die verfügbaren Zugriffe. Im Editor liegt die lokale Arbeitsumgebung direkt daneben: ändern, Tests ausführen und das Ergebnis prüfen. Darum haben wir diesen Weg gewählt. ## 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 können ähnliche Fehler machen. Ein zweites Modell prüft nicht automatisch unabhängig, nur weil es einen neuen Chat bekommt. Wir nutzen deshalb bei wichtigen Aufgaben eine andere Modellfamilie, klare Gegenfragen und konkrete Belege. Das reduziert mögliche gemeinsame blinde Flecken, garantiert aber nicht, dass der Prüfer alles findet. 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 technische Schranke kann die Aktionen blockieren, die sie tatsächlich erfasst. Wir setzen solche Kontrollen an Stellen mit großem Schaden ein: Serveränderungen, ausgehende Post und Löschaktionen. Ob die Schranke schützt, prüfen wir mit den relevanten Ausführungswegen und Fehlerfällen. Ein Hook oder eine Regel ist keine globale Garantie für jedes Werkzeug. 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 Nutzen entsteht, wenn der Assistent beim passenden Anlass die dokumentierte Warnung tatsächlich abruft. Wir prüfen deshalb nicht nur, ob ein Fehler gespeichert wurde, sondern ob die nächste entsprechende Aufgabe ihn findet. Verbindliche Schranken bleiben zusätzlich nötig; eine Erinnerung allein verhindert die Wiederholung nicht. ## 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 - [Jede Firma bekommt ihren eigenen KI-Agenten](https://studiomeyer.io/de/blog/meetmyagent-jeder-hat-einen-agenten.md) - [Eine Lernplattform, die von Agenten betrieben wird](https://studiomeyer.io/de/blog/academy-von-agenten-betrieben.md) - [Mehrere Agenten, eine Aufgabe: Rollen und Prüfung trennen](https://studiomeyer.io/de/blog/crew-mehrere-agenten-eine-aufgabe.md)