How To Give AI Enough Context To Work On Your Code

AI writes better code when it understands the project around the code.

A request such as:

“Add editing to my tasks” may sound clear to you because you already know what a task is, where tasks are stored, how the app currently behaves, which screen displays them, and what you do not want changed.

The AI may know none of that.

It can still produce code. But when important context is missing, it has to fill the gaps with assumptions.

Sometimes those assumptions happen to match your project.

Sometimes they create the wrong behaviour, duplicate something that already exists, change an important decision, or solve the right problem in the wrong part of the app.

The goal is therefore not to give AI as much information as possible.

It is to give AI the information that changes how the work should be done.

Context And Instructions Are Different

Before going further, it helps to separate two ideas.

Context describes the situation.

Instructions describe what you want done.

For example:

“Tasks are stored locally and remain available after the app closes” – is context.

“Allow the user to edit an existing task” – is an instruction.

Both matter, but they serve different purposes.

If AI receives the instruction without the context, it might introduce a completely different way of storing edited tasks.

If it receives the context but no clear instruction, it understands the project but does not know what you want changed.

This blog focuses on the first half: giving AI an accurate picture of the situation.

Blog 12 will focus on turning your intention into a clear request.

AI Does Not Automatically Share Your Mental Model

As you work on an app, you gradually build a mental model of it.

You remember things such as:

• Why a feature exists.
• Which behaviour was intentional.
• Where information is stored.
• What has already been tried.
• Which parts of the app should remain unchanged.
• Why you rejected an earlier approach.
• What users are supposed to experience.

That knowledge may feel obvious because you have been living with the project.

AI only knows the parts available in its current context.

Depending on how you are working, it may have access to some project files, previous conversation messages, documentation, or other information.

But you should not assume it knows something simply because you know it.

This creates a useful habit:

Before asking AI to change the project, ask yourself what facts you are relying on that the AI may not know.

Those facts are often the context it needs.

Start With The Relevant Product Context

Code exists to produce behaviour for someone.

That means technical context alone is not always enough.

Suppose the errands app from earlier blogs has a home screen showing today’s tasks.

You ask AI to add an option to hide completed tasks.

The implementation depends partly on why the screen exists.

If the purpose is to help users see only what still needs attention, hiding completed tasks may make sense by default.

If the screen is supposed to give users a complete record of everything they did today, automatically hiding them may work against the intended experience.

The code cannot answer that product question by itself.

Useful product context might include:

“The home screen is meant to show what the user still needs to do today. Completed tasks remain accessible in task history.”

That one sentence changes how the feature should be approached.

You do not need to repeat the entire product vision every time.

Give the part that affects the current decision.

Explain The Current Behaviour Before Changing It

AI needs to know what already happens.

This is particularly important when you are modifying an existing feature rather than creating something completely new.

Imagine your app currently lets a user tap a task to mark it complete.

Now you want tapping the task to open its details instead.

If you simply say:

“Make tapping a task open the details screen.”

AI may replace the old behaviour without considering whether task completion still needs another interaction.

A more useful description of the current situation is:

“At the moment, tapping a task marks it complete. I now want task tapping to open its details, but users must still be able to mark tasks complete.”

You have not yet fully specified the solution.

You have made the existing behaviour visible.

That helps prevent accidental loss of functionality.

A useful pattern is:

What happens now → what is changing → what must continue to work.

Blog 12 will develop the change itself more precisely.

For context, the important thing is that AI understands the starting point.

Give AI The Relevant Code, Not Random Code

When AI needs to modify existing software, it usually needs to see the code that controls the behaviour.

But sending large amounts of unrelated code can be almost as unhelpful as sending too little.

Suppose a button on your task screen is behaving incorrectly.

The AI may need:

• The screen containing the button.
• The code that runs when the button is pressed.
• The data being changed.
• Any nearby code that determines whether the button is shown.

It probably does not need an unrelated settings screen.

The principle is:

Provide enough surrounding code to understand the behaviour, not every file merely because it belongs to the project.

This becomes easier as your understanding of the app improves.

The previous chapter taught you to recognise interface code, application logic, storage, external services, data flow, and dependencies.

Those ideas help you ask:

“Which parts of the system participate in this behaviour?”

Those are the places AI may need to inspect.

Sometimes The Best Context Is The Project Itself

If your AI tool can inspect the project, you do not always need to manually copy every relevant file into the conversation.

Instead, you can direct it toward the right area.

For example:

“Before changing this, inspect the task list screen, the task model, and the code responsible for saving tasks. Explain how task completion currently works.”

This is valuable because it separates understanding from changing.

AI first builds a picture of the existing implementation.

Only after that should it modify the project.

This can prevent a common vibe-coding failure: asking AI to implement a feature before it understands how the current version already works.

For significant changes, inspection is often a better first move than immediate generation.

Tell AI About Important Constraints

A constraint is something that limits which solutions are acceptable.

Suppose your app stores all user information on the device because you deliberately want the first version to work without creating accounts or sending personal information to a server.

You ask AI to add synchronisation between two screens.

Without the storage constraint, it may suggest introducing a cloud database.

Technically, that could solve the problem.

Architecturally, it could contradict a major project decision.

Relevant constraints might include:

• The platforms the app must support.
• Whether the app must work offline.
• Where information is allowed to be stored.
• Technologies already chosen for the project.
• Whether adding another dependency is acceptable.
• Performance or accessibility requirements.
• Behaviour that must remain backward compatible.
• Areas of the project that should not be changed.

Notice how this builds directly on Blog 10.

A dependency decision becomes context for future AI work.

If you previously decided:

“Do not add another charting dependency because the project already has the capability we need,” future AI work should know that before attempting to solve another chart problem.

Otherwise, the same decision may be unknowingly reopened.

Separate Requirements From Constraints

These two ideas are related, but they are not identical.

A requirement describes something the app needs to do.

For example:

“Users must be able to edit a task title.”

A constraint limits how the solution can be implemented or what else may change.

For example:

“Keep tasks stored locally using the existing storage system.”

That distinction helps AI reason about the solution.

The first tells it the destination.

The second helps define the road it is allowed to take.

Blog 6 covered defining correct behaviour through requirements.

Here, the lesson is that those existing requirements and constraints become useful context whenever AI works on the relevant part of the app.

Show The Problem, Not Just Your Interpretation Of It

When something is broken, developers often describe what they think caused the problem.

For example:

“The database isn’t saving properly.”

But perhaps the database is working correctly and the screen simply fails to reload the saved information.

If AI receives only your diagnosis, it may begin repairing the wrong thing.

Better context includes the evidence you actually observed:

“I create a task and it appears immediately. After closing and reopening the app, the task is gone.”

You can also provide useful evidence such as:

• Error messages.
• Unexpected output.
• Steps that consistently cause the problem.
• Logs.
• Screenshots where relevant.
• The behaviour you expected.
• The behaviour you actually saw.

This does not mean your hypothesis is useless.

You can say:

“I suspect the problem is related to saving, but I am not certain.”

That distinguishes evidence from interpretation.

Blog 21 will cover debugging as a full investigative process.

For now, the important habit is simple:

Give AI the facts of the problem before asking it to accept your explanation of the problem.

Include Relevant History When The Present Code Does Not Explain It

Sometimes looking at the current code is not enough.

A project may contain a strange-looking decision for a good reason.

Imagine AI sees duplicated logic and proposes combining it.

Normally, removing unnecessary duplication might be sensible.

But perhaps the two flows were deliberately separated because one behaves differently on an older platform version.

The current code may show what is different without showing why.

That missing reasoning is project history.

Useful historical context might include:

“These two flows were deliberately kept separate because the older platform behaves differently.”

Or:

“We previously tried loading this information when the screen opens, but it caused duplicated requests, so we moved it here.”

Without that context, AI can accidentally undo previous learning.

This is one reason important decisions should eventually be preserved outside individual conversations.

Blog 14 will cover that directly.

Tell AI What Is Already Working

When something needs improvement, it is easy to focus only on the broken or missing part.

But the working behaviour may be equally important context.

Suppose the task creation screen correctly:

• Creates tasks.
• Saves their date.
• Stores them after the app closes.
• Returns the user to the task list.

The only problem is that newly created tasks appear in the wrong order.

If AI knows only that “task creation needs fixing,” it has a much wider area in which to make changes.

If it knows that creation and storage already work correctly, it can narrow its attention to ordering.

A useful statement might be:

“Task creation and persistence are already working. The problem is only the order in which tasks appear.”

That protects working behaviour from unnecessary modification.

The more precisely you identify what is already correct, the less reason AI has to rebuild it.

Context Should Include What Must Not Change

Sometimes the most valuable sentence is:

“Do not change…”

Suppose you are adjusting how the home screen displays task progress.

You might say:

“Do not change how progress is calculated. Only the way it is displayed needs work.”

That establishes a boundary.

This is particularly helpful when several parts of the project are connected.

AI may notice what appears to be an easier solution by changing another piece of the system.

Without context, it does not know whether that is acceptable.

You should not freeze the entire project unnecessarily. Sometimes AI will discover that a broader change genuinely is needed.

In that situation, a good response is not to ignore the constraint.

It is to explain the conflict:

“The requested behaviour cannot be implemented reliably without changing this part. Here is why.”

That gives you a decision to make instead of silently changing the architecture.

More Context Is Not Always Better

Once people understand that AI needs context, another mistake can appear:

They give it everything.

Entire conversations.

Every project file.

Long documents unrelated to the task.

A complete history of every decision ever made.

This can make the important information harder to identify.

Good context is relevant context.

Consider a change to the task editing screen.

AI may need to know about:

• The task data structure.
• How tasks are saved.
• The existing editing screen.
• Validation rules for task titles.
• The behaviour expected after saving.

It probably does not need detailed information about your app’s onboarding animation.

The right question is not:

“What information can I give AI?”

It is:

“What information could change the correct solution?”

That is a much stronger filter.

Context Can Become Outdated

Another danger is giving AI information that used to be true.

Perhaps an earlier conversation says:

“The app does not support recurring tasks.”

Two weeks later, recurring tasks are added.

If AI receives the old statement without the new project state, it may make decisions based on outdated information.

This is why current code and current behaviour should usually take priority over remembered descriptions when they conflict.

When necessary, tell AI explicitly:

“Some earlier discussions may be outdated. Treat the current project files and the requirements below as the current source of truth.”

Projects evolve.

Your context must evolve with them.

Preserving project decisions, which we will cover in Blog 14, is partly about keeping that knowledge useful rather than merely accumulating more of it.

Let AI Identify Missing Context

You do not always know what information matters.

That is normal.

You can ask AI to identify what it needs before implementation.

For example:

“Before making changes, inspect the relevant code and tell me whether you are missing any information that would materially affect the implementation.”

Or:

“What assumptions would you have to make if you implemented this now?”

This is a powerful question.

Assumptions reveal missing context.

If AI says:

“I would need to assume that completed tasks remain editable,” you now know there is a product decision that needs clarification.

If it says:

“I would assume that the existing local storage should continue to be used,”

you can confirm or correct that assumption.

The aim is not to eliminate every possible unknown.

It is to surface unknowns that could change the result.

Match The Amount Of Context To The Consequence

Not every change requires a project briefing.

If you ask AI to adjust a small amount of spacing on one screen, the relevant context may be tiny.

If you ask it to change how user information is stored, the consequences are much larger.

The necessary context grows with the scope and risk of the decision.

A useful rule is:

The more parts of the app a change can affect, the more existing context AI should understand before making it.

For a small visual change, perhaps one file is enough.

For a change to storage, AI may need to understand:

• The data being stored.
• Where it is currently stored.
• Which parts of the app read it.
• Which parts modify it.
• What happens to information users already have.
• Existing constraints around storage.

You do not need the same process for every task.

You need enough context for the consequences involved.

A Practical Context Check

Before asking AI to work on an existing feature, you can quickly check whether it understands five things:

1. What is this part of the app for?

Give the relevant product purpose when it affects the decision.

2. How does it work now?

Describe or let AI inspect the current implementation and behaviour.

3. What existing decisions matter?

Mention important architecture choices, constraints, dependencies, or requirements.

4. What evidence do we have?

For a problem, provide what actually happens rather than only your theory about why.

5. What must remain intact?

Identify working behaviour or project boundaries that should not be casually changed.

You will not need every item every time.

They are questions to help you notice missing context, not a form that must be completed before writing code.

Do Not Make AI Guess The Project

Vibe coding becomes much more reliable when AI does not have to reconstruct your project from fragments and assumptions every time you ask for something.

Your job is not to explain every line of code yourself.

It is to make sure the AI has access to the facts that matter.

That may mean providing:

• Relevant project purpose.
• Existing behaviour.
• Relevant code.
• Technical constraints.
• Previous decisions.
• Evidence about a problem.
• Working behaviour that must remain intact.

Sometimes you provide those facts directly.

Sometimes you ask AI to inspect the project and establish them first.

Either way, the principle is the same:

Understand the situation before changing the situation.

Giving AI good context does not guarantee good code.

It does something more fundamental: it reduces the number of important things the AI has to guess.

Once the context is clear, the next challenge is deciding exactly what you want AI to do with it.

In Blog 12, we will look at how to turn an intention into a clear coding request, including the change you want, its boundaries, the expected behaviour, and the questions that should be resolved before implementation.