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.
A chat window in the browser only sees what you paste into it. An assistant inside the editor sees the files, can run commands, read results and derive the next step from them. The difference between "explain how I change this" and "change it, run the tests and show me the result" is not convenience, it is a different way of working.
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 from the same family make similar mistakes. When builder and reviewer come from the same house, the reviewer reliably overlooks exactly what the builder overlooked. They share the blind spots.
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 stop that intercepts the command and refuses it with a reason works every time. Such stops hang at the places with the largest blast radius: at anything that can overwrite a server, at outgoing mail, at deleting actions.
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 practical effect: a mistake made once and written down comes back as a warning at the next fitting occasion, without anybody having to remember it. That is the difference between a system that learns and one that starts from zero every Monday.
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.
