Prompt Engineering for Developers: 13 Practical Techniques with Examples

You paste a failing function into ChatGPT, describe the bug in one sentence, and get back a generic checklist you already tried. The prompt usually determines whether the answer becomes a shippable fix. A structured prompt gives AI models the context and constraints they need to return accurate, context-aware responses.

Stack Overflow's 2025 Developer Survey shows the skill is now common among developers: 84% of developers are using or planning to use AI tools, and 51% of professional developers use them daily. The same survey found 66% of developers frustrated by AI answers that are "almost right, but not quite." Structured prompting is how you close that gap, whether you use ChatGPT or any of the other AI developer tools.

Reusable templates cover debugging, documentation, architecture, code generation, DevOps, and data tasks. Each reusable template can be adapted to your stack. The examples also apply to Strapi 5 headless Content Management System (CMS) projects.

In brief:

• Prompts with explicit structure produce measurably better results than one-line questions.
• The 13 techniques are grouped by workflow: code quality, documentation and architecture, code generation, and DevOps and data.
• Every template is model-agnostic. The same structure aligns with ChatGPT guidance and Claude guidance; GitHub Copilot uses the same prompt-engineering concepts inside the IDE.
• Code examples use Strapi 5's Document Service API, which replaces the deprecated Entity Service API.

Use those patterns as a practical baseline for getting more reliable development help from AI assistants.

What Is Prompt Engineering?

OpenAI's guidance defines prompt engineering as "the process of writing effective instructions for a model, such that it consistently generates content that meets your requirements." In practice, it's a systematic approach to structuring instructions for large language models so the output is accurate, relevant, and usable on the first or second attempt instead of after repeated tries.

It matters for developers specifically because an AI model knows nothing about your codebase, your framework version, or your constraints unless you state them. The quality of the input determines the quality of the output.

Vendor guidance from OpenAI, Anthropic, Google, and Microsoft overlaps on four components worth building into every prompt:

• Context: language, framework, version, and the problem itself
• Constraint: output format and limits, plus what to avoid
• Intent: the specific task you need the AI to perform
• Examples: input/output pairs that demonstrate the desired behavior

Anthropic's prompting documentation calls examples "one of the most reliable ways to steer" a model's output format and structure. Use these components across the development tasks that follow.

13 Prompt Engineering Techniques by Workflow

Development work usually moves through code quality, documentation and architecture, generation-heavy tasks, and DevOps, data, and teaching material. Each prompt is meant to be copied, narrowed to your stack, and tested against the output you actually need.

1. Debugging Complex Code

The model can only reason about what you show it, so an omitted detail becomes a wrong answer: leave out the framework version and you get v4 advice applied to a v5 project. Gather the error message, relevant code, environment details, and the steps you've already tried before prompting. A generic question like "Why isn't my function working?" yields generic answers. Use this Strapi 5 debugging template:

// Example prompt for debugging a Strapi 5 service
I'm debugging a JavaScript service in a Strapi 5 project that throws a TypeError.

Code:
const articles = await strapi.documents('api::article.article').findMany({
  filters: { title: { $contains: 'launch' } },
  status: 'published',
  populate: ['author'],
});
return articles.map((article) => article.author.name.toUpperCase());

Error: TypeError: Cannot read properties of undefined (reading 'name')
Expected behavior: an array of uppercase author names for published articles
What I've tried: confirmed the author relation exists in the Content-Type Builder
Environment: Strapi 5, Node.js 22, PostgreSQL 16

What might be causing this issue, and how can I fix it?

Use Strapi 5 syntax: strapi.documents() with the status parameter. If you're still migrating, the rundown of Strapi 5 changes covers the breaking changes.

A second technique catches subtle logic errors: "Walk through this JavaScript function line by line, tracking the count and result variables at each loop iteration. Where might the logic be failing?" This is useful when the code runs without throwing but produces the wrong value, including off-by-one loop conditions and state or accumulator changes that happen in an order you didn't expect. Asking the model to narrate variable state at each step surfaces the exact iteration where the value goes wrong. Iterative follow-ups that reference the AI's previous answer usually pinpoint the issue faster than restarting from scratch.

2. Refactoring and Improving Existing Code

Developers rarely refactor for one reason at a time, so prompt for all your concerns in a single pass:

I have a JavaScript service in a Strapi 5 project that needs refactoring.

Current code:
[paste code]

Address these concerns together:
1. Performance: the service fetches related data with populate: '*' on every
   request, which is slow on large collections.
2. Readability: variable names are unclear, and the function mixes query
   building with response shaping.
3. Strapi 5 migration: the code still uses strapi.entityService.findMany(),
   which is deprecated in Strapi 5.
4. Publication status: replace publicationState with the status parameter.

Suggest refactored code and explain each change.

Bundling these concerns into one pass beats separate prompts because the changes interact: narrowing populate to specific fields changes the response shape your refactor has to preserve, and the v5 migration determines which query methods the performance work can even use. A model that sees them together produces code that reconciles them; isolated prompts produce edits you then have to merge by hand. Asking for the reasoning behind each change helps you catch suggestions that don't fit your project. Read the Document Service improvements before you accept AI-suggested migrations, and the transition FAQ answers the edge cases models tend to get wrong. Test refactored code before it reaches production.

3. Performing Code Security Reviews

Use AI review as a first pass before a professional audit. Anchor the prompt to a specific standard:

Perform a security review of this JavaScript code from my Strapi 5 project:

[paste your code]

Focus on:
1. OWASP categories: OWASP Top 10 vulnerabilities and OWASP API Security risks
2. Input validation issues
3. Authentication and authorization weaknesses
4. Strapi 5-specific concerns, such as returning Document Service results
   without output sanitization

Recommend a fix for each issue you find.

Naming OWASP gives the model a concrete checklist to work against instead of guessing what "secure" means for your code. Without that anchor, a security prompt returns whatever the model associates with the word, which varies run to run; with it, the review walks named categories like broken access control and injection and maps findings to them. That fourth item matters because the Document Service API is a data-access layer that isn't aware of user permissions. Strapi's documentation states that custom controllers calling it directly "must sanitize the output yourself before returning it" using strapi.contentAPI.sanitize.output(). For a broader security walkthrough, the security checklist covers Strapi-specific hardening.

For permissions work, a targeted prompt works well: "How can I modify this Strapi 5 permission policy to follow the principle of least privilege while still allowing editors sufficient access to manage content?"

4. Generating API Documentation

Writing OpenAPI specs by hand is slow. A scoped prompt gets you 80% of the way:

"Generate an OpenAPI 3.0 specification for a Strapi 5 REST API endpoint that manages article content. The endpoint supports CRUD operations with pagination, filtering, and sorting. Include authentication requirements and example responses."

For individual endpoints, use a shorter template:

Create documentation for this API endpoint:

Endpoint: [HTTP method] [path]
Purpose: [brief description]
Request parameters: [list parameters]
Authentication: [requirements]

Format the output in Markdown with JSON request/response examples and
common error scenarios.

Supplying the endpoint contract and auth requirements up front stops the model from inventing fields it has never seen. Given only "document my article endpoint," a model fills the gaps with plausible-looking parameters that don't exist in your schema; given the exact endpoint contract, it documents what you actually built. Review the output against your actual implementation before publishing. If you want to take generated docs further, you can build a documentation site with Strapi and Next.js.

5. Designing System Architecture

The AI works better when the prompt includes real requirements. Use this architecture prompt:

Design a system architecture for a media company's content platform.

Requirements:
- Strapi 5 as the headless CMS backend
- 10,000 daily active users, content-heavy pages
- Content delivered to a Next.js website, an iOS app, and a newsletter service
- Editorial team of 12 publishing 40+ articles per week

Constraints:
- Recommend hosting (Strapi Cloud vs. self-hosted) with reasoning
- Include a caching strategy (CDN plus application-level caching)
- Propose a content model using Collection Types and Single Types
- Choose REST or GraphQL per delivery channel and justify each choice

Output a component-by-component explanation with trade-offs.

A prompt that describes a product ("we're building a content platform") returns a marketing-flavored overview of what such a platform could include. A prompt that states user counts, publishing volume, and delivery channels returns hosting, caching, and API choices tied to those numbers, because the model has concrete constraints to reason against. Use the constraints section to add your judgment. Ground it in the hosting trade-offs, content modeling best practices, and the REST versus GraphQL decision in Strapi 5. Use the output as a starting point for design review.

6. Writing Git Commit Messages and Changelogs

Provide the diff and a format standard, and the AI handles the rest:

I've updated a Strapi 5 controller to implement pagination. Here are the changes:

[paste diff]

Generate a commit message in Conventional Commits format: a clear title, a body
explaining what changed and why, and a footer noting any breaking changes.

The diff tells the model what changed, and the format standard tells it how to shape the answer, so Conventional Commits turns "wrote some pagination code" into a typed title, an explanatory body, and a breaking-change footer that tooling can parse for automated versioning. The same pattern works for changelogs: paste recent commits and ask for entries grouped by change type, with Features and Bug Fixes separated from Breaking Changes.

7. Generating Custom Code Snippets

Detailed prompts produce deployable code; vague ones produce pseudocode. Include four or five specifics: the exact API surface, the parameters to support, the return shape, and the non-obvious requirement most developers forget. Naming "sanitizes output before returning it" is what moves the response from a controller that leaks private fields to one you can ship. For example:

"Generate a custom Strapi 5 controller for a blog-post collection that supports pagination, filtering, and sorting, returns pagination metadata, and sanitizes output before returning it."

A correct Strapi 5 response follows the core controller pattern from the official docs:

// src/api/blog-post/controllers/blog-post.js
const { createCoreController } = require('@strapi/strapi').factories;

module.exports = createCoreController('api::blog-post.blog-post', ({ strapi }) => ({
  async find(ctx) {
    await this.validateQuery(ctx);
    const sanitizedQueryParams = await this.sanitizeQuery(ctx);

    const { results, pagination } = await strapi
      .service('api::blog-post.blog-post')
      .find(sanitizedQueryParams);

    const sanitizedResults = await this.sanitizeOutput(results, ctx);

    return this.transformResponse(sanitizedResults, { pagination });
  },
}));

Watch for v4 patterns in generated code: strapi.entityService calls, publicationState parameters, or missing documentId handling all signal the model trained on older examples. If you need custom logic around document operations, Document Service middleware replaced lifecycle hooks in Strapi 5, and generated code should reflect that.

8. Developing Algorithms

Ask for the implementation, the complexity analysis, and the data considerations in one prompt:

Implement a content recommendation algorithm for a Strapi 5 blog.

Context:
- Content is fetched with strapi.documents('api::article.article').findMany()
- Articles have categories, tags, and a view-count field
- The catalog holds ~50,000 articles and grows by ~200 per week

Requirements:
1. Recommend related articles based on shared tags and categories, weighted
   by recency
2. Explain the time and space complexity of your approach
3. Suggest database indexes that keep the query fast at this scale

Return the implementation as a Strapi service method with comments.

Asking for the complexity analysis alongside the implementation surfaces scaling problems before they reach production: an O(n²) tag-comparison loop looks fine on a demo dataset and falls over at 50,000 articles, and the model naming that cost in its own answer gives you the signal to reject it. Verify the output against your real dataset before shipping. For semantic recommendations beyond tag matching, the AI-powered search tutorial shows an embedding-based approach.

9. Translating Code Between Programming Languages

State the source, the target, and what must survive the translation:

"Translate this Node.js function, which fetches content from a Strapi 5 API, into Python using the requests library. Maintain identical functionality, preserve the error handling, and follow idiomatic Python conventions."

Naming what must survive is what keeps a translation faithful: a model left to its own judgment will happily produce idiomatic Python that silently drops the timeout, collapses the HTTP-error and request-error branches into one, or changes the API contract the caller depends on. A faithful Python translation preserves timeout and error handling:

# Example: fetching Strapi 5 content from Python
import requests

def fetch_strapi_content(content_type, document_id, token):
    url = f"https://api.example.com/api/{content_type}/{document_id}"
    headers = {"Authorization": f"Bearer {token}"}

    try:
        response = requests.get(url, headers=headers, timeout=10)
        response.raise_for_status()
        return response.json()
    except requests.exceptions.HTTPError as err:
        print("HTTP error:", err)
    except requests.exceptions.RequestException as err:
        print("Request failed:", err)

Note the document_id in the route: Strapi 5 identifies documents by documentId rather than the numeric id v4 used. If your original Node.js code came from a project like the ChatGPT integration, include that context so the translation preserves the API contract.

10. Automating DevOps Tasks

Specify the environment precisely, including what the AI shouldn't assume:

Create a Docker Compose setup for a Strapi 5 development environment.

Environment:
- Strapi 5 built from a custom Dockerfile (Strapi publishes no official image)
- PostgreSQL 16 for the database
- Credentials loaded from a .env file
- A healthcheck so Strapi waits for the database

Comment each configuration option.

Stating what the model should not assume is as important as stating requirements: models trained on years of older tutorials will reach for a strapi/strapi base image by default, and telling it up front that no official image exists forces a build-from-Dockerfile config instead of a broken pull. Strapi's Docker documentation states that Strapi "does not build any official container images," so any generated config referencing a strapi/strapi image is outdated. A correct setup builds from your own Dockerfile:

# docker-compose.yml
services:
  strapi:
    container_name: strapi
    build: .
    image: strapi:latest
    restart: unless-stopped
    env_file: .env
    ports:
      - "1337:1337"
    depends_on:
      strapiDB:
        condition: service_healthy

  strapiDB:
    container_name: strapiDB
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${DATABASE_USERNAME}
      POSTGRES_PASSWORD: ${DATABASE_PASSWORD}
      POSTGRES_DB: ${DATABASE_NAME}
    volumes:
      - strapi-data:/var/lib/postgresql/data/
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${DATABASE_USERNAME} -d ${DATABASE_NAME}"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  strapi-data:

Test generated infrastructure in a non-production environment first. For a full walkthrough, see the Coolify deployment tutorial.

11. Improving Database Queries

Include the current query, the data volume, and the constraints you want respected:

Improve this Strapi 5 query. It retrieves blog posts with categories, tags,
and author details, and it slows down as the collection grows past 100,000
documents:

const articles = await strapi.documents('api::article.article').findMany({
  populate: '*',
  sort: [{ publishedAt: 'desc' }],
  status: 'published',
});

Constraints:
- Suggest specific populate, fields, limit, and start parameters
- Recommend indexes (publishedAt, foreign keys)
- Keep the response shape compatible with a paginated frontend

Data volume changes the recommendation, so state it. populate: '*' with no pagination is a fine default at a thousand rows and a query that times out at a hundred thousand; the model needs the collection size to choose the right advice. Baking the indexing and pagination expectations into the prompt gets you targeted parameter changes instead of a lecture on database theory. The performance pitfalls guide is a good checklist for evaluating what comes back. Test any change in staging before production.

12. Generating Synthetic Data for Testing

Specify the data shape and the edge cases you need to test:

"Generate 10 examples of synthetic product data in JSON format compatible with Strapi 5's content structure. Include name, description, price, inventory count, at least two categories per product, and image URLs. Include some products with special characters in their names."

Spelling out edge cases matters because the model defaults to clean, happy-path records that pass every validation, and those are exactly the records that never exercise your error handling. Asking for special characters in names and boundary numeric values produces the fixtures that catch encoding bugs and off-by-one validation before a real user does. The reusable template:

Generate synthetic test data for my Strapi 5 project.

Content-Type: [model name, fields with types, relationships]
Output: [number of records] in [JSON/CSV/SQL] format. Include edge cases.
Cover special characters, empty optional fields, and boundary values for
numeric fields.

Edge cases in test data surface bugs that happy-path fixtures never will.

13. Creating Tutorials and Educational Content

Use learning outcomes to prompt for teaching material:

"Create a step-by-step tutorial for developers new to Strapi 5, demonstrating how to implement scheduled publishing. Include code examples and explanations of key concepts."

Structuring the prompt around what a reader should be able to do afterward changes what the model produces: "explain scheduled publishing" returns a survey of the feature, while "the reader can implement scheduled publishing" returns ordered, runnable steps that build to a working result. The template:

Create an educational tutorial on [topic] for Strapi 5 developers.

Audience: [experience level and prior knowledge]
Learning objectives: [what readers should be able to do afterward]
Format: step-by-step guide with JavaScript code examples

Structure it as: introduction, prerequisites, implementation steps with code,
common pitfalls, and next steps.

You'll still need to validate code examples against the current Strapi 5 release before sharing them with your team.

Prompt Engineering Best Practices

The individual templates become more useful when your team turns them into a repeatable prompting workflow across models and projects.

Structure Every Prompt with Context, Constraint, and Format

Use CCI: context narrows the model to your actual situation, constraints fence off answers you can't use, and intent states the single task so the response doesn't wander. Microsoft's guidance puts it bluntly: "Vague prompts produce vague answers." The three parts do distinct jobs: context narrows the model to your actual situation, constraints fence off answers you can't use, and intent states the single task so the response doesn't wander. When an answer disappoints, it usually means one of the three was thin, and naming which one tells you what to add on the next pass.

Before: "Why is my Strapi query slow?"

After: "My Strapi 5 findMany() call on a 200,000-document collection takes 4+ seconds (context). Suggest changes to populate, fields, and pagination parameters only; don't propose infrastructure changes (constraint). Return the improved query with a one-line explanation per change (intent)."

Same question, but the second version can only be answered with something specific.

Iterate and Refine

Treat the first response as a draft. Evaluate the output, identify what's missing, and refine, changing one element at a time so you can tell what helped.

Change one thing per iteration: if a debugging answer misses the mark, add the environment line and rerun before you also rewrite the constraints, because changing both at once hides which edit fixed it.

A concrete loop looks like this: first prompt returns a query improvement that drops the pagination metadata; your follow-up says "keep the limit and start parameters but restore the pagination metadata in the response," and you leave everything else untouched. Follow-up prompts that reference the AI's prior output ("your suggestion breaks the pagination metadata; fix that while keeping the field selection") often produce more value than the initial query.

Build a Shared Prompt Library

Storing working prompts in a team wiki or repo, categorized by task type, keeps nobody from re-deriving a debugging template from scratch. Treat each stored prompt like code: give it a name that says what it does, note which model and framework version it was tuned against, and record the one change that made it work, since a debugging template written for Strapi 4 will hand back the wrong query methods on a v5 project.

GitHub Copilot productizes this with repository-wide instruction files and reusable prompt files, and the same discipline applies to any assistant.

When a shared prompt starts underperforming after a model update, edit the stored version rather than patching it inline each time, so the whole team inherits the fix. Collections like this curated prompt library show what a curated, task-specific library looks like in practice.

AI Coding Assistants Compared

Every technique in this guide is model-agnostic, but that portability stops at the prompt. Once you choose an assistant, its interface and available context start to matter, along with the way each vendor tuned its model. Match those differences to the task in front of you.

• ChatGPT remains the most-used AI tool among developers at 81.7%, per the Stack Overflow survey. OpenAI's current lineup pairs the GPT-5.6 models with the GPT-5.3-Codex model, its specialized coding model, available across the Codex app, CLI, IDE extension, and web.
• Claude offers Claude Opus 4.8 and Claude Sonnet 5, both with 1,000,000-token context windows, per the model overview, which suits whole-repository review and long documentation tasks. Anthropic reports in its Opus 4.8 guidance that Opus 4.8 is "meaningfully better at finding bugs than prior models." Claude also handles structured generation tasks well; see the Content-Type generation tutorial.
• GitHub Copilot is now a multi-model platform: it serves OpenAI, Anthropic, and Google models through one interface, with Ask, Plan, and Agent chat modes and a 1 million token context window for select models in VS Code and Copilot CLI, per GitHub's documentation. Its inline suggestions make it well-suited for autocomplete while you type.

A practical workflow is to use Copilot for in-editor completion, ChatGPT or Claude for longer reasoning, review, and documentation work.

Frequently Asked Questions

What is prompt engineering? It means writing structured, specific instructions that guide a large language model toward accurate, usable output. For developers, that means supplying context (language, framework, version), constraints (format, scope), and clear intent with every request.

Do developers need to learn prompt engineering? Yes. With more than four in five developers using or planning to use AI tools, prompting quality now directly affects how much value those tools return, and poorly specified prompts are the main source of "almost right" answers.

What are the best AI prompts for debugging code? Include the exact code, the full error message, the expected behavior, your environment details, and what you've already tried. For subtle logic bugs, ask the model to walk through the function line by line while tracking specific variables.

Is prompt engineering a real job? The standalone title has largely disappeared; the role is basically obsolete. The skill itself moved the other direction: it's now an expected competency embedded in engineering, product, and operations roles.

Can AI replace developers? The evidence points to AI augmenting developers, and it's genuinely mixed. One controlled trial found developers completed a task 55.8% faster with GitHub Copilot, while a METR study found experienced open-source developers took 19% longer with AI tools. Skilled direction, which is what prompt engineering provides, is what separates the two outcomes.

Start Prompting Smarter

Structured prompts make a general-purpose chatbot a useful part of your development process: supply context, set constraints, state your intent, iterate on the output, and save what works in a shared library your team can reuse. Try these templates in your next Strapi 5 project. Pair them with Strapi's auto-generated REST and GraphQL APIs to generate documentation and prototype content models faster, and if you're building agent-driven workflows, the Strapi MCP server connects AI agents directly to your CMS.