---
title: "What We Actually Work With"
description: "An editor, two model families side by side, and a layer of recipes, rules and hard stops. The part talked about least and carrying the most."
author: "Matthias Meyer"
published: 2026-08-05
updated: 2026-09-30
updates:
  - date: 2026-09-30
    note: "Clarified browser access, model review, technical guards and verification of warning retrieval."
language: en
tags: ["maschinenraum", "arbeitsweise", "werkzeuge", "claude", "codex"]
canonical: "https://studiomeyer.io/en/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)"
---

# What We Actually Work With

A lot gets said about models. Hardly anything about the surroundings. Yet in daily work the surroundings are what decide.

What is described here is not a product and not something we sell. It is the answer to the question we get asked most in conversation, mostly by people who work with AI themselves: how is this set up at your place.

## The Editor Is The Stage

The work happens in a normal code editor, not in a chat window in the browser. That is the single most important difference.

Direct access to files, commands and verification results mattered for our setup. Browser assistants can now also use uploads, connectors and cloud tools; a chat window alone does not tell you what access exists. In the editor, the local working environment sits alongside the assistant: change files, run tests and inspect results. That is why we chose it.

## Two Model Families, On Purpose

Assistants from two different houses run side by side. That is not indecision but the most effective quality lever we have found.

Models in the same family can make similar errors. A second model is not automatically an independent reviewer merely because it has a new chat. For important tasks, we use another family, explicit counterquestions and evidence. This can reduce shared blind spots, but does not guarantee complete review.

Run a model from a different family over the same work, with the explicit assignment to refute it, and different findings come back. Not more findings, different ones. That is now our standard route for anything non-trivial: one builds, a second attacks, and it keeps going until nothing substantial comes back.

## Recipes Instead Of Explaining Again

The second layer is recipes for recurring procedures. A deploy, a blog post, a client onboarding, a server check.

The point of them is not automation. The point is that each recipe carries the traps we already fell into. For publishing a site, for instance, it holds the order of checks that are due before the switch.

Knowledge like that otherwise disappears. It lives in the head of somebody who is not around that day. In a recipe it is written down and gets followed next time, including by an assistant that does not know the story behind it.

## Hard Stops That Do Not Ask Politely

The third layer is the one that has saved us the most trouble. These are hard blocks that prevent certain actions technically rather than disapproving of them.

The difference is decisive. An instruction like "never use this tool against a server" is a request. It works most of the time and eventually it does not, because it sits in a long session under a lot of other text.

A technical guard can block the actions it actually covers. We place these controls around consequential operations: server changes, outgoing messages and deletion. We test relevant execution paths and failures. A hook or rule is not a global guarantee for every tool.

The lesson behind it is more general than the tool: **a rule without enforcement is a note.** When the same thing has happened twice, the text about it has been refuted and a mechanism is needed.

## And The Memory Underneath

All of it hangs off the memory described elsewhere in this series. It holds decisions, mistakes and patterns across months, and across sessions.

The benefit comes when the assistant actually retrieves a documented warning at the right time. We check not only that an error was stored, but that the next relevant task finds it. Technical guards remain necessary too; memory alone does not prevent recurrence.

## What Of This Transfers

We do not rebuild this setup for anyone, that would be silly. But three things from it hold regardless of tooling.

First: the assistant belongs where the work is, not next to it. Second: reviewing has to be done by somebody other than the builder, and the more different the better. Third: whatever has already gone wrong needs a hard stop, not a reminder.

The rest is taste and habit.

## Read more, Engine Room

- [Every Business Gets Its Own AI Agent](https://studiomeyer.io/en/blog/meetmyagent-jeder-hat-einen-agenten.md)
- [A Learning Platform Run By Agents](https://studiomeyer.io/en/blog/academy-von-agenten-betrieben.md)
- [Multiple Agents, One Task: Separate Roles and Review](https://studiomeyer.io/en/blog/crew-mehrere-agenten-eine-aufgabe.md)