You asked for a bug fix. Your AI rewrote the whole function, renamed three variables, and added error handling you never requested. A prompt framework from r/PromptEngineering fixes this.
One developer, frustrated by ChatGPT constantly touching code it had no business touching, built a structured system called the CODE CRAFT PROTOCOL. It uses hard behavioral guards and named analytical modes to keep AI surgically focused on exactly what you asked. The problem it solves is not unique to any one model either. Claude, GPT-4, Gemini, they all have the same tendency to treat your edit request as an invitation to improve everything they can see.
The root cause is how these models are trained. They optimize for producing clean, functional-looking code. Nothing in their training tells them your project has a six-year-old naming convention that a junior dev will have to track down in three other files if you rename it. The model is just doing what it thinks is helpful. Without explicit guardrails, helpful keeps expanding until you are staring at a diff you did not ask for.
How It Works
Two layers run every session by default.
The first layer is four Hard Guards:
- 🔒 HC-1: Modify only the lines you explicitly target
- HC-2: Show every change as a BEFORE/AFTER block, nothing hidden
- HC-3: No full file output unless you ask for it
- HC-4: No refactors, style fixes, or optimizations you didn’t request
HC-1 is the core rule. It tells the model that scope is defined by you, not by what looks improvable to it. HC-2 makes every change visible and reviewable so nothing slips through inside a wall of output. HC-3 stops the model from returning a 400-line file when you asked it to fix one conditional. HC-4 is where most of the frustration lives. The model sees a slightly awkward variable name or a function it could make cleaner and rewrites it without being asked. This guard kills that behavior at the root.
The second layer is five named analytical modes. PROMETHEUS assesses scope and flags regression risk before anything gets touched. It is the planning step the model often skips, the part where it should be asking what else could break if this changes before it starts writing. SHERLOCK uses deductive elimination during bug hunts. Instead of guessing and iterating, it reasons from symptoms toward causes, ruling out explanations before landing on the most likely one. DAEDALUS handles syntax, memory layout, and execution correctness. It is the mode for low-level precision work where technical accuracy matters more than speed. HERMES explains complex logic, but only when complexity actually warrants it. You do not get a lecture on a three-line function. HERMES waits for the cases where a plain explanation actually earns its place.
LOKI stays off by default. You activate lateral thinking by typing LOKI_ACTIVATE. It does not turn on unless you call it. This matters because lateral, generative thinking is exactly what causes scope creep in normal sessions. By making it opt-in, you get creative problem-solving when you want it and disciplined precision the rest of the time.
The author’s reasoning for the mythology names: LLMs ground themselves to a personality better than to a plain behavioral description. Calling something SHERLOCK carries more reasoning signal than writing “use deductive logic” ever would. The model has absorbed everything ever written about Sherlock Holmes. It knows how that character thinks. Mapping a mode to that character gives the model a much richer behavioral anchor than any plain instruction. Ridiculous-sounding, but it works.
🔧 Where This Is Actually Useful
- Legacy codebases where one AI edit cascades into three broken things. If the code is ten years old and tightly coupled, a well-intentioned refactor can break imports, shift behavior in a module you did not open, and leave you debugging something unrelated for an hour.
- Any session where you need a targeted fix, not a cleanup of surrounding code. Surgical edits stay surgical when the model is not allowed to wander.
- Teams where multiple people use AI for edits and scope creep becomes a constant headache. When five engineers each have different instincts about what the AI should be allowed to touch, a shared protocol makes the output consistent regardless of who runs the session.
- Workflows where you need consistent, auditable BEFORE/AFTER output every single time. If you are reviewing AI changes in a pull request, seeing structured diffs rather than full-file rewrites cuts review time significantly.
Prompt of the Day
Paste the full CODE CRAFT PROTOCOL as your system prompt before any coding session. Most chat interfaces let you save a system prompt or custom instruction that loads automatically. Set it once and it applies to every conversation after that. If you want to test the concept without committing to the whole thing, pull out just the four Hard Guards and paste those before your next edit request. That alone will noticeably change how the model behaves. You can layer in the named modes once you have seen how the guards work in practice.
A useful test: take something you recently asked an AI to fix, run it again under the Hard Guards, and compare the output. The difference in scope tends to be immediately visible. The model stops volunteering improvements and starts executing what you actually asked.
The output will look noticeably different within one or two exchanges.
The Bottom Line
Most AI coding frustration is a boundary problem. The model rewrites what it shouldn’t because nobody told it not to. It is not being careless. It is being helpful in the only direction it knows, which is more. More error handling, more refactoring, more cleanup. A framework like this takes five minutes to set up and saves hours of undoing changes you never wanted. That time adds up fast if you use AI in your development workflow every day.
That is not a bad trade.
Programming prompt that I use
by u/DvorakUser82 in PromptEngineering