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. 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 followe