In partnership with
Build the AI skills senior engineers need to get ahead
AI is already handling large parts of execution. That shift is not coming later. It is happening now.
What is left, and becoming more valuable, is the ability to design systems, apply AI thoughtfully, and own outcomes in production. That is the work strong teams expect from senior engineers in 2026.
Gauntlet is built for engineers who want to operate at that level. In a single week, 15 hiring partners conducted 246 interviews with challengers onsite in Austin. Apply now.
Must be a US citizen to qualify.
You can swap GPT for Claude, switch from 3.5 to 4, upgrade to the latest model. The output improves by 10 to 15%. Change the prompt? The output improves by 200%.
The model is not the bottleneck. Your prompt is.
Welcome to Grind Engineer, your guide to becoming a better software engineer! No fluff. Pure engineering insights.
Zero Shot vs Few Shot
Zero shot: You ask the model to do something with no examples. It relies entirely on what it learned during training.
prompt = "Classify this ticket as bug, feature, or question: 'Login page throws 500 error'"
# Output: "bug"Works for simple tasks. Falls apart when the task has nuances the model cannot guess.
Few shot: You include 2 to 3 examples in the prompt. The model learns the pattern from your examples and applies it.
prompt = """Classify these support tickets:
Ticket: "Can't reset my password" → bug
Ticket: "Add dark mode please" → feature
Ticket: "How do I export data?" → question
Ticket: "Dashboard loading slowly after update" →"""
# Output: "bug"Few shot is the single highest leverage prompting technique. It costs a few extra tokens and dramatically improves accuracy for any classification, extraction, or formatting task.
Chain of Thought
Force the model to show its reasoning before giving an answer. Without it, the model jumps to conclusions. With it, the model breaks problems into steps and catches its own errors.
prompt = """A server handles 1000 requests/sec. Each request takes 50ms.
How many concurrent connections does the server need?
Think step by step before answering."""Adding "think step by step" or "reason through this before answering" costs nearly nothing and measurably improves accuracy on math, logic, and multi step reasoning tasks.
System vs User vs Assistant Roles
Most LLM APIs accept three message roles. Each serves a different purpose.
Role | Purpose | Example |
|---|---|---|
system | Sets behavior, persona, constraints. Persistent across the conversation. | "You are a senior backend engineer. Respond in Go code only." |
user | The actual question or instruction. | "Write a rate limiter using token bucket." |
assistant | Previous model responses. Used in multi turn conversations and few shot examples. | (the model's prior response) |
💡 Key Insight: The system prompt is not a suggestion. It is the most powerful control mechanism you have. "Respond ONLY in valid JSON. No explanations." in the system prompt works far more reliably than putting the same instruction in the user message.
Structured Output and JSON Mode
When you need the model to return data your code can parse, never ask for "structured output" loosely. Constrain it explicitly.
response = client.messages.create(
model="claude-sonnet-4-6",
system="""You extract product info from descriptions.
Respond ONLY with a JSON object. No markdown. No explanation.
Schema: {"name": str, "price": float, "category": str}""",
messages=[{"role": "user", "content": "Nike Air Max 90, running shoe, $129.99"}]
)
# Output: {"name": "Nike Air Max 90", "price": 129.99, "category": "running shoe"}Three rules for reliable structured output:
Put the schema in the system prompt, not the user message
Say "ONLY" and "No explanation" explicitly (the model defaults to being helpful and chatty)
Validate the output programmatically. Never trust, always verify.
Common Failure Modes
Failure | Why it happens | Fix |
|---|---|---|
Model ignores instructions | Instruction buried in a long prompt. Attention diluted. | Move critical instructions to the system prompt or the very end of the user message. |
Output format breaks | No schema provided. Model invents its own structure. | Explicit JSON schema + "ONLY" constraint + programmatic validation. |
Hallucinated facts | Model has no grounding in real data. | Add RAG. Provide source documents in context. |
Inconsistent outputs | Temperature too high for a deterministic task. | Set temperature to 0 for structured/factual tasks. |
Too verbose | Model trained to be helpful = wordy. | "Under 50 words." or "One sentence only." works surprisingly well. |
Prompt Versioning
Prompts are code. Treat them like code.
In production, your prompt will change dozens of times. Without versioning, you lose the ability to understand which change broke accuracy or improved output quality.
Three practices that save you from prompt chaos:
1. Store prompts in files, not inline strings. Keep them in prompts/classify_ticket_v3.txt or a database table with version numbers. Never hardcode prompts inside application code.
2. Test before deploying. Maintain 10 to 20 test cases (input + expected output). Run every prompt version against the test suite before shipping. A prompt that improves one edge case but breaks three others is a regression.
3. Log everything. Log the prompt version, the input, and the full output for every production call. When output quality degrades, you need the data to diagnose whether it was a prompt change, a model update, or a data issue.
Try This Today
Take your worst performing prompt and add 2 to 3 few shot examples. Measure the difference.
Move your most important instruction into the system prompt with the word "ONLY."
Add "think step by step" to any prompt that involves reasoning or multi step logic.
If this sparked something, hit like ❤️
For more visual explanations of system design, DSA patterns, AI in engineering and tech productivity, Subscribe To Grind Engineer! 🚀
See you in the next one!
Signing Off, Scortier