We are an AI-assisted studio and we have never been shy about it. The models write most of the code here. That makes the choice of model family one of the most consequential technical decisions we make, closer to choosing a framework than choosing a tool, because everything we ship passes through it.
We standardized on Claude deliberately, not by default. The alternatives were serious and still are, and committing to one family anyway ranks among the highest-return decisions this studio has made. This post is about what we compared, why Claude won for our kind of work, and what standardizing on one model family changed about how we estimate and what we promise.
What we actually compared
We did not compare benchmark scores. Benchmarks measure puzzle-solving in a vacuum, and we do not ship puzzles. We compared shipping: the same kinds of real briefs, on real codebases, judged by the same quality gates every build here has to pass before it goes anywhere near production.
Three things decided it. First, code quality at long context: how well a model writes when it has to hold an entire design system, a typed content layer, and thousands of lines of existing conventions in mind at once. Second, instruction-following: whether written rules actually stick, or quietly erode over a long working session. Third, degradation behavior: what happens to output quality as the codebase grows and the easy context runs out.
Where the difference showed up
Our builds run large. A typical catalog site here is hundreds of statically generated pages produced from a single typed data layer, and our biggest runs past 490 URLs. At that scale, a model that loses the plot at the edge of its context does not produce one bad file. It produces subtle inconsistency everywhere: a component styled three slightly different ways, a convention honored in one folder and forgotten in another. Long-context code quality was where Claude pulled away first, and it was not close enough to argue about.
Instruction-following mattered even more than we expected, because our rules are strict and written down. Never fabricate a statistic. No em-dashes in body copy. Contrast ratios engineered into the design tokens rather than eyeballed. One conversion path per page. A model that treats written constraints as polite suggestions turns every one of those rules into a manual review step. A model that follows them turns the rules into infrastructure.
“The fewer times you correct the model, the more of your attention goes to the work only a human can do: taste, judgment, and truth.”
What standardizing changed
The obvious change was consistency. One model family means one voice in the codebase, one set of failure modes to learn deeply instead of two sets to learn shallowly, and working conventions that carry from project to project instead of resetting with every tool change.
The less obvious change was to our estimates. Estimating AI-assisted work is really estimating the correction loop: how many passes between first draft and shippable. When the model is a variable, that loop is a dice roll and every quote carries padding. When the model is a constant you know well, the loop becomes predictable enough to quote timelines honestly and hold them.
- Estimates tightened, because the correction loop stopped being the unknown in every quote.
- Quality gates got sharper. A gate earns its keep when failures are rare enough to investigate individually, and they became rare.
- Hard rules moved out of review checklists and into the brief, and they held.
- Model upgrades became a scheduled evaluation instead of a scramble.
The bar did not move. The floor did.
Standardizing on Claude did not lower our standards; it raised the starting point the standards apply to. Nothing here ships unless typecheck, lint, and a full production build are green. Every page is reviewed and screenshot-verified on desktop and a real phone viewport before it is called done. Our marketing builds still run lean, typically 4 to 7 runtime dependencies, and full-site quality sweeps have returned 100 for accessibility, best practices, and SEO on every page we have run them against.
None of that is the model's doing. The gates are ours, and they predate any particular model. But the model determines how often the gates catch something, and that frequency is the difference between a quality bar you actually enforce and one you merely aspire to.
Not loyalty. A standing bet.
This is not brand loyalty. When a major model generation ships, the comparison deserves to be re-run on real work, because the honest answer to which model is best has an expiration date. So far, nothing has narrowed the gap for the work we do: large, custom, strictly ruled production websites.
If that ever reverses, we will switch again and write about it here, because the commitment was never to a logo. It is to what survives our gates.
