Skills don't solve problems

Don't Repeat Yourself is the first principle most developers learn and the last one they manage to keep. Pull the duplicated logic into one function, name it, call it from both places. The reason is not tidiness. It is that a fact written down twice will eventually be written down differently, and then you have two facts and a bug.

We have spent two years pointing AI at our code and somehow never pointed this principle at the AI itself. Ask a model to write a deploy verifier on Monday and it writes one. Ask it for the same thing on Thursday, in a new session, and it writes a different one. Ask a third time and you get a third. Each is plausible, none is the one you reviewed and trusted, and every one of them is a fresh roll of the dice on a problem you already solved. The model is the most prolific violator of DRY ever shipped, and it breaks the rule against its own output, where you cannot see it.

A skill is a wish

The current vocabulary for this is "skills," and skills are good. A skill is a short instruction that steers a model toward the right behavior: validate the input first, prefer the repository pattern, never write a secret into an env file. I use them. They ship with this idea attached. But it is worth being precise about what a skill is, because the precision is the whole point.

A skill is a prompt. A prompt is a wish. It raises the probability of the behavior you want, and on a good model the probability is high, but it is still a probability, and you find out which side of it you landed on after the work is done. "Validate the prompt before you send it" is a wish. A script that reads the prompt, checks it against fixed rules, and exits with a failure code when the prompt is doomed is a guarantee. The skill describes the intention. The script is the intention, executed the same way every time, auditable after the fact, impossible to talk out of.

So skills do not solve problems. Skills backed by a deterministic solution solve problems. The skill is the part that knows when to reach for the tool and how to read the result. The tool is the part that actually does the thing, correctly, on the hundredth call exactly as on the first. Separate them and you get the worst of it: a confident instruction with nothing underneath, a model that has been told to be careful and is now improvising carefulness. Put them together and the model stops being the thing that solves the problem and becomes the thing that recognizes the problem has already been solved.

What you actually keep

The library is not exotic. It is the set of things you have already gotten right and would rather not get wrong again, written down once, each as a plain file with a few lines of front matter saying what it is and when to use it:

• Scripts. The deploy verifier, the find-and-replace across a tree, the JSON patch, the branch sweeper. Parameterized, reviewed once, run forever.
• Snippets. The shape of a FastAPI endpoint with the stats block, the Polly retry policy registration, the optimistic-update mutation. The pattern you keep typing, kept once.
• Design patterns and the anti-patterns that shadow them. Not the textbook definition the model already knows, but your recorded outcome: this combination worked, that one we tried and rejected because we needed it to run offline. The cautionary entries matter most, because a model cannot infer a road you chose not to take.
• Commands. The exact rsync flags, the git worktree invocation, the one form of the command that does the thing without the footgun next to it.

Search runs two ways over all of it. Keyword and field filters for when you know what you want, and semantic search for when you only know what you mean. A small vector index sits over the catalog so "safely retry a flaky remote call" finds the retry-with-backoff entry whether or not you used those words. The files are the truth. The database is a cache the server rebuilds from the files whenever they change. You edit a file; the index follows. Nothing about it is precious.

Rote

I built the smallest honest version of this, stripped of anything private, and put it out under MIT so the idea travels without my own scripts attached. It is called Rote.

The striking part, once it is running, is how little there is. One SQLite file. A vector extension that loads into that same file. A few hundred lines of server. It holds no model, makes no outbound call, and needs no service to function. The semantic search runs against a small embedding model on the same machine, and if that is missing the catalog still lists and serves; only the ranking degrades. You can read the entire thing in an afternoon. That is not a limitation. It is the argument.

The savings do not come from anything clever. They come from not regenerating. The tokens a model spends rederiving a script it has effectively written a dozen times before, across a dozen sessions that cannot see each other, are pure loss, and each rederivation is a new chance to land on a subtly wrong version. Recall replaces all of that with a search and a path.

It exposes the same catalog four ways, because the point is that any agent can reach it: a terse command line built for token-cheap calls, a single-page browser view for humans, a Model Context Protocol server for the editors and desktop clients that speak it, and a plain OpenAPI surface for any function-calling model. Underneath all four is the one SQLite file. It is, with no hedging, just retrieval-augmented generation. That is the part worth saying out loud. RAG got sold as a heavyweight platform play, and it can be one, but the principle underneath is small enough to enforce a software-engineering discipline with a few hundred lines, and the discipline is the valuable part. Build the tool once. Recall it forever. Stop letting the model reinvent the wheel and then bill you for the lathe.

Delegates, and where this meets the codec web

There is a second move the library makes possible, and it connects to the architecture I have been describing across several pieces here. Once you have a registry of deterministic capabilities, some of those capabilities are not scripts. They are other machines.

A delegate, in Rote, is a piece of compute you own that can take a job the frontier model should not be paying attention to: summarizing a log, skimming a document, classifying a ticket, embedding a corpus. The registry tracks which delegate is good at what, by recorded success rate, so an agent can ask "what should handle this bulk job" and hand it off instead of spending an expensive model's tokens on work that needs no genius. This is the same division of labor I described in The Stenographic Mediator: a lean coordinator in the cloud, and the expensive, repetitive, latency-tolerant bulk running on hardware an organization already owns. The cloud's job shrinks from metering every word to coordinating a few. A switchboard, not a tollbooth.

The library is what makes the edge of that switchboard real. Two of its deterministic tools do work a cloud used to charge for, on the device that is already there. The first is a doomed-prompt pre-check: a local screen that rejects the prompts a remote call would waste money on, the empty ones, the oversized ones, the malformed ones, before they ever leave the machine. In The envelope tax I put a number on that waste, tens of millions a year in GPU time spent on prompts that were broken before they were sent, prompts a client-side check should have caught. A deterministic pre-check is that check. It is the kind of safety and format screen a token-native protocol like Codec pushes out to the edge precisely because the edge can run it for free.

The second is the vault. When a job genuinely needs a secret, an API token to read the record it is classifying, the secret is injected into the local tool call and the remote model is handed a reference to it by name. The bytes stay on the machine. The model that never needed to see the secret never sees it. This is the same logic as the pre-check, applied to credentials instead of malformed input: the cheap, correct, deterministic step happens on hardware you own, and only the work that genuinely requires the frontier model crosses the wire to reach it.

None of this is a bet that cloud inference gets cheaper. The economics in Five Siphons run the other way, and the local-hardware wave that makes the alternative practical is the subject of Arming both sides. The library is the unglamorous floor under all of it: a place to keep the deterministic things, so the model recalls them instead of regenerating them, and so the bulk work routes to the cheapest machine that can do it correctly.

The asset you are throwing away

Here is the part that changes how the whole thing looks. Every time a model solves a real problem for you, it produces something of value: a working script, a correct snippet, a pattern that holds under load. That artifact is worth money, because you paid to generate it and it does a job. And almost everyone throws it away. The session closes, the artifact scrolls out of context, the tab shuts, and the next time you need the same thing you pay the model to conjure it again from nothing. You are buying the same asset over and over and discarding it between purchases.

A library is where you stop doing that. You capture what the model made, review it once, and keep it. The value the model created stops evaporating at the end of the session and starts accumulating on your side of the ledger. Each thing it builds for you becomes a durable asset you own, not a recurring charge you absorb. That is the real trade. You give up the fiction that the model will get it right again next time, and in exchange you get a result you reviewed once, can trust on every call, and never pay to make again.

It even changes what kind of spending this is. Regenerating a solved problem is an operating expense, paid in full every single time, forever. Writing it down once is closer to a capital one: the asset sits there and pays out on every future call for free. And because the load-bearing parts are deterministic files you can read, you can audit exactly what you own, which is something a probability will never let you do.

There is no dashboard to buy and no platform to adopt. There is a small library, the habit of keeping what the model gets right instead of letting it disappear, and a model relieved of the job of pretending it has never seen this problem before. Skills point the model at the right answer. Deterministic tools are the right answer, and once one is written down it is yours. Let the model do what it is genuinely good at, which is knowing which tool to reach for, and keep everything it builds for you on the way.

---

William Dunn is the founder of Quasarke, a software development consultancy, and has spent a decade building company architectures. Rote is open source under the MIT license.