I realized something embarrassing last week. I'd been treating Claude and ChatGPT like they were magical boxes that would just understand me if I asked nicely. I'd throw a vague question at them, get a mediocre answer, and blame the AI. But the real problem? I was the one being unclear. After reading about prompting patterns, I understood: I wasn't communicating badly, I just didn't know the patterns that actually work.
This isn't theoretical stuff either. I'm using these techniques daily now, in code reviews, generating test cases, planning architecture, debugging weird edge cases. And the difference between "kind of useful" and "saves me 2 hours" comes down to understanding which pattern fits which problem.
The Kitchen Metaphor That Finally Made Sense
The article uses a cooking analogy, and I'll admit it annoyed me at first. But it stuck with me because it's true. You don't use the same technique for every dish, and you shouldn't use the same prompt structure for every task. I was cooking everything on medium heat and wondering why nothing came out right.
There are really six distinct patterns, and the breakthrough for me was realizing they're not fancy, they're just structured ways of thinking. Zero-shot is just asking directly. Few-shot is showing examples. Chain-of-thought is breaking problems into steps. None of these are complicated. The complication comes from knowing when to use which one.
Where I've Actually Applied This
I started with zero-shot for simple tasks. "Explain this error message" or "Suggest a variable name." It works fine for straightforward stuff. But when I needed to generate code review comments in a specific tone, encouraging but honest, zero-shot gave me generic feedback that felt like it came from a template.
Then I tried few-shot. I fed Claude three examples of good review comments I'd written, showing the tone and structure I wanted. The next batch of generated comments were noticeably better. Not perfect, but directional.
For bigger problems, like analyzing a complex system design or breaking down a migration strategy, I started using chain-of-thought. Instead of asking "How should we refactor this?" I'd ask for specific steps: identify current bottlenecks, list constraints, propose solutions for each, estimate effort. Suddenly I was getting structured, actionable output instead of generic advice.
My Take: It's About Clarity, Not Magic
Here's what I disagree with slightly: the article frames this as a beginner's guide, but I think these patterns are equally valuable for experienced developers. I've worked with people who've been coding for 15 years and still interact with AI like they're hoping for a lottery win.
The real insight isn't that these patterns exist, it's that good prompt engineering is just clear communication. The same principles that make a good PR description, a good issue report, or a good Slack message apply here. You're explaining intent, providing context, and setting expectations.
What I'd add that the article touches on but doesn't emphasize enough: testing matters. Don't just ask once and assume it works. Try your prompt a few times. Tweak it. See what changes the output. This is especially important in production-adjacent work where consistency matters.
A Practical Example from My Week
I needed to categorize user feedback from our app. Using just zero-shot:
Categorize this feedback: "The dashboard is confusing"
Mediocre results. Then I switched to few-shot:
Categorize feedback as: UX Issue, Feature Request, or Bug Report
Example 1: "The dashboard is confusing" → UX Issue
Example 2: "I need to export reports as PDF" → Feature Request
Example 3: "Buttons don't respond on mobile" → Bug Report
Now categorize: "Can't find where to edit my profile"
Much more consistent and accurate. The examples gave the AI a clear decision framework.
What I'm Still Figuring Out
I'm curious about when examples actually hurt. The article hints at this but doesn't go deep. I've had times where my examples biased the output in wrong ways, or where adding more examples made the AI less flexible. There's probably a sweet spot I haven't found yet.
Also: how do these patterns interact? What happens when you combine chain-of-thought with role-based prompting? I've tried it, but I haven't been systematic enough to know what actually improves things versus what's just cargo culting.
Your Turn
If you're working with AI in your development workflow, try something concrete this week. Pick a repetitive prompt you use regularly. Change the pattern, add examples, break it into steps, define a role. See what changes. Then tell me what worked and what didn't.
Because that's really what this is about: making AI actually useful instead of impressive-sounding.
Source: This post was inspired by "Prompt Engineering for Beginners (Part 3): 6 Prompting Techniques You'll Actually Use" by Dev.to. Read the original article
