28 Qwen Prompts for Coding (2026)

Turn on Thinking. I'm hitting this error in [LANGUAGE / FRAMEWORK version]: [PASTE ERROR]. Here's the relevant code: [PASTE CODE]. Reason step by step from the error to the most likely root cause. If more than one cause is plausible, rank them by likelihood and explain the evidence for each. Give me the corrected code and a two-sentence explanation of what was actually wrong. Before you finish, check the fix against the original error.

This code produces the wrong result. Expected: [EXPECTED OUTPUT]. Actual: [ACTUAL OUTPUT]. Input: [SAMPLE INPUT]. Code: [PASTE CODE]. Find the smallest change that fixes it without altering anything else. Return the corrected code, then walk through the sample input line by line to show it now produces the expected output. If the fix has any side effect on other inputs, say so.

Turn on Thinking. I have a bug that only happens sometimes: [DESCRIBE SYMPTOMS, WHEN IT APPEARS, WHAT YOU'VE RULED OUT]. Relevant code and config: [PASTE]. Reason about what could make this non-deterministic — race conditions, uninitialized state, ordering, caching, time or timezone, or environment differences. Rank the suspects, and for the top one give me a minimal way to reliably reproduce it plus the fix.

Here's a full stack trace: [PASTE TRACE]. And here's the code at the frames that matter: [PASTE CODE]. Walk the trace from the top, tell me which frame is the real origin of the failure versus where it merely surfaced, and explain what state must have been true to reach it. Then give the fix and one guard that would have failed louder and earlier.

Turn on Thinking. A request flows through these files and breaks somewhere: [PASTE FILE 1], [PASTE FILE 2], [PASTE FILE 3]. Symptom: [DESCRIBE]. Trace the data as it moves from entry point to the failure, name the exact file and function where the invariant breaks, and explain how the earlier code let bad state through. Give the fix at the true source, not a patch at the symptom.

Turn on Thinking. Build [FEATURE] in [LANGUAGE / STACK]. Requirements: [LIST REQUIREMENTS]. Constraints: [PERFORMANCE, DEPENDENCIES, STYLE CONVENTIONS]. First outline your approach and the two or three key decisions with their trade-offs, then write the full runnable code with comments only on the non-obvious parts. List the assumptions you made and how I'd test each requirement. Confirm the code meets every requirement before finishing.

Use Web Dev. Build a [TYPE OF APP — e.g. task tracker] as a single-page app. Core screens: [LIST SCREENS]. Features: [LIST FEATURES]. Use [STACK / FRAMEWORK] and store data in [localStorage / the given API]. Make it responsive and clean with [STYLE — e.g. a minimal light theme]. Show me the working preview, then explain the file structure so I know where to extend it.

Design and implement a [METHOD] [ROUTE] endpoint in [FRAMEWORK]. It should [WHAT IT DOES]. Inputs: [PARAMS / BODY]. Define the request and response schemas, validate inputs and return proper status codes and error bodies, handle the obvious failure cases, and keep it idiomatic for [FRAMEWORK]. Return the handler code plus a short list of the edge cases you covered and any you'd want product to decide on.

Build a [FRAMEWORK] component called [NAME] that renders [DESCRIBE THE UI, OR ATTACH A SCREENSHOT]. Props: [LIST PROPS AND TYPES]. Handle these states: loading, empty, error, and populated. Keep styling in [CSS APPROACH], make it accessible (labels, keyboard focus, ARIA where needed), and don't pull in new dependencies. Return the component and a small usage example.

Turn on Thinking. I need to integrate [SERVICE / API] into my [STACK] app to [GOAL]. Here are the relevant docs and my current setup: [PASTE]. Write the integration code, handle auth, retries, rate limits, and errors, and keep secrets out of the source. Explain the request flow, call out anything in the docs that's ambiguous or a common gotcha, and tell me exactly what config or keys I need to supply.

Refactor this code for readability and maintainability without changing its behavior: [PASTE CODE]. Improve naming, reduce nesting, extract logic where it earns its place, and remove dead code. Keep it idiomatic for [LANGUAGE] and add no new dependencies. Return the refactored version first, then a short bullet list of what you changed and why, and confirm the public interface is unchanged.

Turn on Thinking. Review this code for security issues: [PASTE CODE]. Check for injection (SQL, command, template), missing input validation, auth and access-control gaps, unsafe deserialization, secrets in code, and unsafe handling of user data. For each finding, rate the severity, explain how it could be exploited in one or two sentences, and give the concrete fix. If something looks safe, don't invent a problem.

Turn on Thinking. This code is slower than I need: [PASTE CODE]. Context: [DATA SIZE, HOT PATH, WHAT'S ACCEPTABLE]. Identify the real bottlenecks — algorithmic complexity, unnecessary work in loops, N+1 queries, allocations — and rank them by expected impact. Give the optimized version, state the before-and-after complexity, and note any readability or correctness trade-off each change makes. Don't micro-optimize what won't matter.

Act as a careful reviewer. Here's a diff: [PASTE DIFF]. Here's the surrounding code for context: [PASTE]. Review it for correctness, edge cases, error handling, naming, and anything that would surprise a future reader. Group comments as blocking, worth-fixing, and nit, quote the exact line for each, and suggest the change. End with a one-line verdict: approve, approve with changes, or request changes.

Turn on Thinking. This module does too much and is hard to change: [PASTE CODE]. Propose a cleaner design: identify the distinct responsibilities, suggest how to split them, and draw the new boundaries and dependencies in plain text. Then show the refactored code for the first, highest-value split. Keep behavior identical, and flag any hidden coupling that makes a clean separation risky.

Write thorough unit tests for this function using [TEST FRAMEWORK]: [PASTE FUNCTION]. Cover the happy path, edge cases, invalid inputs, and boundary conditions. Name each test for the behavior it checks, keep them independent and readable, and mock [EXTERNAL DEPENDENCIES] where needed. Flag any behavior in the function that looks like a bug or is ambiguous enough to need a spec decision rather than silently testing it as-is.

Here's a function and its existing tests: [PASTE CODE AND TESTS]. Find the cases the current tests miss — empty and huge inputs, unicode, nulls, off-by-one boundaries, concurrent access, and malformed data. Add tests for the gaps in [TEST FRAMEWORK]. Where a property holds for all valid inputs (e.g. round-trips, invariants), write a property-based test for it and explain the property in one line.

Add documentation to this code: [PASTE CODE]. Write a docstring for each public function in [STYLE — e.g. Google / NumPy / JSDoc] covering purpose, parameters, return value, and any raised errors or side effects. Add inline comments only where the intent isn't obvious from the code — explain the why, not the what. Don't change any logic. Return the fully documented code.

Here's my project's code and structure: [PASTE KEY FILES / TREE]. Write a clear README in Markdown: a one-line description, what it does, install and setup steps, a minimal usage example that actually runs, the main configuration options, and how to run the tests. Keep it accurate to the code — don't document features that aren't there. Note anything a new contributor would trip over.

Explain what this code does to a developer new to [LANGUAGE / LIBRARY]: [PASTE CODE]. Start with a one-paragraph overview of its job, then walk through the tricky parts block by block, and call out any bugs, edge cases, or performance concerns you notice along the way. Skip the obvious lines and keep it concrete. End with the two or three things I'd need to know before changing it.

Here's my schema: [PASTE TABLES AND COLUMNS]. I'm on [DATABASE — e.g. PostgreSQL]. Write a query that [WHAT YOU NEED]. Use clear aliases, only the joins you need, and handle nulls and duplicates correctly. Return the query, a one-line explanation of what each join and filter does, and note any assumption about the data (e.g. that a column is unique). Suggest an index if the query would be slow at scale.

Write a regex for [FLAVOR — e.g. JavaScript / PCRE] that matches [WHAT TO MATCH] and does not match [WHAT TO EXCLUDE]. Here are real examples of both: should match [LIST], should not match [LIST]. Return the pattern, explain each part in plain English, and show it correctly classifying every example above. Warn me about any catastrophic-backtracking or edge-case risk in the pattern.

Use Code Interpreter. I've attached [CSV / spreadsheet]. Load it, then: clean [DESCRIBE THE MESS — missing values, inconsistent formats, duplicates], compute [WHAT YOU NEED — e.g. totals by category], and show me the result as a table and a quick chart. Print the row counts before and after cleaning so I can see what was dropped, and give me the cleaned file to download plus the Python you ran.

Turn on Thinking. This query is slow: [PASTE QUERY]. Schema and rough table sizes: [PASTE]. Here's the query plan if it helps: [PASTE EXPLAIN OUTPUT]. Explain why it's slow, then rewrite it to be faster while returning the same rows. Recommend specific indexes, note whether they help writes or storage, and show the before-and-after approach. Keep it valid for [DATABASE].

Turn on Thinking. I'm pasting my whole repo below. Read it, then give me: a one-paragraph summary of what the project does, the main modules and how they depend on each other, the entry points and data flow, and the three areas that look riskiest or most tangled. Point to exact files and functions. Don't summarize file by file — explain the system. Repo: [PASTE REPO].

Turn on Thinking. Here's my codebase: [PASTE REPO OR KEY FILES]. I want to migrate from [OLD — e.g. framework/version] to [NEW]. Produce a migration plan: what changes and why, the order to do it in so the app stays working, the risky spots that need manual review, and an estimate of effort per stage. Then show the migrated code for the first, self-contained step so I can validate the approach before committing to it.

You are working in my project with Qwen Code. Goal: [DESCRIBE THE CHANGE — e.g. rename a concept across the codebase, or add a field end to end]. First scan the project and list every file that needs to change and why, then propose the plan and wait for my go-ahead. Once I approve, make the edits, run [TEST / LINT COMMAND], and report what passed, what failed, and any file you weren't sure about.

Turn on Thinking. Here are my dependency manifest and lockfile: [PASTE]. Identify which packages are outdated, which have known-breaking major upgrades, and which look unmaintained or redundant. For each recommended upgrade, note whether it's a safe patch or a breaking change, what in my code would need to adapt, and the order I should tackle them in. Flag any dependency I could drop entirely and what I'd replace it with.