How To Ask AI To Change Your Code Clearly

A good AI coding request makes the intended change clear without pretending you already know every implementation detail.

You should be able to explain:

• What needs to change.
• What should happen afterward.
• What should remain unchanged.
• Where the change begins and ends.
• Which important questions are still unresolved.

This is different from simply giving AI more context.

In the previous blog, we looked at helping AI understand the project it is working on.

Now the task is to turn an intention such as:

“Make task editing better.” Into something that can actually be implemented and checked.

The goal is not to write an enormous prompt.

It is to remove the ambiguity that could materially change the result.

Start With The Change, Not The Implementation

When people work with AI, they often jump straight to a technical solution.

For example:

“Add another state variable and open a modal when the button is pressed.”

That may be the right implementation.

But perhaps your real intention is simply:

“When a user taps Edit on a task, they should be able to change its title and save the updated task.”

The second version is often a better starting point because it tells AI what outcome is required without unnecessarily deciding how the code must achieve it.

This matters because your suggested implementation may be:

• More complicated than necessary.
• Inconsistent with the existing project.
• Based on an incorrect assumption.
• Solving the symptom rather than the real problem.

AI should not be allowed to invent the product requirement.

But it can often help determine the implementation.

A strong request therefore begins with:

What should become true after this change?

Describe One Concrete Change

Requests become difficult when different intentions are bundled together.

Imagine you say:

“Improve the task screen, add editing, make it look cleaner, fix the sorting, add recurring tasks, and make it faster.”

There may be six different pieces of work inside that sentence.

Each one could affect different parts of the app.

If AI attempts all of them together, several problems appear.

It becomes harder to understand what changed.

It becomes harder to identify which change caused a problem.

It becomes harder to check whether each behaviour is correct.

And AI has more opportunities to make assumptions about how the pieces should interact.

A clearer request might begin with:

“Add the ability to edit the title of an existing task.”

That gives the work a definite centre.

This does not mean every request must produce only one tiny code change.

A coherent feature may naturally require some files or behaviours.

The important distinction is whether those changes serve one understandable outcome.

Blog 13 will go further into breaking large pieces of work into smaller coherent parts.

For now, start by making the intended change identifiable.

Say What The User Should Be Able To Do

A feature request becomes clearer when it describes observable behaviour.

Compare:

“Implement task editing.”

With:

“From the task details screen, the user can choose Edit, change the task title, save it, and then see the updated title.”

The second version gives you something you can eventually check.

It describes behaviour from the user’s perspective rather than merely naming a feature.

Useful requests often answer questions such as:

• Where does the interaction begin?
• What can the user do?
• What should happen when they complete the action?
• What should they see afterward?

This connects directly to Blog 6, where we defined correct behaviour through requirements and examples.

You do not need to repeat the entire specification every time.

But your request should contain enough observable behaviour to distinguish a correct implementation from one that merely looks plausible.

Include The Important Rules

Features usually have rules.

Suppose the user edits a task title.

Can the title be empty?

Can it contain only spaces?

Is there a maximum length?

Can a completed task still be edited?

What happens if the user changes the title and then cancels?

If those questions already have answers, include the ones that matter.

For example:

“The title cannot be empty. If the user cancels, the existing title must remain unchanged.”

Those two sentences remove other possible interpretations.

You do not need to list every imaginable case.

Focus on rules that could change what AI builds.

A useful test is:

“Could two reasonable developers implement this request differently because I have not stated this rule?”

If the answer is yes and the difference matters, clarify it.

Define The Boundary Of The Change

One of the most useful things you can tell AI is where the task stops.

Suppose you want to add editing to task titles.

AI might notice that the task model also contains a date, notes, category, priority, and completion state.

Should all of those become editable too?

If you do not say, AI has to decide.

A clear boundary might be:

“For this change, only the task title should be editable. Do not add editing for the date, notes, category, or completion state.”

The word boundary is useful here.

A boundary tells AI:

• Which behaviour belongs to this task.
• Which nearby behaviour does not.
• Which files or systems should not be expanded unnecessarily.
• Which improvements can wait.

This is especially important because AI often sees additional opportunities while working.

Some of those suggestions may be good.

But a good idea discovered during one change does not automatically belong inside that change.

Keeping boundaries clear protects the project from accidental expansion.

Say What Must Stay The Same

A change rarely exists in isolation.

Suppose task titles can already be created, displayed, saved, and restored after the app closes.

You now want to make them editable.

A useful request might include:

“Existing task creation, completion, deletion, and persistence should continue to behave as they do now.”

This creates a preservation requirement.

You are not asking AI to redesign the entire task system.

You are changing one capability inside it.

This matters because AI can sometimes produce a clean-looking solution by replacing more existing code than necessary.

A request that states what must remain intact reduces that risk.

The general pattern is:

Change this. Preserve that.

That simple distinction can make a request dramatically clearer.

Distinguish Behaviour From Appearance

A request can involve what the software does, what it looks like, or both.

These should be made explicit.

Suppose you say:

“Make the task editing screen better.”

Does “better” mean:

• Easier to understand?
• Visually cleaner?
• Faster?
• Fewer taps?
• Better validation?
• More consistent with another screen?

The word describes your judgement, not the desired result.

Instead, separate the concerns.

For example:

“The editing behaviour already works. Change only the layout so the title field and Save button follow the same visual structure as the task creation screen.”

Or:

“Keep the current design. Change only the behaviour so “Save” is disabled when the title is empty.”

Those are very different tasks.

Clear requests tell AI whether the problem is behavioural, visual, structural, or some combination of them.

Use Examples When Words Leave Room For Interpretation

Examples are often the fastest way to make a requirement precise.

Suppose your app groups tasks under headings.

You could say:

“Group tasks appropriately by date.”

But “appropriately” requires interpretation.

An example is clearer:

“A task due today appears under Today. A task due tomorrow appears under Tomorrow. Later tasks appear under Upcoming.”

Examples are especially useful for:

• Sorting.
• Formatting.
• Calculations.
• Validation.
• State changes.
• Conditional behaviour.
• Edge cases.

They are not a replacement for the general rule.

They help reveal what the rule means.

For example:

“Sort tasks by due date from earliest to latest. For example, a task due on Monday should appear above one due on Wednesday.”

Now both the rule and an example are visible.

Do Not Hide Uncertainty

Sometimes you know what problem you want solved but have not decided exactly how the experience should work.

That is not a reason to let AI quietly choose.

Suppose you want users to edit a task, but you have not decided whether editing should happen:

• On a separate screen.
• Directly inside the task list.
• In a small overlay.
• On the existing details screen.

You could ask:

“Add task editing.”

AI will choose one.

But that means a product decision has been made without you noticing.

A better request is:

“I want users to be able to edit an existing task, but I have not decided whether editing should happen on the details screen or in a separate editing screen. Before implementing it, compare those two approaches for this project.”

This is an important habit.

Unresolved decisions should be made visible rather than filled silently with assumptions.

Not every uncertainty must stop the work.

Some implementation details can safely be left to AI.

The important question is whether the uncertainty affects the product, architecture, data, security, or another meaningful project decision.

If it does, resolve it deliberately.

Separate Decisions You Own From Decisions AI Can Make

You do not need to specify everything.

That would defeat much of the value of using AI.

The useful distinction is between decisions that affect what you are building and decisions about the mechanics of implementing it.

You might decide:

“Editing must happen from the existing task details screen.”

But allow AI to decide:

• Which helper function should handle the update.
• How to organise small pieces of internal logic.
• Which existing project pattern should be reused.

You remain responsible for the important result and constraints.

AI can handle implementation decisions within those boundaries.

This balance avoids two extremes.

In one extreme, you tell AI almost nothing and let it design the product for you.

In the other, you prescribe every line of implementation even when you do not have enough technical knowledge to know whether your approach is good.

A stronger approach is:

Be precise about the outcome and important constraints. Be flexible about implementation details that do not materially affect the product.

State Whether AI May Change The Existing Structure

Sometimes a feature can be implemented cleanly within the current design.

Sometimes the existing design makes the feature awkward.

If AI is allowed to restructure the project whenever it sees an opportunity, a small request can turn into a large rewrite.

If AI is never allowed to change structure, you may force increasingly awkward solutions into poor foundations.

You can handle this explicitly.

For a small change:

“Use the existing structure. Do not refactor unrelated code.”

For a larger problem:

“Prefer the existing structure, but if it prevents a reliable implementation, explain the structural change you recommend before making it.”

The second version is especially useful.

It does not forbid architectural judgement.

It prevents that judgement from becoming an invisible side effect of another task.

Ask For Questions Before Code When Important Details Are Missing

Sometimes the strongest instruction is not:

“Implement this.”

It is:

“Tell me what you still need to know before implementing this.”

This works particularly well when the change affects many behaviours.

For example:

“I want users to postpone an existing task to another day. Before making changes, identify any unresolved product or data decisions that would materially affect the implementation.”

AI might ask:

• Can completed tasks be postponed?
• Should postponing preserve the original due date anywhere?
• What happens to reminders?
• Can the user choose any date in the past?

Those questions expose decisions hidden inside the seemingly simple word postpone.

You do not need AI to ask twenty minor questions before every task.

The instruction should focus on uncertainties that could materially change the solution.

A useful phrasing is:

“If anything important is ambiguous, ask before assuming.”

Be Careful With Words That Sound Clear But Are Not

Many common instructions carry very little information.

Examples include:

• “Make it better.”
• “Fix it.”
• “Clean this up.”
• “Make it modern.”
• “Improve the UX.”
• “Optimise it.”
• “Make it scalable.”
• “Make it professional.”
• “Make the code cleaner.”

These requests may express a valid intention.

But they do not define what success looks like.

Suppose you ask AI to:

“Make this screen cleaner.”

It might remove information you wanted.

It might change colours.

It might reduce spacing.

It might restructure the navigation.

All could reasonably be interpreted as “cleaner.”

Instead, explain the observable problem.

For example:

“The screen currently shows five controls at once, even though three are rarely used. Keep the two main actions visible and move the three secondary actions behind the existing “More” menu.”

Now “cleaner” has become a specific change.

Whenever you use a vague word, ask:

“What would I actually expect to be different when this is finished?”

Write that instead.

Avoid Asking For A Feature And A Diagnosis At The Same Time

There is an important difference between:

“Add a loading indicator.”

and:

“The screen freezes for three seconds, so add a loading indicator.”

The second request assumes the solution before the cause has been understood.

Perhaps a loading indicator is appropriate.

Perhaps the freeze is a bug that should be fixed instead.

When the underlying problem is uncertain, separate investigation from implementation.

For example:

“Opening this screen sometimes freezes the interface for about three seconds. Investigate the cause first. Do not add a workaround until we understand why it happens.”

That is a clearer task because it matches your actual knowledge.

Blog 21 will explore debugging in much greater depth.

The principle here is simply not to disguise a guess as a requirement.

Tell AI How You Will Recognise Completion

One of the strongest parts of a request is a simple description of what should be true when the work is finished.

Suppose the feature is task editing.

Completion might mean:

• A user can open an existing task.
• They can change its title.
• Saving updates that task rather than creating another one.
• The updated title appears in the task list.
• The change remains after closing and reopening the app.
• Cancelling leaves the original task unchanged.

These statements function as acceptance criteria.

Acceptance criteria are conditions that must be satisfied for the work to count as complete.

You do not need formal project-management language to use them.

They can simply be a short list of observable outcomes.

They are valuable because they create a shared definition of success between you and the AI.

Later, they also give you something concrete to test.

A Clear Request Can Still Be Short

Good prompting is sometimes mistaken for long prompting.

Length is not the goal.

Compare this vague request:

“Can you improve task editing and make sure everything works nicely?”

With this one:

“Allow users to edit the title of an existing task from the task details screen. The title cannot be empty. Saving must update the existing task and persist after the app restarts. Cancelling must leave the task unchanged. Do not add editing for any other task fields or change existing task creation, completion, or deletion behaviour.”

The second request is not particularly long.

It is simply specific where specificity matters.

A strong request tends to contain information rather than decoration.

A Useful Structure For AI Coding Requests

You do not need to use a rigid template for every request.

But when a change is substantial, it can help to think through five parts.

1. The change

What should become different?

“Allow users to edit the title of an existing task.”

2. The expected behaviour

What should the user observe?

“The updated title should appear throughout the app and remain after the app is reopened.”

3. The rules

What conditions govern the behaviour?

“The title cannot be empty.”

4. The boundaries

What is outside this piece of work?

“Do not add editing for any other fields.”

5. The unresolved questions

What important decisions have not yet been made?

“If the current details screen cannot support editing cleanly, explain the alternatives before changing the navigation.”

Together, those five pieces turn an intention into actionable work.

Compare A Weak Request With A Stronger One

Imagine the errands app already allows users to create, complete, and delete tasks.

You now want editing.

A weak request might be:

“Add editing to tasks.”

AI has to decide:

• Which fields are editable.
• Where editing happens.
• What validation exists.
• What Save does.
• Whether Cancel exists.
• Whether other task behaviour should change.
• Whether the storage system needs replacing.
• What happens to existing tasks.

A stronger request might be:

“Add editing for existing task titles. Editing should begin from the current task details screen. The user can change the title and either Save or Cancel. Titles cannot be empty. Save updates the same task and the change must persist after the app closes. Cancel leaves the original title unchanged. Do not make the date, completion state, or other task fields editable. Keep the existing task storage system and existing create, complete, and delete behaviour. If the current structure makes this unreliable, explain why before making a broader structural change.”

That request gives AI considerable freedom to write the code.

But it does not give AI freedom to redefine the feature.

That is the balance you want.

Do Not Treat The First Request As A Contract With Reality

Even a well-written request may reveal new information once AI inspects the code.

Perhaps the task details screen does not actually own the information you thought it did.

Perhaps changing the title also affects another part of the app.

Perhaps an earlier implementation choice makes the requested behaviour unsafe.

A clear request does not mean:

“Do exactly this even if new evidence shows the plan is wrong.”

It means:

“This is the result and boundary I currently intend. Tell me if the existing project creates an important conflict.”

Software work is iterative.

The purpose of clarity is not rigidity.

It is to make deliberate changes possible.

Good Requests Reduce Accidental Decisions

When an AI coding request is vague, implementation still happens.

The missing decisions do not disappear.

Something—makes them.

If you do not specify whether Cancel should discard changes, AI may decide.

If you do not specify whether existing information must remain compatible, AI may decide.

If you do not define the boundary of the feature, AI may decide how far it should expand.

Some of those decisions are harmless implementation details.

Others belong to you.

The skill is learning the difference.

Before sending a meaningful coding request, ask:

What am I asking to change?

What should be true afterward?

What must remain true?

Where does this task stop?

What important question am I still leaving unanswered?

If those answers are clear, AI has much less room to solve a different problem from the one you intended.

But even a clear request can become too large to implement safely in one move.

In Blog 13, we will look at how to break large software changes into smaller, coherent parts so each one can be understood, implemented, and checked before moving on.