Your experience is a runtime dependency

I was explaining something to Jack Pettit earlier and the analogy landed better than I expected.

We were talking about agents. Well, sort of. It was less "what do I think about agents?" and more "why do some people seem to get much better work out of the same tools?"

The bit I keep coming back to is this: agents are extremely capable, but they don't have your experience. They don't have the production bugs you remember. They don't have the customer conversations that changed how you estimate work. They don't know which reviewer always cares about one particular edge case. They don't know which CLI command you trust and which one you avoid because it lied to you three months ago.

That stuff matters.

The model can be brilliant in the general sense and still be missing the dependencies that make it effective in your environment.

#The missing dependency

The way I explained it was a bit like onboarding a very sharp new starter.

They might have just finished studying and know the newer tools better than you do. They might be quicker at finding patterns, quicker at reading docs, and less attached to the way things were done five years ago.

Great, that's useful.

But someone with a few years of real work behind them usually knows things that are hard to teach in a classroom. They know what "done" means on a real team. They know when a shortcut is fine and when it becomes a support ticket. They know that the Jira ticket is often missing the actual requirement. They know which parts of the system are safe to touch and which parts look simple because the complexity is hidden in the business rules.

That's the gap with agents too.

The agent isn't short on raw intelligence, just on runtime context.

It doesn't know your team conventions unless you give them to it. It doesn't know your preferred validation flow unless you write it down. It doesn't know your taste in PR descriptions, your tolerance for risk, your habits around issue planning, or the little repo-specific commands that make the difference between "technically works" and "works the way we work here."

So when we complain that agents produce generic output, sometimes the uncomfortable answer is that we gave them generic inputs.

#Skills are packaged experience

This is where skills, AGENTS.md, CLAUDE.md, and repo instructions start to matter.

I don't think of those as prompt hacks anymore. They're closer to packaging your working habits so the agent can load them at the right time.

Some of that belongs globally:

• how you like review findings reported
• how you want artifacts created
• when the agent should search instead of guessing
• what commands are safe or unsafe in your environment
• how much autonomy you expect before it comes back to you

Some of it belongs in the repo:

• how to run the tests that actually matter
• which generated files not to hand-edit
• where issue templates live
• which deployment scripts are the real ones
• what "done" looks like for that codebase

And some of it belongs in skills:

• how to review a pull request in your style
• how to refine a backlog item
• how to apply brand rules to an artifact
• how to write in your voice
• how to handle a workflow you repeat often enough that rediscovering it every session is waste

The goal is not to bury the model under rules. I've done that too, and it gets slow and annoying quickly. The goal is to make the important context available where it helps.

A good skill isn't "think exactly like me." It's "when doing this kind of task, here are the constraints, examples, tools, and checks that make the result acceptable."

That tends to age better.

#Every model upgrade makes this more useful

The other part of the analogy is that every new model feels a bit like the next year's intake.

Better trained, more capable, more current, and less likely to get stuck on the things the previous one struggled with.

But the new model still doesn't know your history by default.

That's why I think the context you build around agents compounds. If you put your experience only into one-off prompts, it disappears at the end of the session, but if you put it into durable skills and instructions, the next model gets to inherit it too.

That's the interesting bit for me.

You're using this year's model better, but you're also building a small layer of your own professional context that can travel forward as the tools improve.

The agent gets smarter underneath. Your context gets more useful on top.

#This is also engineering work

There's a trap here where people hear "write better prompts" and think this is about being clever with wording.

I don't think that's the job.

The job is closer to making implicit engineering judgement explicit enough that an agent can use it.

If you always check unresolved GitHub review threads a certain way because the simpler command misses inline comments, write that down. If a repo has one command that looks like it runs the tests but does not cover the important path, write that down. If you keep correcting agents for the same formatting, planning, validation, or artifact mistakes, turn the correction into a skill or instruction.

Not every correction deserves a rule. Some mistakes are one-offs, some are the model having a bad day, and some are just your request being vague.

But when the same correction keeps coming back, that's usually a missing dependency.

Package it.

#The output becomes yours

Two developers can use the same model and get very different results.

Part of that is the prompt in the moment, sure, but more and more I think the bigger difference is the environment around the model. The skills, repo instructions, examples, etc... The little bits of scar tissue that have been turned into reusable guidance.

Nobody else has exactly your experience. Nobody else has your exact set of projects, customers, outages, habits, preferences, and tradeoffs.

If you do this properly, the agent becomes better at producing the kind of work you would have produced, with the speed and breadth the model brings.

That's the part worth paying attention to.

The agent is already smart. The missing piece is experience.

And your experience is a dependency you can choose to ship.