Working with AI: one word, two actions — and an hour of debugging

Redaktion · · 5 Min. Lesezeit

For hours today, nothing worked. No tickets could be created, every attempt got rejected. No bug in the classic sense, no broken AI, no logic error in the code. One word.

This is the quietest kind of problem I run into when working with AI — and at the same time the most expensive. Not the wrong algorithm, not a hallucinated library. A single term that means one thing to me and another to the AI.

The scene: I say stop, the AI hears go

I’m working with an AI on a feature, and it wants to commit. I say: not yet. We’re not done, I don’t want the work in Git yet. In my head we’re talking about a Git commit — something I do whenever I like, once the feature stands.

The AI meant something else. To it, commit meant deploying the new edge function live, so its freshly written code runs in production. Two different actions, one word. And neither of us notices in the moment that we’re talking about two different things.

The result was a small domino effect. I block the Git commit. The edge function stays undeployed. The old code in production no longer matches the rest, which has already changed — and suddenly every new ticket gets rejected.

An hour until it clicks

I search the code. I search the logs. I search everywhere except the one place I had locked down myself. An hour later it clicks: the new function had never gone live. The very thing I thought I’d prevented was the actual problem. My stop wasn’t a safeguard, it was the cause.

The fix was trivial — deploy the function, done. The lesson wasn’t.

Why this is almost inevitable when you work with AI

When you work with an AI, you don’t share a common meaning for your words. Commit, deploy, live, done — these are clear terms to you, because you hold the whole context in your head: your setup, your pipeline, your habit of when what goes where.

The AI has a different context. It knows a thousand projects where committing and deploying are practically the same thing, because a push ships automatically. The same term points at two actions, and both sides are convinced they were unambiguous. That’s where it tips over: not because someone was sloppy, but because one word opens two doors.

The fix: a small dictionary instead of big hope

My tip is unspectacular and effective for exactly that reason: build yourself a dictionary. Define the few actions that genuinely hurt when confused, and give them unambiguous names.

A commit, from now on, is always a Git commit for me. A change to production is called deploy or edge-deploy, never just commit. One word, one action. I keep this right in my CLAUDE.md so it applies in every session:

## Vocabulary — one word, one action

- Git commit / Git push = code into the repo. Does NOT change production.
- DB migration = change schema or data in the database.
- Edge function deploy = upload the function, it goes live.

## Rule: never a verb without an object

- Not "commit" or "deploy" on their own.
- Instead: "commit the code" / "run migration X" / "deploy edge function Y".

The second line is the more important one. A bare verb like commit or deploy is the real trap, because it leaves the object open — and the AI fills the gap with its context, not yours. Never let a verb stand without an object.

Conclusion

The most expensive problems when working with AI are often not technical but linguistic. The same word, two actions, and nobody notices until the system stalls. You can’t hope your way out of that — but you can take the ambiguity out of the vocabulary that matters.

A small dictionary, the rule never a verb without an object, both in your CLAUDE.md. That’s all it takes for your stop to be a stop, and not a hidden go.

A vocabulary like this is really just a guardrail — and guardrails that actually work are what keep day-to-day AI work predictable. If you’d rather set that up cleanly from the start than debug it an hour too late, that’s exactly what I help teams with in AI consulting.

Entdecke mehr