The tools change every few months. What makes them good doesn't change: the engineering judgement they run on. Your job is to get that judgement out of your head and into a form every agent applies, on every run.
In a few years we've gone from autocomplete, to chat, to agents in the editor, to agents in the terminal, to fleets of agents run by an orchestrator. Every wave arrived with a new “best” tool, and most of those were overtaken within months.
Two mistakes follow from that. Waiting for the tools to settle: they won't. And standardising too early on one tool, as if choosing it were the decision that mattered.
Pick something good enough and get good at it. What you learn carries over, because what you're really learning isn't the tool. Switching still has a cost: a new model has a different envelope, so move when the gain is worth recalibrating, not just because something newer exists.
Give two engineers the same harness and the same model, and they get very different results. The difference is everything they bring to it: how they break work down, what context they give, how they'll know the result is right, and what good structure looks like in this codebase.
That is the skill. And it's the scarce input: the model is a commodity anyone can buy.
Judgement that lives in your head only reaches the changes you personally look at. At agentic throughput, that's a shrinking fraction of the total.
Judgement written down as a skill, an AGENTS.md, a rule or a check reaches every agent, on every run, while you sleep. Tooling is how one engineer's skill scales to a fleet.
Illustrative: you can look at about 1 in 6 changes yourself.
Each rung reaches more work, and survives longer. A prompt helps one session. A skill or AGENTS.md helps every session that reads it. A check in the build is applied to every change whether anyone reads it or not.
Not everything can become a check: taste and context live in skills and docs. But anything that can be checked mechanically should be. That's Rules that enforce themselves, seen from the engineer's side.
Here's why the setup and the thesis fit together. Encoded judgement is plain text in a repository: markdown, rules, tests, process models. Any capable harness can read it.
When the next tool arrives, the engineers who wrote their skill down bring all of it with them. The ones who kept it in their heads start from a blank prompt.
Illustrative skill file.
An organisation's real asset in agentic engineering is the judgement of its best engineers, and how much of it has been captured where agents can use it.
Treat that work as first-class: give experts time to do it, review it like code, and recognise it. A senior engineer who turns a recurring review comment into a skill everyone's agents load has done more than one who leaves the same comment on a hundred PRs.
Tools churn; get good with one and move on when it's overtaken. What carries over is your judgement, and it only scales when it's written down: as skills, as AGENTS.md, as rules and checks that every agent applies on every run.