Making Local Code Changes with Codex Efficiently

Welcome back! In the previous lesson, you learned how to use the Codex interface to help with your coding tasks. Now, let’s focus on how to make local code changes efficiently using Codex.

When you want Codex to update your code, the way you write your prompt is very important. Clear and specific prompts help Codex understand exactly what you want, which leads to faster and more accurate results. If your description is vague, you will make Codex "think" for 5-10 minutes or more. In this lesson, you will see how to guide Codex step by step for backend and frontend changes in a Django project.

Let’s start with a backend example. Imagine you have a Django project with a Task model, and you want to add a new field called created_at to track when each task was created.

If you just say:

Add created_at field to tasks

The Codex will take a long time to think whenever it is required to find something in the file's structure.

To avoid this, you should be specific about the following things in your prompt:

• The file to change
• The locations of files with required context OR the context itself
• Specifically ask not to double-check your context if you are sure it is correct

Let’s build a better prompt step by step.

Step 1: Specify the file and model

Start by telling Codex exactly where to make the change:

In core/models.py, add a created_at field to the Task model

This tells Codex the file (core/models.py) and the model (Task) to update.

Step 2: Describe the field

You can add more detail about the field type. For example, if you want a timestamp:

In core/models.py, add a DateTimeField called created_at to the Task model

Step 3: Request follow-up actions

After changing a Django model, you need to make migrations. You can include this in your prompt:

In core/models.py add created_at field to the "Task" model and apply migrations 

This is a clear, complete prompt. Codex now knows exactly what to do: open the right file, update the right model, and run the necessary commands to apply the change.

By being specific, you help Codex:

• Find the right place in your code
• Make the correct change
• Handle any required follow-up steps

There is a natural question: if I already know what to change, why do I even need to use Codex?

1. Sometimes you might not remember the exact syntax, and Codex can make adjustments faster than if you were to search for the correct syntax.
2. Changes can be much more complex in an actual project than in this example. In such cases, Codex might be extremely helpful

Another question is: What if I don't know the location of the changes? Just ask Codex! You can start by asking a general question, like this:

If I want to add a field to my model in Django, which file is to be modified? Where is this file in my project?

And then proceed to a specific request. It is a common prompt engineering approach.

Now, let’s look at a frontend example. Suppose you want to show the creation date of each task in your task list template. You also want the date to appear in a lightweight gray font under the task’s name.

If you just say:

Show created_at in the template

Codex might not know which template to update, where to put the date, or how it should look.

Let’s build a better prompt step by step.

Step 1: Specify the template file

Tell Codex which file to edit:

In task_list.html, show the created_at field for each task

Step 2: Describe the placement

Say where the date should appear:

In task_list.html, show the created_at field under the task name

Step 3: Describe the style

Add details about how it should look:

In task_list.html, show the created_at field under the task name in a lightweight gray font

You make it much more likely that Codex will get it right the first time.

Step 4: Solving the "Long Thinking" problem

Make the context clearer, so Codex doesn't go into project structure exploration:

In task_list.html, show created_at field under the task name in a lightweight gray font. `created_at` is a field of the `Task` model. It is a `DateTimeField`. Don't validate this before making changes.

To sum up, when you want Codex to make local code changes, always be clear and specific. Tell Codex:

• Which file to edit
• What to change or add
• How the change should look or behave
• Any follow-up steps needed

This approach helps Codex work faster and with fewer mistakes.

Now, you’ll get a chance to practice writing your own prompts for local code updates. Try to be as clear and detailed as possible, just like in the examples above. Good luck!