How Long Does Harness Engineering Have?

Everything useful you can build into a harness eventually gets pulled into vanilla. After that, what’s left isn’t the useful features. It’s only whatever Claude structurally won’t do or can’t do. The harness-maker I poured a year into taught me that. Claude Code covered its loop and review the moment it shipped Goal and Dynamic Workflows by default. It landed on exactly that spot.

It started simple. Harness engineering was having its moment, and I wanted one of my own. So I built harness-maker and poured a full year of experience straight into it. Every project has a different taste, and I needed a way to bake that taste into the harness. Between company work, side projects, and things I actually sell, a single open-source harness couldn’t optimize for all of them. A project running Spec Driven and a project running light on Task Driven have different workflows, full stop.

Then I saw Dynamic Workflows and my read flipped. Most OSS harnesses are about to get absorbed. My harness-maker’s loop and review are no exception. I should just count them as already absorbed.

So it makes me ask what’s left in harness engineering going forward. We went from prompt to context, then context to harness. Does this one also fade into a term from a past season, the way prompt engineering and context engineering did?

Lately I keep seeing people around me drift back to Claude Code vanilla. Makes sense. Vanilla keeps getting stronger and more personal, and anything worth using gets sucked into native. So by definition, one thing is left. The useful features all got absorbed, so the only thing that stays in that spot is what Claude structurally won’t or can’t do.

Vendor-neutral features, for one. And vendor-hostile ones. Those survive. Something like ccusage fits: it tracks your token cost from local logs and nudges you to spend less. No vendor is going to build the thing that eats its own revenue. Methodology taste hangs on for a while too. By methodology taste I mean the workflow encodings baked into some OSS harnesses. A workflow that forces SDD, or a methodology that forces a deep interview when you plan or define a spec. That kind of thing.

But it doesn’t last either. The moment a dynamic taste setting or a methodology setting proves useful, the vendor ships it in vanilla by default. Straight to absorbed.

So I’ve stopped piling more harness onto spots that are obviously headed for absorption. I spend time only where the vendor structurally can’t or won’t go.

In the end, OSS and personal harnesses alike are a training signal that teaches the vendor my taste. The better I encode it, the faster it gets learned, and the faster it goes obsolete. For that short transition window, though, it’s real leverage.