brianchitester.comPosts

The Layer Above the Model

Every model release runs the same playbook now. Opus 4.7 ships, GPT-5.5 ships a week later, and within hours half my feed has declared one of them completely cooked and the other a generational leap. By the next release the verdicts have flipped. Then it happens again.

I’ve been quietly running the same workflow through a few of these cycles, and the thing that surprised me isn’t who’s right about which model is better. It’s how little the answer matters compared to what’s above it.


Capabilities Plateaued, the Discourse Didn’t

We crossed a real threshold somewhere around GPT-5 and Opus 4. Before that, model releases genuinely changed what was possible. After that, the deltas got narrower — better long context, better tool use, fewer regressions on specific benchmarks — but the shape of what you can build stopped changing release-to-release.

The hype cycle didn’t get the memo. The same volume of drama now rides on top of much smaller capability shifts, which means most of what’s being argued about isn’t really about the model. It’s about taste, vibes, and a half-dozen prompts run in a coffee shop.


Switching Resets the Compounding

Here’s the part I think gets missed. Tool fluency compounds. The shape of your prompts, the rhythm of your sessions, the eval harness you’ve built up around your actual workflow, the muscle memory for when to one-shot vs. agent-loop, the system prompts you’ve already tuned to your project — all of that gets sharper every week you stay with one tool.

A small capability delta between releases is not big enough to justify resetting that compounding. The gap between someone who knows their tool deeply and someone who’s spread thin across three of them isn’t close — and it doesn’t go to the person with the broader exposure.

The honest version is: pick one, get genuinely good with it, switch when there’s a real reason — not a tweet thread.


The Layer That Survives Releases

The other thing that compounds is the layer of skills above the model. Structured outputs. Eval design. Knowing how to decompose a task for an agent vs. a one-shot. Knowing when context is the bottleneck and when it’s the prompt. Knowing how to write a system prompt that holds across sessions. Knowing what your own code looks like when it’s been generated well, and what it looks like when the model was bluffing.

That layer transfers across model releases. The model is the substrate. These skills are the layer above it. People keep optimizing for the substrate — which churns every quarter — and ignoring the layer above, which doesn’t.

If you spent the last six months tuning your evals and refining how you structure tasks for an agent, you came out of those six months meaningfully better at this. If you spent the last six months switching providers every release cycle, you came out roughly where you started, with a slightly different default model in your IDE.


You Should Still Use the Frontier

I don’t want this read as a “stop chasing models” post. Real capability jumps do happen — long-context Opus, the agent-reliability shift, structured outputs going from a hack to a primitive. You should default to the frontier.

But notice who actually clocked those jumps. It wasn’t the loudest accounts in the discourse. It was the people with their own evals, running the same harness against the new model and watching specific numbers move on their actual workload. That’s the only reliable signal in this space, and it lives downstream of the fundamentals, not the discourse.

The way to notice that the model finally did something new is to have invested in the layer above it.


Where to Spend the Attention

The energy I see going into model takes would be better spent on:

None of those skills get obsolete when 4.7 becomes 4.8. All of them compound.


The model keeps changing. The discourse keeps doing its thing. The lever isn’t down there. It’s in the layer above — and that’s the only place where last quarter’s work is still working for you.

2026 © Brian Chitester.