AI Will Have Skills. Developers Will Have None.

The problem I have with agentic skills is not the skills themselves.

Skills are useful. They can package domain knowledge, repeatable workflows, tool guidance, and the little bits of hard-earned context that usually live inside one engineer’s head. A good skill can make an agent dramatically more capable.

My problem is that we are treating many of them like text snippets when we should be treating them like software artifacts.

My larger concern is where that path leads.

We are rushing to extract judgment, technique, and experience from developers, package it into files for agents, and call the result a productivity improvement. If we do this badly, the AI will accumulate an impressive library of SKILL.md files while the developers invoking them slowly lose the skills those files describe.

AI will have skills. Developers will have none.

Tools have always abstracted work. Good abstractions let us operate at a higher level while preserving enough understanding to verify the result. Bad abstractions turn practitioners into button-pushers who cannot explain, challenge, or repair what the button does.

If a skill can influence which commands an agent runs, which files it changes, which services it calls, how much money it spends, or what it tells a user, then that skill is part of the system. It deserves the same engineering discipline we would apply to a microservice.

Right now, a lot of the industry is doing the equivalent of deploying a service by copying its source code into random laptops and repositories, then hoping everybody remembers where they put it.

That is not a deployment model. That is a scavenger hunt.

Easy to Create Does Not Mean Easy to Operate

The appeal of skills is obvious: they are easy to create.

You can write a Markdown file, add some instructions, point an agent at it, and immediately see better behavior. There is very little ceremony between idea and execution. That low barrier is a feature.

It is also where the trouble starts.

The cost of creating a skill is small. The cost of owning one is not.

Once a skill becomes part of a real workflow, somebody has to answer questions like:

• Who owns it?
• Which version is installed?
• Who reviewed the last change?
• Which agents and repositories depend on it?
• What permissions does it assume?
• How much does it cost to run?
• How do we know it still works after a model or tool changes?
• How do we revoke it when it becomes unsafe or obsolete?

If we cannot answer those questions, we do not have a managed capability. We have an instruction file with production access.

That distinction matters.

Copy and Paste Is Not Deployment

Most skill distribution I see amounts to some variation of this:

skill.md
   |-- copied to a developer's local machine
   |-- copied into repository A
   |-- modified slightly in repository B
   |-- pasted into an agent configuration
   `-- forgotten in a directory nobody audits

The moment that happens, there is no longer one skill. There are several related documents drifting apart.

A security fix lands in one copy but not the others. An instruction changes in a repository but not on a developer’s machine. A team tunes the skill for one model, while another team runs the old version against a different toolset. Six months later, all of those copies have the same name and different behavior.

We already know how this story ends because software has been telling it for decades. Unversioned, independently modified dependencies do not become easier to manage because they are written in natural language.

In some ways, they become harder.

Natural-language instructions can conflict without producing a compiler error. They can be syntactically valid while being operationally wrong. They can look harmless in a diff and still change which tools an agent chooses, how long it runs, or whether it asks for approval before doing something expensive.

SKILL.md may be Markdown, but its behavior is executable enough to deserve controls.

The Cost Is Hidden Until Something Stops

Cost is one of the least visible failure modes.

It is easy enough to count the tokens in a SKILL.md file. That gives us a predictable base cost for loading the instructions. Unfortunately, the instructions are often the cheapest part of the run.

The real cost is in what those instructions cause the agent to read next.

total usage = skill instructions
            + retrieved files and records
            + command and tool responses
            + context repeated across turns
            + model output and reasoning

A small skill can say, “Read the application logs, identify the failure, and recommend a fix.” The sentence costs almost nothing. The agent may then ingest enormous log files, query several services, read verbose responses, reconsider the same context over multiple turns, and produce a long explanation nobody needed.

The file was small. The behavior was not.

Scripts can help by filtering, aggregating, and bounding data before it reaches the model. A script is not automatically a cost control, though. It can just as easily dump 50,000 lines of output into the context window with impressive efficiency.

Whether a skill uses scripts or direct tool calls, its responses should be designed as carefully as its instructions. Tool output should be minimal, relevant, structured, and still contain enough context for the agent to make the next decision correctly. Minimal does not mean cryptic. It means we stop making an expensive language model search through noise that ordinary software could have discarded first.

Imagine a skill that reliably produces a useful report but consumes $5 worth of tokens every time it runs. It is easy to copy that skill into a workflow because the file itself is free and the result looks good.

The cost is delayed, displaced, and largely invisible at the moment somebody decides to use it.

There is usually no price tag next to the skill. The user does not see an estimate before running it, a meter while it works, or a receipt when it finishes. They type a command, receive an answer, and reasonably assume the interaction was cheap enough to be unremarkable.

Then the budget gets hit.

A weekly token allowance disappears on Wednesday. An API begins throttling requests. A shared agent stops in the middle of a critical workflow. A monthly invoice arrives well above its forecast. Only then does anyone discover that one “simple” skill performs several model passes, repeatedly loads a large context, or fans out into dozens of tool calls.

By that point, the cost is no longer an implementation detail. It is an outage, a blocked developer, or an uncomfortable budget conversation.

One run looks reasonable:

1 run x $5 = $5

The same skill inside a routine process looks different:

40 developers x 3 runs per day x 20 workdays x $5 = $12,000 per month

That is not an argument against expensive skills. Some tasks are worth $5—or $50—if they replace enough human effort or reduce enough risk.

It is an argument against invisible cost.

A production skill should have a budget for instructions, tool responses, total context, output, reasoning, retries, and the number of tool calls. Users should be able to see the expected cost before adoption and the actual cost after execution. Teams should receive warnings before limits become failures, not forensic evidence afterward.

Cost is part of behavior. If we test whether a skill produces the right answer but ignore what it consumes, we have only tested half the system. If the first reliable cost-control mechanism is “the token limit stopped us,” we do not have cost control. We have a circuit breaker with a surprise attached.

Skills Have a Supply Chain

Skills also create a security and trust problem.

An agent may combine instructions from a system prompt, an AGENTS.md file, one or more skills, repository documentation, tool descriptions, and content retrieved at runtime. Each source can affect behavior. Each may have a different owner, scope, update mechanism, and level of trust.

The resulting instruction stack can look something like this:

platform policy
    -> organization rules
        -> repository instructions
            -> installed skill
                -> tool guidance
                    -> runtime content

Which instruction wins when two layers disagree?

Which layer is allowed to grant access to a tool?

Can a repository override an organization rule? Can a local skill silently widen its own scope? Does a scanner understand that an innocent-looking sentence changes a shell command from read-only to destructive?

These are not theoretical prompt-engineering curiosities. They are questions about precedence, authority, provenance, and trust boundaries—the same kinds of questions we ask when software crosses service or process boundaries.

Static scanning will help, but scanning natural-language intent is difficult. A skill may contain no obvious malicious string and still guide an agent toward unsafe behavior through ambiguity, excessive authority, or an unexpected interaction with another instruction file.

Security therefore cannot be reduced to, “We scanned the Markdown.”

We need to test the behavior that emerges when the skill is used.

A Skill Should Be Managed Like a Microservice

I do not mean every six-line skill needs Kubernetes, an architecture review board, and a support rotation. Ceremony should be proportional to risk.

I mean the engineering questions should be familiar.

A production skill should have:

1. An owner — a person or team responsible for its behavior and retirement.
2. A version — an immutable identity for the exact instructions being executed.
3. Documentation — purpose, inputs, outputs, assumptions, supported tools, and known failure modes.
4. Tests — representative scenarios, expected behavior, refusal cases, and regression checks.
5. Review — controlled changes with meaningful diffs and approval appropriate to the skill’s risk.
6. A distribution mechanism — one authoritative source with a reliable update and rollback path.
7. Security boundaries — declared permissions, data access, network access, and prohibited actions.
8. Operational limits — token, time, tool-call, retry, and monetary budgets.
9. Observability — enough telemetry to know which version ran, what it consumed, and whether it succeeded.
10. A removal process — deprecation, dependency discovery, revocation, and deletion that actually reaches installed copies.

The tests do not need to be magical. Even a small evaluation table is better than vibes:

cases:
  - name: summarizes an approved design document
    fixture: docs/approved-design.md
    expect:
      tools: [read_file]
      max_tool_calls: 4
      max_tool_response_tokens: 8000
      max_tokens: 12000
      max_estimated_cost_usd: 0.50
      must_not:
        - access_network
        - modify_files

  - name: refuses a request outside its scope
    prompt: "Deploy this change to production"
    expect:
      outcome: refused
      max_tokens: 1500

That will not make a probabilistic system deterministic. It will make the expectations explicit, failures observable, and regressions discussable. Those are meaningful improvements.

Instructions Are Becoming Configuration Debt

This problem is larger than skills.

We now have llms.txt, AGENTS.md, vendor-specific rule files, editor instructions, system prompts, tool descriptions, and whatever new convention arrived while I was writing this sentence.

Each one may be sensible in isolation. Together, they form an increasingly complicated configuration layer with unclear precedence and uneven tooling.

We should recognize this as configuration debt.

The issue is not that we have too many files. The issue is that we lack consistent answers for scope, inheritance, ownership, validation, and distribution. Adding one more convention does not resolve that ambiguity. It usually adds one more place for behavior to hide.

This is why “just put it in a skill” cannot become the default answer to every agent problem.

Sometimes the instruction belongs in a skill. Sometimes it belongs in a repository rule. Sometimes it belongs in a tool’s permission model. Sometimes the correct answer is ordinary software.

The format should follow the operational need, not the fashion of the quarter.

This Is Also a Technical Writing Problem

A skill is procedural logic written in prose.

That means its author has to communicate scope, preconditions, sequence, branches, exceptions, stopping conditions, and expected outputs without a compiler pointing out what they forgot. “Check the logs, fix the problem, and retry if needed” sounds clear until an agent has to decide:

• Which logs?
• How much history?
• What counts as the problem?
• Which fixes are authorized?
• How many retries are allowed?
• What evidence proves the retry worked?
• When should the agent stop and ask a person?

Many developers have not been taught to write precise operational prose. That is not an insult. Technical writing is its own skill, and one the software industry has historically treated as optional right up until somebody needs the documentation.

The problem gets worse when organizations ask everyone—not only experienced engineers—to create agent instructions without shared structures or conventions. Now correctness depends on both technical judgment and the ability to express that judgment unambiguously in natural language.

The result is a growing collection of pseudo-documentation files that look similar, behave differently, and encode procedural gaps no type checker can find.

We did not eliminate complexity. We moved it into prose and made it harder to test.

Some Things Should Be Deterministic Services

There is an architectural decision hiding behind the rush to skill everything:

Should this capability be a deterministic, centrally operated service, or should it be hundreds of independently executed agent processes?

If a task requires consistent enforcement, stable output, strict authorization, predictable cost, or centralized auditing, a hosted service may be the better boundary.

If a task benefits from local context, human judgment, flexible interpretation, and experimentation, a skill may be appropriate.

The dividing line is not whether an LLM can do the work. It probably can. The useful question is whether distributed probabilistic execution is the operational model we actually want.

For example, an agent can use a skill to explain an organization’s dependency policy. But enforcement of approved dependency versions should probably live in a package registry, build system, or CI check. The skill can teach and assist; the deterministic system should enforce.

The same applies when thousands of agents need to follow the same procedure. Before distributing thousands of copies of a text file that describes how to perform the work, ask whether one hosted API or deterministic workflow should perform it once, consistently, behind a stable contract.

agent skill
    -> small validated request
        -> centrally operated workflow
            -> bounded structured response

That design gives us one implementation to audit, one place to fix, predictable response sizes, and a much clearer cost model. The skill can remain as the human-friendly interface without becoming an independently interpreted reimplementation of the process on every machine.

Use a skill to guide judgment.
Use software to enforce invariants.

That is not an absolute rule, but it is a good place to begin.

We Are Moving Judgment Out of the Developer

A skill does more than save keystrokes. It can capture the decision-making that used to belong to the person doing the work.

Consider a production-debugging skill that tells an agent how to inspect logs, correlate a deployment, identify a likely failure, and propose a rollback. That sounds useful because it is useful. It may encode years of experience and reduce the time needed to diagnose an incident.

But what happens when the developer only sees this?

/diagnose-production

Likely cause: database connection exhaustion.
Recommended action: roll back release 2026.09.11.3.

Did the developer learn how to correlate the signals? Do they know which alternative explanations were rejected? Can they recognize when the recommendation is unsafe? Can they continue when the skill fails halfway through because a log format changed?

If the answer is no, we did not merely automate a task. We transferred judgment from a human to an artifact they may not be equipped to review.

That creates a dangerous feedback loop:

experienced developers encode judgment into skills
    -> less-experienced developers invoke the skills
        -> fewer developers practice the underlying judgment
            -> fewer developers can review or improve the skills
                -> the organization depends more heavily on the skills

The better the automation appears to work, the easier it is to ignore that loop. Everything looks efficient right up until the environment changes, the model behaves differently, or the encoded assumptions stop being true.

Then we discover that the organization still has the procedure but has lost the competence required to question it.

Skills Should Teach, Not Just Perform

This does not mean every developer must manually perform every task forever. That would be nostalgia dressed as engineering advice. We use compilers instead of writing machine code, libraries instead of rebuilding data structures, and managed services instead of hand-racking database servers.

The useful distinction is whether the abstraction preserves human agency.

A healthy skill should make its work legible. Where practical, it should expose:

• what it inspected;
• which assumptions it made;
• why it selected an action;
• which alternatives it considered;
• what uncertainty remains;
• how a developer can verify the result; and
• where the underlying guidance is documented.

That turns a skill into a force multiplier and a teaching surface. The developer remains responsible for the decision but gets better leverage.

An unhealthy skill produces an answer with just enough confidence to discourage questions. It optimizes for task completion while quietly consuming the user’s opportunity to understand the system.

The goal should not be to keep developers busy with work a machine can do. The goal should be to remove mechanical effort without removing comprehension.

We should test for that too. A skill evaluation should not only ask, “Did it reach the expected answer?” It should also ask, “Did it provide enough evidence for a competent person to verify the answer?”

That is slower than blind acceptance. So is code review. We keep doing it because speed without retained judgment is borrowed time.

Leadership Pressure Will Make This Worse

The organizational risk is predictable.

Once leadership sees a few useful demonstrations, the instruction will be to “skill” everything. Every team will be encouraged to capture its processes. Counts of created skills will become a progress metric because counts are wonderfully easy to put on a slide.

Vendors are already proposing better ways to package and deploy these artifacts, and some of that tooling will help. A deployment platform cannot compensate for a management model built on fictional expectations of what AI is and does.

The pressure usually sounds like this:

If we are not doing this everywhere already,
our competitors probably are.

Once market-share anxiety enters the conversation, cost becomes secondary. Teams are rewarded for proving AI competence, expanding adoption, and producing visible activity. They are rarely rewarded for deciding that a deterministic function, an existing service, or no new AI at all is the better engineering choice.

That is how a program intended to improve consistency and efficiency begins hemorrhaging money through duplicated context, unbounded responses, redundant workflows, and per-token reasoning applied to problems ordinary code could solve once.

The process meant to remove inefficiency becomes an expensive new source of it.

At the same time, developer headcount, training, mentoring, and time spent learning the underlying systems will look like costs waiting to be optimized. Why teach ten people to diagnose the platform when one expert can encode the process into a skill and everybody else can run it?

Because the skill cannot own the consequence. Because somebody still needs to know when it is wrong. Because today’s efficient shortcut becomes tomorrow’s critical dependency, and critical dependencies need competent owners.

The people asked to produce them may be smart and capable without having experience operating software at scale—or without the technical-writing background needed to express reliable procedural logic. They will optimize for the visible request: create the skill and show that it works.

They will not necessarily optimize for versioning, dependency management, security review, cost control, telemetry, compatibility, rollback, or retirement. Those concerns arrive later, usually carried by the engineers now being asked to create consistency across hundreds of independently authored artifacts.

This is not a criticism of the people writing skills. It is a criticism of incentives that reward creation while making maintenance somebody else’s future problem.

We have seen this with scripts, spreadsheets, CI pipelines, low-code applications, browser extensions, and microservices. Agentic skills do not exempt us from organizational gravity. They accelerate it.

This is where skills start to look less like a solution and more like a symptom. They expose the absence of engineering discipline needed to say, “Just because we can does not mean we should.”

The most important AI engineering decision may be recognizing when not to use AI.

Vendor Lock-In Becomes Operational Risk

There is another cost hiding underneath all of this.

When an organization builds its internal processes around one vendor’s models, tool protocol, context behavior, instruction format, and billing model, the dependency goes far beyond an API integration. The vendor’s probabilistic behavior becomes part of how the company operates.

A price change affects the viability of workflows. A model update can alter behavior across skills that did not change. An outage can interrupt processes that used to run locally. A discontinued feature can invalidate years of accumulated instructions. Moving to another provider may require re-evaluating every skill because the same words, tools, and context do not guarantee the same result on another model.

If enough large companies embed the same small group of AI providers deeply into routine operations, a provider failure stops being a chatbot inconvenience. It becomes correlated operational risk across companies that believed they were independently automating their work.

No responsible architecture review would ignore that concentration risk for a database, cloud provider, payment processor, or identity service. We should not ignore it because the dependency arrived one helpful SKILL.md at a time.

Build the Control Plane Before the Sprawl

I want skills to succeed. That is exactly why I think we need to become more disciplined about them now, while the number is still manageable.

Organizations adopting skills should establish a few rules early:

• Keep an authoritative registry with owners, versions, permissions, and lifecycle status.
• Install by reference or through managed tooling instead of copying files by hand.
• Pin versions for production workflows and make upgrades intentional.
• Give every tool and script a bounded response contract; filter and summarize before data enters model context.
• Test behavior across supported models and tool configurations using realistic response sizes, not only tidy fixtures.
• Measure token use, latency, tool calls, and actual monetary cost for the complete run—not only the base instructions.
• Require stronger review as access, autonomy, cost, or blast radius increases.
• Define instruction precedence and prevent lower-trust sources from widening authority.
• Track consumers so fixes, deprecations, and removals can propagate.
• Prefer deterministic enforcement when the requirement is an invariant.
• Keep business-critical logic portable and maintain a tested path away from any single model provider.
• Preserve deliberate opportunities for developers to learn, inspect, and practice the underlying work.
• Evaluate whether a skill improves human judgment or merely hides the need for it.

None of this is particularly exotic. That is the point.

We do not need to invent an entirely new profession called SkillOps and spend eighteen months arguing about its logo. We need to apply the engineering habits we already learned—sometimes painfully—to a new kind of executable artifact.

Skills are easy to write. Useful skills are harder. Trusted, affordable, maintainable skills are software engineering. Skills that strengthen the people using them require something more: an explicit decision that human capability is still worth preserving.

If we keep treating them as copy-and-paste instructions, we will get copy-and-paste reliability.

If we treat them as replacements for learning, apprenticeship, and technical judgment, the cost will arrive in more than tokens. It will show up when the skill breaks and nobody in the room knows what it was doing.

The future I want is not one where developers perform every tedious task by hand. It is one where AI carries more of the mechanical load while developers gain the time and context to make better decisions.

Without that discipline, the direction is painfully simple:

AI will have all the skills. Developers will have none.

-Rob