Learn

/ The name carried the method

Insight · Prompting

The name carried the method.

I gave the AI five words and pointed it at the repo. No checklist, no definition of done, no scope. The words named a discipline Dieter Rams put best, "less, but better," and the model already knew it cold. It came back with a full cleanup, because the name was the spec. A respected name is the densest prompt there is.

01

Five words, no spec.

The prompt was roughly this long. "What can you declutter here?" One verb, one place, and a method standing behind the verb.

I did not say what counted as clutter. I did not list the file types to check, or set a threshold for an unused dependency, or define when a task is stale enough to delete. I named a way of working and pointed it at a directory. The AI did the rest from there.

Behind the everyday word sat a particular discipline, the one Dieter Rams put best. Less, but better. Subtraction as a craft, with criteria, not a tidy-up. Remove until what remains earns its place, and stop before you take out something load-bearing. That is a real method with a real shape, and the AI had clearly read Rams many times over before it ever met my repo.

So the instruction was five words on the surface and a whole methodology underneath. I supplied the pointer. The shared culture supplied the procedure.

02

What it found.

The audit came back specific, and every item was the right kind of thing to subtract. Nothing load-bearing, all of it dead weight.

  • 38 unused npm packages. Leftovers from the starter kit the project was scaffolded with. Declared in the manifest, imported nowhere, shipped in every install.
  • One dead component. A file that nothing rendered and nothing imported. Present in the tree, absent from the running app.
  • One stale handoff file. A note written for a moment that had passed, kept around because deleting things feels riskier than leaving them.
  • Around 90 settled TODO lines. Tasks already done or quietly abandoned, still sitting in the list, still costing a half-second of doubt every time someone read past them.

Read that list back as a sentence and it is the method talking. Keep what earns its place. Remove what does not. Leave the structure standing. I never wrote those rules into the prompt. They arrived with the name, and the findings are what the name looks like applied to a working codebase.

A vaguer prompt would have produced a vaguer result. "Clean this up" invites a model to reformat whitespace and call it done. The named discipline told it what cleanup is for, so it went after the unused dependency and the dead file instead of the cosmetics.

03

A name is a compression of a method.

Not every name carries an instruction. The ones that do share three things, and all three have to be present.

The method has to be famous, so the model has read enough about it to reconstruct it. It has to be specific, so it resolves to one way of working rather than a vague mood. And it has to be procedural, so it tells you what to do and not only what to admire. Famous and specific and procedural. Miss any one and the name stops being executable.

A model trained on a wide slice of human writing has already absorbed these methods in depth. It has read the books, the critiques, the worked examples, the arguments about where each one stops applying. The name is the handle on all of that. You say the handle and the model unpacks the body of practice attached to it, the same way a colleague who knows the reference would.

There is a litmus test, and it is strict. Could a stranger who shares the culture execute the name with no follow-up question? Give a capable practitioner a famous design principle and a directory, and they would know what to do. Give them a vague aesthetic word and they would have to ask you what you meant. The name passes the test when it removes questions rather than raising them.

Anti-pattern

Invoking a name for its aura, not its method.

Dropping a famous name to sound serious, when the name points at a vibe rather than a procedure, gives the model nothing to execute. It fills the gap with an average of everything that name has ever touched. A name works as a prompt only when a stranger could act on it without asking you a single question.

Other names pass the test in other directions. One novelist's name means cut every sentence to the one true line. One style guide means omit needless words. One trumpeter's name means the value is in the notes you choose not to play. Each is a different procedure. Each is dense for the same reason. The method is famous, specific, and procedural, so the name alone is enough to run.

04

The same move the protocol makes.

This is not a new trick. It is the protocol's oldest habit, working one layer up from where it usually works.

The protocol exists because a fresh AI session knows nothing about your project. So you write the context down in files, and the model reads it back at the start of every session. Files give the AI your context. The repo, the decisions, the constraints, the state of the work. Nothing has to be re-explained, because the file already says it.

A famous name does the same job for method instead of context. The model already holds the method, learned from everything it read before it met you, so you do not write the procedure down. You name it, and the model loads it back the way it loads a file. One source is private and lives in your repo. The other is public and lives in the shared culture the model trained on. Both turn a long instruction into a short pointer at something already written.

Files give the AI your context. Names give the AI a method. Same move, different layer. Each one trades a long explanation for a short pointer at knowledge that already exists.

There is a reason this rhymes with how the protocol itself was found. The protocol was not designed up front. It was read back out of a working app's git history, the patterns that kept recurring, named in hindsight. A good name is the same kind of object. It is a method somebody already worked out, compressed down to the handful of moves that would not stop showing up, and given a label you can hand to a model.

05

How to use it.

The practical version is short. Before you write a long prompt, check whether someone famous already wrote it for you.

When you reach for a paragraph of instructions, stop and ask whether a known method already says the same thing in a word. If the discipline you want is famous, specific, and procedural, the name is a tighter prompt than anything you would type, and the model already holds the body of practice behind it. Name the method, point it at the work, and let it unpack.

When no such name exists, that is information too. It means the method is yours, not the culture's, and the model cannot read your mind any more than a new session can recall yesterday's decisions. So you do the protocol's other move. You write it down in a file, because a private method has to live in your repo to survive the next session. The two are the same instinct. Hand the model a pointer to knowledge that already exists, whether that knowledge is public and carried in a name, or private and carried in a file.

The through-line

Five words ran a full cleanup because four of them were a method the model already knew. That is the whole lesson, and it is the same one underneath every essay here. Good structure is recognised, not invented. The protocol writes your context into files so the model can read it back. A famous name does the same for a method, except someone already wrote it, and you only have to know whose name to say.