Multi-Language Code Example Generation Prompt Template

This prompt is designed for documentation engineers and DevRel teams who maintain multi-language SDK references and need to produce equivalent, idiomatic code examples from a single, stable API operation description. The core job-to-be-done is consistency at scale: you have a known-correct behavior, error modes, and authentication pattern for an endpoint, and you need to mirror that exact logic across Python, JavaScript, Go, Java, Ruby, and other target languages without manually rewriting each example or introducing language-specific drift. The prompt assumes you are the domain expert on the API's behavior—it translates your specification into idiomatic code, it does not invent or validate the API contract itself.

Use this prompt when the underlying API operation is stable and well-understood. The ideal input is a concrete source of truth: a single OpenAPI operation fragment, a reference implementation in one language, or a detailed specification that includes the request shape, successful response shape, error responses, authentication headers, and any idempotency or retry semantics. The prompt works best as part of a documentation engineering pipeline where the output code blocks are checked into a docs repository, validated by a harness, and reviewed before publication. It is not a general-purpose code generator, and it should not be used when the API behavior is still changing sprint-to-sprint, when you need a full SDK library scaffolded, or when the target language lacks a stable, well-known HTTP client ecosystem.

Do not use this prompt for generating production business logic, for inventing API behavior from vague descriptions, or for languages where you cannot verify the output compiles and runs. The prompt produces documentation examples—they must be correct, copy-pasteable, and safe, but they are not a substitute for a maintained SDK. If your goal is to generate a complete client library with resource classes, pagination helpers, and streaming support, you need a code generation toolchain (e.g., OpenAPI Generator) rather than a prompt. Similarly, if you cannot commit to running a validation harness that checks compilability, dependency resolution, and basic behavioral correctness, the risk of publishing broken examples is too high. Start with a single reference implementation, run the prompt, validate the outputs, and only then expand to additional languages.

This prompt template is designed to be pasted directly into your AI orchestration layer. It instructs the model to produce functionally equivalent, idiomatic code examples in multiple target languages from a single API operation specification. The template uses square-bracket placeholders for all dynamic inputs—replace these with your specific API details, target languages, and quality constraints before sending the prompt to the model.

markdownCopy
You are a senior SDK engineer and technical writer. Your task is to generate functionally equivalent, idiomatic code examples for a single API operation in multiple programming languages.

## Input
- **API Operation Description:** [API_OPERATION_DESCRIPTION]
- **Endpoint Details:** [ENDPOINT_METHOD_AND_PATH]
- **Request Schema:** [REQUEST_SCHEMA]
- **Response Schema:** [RESPONSE_SCHEMA]
- **Authentication Method:** [AUTH_METHOD]
- **Target Languages:** [TARGET_LANGUAGES]
- **Error Codes to Handle:** [ERROR_CODES_TO_HANDLE]
- **Dependency Versions:** [DEPENDENCY_VERSIONS]

## Output Schema
For each target language, generate a self-contained code block that includes:
1.  **Imports and dependency declarations** with pinned versions.
2.  **Client initialization** with authentication handling.
3.  **Request construction** with all required and one optional parameter.
4.  **Explicit error handling** for the specified error codes, including a retry on a 429 status code with exponential backoff.
5.  **Response processing** to extract a key field from the successful response body.
6.  **Resource cleanup** where applicable (e.g., closing connections).

## Constraints
- **Security:** Never use hardcoded credentials. Read from environment variables or a secure config pattern idiomatic to the language.
- **Idiomatic Style:** Follow the official style guide and community conventions for each target language. Do not write generic cross-language code.
- **Compilability:** The code must compile and run with the specified dependency versions.
- **Comments:** Add brief inline comments explaining *why* a non-obvious pattern is used, not *what* the code does.
- **No Placeholders:** The final code must be complete and runnable, with no `// TODO` or `...` placeholders.

## Example Output Structure (Python)
```python
import os
import time
import requests
from requests.exceptions import HTTPError, RequestException

API_KEY = os.environ.get("SERVICE_API_KEY")
if not API_KEY:
    raise RuntimeError("SERVICE_API_KEY environment variable not set.")

BASE_URL = "https://api.example.com/v1"

def create_resource(payload: dict) -> dict:
    headers = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
    max_retries = 3
    for attempt in range(max_retries):
        try:
            response = requests.post(f"{BASE_URL}/resources", json=payload, headers=headers)
            response.raise_for_status()
            return response.json()["id"]
        except HTTPError as e:
            if e.response.status_code == 429 and attempt < max_retries - 1:
                time.sleep(2 ** attempt)
                continue
            elif e.response.status_code == 400:
                raise ValueError(f"Invalid request: {e.response.text}") from e
            raise
        except RequestException as e:
            raise ConnectionError(f"A network error occurred: {e}") from e
    raise RuntimeError("Max retries exceeded for rate-limited request.")

Generate the complete output for each of the target languages.

To adapt this template, replace each [PLACEHOLDER] with concrete values from your API spec. The [API_OPERATION_DESCRIPTION] should be a plain-English summary of what the endpoint does. The [TARGET_LANGUAGES] list should be specific (e.g., Python 3.11, Node.js 20 LTS, Go 1.22). The [DEPENDENCY_VERSIONS] field is critical for ensuring the generated examples are runnable; pin major and minor versions (e.g., requests==2.31.0). After generating the output, you must validate each code block against the constraints using the evaluation harness described in the implementation section.

The Multi-Language Code Example Generation Prompt is not a one-shot tool; it is a component in a documentation pipeline that must produce compilable, idiomatic, and secure code across multiple languages. The implementation harness wraps the LLM call with pre-processing, post-generation validation, retry logic, and human review gates. This ensures that generated examples do not introduce security anti-patterns, fail to compile, or drift from the source API contract.

Pipeline Architecture: The harness should accept a single API operation description as input and fan out to N parallel or sequential generation calls—one per target language. Each call must include the language-specific [CONSTRAINTS] (e.g., naming conventions, standard libraries) and a shared [OUTPUT_SCHEMA] that enforces a consistent structure: a code block, a dependencies list with pinned versions, and an explanation string. After generation, a validation layer runs language-specific checks: compilation or linting (e.g., gcc, rustc, eslint), security scanning for hardcoded credentials or injection vectors, and a behavioral test harness that executes the code against a mock server. If any check fails, the harness should retry the prompt with the specific error message injected into the [CONTEXT] as a correction hint, up to a maximum of three attempts.

Human Review and Gating: For high-risk surfaces like authentication flows or database queries, the harness must route the output to a human review queue before publication. The review interface should display a diff against the source API spec, the validation results, and any security flags. Only after explicit approval should the example be merged into the documentation repository. Log every generation attempt, validation failure, and review decision to an observability platform to track prompt drift and model performance over time. Avoid deploying this prompt without these gates; a broken code example in production documentation erodes developer trust faster than no example at all.