The artifact shifted under your feet

Your team's durable product stopped being the running system. Today it is the executable knowledge — playbooks, archetypes, contracts — that agents read in order to act with the team's intent. The running system is becoming a byproduct. I know how that sentence reads, and I know it sounds dramatic. I have sat with it for months and I think it is the most accurate thing I can say about what is shifting under engineering teams right now.

The Shift That Didn't Feel Like a Shift

For decades the team delivered code that ran. That was the artifact. You hired engineers, they wrote code, the code went into production, the company billed customers for what the code did. Everything else — tickets, PRs, deploys, design docs, retrospectives — was an instrument used to manufacture that artifact. The artifact was what survived; the instruments were scaffolding.

Today the code agents produce in many teams is derived from what the team wrote separately. The prompts that frame the work. The specs the agent reads before generating. The architectural archetypes the agent respects by default. The actionable ADRs that constrain the search space. These are not documentation about the code. They are the inputs that produce the code. The code is downstream.

The shift did not feel like a shift because the deliverable still looked the same — code in a repo, a deploy to staging, a feature in production. The thing that changed is upstream of all of that, and it changed quietly, one team at a time, without an announcement.

Why the Distinction Matters

If the durable thing is the running system, you optimize for time-to-production. You measure lead time, deploy frequency, the gap between the idea and the user seeing it. You hire for shipping speed. You celebrate the team that pushed twice on Friday.

If the durable thing is the executable knowledge, you optimize for quality-of-intent. You measure how well your specs survive contact with a new agent. You measure how rarely you have to re-explain the same constraint. You hire for the ability to encode what a senior knows in a form that another agent — or a future teammate — can act on. You celebrate the engineer who finally got the architecture archetype crisp enough that the agent stopped making the same class of mistake.

Those are two different org charts. They have different metrics, different rituals, different ways of hiring. You cannot run both at the same time without either burning people out or producing incoherent priorities. The transition is real and someone has to be willing to name it. The paper §8 makes the structural argument; this is the operational corollary.

What Becomes Executable Knowledge

Four kinds of artifacts are crossing the line from documentation to executable knowledge. Not exhaustive, but a working list.

Architecture archetypes the agent respects by default. Not a markdown file describing the architecture — a structured artifact the agent reads on every relevant task, encoded clearly enough that the agent can detect when its proposed change violates it. The archetype is the thing; the prose explanation is its human-readable shadow.

Quality contracts the agent verifies before proposing a change. Not a wishlist of "we should write tests." An explicit, checked contract: this kind of change requires this kind of evidence, here is the format, here is the verification step. The agent runs the contract. The team writes it once and revises it as understanding improves.

Incident playbooks the agent executes step by step. The runbook stops being a Confluence page someone reads at 3am and becomes a procedure the agent runs while a human watches and approves at decision points. The playbook gets versioned with the same care a service gets versioned, because it is now part of the operational surface.

Research notes the agent reads while reasoning about a feature. The investigation a senior did six months ago — about whether to use a queue or a stream, about why this third-party library is unsafe in this context, about how a previous customer's edge case broke production — becomes context the next agent retrieves and uses. The note stops being archive and becomes active memory.

In each case the artifact already existed in some form. What is new is that the agent reads it, that the team can verify the agent read it, and that the team treats the artifact as load-bearing in a way it previously did not.

The Feeling of Loss

Many senior engineers feel a sting when they internalize this. I have felt it myself. We identified with hand-written code. The craft of the line, the elegance of a clean abstraction, the satisfaction of a well-named function — those were the markers we used to tell ourselves we were good. Watching an agent produce the line, even an inferior line, can feel like a small bereavement.

But hand-written code was the medium, not the end. The end was always well-expressed intent. A beautiful function whose intent is wrong is still wrong. The senior contribution was never the keystrokes; it was the judgment that decided which function to write, why, with what constraints, against what failure modes. That judgment is what becomes executable knowledge. The medium changes. The contribution survives — in fact, it becomes more visible, because it is now written down where it used to be implicit in the choices.

Reclaiming that returns agency. It does not take it away. The senior who masters the encoding of intent into executable knowledge is more powerful inside an agent-driven team, not less. The senior who refuses to make the move — who insists on continuing to compete with the agent at the line-of-code level — is the one who watches her influence shrink.

What Changes in Your Next Sprint

Start versioning your executable knowledge with the same care you version code. Branches, reviews, change history, ownership. If your team's prompts and specs and archetypes live in a Notion page that anyone edits without review, you are treating load-bearing artifacts as decoration.

Run one audit. If every agent your team uses changes tomorrow — different vendor, different model, different harness — what part of the work your team did this quarter survives? That surviving part is your durable artifact. Everything else was scaffolding tied to a specific tool. The ratio between the two is one of the most honest measurements you can take of where your team actually stands in the transition.

The rest was scaffolding. That is harder to hear than it sounds, but it is the test that tells you which work was investment and which work was throughput.

Of everything you wrote last month, which piece passes the "survives even if the agents change" test? That is the new piece of the work.

#TechLeadership #AI #FutureOfWork #Engineering #MetaSoftware