The model eats the layer

I've built on most of the layers people are bolting onto AI this year. Prompt wrappers, skills, spec frameworks, orchestration that drives a fleet of agents through a long job. A lot of it is already dead weight in my repos.

Not because I built it badly. Because the model got good at the thing the layer existed to cover, and the day it did, the layer stopped being worth anything.

Half the tooling scene is doing this right now, pouring months into scaffolding that the next release is about to make redundant. I know the feeling from the inside, because I spent a good part of last year doing exactly that and calling it progress. I keep watching it happen to my own work. Every layer you build to cover what the model can't do yet is a layer the model is coming to eat.

I've started calling it the same thing each time. The model eats the layer. I hold the name loosely. The mechanism under it I don't, because it has cost me real work to learn.

The stack, from the model out

The way I picture it now, after watching a few of these die, is a stack with the model at the bottom and everything I add sitting on top.

The first thing on top is context. The model on its own is a clever autocomplete with no memory of my stack and no stake in my problem, so I wrap the call in the right files, the right instructions, the decisions already made. I've argued before that the context window is everything, and I still think the biggest quality gap in this work lives there.

On top of context sits the skill. Not a prompt saved to a file, but my opinionated way of doing a thing written down, so the model follows it instead of averaging across everyone else's. Left alone it's trained on the beginner and the principal engineer at once and splits the difference. The skill covers for that.

On top of the skill sits the harness. When a job runs long the model's grip on the plan slips and it loses the thread halfway through, so I build something that holds the plan for it. A spec it executes. A workflow that keeps the loop and the partial results and spawns fresh agents, so no single context has to carry the whole thing.

And on top of all of it sits the product, the surface someone actually touches and the relationship around it.

Every one of those layers is there for the same reason. It covers for something the layer below it can't do reliably yet. That is what makes it useful, and it is exactly why it won't last. The moment the layer below stops being unreliable, the cover becomes weight. The model rises through the stack, and the layers that were only ever covering for a missing capability go first.

Why they get eaten

A layer is worth the size of the weakness it covers, times how long the weakness lasts.

The harness is the one I watched most closely. A year ago the model genuinely could not hold a long plan in its head. It drifted through a big job and lost the thread, and there was nothing to do from the outside except build scaffolding that held the plan for it. That was worth a lot. It was the difference between a task finishing and a task falling apart at hour 3. And it had a clock on it from the first commit, because the weakness it covered, "the model can't hold a long plan," is exactly the kind of thing every release chips at directly. The moment the model could hold the plan itself, the scaffolding turned from a feature into weight I now had to maintain.

So I run a rough sum before I build anything on top of the model. What does the layer cost to build, and how long until the model absorbs it. Say a wrapper takes a weekend, call it 20 hours, and saves an hour a day. If the model eats it 6 months later, it handed back something like 120 hours for the 20 I spent. I take that trade every time. Now say a framework takes 2 months to harden properly, a few hundred hours, and the next release makes it redundant 6 weeks after it ships. To break even it had to save those few hundred hours inside 6 weeks, most of a working day every day, doing nothing but running that framework. It never had the chance. It was underwater before it shipped.

What took me longest to accept is that this cuts against the instinct that got me here. The instinct says a hard, well-built thing is an asset. With a layer, how well I built it barely predicts how long it lasts. The model's next release decides that, because the release is what does the eating. The better I build a doomed layer, the more I lose when it goes, because I sank more into it.

The move that survived cloud

This isn't the first time I've watched it happen.

AWS ate the datacenter. It took the undifferentiated heavy lifting, the racking and the cooling and the capacity planning, and turned it into something you rent by the hour. A whole category of work companies used to do for themselves stopped being worth doing yourself, more or less overnight.

The ones who came through it didn't build a better datacenter. That fight was lost the day the alternative went hourly. They moved up to what AWS couldn't commoditize: the application, and the customer relationship. They let the layer under them get eaten and made sure they were standing above it when it happened.

The model is the same kind of force, with one difference that matters. AWS ate a layer and stopped. The model doesn't stop. It rises through the stack release after release, so climbing one layer higher only buys a release or two. The only ground that holds is somewhere the water can't reach.

Everyone says build good products. True and useless, because it never tells you where to build. So the question I run now is how close a layer sits to the water, and whether there's anything under it the water can't touch.

What the water can't reach

So what is out of reach. What does the model structurally not eat.

Not a capability. Capabilities are the one thing it eats reliably. Anything I can phrase as "the model can't do X yet" is a countdown, and the "yet" is doing all the work.

The judgment about what is worth building at all is out of reach. I've written that when agents execute your specs directly, the spec becomes the product, because you can't write a spec that survives a fleet of agents without actually understanding what you're building. The tooling that generates the specs is a layer and gets eaten. The understanding under it didn't get cheaper as the model got stronger. It got scarcer, and it sank further under the water, not closer to the top.

And then there is the thing I spent 15 years learning before any of this. A defensible business was never a pile of features. It was one advantage built deeper than anyone was willing to match. I got that wrong for a long time. The pull is to defend on every front at once, a little brand and a little distribution and a little proprietary data, a thin layer of each, and that is mostly what I did. Deep on one felt riskier than thin across five. What held, the few times I got it right, was going deep enough on one thing that a competitor wouldn't follow.

The ones worth going deep on now are the ones the model can't reach into. Proprietary data is the clearest. The stream your product earns just by being used, the corrections and the edge cases the model has no way to see from outside, compounding every week it runs. One of the things I'm building now, Andelo, runs on exactly that, the operational data of a narrow and genuinely awkward corner of housing that was never in anyone's training set. Going deep in a single vertical is the same move from another angle, and so is becoming the thing a market organizes itself around instead of one more tool inside it. What they share is that the model can't manufacture the thing beneath them, so it only makes that thing scarcer as it gets stronger.

That is also the test to run on your own product. Which part of it gets more valuable as the model gets stronger? The data it earns while it works. A vertical you know deeper than anyone would bother to follow. Or a relationship that already trusts you. Whichever of those you honestly have, the next months of depth go there, not into another layer.

There is a clock on this, and it's running right now. Move fast in one vertical and you can take a real piece of it before the tooling underneath turns commodity and everyone floods in. Moving fast doesn't build the moat. It just gets you to the ground while it's still soft enough to dig.

When everyone can generate the same competent output, the tiebreaker that's left is the one advantage someone went too deep on to copy.

It's the same reason the flood of AI content doesn't eat distribution the way you'd expect. It runs the other way. When the market fills with output that all looks alike, what's worth more is the relationship the flood can't fake, the customer who already trusts you, the audience that already shows up for you. The stronger the model gets at the output, the further down it pushes the relationship underneath, out of its own reach.

The code taught me this one directly. For a while I built as if the code was the asset. It wasn't. The code was the most eatable layer of all, and I was standing right on top of it, sure the height meant I was safe.

What's left

I still build layers, and I build them knowing some will be dead weight by the time the next models land. That is usually still the right call. The job in front of me needs it, and the months it buys are worth having. What changed is that I know it's a layer now, and roughly how long it has, so the water doesn't take me by surprise.

And I know the part worth protecting was never a layer at all. Every layer you build to cover what the model can't do yet is a layer the model is coming to eat.