Picture a five hour night shift with nothing on the schedule and a laptop open on the desk. One engineering student is running the same test three times, just to see what breaks. That is where two years of real prompt engineering for coding work actually got built, not in a classroom.
A Reddit user posting as u/Fragrant-Cheek-4273 shared the whole breakdown in r/PromptEngineering, and it is worth slowing down for. This person sat through two separate prompt engineering trainings during that stretch. Their honest takeaway: the people who are actually good at this spend their hours inside the model, not inside a course.
That is the setup. Here is what actually changed the work.
Why It Actually Matters 🎯
Most prompt advice floating around sounds identical from source to source. Assign a persona, think step by step, be polite to the model. The original poster tested that advice against two years of daily coding work. Most of it did nothing measurable on current reasoning models.
What did move the needle was almost boring: tighter constraints, less clutter, and real attention to how a prompt actually gets processed. None of it requires a course. All of it requires reps.
If you write prompts for coding tasks every day, even a few of these will save you a review cycle this week.
The Habits That Moved The Needle 🛠️
- Say what the model cannot touch, before you say what you want built. Early failures were not about the new code. They were about what got changed on the way there. Listing the files and behaviors that must stay untouched, before describing the task, was the single biggest fix. It cut this poster’s “it worked but broke something else” problem more than anything else tried.
- Make the model restate the plan first. One paragraph, in the model’s own words, describing what it thinks the task is. Roughly half the time that restatement is wrong, and catching it before any code exists beats catching it after reviewing forty lines.
- Put static content first, dynamic content last. Prompt caching works on prefix matching. Anything that changes near the top of the prompt invalidates everything below it. Moving working notes to the bottom and stable project context to the top took five minutes. It made a real dent in the cost of long sessions.
- Stop maxing out the effort setting by default. Cranking reasoning effort to the top for a rename or a boilerplate file buys nothing. There is evidence that on some models, high effort setting slightly underperforms medium on coding tasks. Test it against your own workload instead of assuming more is always better.
- Drop the tricks that stopped working. Step by step instructions, expert personas, and telling the model not to hallucinate showed no measurable benefit on current reasoning models. The step by step version also added latency. Few shot examples still beat all three combined.
- The same prompt does not behave the same on every model. Running Opus 5 next to glm-5.3 side by side showed a bigger gap in instruction following than expected. One model follows instructions literally, the other fills in gaps based on what it assumes you meant. Swapping the model behind a prompt without adjusting the prompt itself does not work. Worth noting: the cheaper per-token pricing on some of these models matters a lot more once you are running loops instead of single calls.
Tips And Tricks Worth Stealing 💡
A few readers added sharp follow-ups worth folding into your own setup.
One commenter has the model write its restated plan straight into a markdown file instead of the chat window. That makes it easy to review and respond to without scrolling back through the conversation.
Another pointed out that restating the plan is still a lossy compression of the task. Their suggestion: mark everything explicitly out of scope before you even describe the goal, not just the files that cannot be touched.
A third commenter learned the model swap lesson the hard way. They moved providers on a prompt that had worked fine for months, and the first few outputs after the switch came back noticeably different.
And one more comment is a good reminder of why the first habit matters. An agent went and tidied up an unrelated module while fixing a bug, and nobody caught it until the tests failed somewhere else entirely.
Give It A Try 🚀
None of this is complicated, and that is sort of the point. Specific constraints, a restated plan, and a prompt structure that respects caching will get you further than another course ever will.
Pick one of the six and run it against your next coding prompt today. Then go read the full thread in r/PromptEngineering, the comments have even more detail worth digging through.
Frequently Asked Questions
Q: How should I structure my prompt instructions for best results?
Start with goals and directives, then define what’s in scope and out of scope, then place constraints last. This ordering ensures guardrails are set before specific tasks, and users report it significantly improves instruction-following.
Q: Is restating the plan actually helpful, or is it just extra overhead?
It’s helpful if you change the format. Instead of inline restatement, have the model write the plan to a markdown file you can review and annotate. This lets you catch misunderstandings and add clarifications before any code is written.
Q: Should I use older prompt tricks like “think step by step” or “act as an expert”?
Some old tricks are still useful, step-by-step prompting is genuinely good for complex workflows and reducing unwanted wandering. But others like “don’t hallucinate” are dated. Test what works with your specific model instead of assuming all old techniques are dead.
Q: Why did my prompt stop working when I switched to a different model?
Different models interpret instructions differently. A stable prompt on one model can produce unusable output on another. When switching models, test your core prompts first and expect to adjust phrasing, don’t assume the same instructions will work identically.
Q: Why does the order of information in my prompt matter beyond clarity?
Modern LLMs cache and reuse static content from the start of prompts across sessions, while giving recency bias to the end. Putting stable project context first and your current request last improves cache efficiency and significantly reduces costs on long sessions.
Two years of prompt engineering for coding work, what actually moved the needle
by u/Fragrant-Cheek-4273 in PromptEngineering