Operating Above the Code

How to structure and steer systems when implementation is no longer the bottleneck.

In the first part of this series, I argued that when you build with agents, the specification starts to look more like the programming language than the code itself. In the second, I wrote about what that shift does to responsibility and cognitive load.

This last part of the series is about how to operate in that world.

If the spec is the language, then shaping it, maintaining it, and structuring it becomes the craft.

Prompts are transient. Specs persist.

A useful distinction I’ve learned the hard way is this: prompts are transient, specs persist.

A conversation with an agent can feel aligned and productive, but anything that lives only in scrollback is temporary. It disappears when the context fills and it becomes difficult to reconstruct precisely.

Specifications, on the other hand, persist. They sit outside the conversation. They can be referenced, revised, compared against the code, and revisited weeks later.

That leads to a simple rule: never leave anything important in the prompt.

If a constraint matters, it moves into the spec. If an invariant is discovered, it gets written down. If a decision shapes future behavior, it is promoted out of the thread and into a living document.

The conversation is where ideas are explored. The spec is where they are anchored.

Exploration is cheap - Commitment is deliberate

Agents make exploration inexpensive. You can sketch alternatives, test edge cases, and evaluate approaches quickly. That’s a gift.

But exploration and commitment are not the same thing.

Moving something into the spec is an act of commitment. It means the idea is no longer tentative - it is now part of the system’s definition. That transition should be deliberate.

Conversations are fluid. Specs are structural.

Knowing when to promote an idea from discussion to documentation is one of the most important judgment calls in this model.

Executive function becomes the constraint

When you first start building with agents, there’s a subtle trap.

Execution moves so quickly that you instinctively try to keep your side of the work in the same proportions as before. In older cycles, planning was important, but implementation dominated the timeline. It felt natural to move briskly through design because the heavy lifting was still ahead.

With agents, the proportions flip.

Most of the time is now spent defining what to build. Clarifying constraints. Stress-testing assumptions. Asking the agent to push back. Exploring alternatives before committing. Execution keeps up effortlessly. Your thinking does not.

There’s a temptation to match the agent’s speed - to move faster on definition simply because implementation is no longer the bottleneck. That’s a trap.

The work hasn’t shrunk. It has shifted upward. And if anything, the definition phase deserves more time than it used to, not less.

The constraint is no longer implementation capacity. It’s the quality of decisions.

Structure before speed

The temptation with agents is obvious: just build something and see what happens.

That works - until it doesn’t.

Before touching implementation, I set up structure. Documents are organized by concern. Specs reference each other deliberately. Release boundaries are clear. The agent is instructed to maintain those references so the system holds together as a whole.

This is not different from code architecture. It’s just that architecture now lives one layer higher as well.

Speed makes iteration cheap. Structure makes iteration safe.

The vision as a north star

Before building a product, I now spend substantial time documenting what it is and where it’s heading. I call this the vision.

It isn’t static. It evolves as understanding deepens. But it exists at the top of the hierarchy, and any part of the system can be checked against it.

Without a north star, local decisions drift quietly. With one, trade-offs have context.

The vision isn’t marketing copy. It’s alignment at the highest level of abstraction.

Instructions are part of the system

Specs describe the product. Instructions describe how the agent should behave while building it - how to interpret documents, how to maintain consistency, what to be careful about.

These instruction layers are first-class artifacts.

Some of this can live in files like AGENTS.md or similar. But I don’t rely passively on automatic injection. Instead, I explicitly reference relevant instruction documents when needed. That act of pointing forces attention and reinforces consistency.

Consistency isn’t accidental. It’s the result of deliberate reference.

Resetting makes context length irrelevant

Context windows fill. That’s normal.

When a discussion becomes dense or approaches the limit, I ask the agent to document the current state of the conversation - what has been decided, what constraints exist, what open questions remain, and what assumptions are still in play.

Then I start fresh, reference that document, and continue.

Nothing important is lost because anything important has already been promoted into a persistent artifact.

Handled this way, context size becomes largely irrelevant. A longer window allows deeper exploration before anchoring decisions, but the durability of the work comes from the documents, not the thread.

Put the state aside. Reset. Continue.

Where this leaves us

Across these three parts, the pattern is consistent: as implementation becomes easier, coordination becomes the real leverage.

We’ve moved up a layer.

The code still matters. But it’s no longer where the primary leverage lives. That leverage now sits in how clearly intent is defined, how deliberately decisions are anchored, and how consistently the system is steered over time.

In the posts that follow, I’ll go deeper into the specifics - how to structure spec documents, how to design instruction layers, how to prevent drift in longer projects, and how to operate tactically without losing architectural coherence.

If the spec is the programming language, learning to write it well is not philosophical. It’s practical.

And this is where the interesting work really begins.