My AI assistant called a "prefix" a "marker"

Notes from a day spent writing rules for a machine to follow.

For a couple of months now I've been building a library called Open Template Scaffolds. It holds templates for the tables behind common Access jobs, an inventory stocktake, a lending library catalog, and an audit trail, among others. They also generate the code and forms that go with them.

Today was an especially challenging day.

The templates are written for Claude Code, who reads them and builds the artifacts they describe. Not you and not Access. Claude reads and executes the templates for you.

To use an OST template, you describe what you need in plain words. Your AI finds and reads the matching template (if it has one) along with a layer of standards files, and it hands back a design for you to approve. Then, if you tell it to, it builds the tables and supporting code and forms. There's a lot of flexibility built in, and that calls for a lot of interaction between your AI and the template.

That dialog between the user and the AI is where my problem lies.

My Target Audience

The primary people I have in mind are the ones who've outgrown Excel and are building real Access applications for the first time, with an AI assistant helping, and without a database designer.

These templates aren't documentation about how to use Access, nor are they pre-built artifacts you can copy and modify, like the templates inside Acces.

They're instructions your AI executes. What've I come to realize is that fact makes writing them a discipline quite unlike anything I've done before. There is a lot of pressure to get it right because every sentence I put in a template is a sentence Claude (or your AI) will act on, literally, without the benefit of knowing me or what I intended when I created the template. The AI can't stop and text me for clarification of the terms I used for a naming convention, or to specify which fields an audit table needs.

Today's session started out like many others, trying to write a sequence of questions for the AI to ask the user. It turned into a good illustration of how hard it is to communicate, especially when three different participants are involved in the conversation, and one is not a human, and another one is not even identified yet. I was trying to manage a conversation between myself, Claude Code, and a future end user who will someday run the template. It didn't go well.

The three words I got upset over

We were building a new piece — a short run of questions the assistant asks before it builds anything. This is prep work, setting up the environment to work the way the end user wants it to work.

Specifically, the first time a person runs the library, they have to decide what standards to use: mine or their own.

That, in turn, means I have to let the user know that a standards layer actually exists in the first place, and that they have a say in what's in it. OTS standards live in seven files, each serving a different purpose such as naming standards and table design standards. The library has to present them to the user one at a time, using plain language, and assuming little or no previous knowledge. That's because I can't predict who might use the library and how much experience they have. Little did I realize that insisting on "plain language" would lead me into a long, frustrating morning arguing with Claude over what was "plain" and what was "not plain". Arguing with AI is a special kind of torture, by the way. Do not recommend.

Claude drafted instructions to be given to new users. I read the first draft. And three times I was disappointed to find the same problem.

• Where the draft, talking about table names, should have said prefix, it said marker.
• Where it should have talked about queries and procedures, it said pieces.
• Where it should have said record, it said row.

That's almost as far as I got before I lost my cool.

As experienced Access developers, I'm sure you can see how record became row, but marker isn't a word anyone uses to refer to prefixes (or suffixes) on table and field names, whether they use them or not. Pieces came straight out of left field.

The painful thing is that those choices followed my "plain language" rule exactly.

Every one of those substitutions is wrong for my target audience, even for real newcomers, or maybe especially for new newcomers. Somebody sitting down to build tables in Access should already know the word prefix from other uses in other contexts. It's more than likely they have seen tbl on the front of a table name. Even if they haven't, calling it a marker doesn't lower the barrier. Just the opposite, it raises one, because now they have to work out whether a marker is the same thing they already know as prefix, a new term for something that other Access developers use, or even some new concept the library invented to confuse everyone.

I changed all three in the draft and handed it back. Then I did something smart for a change. I asked Claude to explain why it had happened.

The logic path

The answer took about ten seconds to find, and it wasn't in the model. It was one line in a file I wrote three days earlier:

Where the plain name and the precise name compete, use the plain one.

That rule exists for a reason I still believe in. It came out of a live failure during a test of the audit logging template. Claude had given me two different names for one folder in consecutive sentences:

• "the path to open"
• "the library folder"

I was stumped. Swapping names like that plants a half-second of doubt about whether two things are one thing. At the time I told Claude that I'd rather insult someone with oversimple directions than mislead them with ambiguous directions. And Claude came up with the "plain name" rule to enforce that decision.

Chosing marker over prefix wasn't a lapse in Claude's judgment. It was compliance with my rule! I had written a tie-break rule, and the assistant applied it, exactly as written, three times in one document. It may well be that the rapid repetition of the same problem was what focused my attention on it. Kind of a silver lining in a cloud thing.

I learned something very useful at that point

I keep running into the same kind of thing with AI, and the explanation for it is the single most useful idea I've picked up from working this way:

AI output that looks inexplicable from a human point of view almost never is.

There is a logic path, and it's usually short. It only feels mystical or bull-headed because the cause is upstream and possibly in an unexpected place. It's in something you had your AI memorize days ago, in a different file, for a different reason. You probably even forgot about it. It's also a contributing reason an AI can hallucinate sometimes. The logic path is there somewhere; It just doesn't always match what a human would normally do.

A human colleague reading my plain language rule would probably still have chosen prefix over marker. Knowing that Access developers already know, or should know, the word prefix and how it applies, they'd realize the plain language rule shouldn't override common sense.

The rule's stated purpose ( which is: don't use a term that goes over the reader's head) simply doesn't apply here.

An AI assistant can't change the rules on its own

The assistant can't make a call to ignore the rule. It has no way to know which words this particular reader already knows. So far as the AI was concerned, my rule was the only evidence available, and my rule said use the plain word. It chose the plainer word, marker.

Claude proposed a rule correction that would have been worse

After I'd called out the issue, things got really interesting. Having watched me overrule it three times in the same direction, Claude responded by proposing to invert the plain language rule across the whole library.

That's a perfectly sound inference. I made three corrections, all one way; therefore the rule points the wrong way. If a junior developer brought me that argument I could easily have said good catch.

Except it was wrong. My three edits weren't evidence about the rule. They were three instances of human judgment about how to apply the rule. The rule was doing its job — it exists to head off language that sails over a newcomer's head, and it does that everywhere in the library. Flipping the tie-break would have been exactly as wrong, but in the other direction, in a hundred places I wasn't looking at.

What I said to Claude at the time was this: You are right in all the logic you cite, except that you don't have the human capability of allowing for useful variance.

Why course correction is hard

This is the part I don't see discussed much. Claude Code and I weren't disagreeing about the words themselves. We were reading the same sentence with two different assumptions underneath, and neither of us had stated the assumption upfront.

When I write a rule, I often read it as a strong default with room in it. Of course there can be exceptions to most rules. That's what judgment is for. My job as the Project Manager is to provide judgement. It's in the job description.

In reality it's seldom the case that a rule can be enforced without at least one exception. And there is even an exception to that rule. Some rules don't have exceptions. (You may have to read that paragraph twice. I did when I wrote it.)

When Claude Code, or any AI really, reads that same sentence, it's a specification. It applies uniformly. That isn't a defect; it's the property that makes the whole thing work. Ambiguity in a rule an agent executes doesn't produce nuance. It produces drift.

That means the obvious fix is not possible. Soften the wording to admit judgment ("generally," "unless it's clearer not to", "for most cases") and you get an unenforcable rule. That creates inconsistency not the nuance you want.

Fool me once, that's on you, fool me twice, that's on me

This lesson landed quickly because we'd already learned it the hard way, with a single word earlier in the project. I've blogged about this one before in fact. I kept describing one of several offered choices as "the default." In my mind that meant the one we'd point at first. As I saw it, the template would still ask if you wanted "the default." However, to something like an AI reading the file in order to act, it means what happens when nobody chooses. Claude didn't bother to ask the question because it already had the default!

I told Claude at the time that when I called it the default, I laid a trap for us. The library doesn't use the word anymore. It says "preferred choice," and it says in writing that a preferred choice becomes the answer only when the person declines to choose.

Where we landed

We didn't need a wording change. We needed a division of labor, which I'd put like this:

I have to write rules the AI assistant can enforce. However, given the proper justification, I can override them. That's where my human judgement comes in.

What makes it workable in practice is on the assistant's side. In fact, it's the sentence I'd hand to anyone doing this kind of work. Share it with your AI:

An override by the human is an event to be evaluated, not evidence about the rule.

The AI needs to be told that it can't generalize from one or even two or three instances without confirming what the human meant . Don't automatically propose amending a rule because it got overridden once or twice. Don't hedge the next draft toward what the override implied. Keep following it; let the human override it without panicking.

Do raise a question about the deviation, though. Hold the human accountable for following the rule or for defending a deviation.

Actually, I decided not to publish my ownright override rules as part of the library itself. There's no sense encoding a rule I can't enforce and don't want enforced. The override lives on in the conversation and in the artifact, not in the text of a rule. Carve-outs accumulated into a rule are how it stops being a rule. It's part of the contract between Claude and me that I can override my own rules, not between Claude and the template library.

My own half of the bargain took a while to become clear:

• Don't anthropomorphize
• Don't criticize AI for failing to behave like a person.

When some output looks bull-headed or obstinate, the productive question isn't why in the heck did you do that. The right question is what did the written instruction that produced this result actually say.

Reading it that way fixed this whole episode in one move. It also means my criticism can stay blunt. Naming a behavior is useful. Guessing at a ulterior motive behind it isn't, because there isn't one.

One more example

Same day, different sentence, and this time the assistant's draft was too plain in a way that made it false.

Part of our explanation of naming conventions is an explanation of why you never name a field Date or Name. The draft said the database "gets confused."

That's not right. Software doesn't "get confused". It's not human any more than the AI is. So I cut that comment from the 1st draft. Almost immediately, I corrected myself because I should have replaced it, not removed it. That explanation was doing a job nothing else was doing.

The replacement we came up with is better than the original, because "confused" is the wrong adjective. Access is not confused. It doesn't pick badly between two meanings. It already uses reserved words, and it has no way to tell that you meant your field not the reserved word. So it hands back the thing it already knows which can cause errors or other unexpected behavior.

There was a poorly thought out rule behind that one too, adopted the day before after a small wording fix quietly deleted the only place in an entire build where a user could have learned the standards layer existed. We had to put it back in.

Our new rule was that every proposed fix now has to say what it removes, not only what it adds. The question that generates it is this: what was this text doing that nothing else does? In other words, the explanation "it gets confused" needs to be replaced with an accurate description of the harm using a reserved word can cause.

The meta point

Thirty-odd years of Access work, and I had never thought through many of the assumptions and implications about naming things. I'd never had to hand it to a reader who would follow it exactly. Writing out rules for the AI as I'd applied them by feel turned out to have unstated conditions inside them.

The plain-name rule had one.

The word "default" had two meanings.

"It gets confused" is a picture I have painted in conversations with other developers for twenty years, knowing I was using a metaphor, not an actual description of what was happening inside the database.

That's the real experience of working with an AI on something hard. It isn't Claude being brilliant, and it isn't Claude being wrong. It's the steady, slightly uncomfortable business of finding out what your own instructions actually said.

If you want to look at it

Open Template Scaffolds is public and free: github.com/Grover-Park-Consulting/open-template-scaffolds. The front page has a "try it out" path that takes about fifteen minutes and installs nothing — download the folder, point Claude at it, describe the tables you want, approve what comes back.

As this blog post should make clear OTS Is a work in progress. We're well on our way, but I have a lot left to do for sure.

In fact, if you are interested, the part I'd point you at first isn't the templates. It's the standards layer: a handful of plain files (7 of them currently) covering naming, audit columns, error handling, and the rest, sitting alongside the templates rather than inside them. The thing is that, when you use the library, you can read them, edit them, or throw them out and drop in your own conventions. Every template in the library would then build to your rules instead of mine. That separation is the whole idea. It's also why the rules I spent today arguing with Claude about are text files in the open, where you can see what they say and decide whether you agree.

It's early. I'd rather hear where it breaks than where it shines.

Claude reluctantly agreed to assist in the writing of this article.