Most developers use ChatGPT like this:
"fix my code"
And then wonder why the output is garbage.
The difference between a useless AI response and one that saves you 30 minutes isn't the model — it's the prompt. After months of refining prompts in real projects, I compiled 50 battle-tested prompts that consistently produce useful results.
Here are 10 free previews across 5 categories. Each one shows the Before (what most devs type) vs the After (what actually works).
🐛 Debugging (3 Prompts)
Prompt #1: Find the Bug
❌ Before (vague):
Find the bug in this code
[paste code]
✅ After (engineered):
Analyze this [language] function for bugs. The expected behavior
is [X], but the actual behavior is [Y]. Focus on:
- Edge cases with [specific input types]
- Off-by-one errors
- Null/undefined references
- Async timing issues
[paste code]
Return: the bug location, why it happens, and a corrected version
with comments explaining each fix.
Example output (truncated):
Bug found on line 12: The `forEach` callback is async but
`forEach` doesn't await promises. This causes the function
to return before all items are processed.
Fix: Replace `items.forEach(async (item) => {...})` with
`await Promise.all(items.map(async (item) => {...}))`
💡 Pro tip: Always state expected vs actual behavior. This alone eliminates 50% of back-and-forth.
Prompt #2: Explain the Error Message
❌ Before:
Explain this error message: TypeError: Cannot read
properties of undefined (reading 'map')
✅ After:
I'm getting this error in a [React/Node/etc.] project:
[full error with stack trace]
Relevant code:
[paste the function where it occurs]
Context: This happens when [describe when it triggers].
Explain:
1. What's causing this specific error
2. The most likely root cause given my code
3. How to fix it
4. How to add a guard so it never happens again
Example output:
1. The error means `data` is undefined when `.map()` is called
2. Root cause: Your useEffect fetches data async, but the
component renders before the fetch completes
3. Fix: Initialize state with empty array: useState([])
4. Guard: Add optional chaining: data?.map() or a loading check
💡 Pro tip: Always include the stack trace AND the code where it happens. Error messages without context are like symptoms without a patient.
Prompt #3: Why Does This Return Undefined?
❌ Before:
Why does this return undefined?
[paste code]
✅ After:
Trace the execution of this [language] function step by step.
I expect it to return [expected value] when called with
[specific input], but it returns undefined.
[paste code]
For each line:
- Show the current state of all variables
- Flag where the logic diverges from expected behavior
- Identify the exact point where the return value becomes undefined
Example output:
Step-by-step trace with input getUserRole("admin"):
Line 3: roles = fetchRoles() → returns Promise (not awaited!)
Line 4: roles.find(...) → calling .find() on a Promise object
Line 5: if (role) → role is undefined (Promise has no .find)
Line 6: Falls through to implicit return → undefined
🔍 Root cause: Missing `await` on line 3
💡 Pro tip: Ask for a step-by-step trace. It forces the model to simulate execution instead of guessing.
🔍 Code Review (2 Prompts)
Prompt #4: Review This Function
❌ Before:
Review this function
[paste code]
✅ After:
Review this [language] function as a senior developer would
in a pull request. Evaluate:
1. **Correctness**: Does it handle all edge cases?
2. **Performance**: Any O(n²) or unnecessary operations?
3. **Readability**: Naming, structure, comments
4. **Security**: Input validation, injection risks
5. **Maintainability**: Would a new team member understand this?
[paste code]
Format as a PR review with severity levels: 🔴 Critical,
🟡 Suggestion, 🟢 Nice-to-have. Include code examples for
each suggestion.
Example output:
🔴 Critical: SQL query on line 8 uses string concatenation
→ SQL injection risk. Use parameterized queries instead.
🟡 Suggestion: The nested loop on lines 12-18 is O(n²).
Convert `users` to a Map for O(1) lookups:
const userMap = new Map(users.map(u => [u.id, u]));
🟢 Nice-to-have: Rename `d` to `userData` for clarity.
💡 Pro tip: The severity levels force prioritized, actionable feedback instead of vague "looks good" responses.
Prompt #5: Suggest Improvements
❌ Before:
Suggest improvements for this code
[paste code]
✅ After:
Refactor this [language] code to be production-ready.
The current version works but needs improvement.
Constraints:
- Must maintain the same public API/interface
- Target environment: [Node 20 / Browser / etc.]
- Performance matters: this runs [frequency, e.g., "on every request"]
Improve:
1. Error handling (what can fail? add try/catch/fallbacks)
2. Type safety (add TypeScript types or JSDoc)
3. Extract magic numbers into named constants
4. Add input validation
5. Optimize the hot path
[paste code]
Show the refactored version with a comment above each
change explaining WHY, not just what changed.
Example output:
// CHANGED: Extract magic number → named constant for clarity
const MAX_RETRY_ATTEMPTS = 3;
const RETRY_DELAY_MS = 1000;
// CHANGED: Add input validation — caller could pass null
if (!url || typeof url !== 'string') {
throw new TypeError(`Expected URL string, got ${typeof url}`);
}
// CHANGED: Replace recursive retry with iterative loop
// to prevent stack overflow on high retry counts
for (let attempt = 1; attempt <= MAX_RETRY_ATTEMPTS; attempt++) {
// ...
}
💡 Pro tip: "Production-ready" is the magic phrase. It triggers the model to think about error handling, edge cases, and real-world concerns.
🏗️ Architecture (2 Prompts)
Prompt #6: Design a REST API
❌ Before:
Design a REST API for a todo app
✅ After:
Design a REST API for [app description].
Requirements:
- Users can [list key actions]
- Auth: [JWT/OAuth/API key]
- Scale: [expected users/requests]
For each endpoint, provide:
1. Method + path (RESTful conventions)
2. Request body/params with types
3. Response shape with status codes (200, 400, 401, 404, 500)
4. Rate limiting recommendations
5. Example curl command
Also include:
- Database schema (tables + relationships)
- Auth middleware flow
- Pagination strategy
- Error response format (consistent across all endpoints)
Example output (one endpoint):
POST /api/v1/tasks
Auth: Bearer token required
Rate limit: 100 req/min per user
Request:
{
"title": string (required, max 200 chars),
"priority": "low" | "medium" | "high" (default: "medium"),
"due_date": ISO 8601 string (optional)
}
Response 201:
{
"id": "uuid",
"title": "Buy groceries",
"priority": "high",
"status": "pending",
"created_at": "2024-01-15T10:30:00Z"
}
curl -X POST https://api.example.com/api/v1/tasks \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"title": "Buy groceries", "priority": "high"}'
💡 Pro tip: Always specify scale. An API for 100 users is designed very differently from one for 100K users.
Prompt #7: Choose the Right Data Structure
❌ Before:
What's the best data structure for this?
✅ After:
I need a data structure for [specific use case].
Operations I need (ranked by frequency):
1. [Most common operation] — must be O(?)
2. [Second operation] — acceptable: O(?)
3. [Rare operation] — can be slower
Constraints:
- Dataset size: [approximate]
- Memory limit: [if applicable]
- Language: [language — affects available stdlib]
- Thread safety: [yes/no]
Compare 3 options with:
- Big-O for each operation
- Memory overhead
- Implementation complexity
- When each option is the WRONG choice
Recommend one with justification.
Example output:
For your case (frequent lookups by key, occasional range scans,
~1M entries):
| Structure | Lookup | Insert | Range Scan | Memory |
|--------------|--------|--------|------------|----------|
| HashMap | O(1) | O(1) | O(n log n) | Medium |
| B-Tree | O(log n)| O(log n)| O(log n + k)| Higher |
| Sorted Array | O(log n)| O(n) | O(log n + k)| Lowest |
✅ Recommendation: B-Tree (or BTreeMap in Rust/TreeMap in Java)
Why: Your range scans happen 30% of the time — HashMap would
require sorting on every scan. B-Tree gives you O(log n) for
everything with reasonable memory.
💡 Pro tip: Ranking operations by frequency changes the recommendation entirely. Always include this.
🧪 Testing (2 Prompts)
Prompt #8: Write Unit Tests
❌ Before:
Write unit tests for this function
[paste code]
✅ After:
Write comprehensive unit tests for this [language] function
using [testing framework, e.g., Jest/pytest/JUnit].
[paste code]
Cover:
1. Happy path (normal inputs, expected output)
2. Edge cases: empty input, single element, max size
3. Error cases: invalid types, null, undefined
4. Boundary values: 0, -1, MAX_INT, empty string
5. Async behavior (if applicable): timeout, rejection
For each test:
- Descriptive test name that reads like a specification
- Arrange → Act → Assert pattern
- One assertion per test (mostly)
- Add comments explaining WHY this case matters
Target: 90%+ branch coverage.
Example output:
describe('calculateDiscount', () => {
// Happy path
it('applies 10% discount for orders over $100', () => {
expect(calculateDiscount(150, 'SAVE10')).toBe(135);
});
// Boundary: exactly at threshold
it('applies discount when order is exactly $100', () => {
expect(calculateDiscount(100, 'SAVE10')).toBe(90);
});
// Edge: discount would make total negative
it('returns 0 when discount exceeds order total', () => {
expect(calculateDiscount(5, 'SAVE90')).toBe(0);
});
// Error: invalid coupon
it('throws InvalidCouponError for expired codes', () => {
expect(() => calculateDiscount(100, 'EXPIRED'))
.toThrow(InvalidCouponError);
});
});
💡 Pro tip: "Reads like a specification" makes test names self-documenting. Your future self will thank you.
Prompt #9: Generate Edge Cases
❌ Before:
Generate edge cases for this function
✅ After:
Generate edge cases for this [language] function that
could cause it to fail or behave unexpectedly.
[paste code]
For each edge case:
1. Input value(s)
2. Why it's tricky (what assumption does it violate?)
3. Expected behavior vs likely actual behavior
4. Severity: 🔴 crash, 🟡 wrong result, 🟢 minor issue
Think about:
- Type coercion gotchas ("0" vs 0 vs false vs null)
- Unicode and special characters (emoji, RTL, zero-width)
- Timezone and locale differences
- Floating point precision (0.1 + 0.2)
- Concurrent access / race conditions
- Very large inputs (memory/timeout)
- Deeply nested structures (stack overflow)
Example output:
🔴 Edge case: Input contains emoji
Input: "Hello 👨👩👧👦 World"
Why: The family emoji is 11 bytes but 1 visual character.
String.length returns 11, .split('') produces 7 elements.
Your substring(0, 5) would split the emoji → garbled output.
🟡 Edge case: Negative zero
Input: -0
Why: -0 === 0 is true, but JSON.stringify(-0) returns "0".
Your comparison on line 4 won't catch this.
🟢 Edge case: Prototype pollution
Input: {"__proto__": {"admin": true}}
Why: Object.assign would merge this into the target object's
prototype chain if not guarded.
💡 Pro tip: The category framework (type coercion, unicode, timezone, etc.) catches things that "generate edge cases" alone would miss.
📝 Documentation (1 Prompt)
Prompt #10: Write a README
❌ Before:
Write a README for this project
✅ After:
Write a professional README.md for this [type] project.
Project: [name and one-line description]
Tech stack: [languages, frameworks, tools]
Target audience: [who uses this]
Include these sections:
1. **Hero section**: Project name, badges (build, coverage,
license, npm version), one-line description, screenshot/gif
2. **Quick start**: Copy-paste commands to get running in <2 min
3. **Features**: Bulleted list with brief descriptions
4. **Installation**: Prerequisites, step-by-step, verify it works
5. **Usage**: 3 real-world examples (basic → advanced)
6. **API reference**: Key functions with params and return types
7. **Configuration**: Environment variables with defaults
8. **Contributing**: Setup, PR process, code style
9. **Troubleshooting**: Top 3 common issues + fixes
10. **License**
Tone: Friendly but professional. Assume the reader has 2 minutes
to decide if they'll use this project.
Example output (hero section):
# 🚀 FastQueue
A lightweight, Redis-backed job queue for Node.js that handles
10K+ jobs/second with zero configuration.
## Quick Start
npm install fastqueue
const { Queue } = require('fastqueue');
const queue = new Queue('tasks');
await queue.add({ email: 'user@example.com', template: 'welcome' });
💡 Pro tip: "2 minutes to decide" makes the model frontload the most compelling information. Developers are ruthless — if your README doesn't hook them in 30 seconds, they leave.
That's 10 out of 50.
The full collection includes 40 more prompts across these additional categories:
- 🔧 Refactoring (5 prompts) — Transform legacy code into clean, modern code
- ⚡ Performance (5 prompts) — Find bottlenecks and optimize hot paths
- 🔒 Security (5 prompts) — Audit code for vulnerabilities before hackers do
- 🗄️ Database (5 prompts) — Schema design, query optimization, migrations
- 🚀 DevOps (5 prompts) — CI/CD, Docker, deployment automation
- 📐 System Design (5 prompts) — Scalability, caching, load balancing
- 🎯 Career (5 prompts) — Resume review, interview prep, salary negotiation
- 📦 Project Kickstart (5 prompts) — Go from idea to boilerplate in minutes
Plus category-specific templates you can copy-paste and customize.
📥 Get All 50 Prompts + Templates
More by MaxMini
🛠️ 27+ Free Developer Tools — JSON formatter, UUID generator, password analyzer, and more. All browser-based, no signup.
🎮 27 Browser Games — Built with vanilla JS. Play instantly, no install.
📚 Developer Resources on Gumroad — AI prompt packs, automation playbooks, and productivity guides.
💰 DonFlow — Free budget tracker. Plan vs reality, zero backend.
What you get:
- ✅ 50 engineered prompts (Before → After format)
- ✅ Copy-paste templates for every category
- ✅ Real output examples for each prompt
- ✅ Pro tips from actual production use
- ✅ Free updates as I add more prompts
One good prompt saves 30+ minutes. The whole pack pays for itself in one debugging session.
📚 More Resources for Developers
If you found this useful, check out my other guides:
| Guide | What You Get | Price |
|---|
🎁 Bonus: Try DonFlow
Building something cool? Check out DonFlow — a visual workflow builder for developers. Try the live demo and see if it fits your project.
If this article helped you write better prompts, drop a ❤️ and share it with a developer friend who's still typing "fix my code" into ChatGPT. 😄
Top comments (0)