What to do when the model gets better next Tuesday.

Building on top of frontier models in 2026 feels a little like building a house on a tide. The ground moves on a schedule you do not control. A capability you spent two months engineering around shows up as a default in the next release. A prompt you tuned for weeks becomes obsolete the morning a new checkpoint drops.

The instinct, when this happens, is either to freeze (pick one model, pin the version, refuse to look up) or to chase (rewire the stack every time a new benchmark crosses a threshold). Both are losing strategies. The first leaves value on the table. The second never compounds.

The frame we use with clients is simpler. Sort every piece of your system into one of three buckets. Substrate is the part the lab does better than you, every quarter, forever. Scaffolding is the part you build to make the substrate usable for your specific job. Soul is the part that is uniquely yours: your data, your taste, your relationships, the judgment you have earned.

Treat substrate as a commodity. Do not write a thousand lines of retry logic for something that will be a parameter next month. Treat scaffolding as disposable. Build it well, but expect to throw most of it away on a one to two year cycle. Treat soul as the actual asset. Invest there. Protect it. Make sure it is not accidentally entangled with substrate or scaffolding in a way that will rot when those layers move.

When the model gets better next Tuesday, the question is not whether to adopt it. The question is which of your scaffolding just became unnecessary, and whether your soul is portable enough to ride the new substrate without rewriting itself.

Most teams have these three layers tangled together. The work is to separate them, on paper, before you separate them in code.