Prompt Engineering Basics for Developers
Prompt Engineering Basics for Developers: A Practical Tutorial
Prompt engineering is not about magic wording. For developers, it is the practice of turning vague instructions into reliable, testable inputs for AI models. A good prompt reduces retries, lowers latency, controls output format, and makes your application easier to debug. In this tutorial, you will learn a practical workflow for writing prompts that work well with Claude and GPT models, including how to test them cheaply using an API relay such as 59API.
Step 1: Define the Job Before Writing the Prompt
Start by describing exactly what the model should do. Do not begin with clever phrasing. Begin with a task contract. A useful contract includes the goal, the input, the expected output, and failure rules.
- Goal: Summarize support tickets, classify feedback, generate SQL, review code, or extract entities.
- Input: Raw text, JSON, logs, code snippets, user messages, or structured records.
- Output: Plain English, JSON, bullet points, a patch, a database query, or a score.
- Failure rules: What should happen if data is missing, ambiguous, unsafe, or outside scope?
For example, instead of asking, “Analyze this customer message,” define the job as: “Classify this customer message into one of: billing, bug, feature request, cancellation, or other. Return JSON with category, confidence, and short_reason. If unsure, use other.”
Step 2: Separate Instructions From Data
Many prompt failures happen because the model cannot tell where your instructions end and user-provided data begins. In production, always separate system instructions, developer instructions, and user input when your SDK supports roles. If you are building on an OpenAI-compatible SDK through 59API, you can keep the same message structure while routing requests to supported GPT or Claude models via https://api.59api.com.
A strong structure is: system message for permanent behavior, developer message for task rules, and user message for the actual input. This reduces prompt injection risk because user content is treated as data, not as trusted instructions.
Step 3: Specify the Output Format Precisely
If your application consumes the model output, never rely on casual prose. Ask for a strict format. JSON is usually best for backend workflows, while short labeled sections work well for human review tools.
Be specific about field names, allowed values, and length limits. For example: “Return only valid JSON with keys: category, priority, summary. category must be one of billing, technical, account, other. priority must be low, medium, or high. summary must be under 25 words.”
This makes parsing easier and lets you write unit tests against the model response. It also helps you compare models. You might find that a cheaper model works well for classification, while a stronger model is better for code generation or reasoning-heavy tasks.
Step 4: Add Examples Only When They Help
Examples are powerful, but they are not always necessary. Use examples when the task has subtle formatting, tone, or labeling rules. This is called few-shot prompting. One or two examples are often enough.
- Use examples for: style matching, custom taxonomies, edge cases, or non-obvious output formats.
- Avoid examples for: simple extraction tasks where rules are already clear.
- Keep examples short: Long examples increase token cost and may distract the model.
When using examples, include both the input and the ideal output. If there are common mistakes, include a counterexample in the instructions, such as: “Do not include explanations outside the JSON.”
Step 5: Control Scope and Refusals
Developers often forget to tell the model what not to do. Scope control improves reliability. If you are building a code assistant, specify whether it should edit only the provided file, avoid changing public interfaces, or ask for missing context before guessing.
For data extraction, add rules like: “If a value is not present in the text, return null. Do not infer missing values.” For legal, financial, or medical content, instruct the model to provide general information and recommend expert review when appropriate.
Step 6: Test Prompts Like Code
Treat prompts as source code. Store them in version control, review changes, and test them against a fixed dataset. Create a small evaluation set with typical inputs, edge cases, and malicious inputs. Then compare outputs across prompt versions and models.
- Correctness: Does the response satisfy the task?
- Format: Is the output valid and parseable?
- Stability: Does it behave consistently across similar inputs?
- Cost: How many tokens does it use?
- Latency: Is it fast enough for your user experience?
This is where a low-cost relay is useful. 59API provides cheap, pay-as-you-go access to Claude models such as Opus, Sonnet, Haiku, and Fable, as well as GPT models, while staying compatible with Claude Code, Codex, and OpenAI SDK workflows. Because the base URL is https://api.59api.com, many projects can switch by changing configuration rather than rewriting the integration.
Step 7: Choose the Right Model for the Task
Do not use the most expensive model for every request. Match the model to the workload. Lightweight classification, routing, tagging, and short extraction often work well on faster, cheaper models. Complex code review, multi-step reasoning, and long-context synthesis may justify a stronger model.
A practical architecture is to use a cheaper model first, then escalate only difficult cases. For example, classify support tickets with a low-cost model, and send only high-risk or low-confidence cases to a stronger model. 59API is a good fit for this pattern because it gives developers access to native official-quality models without downgrade, while helping keep experimentation and production usage affordable. Its referral rebate can also reduce costs for teams that invite other developers.
Step 8: Build a Reusable Prompt Template
Once a prompt works, turn it into a template with variables. Keep the fixed instructions stable and inject only trusted values where needed. A typical template includes role, task, rules, output schema, examples, and user data. Name your templates clearly, such as ticket_classifier_v3 or pr_review_summary_v2.
Also log prompt version, model, token usage, latency, and validation errors. These logs help you debug regressions and decide when to upgrade or downgrade a model.
Final Checklist
- Define the task: Goal, input, output, and failure behavior.
- Separate data from instructions: Use roles when available.
- Demand structured output: Prefer strict JSON for backend systems.
- Add examples carefully: Use them for edge cases and style.
- Evaluate continuously: Test prompts against real cases.
- Optimize cost: Use cheaper models where they are good enough.
Prompt engineering becomes much easier when you treat it as an engineering discipline: specify, test, measure, and iterate. If you want to experiment with Claude and GPT models without overpaying, consider signing up for 59API and pointing your existing SDK configuration to https://api.59api.com.