What Outlives the Code

The monomyth of software engineering.

Joseph Campbell’s monomyth says every hero story is the same story wearing different clothes. The hero descends, transforms, returns. Gilgamesh, Odysseus, Luke Skywalker. Different languages, same structure. The costumes change. The journey doesn’t.

Engineering has its own monomyth. I’ve built the same Cloudflare deployment five times now: bash scripts, an MCP server, a shell wrapper, a Claude Code skill, a TypeScript rewrite with Zero Trust. The code changed completely each time. The knowledge didn’t. What to call, in what order, with what guardrails, for what reason. That knowledge is the persistent structure. The code is the costume.

The Artifact That Runs

We treat code as the primary engineering artifact. PRDs decay. Documentation lags. Architecture diagrams go stale within a quarter. Code is “the truth” because it’s the only artifact that actually runs.

But code is increasingly transient. Agents write it, rewrite it, throw it away. The TypeScript I wrote last month might get rewritten next quarter when the framework shifts or the agent gets smarter. The deployment scripts from six months ago are already gone. None of this felt like a loss because the code was never the real asset. It was one expression of something deeper.

Meanwhile, APIs are necessary but insufficient. An API is a button. It tells you what you can do. A harness tells an agent when to press the button, why, and what to check afterward. Dashboards for humans, APIs for machines, and nothing for agents. That’s where most software sits right now.

Where the Knowledge Actually Lives

I wrote about harness engineering a few weeks ago as an internal practice: skills, CLAUDE.md files, evals. The scaffolding around your own agents. But the durable artifact doesn’t live in engineering. It never did.

Significant chunks of it live in the minds of the team. The ops lead who knows which Cloudflare rules break which client. The PM who remembers why a workflow was designed that way three years ago. The support lead who knows the three questions that actually diagnose the problem. Different people hold different expressions of the same business.

Code was never the source of truth. It was one expression. The real knowledge was distributed across people, Slack threads, onboarding calls, tribal memory. We just called the codebase canonical because it was the only artifact that executed.

Now agents need that same distributed knowledge, and they can’t absorb it through hallway conversations. The harness is the first honest attempt to externalize what’s always lived in people’s heads.

Five Costumes, One Hero

My Cloudflare journey is a clean illustration:

1. CLI automation, pre-AI. Bash scripts wrapping wrangler and the Cloudflare API. Worked, but brittle. Hardcoded assumptions everywhere.

2. MCP server. Didn’t work. Too much ceremony, too little context. The protocol gave you tool calls but no understanding of why you’d chain them.

3. Shell wrapper for metrics. Buggy. The scripts encoded knowledge implicitly (which flags to pass, which endpoints to hit in what order) but none of it was readable or transferable.

4. Claude Code skill. Better. The skill could explain itself, had guardrails, knew the domain. Still basically orchestrating the old bash underneath.

5. TypeScript rewrite with Zero Trust. Clean, testable, full coverage.

Five implementations. The TypeScript is the best code by far. But the knowledge (which rules break which client, which error messages actually mean something, the order of operations for a rollout) was identical in every version. I used that skill last week to assign Zero Trust permissions to an engineering service. The skill worked not because the TypeScript was elegant, but because the accumulated knowledge about our Cloudflare setup was captured in a form the agent could use.

The skill file has outlived all five implementations. That’s the monomyth. The code is the costume. The harness is the hero.

The Spec Is the Source

Sean Grove at OpenAI has been making this case from the other direction. His argument: specifications, not prompts or code, are becoming the fundamental unit of programming. Write the spec first. The spec is the durable artifact. Agents compile it into code, documentation, evaluations, behaviors. The code is the compilation target. The spec is the source.

This isn’t new thinking. Literate programming, design-by-contract, formal methods. People have argued for specification-first development for decades. But it never stuck because the code was still the thing that ran. Writing the spec was extra work on top of the real work.

What’s changed: the documentation is now the thing that runs. Through agents. “Write good docs” was always correct advice that nobody followed because the incentive structure punished it. Now the incentive structure rewards it. The spec runs. The skill executes. The harness produces working software. For the first time, the artifact engineers care about and the artifact that generates value are converging on the same thing.

The Harness Is the Product

Bret Taylor, Sierra’s CEO and OpenAI board chair, made a point on Stripe’s Cheeky Pint podcast that extends this outward. He described a future where SaaS companies aren’t evaluated on dashboard UX or API coverage, but on harness quality. Not the buttons you can click, but the instruction manual that tells an agent how to extract maximum value from your platform. “Imagine the person who’s the greatest Stripe expert,” he said. “That’s the harness. Not the API.”

He gave an example: a client with three acquired identity systems. Traditional approach, a massive IT unification project. His approach, give the agent access to all three and let it reason. The harness (goals, guardrails, context about how those systems overlap and conflict) is what makes that work. Not the APIs. The knowledge of how those three systems relate was in someone’s head. Now it’s in the harness.

Sierra hit $165 million ARR in eight quarters building on this premise. Their clients see 70-90% case automation rates and SoFi raised their net promoter score by 33 points. Those numbers didn’t come from better code. They came from better harness design: goals, guardrails, domain knowledge structured for agents.

What Compounds

I’ve written about feedback loops that make skills compound over time. The pattern holds here, too. My /review skill has outlived dozens of code changes. The code it reviews is disposable. The skill is the asset.

This is the shift. Not just that code is ephemeral (it always was, we just pretended otherwise). Not just that the harness matters more than the model. It’s that the thing worth preserving has changed. The durable artifact was always the knowledge: the intent, the guardrails, the domain understanding, the process. It just used to be trapped in people’s heads and expressed (imperfectly, transiently) through code.

Now it has its own form. Skills, specs, harness files. Readable by humans, executable by agents, improvable through use. Different expressions of the same business, captured once.

Campbell’s monomyth persists because it captures something real about human experience that no single retelling owns. The harness works the same way. It’s the structure that survives when the implementation is disposable. The question for engineering teams isn’t what language to write it in. It’s whether you’ve externalized the knowledge at all.