Good AI prompts for developers do more than ask a model to write code. They define the task, provide the right repository context, set boundaries, and make the expected result easy to inspect. This reusable library covers debugging, explanation, refactoring, test generation, documentation, SQL, API design, and code review, with a practical structure for adapting each prompt to a different codebase or model.
Overview
LLM prompting is most useful in software development when it is treated as a repeatable workflow rather than a collection of clever one-line requests. A vague prompt may produce plausible code, but it gives the model too much room to guess about requirements, conventions, dependencies, and acceptable risk.
The templates below are designed to make those assumptions visible. Each one separates the task from the context, constraints, and output format. You can use them with a general-purpose coding assistant, an internal AI tool, or a model connected to repository search and other developer utilities.
Before sending any prompt, remove secrets, credentials, private keys, and unnecessary personal or customer data. Also treat generated code as a draft: compile it, run the relevant tests, inspect the diff, and check it against the project’s security and licensing requirements.
For tasks involving source documents or repository knowledge, a retrieval step can improve the context supplied to the model. See RAG prompting best practices for a separate workflow focused on grounded, cited answers.
Template structure
A dependable coding prompt usually contains seven parts:
- Role: State the perspective that is useful, such as senior Python reviewer, database engineer, or API designer.
- Task: Describe one outcome in clear terms. Avoid combining unrelated changes in the same request.
- Context: Include the relevant code, error output, file paths, schema, framework version, or acceptance criteria.
- Constraints: Specify compatibility, performance, style, dependency, security, and scope requirements.
- Process: Ask the model to identify assumptions, reason through likely causes, or list risks before proposing a change.
- Output format: Define whether you want a patch, a complete file, a checklist, a table, or structured JSON.
- Verification: Ask for tests, commands to run, edge cases, and a short explanation of what remains uncertain.
A reusable base prompt can look like this:
Act as a [role] working in a [language/framework] repository.
Task:
[Describe one concrete outcome.]
Context:
[Relevant files, code, errors, data shape, and expected behaviour.]
Constraints:
- Preserve [public interfaces or compatibility requirements].
- Do not change [out-of-scope areas].
- Follow [project conventions].
- Treat [security, performance, or reliability requirement] as mandatory.
Before proposing a solution:
1. List important assumptions.
2. Identify likely risks and edge cases.
3. State what additional information would change your recommendation.
Return:
[Required format, such as a unified diff followed by tests.]
Verification:
Include tests or commands that can confirm the result.This structure works for both zero-shot prompting and few-shot prompting. If the model needs to follow a house style, add one or two short examples of an acceptable input and output. Keep examples representative rather than filling the prompt with large amounts of unrelated code.
How to customize
Start with the repository, not with the model. Identify the language, runtime, package manager, test command, formatting rules, and files that define the behaviour in question. A prompt that includes a small, relevant slice of context is usually easier to review than one that pastes an entire project.
Next, define the unit of change. For example, “improve error handling in this function without changing its return type” is more testable than “make this module better”. Include a measurable acceptance condition where possible: a failing test should pass, a query should return one row per customer, or an endpoint should reject malformed input with a specified status.
Be explicit about output boundaries. If you want review comments, request comments only. If you want a patch, request a unified diff and ask the model not to invent files. If your application consumes the response programmatically, use a structured output prompt with a schema and validation step.
Match the prompt to the risk of the task. A documentation draft may need a concise summary and a list of unknowns. A database migration needs rollback considerations, data-loss warnings, transaction behaviour, and a test plan. A security-sensitive change should ask for threat assumptions and negative tests, but it should still receive human review.
Finally, separate investigation from implementation when the problem is unclear. First ask the model to classify the error and propose diagnostic checks. Then provide the results of those checks in a second prompt. This simple form of prompt chaining reduces the chance that an early guess becomes an assumed fact.
Examples
Debugging an error
Act as a senior [language] debugger. Diagnose the failure below without assuming that the first apparent cause is correct.
Error:
[Paste the complete error and relevant log lines.]
Code path:
[Paste the smallest relevant function or file excerpt.]
Environment:
[Runtime, framework, dependency versions, and recent change.]
Return:
1. Three plausible causes ranked by likelihood.
2. A diagnostic check for each cause.
3. The smallest safe fix if the evidence supports it.
4. Regression tests for the confirmed cause.
Do not rewrite unrelated code or claim certainty where the evidence is incomplete.This prompt is useful when the model needs to distinguish symptoms from causes. Include the full traceback where possible, but remove tokens, passwords, and customer data.
Explaining unfamiliar code
Explain this [language] code for a developer joining the project.
Context:
[File path, module purpose, callers, and relevant data types.]
Code:
[Paste the excerpt.]
Return:
- A five-sentence overview.
- The inputs, outputs, and side effects.
- Important invariants and failure paths.
- External dependencies or hidden assumptions.
- Three questions a new maintainer should investigate.
Do not describe behaviour that cannot be supported by the supplied code.Refactoring safely
Refactor the function below for readability while preserving observable behaviour.
Requirements:
- Keep the public signature unchanged.
- Preserve exception types and ordering where practical.
- Do not add dependencies.
- Keep the change limited to this module.
Return a unified diff, followed by:
1. Behaviour preserved.
2. Potential behaviour changes.
3. Tests covering equivalence and edge cases.
4. A command to run the formatter and test suite.Generating tests
Write tests for the supplied [function/class]. Use the existing [test framework] conventions shown in the example.
Cover:
- Normal input.
- Empty, null, or missing input where applicable.
- Boundary values.
- Invalid input and expected errors.
- A regression case for [known defect].
Do not mock a dependency unless the existing test style requires it. For each test, state the behaviour it protects. Return only the test file and a short list of assumptions.Code review
Review this diff as a cautious maintainer.
Priorities, in order:
1. Correctness and data integrity.
2. Security and access control.
3. Reliability and failure handling.
4. Performance regressions.
5. Maintainability and style.
For each finding, provide severity, file and line, the specific concern, why it matters, and a minimal remediation. If there are no findings in a category, say so. Do not praise the change or report formatting preferences unless they affect maintainability.SQL assistance
Act as a database engineer. Review the SQL below for correctness and portability within [database engine].
Schema:
[Relevant tables, columns, keys, and relationships.]
Question:
[Business result required.]
Query:
[SQL.]
Return:
- What rows the query returns.
- Join, filtering, grouping, and null-handling risks.
- A corrected query only if needed.
- Test data cases that could reveal a mistake.
- Index or performance considerations, clearly separated from correctness issues.For readability, you can inspect the result with an online SQL formatter. A formatter improves presentation; it does not validate business logic or make a query safe.
API design and documentation
Design or review an HTTP API for [resource and use case].
Inputs:
[Client needs, authentication assumptions, and data model.]
Constraints:
[Compatibility, idempotency, pagination, validation, and error requirements.]
Return:
- Endpoint and method choices.
- Request and response examples.
- Validation and error model.
- Authentication and authorisation considerations.
- Idempotency and retry behaviour.
- A small set of contract tests.
Mark every unresolved product decision instead of silently choosing one.When to update
Review your coding prompt library whenever the surrounding workflow changes. Useful triggers include adopting a new language or framework, changing test or formatting commands, introducing repository retrieval, moving to structured outputs, or discovering a recurring failure mode in generated responses.
Update prompts after reviewing real outputs, not just after reading general prompting advice. Keep a small evaluation set containing representative tasks: a routine change, a difficult bug, an edge case, and a request the model should refuse to complete without more context. Score outputs for correctness, scope control, test quality, clarity, and unsupported assumptions. This creates a practical form of LLM evaluation without requiring a large benchmark.
Store prompts alongside their intended workflow. Record the model or tool context when it materially affects the result, but avoid treating one successful response as proof that a prompt is reliable. The prompt evaluation framework and evaluation dataset guide can help turn informal testing into a repeatable review process.
Keep a change log for the templates themselves. Note what changed, which examples motivated it, and which checks should be rerun. If the prompt feeds a publishing or deployment workflow, test the complete workflow after changes rather than checking only the text response. Developer utilities such as a JSON formatter and validator can help inspect structured results, while a formatter cannot replace schema validation or automated tests.
To put this library into use today, choose one recurring task and adapt the base structure to your repository. Add one real example, define an output format, and write a verification command. Run the prompt on three representative cases, save the outputs, and revise only the parts that caused ambiguity. Once the result is dependable, add it to your team’s prompt collection with an owner, a short purpose statement, and a clear update trigger. That small feedback loop turns generic AI prompts for developers into maintainable coding prompt templates.
