كتابة Prompt للكود: إزاي تطلب من الذكاء الاصطناعي صحWriting prompts for code: how to ask an AI properly

Writing a prompt that produces good code means giving the tool three things before asking for a single line: the context it is working in, exactly what you want and what the result should look like, and the constraints that must not be broken. Most bad code from AI tools comes from an incomplete request, not a weak tool. This post has seven habits and a template to copy.

Why a short request gives bad code

When you write “make me a sign-up form”, the tool faces a thousand decisions nobody told it about: which language, which library, which fields, where validation runs, how errors show, where data is stored.

It will not ask you about all of that. It will guess. And the guess leans towards the most common solution in its training, not the one that fits your project. The result is code that is “right” in general and wrong for you: a library you do not use, a style unlike your other files, and assumptions about a database that does not exist.

The tool does not read your mind. Whatever is not in the request, it will make up.

Habit 1: give context first

Before the task, say where you are:

• Stack: language and version, framework, important libraries.
• Project shape: where the relevant files are and what calls what.
• Style: how you name things, whether you comment, whether there is a linter.
• An example of yours: a similar file written the way you want. This beats any description.

If your tool reads the project itself, this context goes once into the project instructions file and it reads it every time. In a plain chat, paste it at the top of the message.

Habit 2: define the task and the output

Compare the two:

Before:
Make a function that validates email.

After:
Write a TypeScript function isValidEmail that takes a string and returns boolean.
- Reject empty input and leading/trailing spaces.
- No complex regex: an @ followed by a dot is enough.
- No external libraries.
- Include 6 Vitest tests: 3 valid, 3 invalid.
Return code only, no explanation.

The second is three lines longer and saves three rounds of edits. Notice what it fixed: the name, input and output, edge cases, what is forbidden, the tests, and the reply format.

Habit 3: state constraints and prohibitions

Tools like to add. You ask for a small change and find the file rewritten, a library added and names changed. Close that door explicitly:

• “Change this function only, leave the rest of the file alone.”
• “Do not add any new dependency.”
• “Keep the same function signature because other code calls it.”
• “It must work without JavaScript in the browser.”
• “Do not change existing tests to make them pass.”

The last one matters: a tool pushed to “make the tests pass” may edit the test instead of fixing the code.

Habit 4: ask for a plan before code

For anything bigger than one function, do not ask for code straight away. First ask:

Before writing any code:
1. Tell me how you understood the task in 3 lines.
2. Write the plan: which files change and what changes in each.
3. Tell me what is unclear and needs my decision.
Wait for my approval.

Fixing a wrong plan takes a minute. Fixing 400 lines built on a wrong understanding takes an hour. And often the plan shows you that your own request was incomplete.

Habit 5: split the task

A big request produces a lot of code, and nobody really reviews a lot of code. Split it:

1. Data shape and types.
2. The core function and its tests.
3. Wiring to the interface.
4. Error and loading states.

Each step is tried and committed to Git before the next. If a step goes wrong you roll back one step, not the project. If Git is still unfamiliar, see Git for beginners.

Habit 6: give the full error

“It does not work” is not information. When something breaks, send:

• The full error message with the stack trace, copied, not typed from memory.
• Exactly what you did before it broke.
• What you expected and what happened.
• What you tried that did not help.

And ask it to find the cause before proposing a fix: “explain the cause first, then suggest the smallest change that fixes it”. That avoids covering the symptom instead of treating the illness.

Habit 7: review as you would a colleague’s work

The generated code is not the end of the job. Before accepting it:

• Read the change line by line (the diff), not the whole file.
• Run it yourself. “It should work” is not evidence.
• Look for what was added without being asked.
• Ask the tool itself: “which cases will this code fail on?” The answer will surprise you.
• For anything with sign-in, money or personal data, read it twice.

The difference between this and accepting whatever comes out is explained in Vibe coding: what it is and when to trust it.

A template to copy

## Context
Project: [its type in one line]
Stack: [language, framework, libraries]
Relevant files: [paths]
Style: [example or similar file]

## Task
[one clear sentence]

## Details
- Inputs: ...
- Outputs: ...
- Edge cases: ...

## Constraints
- Do not change anything except: ...
- No new libraries.
- [any other condition]

## How I know it is done
- [a test or visible behaviour]

## Reply format
Plan first, then wait for my approval.

You do not have to fill every field every time. But when the result is bad, go back to the template and see which field was empty. You will usually find the cause there.

Want to understand the tools that carry out these requests on your project by themselves? Read AI agents: what they are and how they work. And if you want to use the same approach across your work and not only in code, that is the subject of the AI automation course.