7 AI Prompts That Actually Work for Developers — Free Samples from a 60-Prompt Pack

I'm getting this error in my {{language}} / {{framework}} application:

```
{{paste_error_message_here}}
```

Relevant code:
```
{{paste_relevant_code_here}}
```

Diagnose this systematically:
1. Explain what this error actually means in plain English
2. List the 3 most likely root causes, ranked by probability
3. For each cause, give me a specific diagnostic step I can run to confirm or rule it out
4. Once the most likely cause is identified, provide the fix with before/after code
5. Suggest what guard, check, or test I should add to prevent this entire class of error in the future

I'm building {{feature_description}} for a {{type_of_app}} using {{tech_stack}}.

Current constraints:
- {{constraint_1, e.g., "must work with existing PostgreSQL schema"}}
- {{constraint_2, e.g., "needs to handle 10k concurrent users"}}
- {{constraint_3, e.g., "team is 2 engineers, so keep it simple"}}

Do NOT write any code yet. Instead:
1. Propose 3 different architectural approaches
2. For each approach, list: (a) how it works in 2-3 sentences, (b) pros, (c) cons, (d) what breaks first at scale
3. Recommend one approach and explain why it fits my constraints
4. Draw the data flow as ASCII art
5. Only THEN outline the implementation plan as a numbered task list

Review this {{language}} code as a senior engineer who is known for catching subtle bugs. Be direct and critical — I want real problems, not praise.

```
{{paste_code_here}}
```

Structure your review as:

**BUGS & CORRECTNESS** — Anything that is actually broken or will break under specific conditions (race conditions, off-by-one, null refs, etc.)

**SECURITY** — SQL injection, XSS, auth bypass, secrets exposure, SSRF, or any OWASP Top 10 issue

**PERFORMANCE** — N+1 queries, unnecessary allocations, missing indexes, O(n^2) where O(n) is possible

**MAINTAINABILITY** — Naming, structure, coupling, or anything that will make the next developer curse

For each issue: state the problem in one sentence, show the exact line(s), and provide the fixed code. If nothing is wrong in a category, say "None found" — don't invent issues.

Write tests for this {{language}} function using {{test_framework}}:

```
{{paste_function_here}}
```

Requirements:
1. Start by listing every edge case and boundary condition you can identify (empty input, null, max values, unicode, concurrent access, etc.) — BEFORE writing any test code
2. Group tests into: Happy Path, Edge Cases, Error Handling, and (if applicable) Performance
3. Each test should have a descriptive name that explains the scenario, not the implementation
4. Use the Arrange-Act-Assert pattern
5. Include at least one test that verifies the function FAILS correctly (expected errors, not just success)
6. Add a brief comment above each test explaining WHY that case matters

Do not mock anything unless I specify what should be mocked. Prefer real objects over mocks.

Optimize this Dockerfile for production. The app is a {{language/framework}} application.

```dockerfile
{{paste_dockerfile_here}}
```

Analyze and fix:
1. **Layer caching** — Are layers ordered so that frequently-changing steps come last? Identify any cache-busting mistakes.
2. **Image size** — Use multi-stage builds if not already. Recommend the smallest viable base image. Identify any unnecessary files or packages.
3. **Security** — Running as root? Missing USER directive? Any secrets baked into the image? CVE-heavy base image?
4. **Build speed** — Anything that can be parallelized or removed from the build context?
5. **Runtime** — Correct ENTRYPOINT/CMD? Health check? Graceful shutdown signal handling?

Output the optimized Dockerfile with inline comments explaining each change. Then show a before/after comparison of estimated image size and build time.

Create a {{method}} {{path}} endpoint in {{framework}} ({{language}}).

Business logic: {{describe_what_the_endpoint_does}}

Data model:
```
{{paste_relevant_schema_or_types}}
```

The endpoint must include:
1. Input validation with specific error messages (not just "invalid input")
2. Authentication check (assume a middleware provides `req.user` or equivalent)
3. Authorization — verify the user has permission to perform this action on this resource
4. Error handling that returns appropriate HTTP status codes (400 vs 401 vs 403 vs 404 vs 422 vs 500)
5. A success response that follows the existing API conventions: {{describe_your_response_format}}
6. Structured logging with request ID, user ID, and action performed
7. A JSDoc/docstring with the route, params, body, response, and possible error codes

Do NOT include: database setup, import boilerplate, or framework configuration. Just the handler and any helper functions it needs.

Refactor this {{language}} code. It works correctly — do NOT change its behavior. Preserve the exact same inputs, outputs, and side effects.

```
{{paste_code_here}}
```

Approach this as a series of small, safe refactoring steps (not one giant rewrite):
1. First, identify code smells: long methods, deep nesting, repeated logic, unclear naming, feature envy, primitive obsession, or god objects
2. For each smell, propose a specific refactoring technique (Extract Method, Replace Conditional with Polymorphism, Introduce Parameter Object, etc.)
3. Apply the refactorings one at a time, showing the code after each step
4. After each step, confirm: "Behavior preserved: yes/no" and explain why
5. Final version should be something a new team member can read and understand in under 2 minutes

Constraints:
- Do not add external dependencies
- Do not change the public API or function signature
- If a refactoring is risky (might change behavior), flag it and skip it