Back to Lab

Prompt Engineering for Developers (Not Marketers)

Forget "Act as a Senior Developer." Write Real Prompts.

Most prompt engineering guides are written for marketers asking ChatGPT to write email subject lines. If you are a developer using Claude Code, Claude API, or any LLM in a production pipeline, those guides are useless.

Developer prompting is a different discipline. You care about structured output, deterministic behavior, error handling, and context management. Not "tone of voice" and "creative brainstorming."

According to Anthropic's own benchmarks, well-structured prompts improve task completion rates by 40-60% compared to natural language requests for coding tasks. For structured data extraction, the improvement jumps to 70-85%. The gap between a mediocre prompt and a good one is not marginal. It is the difference between code that works and code that almost works.

System Prompts vs User Prompts

If you are using the Claude API, you have two prompt surfaces: system and user. Most developers dump everything into the user prompt. That is wrong.

System prompt: Persistent instructions that define behavior across the entire conversation. Think of it as configuring the model's operating mode. Put here: output format requirements, coding conventions, error handling rules, persona constraints.

User prompt: The specific task for this turn. Put here: the actual request, input data, specific parameters for this particular call.

Goes in System Prompt	Goes in User Prompt
"Always return valid JSON"	"Parse this CSV and extract emails"
"Use TypeScript conventions"	"Build a function that validates input"
"Never include comments in output"	"Refactor this component"
"Handle errors with try/catch blocks"	"Add error handling to this API route"

The separation matters because the system prompt is processed differently by the model. Anthropic's documentation confirms that system prompt instructions receive higher priority in the attention mechanism. A rule in the system prompt is more reliably followed than the same rule in the user prompt.

CLAUDE.md: Persistent Prompting for Projects

If you use Claude Code (the CLI), CLAUDE.md is the most powerful prompting tool available. It is a markdown file in your project root that acts as a persistent system prompt for every conversation in that directory.

A good CLAUDE.md includes:

• Code conventions: Naming patterns, file structure, import order
• Tech stack specifics: Framework version, key libraries, database type
• Architecture rules: "Server components by default, client components only for interactivity"
• Known gotchas: "The auth middleware runs before API routes, check session before DB calls"
• Output expectations: "Always include TypeScript types, never use any"

A well-maintained CLAUDE.md saves re-explaining the same context in every conversation. In practice, conversations with good CLAUDE.md context use significantly fewer tokens to achieve the same results. That is real money saved on API calls.

For developers learning to work with Claude Code efficiently, Git Dojo (5 EUR) teaches git fundamentals through an interactive Claude Code skill - a good example of how persistent prompting works in practice.

Few-Shot vs Zero-Shot for Code

Zero-shot: "Write a function that validates email addresses."

Few-shot: "Here are two examples of validation functions in our codebase. Write a similar one for email addresses."

For code generation, few-shot consistently outperforms zero-shot. Providing 2-3 examples of existing code patterns consistently improves output quality and reduces syntax errors significantly.

The trick: your examples should come from your actual codebase. Not from documentation or tutorials. The model needs to match YOUR patterns, not generic best practices.

// Example prompt with few-shot pattern:
// Here is how we validate in this project:

function validateUsername(input: string): ValidationResult {
  if (!input || input.length < 3) {
    return { valid: false, error: "Username must be at least 3 characters" };
  }
  if (!/^[a-zA-Z0-9_]+$/.test(input)) {
    return { valid: false, error: "Username contains invalid characters" };
  }
  return { valid: true, error: null };
}

// Now write a validateEmail function following the same pattern.

Structured Output (JSON, XML, TypeScript)

When you need the LLM to return data, not prose, structure your prompt explicitly:

Return a JSON object with this exact shape:
{
  "status": "success" | "error",
  "data": {
    "items": Array<{ id: string, name: string, price: number }>,
    "total": number
  },
  "error": string | null
}

Do not include any text before or after the JSON.
Do not wrap it in markdown code blocks.

Claude handles JSON output reliably when given explicit schemas. According to Anthropic's tool-use documentation, providing a schema reduces malformed output from roughly 12% to under 1%.

For complex structures, use XML tags as delimiters. Claude was trained with XML-aware formatting and handles it natively:

<instructions>
Parse the following log file and extract errors.
</instructions>

<output_format>
Return each error as a JSON object inside an <errors> tag.
</output_format>

<input>
[paste log content here]
</input>

Temperature Settings (When They Actually Matter)

Task	Recommended Temperature	Why
Code generation	0.0 - 0.2	Deterministic output, fewer hallucinations
Code review	0.1 - 0.3	Slight variation helps catch different issues
Data extraction	0.0	Maximum consistency required
Creative writing	0.7 - 1.0	Variation is the point
Brainstorming	0.8 - 1.0	Higher diversity of suggestions
API response generation	0.0	Consistency across calls

For production API calls where Claude generates user-facing content (like RAXXO Studio does for social media captions), I use temperature 0.7. High enough for creative variation, low enough to stay on-topic. For code generation in Claude Code, the default settings work well - Anthropic has already optimized the temperature curve for coding tasks.

5 Common Prompting Mistakes Developers Make

1. Vague success criteria. "Make this code better" vs "Reduce the cyclomatic complexity of this function to under 10 and extract the validation logic into a separate function." The second prompt produces useful output. The first produces random refactoring.

2. Missing constraints. "Build a REST API endpoint" vs "Build a GET endpoint at /api/users that returns paginated results (max 50 per page), requires auth via Bearer token, and returns 404 for missing users." Constraints are not limitations. They are specifications.

3. Over-prompting. Writing 500-word prompts for simple tasks. If the task is "add a loading spinner to this button," just say that. Do not explain what a loading spinner is or why UX matters.

4. Ignoring context windows. Claude's context window is large but not infinite. Dumping an entire codebase into the prompt dilutes the important context. Be selective. Include only the files relevant to the current task.

5. Not iterating. Treating prompting as a one-shot activity. The best results come from 2-3 turns of refinement: generate, review, adjust prompt, regenerate. This mirrors how you would work with a human developer - first draft, code review, revisions.

5 Real Prompt Templates for Dev Tasks

Template 1: Bug fix

Bug: [describe the unexpected behavior]
Expected: [what should happen]
Actual: [what happens instead]
Relevant files: [list files]
Reproduce: [steps to reproduce]
Fix the bug. Explain what caused it in one sentence.

Template 2: Code review

Review this code for: security issues, performance problems,
and violations of [your coding standard].
Do not suggest style changes.
List issues by severity (critical, warning, info).
For each issue, show the fix.

Template 3: Feature implementation

Structure: Requirements list + constraints + reference to existing patterns + files to preserve. The key is giving Claude both what to build and what NOT to touch.

Template 4: Data transformation

Structure: Explicit input/output shapes + numbered transform rules + edge case handling. Showing exact data shapes eliminates ambiguity.

Template 5: Test generation

Structure: Target function + framework + coverage scope + mock list. The critical rule: test behavior, not implementation details.

The full template library with 15+ production-tested templates is coming in our premium developer guides. The two templates above give you the pattern - the full set covers migrations, refactoring, API design, and more.

FAQ

Does prompt engineering matter for Claude Code specifically?

Yes, but differently than API prompting. Claude Code reads your project context automatically, so you focus less on providing context and more on writing clear task descriptions. The CLAUDE.md file handles persistent prompting. Your conversational prompts should be concise and specific.

Should I use Claude or GPT for code generation?

As of 2026, Claude consistently outperforms GPT on structured output, long-context tasks, and following complex instructions. GPT tends to produce more "creative" code that may deviate from your patterns. For production codebases where consistency matters, Claude is the stronger choice. For quick prototyping where anything goes, both work.

How do I know if my prompt is good enough?

Run it three times. If you get the same quality result all three times, the prompt is well-specified. If results vary wildly, the prompt has ambiguity that needs resolving. Consistent output from consistent input is the test of a good prompt.

What is the biggest ROI prompt engineering skill for developers?

Learning to write good CLAUDE.md files. A well-maintained CLAUDE.md file saves more time than any individual prompt technique because it compounds across every conversation. Second: learning to provide few-shot examples from your own codebase rather than writing abstract descriptions of what you want.