I stopped telling ChatGPT to 'fix it.' Here's the 4-part prompt I use instead.

A developer created a structured prompting method called C.O.R.E. (Context, Objective, Rules, Expected output) to improve results from AI coding assistants like ChatGPT. The method involves specifying language and framework versions, a single concrete objective, guardrails to prevent hallucinations, and a desired output format. The developer reports that this approach yields more reliable code than vague prompts like 'fix it.'

For about a year I used AI to code like a slot machine. Paste a wall of code. Type "fix it" or "make this better." Pull the lever. Sometimes I won. Usually I got a confident answer that solved the thing I asked about and quietly broke two things I didn't. I assumed the problem was the model. So I switched models. Same slot machine, nicer graphics. The problem wasn't the model. It was that I was giving it almost nothing to work with and expecting it to read my mind. Once I started prompting with a bit of structure, the difference was bigger than any model upgrade I'd ever seen. Here's the structure. I call it C.O.R.E. , because I needed something I could actually remember at 11pm. The AI doesn't know what you know. It doesn't know your language version, your framework, or what the code is even supposed to do. If you don't tell it, it guesses — and a confident guess is exactly what produces code that looks right and isn't. So before anything else: language and framework with the version , and one sentence on what this thing does. "I'm working in Python 3.11 with FastAPI. This endpoint returns a user's recent orders." That one line removes about half the wrong answers before they happen. "Improve this" is not an objective. The AI has no idea what "better" means to you — faster? shorter? safer? — so it picks one at random. Give it one concrete target : "Make this function return the orders sorted by date, newest first, without changing its signature." One task, stated like you'd state it to a junior dev who's about to touch your codebase. This is the part almost everyone skips, and it's the one that saves you. Rules are your guardrails: That last rule alone killed most of my hallucination problems. Left to fill a gap, the model invents. Told to ask, it asks. Tell it what good looks like, or you'll get whatever it feels like — usually a 600-word essay when you wanted three lines. "Show me only the changed lines, then a two-sentence explanation." Diff vs. full file. Explanation first or code first. A specific format. Just say it. Here's the before-and-after that made me a believer. Before: here's my function it's slow fix it 200 lines pasted After: I'm working in Python 3.11. This function deduplicates a list of user records before we save them. Objective: it's slow on large inputs — make it faster without changing what it returns. Rules: no external libraries, keep it readable, and tell me whythe current version is slow before you change it.Output: explanation first, then the rewritten function. The "before" gets you a random rewrite. The "after" gets you an explanation of why it was O n² , a fix, and code you actually understand well enough to defend in a code review. Same model. Different result entirely. Once C.O.R.E. clicks, you start aiming it at everything: Debugging: "Before changing anything, explain in plain language what's causing this error and where. Then give me the smallest fix for the root cause, not the symptom." Learning: "Explain this code as if I'm a first-year student, using the actual variable names. Then list the 3 concepts I'd need to write it myself." — this turns the AI from an answer machine into a tutor. Refactoring: "Refactor for readability. Keep the exact same behavior and signatures. Explain each change in one line." The "same behavior + signatures" clause is what lets you trust the result. When an answer disappoints me now, I don't re-roll and pray. I ask which letter I skipped: Add the missing piece, send it again. It's almost never the model. You don't need a prompt library with 500 entries. You need one structure you can recall from memory and adapt on the fly. Context, Objective, Rules, Expected output. That's it. I'm a student, not a guru — I just got tired of fighting the slot machine. If this saves you some of the time it cost me to figure out, it did its job. I put C.O.R.E. and a copy-paste master template on a single free cheatsheet — grab it here if you want it on hand while you work. Everything you need is already in this post, though — no catch.