Day 1: Prompting Isn't About Typing Better Questions
Day 1 of #KarthNode100Days starts with AI & Agentic Systems, and the topic is Prompting Foundations. Before I even got into the techniques, I had a realization that reframed everything.
The Realization
When I'm chatting with Claude or ChatGPT, I don't need perfect prompts. I type casually, make typos, and the model figures out what I mean. So why learn prompting at all?
Here's the answer: prompting engineering isn't for conversations. It's for building systems.
When you're writing code that calls an LLM through an API, there's no back-and-forth. Your prompt has to work on the first try, across hundreds of different inputs, without you in the loop. That's where these techniques become actual engineering tools.
Tools like Claude Code, Cursor, and ChatGPT's custom GPTs — they all work the same way. Your casual message gets wrapped in a system prompt that someone carefully engineered. The user talks naturally. The system prompt does the heavy lifting.
Your message: "fix the login bug"
|
Tool wraps it with:
- System prompt (behavior rules, tool definitions)
- Project context (codebase info, conventions)
- Conversation history
|
All sent to the API as one structured request
That invisible wrapper is where prompting techniques live in production.
Chain-of-Thought (CoT) Prompting
The idea is simple: force the model to show its reasoning steps before giving a final answer, instead of jumping to a conclusion.
Without CoT:
Q: I have 3 servers each handling 150 req/s. One goes down. Can the remaining handle 500 req/s? A: Yes.
Wrong. No reasoning, just a guess.
With CoT:
Q: Same question. Think step by step. A: Total capacity was 3 x 150 = 450 req/s. One down means 2 x 150 = 300 req/s remaining. 300 < 500, so no — they can't handle it.
Correct. The trick is that when the model generates those intermediate reasoning tokens, they become context that guides the final answer. It's like rubber-duck debugging — explaining the steps leads to the right answer.
The trigger can be as simple as adding "Think step by step" to your prompt. This is called zero-shot CoT — no examples needed, just the instruction.
Few-Shot Learning
Instead of describing what you want, you show examples of input-output pairs. The model picks up the pattern and applies it to new inputs.
Zero-shot (no examples):
Convert this to SQL: "all users who signed up last month"
Few-shot (with examples):
Convert natural language to SQL:
Input: "all active users"
Output: SELECT * FROM users WHERE status = 'active';
Input: "top 10 orders by amount"
Output: SELECT * FROM orders ORDER BY amount DESC LIMIT 10;
Input: "all users who signed up last month"
Output:
The few-shot version produces much more consistent formatting and structure because the model has a concrete pattern to follow.
The sweet spot is 3-5 examples. Make them diverse but consistent in format. And put the most relevant example last, closest to the actual query.
Self-Consistency
This is a reliability technique for when you need to be confident in the answer. Instead of asking once, you:
- Ask the same question multiple times (with some randomness)
- Each time, the model uses CoT to reason through it
- Take the majority vote on the final answer
Run 1: ... reasoning ... → Answer: B
Run 2: ... reasoning ... → Answer: B
Run 3: ... reasoning ... → Answer: A
Run 4: ... reasoning ... → Answer: B
Run 5: ... reasoning ... → Answer: B
Majority vote: B (4 out of 5) → high confidence
Think of it like running the same test multiple times. If 4 out of 5 runs agree, you can trust the result. This is especially useful for math, logic, and classification tasks.
How They Connect
You can stack these techniques:
- CoT alone improves reasoning accuracy
- Few-shot alone improves output consistency
- Few-shot + CoT examples teach the model both the format AND the reasoning style
- All three combined (few-shot CoT + self-consistency) gives you the most reliable output possible without fine-tuning
The Takeaway
These aren't conversation skills. They're API design patterns. When you're building an AI-powered app — a code reviewer, a customer support bot, an automated classifier — this is how you make it reliable.
The user doesn't need to know any of this. They just type casually. Your system prompt, written with these techniques, makes the magic happen behind the scenes.
Day 1 down. Tomorrow: building a custom AI copilot with Claude's Projects feature.
Follow along: @KarthNode