36 ChatGPT Prompts That Make You a Faster, Better Developer

I'm getting this error in my [language/framework] project: ``` [paste full error message and stack trace] ``` Relevant code: ```[language] [paste the code around the error] ``` Context: [what you were doing when it happened]. Don't just fix the symptom. Explain: what this error means in plain English, the root cause (not just the line that threw), why this specific input or state triggers it, the fix with explanation of why it works, and how to prevent this class of error in the future.

I have a bug: [describe the unexpected behavior]. Expected behavior: [what should happen]. Actual behavior: [what happens instead]. Here's the relevant code: ```[language] [paste code] ``` Before suggesting a fix: identify all code paths affected, check if the fix could break any existing functionality, look for other places in the code with the same pattern (they might have the same bug). Then provide: the minimal fix (smallest change that solves the problem), explanation of why it works, a test case that proves the bug is fixed, and a test case that proves existing functionality still works.

My [language/framework] application is slow. Here's what I know: What's slow: [specific operation or endpoint] How slow: [current latency/time] Expected: [target performance] Scale: [data size, concurrent users, etc.] Relevant code: ```[language] [paste the slow code] ``` Analyze: what's the time complexity of this code? Where are the likely bottlenecks (N+1 queries, unnecessary loops, blocking calls, memory allocation)? Suggest fixes ranked by impact: highest-impact/lowest-effort first. For each fix, estimate the expected improvement and explain why.

I inherited this code and I don't understand what it does or why it works: ```[language] [paste mysterious code] ``` Explain: what does this code do, step by step in plain English? Why was it written this way instead of the obvious/simple way? What edge cases or problems is it handling that aren't obvious? Are there any bugs or issues hiding in it? If I needed to modify this code, what would I need to be careful about? Add inline comments that explain the non-obvious parts.

I have a flaky test that passes sometimes and fails sometimes: Test code: ```[language] [paste test] ``` Code under test: ```[language] [paste the code being tested] ``` Failure pattern: [describe when it fails — randomly, on CI only, after other tests, etc.] Diagnose the likely cause: timing/race condition, shared mutable state, external dependency, order-dependent setup, floating point comparison, or timezone issue? Suggest a fix that makes the test deterministic. If the test is testing the wrong thing, suggest what it should test instead.

I need to understand how data flows through this code. Starting from [entry point/function call], trace the data transformation step by step: ```[language] [paste all relevant functions/files] ``` For each step: what function is called and with what arguments, how the data is transformed, what side effects occur (database writes, API calls, state changes), where errors could occur and how they propagate, and what the final output looks like. Draw an ASCII diagram showing the flow.

Review this code for production readiness: ```[language] [paste code] ``` Context: this is [describe what the code does] in a [type of application]. Check for: security vulnerabilities (injection, XSS, auth bypass, data exposure), error handling gaps (what happens when things fail?), edge cases that could cause crashes or data corruption, performance issues at scale, logging and observability (can we debug this in production?), and code maintainability (will someone understand this in 6 months?). Rate each issue as critical/warning/suggestion. Don't flag style preferences — only things that could cause real problems.

Refactor this code to be more readable without changing its behavior: ```[language] [paste code] ``` Apply these specific improvements only: extract meaningful variable names, break long functions into smaller ones with clear names, reduce nesting depth (guard clauses, early returns), simplify conditional logic, remove dead code or unnecessary complexity. Show the refactored version and explain each change. Confirm that the refactored code handles the same edge cases as the original. Do NOT add features, change the API, or "improve" the architecture.

This query is slow in [database: PostgreSQL/MySQL/MongoDB/etc.]: ```sql [paste query] ``` Table schema: ```sql [paste relevant CREATE TABLE statements or describe structure] ``` Table sizes: [approximate row counts]. Current execution time: [time]. The query plan shows: [paste EXPLAIN output if available]. Suggest optimizations: query rewriting (joins, subqueries, CTEs), index recommendations with CREATE INDEX statements, schema changes if needed, and caching strategy if the query runs frequently. For each suggestion, explain the expected improvement and any trade-offs (write performance, storage, maintenance).

I have similar code repeated across multiple files: File 1: ```[language] [paste code] ``` File 2: ```[language] [paste similar code] ``` [Add more files if applicable] Identify: what's actually duplicated vs what just looks similar, a shared abstraction that captures the common pattern, the right level of abstraction (don't over-abstract), and how each callsite should use the shared code. Show the extracted shared code AND the updated callsites. Make sure the abstraction handles all the variations between the originals.

This code only handles the happy path: ```[language] [paste code] ``` Identify every point where something can fail: network calls, file I/O, parsing, user input, null/undefined values, database operations, type mismatches. For each failure point: what error could occur, what should happen when it does (retry, fallback, propagate, log), the appropriate error type/class, and user-facing vs internal error messaging. Add comprehensive error handling. Don't catch and swallow errors — every catch block should do something meaningful.

I need tests for this existing code: ```[language] [paste code] ``` Generate a test suite using [testing framework: Jest/pytest/JUnit/etc.] that covers: every public function/method, normal inputs with expected outputs, edge cases (empty inputs, max values, null, special characters), error conditions (what should throw/reject/return errors), and integration between functions if applicable. For each test, explain what it's verifying and why that case matters. Organize tests by function with describe/context blocks. Aim for 90%+ code coverage.

I'm an experienced [known language] developer learning [new language]. Teach me [new language] by comparison: for each core concept (variables, functions, control flow, data structures, error handling, async, types, modules), show the [known language] way I already know, then the [new language] equivalent with idiomatic patterns. Highlight the "gotchas" — things that look the same but behave differently. What are the biggest mindset shifts I need to make? What [known language] habits will hurt me in [new language]? Give me a learning roadmap: what to learn in what order for a developer at my level.

I'm new to [framework]. Explain its architecture and key conventions: what problem does it solve and what's its philosophy? Core concepts (routing, state management, data fetching, etc.) — explain each in 2-3 sentences. The "magic" — things that happen automatically that I should know about. File and folder conventions (what goes where and why). The request/response lifecycle (or component lifecycle). Common antipatterns — things beginners do wrong. Show me a minimal but complete example that demonstrates the core patterns working together.

Explain the [pattern name: Observer/Strategy/Factory/etc.] design pattern for a [language] developer. Include: the problem it solves (when would I need this?), a simple real-world analogy, a code example that's realistic (not just Dog extends Animal), when to use it vs when it's overkill, the trade-offs (what do you give up?), and how [language]'s specific features make this pattern easier or unnecessary. If [language] has a built-in feature that replaces this pattern, show that instead.

I need to implement [feature description] using [library/package name] in [language]. I've never used this library before. Walk me through: what this library does and its core API, installation and setup, a step-by-step implementation of my feature with complete code, what each part of the code does and why, configuration options I should know about, common pitfalls with this library, and how to test that it's working correctly. Use version [X] of the library. Don't use deprecated APIs.

I'm choosing between [technology A] and [technology B] (and [C] if applicable) for [use case]. Compare them on: what each is best at (core strength), performance characteristics and benchmarks, learning curve for a developer with [your background], ecosystem maturity (docs, community, packages), deployment and operational complexity, long-term viability (funding, adoption trends, corporate backing), and specific advantages for my use case: [describe project]. Give me a clear recommendation with your reasoning. Don't say "it depends" without then actually telling me what it depends on.

I'm learning [language/framework] and want a project that teaches me the fundamentals through building. My experience level: [beginner/intermediate/advanced in programming, beginner in this specific technology]. Design a project that: is completable in [timeframe], covers these core concepts: [list concepts you want to learn], has clear milestones I can build incrementally, is interesting enough to actually finish (not another todo app), and teaches concepts in the right order (foundations before advanced). For each milestone: describe what to build, what concept it teaches, provide starter code or pseudocode, and suggest what to Google when I get stuck.

I need a SQL query for [database: PostgreSQL/MySQL/SQLite/etc.]. In plain English, I want to: [describe what data you need and any conditions]. My relevant tables: ```sql [paste CREATE TABLE statements or describe schema] ``` Write the query with: proper JOIN types with explanation of why each is used, WHERE clauses with parameterized inputs (not hardcoded values), appropriate GROUP BY and aggregate functions if needed, ORDER BY and LIMIT for usability, and aliases that make the output readable. Also provide: a line-by-line explanation of the query, the expected output format with sample data, and performance notes (will this be slow on large tables?).

I'm building [describe feature/application] and need a database schema. Requirements: [List data requirements and relationships] Design a schema with: table definitions including column types, constraints, and defaults, primary keys and foreign key relationships, indexes for expected query patterns: [describe common queries], consideration of: data integrity, normalization (or deliberate denormalization), soft deletes if appropriate, and audit fields (created_at, updated_at). Use [database] syntax. Explain each design decision. Flag any areas where I'll need to choose between normalization and query performance.

I need to make this change to my [database] schema: [Describe the change: add column, create table, modify constraint, etc.] Current schema: ```sql [paste current relevant tables] ``` Generate: an UP migration that makes the change, a DOWN migration that reverses it, handling for existing data (defaults, backfills, data transformation), consideration of zero-downtime deployment (can this run while the app is live?), and the ORM migration if I'm using [Prisma/Sequelize/Django/Rails/etc.]. Flag any destructive changes that can't be undone.

I have a reporting query that's too slow for a dashboard: ```sql [paste query] ``` Table sizes: [row counts for each table]. Current execution time: [time]. This runs [frequency: on every page load, hourly, daily]. I need it under [target time]. Suggest a strategy: can the query itself be optimized? Would a materialized view or summary table help? Should I pre-compute results on a schedule? What indexes would help? Can I trade some accuracy for speed (approximate counts, etc.)? Provide the optimized solution with implementation steps.

My SQL query returns unexpected results: ```sql [paste query] ``` Expected: [describe what you expect to see] Actual: [describe what you're actually getting] Schema: ```sql [paste relevant tables] ``` Sample data that demonstrates the problem: ```sql [paste or describe sample data] ``` Diagnose: is it a JOIN issue (wrong type, missing condition, cartesian product)? A GROUP BY issue (aggregating incorrectly)? A WHERE clause issue (filtering too much or too little)? A NULL handling issue? Show me the corrected query and explain exactly where the logic went wrong.

Design a REST API for [describe feature/resource]. The API needs to support: [list operations]. Users: [describe who calls this API and their auth level]. Provide: endpoint list with HTTP methods, paths, and descriptions, request/response schemas for each endpoint (JSON), authentication and authorization requirements, pagination strategy for list endpoints, error response format with specific error codes, rate limiting recommendations, and versioning strategy. Follow REST best practices. Use [camelCase/snake_case] for field names.

Generate API documentation for these endpoints: ```[language] [paste route handlers/controllers] ``` For each endpoint, document: HTTP method and path, description of what it does, authentication requirements, request parameters (path, query, body) with types and validation rules, response format with example JSON for success and each error case, and curl examples that work out of the box. Format as [OpenAPI/Markdown/JSDoc]. Include a "Getting Started" section showing how to authenticate and make the first API call.

Design a consistent error handling strategy for my [language/framework] API. Current endpoints handle errors inconsistently. I need: a standard error response format (JSON structure), error code taxonomy (categories and specific codes), mapping from exceptions/errors to HTTP status codes, a middleware/handler that catches errors and formats responses, client-friendly error messages vs internal error details, logging strategy (what to log at each level), and examples of handling: validation errors, not found, auth failures, rate limits, server errors. Show implementation code.

Generate TypeScript types from this API response: ```json [paste JSON response] ``` Requirements: infer the most specific types (not just `string` for everything), mark nullable fields as optional, create separate interfaces for nested objects, add JSDoc comments describing each field, export everything, handle array items with proper typing, and create a union type for any enum-like string values. Also generate a type guard function for runtime validation.

Write integration tests for these API endpoints using [testing framework/tool: Supertest/requests/RestAssured/etc.]: ```[language] [paste route definitions or OpenAPI spec] ``` For each endpoint, test: successful operation (200/201), validation failures (400), authentication requirements (401/403), resource not found (404), and any business logic edge cases. Include: test setup/teardown (database seeding, auth tokens), helper functions for common operations, assertions on response body, status code, and headers, and tests for race conditions if applicable. Organize with clear test names that describe the scenario.

I need to add webhooks to my [language/framework] application. When [describe events that should trigger webhooks], I need to notify external systems. Design: the webhook registration API (how clients subscribe), payload format for each event type, delivery mechanism (sync vs async, queue-based), retry strategy with exponential backoff, signature verification for security (HMAC), a dashboard/API for clients to see delivery history and failures, and rate limiting to protect both our system and the receiver. Show implementation code for the core delivery mechanism.

I have this [REST/GraphQL/gRPC] API: [paste API definition] Convert it to [target style: REST/GraphQL/gRPC]. Maintain: the same data access patterns, authentication/authorization, error handling, and pagination. Show: the new API definition, any schema/type definitions needed, a mapping document showing old → new endpoints, migration notes for clients transitioning, and what features of the new style we should take advantage of. Highlight anything that doesn't translate cleanly between styles.