AI coding tools make it very easy to begin.
That is the point. Claude Code, Codex, Cursor, and similar tools remove a lot of the friction between a bug and a possible fix. You describe the problem, the agent reads the repo, proposes a patch, runs tests, explains what broke, and tries again.
The part I keep noticing is that most sessions do not fail because the first prompt was bad.
They fail because there was no exit rule.
Without an exit rule, every answer that is almost right becomes an invitation to spend more context.
One more retry.
One more file search.
One more explanation.
One more patch for the patch.
One more refactor while the agent is already there.
Each request feels reasonable on its own. The whole session can still drift into a slow, expensive loop.
A useful AI coding prompt should define when to stop
The prompt I want to write more often is not just:
"Fix this bug."
It is closer to:
"Find the smallest fix for this bug. Touch the fewest files possible. If the cause is not clear after inspecting the obvious files, stop and tell me what you need next."
That last sentence matters.
It gives the session a boundary.
AI coding agents are helpful because they keep momentum. But momentum is not always progress. If the model is guessing, searching wider, or making the diff larger to recover from uncertainty, I want it to stop before the session becomes a context sink.
The exit rule turns vague productivity into a concrete check.
The third similar prompt is usually the warning sign
My personal warning sign is the third similar prompt.
If I have asked some version of the same thing three times, the problem is probably no longer "the model needs one more chance."
It is usually one of these:
- I gave the model the wrong context
- The task is too broad
- The failing case is not written down
- The model is solving the symptom, not the cause
- I should read the code myself for five minutes
That is not anti-AI. It is just workflow hygiene.
A good human pair programmer would pause at that point and ask what we are actually trying to prove. An agent will often keep going if the interface keeps inviting another request.
So the user has to create the pause.
Usage visibility makes the pause easier
This is one reason I built TokenBar as a Mac menu bar app.
I wanted AI usage visibility close to the moment where the next decision happens. Not in a provider dashboard after the session is over. Not in a monthly receipt. Not hidden until a reset window becomes painful.
A small live signal changes the question from:
"How much did that cost?"
To:
"Is the next prompt still worth it?"
That is a better question because it arrives while you can still change behavior.
If I can see usage climbing while the quality of answers is not improving, I am more likely to stop, write the failing test, narrow the prompt, or switch from agent mode to manual inspection.
The goal is not to make developers paranoid about tokens.
The goal is to stop treating every retry like it is free just because the text box is still open.
The boring rule I am trying to follow
Before starting an AI coding session, define one of these:
- the smallest acceptable diff
- the maximum number of files to touch
- the point where the agent should stop and ask
- the test or output that proves the fix worked
- the number of retries before I switch tactics
That is it.
It does not need a giant process. It just needs a boundary.
AI coding gets more useful when the session has a shape. A prompt starts the work. An exit rule protects the work from turning into a loop.
TokenBar is the small Mac menu bar utility I built to make that live usage signal easier to notice while coding with AI. It is free to try, and TokenBar Pro is $15 lifetime: https://tokenbar.site/
If your AI coding sessions keep getting bigger than the bug that started them, try adding the exit rule before the first prompt.
Top comments (0)