0. The mind between human and AI — Working with a process that has no desire

What I think of AI is a process with a very capable brain but lacking domain knowledge — like a person without desire. Because of that, in order to use AI to perform the work I want done, the important thing is to convey to AI exactly what I want. Just because one or two ideas are presented abstractly the way a person would, AI does not think like a person, and it will not carry the work forward in the form the person expects.

The easiest trap a person using AI can fall into is exactly this point. AI owns an extraordinarily capable brain for computation and reasoning, but if the exact input values and the goal are not provided, it may produce results different from the operator's intent. This gap exists because the data AI carries when it begins computation and reasoning is different from the expectations the operator holds in their head. Therefore, in order to obtain the results the operator wants through AI, the most important thing is to understand AI's operating principles well, and to make sure that the operator's thoughts are written down and passed on to AI without omission. A description so detailed that one almost asks "do I really have to explain and define even this?" is the only good way to keep AI from drifting off course.

For this reason, in the early days there were many lectures on prompting techniques and methods. Initially the entire conversation was prose. Originally the only lever the operator had was the next prompt. After that, automated processes such as skills and hooks gained popularity as a way to reduce the gap between AI and people. After that, the approach of controlling the path with a harness — keeping AI from straying off the targeted road — gained ground. All of these various ways to use AI efficiently are, in the end, what is needed to remove ambiguity within a limited memory by expressing what the operator wants as accurately as possible, and to capture the target precisely.

The four accreted layers

What I think the field has actually been doing for the last few years is accreting layers — not replacing them. Each layer leaves the earlier ones in place and adds one more lever for the operator to express intent. Below are the four, in the order they entered daily practice.

1. Persona — the standing role

The persona is the single system prompt that fixes who the collaborator is and how they default to acting. It is the layer the operator reaches for least often, but it shapes every session that runs after it. A persona says, in effect, "you are this kind of engineer, you write in this tone, your defaults look like this." Nothing else needs to repeat those decisions in every conversation, because they live one level up.

The mistake that comes up here is treating the persona as a wishlist. The temptation is to write "be careful, be thorough, be smart" — but those words push no work, because the AI has no measurable target to verify against. What actually moves is the role and the defaults: "senior software engineer with C/C++ background, Korean as the primary working language, terse status updates over verbose ones." Each phrase is a default the AI can adopt without further instruction. Covered in Part 2 — Persona design.

2. Skills and slash commands — collapsing repetition

The next thing the operator notices is that the same paragraphs keep getting typed. "Run the linter, then the build, then check there is no broken cross-ref, then report" appears every day. The fix is not to type it better — the fix is to name it. Once the procedure has a name like /verify or /session-end, the operator stops dictating the procedure and starts invoking the noun.

What this gives the operator is a vocabulary. Instead of writing a six-line instruction, they write one word, and the AI loads the procedure that has already been agreed on. The cost of "what does done look like today" drops to almost nothing. Covered in Part 4 — Skills and slash commands.

3. Hooks — letting the system remember

A skill still requires the operator to remember to invoke it. Hooks remove even that. A hook says "whenever the AI is about to output the word done, run /verify first." The operator does not type anything; the system fires the procedure on their behalf because they once said "this is what done means."

The shift is that responsibility moves from the operator's working memory into the harness configuration. The operator no longer has to remember to verify, because forgetting is no longer possible — the hook will fire whether the operator remembers or not. This is the layer that makes intent transmission durable: it survives tired Friday afternoons. Covered in Part 5 — Hooks and automation.

4. Harness — runtime rails

The fourth layer is the runtime itself — the rails that decide what the AI can and cannot do, regardless of what the persona requested or the hook attempted. Permission policies, sandboxing, file-write guards, branch protection on destructive operations — these are the layer below trust. A persona can ask the AI to be careful with rm -rf; a harness simply makes the call impossible without the operator pressing a button.

Verification loops, release gates, the Ralph loop — they all live at this layer. They are not asking the AI to behave well; they are arranging the environment so that misbehavior cannot ship. This is the layer where the operator's intent becomes physical, in the sense that the system enforces it whether the AI agrees or not.

Not because the new layer makes the old one obsolete, but rather because each layer addresses a different failure mode of the same gap. Prompting still happens inside a persona. Skills still get invoked by prompts. Hooks invoke skills. The harness fires hooks. The stack is cumulative, and the operator's mind is distributed across all four floors at once.

What "moving across without omission" looks like in practice

The accreted layers are abstract until they hit a real procedure. The clearest one to look at is /verify, because it shows the same intent expressed at two different layers and the gap each one closes.

The /verify case

What is /verify actually? It is a skill that runs a seven-step verification loop right before a "done" report — lint, build, type check, test, security, diff check, report sanity check. The operator can invoke it explicitly as a slash command, or a hook can auto-fire it just before the assistant outputs the word "done". Same procedure, two entry paths. Covered in Part 7 — Verification loops.

The distinction matters because the same procedure at two layers is doing two different jobs. The slash command lets the operator pull the procedure on demand — "verify this for me." The hook lets the system push the procedure on the operator's behalf — "do not let the AI report done while the build is broken." Both are needed: the first because some checks happen mid-flow, the second because the operator's memory is the part of the system that fails most often.

What the gap looks like without the hook

Without the hook, the gap shows up exactly where you would expect: the assistant reports "done" while the build is broken, because reporting done and running the build are two different actions and the operator's mind ("done means tests pass too") was never written down anywhere the assistant has to consult. With the hook, the procedure fires whether the assistant remembers or not. The operator's intent — "done means verified" — has moved out of their head and into a piece of machinery that runs without them.

Another way to see it: the session-end procedure that prepends a handoff note before pushing. Without the hook, every session ends with the operator hoping they wrote down what the next session needs. With the hook, the handoff exists because not writing it is no longer one of the possible outcomes. The mind has been moved across, not by writing more, but by changing the structure of the act so that the structure does the remembering.

Loading diagram…

The mind itself keeps changing

The reason all four layers are needed at once is that the operator's mind is not a fixed thing. It is a moving target. Different parts of the mind move at different speeds, and the layers are arranged to absorb that motion at the speed each part actually drifts.

The destination layer — the PRD

No matter how much AI advances and how much its performance improves, I believe it will be hard for AI to anticipate the operator's intent in advance and produce results the operator will be satisfied with. That is because the operator's desires, satisfaction, and goals keep changing. In the morning one might want to see the sea, but in the evening one might want to see the mountains.

Because the mind is a moving target, the discipline cannot be predict the operator. It has to be make the operator's current state cheap to read. That is why the PRD is treated as a single source of truth — not as a one-time spec but as a living statement that the operator updates whenever the destination changes. Covered in Part 10 — PRD as single source.

The method layer — persona and skills

What the PRD does for the destination, persona and skills do for the method. The operator updates the persona when they realize "actually, I prefer terse status updates over verbose ones." That update is then visible to every future session — the mind moved across, in a place where the next session can find it.

The two layers drift at different speeds and that is the point. The destination layer (PRD) moves when the what changes — a new feature, a new constraint, a deadline. The method layer (persona, skills) moves when the how changes — a tone preference, a new procedure, a workflow lesson learned the hard way. Keeping them separate means an update on one layer does not force a rewrite of the other.

What this series is not

Because this is the entry point of a 13-part series, it is worth saying what the series is not, so the rest is read at the right altitude.

This is not a prompt-engineering manual. The series will not teach how to phrase a request to maximize output quality, because that is a rapidly shifting tactic and the prompts that worked six months ago will not be the prompts that work six months from now. The series is about what survives that drift — the layers that keep working even as the prompt-level techniques change underneath them.

This is also not a recommendation of any one tool. The examples lean on a particular CLI because that is the workspace I happen to work in daily, but the layers — persona, skills, hooks, harness — exist in any serious agent runtime. The vocabulary travels even when the specific tool does not.

And this is not a guarantee that following the layers makes AI work the way the operator wants. The layers reduce the gap; they do not eliminate it. The mind keeps changing, and the work of keeping it written down keeps going.

Why this matters more for a senior developer

For a developer like myself who has worked as a software developer for a long time, today's AI technology is extraordinarily attractive. That is because, from the position of having handled a great many designs and architectures commercially, one can draw the big picture and delegate the necessary elements to AI to build the desired system in a short time. What previously had to be explained to each developer — with the work divided up, results combined, and the system made to run — can now be performed for the most part by an AI Agent. I think the change is not that AI replaces developers, but rather that a senior developer with a clear mental model can now ship a polished system with a very small team, because the intent transmission cost has collapsed.

If one composes the PRD and TRD well, builds the design, breaks down the concrete implementation plan along it into very small units, sets gates at each component, and lets a commercial release gate do the final check, it has become possible to develop a fairly polished system with a small team.

Where this series goes from here

The rest of this category walks each accreted layer one at a time, starting from why I gave the collaborator a name at all. The next part — Part 1 — Why Alice — is the personal version: where using Claude as a tool stopped working, and how persona, memory, skills, hooks, and verification gates accreted into a daily partner I now call Alice.