How to Prompt ChatGPT for Coding

Prompt ChatGPT for coding by describing the engineering decision, not only the code you want back. Give it the relevant code or repository context, the behavior to preserve, a concrete outcome, and a way to verify the result.

“Write a function that does X” can be enough for a small utility. It is not enough when a change touches user behavior, a shared contract, or a production system.

Before asking for code, state four things:

• What exists now: the relevant component, function, API, or failure.
• What should change: a user-visible or system-visible outcome.
• What must not change: compatibility, performance, accessibility, contracts, or public APIs.
• How to check it: tests, reproduction steps, type checks, or manual acceptance criteria.

If you use a long-running ChatGPT workspace, keep the architecture notes, requirements, and relevant files together. When your plan supports ChatGPT Projects, you can attach reference files and project-specific instructions to a dedicated workspace—check your current plan and sharing controls before uploading source material.

ChatGPT is strongest when each thread has one engineering goal and a bounded artifact set:

• paste the failing test and the function it exercises, not the whole repository;
• ask for a plan or hypothesis list before a multi-file patch;
• say whether you want explanation, a diff, tests, or all three in separate replies;
• restate constraints when the thread drifts into a broader refactor.

That keeps ChatGPT from treating a debugging chat like a greenfield build.

Avoid this:

Build a file uploader component.

It does not define ownership, error handling, file limits, accessibility, or the surrounding UI contract.

Use a bounded request instead:

We have a React settings page that already owns form submission and error
messages. Add a file uploader to the existing form.

Outcome: A user can select one PNG or JPEG under 5 MB, see the selected
filename, remove it before submit, and receive the existing localized error
message for invalid files.

Constraints: Do not add a new state library, do not create an upload endpoint,
and keep the current submit handler as the single owner of form state.

Return the smallest set of changed files, explain each change, and include
tests for invalid type, size limit, remove, and successful selection.

The request makes the component smaller because it rules out unnecessary architecture.

For debugging, ask for a hypothesis and a reproduction path before you ask for a patch:

Symptom: The save button remains disabled after an API retry succeeds.

Expected behavior: The button becomes available after the successful retry.
Observed behavior: The response data appears, but the button stays disabled.

Relevant context: The button depends on isPending and form.isDirty. This began
after retries were added to the mutation hook.

First, list the most likely state transitions and the evidence needed to
confirm each. Then propose the smallest fix and the regression test.

This is safer than “fix the disabled button” because it asks ChatGPT to distinguish a stale state bug from a validation or UI rendering problem.

Refactoring requests need a stronger preservation clause:

Refactor the pricing card list to remove duplicated plan rendering logic.

Preserve: public props, analytics event names, checkout destinations, keyboard
behavior, loading states, and the existing mobile layout.

Scope: Limit changes to the pricing feature and its directly related tests.
Do not introduce a design-system abstraction unless the existing primitive
cannot express the shared behavior.

Acceptance criteria: Snapshot or interaction tests cover each plan state, and
the rendered links and event payloads stay unchanged.

Before editing, identify the duplication and any hidden behavior that the two
cards currently implement differently.

The phrase “preserve behavior” is not enough on its own. Name the behavior that matters.

Do not ask for “tests for this component” without a contract. Name the scenarios:

Write tests for the password-reset form using the existing test stack.

Cover:
1. an invalid email shows the localized validation message;
2. submit sends the normalized email once;
3. a network error keeps the entered value and shows the existing error state;
4. a successful response announces the confirmation without exposing whether
   an account exists.

Do not mock implementation details. Prefer accessible roles and labels.

This tells the assistant what the user must be able to do and which privacy behavior cannot regress.

An explanation prompt should request an evidence trail, not a summary:

Explain how authentication state reaches the billing screen in this repository.

Trace the path from provider to route guard to checkout call. Name the files
and exported symbols involved. Separate confirmed behavior from assumptions,
and list what you would inspect next if any part is unclear.

That format makes it easier to spot a missing dependency or an invented connection.

ChatGPT is more reliable when you give it the narrowest context that answers the question:

• a failing test plus the code it exercises;
• the component and the hook that owns its state;
• a request/response example with sensitive values removed;
• the project conventions that constrain the change;
• a short list of files that are intentionally out of scope.

Do not upload secrets, production access tokens, customer data, or private logs you are not allowed to share. Replace those values with realistic redactions and keep the behavior you need to reason about.

For the general framework behind these prompts, read how to write better AI prompts. For a role-based set of implementation and review patterns, continue with prompt engineering for developers. Use prompt engineering examples for software engineers when you want a worked before-and-after request, and use the production debugging prompt templates before investigating a live issue.

Generated code is a proposal. Run the relevant tests, inspect the diff, and exercise the affected path yourself. When the work involves command output, errors, or shell scripts, reproducing the workflow is part of validation—not an optional extra. Use the browser-based command-line practice area to build that habit with real command input and feedback.